From julian.reschke@gmx.de Sun Jan 1 11:15:10 2012 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 6961811E8081 for ; Sun, 1 Jan 2012 11:15:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.866 X-Spam-Level: X-Spam-Status: No, score=-103.866 tagged_above=-999 required=5 tests=[AWL=-1.267, 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 OuhO7EnjiQ08 for ; Sun, 1 Jan 2012 11:15:09 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 77D1111E8073 for ; Sun, 1 Jan 2012 11:15:09 -0800 (PST) Received: (qmail invoked by alias); 01 Jan 2012 19:15:08 -0000 Received: from p5DCC3F8F.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.63.143] by mail.gmx.net (mp061) with SMTP; 01 Jan 2012 20:15:08 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18XtMFoyywXUAMtxRUJA9JEQJie+9bLz2dJTP8cuU etFoo5spexczsV Message-ID: <4F00B0B6.4020209@gmx.de> Date: Sun, 01 Jan 2012 20:15:02 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Mike Jones References: <4E1F6AAD24975D4BA5B16804296739435F763122@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739435F772D1D@TK5EX14MBXC283.redmond.corp.microsoft.com> <4EEF13F1.7030409@gmx.de> <4E1F6AAD24975D4BA5B16804296739435F78F5BB@TK5EX14MBXC283.redmond.corp.microsoft.com> <4EFD91B4.5050904@gmx.de> <4E1F6AAD24975D4BA5B16804296739435F790386@TK5EX14MBXC283.redmond.corp.microsoft.com> <4EFEF8F1.9070406@gmx.de> <4E1F6AAD24975D4BA5B16804296739435F790F3D@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739435F790F3D@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: Mark Nottingham , Barry Leiba , OAuth WG Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft 15? 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, 01 Jan 2012 19:15:10 -0000 On 2011-12-31 20:40, Mike Jones wrote: > Maybe I misunderstood your position. If you agree that '\' may not occur in the INPUT string, then that issue can be closed. That was the working group consensus position, per the cited e-mails. I thought that you were arguing that syntax restrictions on the parameters should only be placed upon the OUTPUT string - which forces all implementations to support unnecessary encodings like "\a\b\c" for "abc". Please let me know whether you're fine with the working group prohibiting the use of '\' in the input string as the spec presently currently does. I'm not ok with that; because it's totally besides the point. A recipient of WWW-Authenticate needs to use a proper parser for that header field. And if you use a proper parser, it doesn't matter. I'm not saying anybody should send something like that. What I'm saying is that you shouldn't create an illusion that a recipient doesn't need to deal with it. A recipient that can't handle quoted-string syntax in auth-params is broken. A recipient that can't handle token syntax in auth-params is broken as well. Finally, please re-read what I said: the syntax of the challenge is defined by HTTP. The bearer spec can't change the parsing rules, because you need a generic parser to properly handle header fields containing multiple challenges. Once that generic parser has done it's job, it should not matter anymore whether a value used the token syntax or the quoted-string syntax, and also it shouldn't matter anymore where unescaping has taken place or not. What you're trying to do is comparable with defining an XML vocabulary where you profile how an attribute is serialized (' vs ", character encoding, escaping). Don't. Best regards, Julian From Michael.Jones@microsoft.com Sun Jan 1 11:41:43 2012 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 DBB6411E8080 for ; Sun, 1 Jan 2012 11:41:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.832 X-Spam-Level: X-Spam-Status: No, score=-4.832 tagged_above=-999 required=5 tests=[AWL=1.767, 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 F3ug3-t6tcpu for ; Sun, 1 Jan 2012 11:41:43 -0800 (PST) Received: from TX2EHSOBE004.bigfish.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id 274FE11E8073 for ; Sun, 1 Jan 2012 11:41:43 -0800 (PST) Received: from mail120-tx2-R.bigfish.com (10.9.14.241) by TX2EHSOBE004.bigfish.com (10.9.40.24) with Microsoft SMTP Server id 14.1.225.23; Sun, 1 Jan 2012 19:41:42 +0000 Received: from mail120-tx2 (localhost [127.0.0.1]) by mail120-tx2-R.bigfish.com (Postfix) with ESMTP id 77EB9802AA; Sun, 1 Jan 2012 19:41:42 +0000 (UTC) X-SpamScore: -12 X-BigFish: VS-12(zz9371I936eK542M98dKzz1202hzzz2fh2a8h668h839h944h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail120-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail120-tx2 (localhost.localdomain [127.0.0.1]) by mail120-tx2 (MessageSwitch) id 1325446902268626_30095; Sun, 1 Jan 2012 19:41:42 +0000 (UTC) Received: from TX2EHSMHS040.bigfish.com (unknown [10.9.14.244]) by mail120-tx2.bigfish.com (Postfix) with ESMTP id 39D6160228; Sun, 1 Jan 2012 19:41:42 +0000 (UTC) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS040.bigfish.com (10.9.99.140) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sun, 1 Jan 2012 19:41:42 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.84]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.02.0247.005; Sun, 1 Jan 2012 11:41:42 -0800 From: Mike Jones To: Julian Reschke Thread-Topic: auth-param syntax, was: [OAUTH-WG] OK to post OAuth Bearer draft 15? Thread-Index: Acy6zxL5vGVpwSHMTIKvMNNyq2nAEgARlkuAAK9WC5AAKqDYgAH8LmDAACydzgAACThoEAAsT3KAAADdvvAAQKoiAAAQYozQ Date: Sun, 1 Jan 2012 19:41:42 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739435F79132B@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739435F763122@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739435F772D1D@TK5EX14MBXC283.redmond.corp.microsoft.com> <4EEF13F1.7030409@gmx.de> <4E1F6AAD24975D4BA5B16804296739435F78F5BB@TK5EX14MBXC283.redmond.corp.microsoft.com> <4EFD91B4.5050904@gmx.de> <4E1F6AAD24975D4BA5B16804296739435F790386@TK5EX14MBXC283.redmond.corp.microsoft.com> <4EFEF8F1.9070406@gmx.de> <4E1F6AAD24975D4BA5B16804296739435F790F3D@TK5EX14MBXC283.redmond.corp.microsoft.com> <4F00B0B6.4020209@gmx.de> In-Reply-To: <4F00B0B6.4020209@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 X-OriginatorOrg: microsoft.com Cc: Mark Nottingham , Barry Leiba , OAuth WG Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft 15? 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, 01 Jan 2012 19:41:44 -0000 I'll note that in some profiles, the Bearer challenge may be the only one t= hat the application may legally use. In that case, there's no need to be a= ble parse other challenges that the application can't fulfill in the first = place. The application would fail if an unsupported challenge type was use= d in either case. As editor, I'll note that it doesn't seem like this discussion is moving th= e process forward anymore. I believe that we've sufficiently clarified tha= t you hold a different position than the working group consensus (which I r= ealize is your right to do). I also believe that the issues have been suff= iciently well discussed on the list for all parties to be well informed. Therefore, it seems that my earlier observation still holds: In the New Ye= ar, the chairs and area directors (and possibly the OAuth design committee)= will need to decide how to proceed on this issue. It would be good to see= the spec finished shortly. All the best, -- Mike -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de]=20 Sent: Sunday, January 01, 2012 11:15 AM To: Mike Jones Cc: Barry Leiba; Mark Nottingham; OAuth WG Subject: Re: auth-param syntax, was: [OAUTH-WG] OK to post OAuth Bearer dra= ft 15? On 2011-12-31 20:40, Mike Jones wrote: > Maybe I misunderstood your position. If you agree that '\' may not occur= in the INPUT string, then that issue can be closed. That was the working = group consensus position, per the cited e-mails. I thought that you were a= rguing that syntax restrictions on the parameters should only be placed upo= n the OUTPUT string - which forces all implementations to support unnecessa= ry encodings like "\a\b\c" for "abc". Please let me know whether you're fi= ne with the working group prohibiting the use of '\' in the input string as= the spec presently currently does. I'm not ok with that; because it's totally besides the point. A recipient of WWW-Authenticate needs to use a proper parser for that heade= r field. And if you use a proper parser, it doesn't matter. I'm not saying anybody should send something like that. What I'm saying is = that you shouldn't create an illusion that a recipient doesn't need to deal= with it. A recipient that can't handle quoted-string syntax in auth-params is broken= . A recipient that can't handle token syntax in auth-params is broken as we= ll. Finally, please re-read what I said: the syntax of the challenge is defined= by HTTP. The bearer spec can't change the parsing rules, because you need = a generic parser to properly handle header fields containing multiple chall= enges. Once that generic parser has done it's job, it should not matter any= more whether a value used the token syntax or the quoted-string syntax, and= also it shouldn't matter anymore where unescaping has taken place or not. What you're trying to do is comparable with defining an XML vocabulary wher= e you profile how an attribute is serialized (' vs ", character encoding, = escaping). Don't. Best regards, Julian From julian.reschke@gmx.de Sun Jan 1 11:49:28 2012 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 A58721F0C47 for ; Sun, 1 Jan 2012 11:49:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.739 X-Spam-Level: X-Spam-Status: No, score=-103.739 tagged_above=-999 required=5 tests=[AWL=-1.140, 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 1gTlQlEvp6RO for ; Sun, 1 Jan 2012 11:49:28 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id B8CEB1F0C36 for ; Sun, 1 Jan 2012 11:49:27 -0800 (PST) Received: (qmail invoked by alias); 01 Jan 2012 19:49:26 -0000 Received: from p5DCC3F8F.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.63.143] by mail.gmx.net (mp028) with SMTP; 01 Jan 2012 20:49:26 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/mav4r3TPmQheJw00Y6ZD/aX3U7t/bWQkCSn7Jda bkdt1tRQudvcSV Message-ID: <4F00B8BE.4080603@gmx.de> Date: Sun, 01 Jan 2012 20:49:18 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Mike Jones References: <4E1F6AAD24975D4BA5B16804296739435F763122@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739435F772D1D@TK5EX14MBXC283.redmond.corp.microsoft.com> <4EEF13F1.7030409@gmx.de> <4E1F6AAD24975D4BA5B16804296739435F78F5BB@TK5EX14MBXC283.redmond.corp.microsoft.com> <4EFD91B4.5050904@gmx.de> <4E1F6AAD24975D4BA5B16804296739435F790386@TK5EX14MBXC283.redmond.corp.microsoft.com> <4EFEF8F1.9070406@gmx.de> <4E1F6AAD24975D4BA5B16804296739435F790F3D@TK5EX14MBXC283.redmond.corp.microsoft.com> <4F00B0B6.4020209@gmx.de> <4E1F6AAD24975D4BA5B16804296739435F79132B@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739435F79132B@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: Mark Nottingham , Barry Leiba , OAuth WG Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft 15? 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, 01 Jan 2012 19:49:28 -0000 On 2012-01-01 20:41, Mike Jones wrote: > I'll note that in some profiles, the Bearer challenge may be the only one that the application may legally use. In that case, there's no need to be able parse other challenges that the application can't fulfill in the first place. The application would fail if an unsupported challenge type was used in either case. The ability to send multiple challenges with the recipient taking the strongest one it supports is an important part of HTTP auth. I'd like to understand what scenario would disable that. > As editor, I'll note that it doesn't seem like this discussion is moving the process forward anymore. I believe that we've sufficiently clarified that you hold a different position than the working group consensus (which I realize is your right to do). I also believe that the issues have been sufficiently well discussed on the list for all parties to be well informed. For completeness, I'll repeat that I don't think that there was WG consensus for your point of view, but I'll leave it to the chairs to decide how to proceed. > Therefore, it seems that my earlier observation still holds: In the New Year, the chairs and area directors (and possibly the OAuth design committee) will need to decide how to proceed on this issue. It would be good to see the spec finished shortly. Yes, it would. I still have no idea what's keeping you from doing what HTTPbis recommends. It would be extremely helpful to get *technical* feedback on that (so far I haven't seen any). Best regards, Julian From igor.faynberg@alcatel-lucent.com Sun Jan 1 22:26:12 2012 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 10D3821F8F06 for ; Sun, 1 Jan 2012 22:26:12 -0800 (PST) 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 JHfIhjJq-8O6 for ; Sun, 1 Jan 2012 22:26:11 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 73C6221F8D3E for ; Sun, 1 Jan 2012 22:26:11 -0800 (PST) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q026Q6ut011990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 2 Jan 2012 00:26:09 -0600 (CST) 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 q026Q6S6006237 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 2 Jan 2012 00:26:06 -0600 Received: from [135.244.20.78] (faynberg.lra.lucent.com [135.244.20.78]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q026Pu0U004085; Mon, 2 Jan 2012 00:26:04 -0600 (CST) Message-ID: <4F014DF3.9030105@alcatel-lucent.com> Date: Mon, 02 Jan 2012 01:25:55 -0500 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: Amos Jeffries References: <301AF9A4-395C-4B5A-8610-CD86BEE1401A@mnot.net> <4EFE7E22.9010200@treenet.co.nz> In-Reply-To: <4EFE7E22.9010200@treenet.co.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Cc: ietf-http-wg@w3.org, oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth Bearer authentication - for proxies? 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: Mon, 02 Jan 2012 06:26:12 -0000 On 12/30/2011 10:14 PM, Amos Jeffries wrote: > .... >> >> Reading section 2.3, it appears this method of transferring the >> credentials is open to replay attacks when caching TLS middleware is >> present. I believe this spec should mandate cache controls on >> responses using that method. Otherwise a lot of HTTP compliant >> middleware will feel free to store and supply the protected response >> to later replay attacks. >> > Amos, I believe that the draft addresses the replay matters by specifying the validity time field. Do you see a problem with that? (I did not understand what "HTTP-compliant middleware" meant, but if it is something at the proxies, I think this is further addressed by making TLS a must--which will make the token simply invisible.) With best wishes for the New Year to you and all OAuthers, Igor Igor From squid3@treenet.co.nz Mon Jan 2 00:18:12 2012 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 556ED11E8099 for ; Mon, 2 Jan 2012 00:18:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.225 X-Spam-Level: X-Spam-Status: No, score=-2.225 tagged_above=-999 required=5 tests=[AWL=-1.563, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_EQ_STATIC=1.172] 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 9Z6pGqmJfXhI for ; Mon, 2 Jan 2012 00:18:11 -0800 (PST) Received: from treenet.co.nz (ip-58-28-153-233.static-xdsl.xnet.co.nz [58.28.153.233]) by ietfa.amsl.com (Postfix) with ESMTP id BA50A11E8098 for ; Mon, 2 Jan 2012 00:18:11 -0800 (PST) Received: from [192.168.1.3] (unknown [119.224.36.238]) by treenet.co.nz (Postfix) with ESMTP id AE990E6E3D; Mon, 2 Jan 2012 21:18:01 +1300 (NZDT) Message-ID: <4F016837.3040904@treenet.co.nz> Date: Mon, 02 Jan 2012 21:17:59 +1300 From: Amos Jeffries User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: igor.faynberg@alcatel-lucent.com References: <301AF9A4-395C-4B5A-8610-CD86BEE1401A@mnot.net> <4EFE7E22.9010200@treenet.co.nz> <4F014DF3.9030105@alcatel-lucent.com> In-Reply-To: <4F014DF3.9030105@alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ietf-http-wg@w3.org, oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth Bearer authentication - for proxies? 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, 02 Jan 2012 08:18:12 -0000 On 2/01/2012 7:25 p.m., Igor Faynberg wrote: > On 12/30/2011 10:14 PM, Amos Jeffries wrote: >> .... >>> >>> Reading section 2.3, it appears this method of transferring the >>> credentials is open to replay attacks when caching TLS middleware is >>> present. I believe this spec should mandate cache controls on >>> responses using that method. Otherwise a lot of HTTP compliant >>> middleware will feel free to store and supply the protected response >>> to later replay attacks. >>> >> > Amos, > > I believe that the draft addresses the replay matters by specifying > the validity time field. Do you see a problem with that? I did not see any such validity time field in the HTTP mechanisms. You mean the validity period of the token itself? that would be irrelevant as the case I am raising is for software which does not support Bearer specs. (1) assuming the client is malicious and cannot be trusted to follow the bearer token limits. (2) the proxy acting as server for the transaction does *not* support bearer and is thus not implementing any bearer token time limitations. The HTTP definition of www-auth specifies an implicit "Cache-Control: private" unless explicit "public" is added. The cache supports the HTTP imiplicit definitinon and does not cache the reply. Replay requests will get nothing from the cache. In the query string case proxies use the full abolute URL (including query string with token) as part of the storage key. The HTTP spec outlines that the absence of cache-control time limitations permits a proxy to store the reply as long as it wishes. Meaning that any time limits imposed by the Bearer spec around the token itself are not supported. Therefore Therefore any client requesting the URL with the token can be presented with a cached reply *indefinitely*. At no point between malicious client and proxy is any bearer implementation involved. > > (I did not understand what "HTTP-compliant middleware" meant, but if > it is something at the proxies, I think this is further addressed by > making TLS a must--which will make the token simply invisible.) By "HTTP compolliant middleware" I mean any software which obeys HTTP proxy guidelines but not necessarily OAuth or other specifications. There are alot of those. > > With best wishes for the New Year to you and all OAuthers, > > Igor > > Igor From torsten@lodderstedt.net Mon Jan 2 02:00:50 2012 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 7466D21F8EED for ; Mon, 2 Jan 2012 02:00:50 -0800 (PST) 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 J0HaQD3s-r56 for ; Mon, 2 Jan 2012 02:00:50 -0800 (PST) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.40]) by ietfa.amsl.com (Postfix) with ESMTP id E9FCD21F8EEB for ; Mon, 2 Jan 2012 02:00:49 -0800 (PST) Received: from [77.6.189.11] (helo=[192.168.1.37]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1Rheh8-0002OM-Hx; Mon, 02 Jan 2012 11:00:42 +0100 Message-ID: <4F018048.1020900@lodderstedt.net> Date: Mon, 02 Jan 2012 11:00:40 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Amos Jeffries References: <301AF9A4-395C-4B5A-8610-CD86BEE1401A@mnot.net> <4EFE7E22.9010200@treenet.co.nz> <4F014DF3.9030105@alcatel-lucent.com> <4F016837.3040904@treenet.co.nz> In-Reply-To: <4F016837.3040904@treenet.co.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: ietf-http-wg@w3.org, oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth Bearer authentication - for proxies? 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, 02 Jan 2012 10:00:50 -0000 Hi, >>> >> Amos, >> >> I believe that the draft addresses the replay matters by specifying >> the validity time field. Do you see a problem with that? > > I did not see any such validity time field in the HTTP mechanisms. > You mean the validity period of the token itself? that would be > irrelevant as the case I am raising is for software which does not > support Bearer specs. > > Even if the software is not aware of the bearer spec, a token that becomes invalid after a certain time span cannot sucessfully be replayed any longer. general note: I do not understand why caching proxies should impose a problem in case TLS is used (end2end). Could you please explain? regards, Torsten. From squid3@treenet.co.nz Mon Jan 2 04:07:54 2012 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 9BFB521F8E27 for ; Mon, 2 Jan 2012 04:07:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.593 X-Spam-Level: X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=-1.931, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_EQ_STATIC=1.172] 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 7ZVBAU9jxnnQ for ; Mon, 2 Jan 2012 04:07:54 -0800 (PST) Received: from treenet.co.nz (ip-58-28-153-233.static-xdsl.xnet.co.nz [58.28.153.233]) by ietfa.amsl.com (Postfix) with ESMTP id 21A9321F8E26 for ; Mon, 2 Jan 2012 04:07:54 -0800 (PST) Received: from [192.168.1.3] (unknown [119.224.36.238]) by treenet.co.nz (Postfix) with ESMTP id 6FECEE6D60; Tue, 3 Jan 2012 01:07:43 +1300 (NZDT) Message-ID: <4F019E09.3070007@treenet.co.nz> Date: Tue, 03 Jan 2012 01:07:37 +1300 From: Amos Jeffries User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Torsten Lodderstedt References: <301AF9A4-395C-4B5A-8610-CD86BEE1401A@mnot.net> <4EFE7E22.9010200@treenet.co.nz> <4F014DF3.9030105@alcatel-lucent.com> <4F016837.3040904@treenet.co.nz> <4F018048.1020900@lodderstedt.net> In-Reply-To: <4F018048.1020900@lodderstedt.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ietf-http-wg@w3.org, oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth Bearer authentication - for proxies? 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, 02 Jan 2012 12:07:54 -0000 On 2/01/2012 11:00 p.m., Torsten Lodderstedt wrote: > Hi, >>>> >>> Amos, >>> >>> I believe that the draft addresses the replay matters by specifying >>> the validity time field. Do you see a problem with that? >> >> I did not see any such validity time field in the HTTP mechanisms. >> You mean the validity period of the token itself? that would be >> irrelevant as the case I am raising is for software which does not >> support Bearer specs. >> >> > > Even if the software is not aware of the bearer spec, a token that > becomes invalid after a certain time span cannot sucessfully be > replayed any longer. There is no time span limit mentioned in the section 2.3 when token is passed in the query string. That is my point. Proxies which cache and obey HTTP but not Bearer *will* answer to replay attacks by providing the supposedly secure response body. > > general note: I do not understand why caching proxies should impose a > problem in case TLS is used (end2end). Could you please explain? Because TLS is hop-by-hop (in HTTP hops, end-to-end only in TCP hops). Proxies which decrypt TLS and provide responses out of cache are already deployed in many places. Mostly in the form of reverse-proxies, but corporate decryption proxies are also on the increase. AYJ From igor.faynberg@alcatel-lucent.com Mon Jan 2 14:17:57 2012 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 87A1921F8AB9 for ; Mon, 2 Jan 2012 14:17:57 -0800 (PST) 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 VCZRnarwLuvQ for ; Mon, 2 Jan 2012 14:17:55 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id F065421F8AB8 for ; Mon, 2 Jan 2012 14:17:54 -0800 (PST) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id q02MHpt2001865 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 2 Jan 2012 16:17:53 -0600 (CST) 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 q02MHoTx031983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 2 Jan 2012 16:17:51 -0600 Received: from [135.244.20.78] (faynberg.lra.lucent.com [135.244.20.78]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q02MHbce020039; Mon, 2 Jan 2012 16:17:50 -0600 (CST) Message-ID: <4F022CFA.80907@alcatel-lucent.com> Date: Mon, 02 Jan 2012 17:17:30 -0500 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: Amos Jeffries References: <301AF9A4-395C-4B5A-8610-CD86BEE1401A@mnot.net> <4EFE7E22.9010200@treenet.co.nz> <4F014DF3.9030105@alcatel-lucent.com> <4F016837.3040904@treenet.co.nz> <4F018048.1020900@lodderstedt.net> <4F019E09.3070007@treenet.co.nz> In-Reply-To: <4F019E09.3070007@treenet.co.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Cc: ietf-http-wg@w3.org, oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth Bearer authentication - for proxies? 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: Mon, 02 Jan 2012 22:17:57 -0000 I am at a loss here; granted, it is a gray area... Does it mean that RFC 2817 has not been implemented properly? To make it simple: At the client, I establish a session key with the server, and then use it for confidentiality. How is this key known to any proxy? Igor On 1/2/2012 7:07 AM, Amos Jeffries wrote: > On 2/01/2012 11:00 p.m., Torsten Lodderstedt wrote: > ... >> >> general note: I do not understand why caching proxies should impose a >> problem in case TLS is used (end2end). Could you please explain? > > Because TLS is hop-by-hop (in HTTP hops, end-to-end only in TCP hops). > Proxies which decrypt TLS and provide responses out of cache are > already deployed in many places. Mostly in the form of > reverse-proxies, but corporate decryption proxies are also on the > increase. > > AYJ From squid3@treenet.co.nz Mon Jan 2 16:36:57 2012 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 1361321F8522 for ; Mon, 2 Jan 2012 16:36:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.751 X-Spam-Level: X-Spam-Status: No, score=-2.751 tagged_above=-999 required=5 tests=[AWL=-2.089, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_EQ_STATIC=1.172] 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 shEvTPl+SBou for ; Mon, 2 Jan 2012 16:36:56 -0800 (PST) Received: from treenet.co.nz (ip-58-28-153-233.static-xdsl.xnet.co.nz [58.28.153.233]) by ietfa.amsl.com (Postfix) with ESMTP id 8799F21F8516 for ; Mon, 2 Jan 2012 16:36:56 -0800 (PST) Received: from [192.168.1.3] (unknown [119.224.36.238]) by treenet.co.nz (Postfix) with ESMTP id ECE5DE70DA; Tue, 3 Jan 2012 13:36:51 +1300 (NZDT) Message-ID: <4F024DA0.7080707@treenet.co.nz> Date: Tue, 03 Jan 2012 13:36:48 +1300 From: Amos Jeffries User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: igor.faynberg@alcatel-lucent.com References: <301AF9A4-395C-4B5A-8610-CD86BEE1401A@mnot.net> <4EFE7E22.9010200@treenet.co.nz> <4F014DF3.9030105@alcatel-lucent.com> <4F016837.3040904@treenet.co.nz> <4F018048.1020900@lodderstedt.net> <4F019E09.3070007@treenet.co.nz> <4F022CFA.80907@alcatel-lucent.com> In-Reply-To: <4F022CFA.80907@alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ietf-http-wg@w3.org, oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth Bearer authentication - for proxies? 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, 03 Jan 2012 00:36:57 -0000 On 1/2/2012 7:07 AM, Amos Jeffries wrote: >> On 2/01/2012 11:00 p.m., Torsten Lodderstedt wrote: >> ... >>> >>> general note: I do not understand why caching proxies should impose >>> a problem in case TLS is used (end2end). Could you please explain? >> >> Because TLS is hop-by-hop (in HTTP hops, end-to-end only in TCP >> hops). Proxies which decrypt TLS and provide responses out of cache >> are already deployed in many places. Mostly in the form of >> reverse-proxies, but corporate decryption proxies are also on the >> increase. >> >> AYJ On 3/01/2012 11:17 a.m., Igor Faynberg wrote: > I am at a loss here; granted, it is a gray area... Does it mean that > RFC 2817 has not been implemented properly? > From RFC 2817: " 5. Upgrade across Proxies As a hop-by-hop header, Upgrade is negotiated between each pair of HTTP counterparties. If a User Agent sends a request with an Upgrade header to a proxy, it is requesting a change to the protocol between itself and the proxy, not an end-to-end change. " The more common case is CONNECT method from RFC 2068, from a user agent to a reverse-proxy. Same behaviour. > To make it simple: At the client, I establish a session key with the > server, and then use it for confidentiality. How is this key known to > any proxy? "the server" is a proxy. AYJ From internet-drafts@ietf.org Tue Jan 3 08:33:46 2012 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 786A121F84E4; Tue, 3 Jan 2012 08:33:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 qY64QaqWpnmO; Tue, 3 Jan 2012 08:33:46 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFD2021F8482; Tue, 3 Jan 2012 08:33:45 -0800 (PST) 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.64p1 Message-ID: <20120103163345.3744.11230.idtracker@ietfa.amsl.com> Date: Tue, 03 Jan 2012 08:33:45 -0800 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-urn-sub-ns-02.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, 03 Jan 2012 16:33:46 -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 : An IETF URN Sub-Namespace for OAuth Author(s) : Hannes Tschofenig Filename : draft-ietf-oauth-urn-sub-ns-02.txt Pages : 5 Date : 2012-01-03 This document establishes an IETF URN Sub-namespace for use with OAuth related specifications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-urn-sub-ns-02.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-urn-sub-ns-02.txt From internet-drafts@ietf.org Tue Jan 3 08:34:47 2012 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 916CA21F84E5; Tue, 3 Jan 2012 08:34:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 DT2xSLj8ACMc; Tue, 3 Jan 2012 08:34:46 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2188B21F84B1; Tue, 3 Jan 2012 08:34:46 -0800 (PST) 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.64p1 Message-ID: <20120103163446.4462.56618.idtracker@ietfa.amsl.com> Date: Tue, 03 Jan 2012 08:34:46 -0800 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-saml2-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: Tue, 03 Jan 2012 16:34: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-10.txt Pages : 16 Date : 2012-01-03 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-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-saml2-bearer-10.txt From wmills@yahoo-inc.com Tue Jan 3 11:35:42 2012 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 15AF911E80CB for ; Tue, 3 Jan 2012 11:35:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.246 X-Spam-Level: X-Spam-Status: No, score=-15.246 tagged_above=-999 required=5 tests=[AWL=-0.061, BAYES_40=-0.185, 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 n4hmDVMqb80H for ; Tue, 3 Jan 2012 11:35:41 -0800 (PST) Received: from nm10.bullet.mail.sp2.yahoo.com (nm10.bullet.mail.sp2.yahoo.com [98.139.91.80]) by ietfa.amsl.com (Postfix) with SMTP id 0FBD711E80C7 for ; Tue, 3 Jan 2012 11:35:41 -0800 (PST) Received: from [98.139.91.61] by nm10.bullet.mail.sp2.yahoo.com with NNFMP; 03 Jan 2012 19:35:40 -0000 Received: from [98.139.91.47] by tm1.bullet.mail.sp2.yahoo.com with NNFMP; 03 Jan 2012 19:35:40 -0000 Received: from [127.0.0.1] by omp1047.mail.sp2.yahoo.com with NNFMP; 03 Jan 2012 19:35:40 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 940420.91576.bm@omp1047.mail.sp2.yahoo.com Received: (qmail 872 invoked by uid 60001); 3 Jan 2012 19:35:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1325619340; bh=UDUU+I4XTKr8xEBbBiWNaeDlXPP2WD988bNhBj//CqM=; 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=o2qfkVvNpp9q50mCwdV7/UTfixbboVCZAI538QjYVUZj7IkZAObyLEGdWAQPcbfzp/SmMwAIkiuV0rdUrsKM+V6NRnYqz84npACDzcntcnA/8B7t1oKZsAEav2+g2rUk7/sjr9jlupKYHG0mXh4hRvPSI1tBlq2FQSFdTkxR3zU= 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=HVDjeegQBaOn0oaAwSZ7Ujbj/sdkYQc6YFDY3XK116rlbbI+t6+shbFCA5XXHW7MPrlOQoRKWiadoaOLxo8iEQpF9FzSCzvlgX2PSO3eFt+xTp8Eaq34UYkFp+TPzb7pgHUVI1RouTdtSkrEYS0pjpuMoErdEAGUXSgGdpbyPS4=; X-YMail-OSG: M.r3AP8VM1kPx_CC8pRYFWWevpuGtmblVsqvOjE0yRngpd. 0YicuL4qfg7AT5A5zNZZ55XOeslDFYe5eY0qeMYV_B35RPSaHFc9aF50cysD o.rHgtAo5ibH6WxQcpW4PUlaVhDn5NFuotz_8HkzDDq90OzVaGHVNV0SEHam 3PXYEavpiU5CSLWDPuUecNZ1G_zV9SGaEJwnzQKGes6E690KkLLh8lVIXDIW Iim.sMLWtgAdxtIo4o3eesJjBWmQygCwE1YnvykMuO3qdlAKkuIUD03c5eJh u_mtsuai4RQ2lQHczP8Nf7E6jqpGy3fPUOAuAMb9v_Tvvf7_wKwQdm_zrXCq 3AxMcyah59cMzou.yInQIGcYsiehOqgzyLGkowl2MMCyU.fer2N8xFJMf4Sh bB9zjBuh6xXp9puw7emVqAXq85UdbiUDk.Q-- Received: from [209.131.62.115] by web31808.mail.mud.yahoo.com via HTTP; Tue, 03 Jan 2012 11:35:40 PST X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.116.331537 References: <4E1F6AAD24975D4BA5B16804296739435F763122@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739435F772D1D@TK5EX14MBXC283.redmond.corp.microsoft.com> <4EEF13F1.7030409@gmx.de> <4E1F6AAD24975D4BA5B16804296739435F78F5BB@TK5EX14MBXC283.redmond.corp.microsoft.com> <4EFD91B4.5050904@gmx.de> <4E1F6AAD24975D4BA5B16804296739435F790386@TK5EX14MBXC283.redmond.corp.microsoft.com> Message-ID: <1325619340.463.YahooMailNeo@web31808.mail.mud.yahoo.com> Date: Tue, 3 Jan 2012 11:35:40 -0800 (PST) From: William Mills To: Mike Jones , Julian Reschke In-Reply-To: <4E1F6AAD24975D4BA5B16804296739435F790386@TK5EX14MBXC283.redmond.corp.microsoft.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="258328648-620139665-1325619340=:463" Cc: Mark Nottingham , Barry Leiba , OAuth WG Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft 15? 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, 03 Jan 2012 19:35:42 -0000 --258328648-620139665-1325619340=:463 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Is all this only around the scope parameter?=A0 My mail cited below is with= regards to the character set for a valid scope parameter, which we should = be able to define and then lean on the HTTPbis spec for the actual paramete= r syntax.=0A=0A=0A=0A________________________________=0A From: Mike Jones <= Michael.Jones@microsoft.com>=0ATo: Julian Reschke = =0ACc: Mark Nottingham ; Barry Leiba ; OAuth WG =0ASent: Friday, December 30, 2011 3:19 PM=0A= Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer dr= aft 15?=0A =0AI did already back the statement that this is the working gro= up consensus with the e-mails attached in this note sent to you on December= 12, 2011:=0A=A0 - http://www.ietf.org/mail-archive/web/oauth/current/msg08= 042.html=0A=0ABut since that apparently wasn't convincing to you that this = working group decision represents more than "just me disagreeing with you",= here are references to individual messages referenced in the above e-mail:= =0A=A0 - Eran Hammer-Lahav: http://www.ietf.org/mail-archive/web/oauth/curr= ent/msg07698.html=0A=A0 - John Bradley:=A0 http://www.ietf.org/mail-archive= /web/oauth/current/msg07699.html=0A=A0 - William Mills:=A0 http://www.ietf.= org/mail-archive/web/oauth/current/msg07700.html=0A=A0 - Mike Jones:=A0 htt= p://www.ietf.org/mail-archive/web/oauth/current/msg07701.html=0A=A0 - Phil = Hunt:=A0 http://www.ietf.org/mail-archive/web/oauth/current/msg07702.html= =0A=A0 - Justin Richer:=A0 http://www.ietf.org/mail-archive/web/oauth/curre= nt/msg07692.html=0A=0AAs for your assertion that the specs are in conflict,= yes, the Bearer spec includes a different decision than a RECOMMENDED clau= se in the HTTPbis spec (which was added after the Bearer text was already i= n place).=A0 However, it is not violating any MUST clauses in the HTTPbis s= pec.=A0 Given that no MUSTS are violated, I don't see it mandatory for this= tension to be resolved in favor of one spec or the other in order for both= to be approved as RFCs.=A0 I look forward to seeing that happen soon in bo= th cases (and for the OAuth core spec as well).=0A=0A=A0=A0=A0 =A0=A0=A0 = =A0=A0=A0 =A0=A0=A0 Best wishes,=0A=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 = -- Mike=0A=0A-----Original Message-----=0AFrom: Julian Reschke [mailto:juli= an.reschke@gmx.de] =0ASent: Friday, December 30, 2011 2:26 AM=0ATo: Mike Jo= nes=0ACc: Barry Leiba; Mark Nottingham; OAuth WG=0ASubject: Re: auth-param = syntax, was: [OAUTH-WG] OK to post OAuth Bearer draft 15?=0A=0AOn 2011-12-2= 9 22:18, Mike Jones wrote:=0A> You proposed, Julian "3. Do not specify the = ABNF. The ABNF of the WWW-Authenticate is defined in HTTPbis. Just state th= e names of the parameters, their syntax *after* parsing and their semantics= ."=0A>=0A> About some of Mark Nottingham's comments, Barry wrote "Let me po= int out that "this represents working-group consensus" is not always a vali= d response.=A0 If the working group has actually considered the *issue*, th= at might be OK.=A0 But if there's consensus for the chosen solution and som= eone brings up a *new* issue with it, that issue needs to be addressed anew= ."=0A>=0A> Relative to these two statements, I believe that I should remark= at this point that your proposed semantics of only considering the syntax = after potential quoting was explicitly considered earlier by the working gr= oup and rejected.=A0 The consensus, instead, was for the present "no quotin= g will occur for legal inputs" semantics.=0A=0AIt would be helpful if you c= ould back this statement with pointers to mails. As far as I can tell it's = just you disagreeing with me.=0A=0ABack to the facts:=0A=0Aa) the bearer sp= ec defines an HTTP authentication scheme, and normatively refers to HTTPbis= Part7 for that=0A=0Ab) HTTPbis recommends new scheme definitions not to ha= ve their own ABNF, as the header field syntax is defined by HTTPbis, not th= e individual scheme=0A=0Ac) the bearer spec defines it's own ABNF neverthel= ess=0A=0ASo the two specs are in conflict, and we should resolve the confli= ct one way or the other.=0A=0AIf you disagree with the recommendation in HT= TPbis, then you really really should come over to HTTPbis WG and argue your= point of view.=0A=0AIf you agree with it, but think that the bearer spec c= an't follow the recommendation, then it would be good to explain the reason= ing (optimally in the spec).=0A=0AIf you agree with it, and think the beare= r spec *could* follow it, then... change it, by all means.=0A=0AAnyway, if = this issue isn't resolved before IETF LC then it will be raised again at th= at time.=0A=0A=0A> I believe that in the New Year the chairs and area direc= tors will need to decide how to proceed on this issue.=A0 (The working grou= p consensus, as I see it, is already both well-informed and clear on this p= oint, but I understand that that's not the only consideration.)=A0 It would= be good to see the spec finished shortly.=0A> ...=0A=0ABest regards, Julia= n=0A=0A=0A=0A_______________________________________________=0AOAuth mailin= g list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/oauth --258328648-620139665-1325619340=:463 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Is all this only around the scope parameter?  My mail cited below is= with regards to the character set for a valid scope parameter, which we sh= ould be able to define and then lean on the HTTPbis spec for the actual par= ameter syntax.

From: Mike Jones <Michael.Jones@micros= oft.com>
To: Julian= Reschke <julian.reschke@gmx.de>
Cc: Mark Nottingham <mnot@mnot.net>; Barry Leiba <barryleiba@computer.org>; OAuth WG <oauth@ietf.org>
<= span style=3D"font-weight: bold;">Sent: Friday, December 30, 201= 1 3:19 PM
Subject: Re:= [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft 15?
=
=0AI did already back the statement that this is the working gr= oup consensus with the e-mails attached in this note sent to you on Decembe= r 12, 2011:
  - http://www.ietf.org/mail-archive/web/oauth/current/= msg08042.html

But since that apparently wasn't convincing to you tha= t this working group decision represents more than "just me disagreeing wit= h you", here are references to individual messages referenced in the above = e-mail:
  - Eran Hammer-Lahav: http://www.ietf.org/mail-archive/web= /oauth/current/msg07698.html
  - John Bradley:  http://www.iet= f.org/mail-archive/web/oauth/current/msg07699.html
  - William Mill= s:  http://www.ietf.org/mail-archive/web/oauth/current/msg07700.html  - Mike Jones:  http://www.ietf.org/mail-archive/web/oauth/cur= rent/msg07701.html
  - Phil Hunt:  http://www.ietf.org/mail-ar= chive/web/oauth/current/msg07702.html
  - Justin Richer:  http://www.ietf.org/mail-archive/web/oauth/current/msg07692.html

As= for your assertion that the specs are in conflict, yes, the Bearer spec in= cludes a different decision than a RECOMMENDED clause in the HTTPbis spec (= which was added after the Bearer text was already in place).  However,= it is not violating any MUST clauses in the HTTPbis spec.  Given that= no MUSTS are violated, I don't see it mandatory for this tension to be res= olved in favor of one spec or the other in order for both to be approved as= RFCs.  I look forward to seeing that happen soon in both cases (and f= or the OAuth core spec as well).

      &nbs= p;         Best wishes,
   =             -- Mike

--= ---Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]
Sent:= Friday, December 30, 2011 2:26 AM
To: Mike Jones
Cc: Barry Leiba; Ma= rk Nottingham; OAuth WG
Subject: Re: auth-param syntax, was: [OAUTH-WG] = OK to post OAuth Bearer draft 15?

On 2011-12-29 22:18, Mike Jones wr= ote:
> You proposed, Julian "3. Do not specify the ABNF. The ABNF of = the WWW-Authenticate is defined in HTTPbis. Just state the names of the par= ameters, their syntax *after* parsing and their semantics."
>
>= About some of Mark Nottingham's comments, Barry wrote "Let me point out th= at "this represents working-group consensus" is not always a valid response= .  If the working group has actually considered the *issue*, that migh= t be OK.  But if there's consensus for the chosen solution and someone= brings up a *new* issue with it, that issue needs to be addressed anew.">
> Relative to these two statements, I believe that I should remark at this point that your proposed semantics of only consideri= ng the syntax after potential quoting was explicitly considered earlier by = the working group and rejected.  The consensus, instead, was for the p= resent "no quoting will occur for legal inputs" semantics.

It would = be helpful if you could back this statement with pointers to mails. As far = as I can tell it's just you disagreeing with me.

Back to the facts:<= br>
a) the bearer spec defines an HTTP authentication scheme, and normat= ively refers to HTTPbis Part7 for that

b) HTTPbis recommends new sch= eme definitions not to have their own ABNF, as the header field syntax is d= efined by HTTPbis, not the individual scheme

c) the bearer spec defi= nes it's own ABNF nevertheless

So the two specs are in conflict, and= we should resolve the conflict one way or the other.

If you disagre= e with the recommendation in HTTPbis, then you really really should come over to HTTPbis WG and argue your point of view.

If you agree = with it, but think that the bearer spec can't follow the recommendation, th= en it would be good to explain the reasoning (optimally in the spec).
If you agree with it, and think the bearer spec *could* follow it, then..= . change it, by all means.

Anyway, if this issue isn't resolved befo= re IETF LC then it will be raised again at that time.


> I bel= ieve that in the New Year the chairs and area directors will need to decide= how to proceed on this issue.  (The working group consensus, as I see= it, is already both well-informed and clear on this point, but I understan= d that that's not the only consideration.)  It would be good to see th= e spec finished shortly.
> ...

Best regards, Julian


_______________________________________________
OAuth mailing list<= br>OAuth@ietf.org
https://www.ietf.org/m= ailman/listinfo/oauth


--258328648-620139665-1325619340=:463-- From wmills@yahoo-inc.com Tue Jan 3 11:44:48 2012 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 2355B11E80E3 for ; Tue, 3 Jan 2012 11:44:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.437 X-Spam-Level: X-Spam-Status: No, score=-16.437 tagged_above=-999 required=5 tests=[AWL=1.161, 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 JlJoCdgqCOg9 for ; Tue, 3 Jan 2012 11:44:46 -0800 (PST) Received: from nm30.bullet.mail.ac4.yahoo.com (nm30.bullet.mail.ac4.yahoo.com [98.139.52.227]) by ietfa.amsl.com (Postfix) with SMTP id 977DA11E80E1 for ; Tue, 3 Jan 2012 11:44:45 -0800 (PST) Received: from [98.139.52.196] by nm30.bullet.mail.ac4.yahoo.com with NNFMP; 03 Jan 2012 19:44:40 -0000 Received: from [98.139.52.143] by tm9.bullet.mail.ac4.yahoo.com with NNFMP; 03 Jan 2012 19:44:40 -0000 Received: from [127.0.0.1] by omp1026.mail.ac4.yahoo.com with NNFMP; 03 Jan 2012 19:44:40 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 52605.71072.bm@omp1026.mail.ac4.yahoo.com Received: (qmail 47976 invoked by uid 60001); 3 Jan 2012 19:44:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1325619879; bh=t6+dRNPIJTXqW4c3P8lA6UeuRiAtUnIaILIXRe555ik=; 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=lc+0P39tw/G4zXx8y2T5iZ4v0rPlJv87m48UyfALXrVruP3lrs/+xr1HQS7+qUGocSsw8BYdf0EgW1urf6jQeQghieTjIYDIrBd4BrFVMjaQlKL7u7QcA4l68KfUMo1k/WtJisSWTzW7VSLKYuGV5Orr+WDjXfVx71LtkxvBD6Q= 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=VTUm2VtmZDQVZQlVYMdcv/xmvfd53dbWNwve7NLfEfaccPy9Pxnv1hilpK/OHIiRorPaWKim4hRxBXcUs5Ye5dJhLFnoVwJqxBqEWDJNTttbh9CaBQyUS7zwXmOmKU+nUOTgHhsB6H8QAQ6aphVx012nkd8qmLarQ+MAl0I82yY=; X-YMail-OSG: 0p_WMWcVM1lgxegCDGaBR7l5Q7pDXs8V9lhlU3qQh5gAcSV 7D0KHvrUTe36JI2sN5Tb7kkz3rTyDmEk6oinQScTNWjTjzaZjm5KD7toqrV7 QgaYiqTk9cmk9PvjZwNSzrHGbTMA_kzmvcY6lD9zBMyJgwvBb3Wu377OWVcK zAgwyzk_yh9htC2aNdj79Esg64FD8l4vT_eLc1TPQikRylwAJNPBsq4dqQdp xp7pWwvRsShPqhauYQNLvLZbn_jDveho.TRafcZ6K8r7yH3OHRkcaJAdl3iE Squs2S5V2MJqYfX8.nMvOcwANB2KImYc850SkhWs7YoPpkuB4IAepZXXkhpl bOTZ5Ki3rGPSmM7mMuUHNDg84I8BD1nEGPU4DsDSwqzWngtf1gY0_iPJOspl 8XiLsd8kPyj_.Iu0efsERu5T7AHlSzTwRBA-- Received: from [209.131.62.115] by web31813.mail.mud.yahoo.com via HTTP; Tue, 03 Jan 2012 11:44:39 PST X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.116.331537 References: <4E1F6AAD24975D4BA5B16804296739435F763122@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739435F772D1D@TK5EX14MBXC283.redmond.corp.microsoft.com> <4EEF13F1.7030409@gmx.de> <4E1F6AAD24975D4BA5B16804296739435F78F5BB@TK5EX14MBXC283.redmond.corp.microsoft.com> <4EFD91B4.5050904@gmx.de> <4E1F6AAD24975D4BA5B16804296739435F790386@TK5EX14MBXC283.redmond.corp.microsoft.com> <1325619340.463.YahooMailNeo@web31808.mail.mud.yahoo.com> Message-ID: <1325619879.36939.YahooMailNeo@web31813.mail.mud.yahoo.com> Date: Tue, 3 Jan 2012 11:44:39 -0800 (PST) From: William Mills To: William Mills , Mike Jones , Julian Reschke In-Reply-To: <1325619340.463.YahooMailNeo@web31808.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="767760015-608514281-1325619879=:36939" Cc: Mark Nottingham , Barry Leiba , OAuth WG Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft 15? 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, 03 Jan 2012 19:44:48 -0000 --767760015-608514281-1325619879=:36939 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable By "parameter syntax" I mean the syntax of the Authentication HTTP header.= =0A=0A=0A=0A________________________________=0A From: William Mills =0ATo: Mike Jones ; Julian Resc= hke =0ACc: Mark Nottingham ; Barry L= eiba ; OAuth WG =0ASent: Tuesday,= January 3, 2012 11:35 AM=0ASubject: Re: [OAUTH-WG] auth-param syntax, was:= OK to post OAuth Bearer draft 15?=0A =0A=0AIs all this only around the sc= ope parameter?=A0 My mail cited below is with regards to the character set = for a valid scope parameter, which we should be able to define and then lea= n on the HTTPbis spec for the actual parameter syntax.=0A=0A=0A=0A_________= _______________________=0A From: Mike Jones = =0ATo: Julian Reschke =0ACc: Mark Nottingham ; Barry Leiba ; OAuth WG = =0ASent: Friday, December 30, 2011 3:19 PM=0ASubject: Re: [OAUTH-WG] auth-= param syntax, was: OK to post OAuth Bearer draft 15?=0A =0AI did already b= ack the statement that this is the working group consensus with the e-mails= attached in this note sent to you on December 12, 2011:=0A=A0 - http://www= .ietf.org/mail-archive/web/oauth/current/msg08042.html=0A=0ABut since that = apparently wasn't convincing to you that this working group decision repres= ents more than "just me disagreeing with you", here are references to indiv= idual messages referenced in the above e-mail:=0A=A0 - Eran Hammer-Lahav: h= ttp://www.ietf.org/mail-archive/web/oauth/current/msg07698.html=0A=A0 - Joh= n Bradley:=A0 http://www.ietf.org/mail-archive/web/oauth/current/msg07699.h= tml=0A=A0 - William Mills:=A0 http://www.ietf.org/mail-archive/web/oauth/cu= rrent/msg07700.html=0A=A0 - Mike Jones:=A0 http://www.ietf.org/mail-archive= /web/oauth/current/msg07701.html=0A=A0 - Phil Hunt:=A0 http://www.ietf.org/= mail-archive/web/oauth/current/msg07702.html=0A=A0 - Justin Richer:=A0=0A h= ttp://www.ietf.org/mail-archive/web/oauth/current/msg07692.html=0A=0AAs for= your assertion that the specs are in conflict, yes, the Bearer spec includ= es a different decision than a RECOMMENDED clause in the HTTPbis spec (whic= h was added after the Bearer text was already in place).=A0 However, it is = not violating any MUST clauses in the HTTPbis spec.=A0 Given that no MUSTS = are violated, I don't see it mandatory for this tension to be resolved in f= avor of one spec or the other in order for both to be approved as RFCs.=A0 = I look forward to seeing that happen soon in both cases (and for the OAuth = core spec as well).=0A=0A=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 Best wishe= s,=0A=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 -- Mike=0A=0A-----Original Mes= sage-----=0AFrom: Julian Reschke [mailto:julian.reschke@gmx.de] =0ASent: Fr= iday, December 30, 2011 2:26 AM=0ATo: Mike Jones=0ACc: Barry Leiba; Mark No= ttingham; OAuth WG=0ASubject: Re: auth-param syntax, was: [OAUTH-WG] OK to = post OAuth Bearer draft 15?=0A=0AOn 2011-12-29 22:18, Mike Jones wrote:=0A>= You proposed, Julian "3. Do not specify the ABNF. The ABNF of the WWW-Auth= enticate is defined in HTTPbis. Just state the names of the parameters, the= ir syntax *after* parsing and their semantics."=0A>=0A> About some of Mark = Nottingham's comments, Barry wrote "Let me point out that "this represents = working-group consensus" is not always a valid response.=A0 If the working = group has actually considered the *issue*, that might be OK.=A0 But if ther= e's consensus for the chosen solution and someone brings up a *new* issue w= ith it, that issue needs to be addressed anew."=0A>=0A> Relative to these t= wo statements, I believe that I=0A should remark at this point that your pr= oposed semantics of only considering the syntax after potential quoting was= explicitly considered earlier by the working group and rejected.=A0 The co= nsensus, instead, was for the present "no quoting will occur for legal inpu= ts" semantics.=0A=0AIt would be helpful if you could back this statement wi= th pointers to mails. As far as I can tell it's just you disagreeing with m= e.=0A=0ABack to the facts:=0A=0Aa) the bearer spec defines an HTTP authenti= cation scheme, and normatively refers to HTTPbis Part7 for that=0A=0Ab) HTT= Pbis recommends new scheme definitions not to have their own ABNF, as the h= eader field syntax is defined by HTTPbis, not the individual scheme=0A=0Ac)= the bearer spec defines it's own ABNF nevertheless=0A=0ASo the two specs a= re in conflict, and we should resolve the conflict one way or the other.=0A= =0AIf you disagree with the recommendation in HTTPbis, then you really real= ly should=0A come over to HTTPbis WG and argue your point of view.=0A=0AIf = you agree with it, but think that the bearer spec can't follow the recommen= dation, then it would be good to explain the reasoning (optimally in the sp= ec).=0A=0AIf you agree with it, and think the bearer spec *could* follow it= , then... change it, by all means.=0A=0AAnyway, if this issue isn't resolve= d before IETF LC then it will be raised again at that time.=0A=0A=0A> I bel= ieve that in the New Year the chairs and area directors will need to decide= how to proceed on this issue.=A0 (The working group consensus, as I see it= , is already both well-informed and clear on this point, but I understand t= hat that's not the only consideration.)=A0 It would be good to see the spec= finished shortly.=0A> ...=0A=0ABest regards, Julian=0A=0A=0A=0A___________= ____________________________________=0AOAuth mailing list=0AOAuth@ietf.org= =0Ahttps://www.ietf.org/mailman/listinfo/oauth=0A=0A=0A=0A_________________= ______________________________=0AOAuth mailing list=0AOAuth@ietf.org=0Ahttp= s://www.ietf.org/mailman/listinfo/oauth --767760015-608514281-1325619879=:36939 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
By "parameter syntax" I mean the syntax of the Authentication HTTP header= .

From: William Mills <wmills@yahoo-inc.com>
= To: Mike Jones <Michael.Jo= nes@microsoft.com>; Julian Reschke <julian.reschke@gmx.de>
= Cc: Mark Nottingham <mnot@= mnot.net>; Barry Leiba <barryleiba@computer.org>; OAuth WG <oau= th@ietf.org>
Sent:= Tuesday, January 3, 2012 11:35 AM
Subject= : Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Beare= r draft 15?

=0A
Is all this only around = the scope parameter?  My mail cited below is with regards to the chara= cter set for a valid scope parameter, which we should be able to define and= then lean on the HTTPbis spec for the actual parameter syntax.
<= /div>

From: Mike Jones <Michael.Jones@microsoft.com>
To: Julian Reschke <julian.reschke@gmx.de&= gt;
Cc: Mark Nottingham= <mnot@mnot.net>; Barry Leiba=0A <barryleiba@computer.org>; OAu= th WG <oauth@ietf.org>
Sent= : Friday, December 30, 2011 3:19 PM
Subject: Re: [OAUTH-WG] auth-param syntax, was: OK= to post OAuth Bearer draft 15?
=0AI did already back the s= tatement that this is the working group consensus with the e-mails attached= in this note sent to you on December 12, 2011:
  - http://www.ietf= .org/mail-archive/web/oauth/current/msg08042.html

But since that app= arently wasn't convincing to you that this working group decision represent= s more than "just me disagreeing with you", here are references to individu= al messages referenced in the above e-mail:
  - Eran Hammer-Lahav: = http://www.ietf.org/mail-archive/web/oauth/current/msg07698.html
  = - John Bradley:  http://www.ietf.org/mail-archive/web/oauth/current/ms= g07699.html
  - William Mills:  http://www.ietf.org/mail-archi= ve/web/oauth/current/msg07700.html
  - Mike Jones:  http://www= .ietf.org/mail-archive/web/oauth/current/msg07701.html
  - Phil Hun= t:  http://www.ietf.org/mail-archive/web/oauth/current/msg07702.html  - Justin Richer: =0A http://www.ietf.org/mail-archive/web/oau= th/current/msg07692.html

As for your assertion that the specs are in= conflict, yes, the Bearer spec includes a different decision than a RECOMM= ENDED clause in the HTTPbis spec (which was added after the Bearer text was= already in place).  However, it is not violating any MUST clauses in = the HTTPbis spec.  Given that no MUSTS are violated, I don't see it ma= ndatory for this tension to be resolved in favor of one spec or the other i= n order for both to be approved as RFCs.  I look forward to seeing tha= t happen soon in both cases (and for the OAuth core spec as well).

&= nbsp;               = Best wishes,
            &n= bsp;   -- Mike

-----Original Message-----
From: Julian = Reschke [mailto:julian.reschke@gmx.de]
Sent:= Friday, December 30, 2011 2:26 AM
To: Mike Jones
Cc: Barry Leiba; Ma= rk Nottingham; OAuth WG
Subject: Re: auth-param syntax, was: [OAUTH-WG] = OK to post OAuth Bearer draft 15?

On 2011-12-29 22:18, Mike Jones wr= ote:
> You proposed, Julian "3. Do not specify the ABNF. The ABNF of = the WWW-Authenticate is defined in HTTPbis. Just state the names of the par= ameters, their syntax *after* parsing and their semantics."
>
>= About some of Mark Nottingham's comments, Barry wrote "Let me point out th= at "this represents working-group consensus" is not always a valid response= .  If the working group has actually considered the *issue*, that migh= t be OK.  But if there's consensus for the chosen solution and someone= brings up a *new* issue with it, that issue needs to be addressed anew.">
> Relative to these two statements, I believe that I=0A should= remark at this point that your proposed semantics of only considering the = syntax after potential quoting was explicitly considered earlier by the wor= king group and rejected.  The consensus, instead, was for the present = "no quoting will occur for legal inputs" semantics.

It would be help= ful if you could back this statement with pointers to mails. As far as I ca= n tell it's just you disagreeing with me.

Back to the facts:

= a) the bearer spec defines an HTTP authentication scheme, and normatively r= efers to HTTPbis Part7 for that

b) HTTPbis recommends new scheme def= initions not to have their own ABNF, as the header field syntax is defined = by HTTPbis, not the individual scheme

c) the bearer spec defines it'= s own ABNF nevertheless

So the two specs are in conflict, and we sho= uld resolve the conflict one way or the other.

If you disagree with = the recommendation in HTTPbis, then you really really should=0A come over t= o HTTPbis WG and argue your point of view.

If you agree with it, but= think that the bearer spec can't follow the recommendation, then it would = be good to explain the reasoning (optimally in the spec).

If you agr= ee with it, and think the bearer spec *could* follow it, then... change it,= by all means.

Anyway, if this issue isn't resolved before IETF LC t= hen it will be raised again at that time.


> I believe that in= the New Year the chairs and area directors will need to decide how to proc= eed on this issue.  (The working group consensus, as I see it, is alre= ady both well-informed and clear on this point, but I understand that that'= s not the only consideration.)  It would be good to see the spec finis= hed shortly.
> ...

Best regards, Julian



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



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


--767760015-608514281-1325619879=:36939-- From Michael.Jones@microsoft.com Tue Jan 3 11:46:57 2012 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 1F1C111E80EC for ; Tue, 3 Jan 2012 11:46:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.508 X-Spam-Level: X-Spam-Status: No, score=-3.508 tagged_above=-999 required=5 tests=[AWL=0.090, 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 sPpalduZmeNd for ; Tue, 3 Jan 2012 11:46:55 -0800 (PST) Received: from AM1EHSOBE004.bigfish.com (am1ehsobe004.messaging.microsoft.com [213.199.154.207]) by ietfa.amsl.com (Postfix) with ESMTP id 0E70B11E80E8 for ; Tue, 3 Jan 2012 11:46:55 -0800 (PST) Received: from mail39-am1-R.bigfish.com (10.3.201.244) by AM1EHSOBE004.bigfish.com (10.3.204.24) with Microsoft SMTP Server id 14.1.225.23; Tue, 3 Jan 2012 19:46:54 +0000 Received: from mail39-am1 (localhost [127.0.0.1]) by mail39-am1-R.bigfish.com (Postfix) with ESMTP id 4A63C28013C; Tue, 3 Jan 2012 19:46:54 +0000 (UTC) X-SpamScore: -48 X-BigFish: VS-48(zz9371I1415J2174M936eKc85fh146fK542M1432N98dKzz1202hzz8275ch1033IL8275bh8275dhz2fh2a8h668h839h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC106.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail39-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC106.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail39-am1 (localhost.localdomain [127.0.0.1]) by mail39-am1 (MessageSwitch) id 1325620013828350_6828; Tue, 3 Jan 2012 19:46:53 +0000 (UTC) Received: from AM1EHSMHS001.bigfish.com (unknown [10.3.201.247]) by mail39-am1.bigfish.com (Postfix) with ESMTP id B9CDD3A00DF; Tue, 3 Jan 2012 19:46:53 +0000 (UTC) Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS001.bigfish.com (10.3.207.101) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 3 Jan 2012 19:46:52 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.84]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.02.0247.005; Tue, 3 Jan 2012 11:46:37 -0800 From: Mike Jones To: William Mills , Julian Reschke Thread-Topic: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft 15? Thread-Index: AQHMyk7k0nsxP6uHFU2ycTUC8uzaDZX7CnqQ Date: Tue, 3 Jan 2012 19:46:37 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739435F7936E7@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739435F763122@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739435F772D1D@TK5EX14MBXC283.redmond.corp.microsoft.com> <4EEF13F1.7030409@gmx.de> <4E1F6AAD24975D4BA5B16804296739435F78F5BB@TK5EX14MBXC283.redmond.corp.microsoft.com> <4EFD91B4.5050904@gmx.de> <4E1F6AAD24975D4BA5B16804296739435F790386@TK5EX14MBXC283.redmond.corp.microsoft.com> <1325619340.463.YahooMailNeo@web31808.mail.mud.yahoo.com> In-Reply-To: <1325619340.463.YahooMailNeo@web31808.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_4E1F6AAD24975D4BA5B16804296739435F7936E7TK5EX14MBXC283r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: Mark Nottingham , Barry Leiba , OAuth WG Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft 15? 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, 03 Jan 2012 19:46:57 -0000 --_000_4E1F6AAD24975D4BA5B16804296739435F7936E7TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is about the syntax for the scope, error, and error_description parame= ters. The pertinent text from Section 3 is: Producers of "scope" strings MUST NOT use characters outside the set %x21 / %x23-5B / %x5D-7E for representing the scope values and %x20 for the delimiter. Producers of "error" and "error_description" strings MUST NOT use characters outside the set %x20-21 / %x23-5B / %x5D-7E for representing these values. Producers of "error-uri" strings MUST NOT use characters outside the set %x21 / %x23-5B / %x5D-7E for representing these values. Furthermore, "error-uri" strings MUST conform to the URI-Reference syntax. In all these cases, no character quoting will occur, as senders are prohibited from using the %5C ('\') character. Cheers, -- Mike From: William Mills [mailto:wmills@yahoo-inc.com] Sent: Tuesday, January 03, 2012 11:36 AM To: Mike Jones; Julian Reschke Cc: Mark Nottingham; Barry Leiba; OAuth WG Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer dra= ft 15? Is all this only around the scope parameter? My mail cited below is with r= egards to the character set for a valid scope parameter, which we should be= able to define and then lean on the HTTPbis spec for the actual parameter = syntax. ________________________________ From: Mike Jones > To: Julian Reschke > Cc: Mark Nottingham >; Barry Leiba >; OAuth WG > Sent: Friday, December 30, 2011 3:19 PM Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer dra= ft 15? I did already back the statement that this is the working group consensus w= ith the e-mails attached in this note sent to you on December 12, 2011: - http://www.ietf.org/mail-archive/web/oauth/current/msg08042.html But since that apparently wasn't convincing to you that this working group = decision represents more than "just me disagreeing with you", here are refe= rences to individual messages referenced in the above e-mail: - Eran Hammer-Lahav: http://www.ietf.org/mail-archive/web/oauth/current/m= sg07698.html - John Bradley: http://www.ietf.org/mail-archive/web/oauth/current/msg07= 699.html - William Mills: http://www.ietf.org/mail-archive/web/oauth/current/msg0= 7700.html - Mike Jones: http://www.ietf.org/mail-archive/web/oauth/current/msg0770= 1.html - Phil Hunt: http://www.ietf.org/mail-archive/web/oauth/current/msg07702= .html - Justin Richer: http://www.ietf.org/mail-archive/web/oauth/current/msg0= 7692.html As for your assertion that the specs are in conflict, yes, the Bearer spec = includes a different decision than a RECOMMENDED clause in the HTTPbis spec= (which was added after the Bearer text was already in place). However, it= is not violating any MUST clauses in the HTTPbis spec. Given that no MUST= S are violated, I don't see it mandatory for this tension to be resolved in= favor of one spec or the other in order for both to be approved as RFCs. = I look forward to seeing that happen soon in both cases (and for the OAuth = core spec as well). Best wishes, -- Mike -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Friday, December 30, 2011 2:26 AM To: Mike Jones Cc: Barry Leiba; Mark Nottingham; OAuth WG Subject: Re: auth-param syntax, was: [OAUTH-WG] OK to post OAuth Bearer dra= ft 15? On 2011-12-29 22:18, Mike Jones wrote: > You proposed, Julian "3. Do not specify the ABNF. The ABNF of the WWW-Aut= henticate is defined in HTTPbis. Just state the names of the parameters, th= eir syntax *after* parsing and their semantics." > > About some of Mark Nottingham's comments, Barry wrote "Let me point out t= hat "this represents working-group consensus" is not always a valid respons= e. If the working group has actually considered the *issue*, that might be= OK. But if there's consensus for the chosen solution and someone brings u= p a *new* issue with it, that issue needs to be addressed anew." > > Relative to these two statements, I believe that I should remark at this = point that your proposed semantics of only considering the syntax after pot= ential quoting was explicitly considered earlier by the working group and r= ejected. The consensus, instead, was for the present "no quoting will occu= r for legal inputs" semantics. It would be helpful if you could back this statement with pointers to mails= . As far as I can tell it's just you disagreeing with me. Back to the facts: a) the bearer spec defines an HTTP authentication scheme, and normatively r= efers to HTTPbis Part7 for that b) HTTPbis recommends new scheme definitions not to have their own ABNF, as= the header field syntax is defined by HTTPbis, not the individual scheme c) the bearer spec defines it's own ABNF nevertheless So the two specs are in conflict, and we should resolve the conflict one wa= y or the other. If you disagree with the recommendation in HTTPbis, then you really really = should come over to HTTPbis WG and argue your point of view. If you agree with it, but think that the bearer spec can't follow the recom= mendation, then it would be good to explain the reasoning (optimally in the= spec). If you agree with it, and think the bearer spec *could* follow it, then... = change it, by all means. Anyway, if this issue isn't resolved before IETF LC then it will be raised = again at that time. > I believe that in the New Year the chairs and area directors will need to= decide how to proceed on this issue. (The working group consensus, as I s= ee it, is already both well-informed and clear on this point, but I underst= and that that's not the only consideration.) It would be good to see the s= pec finished shortly. > ... Best regards, Julian _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_4E1F6AAD24975D4BA5B16804296739435F7936E7TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is about the syntax = for the scope, error, and error_description parameters.  The pertinent= text from Section 3 is:

 <= /p>

  = ; Producers of "scope" strings MUST NOT use characters outside th= e set

  = ; %x21 / %x23-5B / %x5D-7E for representing the scope values and %x20<= /o:p>

  = ; for the delimiter.  Producers of "error" and "error_d= escription"

  = ; strings MUST NOT use characters outside the set %x20-21 / %x23-5B /<= /o:p>

  = ; %x5D-7E for representing these values.  Producers of "error-uri= "

  = ; strings MUST NOT use characters outside the set %x21 / %x23-5B /

  = ; %x5D-7E for representing these values.  Furthermore, "error-uri= "

  = ; strings MUST conform to the URI-Reference syntax.  In all these=

  = ; cases, no character quoting will occur, as senders are prohibited

  = ; from using the %5C ('\') character.

 <= /p>

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;     Cheers,

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

 <= /p>

From: William = Mills [mailto:wmills@yahoo-inc.com]
Sent: Tuesday, January 03, 2012 11:36 AM
To: Mike Jones; Julian Reschke
Cc: Mark Nottingham; Barry Leiba; OAuth WG
Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bea= rer draft 15?

 

Is all this only ar= ound the scope parameter?  My mail cited below is with regards to the = character set for a valid scope parameter, which we should be able to define and then lean on the HTTPbis spec for the actual paramet= er syntax.

 

<= span style=3D"font-size:10.0pt;font-family:"Arial","sans-ser= if";color:black">From: Mike Jones &l= t;Michael.Jones@microsoft.co= m>
To: Julian Reschke <juli= an.reschke@gmx.de>
Cc: Mark Nottingham <mnot@mnot.n= et>; Barry Leiba <barr= yleiba@computer.org>; OAuth WG <oauth@ietf.org>
Sent: Friday, December 30, 2011 3:19 PM
Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bea= rer draft 15?

I did already back the statement that this is the working group consensus w= ith the e-mails attached in this note sent to you on December 12, 2011:
  - http://www.ietf.org/mail-archive/web/oauth/current/msg08042.html=

But since that apparently wasn't convincing to you that this working group = decision represents more than "just me disagreeing with you", her= e are references to individual messages referenced in the above e-mail:
  - Eran Hammer-Lahav: http://www.ietf.org/mail-archive/web/oauth/current/msg07698.html
  - John Bradley:  http://www.ietf.org/mail-archive/web/oauth/current/msg07699.html
  - William Mills:  http://www.ietf.org/mail-archive/web/oauth/current/msg07700.html
  - Mike Jones:  http://www.ietf.org/mail-archive/web/oauth/current/msg07701.html
  - Phil Hunt:  http://www.ietf.org/mail-archive/web/oauth/current/msg07702.html
  - Justin Richer:  http://www.ietf.org/mail-archive/web/oauth/current/msg07692.html

As for your assertion that the specs are in conflict, yes, the Bearer spec = includes a different decision than a RECOMMENDED clause in the HTTPbis spec= (which was added after the Bearer text was already in place).  Howeve= r, it is not violating any MUST clauses in the HTTPbis spec.  Given that no MUSTS are violated, I don't see i= t mandatory for this tension to be resolved in favor of one spec or the oth= er in order for both to be approved as RFCs.  I look forward to seeing= that happen soon in both cases (and for the OAuth core spec as well).

               = Best wishes,
               = -- Mike

-----Original Message-----
From: Julian Reschke [mailto:julia= n.reschke@gmx.de]
Sent: Friday, December 30, 2011 2:26 AM
To: Mike Jones
Cc: Barry Leiba; Mark Nottingham; OAuth WG
Subject: Re: auth-param syntax, was: [OAUTH-WG] OK to post OAuth Bearer dra= ft 15?

On 2011-12-29 22:18, Mike Jones wrote:
> You proposed, Julian "3. Do not specify the ABNF. The ABNF of the= WWW-Authenticate is defined in HTTPbis. Just state the names of the parame= ters, their syntax *after* parsing and their semantics."
>
> About some of Mark Nottingham's comments, Barry wrote "Let me poi= nt out that "this represents working-group consensus" is not alwa= ys a valid response.  If the working group has actually considered the= *issue*, that might be OK.  But if there's consensus for the chosen solution and someone brings up a *new* issue with it, that issu= e needs to be addressed anew."
>
> Relative to these two statements, I believe that I should remark at th= is point that your proposed semantics of only considering the syntax after = potential quoting was explicitly considered earlier by the working group an= d rejected.  The consensus, instead, was for the present "no quoting will occur for legal inputs" sem= antics.

It would be helpful if you could back this statement with pointers to mails= . As far as I can tell it's just you disagreeing with me.

Back to the facts:

a) the bearer spec defines an HTTP authentication scheme, and normatively r= efers to HTTPbis Part7 for that

b) HTTPbis recommends new scheme definitions not to have their own ABNF, as= the header field syntax is defined by HTTPbis, not the individual scheme
c) the bearer spec defines it's own ABNF nevertheless

So the two specs are in conflict, and we should resolve the conflict one wa= y or the other.

If you disagree with the recommendation in HTTPbis, then you really really = should come over to HTTPbis WG and argue your point of view.

If you agree with it, but think that the bearer spec can't follow the recom= mendation, then it would be good to explain the reasoning (optimally in the= spec).

If you agree with it, and think the bearer spec *could* follow it, then... = change it, by all means.

Anyway, if this issue isn't resolved before IETF LC then it will be raised = again at that time.


> I believe that in the New Year the chairs and area directors will need= to decide how to proceed on this issue.  (The working group consensus= , as I see it, is already both well-informed and clear on this point, but I= understand that that's not the only consideration.)  It would be good to see the spec finished shortly.
> ...

Best regards, Julian



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

--_000_4E1F6AAD24975D4BA5B16804296739435F7936E7TK5EX14MBXC283r_-- From wmills@yahoo-inc.com Tue Jan 3 11:59:40 2012 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 2ADAE1F0C3F for ; Tue, 3 Jan 2012 11:59:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.669 X-Spam-Level: X-Spam-Status: No, score=-16.669 tagged_above=-999 required=5 tests=[AWL=0.929, 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 Y4FiDoUVrRFV for ; Tue, 3 Jan 2012 11:59:38 -0800 (PST) Received: from nm28-vm0.bullet.mail.sp2.yahoo.com (nm28-vm0.bullet.mail.sp2.yahoo.com [98.139.91.234]) by ietfa.amsl.com (Postfix) with SMTP id C7F9C1F0C3B for ; Tue, 3 Jan 2012 11:59:38 -0800 (PST) Received: from [98.139.91.62] by nm28.bullet.mail.sp2.yahoo.com with NNFMP; 03 Jan 2012 19:59:33 -0000 Received: from [98.139.91.17] by tm2.bullet.mail.sp2.yahoo.com with NNFMP; 03 Jan 2012 19:59:33 -0000 Received: from [127.0.0.1] by omp1017.mail.sp2.yahoo.com with NNFMP; 03 Jan 2012 19:59:33 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 232693.71444.bm@omp1017.mail.sp2.yahoo.com Received: (qmail 51815 invoked by uid 60001); 3 Jan 2012 19:59:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1325620772; bh=dgPb6GxPqhMwFEy5DG1TyEbNhB8MXrOQWmzsCnhI/oI=; 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=HO0jhzrY01tn5xFqxnAyoOh7UTZrSfgLxiFWLytEynwCD46sUHn5bWaldSrr849SD7ZIfq/aRhhDBwpnjhn3uRAJbM3UE/F/+sv/mHxPlcuvRznngc9G81ATk+z2ZCFqI+n4LvrywiADa6rJEXUi5tqxyfz5/wstZWnX3BNXccY= 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=AkqosS62WN1//u8MAvVjUPg1hCkGoh5M+0DZCWF2YlXGf+A3jEjW4X8CF66HvPqTnIZl+Q42jajCaQXAt1mITP3E52NGtk5hDq2qbzZoYFVS025E3Fv7ph2ojQor5VNKy0hhOWj7pX1bO45hDi+zgpzrYpxy3kr+u59bvtSqWMM=; X-YMail-OSG: 9Wl1xysVM1nqIdMB2tZ9qJg_qEYC7mReSZv3xrJfIFP_XXf RyixBSwZrhDU8jU.7RFxslXPGjlslcnkOK9rMCaQlAKiGFnPXohjsT2Uwco1 AcjPwv4a3ss4FDILMemR0p12q_HFuU_k5I5450KWCS61lcP.LeGabcglryKk SSeEXGrsZFEs88hJobgivqKrU20vN0tG3iCkVTecsz64pyCoyrqGyZZT2w61 EF6Yl5EW5v0p1_Q1SC0aSuS2qyIJAKiME.qKT_s5cVd.W2GUZ6dFoPVcsJIA JVhfvKiN7GZISOYs3J6yB3imn51oasGr7v.Q9kQUy8EfXGq3M_i5owes41Hh 6yHSyI8CZuL_9q8qN1fF7wPpOo0B.uooVlT2aGCCRw7AX5BG.10Bls.pbsRt aedpiuvWoN.E9i_hmKo8iVwpZClAmDKyOEr8- Received: from [209.131.62.115] by web31802.mail.mud.yahoo.com via HTTP; Tue, 03 Jan 2012 11:59:32 PST X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.116.331537 References: <4E1F6AAD24975D4BA5B16804296739435F763122@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739435F772D1D@TK5EX14MBXC283.redmond.corp.microsoft.com> <4EEF13F1.7030409@gmx.de> <4E1F6AAD24975D4BA5B16804296739435F78F5BB@TK5EX14MBXC283.redmond.corp.microsoft.com> <4EFD91B4.5050904@gmx.de> <4E1F6AAD24975D4BA5B16804296739435F790386@TK5EX14MBXC283.redmond.corp.microsoft.com> <1325619340.463.YahooMailNeo@web31808.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B16804296739435F7936E7@TK5EX14MBXC283.redmond.corp.microsoft.com> Message-ID: <1325620772.48511.YahooMailNeo@web31802.mail.mud.yahoo.com> Date: Tue, 3 Jan 2012 11:59:32 -0800 (PST) From: William Mills To: Mike Jones , Julian Reschke In-Reply-To: <4E1F6AAD24975D4BA5B16804296739435F7936E7@TK5EX14MBXC283.redmond.corp.microsoft.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1036955950-954204332-1325620772=:48511" Cc: Mark Nottingham , Barry Leiba , OAuth WG Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft 15? 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, 03 Jan 2012 19:59:40 -0000 ---1036955950-954204332-1325620772=:48511 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Why is Bearer dealing with this at all?=A0 the BNF for that stuff should be= part of the core spec, and additional values perhaps defined in Bearer.=0A= =0A=0A=0A________________________________=0A From: Mike Jones =0ATo: William Mills ; Julian Reschke= =0ACc: Mark Nottingham ; Barry Leib= a ; OAuth WG =0ASent: Tuesday, Ja= nuary 3, 2012 11:46 AM=0ASubject: RE: [OAUTH-WG] auth-param syntax, was: O= K to post OAuth Bearer draft 15?=0A =0A=0A =0AThis is about the syntax for = the scope, error, and error_description parameters.=A0 The pertinent text f= rom Section 3 is:=0A=A0=0A=A0=A0 Producers of "scope" strings MUST NOT use = characters outside the set=0A=A0=A0 %x21 / %x23-5B / %x5D-7E for representi= ng the scope values and %x20=0A=A0=A0 for the delimiter.=A0 Producers of "e= rror" and "error_description"=0A=A0=A0 strings MUST NOT use characters outs= ide the set %x20-21 / %x23-5B /=0A=A0=A0 %x5D-7E for representing these val= ues.=A0 Producers of "error-uri"=0A=A0=A0 strings MUST NOT use characters o= utside the set %x21 / %x23-5B /=0A=A0=A0 %x5D-7E for representing these val= ues.=A0 Furthermore, "error-uri"=0A=A0=A0 strings MUST conform to the URI-R= eference syntax.=A0 In all these=0A=A0=A0 cases, no character quoting will = occur, as senders are prohibited=0A=A0=A0 from using the %5C ('\') characte= r.=0A=A0=0A=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 Cheers,=0A=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=0A=A0=0AFrom:William Mills [mailto:wmills@yahoo-inc.com] =0ASen= t: Tuesday, January 03, 2012 11:36 AM=0ATo: Mike Jones; Julian Reschke=0ACc= : Mark Nottingham; Barry Leiba; OAuth WG=0ASubject: Re: [OAUTH-WG] auth-par= am syntax, was: OK to post OAuth Bearer draft 15?=0A=A0=0AIs all this only = around the scope parameter?=A0 My mail cited below is with regards to the c= haracter set for a valid scope parameter, which we should be able to define= and then lean on the HTTPbis spec for the actual parameter syntax.=0A=A0= =0A=0A________________________________=0A =0AFrom:Mike Jones =0ATo: Julian Reschke =0ACc: Mark No= ttingham ; Barry Leiba ; OAuth WG <= oauth@ietf.org> =0ASent: Friday, December 30, 2011 3:19 PM=0ASubject: Re: [= OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft 15?=0A=0AI = did already back the statement that this is the working group consensus wit= h the e-mails attached in this note sent to you on December 12, 2011:=0A=A0= - http://www.ietf.org/mail-archive/web/oauth/current/msg08042.html=0A=0ABu= t since that apparently wasn't convincing to you that this working group de= cision represents more than "just me disagreeing with you", here are refere= nces to individual messages referenced in the above e-mail:=0A=A0 - Eran Ha= mmer-Lahav: http://www.ietf.org/mail-archive/web/oauth/current/msg07698.htm= l=0A=A0 - John Bradley:=A0 http://www.ietf.org/mail-archive/web/oauth/curre= nt/msg07699.html=0A=A0 - William Mills:=A0 http://www.ietf.org/mail-archive= /web/oauth/current/msg07700.html=0A=A0 - Mike Jones:=A0 http://www.ietf.org= /mail-archive/web/oauth/current/msg07701.html=0A=A0 - Phil Hunt:=A0 http://= www.ietf.org/mail-archive/web/oauth/current/msg07702.html=0A=A0 - Justin Ri= cher:=A0 http://www.ietf.org/mail-archive/web/oauth/current/msg07692.html= =0A=0AAs for your assertion that the specs are in conflict, yes, the Bearer= spec includes a different decision than a RECOMMENDED clause in the HTTPbi= s spec (which was added after the Bearer text was already in place).=A0 How= ever, it is not violating any MUST clauses=0A in the HTTPbis spec.=A0 Given= that no MUSTS are violated, I don't see it mandatory for this tension to b= e resolved in favor of one spec or the other in order for both to be approv= ed as RFCs.=A0 I look forward to seeing that happen soon in both cases (and= for the=0A OAuth core spec as well).=0A=0A=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 = =A0=A0=A0 Best wishes,=0A=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 -- Mike=0A= =0A-----Original Message-----=0AFrom: Julian Reschke [mailto:julian.reschke= @gmx.de] =0ASent: Friday, December 30, 2011 2:26 AM=0ATo: Mike Jones=0ACc: = Barry Leiba; Mark Nottingham; OAuth WG=0ASubject: Re: auth-param syntax, wa= s: [OAUTH-WG] OK to post OAuth Bearer draft 15?=0A=0AOn 2011-12-29 22:18, M= ike Jones wrote:=0A> You proposed, Julian "3. Do not specify the ABNF. The = ABNF of the WWW-Authenticate is defined in HTTPbis. Just state the names of= the parameters, their syntax *after* parsing and their semantics."=0A>=0A>= About some of Mark Nottingham's comments, Barry wrote "Let me point out th= at "this represents working-group consensus" is not always a valid response= .=A0 If the working group has actually considered the *issue*, that might b= e OK.=A0 But if there's consensus for=0A the chosen solution and someone br= ings up a *new* issue with it, that issue needs to be addressed anew."=0A>= =0A> Relative to these two statements, I believe that I should remark at th= is point that your proposed semantics of only considering the syntax after = potential quoting was explicitly considered earlier by the working group an= d rejected.=A0 The consensus, instead,=0A was for the present "no quoting w= ill occur for legal inputs" semantics.=0A=0AIt would be helpful if you coul= d back this statement with pointers to mails. As far as I can tell it's jus= t you disagreeing with me.=0A=0ABack to the facts:=0A=0Aa) the bearer spec = defines an HTTP authentication scheme, and normatively refers to HTTPbis Pa= rt7 for that=0A=0Ab) HTTPbis recommends new scheme definitions not to have = their own ABNF, as the header field syntax is defined by HTTPbis, not the i= ndividual scheme=0A=0Ac) the bearer spec defines it's own ABNF nevertheless= =0A=0ASo the two specs are in conflict, and we should resolve the conflict = one way or the other.=0A=0AIf you disagree with the recommendation in HTTPb= is, then you really really should come over to HTTPbis WG and argue your po= int of view.=0A=0AIf you agree with it, but think that the bearer spec can'= t follow the recommendation, then it would be good to explain the reasoning= (optimally in the spec).=0A=0AIf you agree with it, and think the bearer s= pec *could* follow it, then... change it, by all means.=0A=0AAnyway, if thi= s issue isn't resolved before IETF LC then it will be raised again at that = time.=0A=0A=0A> I believe that in the New Year the chairs and area director= s will need to decide how to proceed on this issue.=A0 (The working group c= onsensus, as I see it, is already both well-informed and clear on this poin= t, but I understand that that's not the only consideration.)=A0=0A It would= be good to see the spec finished shortly.=0A> ...=0A=0ABest regards, Julia= n=0A=0A=0A=0A_______________________________________________=0AOAuth mailin= g list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/oauth ---1036955950-954204332-1325620772=:48511 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Why is Bearer dealing with this at all?  the BNF for that stuff shou= ld be part of the core spec, and additional values perhaps defined in Beare= r.

From: Mike Jones <Michael.Jones@microsoft.com> To: William Mills <wm= ills@yahoo-inc.com>; Julian Reschke <julian.reschke@gmx.de>
Cc: Mark Nottingham <mnot= @mnot.net>; Barry Leiba <barryleiba@computer.org>; OAuth WG <oauth@ietf.org>
Sent: Tuesday, January 3, 2012 11:46 AM
Subject: RE: [OAUTH-WG] auth-param syntax, was: OK to= post OAuth Bearer draft 15?

=0A
= =0A=0A =0A =0A=0A=0A
=0A
=0A
This is about the syntax for the sc= ope, error, and error_description parameters.  The pertinent text from= =0ASection 3=0Ais:
= =0A
 
=0A
   Produc= ers of "scope" strings MUST NOT use characters outside the set
= =0A
   %x21 / %x23-5B / %x5D-7E for representi= ng the scope values and %x20
=0A
  = ; for the delimiter.  Producers of "error" and "error_description"
=0A
   strings MUST NOT use character= s outside the set %x20-21 / %x23-5B /
=0A
&n= bsp;  %x5D-7E for representing these values.  Producers of "error= -uri"
=0A
   strings MUST NOT use = characters outside the set %x21 / %x23-5B /
=0A
   %x5D-7E for representing these values.  Furthermore, = "error-uri"
=0A
   strings MUST co= nform to the URI-Reference syntax.  In all these
=0A
   cases, no character quoting will occur, as sende= rs are prohibited
=0A
   from usin= g the %5C ('\') character.
=0A
 
= =0A
          &n= bsp;            = ;            &n= bsp;            = ;            Cheers,=
=0A
        =             &nb= sp;            =             &nb= sp;            =   -- Mike
=0A
 
=0A
=0A=0A
From: William Mills = [mailto:wmills@yahoo-inc.com]=0A
=0ASent: Tuesday, January 03, 20= 12 11:36 AM
=0ATo: Mike Jones; Julian Reschke
=0ACc: Ma= rk Nottingham; Barry Leiba; OAuth WG
=0ASubject: Re: [OAUTH-WG] a= uth-param syntax, was: OK to post OAuth Bearer draft 15?
=0A=0A
=0A
 
=0A
= =0A
=0A
Is all this only around the = scope parameter?  My mail cited below is with regards to the character= set for a valid scope parameter, which we should=0A be able to define and = then lean on the HTTPbis spec for the actual parameter syntax.
= =0A
=0A
=0A
  =0A
=0A
=0A
=0A
=0A=0A
=0A
=0A
From: M= ike Jones <Michael= .Jones@microsoft.com>
=0ATo: Julian Reschke <julian.reschke@gmx.de>=0A
=0ACc: Mark Nottingham <mnot@mnot.net>= ;; Barry Leiba <barryleiba= @computer.org>; OAuth WG <oauth@ietf.= org>=0A
=0ASent: Friday, December 30, 2011 3:19 PM
=0A<= b>Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bear= er draft 15?
=0A
=0AI did already= back the statement that this is the working group consensus with the e-mai= ls attached in this note sent to you on December 12, 2011:
=0A  - h= ttp://www.ietf.org/mail-archive/web/oauth/current/msg08042.html
=0A
= =0ABut since that apparently wasn't convincing to you that this working gro= up decision represents more than "just me disagreeing with you", here are r= eferences to individual messages referenced in the above e-mail:
=0A&nbs= p; - Eran Hammer-Lahav: http://www.ietf.org/mail-archive/web/oauth/current/= msg07698.html
=0A  - John Bradley:  http://www.ietf.org/mail-a= rchive/web/oauth/current/msg07699.html
=0A  - William Mills:  = http://www.ietf.org/mail-archive/web/oauth/current/msg07700.html
=0A&nbs= p; - Mike Jones:  http://www.ietf.org/mail-archive/web/oauth/current/m= sg07701.html
=0A  - Phil Hunt:  http://www.ietf.org/mail-archi= ve/web/oauth/current/msg07702.html
=0A  - Justin Richer:  http= ://www.ietf.org/mail-archive/web/oauth/current/msg07692.html
=0A
=0AA= s for your assertion that the specs are in conflict, yes, the Bearer spec i= ncludes a different decision than a RECOMMENDED clause in the HTTPbis spec = (which was added after the Bearer text was already in place).  However= , it is not violating any MUST clauses=0A in the HTTPbis spec.  Given = that no MUSTS are violated, I don't see it mandatory for this tension to be= resolved in favor of one spec or the other in order for both to be approve= d as RFCs.  I look forward to seeing that happen soon in both cases (a= nd for the=0A OAuth core spec as well).
=0A
=0A    &nb= sp;           Best wishes,
=0A&n= bsp;               -= - Mike
=0A
=0A-----Original Message-----
=0AFrom: Julian Reschke [= mailto:julian.reschke@gmx.de= ]=0A
=0ASent: Friday, December 30, 2011 2:26 AM
=0ATo: Mike Jones
= =0ACc: Barry Leiba; Mark Nottingham; OAuth WG
=0ASubject: Re: auth-param= syntax, was: [OAUTH-WG] OK to post OAuth Bearer draft 15?
=0A
=0AOn = 2011-12-29 22:18, Mike Jones wrote:
=0A> You proposed, Julian "3. Do = not specify the ABNF. The ABNF of the WWW-Authenticate is defined in HTTPbi= s. Just state the names of the parameters, their syntax *after* parsing and= their semantics."
=0A>
=0A> About some of Mark Nottingham's co= mments, Barry wrote "Let me point out that "this represents working-group c= onsensus" is not always a valid response.  If the working group has ac= tually considered the *issue*, that might be OK.  But if there's conse= nsus for=0A the chosen solution and someone brings up a *new* issue with it= , that issue needs to be addressed anew."
=0A>
=0A> Relative to= these two statements, I believe that I should remark at this point that yo= ur proposed semantics of only considering the syntax after potential quotin= g was explicitly considered earlier by the working group and rejected. = ; The consensus, instead,=0A was for the present "no quoting will occur for= legal inputs" semantics.
=0A
=0AIt would be helpful if you could bac= k this statement with pointers to mails. As far as I can tell it's just you= disagreeing with me.
=0A
=0ABack to the facts:
=0A
=0Aa) the b= earer spec defines an HTTP authentication scheme, and normatively refers to= HTTPbis Part7 for that
=0A
=0Ab) HTTPbis recommends new scheme defin= itions not to have their own ABNF, as the header field syntax is defined by= HTTPbis, not the individual scheme
=0A
=0Ac) the bearer spec defines= it's own ABNF nevertheless
=0A
=0ASo the two specs are in conflict, = and we should resolve the conflict one way or the other.
=0A
=0AIf yo= u disagree with the recommendation in HTTPbis, then you really really shoul= d come over to HTTPbis WG and argue your point of view.
=0A
=0AIf you= agree with it, but think that the bearer spec can't follow the recommendat= ion, then it would be good to explain the reasoning (optimally in the spec)= .
=0A
=0AIf you agree with it, and think the bearer spec *could* foll= ow it, then... change it, by all means.
=0A
=0AAnyway, if this issue = isn't resolved before IETF LC then it will be raised again at that time.=0A
=0A
=0A> I believe that in the New Year the chairs and area d= irectors will need to decide how to proceed on this issue.  (The worki= ng group consensus, as I see it, is already both well-informed and clear on= this point, but I understand that that's not the only consideration.) = ;=0A It would be good to see the spec finished shortly.
=0A> ...
= =0A
=0ABest regards, Julian
=0A
=0A
=0A
=0A_________________= ______________________________
=0AOAuth mailing list
=0AOAuth@ietf.org
=0Ahttps://www.ietf.or= g/mailman/listinfo/oauth
=0A
=0A
=0A
=0A
= =0A
=0A
=0A
=0A=0A


---1036955950-954204332-1325620772=:48511-- From Michael.Jones@microsoft.com Tue Jan 3 12:01:01 2012 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 50B1011E80B4 for ; Tue, 3 Jan 2012 12:01:01 -0800 (PST) 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.082, 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 i5Nk3rtwm7PH for ; Tue, 3 Jan 2012 12:00:56 -0800 (PST) Received: from AM1EHSOBE004.bigfish.com (am1ehsobe004.messaging.microsoft.com [213.199.154.207]) by ietfa.amsl.com (Postfix) with ESMTP id BC68A1F0C5A for ; Tue, 3 Jan 2012 12:00:54 -0800 (PST) Received: from mail97-am1-R.bigfish.com (10.3.201.251) by AM1EHSOBE004.bigfish.com (10.3.204.24) with Microsoft SMTP Server id 14.1.225.23; Tue, 3 Jan 2012 20:00:54 +0000 Received: from mail97-am1 (localhost [127.0.0.1]) by mail97-am1-R.bigfish.com (Postfix) with ESMTP id 10EF550038A; Tue, 3 Jan 2012 20:00:54 +0000 (UTC) X-SpamScore: -48 X-BigFish: VS-48(zz9371I1415J2174M936eKc85fh146fK542M1432N98dKzz1202hzz8275ch1033IL8275bh8275dhz2fh2a8h668h839h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail97-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail97-am1 (localhost.localdomain [127.0.0.1]) by mail97-am1 (MessageSwitch) id 132562083542380_9957; Tue, 3 Jan 2012 20:00:35 +0000 (UTC) Received: from AM1EHSMHS015.bigfish.com (unknown [10.3.201.242]) by mail97-am1.bigfish.com (Postfix) with ESMTP id 04BC74E0050; Tue, 3 Jan 2012 20:00:35 +0000 (UTC) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS015.bigfish.com (10.3.207.153) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 3 Jan 2012 20:00:28 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.84]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.02.0247.005; Tue, 3 Jan 2012 12:00:27 -0800 From: Mike Jones To: William Mills , Julian Reschke Thread-Topic: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft 15? Thread-Index: AQHMyk7k0nsxP6uHFU2ycTUC8uzaDZX7CnqQgACLbwD//3oSIA== Date: Tue, 3 Jan 2012 20:00:26 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739435F79376F@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739435F763122@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739435F772D1D@TK5EX14MBXC283.redmond.corp.microsoft.com> <4EEF13F1.7030409@gmx.de> <4E1F6AAD24975D4BA5B16804296739435F78F5BB@TK5EX14MBXC283.redmond.corp.microsoft.com> <4EFD91B4.5050904@gmx.de> <4E1F6AAD24975D4BA5B16804296739435F790386@TK5EX14MBXC283.redmond.corp.microsoft.com> <1325619340.463.YahooMailNeo@web31808.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B16804296739435F7936E7@TK5EX14MBXC283.redmond.corp.microsoft.com> <1325620772.48511.YahooMailNeo@web31802.mail.mud.yahoo.com> In-Reply-To: <1325620772.48511.YahooMailNeo@web31802.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.79] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739435F79376FTK5EX14MBXC283r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: Mark Nottingham , Barry Leiba , OAuth WG Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft 15? 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, 03 Jan 2012 20:01:01 -0000 --_000_4E1F6AAD24975D4BA5B16804296739435F79376FTK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The core spec doesn't include these parameters. From: William Mills [mailto:wmills@yahoo-inc.com] Sent: Tuesday, January 03, 2012 12:00 PM To: Mike Jones; Julian Reschke Cc: Mark Nottingham; Barry Leiba; OAuth WG Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer dra= ft 15? Why is Bearer dealing with this at all? the BNF for that stuff should be p= art of the core spec, and additional values perhaps defined in Bearer. ________________________________ From: Mike Jones > To: William Mills >; Juli= an Reschke > Cc: Mark Nottingham >; Barry Leiba >; OAuth WG > Sent: Tuesday, January 3, 2012 11:46 AM Subject: RE: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer dra= ft 15? This is about the syntax for the scope, error, and error_description parame= ters. The pertinent text from Section 3 is: Producers of "scope" strings MUST NOT use characters outside the set %x21 / %x23-5B / %x5D-7E for representing the scope values and %x20 for the delimiter. Producers of "error" and "error_description" strings MUST NOT use characters outside the set %x20-21 / %x23-5B / %x5D-7E for representing these values. Producers of "error-uri" strings MUST NOT use characters outside the set %x21 / %x23-5B / %x5D-7E for representing these values. Furthermore, "error-uri" strings MUST conform to the URI-Reference syntax. In all these cases, no character quoting will occur, as senders are prohibited from using the %5C ('\') character. Cheers, -- Mike From: William Mills [mailto:wmills@yahoo-inc.com] Sent: Tuesday, January 03, 2012 11:36 AM To: Mike Jones; Julian Reschke Cc: Mark Nottingham; Barry Leiba; OAuth WG Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer dra= ft 15? Is all this only around the scope parameter? My mail cited below is with r= egards to the character set for a valid scope parameter, which we should be= able to define and then lean on the HTTPbis spec for the actual parameter = syntax. ________________________________ From: Mike Jones > To: Julian Reschke > Cc: Mark Nottingham >; Barry Leiba >; OAuth WG > Sent: Friday, December 30, 2011 3:19 PM Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer dra= ft 15? I did already back the statement that this is the working group consensus w= ith the e-mails attached in this note sent to you on December 12, 2011: - http://www.ietf.org/mail-archive/web/oauth/current/msg08042.html But since that apparently wasn't convincing to you that this working group = decision represents more than "just me disagreeing with you", here are refe= rences to individual messages referenced in the above e-mail: - Eran Hammer-Lahav: http://www.ietf.org/mail-archive/web/oauth/current/m= sg07698.html - John Bradley: http://www.ietf.org/mail-archive/web/oauth/current/msg07= 699.html - William Mills: http://www.ietf.org/mail-archive/web/oauth/current/msg0= 7700.html - Mike Jones: http://www.ietf.org/mail-archive/web/oauth/current/msg0770= 1.html - Phil Hunt: http://www.ietf.org/mail-archive/web/oauth/current/msg07702= .html - Justin Richer: http://www.ietf.org/mail-archive/web/oauth/current/msg0= 7692.html As for your assertion that the specs are in conflict, yes, the Bearer spec = includes a different decision than a RECOMMENDED clause in the HTTPbis spec= (which was added after the Bearer text was already in place). However, it= is not violating any MUST clauses in the HTTPbis spec. Given that no MUST= S are violated, I don't see it mandatory for this tension to be resolved in= favor of one spec or the other in order for both to be approved as RFCs. = I look forward to seeing that happen soon in both cases (and for the OAuth = core spec as well). Best wishes, -- Mike -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Friday, December 30, 2011 2:26 AM To: Mike Jones Cc: Barry Leiba; Mark Nottingham; OAuth WG Subject: Re: auth-param syntax, was: [OAUTH-WG] OK to post OAuth Bearer dra= ft 15? On 2011-12-29 22:18, Mike Jones wrote: > You proposed, Julian "3. Do not specify the ABNF. The ABNF of the WWW-Aut= henticate is defined in HTTPbis. Just state the names of the parameters, th= eir syntax *after* parsing and their semantics." > > About some of Mark Nottingham's comments, Barry wrote "Let me point out t= hat "this represents working-group consensus" is not always a valid respons= e. If the working group has actually considered the *issue*, that might be= OK. But if there's consensus for the chosen solution and someone brings u= p a *new* issue with it, that issue needs to be addressed anew." > > Relative to these two statements, I believe that I should remark at this = point that your proposed semantics of only considering the syntax after pot= ential quoting was explicitly considered earlier by the working group and r= ejected. The consensus, instead, was for the present "no quoting will occu= r for legal inputs" semantics. It would be helpful if you could back this statement with pointers to mails= . As far as I can tell it's just you disagreeing with me. Back to the facts: a) the bearer spec defines an HTTP authentication scheme, and normatively r= efers to HTTPbis Part7 for that b) HTTPbis recommends new scheme definitions not to have their own ABNF, as= the header field syntax is defined by HTTPbis, not the individual scheme c) the bearer spec defines it's own ABNF nevertheless So the two specs are in conflict, and we should resolve the conflict one wa= y or the other. If you disagree with the recommendation in HTTPbis, then you really really = should come over to HTTPbis WG and argue your point of view. If you agree with it, but think that the bearer spec can't follow the recom= mendation, then it would be good to explain the reasoning (optimally in the= spec). If you agree with it, and think the bearer spec *could* follow it, then... = change it, by all means. Anyway, if this issue isn't resolved before IETF LC then it will be raised = again at that time. > I believe that in the New Year the chairs and area directors will need to= decide how to proceed on this issue. (The working group consensus, as I s= ee it, is already both well-informed and clear on this point, but I underst= and that that's not the only consideration.) It would be good to see the s= pec finished shortly. > ... Best regards, Julian _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_4E1F6AAD24975D4BA5B16804296739435F79376FTK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The core spec doesn’= ;t include these parameters.

 <= /p>

From: William = Mills [mailto:wmills@yahoo-inc.com]
Sent: Tuesday, January 03, 2012 12:00 PM
To: Mike Jones; Julian Reschke
Cc: Mark Nottingham; Barry Leiba; OAuth WG
Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bea= rer draft 15?

 

Why is Bearer deali= ng with this at all?  the BNF for that stuff should be part of the cor= e spec, and additional values perhaps defined in Bearer.<= /p>

 

<= span style=3D"font-size:10.0pt;font-family:"Arial","sans-ser= if";color:black">From: Mike Jones &l= t;Michael.Jones@microsoft.co= m>
To: William Mills <wmills= @yahoo-inc.com>; Julian Reschke <julian.reschke@gmx.de>
Cc: Mark Nottingham <mnot@mnot.n= et>; Barry Leiba <barr= yleiba@computer.org>; OAuth WG <oauth@ietf.org>
Sent: Tuesday, January 3, 2012 11:46 AM
Subject: RE: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bea= rer draft 15?

This is about the syntax for the scope, error, and er= ror_description parameters.  The pertinent text from Section 3 is:

 <= /span>

   Producers of "scope&quo= t; strings MUST NOT use characters outside the set

   %x21 / %x23-5B / %x5D-7E for= representing the scope values and %x20<= o:p>

   for the delimiter.  Pro= ducers of "error" and "error_description"

   strings MUST NOT use charact= ers outside the set %x20-21 / %x23-5B /<= o:p>

   %x5D-7E for representing the= se values.  Producers of "error-uri"

   strings MUST NOT use charact= ers outside the set %x21 / %x23-5B /

   %x5D-7E for representing the= se values.  Furthermore, "error-uri"

   strings MUST conform to the = URI-Reference syntax.  In all these=

   cases, no character quoting = will occur, as senders are prohibited

   from using the %5C ('\') cha= racter.

 <= /span>

         = ;            &n= bsp;            = ;            &n= bsp;            = ; Cheers,

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

 <= /span>

From: William Mills [mailto:wmills@yahoo-inc.c= om]
Sent: Tuesday, January 03, 2012 11:36 AM
To: Mike Jones; Julian Reschke
Cc: Mark Nottingham; Barry Leiba; OAuth WG
Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bea= rer draft 15?

 

Is all this only around the scope parameter?  My m= ail cited below is with regards to the character set for a valid scope para= meter, which we should be able to define and then lean on the HTTPbis spec for the actual parameter syntax.

 

<= span style=3D"font-size:10.0pt;color:black">From: Mike Jones <Michael.Jones@microsoft.com>
To: Julian Reschke <julian.reschke@gmx.de>
Cc: Mark Nottingham <mnot@mnot.net>; Barry Leiba <barryleiba@computer.org>; OAuth WG &= lt;oauth@ietf.org&g= t;
Sent: Friday, December 30, 2011 3:19 PM
Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bea= rer draft 15?

I did already back the statement that this is the working group consensus w= ith the e-mails attached in this note sent to you on December 12, 2011:
  - http://www.ietf.org/mail-archive/web/oauth/current/msg08042.html=

But since that apparently wasn't convincing to you that this working group = decision represents more than "just me disagreeing with you", her= e are references to individual messages referenced in the above e-mail:
  - Eran Hammer-Lahav: http://www.ietf.org/mail-archive/web/oauth/current/msg07698.html
  - John Bradley:  http://www.ietf.org/mail-archive/web/oauth/current/msg07699.html
  - William Mills:  http://www.ietf.org/mail-archive/web/oauth/current/msg07700.html
  - Mike Jones:  http://www.ietf.org/mail-archive/web/oauth/current/msg07701.html
  - Phil Hunt:  http://www.ietf.org/mail-archive/web/oauth/current/msg07702.html
  - Justin Richer:  http://www.ietf.org/mail-archive/web/oauth/current/msg07692.html

As for your assertion that the specs are in conflict, yes, the Bearer spec = includes a different decision than a RECOMMENDED clause in the HTTPbis spec= (which was added after the Bearer text was already in place).  Howeve= r, it is not violating any MUST clauses in the HTTPbis spec.  Given that no MUSTS are violated, I don't see i= t mandatory for this tension to be resolved in favor of one spec or the oth= er in order for both to be approved as RFCs.  I look forward to seeing= that happen soon in both cases (and for the OAuth core spec as well).

               = Best wishes,
               = -- Mike

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]
Sent: Friday, December 30, 2011 2:26 AM
To: Mike Jones
Cc: Barry Leiba; Mark Nottingham; OAuth WG
Subject: Re: auth-param syntax, was: [OAUTH-WG] OK to post OAuth Bearer dra= ft 15?

On 2011-12-29 22:18, Mike Jones wrote:
> You proposed, Julian "3. Do not specify the ABNF. The ABNF of the= WWW-Authenticate is defined in HTTPbis. Just state the names of the parame= ters, their syntax *after* parsing and their semantics."
>
> About some of Mark Nottingham's comments, Barry wrote "Let me poi= nt out that "this represents working-group consensus" is not alwa= ys a valid response.  If the working group has actually considered the= *issue*, that might be OK.  But if there's consensus for the chosen solution and someone brings up a *new* issue with it, that issu= e needs to be addressed anew."
>
> Relative to these two statements, I believe that I should remark at th= is point that your proposed semantics of only considering the syntax after = potential quoting was explicitly considered earlier by the working group an= d rejected.  The consensus, instead, was for the present "no quoting will occur for legal inputs" sem= antics.

It would be helpful if you could back this statement with pointers to mails= . As far as I can tell it's just you disagreeing with me.

Back to the facts:

a) the bearer spec defines an HTTP authentication scheme, and normatively r= efers to HTTPbis Part7 for that

b) HTTPbis recommends new scheme definitions not to have their own ABNF, as= the header field syntax is defined by HTTPbis, not the individual scheme
c) the bearer spec defines it's own ABNF nevertheless

So the two specs are in conflict, and we should resolve the conflict one wa= y or the other.

If you disagree with the recommendation in HTTPbis, then you really really = should come over to HTTPbis WG and argue your point of view.

If you agree with it, but think that the bearer spec can't follow the recom= mendation, then it would be good to explain the reasoning (optimally in the= spec).

If you agree with it, and think the bearer spec *could* follow it, then... = change it, by all means.

Anyway, if this issue isn't resolved before IETF LC then it will be raised = again at that time.


> I believe that in the New Year the chairs and area directors will need= to decide how to proceed on this issue.  (The working group consensus= , as I see it, is already both well-informed and clear on this point, but I= understand that that's not the only consideration.)  It would be good to see the spec finished shortly.
> ...

Best regards, Julian



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

 

--_000_4E1F6AAD24975D4BA5B16804296739435F79376FTK5EX14MBXC283r_-- From wmills@yahoo-inc.com Tue Jan 3 12:13:51 2012 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 555D921F8574 for ; Tue, 3 Jan 2012 12:13:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.824 X-Spam-Level: X-Spam-Status: No, score=-16.824 tagged_above=-999 required=5 tests=[AWL=0.774, 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 Mpl+hJX81RKz for ; Tue, 3 Jan 2012 12:13:49 -0800 (PST) Received: from nm24-vm0.bullet.mail.sp2.yahoo.com (nm24-vm0.bullet.mail.sp2.yahoo.com [98.139.91.226]) by ietfa.amsl.com (Postfix) with SMTP id C5FBF21F853E for ; Tue, 3 Jan 2012 12:13:49 -0800 (PST) Received: from [98.139.91.68] by nm24.bullet.mail.sp2.yahoo.com with NNFMP; 03 Jan 2012 20:13:45 -0000 Received: from [98.139.91.27] by tm8.bullet.mail.sp2.yahoo.com with NNFMP; 03 Jan 2012 20:13:45 -0000 Received: from [127.0.0.1] by omp1027.mail.sp2.yahoo.com with NNFMP; 03 Jan 2012 20:13:45 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 679780.29836.bm@omp1027.mail.sp2.yahoo.com Received: (qmail 21476 invoked by uid 60001); 3 Jan 2012 20:13:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1325621624; bh=oxBK+zTuK+YQFl7JKdHGusNap/JRtDvgmqFktNkSFVg=; 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=rcpXtljbmcxNn1B4vHR6kXOVSkPoAGyAaG1nAKsffCU1Ex5V9buPjB24Xy/7Vx3+fQHfrIP3TZTVsxRtePbgjcZQ9NQa62nyVuvGwzWvrDILWqBWgCQUGj6qgUzQb+jdQQqS1AhFKaihVPa5s5bjEsmlvqV/UYxZ/rJkRuZhG/o= 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=TmoVLcoCdLjnXrwjhKIwGStxtXxFPQ+nWV1IxbZQT9yfiXk8FckNaZRNPwIcXWGPcnmRiU+KU0TyseQoB50NaP6wYfXWvk5z4Q4Hg+ygsTJHVtME7vzMnupGmlSA4HrMFXNybrw1Cv5RI+zCUr0Il4I13wUU/2KacnHqQ+7/3eM=; X-YMail-OSG: _wa1v.UVM1lapopAyydyVJtse7NhODrF.Sb3g6e3go.IcFB cdlUEvfZg8avmN208l_B9dsVptVgdYstcpoDrkPaL11sYpUuKzwjZf6o55B3 4kJg03ha6a904EMVMIemdbx_DvrmIaUEI9OHygi2_a7z_GudQguFWDz29Gai RZCvwGP5mA7qPA_0g5I5U1QZd2aFfGNqP36L26pMhDHHFjI36seDdYrPczZ. Vby5UjafjKN1XyFtJZC9Zum8L5.LQYZARm4oWy3QxTQypbZJkIpWJjIVcA8D faGGEu1gkxfbU0WvOVLGmimL2X_WDS53MtYsIAil1gtQ05iq4ivn1EewHTsI iFCa4sRiZUplVaNROKu_1S1AIX92wnmjT2JXoUaYLaIMC31lRKehgVKfXwE_ w7dXYcXpA1KlwPr.F5mr0GuNvMtGkN7eNUQ-- Received: from [209.131.62.115] by web31808.mail.mud.yahoo.com via HTTP; Tue, 03 Jan 2012 12:13:44 PST X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.116.331537 References: <4E1F6AAD24975D4BA5B16804296739435F763122@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739435F772D1D@TK5EX14MBXC283.redmond.corp.microsoft.com> <4EEF13F1.7030409@gmx.de> <4E1F6AAD24975D4BA5B16804296739435F78F5BB@TK5EX14MBXC283.redmond.corp.microsoft.com> <4EFD91B4.5050904@gmx.de> <4E1F6AAD24975D4BA5B16804296739435F790386@TK5EX14MBXC283.redmond.corp.microsoft.com> <1325619340.463.YahooMailNeo@web31808.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B16804296739435F7936E7@TK5EX14MBXC283.redmond.corp.microsoft.com> <1325620772.48511.YahooMailNeo@web31802.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B16804296739435F79376F@TK5EX14MBXC283.redmond.corp.microsoft.com> Message-ID: <1325621624.9908.YahooMailNeo@web31808.mail.mud.yahoo.com> Date: Tue, 3 Jan 2012 12:13:44 -0800 (PST) From: William Mills To: Mike Jones , Julian Reschke In-Reply-To: <4E1F6AAD24975D4BA5B16804296739435F79376F@TK5EX14MBXC283.redmond.corp.microsoft.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="258328648-1814078502-1325621624=:9908" Cc: Mark Nottingham , Barry Leiba , OAuth WG Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft 15? 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, 03 Jan 2012 20:13:51 -0000 --258328648-1814078502-1325621624=:9908 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable http://tools.ietf.org/html/draft-ietf-oauth-v2-22#section-11.2.2 certainly = has these as predefined registered parameters.=C2=A0 If the definition ther= e isn't strong enough, or in that spec, we should fix that.=C2=A0 That is w= here these should be defined.=0A=0A=0A=0A________________________________= =0A From: Mike Jones =0ATo: William Mills ; Julian Reschke =0ACc: Mark Nott= ingham ; Barry Leiba ; OAuth WG =0ASent: Tuesday, January 3, 2012 12:00 PM=0ASubject: RE: [OA= UTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft 15?=0A =0A= =0A =0AThe core spec doesn=E2=80=99t include these parameters.=0A=C2=A0=0AF= rom:William Mills [mailto:wmills@yahoo-inc.com] =0ASent: Tuesday, January 0= 3, 2012 12:00 PM=0ATo: Mike Jones; Julian Reschke=0ACc: Mark Nottingham; Ba= rry Leiba; OAuth WG=0ASubject: Re: [OAUTH-WG] auth-param syntax, was: OK to= post OAuth Bearer draft 15?=0A=C2=A0=0AWhy is Bearer dealing with this at = all?=C2=A0 the BNF for that stuff should be part of the core spec, and addi= tional values perhaps defined in Bearer.=0A=C2=A0=0A=0A____________________= ____________=0A =0AFrom:Mike Jones =0ATo: Will= iam Mills ; Julian Reschke = =0ACc: Mark Nottingham ; Barry Leiba ; OAuth WG =0ASent: Tuesday, January 3, 2012 11:46 AM=0A= Subject: RE: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer dra= ft 15?=0AThis is about the syntax for the scope, error, and error_descripti= on parameters.=C2=A0 The pertinent text from Section 3 is:=0A=C2=A0=0A=C2= =A0=C2=A0 Producers of "scope" strings MUST NOT use characters outside the = set=0A=C2=A0=C2=A0 %x21 / %x23-5B / %x5D-7E for representing the scope valu= es and %x20=0A=C2=A0=C2=A0 for the delimiter.=C2=A0 Producers of "error" an= d "error_description"=0A=C2=A0=C2=A0 strings MUST NOT use characters outsid= e the set %x20-21 / %x23-5B /=0A=C2=A0=C2=A0 %x5D-7E for representing these= values.=C2=A0 Producers of "error-uri"=0A=C2=A0=C2=A0 strings MUST NOT use= characters outside the set %x21 / %x23-5B /=0A=C2=A0=C2=A0 %x5D-7E for rep= resenting these values.=C2=A0 Furthermore, "error-uri"=0A=C2=A0=C2=A0 strin= gs MUST conform to the URI-Reference syntax.=C2=A0 In all these=0A=C2=A0=C2= =A0 cases, no character quoting will occur, as senders are prohibited=0A=C2= =A0=C2=A0 from using the %5C ('\') character.=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 Cheers,=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:William Mills [mailto:w= mills@yahoo-inc.com] =0ASent: Tuesday, January 03, 2012 11:36 AM=0ATo: Mike= Jones; Julian Reschke=0ACc: Mark Nottingham; Barry Leiba; OAuth WG=0ASubje= ct: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft 15= ?=0A=C2=A0=0AIs all this only around the scope parameter?=C2=A0 My mail cit= ed below is with regards to the character set for a valid scope parameter, = which we should be able to define and then lean on the HTTPbis spec for the= actual parameter syntax.=0A=C2=A0=0A=0A________________________________=0A= =0AFrom:Mike Jones =0ATo: Julian Reschke =0ACc: Mark Nottingham ; Barry Leiba ; OAuth WG =0ASent: Friday, December= 30, 2011 3:19 PM=0ASubject: Re: [OAUTH-WG] auth-param syntax, was: OK to p= ost OAuth Bearer draft 15?=0A=0AI did already back the statement that this = is the working group consensus with the e-mails attached in this note sent = to you on December 12, 2011:=0A=C2=A0 - http://www.ietf.org/mail-archive/we= b/oauth/current/msg08042.html=0A=0ABut since that apparently wasn't convinc= ing to you that this working group decision represents more than "just me d= isagreeing with you", here are references to individual messages referenced= in the above e-mail:=0A=C2=A0 - Eran Hammer-Lahav: http://www.ietf.org/mai= l-archive/web/oauth/current/msg07698.html=0A=C2=A0 - John Bradley:=C2=A0 ht= tp://www.ietf.org/mail-archive/web/oauth/current/msg07699.html=0A=C2=A0 - W= illiam Mills:=C2=A0 http://www.ietf.org/mail-archive/web/oauth/current/msg0= 7700.html=0A=C2=A0 - Mike Jones:=C2=A0 http://www.ietf.org/mail-archive/web= /oauth/current/msg07701.html=0A=C2=A0 - Phil Hunt:=C2=A0 http://www.ietf.or= g/mail-archive/web/oauth/current/msg07702.html=0A=C2=A0 - Justin Richer:=C2= =A0 http://www.ietf.org/mail-archive/web/oauth/current/msg07692.html=0A=0AA= s for your assertion that the specs are in conflict, yes, the Bearer spec i= ncludes a different decision than a RECOMMENDED clause in the HTTPbis spec = (which was added after the Bearer text was already in place).=C2=A0 However= , it is not violating any MUST clauses=0A in the HTTPbis spec.=C2=A0 Given = that no MUSTS are violated, I don't see it mandatory for this tension to be= resolved in favor of one spec or the other in order for both to be approve= d as RFCs.=C2=A0 I look forward to seeing that happen soon in both cases (a= nd for the=0A OAuth core spec as well).=0A=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 Best wishes,=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 -- Mike=0A= =0A-----Original Message-----=0AFrom: Julian Reschke [mailto:julian.reschke= @gmx.de] =0ASent: Friday, December 30, 2011 2:26 AM=0ATo: Mike Jones=0ACc: = Barry Leiba; Mark Nottingham; OAuth WG=0ASubject: Re: auth-param syntax, wa= s: [OAUTH-WG] OK to post OAuth Bearer draft 15?=0A=0AOn 2011-12-29 22:18, M= ike Jones wrote:=0A> You proposed, Julian "3. Do not specify the ABNF. The = ABNF of the WWW-Authenticate is defined in HTTPbis. Just state the names of= the parameters, their syntax *after* parsing and their semantics."=0A>=0A>= About some of Mark Nottingham's comments, Barry wrote "Let me point out th= at "this represents working-group consensus" is not always a valid response= .=C2=A0 If the working group has actually considered the *issue*, that migh= t be OK.=C2=A0 But if there's consensus for=0A the chosen solution and some= one brings up a *new* issue with it, that issue needs to be addressed anew.= "=0A>=0A> Relative to these two statements, I believe that I should remark = at this point that your proposed semantics of only considering the syntax a= fter potential quoting was explicitly considered earlier by the working gro= up and rejected.=C2=A0 The consensus, instead,=0A was for the present "no q= uoting will occur for legal inputs" semantics.=0A=0AIt would be helpful if = you could back this statement with pointers to mails. As far as I can tell = it's just you disagreeing with me.=0A=0ABack to the facts:=0A=0Aa) the bear= er spec defines an HTTP authentication scheme, and normatively refers to HT= TPbis Part7 for that=0A=0Ab) HTTPbis recommends new scheme definitions not = to have their own ABNF, as the header field syntax is defined by HTTPbis, n= ot the individual scheme=0A=0Ac) the bearer spec defines it's own ABNF neve= rtheless=0A=0ASo the two specs are in conflict, and we should resolve the c= onflict one way or the other.=0A=0AIf you disagree with the recommendation = in HTTPbis, then you really really should come over to HTTPbis WG and argue= your point of view.=0A=0AIf you agree with it, but think that the bearer s= pec can't follow the recommendation, then it would be good to explain the r= easoning (optimally in the spec).=0A=0AIf you agree with it, and think the = bearer spec *could* follow it, then... change it, by all means.=0A=0AAnyway= , if this issue isn't resolved before IETF LC then it will be raised again = at that time.=0A=0A=0A> I believe that in the New Year the chairs and area = directors will need to decide how to proceed on this issue.=C2=A0 (The work= ing group consensus, as I see it, is already both well-informed and clear o= n this point, but I understand that that's not the only consideration.)=C2= =A0=0A It would be good to see the spec finished shortly.=0A> ...=0A=0ABest= regards, Julian=0A=0A=0A=0A_______________________________________________= =0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/listi= nfo/oauth --258328648-1814078502-1325621624=:9908 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
http://tools.ietf.org/html/draft-ietf-oauth-v2-22#section-11.2.2 certainl= y has these as predefined registered parameters.  If the definition th= ere isn't strong enough, or in that spec, we should fix that.  That is= where these should be defined.

= From: Mike Jones <Micha= el.Jones@microsoft.com>
To: William Mills <wmills@yahoo-inc.com>; Julian Reschke <jul= ian.reschke@gmx.de>
Cc:= Mark Nottingham <mnot@mnot.net>; Barry Leiba <barryleiba@computer.org&= gt;; OAuth WG <oauth@ietf.org>
Sent: Tuesday, January 3, 2012 12:00 PM
Subject: RE: [OAUTH-WG] auth-param synta= x, was: OK to post OAuth Bearer draft 15?
=0A
=0A=0A =0A =0A=0A=0A
=0A
=0A
The core spec doesn=E2=80=99t = include these parameters.
=0A
 
= =0A
=0A
=0A
From: W= illiam Mills [mailto:wmills@yahoo-inc.com]=0A
=0ASent: Tuesday, J= anuary 03, 2012 12:00 PM
=0ATo: Mike Jones; Julian Reschke
=0A= Cc: Mark Nottingham; Barry Leiba; OAuth WG
=0ASubject: Re:= [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft 15?
=0A
=0A
=0A
  =0A
=0A
=0A
Why is Bearer d= ealing with this at all?  the BNF for that stuff should be part of the= core spec, and additional values perhaps defined in Bearer.
= =0A
=0A
=0A
  =0A
=0A
=0A
=0A
=0A=0A
=0A
=0A
From: Mike= Jones <Michael.Jo= nes@microsoft.com>
=0ATo: William Mills <wmills@yahoo-inc.com>; Julian Reschke <= julian.reschke@gmx.de>=0A<= br>=0ACc: Mark Nottingham <mnot@mnot.ne= t>; Barry Leiba <ba= rryleiba@computer.org>; OAuth WG <oau= th@ietf.org>=0A
=0ASent: Tuesday, January 3, 2012 11:46 AM=
=0ASubject: RE: [OAUTH-WG] auth-param syntax, was: OK to post OA= uth Bearer draft 15?
=0A=0A
=0A
=0A
=0A
This is about the syntax for the scope, error, and error_descr= iption parameters.  The pertinent text from=0A=0ASection 3 is:
=0A
=0A
=0A
 <= /span>
=0A
=0A
=0A
   Producers of "scope"= strings MUST NOT use characters outside the set
=0A
=0A
=0A
   %x21 / %x23-5B / %x5D-7E for representing the = scope values and %x20
=0A<= /div>=0A
=0A
  = ; for the delimiter.  Producers of "error" and "error_description"
=0A
=0A
=0A
   strings MUST NOT use ch= aracters outside the set %x20-21 / %x23-5B /
=0A
=0A
=0A
   %x5D-7E for representing these values.  Produ= cers of "error-uri"
=0A=0A
=0A
   = strings MUST NOT use characters outside the set %x21 / %x23-5B /
=0A
=0A
=0A
   %x5D-7E for representing these= values.  Furthermore, "error-uri"=
=0A
=0A
=0A
   strings MUST conform to the URI-Reference syntax. = ; In all these
=0A
= =0A
=0A
   cas= es, no character quoting will occur, as senders are prohibited
=0A
=0A
=0A
   from using the %5C ('\') charact= er.
=0A
=0A
=0A 
=0A
=0A
=0A
            &n= bsp;            = ;            &n= bsp;            = ;          Cheers,
=0A
=0A
=0A
         =             &nb= sp;            =             &nb= sp;            = -- Mike
=0A
=0A
= =0A
 
=0A
=0A
=0A
=0A
=0A
From: William Mills=0A[mailto:wmills@yahoo-inc.com]
=0ASent: Tuesd= ay, January 03, 2012 11:36 AM
=0ATo: Mike Jones; Julian Reschke=0ACc: Mark Nottingham; Barry Leiba; OAuth WG
=0ASubject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft 15?<= /span>
=0A
=0A
=0A=0A
=0A
 
=0A
=0A
=0A=0A
=0A
Is all this only around the= scope parameter?  My mail cited below is with regards to the characte= r set for a valid scope parameter, which we should be able to define and=0A= then lean on the HTTPbis spec for the actual parameter syntax.
=0A
=0A
=0A
=0A
=0A=
 
=0A
=0A
=0A
=0A
=0A
=0A=0A
=0A
=0A
=0A
Fro= m: Mike Jones <= Michael.Jones@micro= soft.com>
=0ATo: Julian Reschke <julian.reschke@gmx.de>=0A
=0ACc: Mark = Nottingham <mnot@mnot.net>; Barry Leib= a <barryleiba@computer.org= >; OAuth WG <oauth@ietf.org>= =0A
=0ASent: Friday, December 30, 2011 3:19 PM
=0ASubject:<= /b> Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft 15= ?
=0A
=0AI did already back the s= tatement that this is the working group consensus with the e-mails attached= in this note sent to you on December 12, 2011:
=0A  - http://www.i= etf.org/mail-archive/web/oauth/current/msg08042.html
=0A
=0ABut since= that apparently wasn't convincing to you that this working group decision = represents more than "just me disagreeing with you", here are references to= individual messages referenced in the above e-mail:
=0A  - Eran Ha= mmer-Lahav: http://www.ietf.org/mail-archive/web/oauth/current/msg07698.htm= l
=0A  - John Bradley:  http://www.ietf.org/mail-archive/web/o= auth/current/msg07699.html
=0A  - William Mills:  http://www.i= etf.org/mail-archive/web/oauth/current/msg07700.html
=0A  - Mike Jo= nes:  http://www.ietf.org/mail-archive/web/oauth/current/msg07701.html=
=0A  - Phil Hunt:  http://www.ietf.org/mail-archive/web/oauth= /current/msg07702.html
=0A  - Justin Richer:  http://www.ietf.= org/mail-archive/web/oauth/current/msg07692.html
=0A
=0AAs for your a= ssertion that the specs are in conflict, yes, the Bearer spec includes a di= fferent decision than a RECOMMENDED clause in the HTTPbis spec (which was a= dded after the Bearer text was already in place).  However, it is not = violating any MUST clauses=0A in the HTTPbis spec.  Given that no MUST= S are violated, I don't see it mandatory for this tension to be resolved in= favor of one spec or the other in order for both to be approved as RFCs.&n= bsp; I look forward to seeing that happen soon in both cases (and for the= =0A OAuth core spec as well).
=0A
=0A      &= nbsp;         Best wishes,
=0A  =               -- Mike
= =0A
=0A-----Original Message-----
=0AFrom: Julian Reschke [mailto:julian.reschke@gmx.de]=0A
=0A= Sent: Friday, December 30, 2011 2:26 AM
=0ATo: Mike Jones
=0ACc: Barr= y Leiba; Mark Nottingham; OAuth WG
=0ASubject: Re: auth-param syntax, wa= s: [OAUTH-WG] OK to post OAuth Bearer draft 15?
=0A
=0AOn 2011-12-29 = 22:18, Mike Jones wrote:
=0A> You proposed, Julian "3. Do not specify= the ABNF. The ABNF of the WWW-Authenticate is defined in HTTPbis. Just sta= te the names of the parameters, their syntax *after* parsing and their sema= ntics."
=0A>
=0A> About some of Mark Nottingham's comments, Bar= ry wrote "Let me point out that "this represents working-group consensus" i= s not always a valid response.  If the working group has actually cons= idered the *issue*, that might be OK.  But if there's consensus for=0A= the chosen solution and someone brings up a *new* issue with it, that issu= e needs to be addressed anew."
=0A>
=0A> Relative to these two = statements, I believe that I should remark at this point that your proposed= semantics of only considering the syntax after potential quoting was expli= citly considered earlier by the working group and rejected.  The conse= nsus, instead,=0A was for the present "no quoting will occur for legal inpu= ts" semantics.
=0A
=0AIt would be helpful if you could back this stat= ement with pointers to mails. As far as I can tell it's just you disagreein= g with me.
=0A
=0ABack to the facts:
=0A
=0Aa) the bearer spec = defines an HTTP authentication scheme, and normatively refers to HTTPbis Pa= rt7 for that
=0A
=0Ab) HTTPbis recommends new scheme definitions not = to have their own ABNF, as the header field syntax is defined by HTTPbis, n= ot the individual scheme
=0A
=0Ac) the bearer spec defines it's own A= BNF nevertheless
=0A
=0ASo the two specs are in conflict, and we shou= ld resolve the conflict one way or the other.
=0A
=0AIf you disagree = with the recommendation in HTTPbis, then you really really should come over= to HTTPbis WG and argue your point of view.
=0A
=0AIf you agree with= it, but think that the bearer spec can't follow the recommendation, then i= t would be good to explain the reasoning (optimally in the spec).
=0A=0AIf you agree with it, and think the bearer spec *could* follow it, then= ... change it, by all means.
=0A
=0AAnyway, if this issue isn't resol= ved before IETF LC then it will be raised again at that time.
=0A
=0A=
=0A> I believe that in the New Year the chairs and area directors wi= ll need to decide how to proceed on this issue.  (The working group co= nsensus, as I see it, is already both well-informed and clear on this point= , but I understand that that's not the only consideration.) =0A It wou= ld be good to see the spec finished shortly.
=0A> ...
=0A
=0ABe= st regards, Julian
=0A
=0A
=0A
=0A_____________________________= __________________
=0AOAuth mailing list
=0AOAuth@ietf.org
=0Ahttps://www.ietf.org/mailman/li= stinfo/oauth
=0A
=0A
=0A
=0A
=0A
= =0A
=0A
=0A
 =
=0A
=0A
=0A
=0A
=0A
=0A=0A


--258328648-1814078502-1325621624=:9908-- From Michael.Jones@microsoft.com Tue Jan 3 12:20:30 2012 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 1B98911E80E2 for ; Tue, 3 Jan 2012 12:20:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.523 X-Spam-Level: X-Spam-Status: No, score=-3.523 tagged_above=-999 required=5 tests=[AWL=0.075, 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 B-Id6g74Hjyk for ; Tue, 3 Jan 2012 12:20:28 -0800 (PST) Received: from AM1EHSOBE002.bigfish.com (am1ehsobe002.messaging.microsoft.com [213.199.154.205]) by ietfa.amsl.com (Postfix) with ESMTP id 2A11711E80D9 for ; Tue, 3 Jan 2012 12:20:19 -0800 (PST) Received: from mail80-am1-R.bigfish.com (10.3.201.254) by AM1EHSOBE002.bigfish.com (10.3.204.22) with Microsoft SMTP Server id 14.1.225.23; Tue, 3 Jan 2012 20:20:18 +0000 Received: from mail80-am1 (localhost [127.0.0.1]) by mail80-am1-R.bigfish.com (Postfix) with ESMTP id EC593A015A; Tue, 3 Jan 2012 20:20:17 +0000 (UTC) X-SpamScore: -48 X-BigFish: VS-48(zz9371I1415Jc89bh2174M936eK146fK542M1432Nc857h98dKzz1202hzz8275ch1033IL8275bh8275dhz2fh2a8h668h839h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail80-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail80-am1 (localhost.localdomain [127.0.0.1]) by mail80-am1 (MessageSwitch) id 1325622017281915_19849; Tue, 3 Jan 2012 20:20:17 +0000 (UTC) Received: from AM1EHSMHS020.bigfish.com (unknown [10.3.201.248]) by mail80-am1.bigfish.com (Postfix) with ESMTP id 39EB280049; Tue, 3 Jan 2012 20:20:17 +0000 (UTC) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS020.bigfish.com (10.3.206.23) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 3 Jan 2012 20:20:13 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.84]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.02.0247.005; Tue, 3 Jan 2012 12:20:07 -0800 From: Mike Jones To: William Mills , Julian Reschke Thread-Topic: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft 15? Thread-Index: AQHMyk7k0nsxP6uHFU2ycTUC8uzaDZX7CnqQgACLbwD//3oSIIAAieYA//97QxA= Date: Tue, 3 Jan 2012 20:20:07 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739435F793829@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739435F763122@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739435F772D1D@TK5EX14MBXC283.redmond.corp.microsoft.com> <4EEF13F1.7030409@gmx.de> <4E1F6AAD24975D4BA5B16804296739435F78F5BB@TK5EX14MBXC283.redmond.corp.microsoft.com> <4EFD91B4.5050904@gmx.de> <4E1F6AAD24975D4BA5B16804296739435F790386@TK5EX14MBXC283.redmond.corp.microsoft.com> <1325619340.463.YahooMailNeo@web31808.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B16804296739435F7936E7@TK5EX14MBXC283.redmond.corp.microsoft.com> <1325620772.48511.YahooMailNeo@web31802.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B16804296739435F79376F@TK5EX14MBXC283.redmond.corp.microsoft.com> <1325621624.9908.YahooMailNeo@web31808.mail.mud.yahoo.com> In-Reply-To: <1325621624.9908.YahooMailNeo@web31808.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.79] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739435F793829TK5EX14MBXC283r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: Mark Nottingham , Barry Leiba , OAuth WG Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft 15? 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, 03 Jan 2012 20:20:30 -0000 --_000_4E1F6AAD24975D4BA5B16804296739435F793829TK5EX14MBXC283r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U29ycnksIEkgc2hvdWxkIGhhdmUgYmVlbiBtb3JlIHByZWNpc2UuICBUaGUgQ29yZSBzcGVjIGRv ZXNu4oCZdCBkZWZpbmUgaG93IHRvIHRyYW5zbWl0IHRoZXNlIGZpZWxkcyBpbiB0aGUgV1dXLUF1 dGhlbnRpY2F0ZSByZXNwb25zZSBoZWFkZXIgZmllbGQuICBUaGUgQmVhcmVyIHNwZWMgZG9lcy4N Cg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogV2lsbGlhbSBNaWxscyBbbWFpbHRvOndtaWxsc0B5 YWhvby1pbmMuY29tXQ0KU2VudDogVHVlc2RheSwgSmFudWFyeSAwMywgMjAxMiAxMjoxNCBQTQ0K VG86IE1pa2UgSm9uZXM7IEp1bGlhbiBSZXNjaGtlDQpDYzogTWFyayBOb3R0aW5naGFtOyBCYXJy eSBMZWliYTsgT0F1dGggV0cNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIGF1dGgtcGFyYW0gc3lu dGF4LCB3YXM6IE9LIHRvIHBvc3QgT0F1dGggQmVhcmVyIGRyYWZ0IDE1Pw0KDQpodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXYyLTIyI3NlY3Rpb24tMTEuMi4yIGNl cnRhaW5seSBoYXMgdGhlc2UgYXMgcHJlZGVmaW5lZCByZWdpc3RlcmVkIHBhcmFtZXRlcnMuICBJ ZiB0aGUgZGVmaW5pdGlvbiB0aGVyZSBpc24ndCBzdHJvbmcgZW5vdWdoLCBvciBpbiB0aGF0IHNw ZWMsIHdlIHNob3VsZCBmaXggdGhhdC4gIFRoYXQgaXMgd2hlcmUgdGhlc2Ugc2hvdWxkIGJlIGRl ZmluZWQuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBNaWtlIEpv bmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWlj cm9zb2Z0LmNvbT4+DQpUbzogV2lsbGlhbSBNaWxscyA8d21pbGxzQHlhaG9vLWluYy5jb208bWFp bHRvOndtaWxsc0B5YWhvby1pbmMuY29tPj47IEp1bGlhbiBSZXNjaGtlIDxqdWxpYW4ucmVzY2hr ZUBnbXguZGU8bWFpbHRvOmp1bGlhbi5yZXNjaGtlQGdteC5kZT4+DQpDYzogTWFyayBOb3R0aW5n aGFtIDxtbm90QG1ub3QubmV0PG1haWx0bzptbm90QG1ub3QubmV0Pj47IEJhcnJ5IExlaWJhIDxi YXJyeWxlaWJhQGNvbXB1dGVyLm9yZzxtYWlsdG86YmFycnlsZWliYUBjb21wdXRlci5vcmc+Pjsg T0F1dGggV0cgPG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4+DQpTZW50OiBU dWVzZGF5LCBKYW51YXJ5IDMsIDIwMTIgMTI6MDAgUE0NClN1YmplY3Q6IFJFOiBbT0FVVEgtV0dd IGF1dGgtcGFyYW0gc3ludGF4LCB3YXM6IE9LIHRvIHBvc3QgT0F1dGggQmVhcmVyIGRyYWZ0IDE1 Pw0KVGhlIGNvcmUgc3BlYyBkb2VzbuKAmXQgaW5jbHVkZSB0aGVzZSBwYXJhbWV0ZXJzLg0KDQpG cm9tOiBXaWxsaWFtIE1pbGxzIFttYWlsdG86d21pbGxzQHlhaG9vLWluYy5jb21dPG1haWx0bzpb bWFpbHRvOndtaWxsc0B5YWhvby1pbmMuY29tXT4NClNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMDMs IDIwMTIgMTI6MDAgUE0NClRvOiBNaWtlIEpvbmVzOyBKdWxpYW4gUmVzY2hrZQ0KQ2M6IE1hcmsg Tm90dGluZ2hhbTsgQmFycnkgTGVpYmE7IE9BdXRoIFdHDQpTdWJqZWN0OiBSZTogW09BVVRILVdH XSBhdXRoLXBhcmFtIHN5bnRheCwgd2FzOiBPSyB0byBwb3N0IE9BdXRoIEJlYXJlciBkcmFmdCAx NT8NCg0KV2h5IGlzIEJlYXJlciBkZWFsaW5nIHdpdGggdGhpcyBhdCBhbGw/ICB0aGUgQk5GIGZv ciB0aGF0IHN0dWZmIHNob3VsZCBiZSBwYXJ0IG9mIHRoZSBjb3JlIHNwZWMsIGFuZCBhZGRpdGlv bmFsIHZhbHVlcyBwZXJoYXBzIGRlZmluZWQgaW4gQmVhcmVyLg0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KRnJvbTogTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3Nv ZnQuY29tPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+Pg0KVG86IFdpbGxpYW0g TWlsbHMgPHdtaWxsc0B5YWhvby1pbmMuY29tPG1haWx0bzp3bWlsbHNAeWFob28taW5jLmNvbT4+ OyBKdWxpYW4gUmVzY2hrZSA8anVsaWFuLnJlc2Noa2VAZ214LmRlPG1haWx0bzpqdWxpYW4ucmVz Y2hrZUBnbXguZGU+Pg0KQ2M6IE1hcmsgTm90dGluZ2hhbSA8bW5vdEBtbm90Lm5ldDxtYWlsdG86 bW5vdEBtbm90Lm5ldD4+OyBCYXJyeSBMZWliYSA8YmFycnlsZWliYUBjb21wdXRlci5vcmc8bWFp bHRvOmJhcnJ5bGVpYmFAY29tcHV0ZXIub3JnPj47IE9BdXRoIFdHIDxvYXV0aEBpZXRmLm9yZzxt YWlsdG86b2F1dGhAaWV0Zi5vcmc+Pg0KU2VudDogVHVlc2RheSwgSmFudWFyeSAzLCAyMDEyIDEx OjQ2IEFNDQpTdWJqZWN0OiBSRTogW09BVVRILVdHXSBhdXRoLXBhcmFtIHN5bnRheCwgd2FzOiBP SyB0byBwb3N0IE9BdXRoIEJlYXJlciBkcmFmdCAxNT8NClRoaXMgaXMgYWJvdXQgdGhlIHN5bnRh eCBmb3IgdGhlIHNjb3BlLCBlcnJvciwgYW5kIGVycm9yX2Rlc2NyaXB0aW9uIHBhcmFtZXRlcnMu ICBUaGUgcGVydGluZW50IHRleHQgZnJvbSBTZWN0aW9uIDMgPGh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtdjItYmVhcmVyLTE1I3NlY3Rpb24tMz4gaXM6DQoNCiAg IFByb2R1Y2VycyBvZiAic2NvcGUiIHN0cmluZ3MgTVVTVCBOT1QgdXNlIGNoYXJhY3RlcnMgb3V0 c2lkZSB0aGUgc2V0DQogICAleDIxIC8gJXgyMy01QiAvICV4NUQtN0UgZm9yIHJlcHJlc2VudGlu ZyB0aGUgc2NvcGUgdmFsdWVzIGFuZCAleDIwDQogICBmb3IgdGhlIGRlbGltaXRlci4gIFByb2R1 Y2VycyBvZiAiZXJyb3IiIGFuZCAiZXJyb3JfZGVzY3JpcHRpb24iDQogICBzdHJpbmdzIE1VU1Qg Tk9UIHVzZSBjaGFyYWN0ZXJzIG91dHNpZGUgdGhlIHNldCAleDIwLTIxIC8gJXgyMy01QiAvDQog ICAleDVELTdFIGZvciByZXByZXNlbnRpbmcgdGhlc2UgdmFsdWVzLiAgUHJvZHVjZXJzIG9mICJl cnJvci11cmkiDQogICBzdHJpbmdzIE1VU1QgTk9UIHVzZSBjaGFyYWN0ZXJzIG91dHNpZGUgdGhl IHNldCAleDIxIC8gJXgyMy01QiAvDQogICAleDVELTdFIGZvciByZXByZXNlbnRpbmcgdGhlc2Ug dmFsdWVzLiAgRnVydGhlcm1vcmUsICJlcnJvci11cmkiDQogICBzdHJpbmdzIE1VU1QgY29uZm9y bSB0byB0aGUgVVJJLVJlZmVyZW5jZSBzeW50YXguICBJbiBhbGwgdGhlc2UNCiAgIGNhc2VzLCBu byBjaGFyYWN0ZXIgcXVvdGluZyB3aWxsIG9jY3VyLCBhcyBzZW5kZXJzIGFyZSBwcm9oaWJpdGVk DQogICBmcm9tIHVzaW5nIHRoZSAlNUMgKCdcJykgY2hhcmFjdGVyLg0KDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBDaGVlcnMsDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAtLSBNaWtlDQoNCkZyb206IFdpbGxpYW0gTWlsbHMgW21haWx0bzp3bWlsbHNAeWFob28taW5j LmNvbV08bWFpbHRvOlttYWlsdG86d21pbGxzQHlhaG9vLWluYy5jb21dPg0KU2VudDogVHVlc2Rh eSwgSmFudWFyeSAwMywgMjAxMiAxMTozNiBBTQ0KVG86IE1pa2UgSm9uZXM7IEp1bGlhbiBSZXNj aGtlDQpDYzogTWFyayBOb3R0aW5naGFtOyBCYXJyeSBMZWliYTsgT0F1dGggV0cNClN1YmplY3Q6 IFJlOiBbT0FVVEgtV0ddIGF1dGgtcGFyYW0gc3ludGF4LCB3YXM6IE9LIHRvIHBvc3QgT0F1dGgg QmVhcmVyIGRyYWZ0IDE1Pw0KDQpJcyBhbGwgdGhpcyBvbmx5IGFyb3VuZCB0aGUgc2NvcGUgcGFy YW1ldGVyPyAgTXkgbWFpbCBjaXRlZCBiZWxvdyBpcyB3aXRoIHJlZ2FyZHMgdG8gdGhlIGNoYXJh Y3RlciBzZXQgZm9yIGEgdmFsaWQgc2NvcGUgcGFyYW1ldGVyLCB3aGljaCB3ZSBzaG91bGQgYmUg YWJsZSB0byBkZWZpbmUgYW5kIHRoZW4gbGVhbiBvbiB0aGUgSFRUUGJpcyBzcGVjIGZvciB0aGUg YWN0dWFsIHBhcmFtZXRlciBzeW50YXguDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpGcm9tOiBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRv Ok1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+DQpUbzogSnVsaWFuIFJlc2Noa2UgPGp1bGlh bi5yZXNjaGtlQGdteC5kZTxtYWlsdG86anVsaWFuLnJlc2Noa2VAZ214LmRlPj4NCkNjOiBNYXJr IE5vdHRpbmdoYW0gPG1ub3RAbW5vdC5uZXQ8bWFpbHRvOm1ub3RAbW5vdC5uZXQ+PjsgQmFycnkg TGVpYmEgPGJhcnJ5bGVpYmFAY29tcHV0ZXIub3JnPG1haWx0bzpiYXJyeWxlaWJhQGNvbXB1dGVy Lm9yZz4+OyBPQXV0aCBXRyA8b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4N ClNlbnQ6IEZyaWRheSwgRGVjZW1iZXIgMzAsIDIwMTEgMzoxOSBQTQ0KU3ViamVjdDogUmU6IFtP QVVUSC1XR10gYXV0aC1wYXJhbSBzeW50YXgsIHdhczogT0sgdG8gcG9zdCBPQXV0aCBCZWFyZXIg ZHJhZnQgMTU/DQoNCkkgZGlkIGFscmVhZHkgYmFjayB0aGUgc3RhdGVtZW50IHRoYXQgdGhpcyBp cyB0aGUgd29ya2luZyBncm91cCBjb25zZW5zdXMgd2l0aCB0aGUgZS1tYWlscyBhdHRhY2hlZCBp biB0aGlzIG5vdGUgc2VudCB0byB5b3Ugb24gRGVjZW1iZXIgMTIsIDIwMTE6DQogIC0gaHR0cDov L3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMDgwNDIuaHRt bA0KDQpCdXQgc2luY2UgdGhhdCBhcHBhcmVudGx5IHdhc24ndCBjb252aW5jaW5nIHRvIHlvdSB0 aGF0IHRoaXMgd29ya2luZyBncm91cCBkZWNpc2lvbiByZXByZXNlbnRzIG1vcmUgdGhhbiAianVz dCBtZSBkaXNhZ3JlZWluZyB3aXRoIHlvdSIsIGhlcmUgYXJlIHJlZmVyZW5jZXMgdG8gaW5kaXZp ZHVhbCBtZXNzYWdlcyByZWZlcmVuY2VkIGluIHRoZSBhYm92ZSBlLW1haWw6DQogIC0gRXJhbiBI YW1tZXItTGFoYXY6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vYXV0aC9j dXJyZW50L21zZzA3Njk4Lmh0bWwNCiAgLSBKb2huIEJyYWRsZXk6ICBodHRwOi8vd3d3LmlldGYu b3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgvY3VycmVudC9tc2cwNzY5OS5odG1sDQogIC0gV2ls bGlhbSBNaWxsczogIGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vYXV0aC9j dXJyZW50L21zZzA3NzAwLmh0bWwNCiAgLSBNaWtlIEpvbmVzOiAgaHR0cDovL3d3dy5pZXRmLm9y Zy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMDc3MDEuaHRtbA0KICAtIFBoaWwg SHVudDogIGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vYXV0aC9jdXJyZW50 L21zZzA3NzAyLmh0bWwNCiAgLSBKdXN0aW4gUmljaGVyOiAgaHR0cDovL3d3dy5pZXRmLm9yZy9t YWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMDc2OTIuaHRtbA0KDQpBcyBmb3IgeW91 ciBhc3NlcnRpb24gdGhhdCB0aGUgc3BlY3MgYXJlIGluIGNvbmZsaWN0LCB5ZXMsIHRoZSBCZWFy ZXIgc3BlYyBpbmNsdWRlcyBhIGRpZmZlcmVudCBkZWNpc2lvbiB0aGFuIGEgUkVDT01NRU5ERUQg Y2xhdXNlIGluIHRoZSBIVFRQYmlzIHNwZWMgKHdoaWNoIHdhcyBhZGRlZCBhZnRlciB0aGUgQmVh cmVyIHRleHQgd2FzIGFscmVhZHkgaW4gcGxhY2UpLiAgSG93ZXZlciwgaXQgaXMgbm90IHZpb2xh dGluZyBhbnkgTVVTVCBjbGF1c2VzIGluIHRoZSBIVFRQYmlzIHNwZWMuICBHaXZlbiB0aGF0IG5v IE1VU1RTIGFyZSB2aW9sYXRlZCwgSSBkb24ndCBzZWUgaXQgbWFuZGF0b3J5IGZvciB0aGlzIHRl bnNpb24gdG8gYmUgcmVzb2x2ZWQgaW4gZmF2b3Igb2Ygb25lIHNwZWMgb3IgdGhlIG90aGVyIGlu IG9yZGVyIGZvciBib3RoIHRvIGJlIGFwcHJvdmVkIGFzIFJGQ3MuICBJIGxvb2sgZm9yd2FyZCB0 byBzZWVpbmcgdGhhdCBoYXBwZW4gc29vbiBpbiBib3RoIGNhc2VzIChhbmQgZm9yIHRoZSBPQXV0 aCBjb3JlIHNwZWMgYXMgd2VsbCkuDQoNCiAgICAgICAgICAgICAgICBCZXN0IHdpc2hlcywNCiAg ICAgICAgICAgICAgICAtLSBNaWtlDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBKdWxpYW4gUmVzY2hrZSBbbWFpbHRvOmp1bGlhbi5yZXNjaGtlQGdteC5kZTxtYWlsdG86anVs aWFuLnJlc2Noa2VAZ214LmRlPl0NClNlbnQ6IEZyaWRheSwgRGVjZW1iZXIgMzAsIDIwMTEgMjoy NiBBTQ0KVG86IE1pa2UgSm9uZXMNCkNjOiBCYXJyeSBMZWliYTsgTWFyayBOb3R0aW5naGFtOyBP QXV0aCBXRw0KU3ViamVjdDogUmU6IGF1dGgtcGFyYW0gc3ludGF4LCB3YXM6IFtPQVVUSC1XR10g T0sgdG8gcG9zdCBPQXV0aCBCZWFyZXIgZHJhZnQgMTU/DQoNCk9uIDIwMTEtMTItMjkgMjI6MTgs IE1pa2UgSm9uZXMgd3JvdGU6DQo+IFlvdSBwcm9wb3NlZCwgSnVsaWFuICIzLiBEbyBub3Qgc3Bl Y2lmeSB0aGUgQUJORi4gVGhlIEFCTkYgb2YgdGhlIFdXVy1BdXRoZW50aWNhdGUgaXMgZGVmaW5l ZCBpbiBIVFRQYmlzLiBKdXN0IHN0YXRlIHRoZSBuYW1lcyBvZiB0aGUgcGFyYW1ldGVycywgdGhl aXIgc3ludGF4ICphZnRlciogcGFyc2luZyBhbmQgdGhlaXIgc2VtYW50aWNzLiINCj4NCj4gQWJv dXQgc29tZSBvZiBNYXJrIE5vdHRpbmdoYW0ncyBjb21tZW50cywgQmFycnkgd3JvdGUgIkxldCBt ZSBwb2ludCBvdXQgdGhhdCAidGhpcyByZXByZXNlbnRzIHdvcmtpbmctZ3JvdXAgY29uc2Vuc3Vz IiBpcyBub3QgYWx3YXlzIGEgdmFsaWQgcmVzcG9uc2UuICBJZiB0aGUgd29ya2luZyBncm91cCBo YXMgYWN0dWFsbHkgY29uc2lkZXJlZCB0aGUgKmlzc3VlKiwgdGhhdCBtaWdodCBiZSBPSy4gIEJ1 dCBpZiB0aGVyZSdzIGNvbnNlbnN1cyBmb3IgdGhlIGNob3NlbiBzb2x1dGlvbiBhbmQgc29tZW9u ZSBicmluZ3MgdXAgYSAqbmV3KiBpc3N1ZSB3aXRoIGl0LCB0aGF0IGlzc3VlIG5lZWRzIHRvIGJl IGFkZHJlc3NlZCBhbmV3LiINCj4NCj4gUmVsYXRpdmUgdG8gdGhlc2UgdHdvIHN0YXRlbWVudHMs IEkgYmVsaWV2ZSB0aGF0IEkgc2hvdWxkIHJlbWFyayBhdCB0aGlzIHBvaW50IHRoYXQgeW91ciBw cm9wb3NlZCBzZW1hbnRpY3Mgb2Ygb25seSBjb25zaWRlcmluZyB0aGUgc3ludGF4IGFmdGVyIHBv dGVudGlhbCBxdW90aW5nIHdhcyBleHBsaWNpdGx5IGNvbnNpZGVyZWQgZWFybGllciBieSB0aGUg d29ya2luZyBncm91cCBhbmQgcmVqZWN0ZWQuICBUaGUgY29uc2Vuc3VzLCBpbnN0ZWFkLCB3YXMg Zm9yIHRoZSBwcmVzZW50ICJubyBxdW90aW5nIHdpbGwgb2NjdXIgZm9yIGxlZ2FsIGlucHV0cyIg c2VtYW50aWNzLg0KDQpJdCB3b3VsZCBiZSBoZWxwZnVsIGlmIHlvdSBjb3VsZCBiYWNrIHRoaXMg c3RhdGVtZW50IHdpdGggcG9pbnRlcnMgdG8gbWFpbHMuIEFzIGZhciBhcyBJIGNhbiB0ZWxsIGl0 J3MganVzdCB5b3UgZGlzYWdyZWVpbmcgd2l0aCBtZS4NCg0KQmFjayB0byB0aGUgZmFjdHM6DQoN CmEpIHRoZSBiZWFyZXIgc3BlYyBkZWZpbmVzIGFuIEhUVFAgYXV0aGVudGljYXRpb24gc2NoZW1l LCBhbmQgbm9ybWF0aXZlbHkgcmVmZXJzIHRvIEhUVFBiaXMgUGFydDcgZm9yIHRoYXQNCg0KYikg SFRUUGJpcyByZWNvbW1lbmRzIG5ldyBzY2hlbWUgZGVmaW5pdGlvbnMgbm90IHRvIGhhdmUgdGhl aXIgb3duIEFCTkYsIGFzIHRoZSBoZWFkZXIgZmllbGQgc3ludGF4IGlzIGRlZmluZWQgYnkgSFRU UGJpcywgbm90IHRoZSBpbmRpdmlkdWFsIHNjaGVtZQ0KDQpjKSB0aGUgYmVhcmVyIHNwZWMgZGVm aW5lcyBpdCdzIG93biBBQk5GIG5ldmVydGhlbGVzcw0KDQpTbyB0aGUgdHdvIHNwZWNzIGFyZSBp biBjb25mbGljdCwgYW5kIHdlIHNob3VsZCByZXNvbHZlIHRoZSBjb25mbGljdCBvbmUgd2F5IG9y IHRoZSBvdGhlci4NCg0KSWYgeW91IGRpc2FncmVlIHdpdGggdGhlIHJlY29tbWVuZGF0aW9uIGlu IEhUVFBiaXMsIHRoZW4geW91IHJlYWxseSByZWFsbHkgc2hvdWxkIGNvbWUgb3ZlciB0byBIVFRQ YmlzIFdHIGFuZCBhcmd1ZSB5b3VyIHBvaW50IG9mIHZpZXcuDQoNCklmIHlvdSBhZ3JlZSB3aXRo IGl0LCBidXQgdGhpbmsgdGhhdCB0aGUgYmVhcmVyIHNwZWMgY2FuJ3QgZm9sbG93IHRoZSByZWNv bW1lbmRhdGlvbiwgdGhlbiBpdCB3b3VsZCBiZSBnb29kIHRvIGV4cGxhaW4gdGhlIHJlYXNvbmlu ZyAob3B0aW1hbGx5IGluIHRoZSBzcGVjKS4NCg0KSWYgeW91IGFncmVlIHdpdGggaXQsIGFuZCB0 aGluayB0aGUgYmVhcmVyIHNwZWMgKmNvdWxkKiBmb2xsb3cgaXQsIHRoZW4uLi4gY2hhbmdlIGl0 LCBieSBhbGwgbWVhbnMuDQoNCkFueXdheSwgaWYgdGhpcyBpc3N1ZSBpc24ndCByZXNvbHZlZCBi ZWZvcmUgSUVURiBMQyB0aGVuIGl0IHdpbGwgYmUgcmFpc2VkIGFnYWluIGF0IHRoYXQgdGltZS4N Cg0KDQo+IEkgYmVsaWV2ZSB0aGF0IGluIHRoZSBOZXcgWWVhciB0aGUgY2hhaXJzIGFuZCBhcmVh IGRpcmVjdG9ycyB3aWxsIG5lZWQgdG8gZGVjaWRlIGhvdyB0byBwcm9jZWVkIG9uIHRoaXMgaXNz dWUuICAoVGhlIHdvcmtpbmcgZ3JvdXAgY29uc2Vuc3VzLCBhcyBJIHNlZSBpdCwgaXMgYWxyZWFk eSBib3RoIHdlbGwtaW5mb3JtZWQgYW5kIGNsZWFyIG9uIHRoaXMgcG9pbnQsIGJ1dCBJIHVuZGVy c3RhbmQgdGhhdCB0aGF0J3Mgbm90IHRoZSBvbmx5IGNvbnNpZGVyYXRpb24uKSAgSXQgd291bGQg YmUgZ29vZCB0byBzZWUgdGhlIHNwZWMgZmluaXNoZWQgc2hvcnRseS4NCj4gLi4uDQoNCkJlc3Qg cmVnYXJkcywgSnVsaWFuDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86 T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h dXRoDQoNCg0K --_000_4E1F6AAD24975D4BA5B16804296739435F793829TK5EX14MBXC283r_ 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 MyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5v c2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRN TCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAu TXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2lu OjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFy DQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250 LWZhbWlseTpDb25zb2xhczt9DQpwLnlpdjM0ODE0OTYxN21zb2FjZXRhdGUsIGxpLnlpdjM0ODE0 OTYxN21zb2FjZXRhdGUsIGRpdi55aXYzNDgxNDk2MTdtc29hY2V0YXRlDQoJe21zby1zdHlsZS1u YW1lOnlpdjM0ODE0OTYxN21zb2FjZXRhdGU7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJ bWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4t bGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCnAueWl2MzQ4MTQ5NjE3bXNvbm9ybWFsLCBsaS55aXYzNDgxNDk2MTdt c29ub3JtYWwsIGRpdi55aXYzNDgxNDk2MTdtc29ub3JtYWwNCgl7bXNvLXN0eWxlLW5hbWU6eWl2 MzQ4MTQ5NjE3bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1y aWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGlu Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNl cmlmIjt9DQpwLnlpdjM0ODE0OTYxN21zb2NocGRlZmF1bHQsIGxpLnlpdjM0ODE0OTYxN21zb2No cGRlZmF1bHQsIGRpdi55aXYzNDgxNDk2MTdtc29jaHBkZWZhdWx0DQoJe21zby1zdHlsZS1uYW1l OnlpdjM0ODE0OTYxN21zb2NocGRlZmF1bHQ7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJ bWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4t bGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCnAueWl2MzQ4MTQ5NjE3bXNvbm9ybWFsMSwgbGkueWl2MzQ4MTQ5NjE3 bXNvbm9ybWFsMSwgZGl2LnlpdjM0ODE0OTYxN21zb25vcm1hbDENCgl7bXNvLXN0eWxlLW5hbWU6 eWl2MzQ4MTQ5NjE3bXNvbm9ybWFsMTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJn aW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0 OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i LCJzZXJpZiI7fQ0KcC55aXYzNDgxNDk2MTdtc29hY2V0YXRlMSwgbGkueWl2MzQ4MTQ5NjE3bXNv YWNldGF0ZTEsIGRpdi55aXYzNDgxNDk2MTdtc29hY2V0YXRlMQ0KCXttc28tc3R5bGUtbmFtZTp5 aXYzNDgxNDk2MTdtc29hY2V0YXRlMTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJn aW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0 OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i LCJzZXJpZiI7fQ0KcC55aXYzNDgxNDk2MTdtc29jaHBkZWZhdWx0MSwgbGkueWl2MzQ4MTQ5NjE3 bXNvY2hwZGVmYXVsdDEsIGRpdi55aXYzNDgxNDk2MTdtc29jaHBkZWZhdWx0MQ0KCXttc28tc3R5 bGUtbmFtZTp5aXYzNDgxNDk2MTdtc29jaHBkZWZhdWx0MTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0K CW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi55aXYzNDgxNDk2MTdtc29oeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLW5hbWU6eWl2MzQ4MTQ5NjE3bXNvaHlwZXJsaW5rO30NCnNwYW4ueWl2MzQ4MTQ5 NjE3bXNvaHlwZXJsaW5rZm9sbG93ZWQNCgl7bXNvLXN0eWxlLW5hbWU6eWl2MzQ4MTQ5NjE3bXNv aHlwZXJsaW5rZm9sbG93ZWQ7fQ0Kc3Bhbi55aXYzNDgxNDk2MTdodG1scHJlZm9ybWF0dGVkY2hh cg0KCXttc28tc3R5bGUtbmFtZTp5aXYzNDgxNDk2MTdodG1scHJlZm9ybWF0dGVkY2hhcjt9DQpz cGFuLnlpdjM0ODE0OTYxN21zb2h5cGVybGluazENCgl7bXNvLXN0eWxlLW5hbWU6eWl2MzQ4MTQ5 NjE3bXNvaHlwZXJsaW5rMTt9DQpzcGFuLnlpdjM0ODE0OTYxN21zb2h5cGVybGlua2ZvbGxvd2Vk MQ0KCXttc28tc3R5bGUtbmFtZTp5aXYzNDgxNDk2MTdtc29oeXBlcmxpbmtmb2xsb3dlZDE7fQ0K c3Bhbi55aXYzNDgxNDk2MTdlbWFpbHN0eWxlMTcxDQoJe21zby1zdHlsZS1uYW1lOnlpdjM0ODE0 OTYxN2VtYWlsc3R5bGUxNzE7fQ0Kc3Bhbi55aXYzNDgxNDk2MTdiYWxsb29udGV4dGNoYXIxDQoJ e21zby1zdHlsZS1uYW1lOnlpdjM0ODE0OTYxN2JhbGxvb250ZXh0Y2hhcjE7fQ0Kc3Bhbi55aXYz NDgxNDk2MTdodG1scHJlZm9ybWF0dGVkY2hhcjENCgl7bXNvLXN0eWxlLW5hbWU6eWl2MzQ4MTQ5 NjE3aHRtbHByZWZvcm1hdHRlZGNoYXIxO30NCnNwYW4ueWl2MzQ4MTQ5NjE3YmFsbG9vbnRleHRj aGFyDQoJe21zby1zdHlsZS1uYW1lOnlpdjM0ODE0OTYxN2JhbGxvb250ZXh0Y2hhcjt9DQpzcGFu LnlpdjM0ODE0OTYxN2VtYWlsc3R5bGUzNw0KCXttc28tc3R5bGUtbmFtZTp5aXYzNDgxNDk2MTdl bWFpbHN0eWxlMzc7fQ0KcC55aXYzNDgxNDk2MTdtc29ub3JtYWwyLCBsaS55aXYzNDgxNDk2MTdt c29ub3JtYWwyLCBkaXYueWl2MzQ4MTQ5NjE3bXNvbm9ybWFsMg0KCXttc28tc3R5bGUtbmFtZTp5 aXYzNDgxNDk2MTdtc29ub3JtYWwyOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQpzcGFuLnlpdjM0ODE0OTYxN21zb2h5cGVybGluazINCgl7bXNvLXN0eWxlLW5h bWU6eWl2MzQ4MTQ5NjE3bXNvaHlwZXJsaW5rMjsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi55aXYzNDgxNDk2MTdtc29oeXBlcmxpbmtmb2xsb3dlZDIN Cgl7bXNvLXN0eWxlLW5hbWU6eWl2MzQ4MTQ5NjE3bXNvaHlwZXJsaW5rZm9sbG93ZWQyOw0KCWNv bG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAueWl2MzQ4MTQ5NjE3 bXNvYWNldGF0ZTIsIGxpLnlpdjM0ODE0OTYxN21zb2FjZXRhdGUyLCBkaXYueWl2MzQ4MTQ5NjE3 bXNvYWNldGF0ZTINCgl7bXNvLXN0eWxlLW5hbWU6eWl2MzQ4MTQ5NjE3bXNvYWNldGF0ZTI7DQoJ bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsN Cglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4ueWl2MzQ4MTQ5 NjE3aHRtbHByZWZvcm1hdHRlZGNoYXIyDQoJe21zby1zdHlsZS1uYW1lOnlpdjM0ODE0OTYxN2h0 bWxwcmVmb3JtYXR0ZWRjaGFyMjsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2Vy aWYiO30NCnAueWl2MzQ4MTQ5NjE3bXNvbm9ybWFsMywgbGkueWl2MzQ4MTQ5NjE3bXNvbm9ybWFs MywgZGl2LnlpdjM0ODE0OTYxN21zb25vcm1hbDMNCgl7bXNvLXN0eWxlLW5hbWU6eWl2MzQ4MTQ5 NjE3bXNvbm9ybWFsMzsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6 MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglm b250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7 fQ0KcC55aXYzNDgxNDk2MTdtc29jaHBkZWZhdWx0MiwgbGkueWl2MzQ4MTQ5NjE3bXNvY2hwZGVm YXVsdDIsIGRpdi55aXYzNDgxNDk2MTdtc29jaHBkZWZhdWx0Mg0KCXttc28tc3R5bGUtbmFtZTp5 aXYzNDgxNDk2MTdtc29jaHBkZWZhdWx0MjsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCglt YXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1s ZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iLCJzZXJpZiI7fQ0KcC55aXYzNDgxNDk2MTdtc29ub3JtYWwxMSwgbGkueWl2MzQ4MTQ5NjE3 bXNvbm9ybWFsMTEsIGRpdi55aXYzNDgxNDk2MTdtc29ub3JtYWwxMQ0KCXttc28tc3R5bGUtbmFt ZTp5aXYzNDgxNDk2MTdtc29ub3JtYWwxMTsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iLCJzZXJpZiI7fQ0Kc3Bhbi55aXYzNDgxNDk2MTdtc29oeXBlcmxpbmsxMQ0KCXttc28tc3R5 bGUtbmFtZTp5aXYzNDgxNDk2MTdtc29oeXBlcmxpbmsxMTsNCgljb2xvcjpibHVlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi55aXYzNDgxNDk2MTdtc29oeXBlcmxpbmtmb2xs b3dlZDExDQoJe21zby1zdHlsZS1uYW1lOnlpdjM0ODE0OTYxN21zb2h5cGVybGlua2ZvbGxvd2Vk MTE7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC55aXYz NDgxNDk2MTdtc29hY2V0YXRlMTEsIGxpLnlpdjM0ODE0OTYxN21zb2FjZXRhdGUxMSwgZGl2Lnlp djM0ODE0OTYxN21zb2FjZXRhdGUxMQ0KCXttc28tc3R5bGUtbmFtZTp5aXYzNDgxNDk2MTdtc29h Y2V0YXRlMTE7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO30NCnNwYW4ueWl2 MzQ4MTQ5NjE3ZW1haWxzdHlsZTE3MTENCgl7bXNvLXN0eWxlLW5hbWU6eWl2MzQ4MTQ5NjE3ZW1h aWxzdHlsZTE3MTE7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6 IzFGNDk3RDt9DQpzcGFuLnlpdjM0ODE0OTYxN2JhbGxvb250ZXh0Y2hhcjExDQoJe21zby1zdHls ZS1uYW1lOnlpdjM0ODE0OTYxN2JhbGxvb250ZXh0Y2hhcjExOw0KCWZvbnQtZmFtaWx5OiJBcmlh bCIsInNhbnMtc2VyaWYiO30NCnNwYW4ueWl2MzQ4MTQ5NjE3aHRtbHByZWZvcm1hdHRlZGNoYXIx MQ0KCXttc28tc3R5bGUtbmFtZTp5aXYzNDgxNDk2MTdodG1scHJlZm9ybWF0dGVkY2hhcjExOw0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC55aXYzNDgxNDk2MTdtc29jaHBkZWZhdWx0 MTEsIGxpLnlpdjM0ODE0OTYxN21zb2NocGRlZmF1bHQxMSwgZGl2LnlpdjM0ODE0OTYxN21zb2No cGRlZmF1bHQxMQ0KCXttc28tc3R5bGUtbmFtZTp5aXYzNDgxNDk2MTdtc29jaHBkZWZhdWx0MTE7 DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4ueWl2MzQ4 MTQ5NjE3YmFsbG9vbnRleHRjaGFyMg0KCXttc28tc3R5bGUtbmFtZTp5aXYzNDgxNDk2MTdiYWxs b29udGV4dGNoYXIyOw0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO30NCnNwYW4u eWl2MzQ4MTQ5NjE3ZW1haWxzdHlsZTM3MQ0KCXttc28tc3R5bGUtbmFtZTp5aXYzNDgxNDk2MTdl bWFpbHN0eWxlMzcxOw0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0KCWNvbG9y OiMwMDIwNjA7fQ0Kc3Bhbi5FbWFpbFN0eWxlNTINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt cmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMDAy MDYwO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRl eHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxs b29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0 O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4w aW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9 InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDIwNjAiPlNvcnJ5LCBJIHNo b3VsZCBoYXZlIGJlZW4gbW9yZSBwcmVjaXNlLiZuYnNwOyBUaGUgQ29yZSBzcGVjIGRvZXNu4oCZ dCBkZWZpbmUgaG93IHRvIHRyYW5zbWl0IHRoZXNlIGZpZWxkcyBpbiB0aGUgV1dXLUF1dGhlbnRp Y2F0ZSByZXNwb25zZSBoZWFkZXIgZmllbGQuJm5ic3A7IFRoZSBCZWFyZXINCiBzcGVjIGRvZXMu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERG IDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+IFdpbGxpYW0gTWlsbHMgW21haWx0bzp3bWlsbHNAeWFob28taW5j LmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBKYW51YXJ5IDAzLCAyMDEyIDEyOjE0 IFBNPGJyPg0KPGI+VG86PC9iPiBNaWtlIEpvbmVzOyBKdWxpYW4gUmVzY2hrZTxicj4NCjxiPkNj OjwvYj4gTWFyayBOb3R0aW5naGFtOyBCYXJyeSBMZWliYTsgT0F1dGggV0c8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gYXV0aC1wYXJhbSBzeW50YXgsIHdhczogT0sgdG8gcG9z dCBPQXV0aCBCZWFyZXIgZHJhZnQgMTU/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6YmxhY2siPjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtb2F1dGgtdjItMjIjc2VjdGlvbi0xMS4yLjIiPmh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtdjItMjIjc2VjdGlvbi0xMS4yLjI8L2E+DQogY2VydGFp bmx5IGhhcyB0aGVzZSBhcyBwcmVkZWZpbmVkIHJlZ2lzdGVyZWQgcGFyYW1ldGVycy4mbmJzcDsg SWYgdGhlIGRlZmluaXRpb24gdGhlcmUgaXNuJ3Qgc3Ryb25nIGVub3VnaCwgb3IgaW4gdGhhdCBz cGVjLCB3ZSBzaG91bGQgZml4IHRoYXQuJm5ic3A7IFRoYXQgaXMgd2hlcmUgdGhlc2Ugc2hvdWxk IGJlIGRlZmluZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTQuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJs YWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpj ZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj4NCjxociBzaXplPSIxIiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+DQo8L3Nw YW4+PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQ7YmFja2dyb3VuZDp3aGl0ZSI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPiBNaWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3Nv ZnQuY29tIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0Ozxicj4NCjxiPlRvOjwv Yj4gV2lsbGlhbSBNaWxscyAmbHQ7PGEgaHJlZj0ibWFpbHRvOndtaWxsc0B5YWhvby1pbmMuY29t Ij53bWlsbHNAeWFob28taW5jLmNvbTwvYT4mZ3Q7OyBKdWxpYW4gUmVzY2hrZSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmp1bGlhbi5yZXNjaGtlQGdteC5kZSI+anVsaWFuLnJlc2Noa2VAZ214LmRlPC9h PiZndDsNCjxicj4NCjxiPkNjOjwvYj4gTWFyayBOb3R0aW5naGFtICZsdDs8YSBocmVmPSJtYWls dG86bW5vdEBtbm90Lm5ldCI+bW5vdEBtbm90Lm5ldDwvYT4mZ3Q7OyBCYXJyeSBMZWliYSAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmJhcnJ5bGVpYmFAY29tcHV0ZXIub3JnIj5iYXJyeWxlaWJhQGNvbXB1 dGVyLm9yZzwvYT4mZ3Q7OyBPQXV0aCBXRyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYu b3JnIj5vYXV0aEBpZXRmLm9yZzwvYT4mZ3Q7DQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwg SmFudWFyeSAzLCAyMDEyIDEyOjAwIFBNPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbT0FVVEgt V0ddIGF1dGgtcGFyYW0gc3ludGF4LCB3YXM6IE9LIHRvIHBvc3QgT0F1dGggQmVhcmVyIGRyYWZ0 IDE1Pzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXYgaWQ9InlpdjM0ODE0OTYxNyI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Y29sb3I6IzAwMjA2MCI+VGhlIGNvcmUgc3BlYyBkb2VzbuKAmXQgaW5jbHVk ZSB0aGVzZSBwYXJhbWV0ZXJzLjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xv cjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPiBXaWxsaWFtIE1p bGxzDQo8YSBocmVmPSJtYWlsdG86W21haWx0bzp3bWlsbHNAeWFob28taW5jLmNvbV0iPlttYWls dG86d21pbGxzQHlhaG9vLWluYy5jb21dPC9hPiA8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwg SmFudWFyeSAwMywgMjAxMiAxMjowMCBQTTxicj4NCjxiPlRvOjwvYj4gTWlrZSBKb25lczsgSnVs aWFuIFJlc2Noa2U8YnI+DQo8Yj5DYzo8L2I+IE1hcmsgTm90dGluZ2hhbTsgQmFycnkgTGVpYmE7 IE9BdXRoIFdHPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIGF1dGgtcGFyYW0g c3ludGF4LCB3YXM6IE9LIHRvIHBvc3QgT0F1dGggQmVhcmVyIGRyYWZ0IDE1Pzwvc3Bhbj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3Vu ZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdDtj b2xvcjpibGFjayI+V2h5IGlzIEJlYXJlciBkZWFsaW5nIHdpdGggdGhpcyBhdCBhbGw/Jm5ic3A7 IHRoZSBCTkYgZm9yIHRoYXQgc3R1ZmYgc2hvdWxkIGJlIHBhcnQgb2YgdGhlIGNvcmUgc3BlYywg YW5kIGFkZGl0aW9uYWwgdmFsdWVzIHBlcmhhcHMgZGVmaW5lZCBpbiBCZWFyZXIuPC9zcGFuPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTQuMHB0O2NvbG9yOmJsYWNrIj4mbmJz cDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFs aWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlIj4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj4NCjxociBzaXplPSIx IiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+DQo8L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6Ymxh Y2siPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpi bGFjayI+IE1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jv c29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+ Jmd0Ozxicj4NCjxiPlRvOjwvYj4gV2lsbGlhbSBNaWxscyAmbHQ7PGEgaHJlZj0ibWFpbHRvOndt aWxsc0B5YWhvby1pbmMuY29tIiB0YXJnZXQ9Il9ibGFuayI+d21pbGxzQHlhaG9vLWluYy5jb208 L2E+Jmd0OzsgSnVsaWFuIFJlc2Noa2UgJmx0OzxhIGhyZWY9Im1haWx0bzpqdWxpYW4ucmVzY2hr ZUBnbXguZGUiIHRhcmdldD0iX2JsYW5rIj5qdWxpYW4ucmVzY2hrZUBnbXguZGU8L2E+Jmd0Ow0K PGJyPg0KPGI+Q2M6PC9iPiBNYXJrIE5vdHRpbmdoYW0gJmx0OzxhIGhyZWY9Im1haWx0bzptbm90 QG1ub3QubmV0IiB0YXJnZXQ9Il9ibGFuayI+bW5vdEBtbm90Lm5ldDwvYT4mZ3Q7OyBCYXJyeSBM ZWliYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJhcnJ5bGVpYmFAY29tcHV0ZXIub3JnIiB0YXJnZXQ9 Il9ibGFuayI+YmFycnlsZWliYUBjb21wdXRlci5vcmc8L2E+Jmd0OzsgT0F1dGggV0cgJmx0Ozxh IGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoQGlldGYu b3JnPC9hPiZndDsNCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBKYW51YXJ5IDMsIDIwMTIg MTE6NDYgQU08YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtPQVVUSC1XR10gYXV0aC1wYXJhbSBz eW50YXgsIHdhczogT0sgdG8gcG9zdCBPQXV0aCBCZWFyZXIgZHJhZnQgMTU/PC9zcGFuPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 IGlkPSJ5aXYzNDgxNDk2MTciPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj5UaGlzIGlzIGFib3V0IHRoZSBzeW50YXggZm9yIHRo ZSBzY29wZSwgZXJyb3IsIGFuZCBlcnJvcl9kZXNjcmlwdGlvbiBwYXJhbWV0ZXJzLiZuYnNwOyBU aGUgcGVydGluZW50IHRleHQgZnJvbQ0KPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi1vYXV0aC12Mi1iZWFyZXItMTUjc2VjdGlvbi0zIiB0YXJnZXQ9Il9ibGFu ayI+DQpTZWN0aW9uIDMgPC9hPmlzOjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNw YW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDsm bmJzcDsgUHJvZHVjZXJzIG9mICZxdW90O3Njb3BlJnF1b3Q7IHN0cmluZ3MgTVVTVCBOT1QgdXNl IGNoYXJhY3RlcnMgb3V0c2lkZSB0aGUgc2V0PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9 IkVOIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7ICV4 MjEgLyAleDIzLTVCIC8gJXg1RC03RSBmb3IgcmVwcmVzZW50aW5nIHRoZSBzY29wZSB2YWx1ZXMg YW5kICV4MjA8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgZm9yIHRoZSBkZWxpbWl0ZXIuJm5i c3A7IFByb2R1Y2VycyBvZiAmcXVvdDtlcnJvciZxdW90OyBhbmQgJnF1b3Q7ZXJyb3JfZGVzY3Jp cHRpb24mcXVvdDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgc3RyaW5ncyBNVVNUIE5PVCB1 c2UgY2hhcmFjdGVycyBvdXRzaWRlIHRoZSBzZXQgJXgyMC0yMSAvICV4MjMtNUIgLzwvc3Bhbj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6 YmxhY2siPiZuYnNwOyZuYnNwOyAleDVELTdFIGZvciByZXByZXNlbnRpbmcgdGhlc2UgdmFsdWVz LiZuYnNwOyBQcm9kdWNlcnMgb2YgJnF1b3Q7ZXJyb3ItdXJpJnF1b3Q7PC9zcGFuPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7IHN0cmluZ3MgTVVTVCBOT1QgdXNlIGNoYXJhY3RlcnMgb3V0c2lkZSB0aGUg c2V0ICV4MjEgLyAleDIzLTVCIC88L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4iIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgJXg1RC03RSBm b3IgcmVwcmVzZW50aW5nIHRoZXNlIHZhbHVlcy4mbmJzcDsgRnVydGhlcm1vcmUsICZxdW90O2Vy cm9yLXVyaSZxdW90Ozwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBzdHJpbmdzIE1VU1QgY29u Zm9ybSB0byB0aGUgVVJJLVJlZmVyZW5jZSBzeW50YXguJm5ic3A7IEluIGFsbCB0aGVzZTwvc3Bh bj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29s b3I6YmxhY2siPiZuYnNwOyZuYnNwOyBjYXNlcywgbm8gY2hhcmFjdGVyIHF1b3Rpbmcgd2lsbCBv Y2N1ciwgYXMgc2VuZGVycyBhcmUgcHJvaGliaXRlZDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBs YW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNw OyBmcm9tIHVzaW5nIHRoZSAlNUMgKCdcJykgY2hhcmFjdGVyLjwvc3Bhbj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IENoZWVycyw8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8L3NwYW4+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3Vu ZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj4gV2lsbGlhbSBN aWxscw0KPGEgaHJlZj0ibWFpbHRvOlttYWlsdG86d21pbGxzQHlhaG9vLWluYy5jb21dIiB0YXJn ZXQ9Il9ibGFuayI+W21haWx0bzp3bWlsbHNAeWFob28taW5jLmNvbV08L2E+DQo8YnI+DQo8Yj5T ZW50OjwvYj4gVHVlc2RheSwgSmFudWFyeSAwMywgMjAxMiAxMTozNiBBTTxicj4NCjxiPlRvOjwv Yj4gTWlrZSBKb25lczsgSnVsaWFuIFJlc2Noa2U8YnI+DQo8Yj5DYzo8L2I+IE1hcmsgTm90dGlu Z2hhbTsgQmFycnkgTGVpYmE7IE9BdXRoIFdHPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FV VEgtV0ddIGF1dGgtcGFyYW0gc3ludGF4LCB3YXM6IE9LIHRvIHBvc3QgT0F1dGggQmVhcmVyIGRy YWZ0IDE1Pzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdDtjb2xvcjpibGFj ayI+SXMgYWxsIHRoaXMgb25seSBhcm91bmQgdGhlIHNjb3BlIHBhcmFtZXRlcj8mbmJzcDsgTXkg bWFpbCBjaXRlZCBiZWxvdyBpcyB3aXRoIHJlZ2FyZHMgdG8gdGhlIGNoYXJhY3RlciBzZXQgZm9y IGEgdmFsaWQgc2NvcGUgcGFyYW1ldGVyLCB3aGljaCB3ZSBzaG91bGQgYmUgYWJsZSB0byBkZWZp bmUgYW5kDQogdGhlbiBsZWFuIG9uIHRoZSBIVFRQYmlzIHNwZWMgZm9yIHRoZSBhY3R1YWwgcGFy YW1ldGVyIHN5bnRheC48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxNC4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVy IiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+DQo8aHIgc2l6ZT0iMSIgd2lkdGg9IjEw MCUiIGFsaWduPSJjZW50ZXIiPg0KPC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQiPg0KPGRpdiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPiBNaWtlIEpvbmVzICZsdDs8YSBocmVmPSJt YWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+TWljaGFl bC5Kb25lc0BtaWNyb3NvZnQuY29tPC9hPiZndDs8YnI+DQo8Yj5Ubzo8L2I+IEp1bGlhbiBSZXNj aGtlICZsdDs8YSBocmVmPSJtYWlsdG86anVsaWFuLnJlc2Noa2VAZ214LmRlIiB0YXJnZXQ9Il9i bGFuayI+anVsaWFuLnJlc2Noa2VAZ214LmRlPC9hPiZndDsNCjxicj4NCjxiPkNjOjwvYj4gTWFy ayBOb3R0aW5naGFtICZsdDs8YSBocmVmPSJtYWlsdG86bW5vdEBtbm90Lm5ldCIgdGFyZ2V0PSJf YmxhbmsiPm1ub3RAbW5vdC5uZXQ8L2E+Jmd0OzsgQmFycnkgTGVpYmEgJmx0OzxhIGhyZWY9Im1h aWx0bzpiYXJyeWxlaWJhQGNvbXB1dGVyLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmJhcnJ5bGVpYmFA Y29tcHV0ZXIub3JnPC9hPiZndDs7IE9BdXRoIFdHICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGhA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aEBpZXRmLm9yZzwvYT4mZ3Q7DQo8YnI+DQo8 Yj5TZW50OjwvYj4gRnJpZGF5LCBEZWNlbWJlciAzMCwgMjAxMSAzOjE5IFBNPGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIGF1dGgtcGFyYW0gc3ludGF4LCB3YXM6IE9LIHRvIHBv c3QgT0F1dGggQmVhcmVyIGRyYWZ0IDE1Pzxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPjxicj4NCkkgZGlkIGFscmVhZHkgYmFjayB0aGUgc3RhdGVtZW50IHRoYXQgdGhpcyBp cyB0aGUgd29ya2luZyBncm91cCBjb25zZW5zdXMgd2l0aCB0aGUgZS1tYWlscyBhdHRhY2hlZCBp biB0aGlzIG5vdGUgc2VudCB0byB5b3Ugb24gRGVjZW1iZXIgMTIsIDIwMTE6PGJyPg0KJm5ic3A7 IC0gPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1 cnJlbnQvbXNnMDgwNDIuaHRtbCI+aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2Vi L29hdXRoL2N1cnJlbnQvbXNnMDgwNDIuaHRtbDwvYT48YnI+DQo8YnI+DQpCdXQgc2luY2UgdGhh dCBhcHBhcmVudGx5IHdhc24ndCBjb252aW5jaW5nIHRvIHlvdSB0aGF0IHRoaXMgd29ya2luZyBn cm91cCBkZWNpc2lvbiByZXByZXNlbnRzIG1vcmUgdGhhbiAmcXVvdDtqdXN0IG1lIGRpc2FncmVl aW5nIHdpdGggeW91JnF1b3Q7LCBoZXJlIGFyZSByZWZlcmVuY2VzIHRvIGluZGl2aWR1YWwgbWVz c2FnZXMgcmVmZXJlbmNlZCBpbiB0aGUgYWJvdmUgZS1tYWlsOjxicj4NCiZuYnNwOyAtIEVyYW4g SGFtbWVyLUxhaGF2OiA8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93 ZWIvb2F1dGgvY3VycmVudC9tc2cwNzY5OC5odG1sIj4NCmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFp bC1hcmNoaXZlL3dlYi9vYXV0aC9jdXJyZW50L21zZzA3Njk4Lmh0bWw8L2E+PGJyPg0KJm5ic3A7 IC0gSm9obiBCcmFkbGV5OiZuYnNwOyA8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL21haWwt YXJjaGl2ZS93ZWIvb2F1dGgvY3VycmVudC9tc2cwNzY5OS5odG1sIj4NCmh0dHA6Ly93d3cuaWV0 Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vYXV0aC9jdXJyZW50L21zZzA3Njk5Lmh0bWw8L2E+PGJy Pg0KJm5ic3A7IC0gV2lsbGlhbSBNaWxsczombmJzcDsgPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRm Lm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMDc3MDAuaHRtbCI+DQpodHRw Oi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgvY3VycmVudC9tc2cwNzcwMC5o dG1sPC9hPjxicj4NCiZuYnNwOyAtIE1pa2UgSm9uZXM6Jm5ic3A7IDxhIGhyZWY9Imh0dHA6Ly93 d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vYXV0aC9jdXJyZW50L21zZzA3NzAxLmh0bWwi Pg0KaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNn MDc3MDEuaHRtbDwvYT48YnI+DQombmJzcDsgLSBQaGlsIEh1bnQ6Jm5ic3A7IDxhIGhyZWY9Imh0 dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vYXV0aC9jdXJyZW50L21zZzA3NzAy Lmh0bWwiPg0KaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1cnJl bnQvbXNnMDc3MDIuaHRtbDwvYT48YnI+DQombmJzcDsgLSBKdXN0aW4gUmljaGVyOiZuYnNwOyA8 YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgvY3VycmVu dC9tc2cwNzY5Mi5odG1sIj4NCmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9v YXV0aC9jdXJyZW50L21zZzA3NjkyLmh0bWw8L2E+PGJyPg0KPGJyPg0KQXMgZm9yIHlvdXIgYXNz ZXJ0aW9uIHRoYXQgdGhlIHNwZWNzIGFyZSBpbiBjb25mbGljdCwgeWVzLCB0aGUgQmVhcmVyIHNw ZWMgaW5jbHVkZXMgYSBkaWZmZXJlbnQgZGVjaXNpb24gdGhhbiBhIFJFQ09NTUVOREVEIGNsYXVz ZSBpbiB0aGUgSFRUUGJpcyBzcGVjICh3aGljaCB3YXMgYWRkZWQgYWZ0ZXIgdGhlIEJlYXJlciB0 ZXh0IHdhcyBhbHJlYWR5IGluIHBsYWNlKS4mbmJzcDsgSG93ZXZlciwgaXQgaXMgbm90IHZpb2xh dGluZyBhbnkgTVVTVCBjbGF1c2VzDQogaW4gdGhlIEhUVFBiaXMgc3BlYy4mbmJzcDsgR2l2ZW4g dGhhdCBubyBNVVNUUyBhcmUgdmlvbGF0ZWQsIEkgZG9uJ3Qgc2VlIGl0IG1hbmRhdG9yeSBmb3Ig dGhpcyB0ZW5zaW9uIHRvIGJlIHJlc29sdmVkIGluIGZhdm9yIG9mIG9uZSBzcGVjIG9yIHRoZSBv dGhlciBpbiBvcmRlciBmb3IgYm90aCB0byBiZSBhcHByb3ZlZCBhcyBSRkNzLiZuYnNwOyBJIGxv b2sgZm9yd2FyZCB0byBzZWVpbmcgdGhhdCBoYXBwZW4gc29vbiBpbiBib3RoIGNhc2VzIChhbmQg Zm9yIHRoZQ0KIE9BdXRoIGNvcmUgc3BlYyBhcyB3ZWxsKS48YnI+DQo8YnI+DQombmJzcDsmbmJz cDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJz cDsmbmJzcDsgQmVzdCB3aXNoZXMsPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNw OyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8YnI+ DQo8YnI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IEp1bGlhbiBSZXNj aGtlIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmp1bGlhbi5yZXNjaGtlQGdteC5kZSIgdGFyZ2V0 PSJfYmxhbmsiPmp1bGlhbi5yZXNjaGtlQGdteC5kZTwvYT5dDQo8YnI+DQpTZW50OiBGcmlkYXks IERlY2VtYmVyIDMwLCAyMDExIDI6MjYgQU08YnI+DQpUbzogTWlrZSBKb25lczxicj4NCkNjOiBC YXJyeSBMZWliYTsgTWFyayBOb3R0aW5naGFtOyBPQXV0aCBXRzxicj4NClN1YmplY3Q6IFJlOiBh dXRoLXBhcmFtIHN5bnRheCwgd2FzOiBbT0FVVEgtV0ddIE9LIHRvIHBvc3QgT0F1dGggQmVhcmVy IGRyYWZ0IDE1Pzxicj4NCjxicj4NCk9uIDIwMTEtMTItMjkgMjI6MTgsIE1pa2UgSm9uZXMgd3Jv dGU6PGJyPg0KJmd0OyBZb3UgcHJvcG9zZWQsIEp1bGlhbiAmcXVvdDszLiBEbyBub3Qgc3BlY2lm eSB0aGUgQUJORi4gVGhlIEFCTkYgb2YgdGhlIFdXVy1BdXRoZW50aWNhdGUgaXMgZGVmaW5lZCBp biBIVFRQYmlzLiBKdXN0IHN0YXRlIHRoZSBuYW1lcyBvZiB0aGUgcGFyYW1ldGVycywgdGhlaXIg c3ludGF4ICphZnRlciogcGFyc2luZyBhbmQgdGhlaXIgc2VtYW50aWNzLiZxdW90Ozxicj4NCiZn dDs8YnI+DQomZ3Q7IEFib3V0IHNvbWUgb2YgTWFyayBOb3R0aW5naGFtJ3MgY29tbWVudHMsIEJh cnJ5IHdyb3RlICZxdW90O0xldCBtZSBwb2ludCBvdXQgdGhhdCAmcXVvdDt0aGlzIHJlcHJlc2Vu dHMgd29ya2luZy1ncm91cCBjb25zZW5zdXMmcXVvdDsgaXMgbm90IGFsd2F5cyBhIHZhbGlkIHJl c3BvbnNlLiZuYnNwOyBJZiB0aGUgd29ya2luZyBncm91cCBoYXMgYWN0dWFsbHkgY29uc2lkZXJl ZCB0aGUgKmlzc3VlKiwgdGhhdCBtaWdodCBiZSBPSy4mbmJzcDsgQnV0IGlmIHRoZXJlJ3MgY29u c2Vuc3VzIGZvcg0KIHRoZSBjaG9zZW4gc29sdXRpb24gYW5kIHNvbWVvbmUgYnJpbmdzIHVwIGEg Km5ldyogaXNzdWUgd2l0aCBpdCwgdGhhdCBpc3N1ZSBuZWVkcyB0byBiZSBhZGRyZXNzZWQgYW5l dy4mcXVvdDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBSZWxhdGl2ZSB0byB0aGVzZSB0d28gc3RhdGVt ZW50cywgSSBiZWxpZXZlIHRoYXQgSSBzaG91bGQgcmVtYXJrIGF0IHRoaXMgcG9pbnQgdGhhdCB5 b3VyIHByb3Bvc2VkIHNlbWFudGljcyBvZiBvbmx5IGNvbnNpZGVyaW5nIHRoZSBzeW50YXggYWZ0 ZXIgcG90ZW50aWFsIHF1b3Rpbmcgd2FzIGV4cGxpY2l0bHkgY29uc2lkZXJlZCBlYXJsaWVyIGJ5 IHRoZSB3b3JraW5nIGdyb3VwIGFuZCByZWplY3RlZC4mbmJzcDsgVGhlIGNvbnNlbnN1cywgaW5z dGVhZCwNCiB3YXMgZm9yIHRoZSBwcmVzZW50ICZxdW90O25vIHF1b3Rpbmcgd2lsbCBvY2N1ciBm b3IgbGVnYWwgaW5wdXRzJnF1b3Q7IHNlbWFudGljcy48YnI+DQo8YnI+DQpJdCB3b3VsZCBiZSBo ZWxwZnVsIGlmIHlvdSBjb3VsZCBiYWNrIHRoaXMgc3RhdGVtZW50IHdpdGggcG9pbnRlcnMgdG8g bWFpbHMuIEFzIGZhciBhcyBJIGNhbiB0ZWxsIGl0J3MganVzdCB5b3UgZGlzYWdyZWVpbmcgd2l0 aCBtZS48YnI+DQo8YnI+DQpCYWNrIHRvIHRoZSBmYWN0czo8YnI+DQo8YnI+DQphKSB0aGUgYmVh cmVyIHNwZWMgZGVmaW5lcyBhbiBIVFRQIGF1dGhlbnRpY2F0aW9uIHNjaGVtZSwgYW5kIG5vcm1h dGl2ZWx5IHJlZmVycyB0byBIVFRQYmlzIFBhcnQ3IGZvciB0aGF0PGJyPg0KPGJyPg0KYikgSFRU UGJpcyByZWNvbW1lbmRzIG5ldyBzY2hlbWUgZGVmaW5pdGlvbnMgbm90IHRvIGhhdmUgdGhlaXIg b3duIEFCTkYsIGFzIHRoZSBoZWFkZXIgZmllbGQgc3ludGF4IGlzIGRlZmluZWQgYnkgSFRUUGJp cywgbm90IHRoZSBpbmRpdmlkdWFsIHNjaGVtZTxicj4NCjxicj4NCmMpIHRoZSBiZWFyZXIgc3Bl YyBkZWZpbmVzIGl0J3Mgb3duIEFCTkYgbmV2ZXJ0aGVsZXNzPGJyPg0KPGJyPg0KU28gdGhlIHR3 byBzcGVjcyBhcmUgaW4gY29uZmxpY3QsIGFuZCB3ZSBzaG91bGQgcmVzb2x2ZSB0aGUgY29uZmxp Y3Qgb25lIHdheSBvciB0aGUgb3RoZXIuPGJyPg0KPGJyPg0KSWYgeW91IGRpc2FncmVlIHdpdGgg dGhlIHJlY29tbWVuZGF0aW9uIGluIEhUVFBiaXMsIHRoZW4geW91IHJlYWxseSByZWFsbHkgc2hv dWxkIGNvbWUgb3ZlciB0byBIVFRQYmlzIFdHIGFuZCBhcmd1ZSB5b3VyIHBvaW50IG9mIHZpZXcu PGJyPg0KPGJyPg0KSWYgeW91IGFncmVlIHdpdGggaXQsIGJ1dCB0aGluayB0aGF0IHRoZSBiZWFy ZXIgc3BlYyBjYW4ndCBmb2xsb3cgdGhlIHJlY29tbWVuZGF0aW9uLCB0aGVuIGl0IHdvdWxkIGJl IGdvb2QgdG8gZXhwbGFpbiB0aGUgcmVhc29uaW5nIChvcHRpbWFsbHkgaW4gdGhlIHNwZWMpLjxi cj4NCjxicj4NCklmIHlvdSBhZ3JlZSB3aXRoIGl0LCBhbmQgdGhpbmsgdGhlIGJlYXJlciBzcGVj ICpjb3VsZCogZm9sbG93IGl0LCB0aGVuLi4uIGNoYW5nZSBpdCwgYnkgYWxsIG1lYW5zLjxicj4N Cjxicj4NCkFueXdheSwgaWYgdGhpcyBpc3N1ZSBpc24ndCByZXNvbHZlZCBiZWZvcmUgSUVURiBM QyB0aGVuIGl0IHdpbGwgYmUgcmFpc2VkIGFnYWluIGF0IHRoYXQgdGltZS48YnI+DQo8YnI+DQo8 YnI+DQomZ3Q7IEkgYmVsaWV2ZSB0aGF0IGluIHRoZSBOZXcgWWVhciB0aGUgY2hhaXJzIGFuZCBh cmVhIGRpcmVjdG9ycyB3aWxsIG5lZWQgdG8gZGVjaWRlIGhvdyB0byBwcm9jZWVkIG9uIHRoaXMg aXNzdWUuJm5ic3A7IChUaGUgd29ya2luZyBncm91cCBjb25zZW5zdXMsIGFzIEkgc2VlIGl0LCBp cyBhbHJlYWR5IGJvdGggd2VsbC1pbmZvcm1lZCBhbmQgY2xlYXIgb24gdGhpcyBwb2ludCwgYnV0 IEkgdW5kZXJzdGFuZCB0aGF0IHRoYXQncyBub3QgdGhlIG9ubHkgY29uc2lkZXJhdGlvbi4pJm5i c3A7DQogSXQgd291bGQgYmUgZ29vZCB0byBzZWUgdGhlIHNwZWMgZmluaXNoZWQgc2hvcnRseS48 YnI+DQomZ3Q7IC4uLjxicj4NCjxicj4NCkJlc3QgcmVnYXJkcywgSnVsaWFuPGJyPg0KPGJyPg0K PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFu ayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_4E1F6AAD24975D4BA5B16804296739435F793829TK5EX14MBXC283r_-- From wmills@yahoo-inc.com Tue Jan 3 12:38:05 2012 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 09C4C11E8106 for ; Tue, 3 Jan 2012 12:38:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.935 X-Spam-Level: X-Spam-Status: No, score=-16.935 tagged_above=-999 required=5 tests=[AWL=0.663, 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 kajT1Ut0W9JI for ; Tue, 3 Jan 2012 12:38:03 -0800 (PST) Received: from nm8-vm2.bullet.mail.ne1.yahoo.com (nm8-vm2.bullet.mail.ne1.yahoo.com [98.138.90.156]) by ietfa.amsl.com (Postfix) with SMTP id 4D30711E80B6 for ; Tue, 3 Jan 2012 12:37:49 -0800 (PST) Received: from [98.138.90.48] by nm8.bullet.mail.ne1.yahoo.com with NNFMP; 03 Jan 2012 20:37:48 -0000 Received: from [98.138.226.165] by tm1.bullet.mail.ne1.yahoo.com with NNFMP; 03 Jan 2012 20:37:48 -0000 Received: from [127.0.0.1] by omp1066.mail.ne1.yahoo.com with NNFMP; 03 Jan 2012 20:37:48 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 844241.64201.bm@omp1066.mail.ne1.yahoo.com Received: (qmail 92033 invoked by uid 60001); 3 Jan 2012 20:37:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1325623068; bh=LDSJmXroyS6g7SzP3J9ZnKDq140WLIc2o8IH9wuRAf0=; 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=kKPuroCzrtqAMQIEd42C3+BUX5YW0ccjQvW85/LJg7/4WripzFX1JX/iUDFaffjcgQWsKrW0ncUNEDxs4qG+2FCAoi0WYJaVUNrHnvVgGdW1aU0xN7JR5pBcDxofFw2HkWm/7ZG2P8vs4MQXE3EEPfZXMmnK4KrfXLL6TJyXtng= 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=W8FtcXMtGHXJw1yREgupy+GsWiepLb1mO5Qp/daaQvi1qWj9qFCytqedd+52EMExUpvw+YQhePZiQIPTY/lEuyfoB/s3L79ReKrJ2FeWxjb7IlVkn12UKK7SqVjUa+ghLdh+23qNK2nNTT++DSuaOsUo7K4N5Cjmmd0xpDc81VA=; X-YMail-OSG: lDZlp8kVM1nj5QhZ1_fyY5AYikLH232ajITpR7uhcobnJsM SiZh4FBbMgC6U4I41_cZEXvGTPVwePHuVkqwxL9n8ccGCkASEK8nDJnvRxfD IBDcHEbHCmmHwcKKEQlCeY_3L4XEHVOZQV944.xj0FRKsZAomJxkAZMWrmbk VQqFH9OckD2G5mFObHdUBBPtXXXtVyr74DJjWe_0jXuOSlCyol2mXnEhomtw GsMYg6U9IJVBtXB1Qrzett0cfTEqyiS6wFm9uWlBETXpnyn0x3gT8H7tL.R7 OSJSTdJey1XwryS7Vl52f7axUvJnyj6wzCV5B_dBbIGk_IpTPubSj1iuVzmV 9r.h0C9UpbXDBamfEPNpZWF0mpgau.ejx3SnrwQWu7qqxdxS1bfWfeBjffmF kDRVsa5KE4X7cCe6X2PZmCJyJFNB4wR231Q-- Received: from [209.131.62.115] by web31816.mail.mud.yahoo.com via HTTP; Tue, 03 Jan 2012 12:37:48 PST X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.116.331537 References: <4E1F6AAD24975D4BA5B16804296739435F763122@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739435F772D1D@TK5EX14MBXC283.redmond.corp.microsoft.com> <4EEF13F1.7030409@gmx.de> <4E1F6AAD24975D4BA5B16804296739435F78F5BB@TK5EX14MBXC283.redmond.corp.microsoft.com> <4EFD91B4.5050904@gmx.de> <4E1F6AAD24975D4BA5B16804296739435F790386@TK5EX14MBXC283.redmond.corp.microsoft.com> <1325619340.463.YahooMailNeo@web31808.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B16804296739435F7936E7@TK5EX14MBXC283.redmond.corp.microsoft.com> <1325620772.48511.YahooMailNeo@web31802.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B16804296739435F79376F@TK5EX14MBXC283.redmond.corp.microsoft.com> <1325621624.9908.YahooMailNeo@web31808.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B16804296739435F793829@TK5EX14MBXC283.redmond.corp.microsoft.com> Message-ID: <1325623068.88228.YahooMailNeo@web31816.mail.mud.yahoo.com> Date: Tue, 3 Jan 2012 12:37:48 -0800 (PST) From: William Mills To: Mike Jones , Julian Reschke In-Reply-To: <4E1F6AAD24975D4BA5B16804296739435F793829@TK5EX14MBXC283.redmond.corp.microsoft.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1238014912-1278798801-1325623068=:88228" Cc: Mark Nottingham , Barry Leiba , OAuth WG Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft 15? 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, 03 Jan 2012 20:38:05 -0000 ---1238014912-1278798801-1325623068=:88228 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable OK, then the core spec should.=0A=0A=0A=0A________________________________= =0A From: Mike Jones =0ATo: William Mills ; Julian Reschke =0ACc: Mark Nott= ingham ; Barry Leiba ; OAuth WG =0ASent: Tuesday, January 3, 2012 12:20 PM=0ASubject: RE: [OA= UTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft 15?=0A =0A= =0A =0ASorry, I should have been more precise.=C2=A0 The Core spec doesn=E2= =80=99t define how to transmit these fields in the WWW-Authenticate respons= e header field.=C2=A0 The Bearer spec does.=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: Tuesday, Ja= nuary 03, 2012 12:14 PM=0ATo: Mike Jones; Julian Reschke=0ACc: Mark Notting= ham; Barry Leiba; OAuth WG=0ASubject: Re: [OAUTH-WG] auth-param syntax, was= : OK to post OAuth Bearer draft 15?=0A=C2=A0=0Ahttp://tools.ietf.org/html/d= raft-ietf-oauth-v2-22#section-11.2.2 certainly has these as predefined regi= stered parameters.=C2=A0 If the definition there isn't strong enough, or in= that spec, we should fix that.=C2=A0 That is where these should be defined= .=0A=C2=A0=0A=0A________________________________=0A =0AFrom:Mike Jones =0ATo: William Mills ; Julia= n Reschke =0ACc: Mark Nottingham ; B= arry Leiba ; OAuth WG =0ASent: Tu= esday, January 3, 2012 12:00 PM=0ASubject: RE: [OAUTH-WG] auth-param syntax= , was: OK to post OAuth Bearer draft 15?=0AThe core spec doesn=E2=80=99t in= clude these parameters.=0A=C2=A0=0AFrom:William Mills [mailto:wmills@yahoo-= inc.com] =0ASent: Tuesday, January 03, 2012 12:00 PM=0ATo: Mike Jones; Juli= an Reschke=0ACc: Mark Nottingham; Barry Leiba; OAuth WG=0ASubject: Re: [OAU= TH-WG] auth-param syntax, was: OK to post OAuth Bearer draft 15?=0A=C2=A0= =0AWhy is Bearer dealing with this at all?=C2=A0 the BNF for that stuff sho= uld be part of the core spec, and additional values perhaps defined in Bear= er.=0A=C2=A0=0A=0A________________________________=0A =0AFrom:Mike Jones =0ATo: William Mills ; Jul= ian Reschke =0ACc: Mark Nottingham ;= Barry Leiba ; OAuth WG =0ASent: = Tuesday, January 3, 2012 11:46 AM=0ASubject: RE: [OAUTH-WG] auth-param synt= ax, was: OK to post OAuth Bearer draft 15?=0AThis is about the syntax for t= he scope, error, and error_description parameters.=C2=A0 The pertinent text= from Section 3 is:=0A=C2=A0=0A=C2=A0=C2=A0 Producers of "scope" strings MU= ST NOT use characters outside the set=0A=C2=A0=C2=A0 %x21 / %x23-5B / %x5D-= 7E for representing the scope values and %x20=0A=C2=A0=C2=A0 for the delimi= ter.=C2=A0 Producers of "error" and "error_description"=0A=C2=A0=C2=A0 stri= ngs MUST NOT use characters outside the set %x20-21 / %x23-5B /=0A=C2=A0=C2= =A0 %x5D-7E for representing these values.=C2=A0 Producers of "error-uri"= =0A=C2=A0=C2=A0 strings MUST NOT use characters outside the set %x21 / %x23= -5B /=0A=C2=A0=C2=A0 %x5D-7E for representing these values.=C2=A0 Furthermo= re, "error-uri"=0A=C2=A0=C2=A0 strings MUST conform to the URI-Reference sy= ntax.=C2=A0 In all these=0A=C2=A0=C2=A0 cases, no character quoting will oc= cur, as senders are prohibited=0A=C2=A0=C2=A0 from using the %5C ('\') char= acter.=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 Ch= eers,=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:William Mills [mailto:wmills@yahoo-inc.com] =0ASent: Tuesday,= January 03, 2012 11:36 AM=0ATo: Mike Jones; Julian Reschke=0ACc: Mark Nott= ingham; Barry Leiba; OAuth WG=0ASubject: Re: [OAUTH-WG] auth-param syntax, = was: OK to post OAuth Bearer draft 15?=0A=C2=A0=0AIs all this only around t= he scope parameter?=C2=A0 My mail cited below is with regards to the charac= ter set for a valid scope parameter, which we should be able to define and = then lean on the HTTPbis spec for the actual parameter syntax.=0A=C2=A0=0A= =0A________________________________=0A =0AFrom:Mike Jones =0ATo: Julian Reschke =0ACc: Mark Notti= ngham ; Barry Leiba ; OAuth WG =0ASent: Friday, December 30, 2011 3:19 PM=0ASubject: Re: [OAU= TH-WG] auth-param syntax, was: OK to post OAuth Bearer draft 15?=0A=0AI did= already back the statement that this is the working group consensus with t= he e-mails attached in this note sent to you on December 12, 2011:=0A=C2=A0= - http://www.ietf.org/mail-archive/web/oauth/current/msg08042.html=0A=0ABu= t since that apparently wasn't convincing to you that this working group de= cision represents more than "just me disagreeing with you", here are refere= nces to individual messages referenced in the above e-mail:=0A=C2=A0 - Eran= Hammer-Lahav: http://www.ietf.org/mail-archive/web/oauth/current/msg07698.= html=0A=C2=A0 - John Bradley:=C2=A0 http://www.ietf.org/mail-archive/web/oa= uth/current/msg07699.html=0A=C2=A0 - William Mills:=C2=A0 http://www.ietf.o= rg/mail-archive/web/oauth/current/msg07700.html=0A=C2=A0 - Mike Jones:=C2= =A0 http://www.ietf.org/mail-archive/web/oauth/current/msg07701.html=0A=C2= =A0 - Phil Hunt:=C2=A0 http://www.ietf.org/mail-archive/web/oauth/current/m= sg07702.html=0A=C2=A0 - Justin Richer:=C2=A0 http://www.ietf.org/mail-archi= ve/web/oauth/current/msg07692.html=0A=0AAs for your assertion that the spec= s are in conflict, yes, the Bearer spec includes a different decision than = a RECOMMENDED clause in the HTTPbis spec (which was added after the Bearer = text was already in place).=C2=A0 However, it is not violating any MUST cla= uses=0A in the HTTPbis spec.=C2=A0 Given that no MUSTS are violated, I don'= t see it mandatory for this tension to be resolved in favor of one spec or = the other in order for both to be approved as RFCs.=C2=A0 I look forward to= seeing that happen soon in both cases (and for the=0A OAuth core spec as w= ell).=0A=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 Best wishes,=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 -- Mike=0A=0A-----Original Message-----=0AFrom= : Julian Reschke [mailto:julian.reschke@gmx.de] =0ASent: Friday, December 3= 0, 2011 2:26 AM=0ATo: Mike Jones=0ACc: Barry Leiba; Mark Nottingham; OAuth = WG=0ASubject: Re: auth-param syntax, was: [OAUTH-WG] OK to post OAuth Beare= r draft 15?=0A=0AOn 2011-12-29 22:18, Mike Jones wrote:=0A> You proposed, J= ulian "3. Do not specify the ABNF. The ABNF of the WWW-Authenticate is defi= ned in HTTPbis. Just state the names of the parameters, their syntax *after= * parsing and their semantics."=0A>=0A> About some of Mark Nottingham's com= ments, Barry wrote "Let me point out that "this represents working-group co= nsensus" is not always a valid response.=C2=A0 If the working group has act= ually considered the *issue*, that might be OK.=C2=A0 But if there's consen= sus for=0A the chosen solution and someone brings up a *new* issue with it,= that issue needs to be addressed anew."=0A>=0A> Relative to these two stat= ements, I believe that I should remark at this point that your proposed sem= antics of only considering the syntax after potential quoting was explicitl= y considered earlier by the working group and rejected.=C2=A0 The consensus= , instead,=0A was for the present "no quoting will occur for legal inputs" = semantics.=0A=0AIt would be helpful if you could back this statement with p= ointers to mails. As far as I can tell it's just you disagreeing with me.= =0A=0ABack to the facts:=0A=0Aa) the bearer spec defines an HTTP authentica= tion scheme, and normatively refers to HTTPbis Part7 for that=0A=0Ab) HTTPb= is recommends new scheme definitions not to have their own ABNF, as the hea= der field syntax is defined by HTTPbis, not the individual scheme=0A=0Ac) t= he bearer spec defines it's own ABNF nevertheless=0A=0ASo the two specs are= in conflict, and we should resolve the conflict one way or the other.=0A= =0AIf you disagree with the recommendation in HTTPbis, then you really real= ly should come over to HTTPbis WG and argue your point of view.=0A=0AIf you= agree with it, but think that the bearer spec can't follow the recommendat= ion, then it would be good to explain the reasoning (optimally in the spec)= .=0A=0AIf you agree with it, and think the bearer spec *could* follow it, t= hen... change it, by all means.=0A=0AAnyway, if this issue isn't resolved b= efore IETF LC then it will be raised again at that time.=0A=0A=0A> I believ= e that in the New Year the chairs and area directors will need to decide ho= w to proceed on this issue.=C2=A0 (The working group consensus, as I see it= , is already both well-informed and clear on this point, but I understand t= hat that's not the only consideration.)=C2=A0=0A It would be good to see th= e spec finished shortly.=0A> ...=0A=0ABest regards, Julian=0A=0A=0A=0A_____= __________________________________________=0AOAuth mailing list=0AOAuth@iet= f.org=0Ahttps://www.ietf.org/mailman/listinfo/oauth ---1238014912-1278798801-1325623068=:88228 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
OK, then the core spec should.

From: Mike Jones <Michael.= Jones@microsoft.com>
To: William Mills <wmills@yahoo-inc.com>; Julian Reschke <julian= .reschke@gmx.de>
Cc: Mark Nottingham <mnot@mnot.net>; Barry Leiba <barryleiba@compute= r.org>; OAuth WG <oauth@ietf.org>
Sent: Tuesday, January 3, 2012 12:20 PM
Subject: RE: [OAUTH-WG] auth-param= syntax, was: OK to post OAuth Bearer draft 15?
=0A
=0A=0A =0A =0A=0A=0A
= =0A
=0A
Sorry, I should hav= e been more precise.  The Core spec doesn=E2=80=99t define how to tran= smit these fields in the WWW-Authenticate response header field.  The = Bearer=0A spec does.
=0A
<= span style=3D"font-size:11.0pt;color:#002060;">  
=0A           &nb= sp;            =             &nb= sp;            =             &nb= sp;  -- Mike
=0A
 
=0A
= =0A
=0A
From: William M= ills [mailto:wmills@yahoo-inc.com]=0A
=0ASent: Tuesday, January 0= 3, 2012 12:14 PM
=0ATo: Mike Jones; Julian Reschke
=0ACc: Mark Nottingham; Barry Leiba; OAuth WG
=0ASubject: Re: [OAUTH-= WG] auth-param syntax, was: OK to post OAuth Bearer draft 15?
= =0A
=0A
=0A
 
=0A=
=0A
=0A
http://tools.ietf.org/h= tml/draft-ietf-oauth-v2-22#section-11.2.2=0A certainly has these as predefi= ned registered parameters.  If the definition there isn't strong enoug= h, or in that spec, we should fix that.  That is where these should be= defined.
=0A
=0A
=0A
 
=0A
=0A
=0A
=0A
=0A=0A
=0A
=0A
From: Mike Jones <Michael.Jones@microsoft.com>
=0ATo: William M= ills <wmills@yahoo-inc.com&g= t;; Julian Reschke <julian.res= chke@gmx.de>=0A
=0ACc: Mark Nottingham <mnot@mnot.net>; Barry Leiba <barryleiba@computer.org>; OAuth WG <oauth@ietf.org>=0A
=0ASent: Tuesday,= January 3, 2012 12:00 PM
=0ASubject: RE: [OAUTH-WG] auth-param s= yntax, was: OK to post OAuth Bearer draft 15?
=0A
=0A
=0A
=0A
=0A=
The core spec doesn=E2=80=99t include= these parameters.
=0A=0A
=0A
 
=0A
=0A
=0A
=0A
=0AFrom: William Mills=0A[mailto:wmills@yahoo-inc.com]
=0ASent: Tuesday, January 03, 2012 12:00 PM
=0ATo: Mike Jones; Julian R= eschke
=0ACc: Mark Nottingham; Barry Leiba; OAuth WG
=0ASub= ject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer dr= aft 15?
=0A
=0A
= =0A
=0A
=0A
 
=0A
=0A=0A
=0A
=0A
Why is Bearer deali= ng with this at all?  the BNF for that stuff should be part of the cor= e spec, and additional values perhaps defined in Bearer.
=0A
=0A
=0A
=0A
=0A
 
=0A
=0A
=0A
=0A
=0A
= =0A=0A
=0A
=0A
=0A
From: Mike Jones <Michael.Jones@microsoft.com>
=0A= To: William Mills <wmills@ya= hoo-inc.com>; Julian Reschke <julian.reschke@gmx.de>=0A
=0ACc: Mark Nottingham &l= t;mnot@mnot.net>; Barry Leiba <barryleiba@computer.org>; OA= uth WG <oauth@ietf.org>=0A
=0AS= ent: Tuesday, January 3, 2012 11:46 AM
=0ASubject: RE: [OAUTH= -WG] auth-param syntax, was: OK to post OAuth Bearer draft 15?
=0A
=0A
= =0A
=0A
=0A
=0A
=0A
Th= is is about the syntax for the scope, error, and error_description paramete= rs.  The pertinent text from=0A= =0ASection 3 is:
=0A=0A
=0A
=0A
=0A
&nbs= p;
=0A
=0A
=0A=0A
=0A
   = Producers of "scope" strings MUST NOT use characters outside the set=
=0A
=0A
=0A
=0A=0A
   %x21 / %x= 23-5B / %x5D-7E for representing the scope values and %x20
=0A
=0A
=0A
=0A
=0A
   for the delimiter.&= nbsp; Producers of "error" and "error_description"
=0A
=0A
=0A
=0A
=0A
   strings MUST NOT use charac= ters outside the set %x20-21 / %x23-5B /
=0A
=0A
=0A
=0A
=0A
   %x5D-7E for representing these values= .  Producers of "error-uri"=
=0A
=0A
=0A
=0A
=0A
   strings MUST NOT use characters outside the s= et %x21 / %x23-5B /
=0A=0A
=0A
=0A
=0A
   %x5D-7E for representing these values.  Furthermo= re, "error-uri"
=0A
= =0A
=0A
=0A
=0A
   strings MUST conform to the URI-Reference syntax.  In al= l these
=0A
=0A
= =0A
=0A
=0A
 &n= bsp; cases, no character quoting will occur, as senders are prohibited
=0A
=0A
=0A
=0A<= div>=0A
   from us= ing the %5C ('\') character. =0A
=0A
=0A
=0A
=0A
 
=0A
=0A=0A
=0A
=0A
  &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;       Cheers,
=0A
=0A
=0A
=0A
=0A
         =             &nb= sp;            =             &nb= sp;            = -- Mike
=0A
=0A=0A
=0A
=0A
 
=0A
=0A
=0A
=0A
=0A
=0A
=0A
From: William Mills=0A[mailto:wmills@yahoo-inc.co= m]=0A
=0ASent: Tuesday, January 03, 2012 11:36 AM
=0ATo= : Mike Jones; Julian Reschke
=0ACc: Mark Nottingham; Barry Le= iba; OAuth WG
=0ASubject: Re: [OAUTH-WG] auth-param syntax, was: = OK to post OAuth Bearer draft 15?
=0A
=0A
=0A
=0A
=0A
=0A
=0A
 
=0A
=0A
=0A
=0A
=0A
=0A<= div>=0A
Is all this only around the scop= e parameter?  My mail cited below is with regards to the character set= for a valid scope parameter, which we should be able to define and=0A then= lean on the HTTPbis spec for the actual parameter syntax.
=0A
=0A
=0A
=0A
=0A=0A
=0A
 
=0A
=0A
=0A
=0A
=0A
=0A=
=0A= =0A
=0A
=0A
=0A
=0A<= div class=3D"yiv753047374MsoNormal" style=3D"background:white;">From: Mike Jones <Michael.Jones@microsoft.com>
=0ATo: Ju= lian Reschke <julian.reschke@g= mx.de>=0A
=0ACc: Mark Nottingham <mnot@mnot.net>; Barry Leiba <barryleiba@computer.org>; OAuth WG <oauth@ietf.org>=0A
=0ASent: Friday, December= 30, 2011 3:19 PM
=0ASubject: Re: [OAUTH-WG] auth-param syntax, w= as: OK to post OAuth Bearer draft 15?
=0A
=0AI did already back the statement that this is the working group= consensus with the e-mails attached in this note sent to you on December 1= 2, 2011:
=0A  - http://www.iet= f.org/mail-archive/web/oauth/current/msg08042.html
=0A
=0ABut sin= ce that apparently wasn't convincing to you that this working group decisio= n represents more than "just me disagreeing with you", here are references = to individual messages referenced in the above e-mail:
=0A  - Eran = Hammer-Lahav: =0Ahttp://www.ietf.org/m= ail-archive/web/oauth/current/msg07698.html
=0A  - John Bradley= :  =0Ahttp://www.ietf.org/mail-ar= chive/web/oauth/current/msg07699.html
=0A  - William Mills:&nbs= p; =0Ahttp://www.ietf.org/mail-archive= /web/oauth/current/msg07700.html
=0A  - Mike Jones:  =0Ahttp://www.ietf.org/mail-archive/web/oau= th/current/msg07701.html
=0A  - Phil Hunt:  =0Ahttp://www.ietf.org/mail-archive/web/oauth/curren= t/msg07702.html
=0A  - Justin Richer:  =0Ahttp://www.ietf.org/mail-archive/web/oauth/current/msg= 07692.html
=0A
=0AAs for your assertion that the specs are in con= flict, yes, the Bearer spec includes a different decision than a RECOMMENDE= D clause in the HTTPbis spec (which was added after the Bearer text was alr= eady in place).  However, it is not violating any MUST clauses=0A in t= he HTTPbis spec.  Given that no MUSTS are violated, I don't see it man= datory for this tension to be resolved in favor of one spec or the other in= order for both to be approved as RFCs.  I look forward to seeing that= happen soon in both cases (and for the=0A OAuth core spec as well).
=0A=
=0A              = ;  Best wishes,
=0A         &nbs= p;      -- Mike
=0A
=0A-----Original Message-----=
=0AFrom: Julian Reschke [mailto:julian.reschke@gmx.de]=0A
=0ASent: Friday, December 30, 2011 2:26= AM
=0ATo: Mike Jones
=0ACc: Barry Leiba; Mark Nottingham; OAuth WG=0ASubject: Re: auth-param syntax, was: [OAUTH-WG] OK to post OAuth Beare= r draft 15?
=0A
=0AOn 2011-12-29 22:18, Mike Jones wrote:
=0A> = You proposed, Julian "3. Do not specify the ABNF. The ABNF of the WWW-Authe= nticate is defined in HTTPbis. Just state the names of the parameters, thei= r syntax *after* parsing and their semantics."
=0A>
=0A> About = some of Mark Nottingham's comments, Barry wrote "Let me point out that "thi= s represents working-group consensus" is not always a valid response. = If the working group has actually considered the *issue*, that might be OK= .  But if there's consensus for=0A the chosen solution and someone bri= ngs up a *new* issue with it, that issue needs to be addressed anew."
= =0A>
=0A> Relative to these two statements, I believe that I shoul= d remark at this point that your proposed semantics of only considering the= syntax after potential quoting was explicitly considered earlier by the wo= rking group and rejected.  The consensus, instead,=0A was for the pres= ent "no quoting will occur for legal inputs" semantics.
=0A
=0AIt wou= ld be helpful if you could back this statement with pointers to mails. As f= ar as I can tell it's just you disagreeing with me.
=0A
=0ABack to th= e facts:
=0A
=0Aa) the bearer spec defines an HTTP authentication sch= eme, and normatively refers to HTTPbis Part7 for that
=0A
=0Ab) HTTPb= is recommends new scheme definitions not to have their own ABNF, as the hea= der field syntax is defined by HTTPbis, not the individual scheme
=0A=0Ac) the bearer spec defines it's own ABNF nevertheless
=0A
=0ASo t= he two specs are in conflict, and we should resolve the conflict one way or= the other.
=0A
=0AIf you disagree with the recommendation in HTTPbis= , then you really really should come over to HTTPbis WG and argue your poin= t of view.
=0A
=0AIf you agree with it, but think that the bearer spe= c can't follow the recommendation, then it would be good to explain the rea= soning (optimally in the spec).
=0A
=0AIf you agree with it, and thin= k the bearer spec *could* follow it, then... change it, by all means.
= =0A
=0AAnyway, if this issue isn't resolved before IETF LC then it will = be raised again at that time.
=0A
=0A
=0A> I believe that in th= e New Year the chairs and area directors will need to decide how to proceed= on this issue.  (The working group consensus, as I see it, is already= both well-informed and clear on this point, but I understand that that's n= ot the only consideration.) =0A It would be good to see the spec finis= hed shortly.
=0A> ...
=0A
=0ABest regards, Julian
=0A
=0A=
=0A
=0A_______________________________________________
=0AOAuth m= ailing list
=0AOAuth@ietf.org
=0Ahttps://www.ietf.org/mailman/listinfo/oauth
= =0A
=0A
=0A
=0A
=0A
=0A
=0A
=0A
=0A=
=0A
  =0A
=0A
=0A
=0A
=0A
=0A
=0A
=0A
 
=0A
=0A
= =0A
=0A
=0A
=0A=0A


---1238014912-1278798801-1325623068=:88228-- From igor.faynberg@alcatel-lucent.com Tue Jan 3 15:34:22 2012 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 D74D511E8080 for ; Tue, 3 Jan 2012 15:34:22 -0800 (PST) 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 Kt3baG4X4o98 for ; Tue, 3 Jan 2012 15:34:22 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 3D31811E8073 for ; Tue, 3 Jan 2012 15:34:21 -0800 (PST) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q03NYHLC013325 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 3 Jan 2012 17:34:20 -0600 (CST) 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 q03NYG9m002968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 3 Jan 2012 17:34:16 -0600 Received: from [135.222.134.168] (USMUYN0L055118.mh.lucent.com [135.222.134.168]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q03NY1PE025362; Tue, 3 Jan 2012 17:34:15 -0600 (CST) Message-ID: <4F039069.6090504@alcatel-lucent.com> Date: Tue, 03 Jan 2012 18:34:01 -0500 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: Amos Jeffries References: <301AF9A4-395C-4B5A-8610-CD86BEE1401A@mnot.net> <4EFE7E22.9010200@treenet.co.nz> <4F014DF3.9030105@alcatel-lucent.com> <4F016837.3040904@treenet.co.nz> <4F018048.1020900@lodderstedt.net> <4F019E09.3070007@treenet.co.nz> <4F022CFA.80907@alcatel-lucent.com> <4F024DA0.7080707@treenet.co.nz> In-Reply-To: <4F024DA0.7080707@treenet.co.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: ietf-http-wg@w3.org, oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth Bearer authentication - for proxies? 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: Tue, 03 Jan 2012 23:34:23 -0000 Well, this exchange made me read all I could find on reverse proxies. Now I understand--and agree with--the last statement of AYJ: '"the server" is a proxy. ' But my understanding is that the proxy (which DNS pointed me to when I tried to get to my bank) belongs in the domain "mybank," and this proxy had been issued a valid certificate--which I had ascertained in the process of authentication. So, the end result is that the proxy is part of the bank. If we expect it to be harmful to the bank--so we could the "server" itself as well as any bank's employee. It would be the bank replaying things to itself, right? Then it is the bank's problem, not OAuth's as far as I am concerned... Igor On 1/2/2012 7:36 PM, Amos Jeffries wrote: > On 1/2/2012 7:07 AM, Amos Jeffries wrote: >>> On 2/01/2012 11:00 p.m., Torsten Lodderstedt wrote: >>> ... >>>> >>>> general note: I do not understand why caching proxies should impose >>>> a problem in case TLS is used (end2end). Could you please explain? >>> >>> Because TLS is hop-by-hop (in HTTP hops, end-to-end only in TCP >>> hops). Proxies which decrypt TLS and provide responses out of cache >>> are already deployed in many places. Mostly in the form of >>> reverse-proxies, but corporate decryption proxies are also on the >>> increase. >>> >>> AYJ > > On 3/01/2012 11:17 a.m., Igor Faynberg wrote: >> I am at a loss here; granted, it is a gray area... Does it mean that >> RFC 2817 has not been implemented properly? >> > > From RFC 2817: > " > > 5. Upgrade across Proxies > > As a hop-by-hop header, Upgrade is negotiated between each pair of > HTTP counterparties. If a User Agent sends a request with an Upgrade > header to a proxy, it is requesting a change to the protocol between > itself and the proxy, not an end-to-end change. > " > > The more common case is CONNECT method from RFC 2068, from a user > agent to a reverse-proxy. Same behaviour. > >> To make it simple: At the client, I establish a session key with the >> server, and then use it for confidentiality. How is this key known >> to any proxy? > > "the server" is a proxy. > > AYJ From mike@mtcc.com Tue Jan 3 15:39:49 2012 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 C794011E8089; Tue, 3 Jan 2012 15:39:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GhP+Vmvj1y0y; Tue, 3 Jan 2012 15:39:48 -0800 (PST) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 4787E11E8086; Tue, 3 Jan 2012 15:39:24 -0800 (PST) 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 q03NIHvP022271 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 3 Jan 2012 15:18:18 -0800 Message-ID: <4F038CB9.1040403@mtcc.com> Date: Tue, 03 Jan 2012 15:18:17 -0800 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: Mark Mcgloin References: <8AB6F5CC-E9A2-4A07-9AA0-83FB7C67A221@oracle.com> <4EEA3951.5010904@mtcc.com> <4EEB5BDD.7080401@mtcc.com> In-Reply-To: <4EEB5BDD.7080401@mtcc.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=7226; t=1325632762; x=1326496762; 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]=20WGLC=20on=20draft-ietf-oau th-v2-threatmodel-01,=20ends=209=0A=20Dec=202011 |Sender:=20 |To:=20Mark=20Mcgloin=20 |Content-Type:=20text/plain=3B=20charset=3DUTF-8=3B=20forma t=3Dflowed |Content-Transfer-Encoding:=208bit |MIME-Version:=201.0; bh=7QGObA2xW4o5EK3HSmybED7CRcpl3ogcxIbEsHw818A=; b=nEEuI1+JeVV5gbi0w096sJ8Grxdxbn5S7qdsRwe6H8mQmx+UuWlRs0oWfu M6jX06odb1tZPmtjjEttwuvLafly9ovs3jUYdKJbFplrf6/RCc6Eu5HVv3qE XChbV/DtiBJSujlkBx1Z/Wehjh+c80Ru/dqHjuqVFbfrCyHTm/F6c=; 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: Barry Leiba , oauth WG , oauth-bounces@ietf.org Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011 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, 03 Jan 2012 23:39:49 -0000 Barry -- It's now been two weeks and I haven't heard anything to the objections I raised. It is not my responsibility to come up with mitigation that works, it's the working group's. If there is no reasonable mitigation it should just say that. Mike On 12/16/2011 06:55 AM, Michael Thomas wrote: > On 12/16/2011 03:02 AM, Mark Mcgloin wrote: >> Michael, >> >> I will review the comments from Phil where he suggests some changes in >> section 4.1.4 of the threat model >> >> I am unclear exactly what you are proposing. If you want to propose a >> clearly worded revamp of that section in the next couple of days, I am >> willing to review and accept legitimate changes. Clearly worded means >> concise, technically accurate and devoid of alarmist phrases and words used >> out of context, such as existential. Can I suggest you review with a >> colleague before posting here. > > Barry -- I have gone through this section and made comments > and was blown off seemingly without reading them at all, and > now I'm being told to come up with text for which I can be blown > off again: "Can I suggest you review..." > > The fact of the matter is that my comments say that the > threats are understated and mitigations that are proposed do not > work. It's not my job alone to fix this. It's the working group's. > In fact if I were to propose text, it would be along the lines of > "can't be mitigated" because I do not know how to fix them. If > nobody else can come up with a better mitigation, then that > *is* what should be there, not some hand waving nonsense that > doesn't work. > > Mike, "instruct users..." feh > >> Regards >> Mark >> >> oauth-bounces@ietf.org wrote on 15/12/2011 18:15:45: >> >>> From: >>> >>> Michael Thomas >>> >>> To: >>> >>> Phil Hunt >>> >>> Cc: >>> >>> Barry Leiba, oauth WG >>> >>> Date: >>> >>> 15/12/2011 18:16 >>> >>> Subject: >>> >>> Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec >> 2011 >>> Sent by: >>> >>> oauth-bounces@ietf.org >>> >>> On 12/15/2011 09:54 AM, Phil Hunt wrote: >>>> Note: one change recommended below... >>>> >>>> With regards to 4.1.4… >>>> 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. >>>> >>>> [Phil] I don't think we need to really add much here. We could >>> write whole essays on this topic and likely will. >>>> I think the point is simply to educate the client developer that >>> there is no need for a client application to ever have access to a >>> raw uid/password (or any other user credential). >>>> [/Phi] >>>> >>> Remember: I came here not understanding whether this threat was real or >> not. >>> A threat document that can't be bothered to elaborate on one of the >> biggest >>> existential threats to the protocol is worthless. The way it is worded >>> now does >>> not make it crystal clear that, yes, this means UIWebView's in iPhone >>> apps, etc too. >>> It should because it needs to scream: THIS THREAT APPLIES TO YOU, AUTH >>> SERVER. >>> >>> >>>> [snip] >>>> >>>> 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. >>>> >>>> [Phil] I agree, Firefox recently demonstrated how poorly users >>> recognize the security signals in the browser by dropping the "lock" >>> icon without announcement. When I found out, I had already been >>> using it for some time and hadn't noticed. This counter measure >>> should be changed to: >>>> o The OAuth flow is designed so that client applications never >>> need to know user passwords. Where possible Client applications >>> SHOULD avoid directly asking for user credentials during an >>> authorization flow. >>>> [/Phil] >>>> >>> The basic problem here is that the client app is not trusted. So if it's >>> a bad >>> actor this admonition will be ignored. If it's a good actor, there >>> wasn't a threat >>> in first place. So the mitigation completely misses the mark. >>> >>>> o Client applications could be validated prior publication in a >>>> application market. >>>> >>>> [mat] How would this be done in practice? >>>> [Phil] I think this needs to change to: >>>> >>>> o Client applications could be validated for acceptable practices >>> by the Resource Site provider prior to issuing production Client >> Credentials. >>> When, exactly, can we expect to see this in the field? Neither Twitter >>> or Facebook >>> do this. And even if they were so inclined, the draft provides exactly >>> zero guidance >>> as to what exactly that "validated" might mean in practice. The way I >>> read this is: >>> "we don't know how to mitigate this". >>>> [/Phil] >>>> 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? >>>> [Phil] This is a best practice for the client developer. [Phil] >>>> >>>> >>> I don't even know what that means in the context of embedded apps. >>> Has anybody even tried this? At the very least, an example flow might >>> be useful for the uninitiated client developer. >>> >>> 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 Jan 3 15:46:31 2012 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 3073A11E80AB; Tue, 3 Jan 2012 15:46:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 aXHyolA8Velq; Tue, 3 Jan 2012 15:46:30 -0800 (PST) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA9D11E808D; Tue, 3 Jan 2012 15:46:30 -0800 (PST) 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 q03NkNJB003719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 3 Jan 2012 23:46:24 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q03NkMjO024136 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jan 2012 23:46:23 GMT Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q03NkMQY011840; Tue, 3 Jan 2012 17:46:22 -0600 Received: from [192.168.1.67] (/24.85.235.164) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 03 Jan 2012 15:46:22 -0800 References: <8AB6F5CC-E9A2-4A07-9AA0-83FB7C67A221@oracle.com> <4EEA3951.5010904@mtcc.com> <4EEB5BDD.7080401@mtcc.com> <4F038CB9.1040403@mtcc.com> In-Reply-To: <4F038CB9.1040403@mtcc.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: X-Mailer: iPhone Mail (9A405) From: Phillip Hunt Date: Tue, 3 Jan 2012 15:46:18 -0800 To: Michael Thomas X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-CT-RefId: str=0001.0A020209.4F039351.004B,ss=1,re=0.000,fgs=0 Cc: Barry Leiba , oauth WG , "oauth-bounces@ietf.org" Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011 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, 03 Jan 2012 23:46:31 -0000 -1. I think you should be suggesting alternative text at this stage. We all h= ave same responsibilities here.=20 Phil On 2012-01-03, at 15:18, Michael Thomas wrote: > Barry -- It's now been two weeks and I haven't heard anything to > the objections I raised. It is not my responsibility to come up with > mitigation that works, it's the working group's. If there is no reasonable= > mitigation it should just say that. >=20 > Mike >=20 > On 12/16/2011 06:55 AM, Michael Thomas wrote: >> On 12/16/2011 03:02 AM, Mark Mcgloin wrote: >>> Michael, >>>=20 >>> I will review the comments from Phil where he suggests some changes in >>> section 4.1.4 of the threat model >>>=20 >>> I am unclear exactly what you are proposing. If you want to propose a >>> clearly worded revamp of that section in the next couple of days, I am >>> willing to review and accept legitimate changes. Clearly worded means >>> concise, technically accurate and devoid of alarmist phrases and words u= sed >>> out of context, such as existential. Can I suggest you review with a >>> colleague before posting here. >>=20 >> Barry -- I have gone through this section and made comments >> and was blown off seemingly without reading them at all, and >> now I'm being told to come up with text for which I can be blown >> off again: "Can I suggest you review..." >>=20 >> The fact of the matter is that my comments say that the >> threats are understated and mitigations that are proposed do not >> work. It's not my job alone to fix this. It's the working group's. >> In fact if I were to propose text, it would be along the lines of >> "can't be mitigated" because I do not know how to fix them. If >> nobody else can come up with a better mitigation, then that >> *is* what should be there, not some hand waving nonsense that >> doesn't work. >>=20 >> Mike, "instruct users..." feh >>=20 >>> Regards >>> Mark >>>=20 >>> oauth-bounces@ietf.org wrote on 15/12/2011 18:15:45: >>>=20 >>>> From: >>>>=20 >>>> Michael Thomas >>>>=20 >>>> To: >>>>=20 >>>> Phil Hunt >>>>=20 >>>> Cc: >>>>=20 >>>> Barry Leiba, oauth WG >>>>=20 >>>> Date: >>>>=20 >>>> 15/12/2011 18:16 >>>>=20 >>>> Subject: >>>>=20 >>>> Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec >>> 2011 >>>> Sent by: >>>>=20 >>>> oauth-bounces@ietf.org >>>>=20 >>>> On 12/15/2011 09:54 AM, Phil Hunt wrote: >>>>> Note: one change recommended below... >>>>>=20 >>>>> With regards to 4.1.4=E2=80=A6 >>>>> 4.1.4. Threat: End-user credentials phished using compromised or >>>>> embedded browser >>>>>=20 >>>>> 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 truste= d >>>>> 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). >>>>>=20 >>>>>=20 >>>>> [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. >>>>>=20 >>>>> [Phil] I don't think we need to really add much here. We could >>>> write whole essays on this topic and likely will. >>>>> I think the point is simply to educate the client developer that >>>> there is no need for a client application to ever have access to a >>>> raw uid/password (or any other user credential). >>>>> [/Phi] >>>>>=20 >>>> Remember: I came here not understanding whether this threat was real or= >>> not. >>>> A threat document that can't be bothered to elaborate on one of the >>> biggest >>>> existential threats to the protocol is worthless. The way it is worded= >>>> now does >>>> not make it crystal clear that, yes, this means UIWebView's in iPhone >>>> apps, etc too. >>>> It should because it needs to scream: THIS THREAT APPLIES TO YOU, AUTH >>>> SERVER. >>>>=20 >>>>=20 >>>>> [snip] >>>>>=20 >>>>> Countermeasures: >>>>>=20 >>>>> o Client developers and end-user can be educated to trust an >>>>> external System-Browser only. >>>>>=20 >>>>>=20 >>>>> [mat] I assume that this is in here just for the amusement factor >>> because >>>>> it is not a credible countermeasure. >>>>>=20 >>>>> [Phil] I agree, Firefox recently demonstrated how poorly users >>>> recognize the security signals in the browser by dropping the "lock" >>>> icon without announcement. When I found out, I had already been >>>> using it for some time and hadn't noticed. This counter measure >>>> should be changed to: >>>>> o The OAuth flow is designed so that client applications never >>>> need to know user passwords. Where possible Client applications >>>> SHOULD avoid directly asking for user credentials during an >>>> authorization flow. >>>>> [/Phil] >>>>>=20 >>>> The basic problem here is that the client app is not trusted. So if it'= s >>>> a bad >>>> actor this admonition will be ignored. If it's a good actor, there >>>> wasn't a threat >>>> in first place. So the mitigation completely misses the mark. >>>>=20 >>>>> o Client applications could be validated prior publication in a >>>>> application market. >>>>>=20 >>>>> [mat] How would this be done in practice? >>>>> [Phil] I think this needs to change to: >>>>>=20 >>>>> o Client applications could be validated for acceptable practices >>>> by the Resource Site provider prior to issuing production Client >>> Credentials. >>>> When, exactly, can we expect to see this in the field? Neither Twitter >>>> or Facebook >>>> do this. And even if they were so inclined, the draft provides exactly >>>> zero guidance >>>> as to what exactly that "validated" might mean in practice. The way I >>>> read this is: >>>> "we don't know how to mitigate this". >>>>> [/Phil] >>>>> o Client developers should not collect authentication information= >>>>> directly from users and should instead use redirects to and bac= k >>>>> from a trusted external system-browser. >>>>>=20 >>>>>=20 >>>>> [mat] How would the resource/authentication server enforce such a >>> thing? >>>>> [Phil] This is a best practice for the client developer. [Phil] >>>>>=20 >>>>>=20 >>>> I don't even know what that means in the context of embedded apps. >>>> Has anybody even tried this? At the very least, an example flow might >>>> be useful for the uninitiated client developer. >>>>=20 >>>> Mike >>>> _______________________________________________ >>>> 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 mike@mtcc.com Tue Jan 3 15:53:03 2012 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 46E6D1F0C4C; Tue, 3 Jan 2012 15:53:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id diR6uyiEOmsC; Tue, 3 Jan 2012 15:53:02 -0800 (PST) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 2F9761F0C46; Tue, 3 Jan 2012 15:53:02 -0800 (PST) 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 q03NqsAL001412 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 3 Jan 2012 15:52:55 -0800 Message-ID: <4F0394D6.1090006@mtcc.com> Date: Tue, 03 Jan 2012 15:52:54 -0800 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: Phillip Hunt References: <8AB6F5CC-E9A2-4A07-9AA0-83FB7C67A221@oracle.com> <4EEA3951.5010904@mtcc.com> <4EEB5BDD.7080401@mtcc.com> <4F038CB9.1040403@mtcc.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8369; t=1325634776; x=1326498776; 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]=20WGLC=20on=20draft-ietf-oau th-v2-threatmodel-01,=20ends=209=0A=20Dec=202011 |Sender:=20 |To:=20Phillip=20Hunt=20 |Content-Type:=20text/plain=3B=20charset=3DUTF-8=3B=20forma t=3Dflowed |Content-Transfer-Encoding:=208bit |MIME-Version:=201.0; bh=9Q8Fa8PVdeOWLlwOs74+RYXqBpvu+PQ3jggVnpYYHm4=; b=UbTr8DN58KgcDAFDqNjqNcRtgQ22FD5JZf9Cag5iyf2PmftFzneiorH6Uu yCzLFZD4MU2fR25iwIY8cTCG2vt2cYLe9r3iCRJR7jhSPRxWgQvdaLq124MO C/3JzH2Ie3814ljEhUAO0N9jVtizRgyQa43ZLNdi1zNaSSaiCNWeY=; 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: Barry Leiba , oauth WG , "oauth-bounces@ietf.org" Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011 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, 03 Jan 2012 23:53:03 -0000 On 01/03/2012 03:46 PM, Phillip Hunt wrote: > -1. I think you should be suggesting alternative text at this stage. We all have same responsibilities here. My "responsibility", such as it is, is to bring up that the document's threat mitigations suggested don't work. I am only a recent and reluctant participant, versus the principals of this working group who have been around for many years. But if you insist, here's my concise suggestion to that points that I raised objections to: "No known mitigation exists." Mike > > Phil > > On 2012-01-03, at 15:18, Michael Thomas wrote: > >> Barry -- It's now been two weeks and I haven't heard anything to >> the objections I raised. It is not my responsibility to come up with >> mitigation that works, it's the working group's. If there is no reasonable >> mitigation it should just say that. >> >> Mike >> >> On 12/16/2011 06:55 AM, Michael Thomas wrote: >>> On 12/16/2011 03:02 AM, Mark Mcgloin wrote: >>>> Michael, >>>> >>>> I will review the comments from Phil where he suggests some changes in >>>> section 4.1.4 of the threat model >>>> >>>> I am unclear exactly what you are proposing. If you want to propose a >>>> clearly worded revamp of that section in the next couple of days, I am >>>> willing to review and accept legitimate changes. Clearly worded means >>>> concise, technically accurate and devoid of alarmist phrases and words used >>>> out of context, such as existential. Can I suggest you review with a >>>> colleague before posting here. >>> Barry -- I have gone through this section and made comments >>> and was blown off seemingly without reading them at all, and >>> now I'm being told to come up with text for which I can be blown >>> off again: "Can I suggest you review..." >>> >>> The fact of the matter is that my comments say that the >>> threats are understated and mitigations that are proposed do not >>> work. It's not my job alone to fix this. It's the working group's. >>> In fact if I were to propose text, it would be along the lines of >>> "can't be mitigated" because I do not know how to fix them. If >>> nobody else can come up with a better mitigation, then that >>> *is* what should be there, not some hand waving nonsense that >>> doesn't work. >>> >>> Mike, "instruct users..." feh >>> >>>> Regards >>>> Mark >>>> >>>> oauth-bounces@ietf.org wrote on 15/12/2011 18:15:45: >>>> >>>>> From: >>>>> >>>>> Michael Thomas >>>>> >>>>> To: >>>>> >>>>> Phil Hunt >>>>> >>>>> Cc: >>>>> >>>>> Barry Leiba, oauth WG >>>>> >>>>> Date: >>>>> >>>>> 15/12/2011 18:16 >>>>> >>>>> Subject: >>>>> >>>>> Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec >>>> 2011 >>>>> Sent by: >>>>> >>>>> oauth-bounces@ietf.org >>>>> >>>>> On 12/15/2011 09:54 AM, Phil Hunt wrote: >>>>>> Note: one change recommended below... >>>>>> >>>>>> With regards to 4.1.4… >>>>>> 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. >>>>>> >>>>>> [Phil] I don't think we need to really add much here. We could >>>>> write whole essays on this topic and likely will. >>>>>> I think the point is simply to educate the client developer that >>>>> there is no need for a client application to ever have access to a >>>>> raw uid/password (or any other user credential). >>>>>> [/Phi] >>>>>> >>>>> Remember: I came here not understanding whether this threat was real or >>>> not. >>>>> A threat document that can't be bothered to elaborate on one of the >>>> biggest >>>>> existential threats to the protocol is worthless. The way it is worded >>>>> now does >>>>> not make it crystal clear that, yes, this means UIWebView's in iPhone >>>>> apps, etc too. >>>>> It should because it needs to scream: THIS THREAT APPLIES TO YOU, AUTH >>>>> SERVER. >>>>> >>>>> >>>>>> [snip] >>>>>> >>>>>> 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. >>>>>> >>>>>> [Phil] I agree, Firefox recently demonstrated how poorly users >>>>> recognize the security signals in the browser by dropping the "lock" >>>>> icon without announcement. When I found out, I had already been >>>>> using it for some time and hadn't noticed. This counter measure >>>>> should be changed to: >>>>>> o The OAuth flow is designed so that client applications never >>>>> need to know user passwords. Where possible Client applications >>>>> SHOULD avoid directly asking for user credentials during an >>>>> authorization flow. >>>>>> [/Phil] >>>>>> >>>>> The basic problem here is that the client app is not trusted. So if it's >>>>> a bad >>>>> actor this admonition will be ignored. If it's a good actor, there >>>>> wasn't a threat >>>>> in first place. So the mitigation completely misses the mark. >>>>> >>>>>> o Client applications could be validated prior publication in a >>>>>> application market. >>>>>> >>>>>> [mat] How would this be done in practice? >>>>>> [Phil] I think this needs to change to: >>>>>> >>>>>> o Client applications could be validated for acceptable practices >>>>> by the Resource Site provider prior to issuing production Client >>>> Credentials. >>>>> When, exactly, can we expect to see this in the field? Neither Twitter >>>>> or Facebook >>>>> do this. And even if they were so inclined, the draft provides exactly >>>>> zero guidance >>>>> as to what exactly that "validated" might mean in practice. The way I >>>>> read this is: >>>>> "we don't know how to mitigate this". >>>>>> [/Phil] >>>>>> 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? >>>>>> [Phil] This is a best practice for the client developer. [Phil] >>>>>> >>>>>> >>>>> I don't even know what that means in the context of embedded apps. >>>>> Has anybody even tried this? At the very least, an example flow might >>>>> be useful for the uninitiated client developer. >>>>> >>>>> 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 From squid3@treenet.co.nz Tue Jan 3 17:30:41 2012 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 B32E821F84B3 for ; Tue, 3 Jan 2012 17:30:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.51 X-Spam-Level: X-Spam-Status: No, score=-0.51 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_EQ_STATIC=1.172, SARE_SUB_ENC_UTF8=0.152] 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 YPI5R0pEhj-2 for ; Tue, 3 Jan 2012 17:30:41 -0800 (PST) Received: from treenet.co.nz (ip-58-28-153-233.static-xdsl.xnet.co.nz [58.28.153.233]) by ietfa.amsl.com (Postfix) with ESMTP id CFAD421F8442 for ; Tue, 3 Jan 2012 17:30:40 -0800 (PST) Received: by treenet.co.nz (Postfix, from userid 33) id 06551E70EA; Wed, 4 Jan 2012 14:30:02 +1300 (NZDT) To: X-PHP-Originating-Script: 0:func.inc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 04 Jan 2012 14:30:01 +1300 From: Amos Jeffries In-Reply-To: <4F039069.6090504@alcatel-lucent.com> References: "<301AF9A4-395C-4B5A-8610-CD86BEE1401A@mnot.net>" <4EFE7E22.9010200@treenet.co.nz> <4F014DF3.9030105@alcatel-lucent.com> <4F016837.3040904@treenet.co.nz> <4F018048.1020900@lodderstedt.net> <4F019E09.3070007@treenet.co.nz> <4F022CFA.80907@alcatel-lucent.com> <4F024DA0.7080707@treenet.co.nz> <4F039069.6090504@alcatel-lucent.com> Message-ID: <5cdce7b5590ab91952afb70b2cb81694@treenet.co.nz> X-Sender: squid3@treenet.co.nz User-Agent: Roundcube Webmail/0.5.1 Cc: ietf-http-wg@w3.org, oauth@ietf.org Subject: Re: [OAUTH-WG] =?utf-8?q?OAuth_Bearer_authentication_-_for_proxies=3F?= 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, 04 Jan 2012 01:30:41 -0000 On Tue, 03 Jan 2012 18:34:01 -0500, Igor Faynberg wrote: > Well, this exchange made me read all I could find on reverse proxies. > Now I understand--and agree with--the last statement of AYJ: '"the > server" is a proxy. ' > > But my understanding is that the proxy (which DNS pointed me to when > I tried to get to my bank) belongs in the domain "mybank," and this > proxy had been issued a valid certificate--which I had ascertained in > the process of authentication. So, the end result is that the proxy > is > part of the bank. If we expect it to be harmful to the bank--so we > could the "server" itself as well as any bank's employee. It would > be > the bank replaying things to itself, right? I'm not sure we quite match ideas on this. The problem is between the client and proxy. Not between the proxy and the server. Here is a transaction sequence for that bank: client 1 to proxy: GET /?oauth_token=FOO HTTP/1.1 Host: bank.example.com proxy to server: GET /?oauth_token=FOO HTTP/1.1 Host: bank.example.com (server verifies the token "FOO" is valid for client 1 through the proxy) bank server to proxy: HTTP/1.1 200 OK stuff proxy to client 1: HTTP/1.1 200 OK stuff .. some time passes. The token "FOO" expires, gets replaced by token "FOO-2". client 1 to proxy: GET /?oauth_token=FOO-2 HTTP/1.1 Host: bank.example.com proxy to server: GET /?oauth_token=FOO-2 HTTP/1.1 Host: bank.example.com (server verifies the token "FOO-2" is valid for client 1 through the proxy) bank server to proxy: HTTP/1.1 200 OK other-stuff proxy to client 1: HTTP/1.1 200 OK other-stuff Attacker processes some URL records they somehow swiped from the client transactions... attacker to proxy: GET /?oauth_token=FOO HTTP/1.1 Host: bank.example.com proxy to attacker: HTTP/1.1 200 OK stuff ... Oops. attacker to proxy: GET /?oauth_token=FOO-2 HTTP/1.1 Host: bank.example.com proxy to attacker: HTTP/1.1 200 OK other-stuff ... Oops. I assume for clarity that the server and client 1 have both correctly implemented Bearer and are performing proper validation and expiry on the query-string tokens. The mitigation is for the server which implements Bearer to be sending Cache-Control with one of the values: no-store, private, proxy-revalidate and/or must-revalidate. AYJ > > Then it is the bank's problem, not OAuth's as far as I am > concerned... > > Igor > > On 1/2/2012 7:36 PM, Amos Jeffries wrote: >> On 1/2/2012 7:07 AM, Amos Jeffries wrote: >>>> On 2/01/2012 11:00 p.m., Torsten Lodderstedt wrote: >>>> ... >>>>> >>>>> general note: I do not understand why caching proxies should >>>>> impose a problem in case TLS is used (end2end). Could you please >>>>> explain? >>>> >>>> Because TLS is hop-by-hop (in HTTP hops, end-to-end only in TCP >>>> hops). Proxies which decrypt TLS and provide responses out of cache >>>> are already deployed in many places. Mostly in the form of >>>> reverse-proxies, but corporate decryption proxies are also on the >>>> increase. >>>> >>>> AYJ >> >> On 3/01/2012 11:17 a.m., Igor Faynberg wrote: >>> I am at a loss here; granted, it is a gray area... Does it mean >>> that RFC 2817 has not been implemented properly? >>> >> >> From RFC 2817: >> " >> >> 5. Upgrade across Proxies >> >> As a hop-by-hop header, Upgrade is negotiated between each pair >> of >> HTTP counterparties. If a User Agent sends a request with an >> Upgrade >> header to a proxy, it is requesting a change to the protocol >> between >> itself and the proxy, not an end-to-end change. >> " >> >> The more common case is CONNECT method from RFC 2068, from a user >> agent to a reverse-proxy. Same behaviour. >> >>> To make it simple: At the client, I establish a session key with >>> the server, and then use it for confidentiality. How is this key >>> known to any proxy? >> >> "the server" is a proxy. >> >> AYJ From igor.faynberg@alcatel-lucent.com Tue Jan 3 18:58:51 2012 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 D4A8921F8519 for ; Tue, 3 Jan 2012 18:58:51 -0800 (PST) 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 woRr8G7jX7ob for ; Tue, 3 Jan 2012 18:58:50 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id E750D21F8503 for ; Tue, 3 Jan 2012 18:58:49 -0800 (PST) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id q042wbPT002028 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 3 Jan 2012 20:58:46 -0600 (CST) 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 q042waQt020484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 3 Jan 2012 20:58:37 -0600 Received: from [135.244.21.27] (faynberg.lra.lucent.com [135.244.21.27]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q042wT8r003417; Tue, 3 Jan 2012 20:58:35 -0600 (CST) Message-ID: <4F03C055.6090105@alcatel-lucent.com> Date: Tue, 03 Jan 2012 21:58:29 -0500 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: Amos Jeffries References: "<301AF9A4-395C-4B5A-8610-CD86BEE1401A@mnot.net>" <4EFE7E22.9010200@treenet.co.nz> <4F014DF3.9030105@alcatel-lucent.com> <4F016837.3040904@treenet.co.nz> <4F018048.1020900@lodderstedt.net> <4F019E09.3070007@treenet.co.nz> <4F022CFA.80907@alcatel-lucent.com> <4F024DA0.7080707@treenet.co.nz> <4F039069.6090504@alcatel-lucent.com> <5cdce7b5590ab91952afb70b2cb81694@treenet.co.nz> In-Reply-To: <5cdce7b5590ab91952afb70b2cb81694@treenet.co.nz> Content-Type: multipart/alternative; boundary="------------040307010108070302030903" X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: ietf-http-wg@w3.org, oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth Bearer authentication - for proxies? 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, 04 Jan 2012 02:58:52 -0000 This is a multi-part message in MIME format. --------------040307010108070302030903 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Very good to have a clear sequence! Many thanks for all the work explaining this to me. Maybe my misunderstanding can be corrected by considering observations 1) and 2) and answering question 3) in-line: On 1/3/2012 8:30 PM, Amos Jeffries wrote: > ... Here is a transaction sequence for that bank: > > > client 1 to proxy: > GET /?oauth_token=FOO HTTP/1.1 > Host: bank.example.com 1): If this transaction is done over TLS, then this specific proxy is the ONLY entity in the chain that knows the token at the moment, and since it is in the same domain as the server, we must assume its fidelity.. > > proxy to server: > GET /?oauth_token=FOO HTTP/1.1 > Host: bank.example.com 2) Now the server knows it, too. > > (server verifies the token "FOO" is valid for client 1 through the > proxy) > > bank server to proxy: > HTTP/1.1 200 OK > stuff > > proxy to client 1: > HTTP/1.1 200 OK > stuff > > .. some time passes. The token "FOO" expires, gets replaced by token > "FOO-2". > > > client 1 to proxy: > GET /?oauth_token=FOO-2 HTTP/1.1 > Host: bank.example.com Same as in 1) > > proxy to server: > GET /?oauth_token=FOO-2 HTTP/1.1 > Host: bank.example.com Sane as in 2) > > (server verifies the token "FOO-2" is valid for client 1 through the > proxy) > > bank server to proxy: > HTTP/1.1 200 OK > other-stuff > > proxy to client 1: > HTTP/1.1 200 OK > other-stuff > > > Attacker processes some URL records they somehow swiped from the > client transactions... 3) How can attacker swipe it, if the token was passed *as part of an encrypted payload?* > > attacker to proxy: > GET /?oauth_token=FOO HTTP/1.1 > Host: bank.example.com > > proxy to attacker: > HTTP/1.1 200 OK > stuff > > ... Oops. > > attacker to proxy: > GET /?oauth_token=FOO-2 HTTP/1.1 > Host: bank.example.com > > proxy to attacker: > HTTP/1.1 200 OK > other-stuff > > ... Oops. > > > I assume for clarity that the server and client 1 have both correctly > implemented Bearer and are performing proper validation and expiry on > the query-string tokens. > > The mitigation is for the server which implements Bearer to be sending > Cache-Control with one of the values: no-store, private, > proxy-revalidate and/or must-revalidate. > > AYJ > > >> >> Then it is the bank's problem, not OAuth's as far as I am concerned... >> >> Igor >> >> On 1/2/2012 7:36 PM, Amos Jeffries wrote: >>> On 1/2/2012 7:07 AM, Amos Jeffries wrote: >>>>> On 2/01/2012 11:00 p.m., Torsten Lodderstedt wrote: >>>>> ... >>>>>> >>>>>> general note: I do not understand why caching proxies should >>>>>> impose a problem in case TLS is used (end2end). Could you please >>>>>> explain? >>>>> >>>>> Because TLS is hop-by-hop (in HTTP hops, end-to-end only in TCP >>>>> hops). Proxies which decrypt TLS and provide responses out of >>>>> cache are already deployed in many places. Mostly in the form of >>>>> reverse-proxies, but corporate decryption proxies are also on the >>>>> increase. >>>>> >>>>> AYJ >>> >>> On 3/01/2012 11:17 a.m., Igor Faynberg wrote: >>>> I am at a loss here; granted, it is a gray area... Does it mean >>>> that RFC 2817 has not been implemented properly? >>>> >>> >>> From RFC 2817: >>> " >>> >>> 5. Upgrade across Proxies >>> >>> As a hop-by-hop header, Upgrade is negotiated between each pair of >>> HTTP counterparties. If a User Agent sends a request with an >>> Upgrade >>> header to a proxy, it is requesting a change to the protocol between >>> itself and the proxy, not an end-to-end change. >>> " >>> >>> The more common case is CONNECT method from RFC 2068, from a user >>> agent to a reverse-proxy. Same behaviour. >>> >>>> To make it simple: At the client, I establish a session key with >>>> the server, and then use it for confidentiality. How is this key >>>> known to any proxy? >>> >>> "the server" is a proxy. >>> >>> AYJ > --------------040307010108070302030903 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Very good to have a clear sequence! Many thanks for all the work explaining this to me.
Maybe my misunderstanding can be corrected by considering observations 1) and 2) and answering question 3) in-line:

On 1/3/2012 8:30 PM, Amos Jeffries wrote:
... Here is a transaction sequence for that bank:


client 1 to proxy:
  GET /?oauth_token=FOO HTTP/1.1
  Host: bank.example.com
1): If this transaction is done over TLS, then this specific proxy is the ONLY  entity in the chain that knows the token at the moment, and since it is in the same domain as the server, we must assume its fidelity..

proxy to server:
  GET /?oauth_token=FOO HTTP/1.1
  Host: bank.example.com

2) Now the server knows it, too.

 (server verifies the token "FOO" is valid for client 1 through the proxy)

bank server to proxy:
  HTTP/1.1 200 OK
  stuff

proxy to client 1:
  HTTP/1.1 200 OK
  stuff

.. some time passes. The token "FOO" expires, gets replaced by token "FOO-2".


client 1 to proxy:
  GET /?oauth_token=FOO-2 HTTP/1.1
  Host: bank.example.com

Same as in 1)

proxy to server:
  GET /?oauth_token=FOO-2 HTTP/1.1
  Host: bank.example.com

Sane as in 2)

 (server verifies the token "FOO-2" is valid for client 1 through the proxy)

bank server to proxy:
  HTTP/1.1 200 OK
  other-stuff

proxy to client 1:
  HTTP/1.1 200 OK
  other-stuff


Attacker processes some URL records they somehow swiped from the client transactions...

3) How can attacker swipe it, if the token was passed as part of an encrypted payload?


attacker to proxy:
  GET /?oauth_token=FOO HTTP/1.1
  Host: bank.example.com

proxy to attacker:
  HTTP/1.1 200 OK
  stuff

... Oops.

attacker to proxy:
  GET /?oauth_token=FOO-2 HTTP/1.1
  Host: bank.example.com

proxy to attacker:
  HTTP/1.1 200 OK
  other-stuff

... Oops.


I assume for clarity that the server and client 1 have both correctly implemented Bearer and are performing proper validation and expiry on the query-string tokens.

The mitigation is for the server which implements Bearer to be sending Cache-Control with one of the values: no-store, private, proxy-revalidate and/or must-revalidate.

AYJ



Then it is the bank's problem, not OAuth's as far as I am concerned...

Igor

On 1/2/2012 7:36 PM, Amos Jeffries wrote:
On 1/2/2012 7:07 AM, Amos Jeffries wrote:
On 2/01/2012 11:00 p.m., Torsten Lodderstedt wrote:
...

general note: I do not understand why caching proxies should impose a problem in case TLS is used (end2end). Could you please explain?

Because TLS is hop-by-hop (in HTTP hops, end-to-end only in TCP hops). Proxies which decrypt TLS and provide responses out of cache are already deployed in many places. Mostly in the form of reverse-proxies, but corporate decryption proxies are also on the increase.

AYJ

On 3/01/2012 11:17 a.m., Igor Faynberg wrote:
I am at a loss here; granted, it is a gray area...  Does it mean that RFC 2817 has not been implemented properly?


From RFC 2817:
"

5. Upgrade across Proxies

   As a hop-by-hop header, Upgrade is negotiated between each pair of
   HTTP counterparties.  If a User Agent sends a request with an Upgrade
   header to a proxy, it is requesting a change to the protocol between
   itself and the proxy, not an end-to-end change.
"

The more common case is CONNECT method from RFC 2068, from a user agent to a reverse-proxy. Same behaviour.

To make it simple: At the client, I establish a session key with the server, and then use it for confidentiality.  How is this key known to any proxy?

 "the server" is a proxy.

AYJ

--------------040307010108070302030903-- From squid3@treenet.co.nz Tue Jan 3 21:08:01 2012 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 D487321F8583 for ; Tue, 3 Jan 2012 21:08:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=-2.477, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_EQ_STATIC=1.172, J_CHICKENPOX_35=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 iYunK21T0JrC for ; Tue, 3 Jan 2012 21:08:00 -0800 (PST) Received: from treenet.co.nz (ip-58-28-153-233.static-xdsl.xnet.co.nz [58.28.153.233]) by ietfa.amsl.com (Postfix) with ESMTP id 8F6FC21F8575 for ; Tue, 3 Jan 2012 21:08:00 -0800 (PST) Received: from [192.168.1.3] (unknown [119.224.36.238]) by treenet.co.nz (Postfix) with ESMTP id 6FF32E6E76; Wed, 4 Jan 2012 18:07:23 +1300 (NZDT) Message-ID: <4F03DE86.5040701@treenet.co.nz> Date: Wed, 04 Jan 2012 18:07:18 +1300 From: Amos Jeffries User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: igor.faynberg@alcatel-lucent.com References: "<301AF9A4-395C-4B5A-8610-CD86BEE1401A@mnot.net>" <4EFE7E22.9010200@treenet.co.nz> <4F014DF3.9030105@alcatel-lucent.com> <4F016837.3040904@treenet.co.nz> <4F018048.1020900@lodderstedt.net> <4F019E09.3070007@treenet.co.nz> <4F022CFA.80907@alcatel-lucent.com> <4F024DA0.7080707@treenet.co.nz> <4F039069.6090504@alcatel-lucent.com> <5cdce7b5590ab91952afb70b2cb81694@treenet.co.nz> <4F03C055.6090105@alcatel-lucent.com> In-Reply-To: <4F03C055.6090105@alcatel-lucent.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: ietf-http-wg@w3.org, oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth Bearer authentication - for proxies? 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, 04 Jan 2012 05:08:01 -0000 On 4/01/2012 3:58 p.m., Igor Faynberg wrote: > Very good to have a clear sequence! Many thanks for all the work > explaining this to me. > Maybe my misunderstanding can be corrected by considering observations > 1) and 2) and answering question 3) in-line: > > On 1/3/2012 8:30 PM, Amos Jeffries wrote: >> ... Here is a transaction sequence for that bank: >> >> >> client 1 to proxy: >> GET /?oauth_token=FOO HTTP/1.1 >> Host: bank.example.com > 1): If this transaction is done over TLS, then this specific proxy is > the ONLY entity in the chain that knows the token at the moment, and > since it is in the same domain as the server, we must assume its > fidelity.. The client does too, surely. Fidelity, well; * it is going to cache the reply for re-use, <=== this is what I worry about. * it is going to log the URL+token for a longish term, * it may pass the URL+token in unencrypted packets (via ICP, HTCP, UDP syslog) to any peers it may have, Given these risks are all internal to the security domain and so very slight, they are still weak points in the transactions long-term integrity. Adding the cache-controls erases the risks related to caching. With correct CC headers URL replay would fail even if TLS were not present. >> >> proxy to server: >> GET /?oauth_token=FOO HTTP/1.1 >> Host: bank.example.com > > 2) Now the server knows it, too. >> >> (server verifies the token "FOO" is valid for client 1 through the >> proxy) >> >> bank server to proxy: >> HTTP/1.1 200 OK >> stuff >> >> proxy to client 1: >> HTTP/1.1 200 OK >> stuff >> >> .. some time passes. The token "FOO" expires, gets replaced by token >> "FOO-2". >> >> >> client 1 to proxy: >> GET /?oauth_token=FOO-2 HTTP/1.1 >> Host: bank.example.com > > Same as in 1) >> >> proxy to server: >> GET /?oauth_token=FOO-2 HTTP/1.1 >> Host: bank.example.com > > Sane as in 2) >> >> (server verifies the token "FOO-2" is valid for client 1 through the >> proxy) >> >> bank server to proxy: >> HTTP/1.1 200 OK >> other-stuff >> >> proxy to client 1: >> HTTP/1.1 200 OK >> other-stuff >> >> >> Attacker processes some URL records they somehow swiped from the >> client transactions... > > 3) How can attacker swipe it, if the token was passed *as part of an > encrypted payload?* > In the last year or so it has become safe to assume SSL/TLS is compromised by MITM. Or alternatively some secondary infection at one of the end points. Paranoia dictates that someone will figure it out somehow if the stakes are high enough. When they do, its a good idea to have the rest of the system firmly sealed. The given sequence was for the reverse-proxy. The alternative scenario is an identical sequence with a SSL interception proxy. For example an installation of: http://wiki.squid-cache.org/Features/SslBump. In that alternative the proxy is outside the servers security domain and inside some third-party ISP domain at the user end. AYJ From mark.mcgloin@ie.ibm.com Wed Jan 4 03:43:01 2012 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 415EB21F8600 for ; Wed, 4 Jan 2012 03:43:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_BASE64_BLANKS=0.041] 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 aw1Ixqmk+vWA for ; Wed, 4 Jan 2012 03:43:00 -0800 (PST) Received: from e06smtp11.uk.ibm.com (e06smtp11.uk.ibm.com [195.75.94.107]) by ietfa.amsl.com (Postfix) with ESMTP id 9507021F85E8 for ; Wed, 4 Jan 2012 03:42:59 -0800 (PST) Received: from /spool/local by e06smtp11.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 4 Jan 2012 11:42:57 -0000 Received: from d06nrmr1507.portsmouth.uk.ibm.com ([9.149.38.233]) by e06smtp11.uk.ibm.com ([192.168.101.141]) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 4 Jan 2012 11:42:26 -0000 Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1507.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q04BgPP51925124; Wed, 4 Jan 2012 11:42:25 GMT Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q04BgOAn021438; Wed, 4 Jan 2012 04:42:25 -0700 Received: from d06ml091.portsmouth.uk.ibm.com (d06ml091.portsmouth.uk.ibm.com [9.149.104.170]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q04BgODX021419; Wed, 4 Jan 2012 04:42:24 -0700 In-Reply-To: <4F0394D6.1090006@mtcc.com> References: <8AB6F5CC-E9A2-4A07-9AA0-83FB7C67A221@oracle.com> <4EEA3951.5010904@mtcc.com> <4EEB5BDD.7080401@mtcc.com> <4F038CB9.1040403@mtcc.com> <4F0394D6.1090006@mtcc.com> X-KeepSent: D88021B6:E1FD29B9-8025797B:004036CF; type=4; name=$KeepSent To: Michael Thomas X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 Message-ID: From: Mark Mcgloin Date: Wed, 4 Jan 2012 11:42:19 +0000 X-MIMETrack: Serialize by Router on D06ML091/06/M/IBM(Release 8.5.2FP1 ZX852FP1HF12|September 28, 2011) at 04/01/2012 11:42:19 MIME-Version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: base64 x-cbid: 12010411-5024-0000-0000-00000141A02B Cc: Barry Leiba , oauth WG , "oauth-bounces@ietf.org" Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011 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, 04 Jan 2012 11:43:01 -0000 SGkgTWljaGFlbA0KDQpDYW4geW91IGNsZWFybHkgd29yZCB0aGUgdGhyZWF0IGZvciB3aGljaCB0 aGlzIGNvdW50ZXJtZWFzdXJlIChvciBsYWNrIG9mKQ0KYXBwbGllcw0KDQoNCnRoYW5rcw0KTWFy aw0KDQpNaWNoYWVsIFRob21hcyA8bWlrZUBtdGNjLmNvbT4gd3JvdGUgb24gMDMvMDEvMjAxMiAy Mzo1Mjo1NDoNCg0KPiBGcm9tOg0KPg0KPiBNaWNoYWVsIFRob21hcyA8bWlrZUBtdGNjLmNvbT4N Cj4NCj4gVG86DQo+DQo+IFBoaWxsaXAgSHVudCA8cGhpbC5odW50QG9yYWNsZS5jb20+DQo+DQo+ IENjOg0KPg0KPiBNYXJrIE1jZ2xvaW4vSXJlbGFuZC9JQk1ASUJNSUUsIEJhcnJ5IExlaWJhDQo+ IDxiYXJyeWxlaWJhQGNvbXB1dGVyLm9yZz4sIG9hdXRoIFdHIDxvYXV0aEBpZXRmLm9yZz4sICJv YXV0aC0NCj4gYm91bmNlc0BpZXRmLm9yZyIgPG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+DQo+DQo+ IERhdGU6DQo+DQo+IDAzLzAxLzIwMTIgMjM6NTMNCj4NCj4gU3ViamVjdDoNCj4NCj4gUmU6IFtP QVVUSC1XR10gV0dMQyBvbiBkcmFmdC1pZXRmLW9hdXRoLXYyLXRocmVhdG1vZGVsLTAxLCBlbmRz IDkgRGVjDQoyMDExDQo+DQo+IE9uIDAxLzAzLzIwMTIgMDM6NDYgUE0sIFBoaWxsaXAgSHVudCB3 cm90ZToNCj4gPiAtMS4gSSB0aGluayB5b3Ugc2hvdWxkIGJlIHN1Z2dlc3RpbmcgYWx0ZXJuYXRp dmUgdGV4dCBhdCB0aGlzDQo+IHN0YWdlLiBXZSBhbGwgaGF2ZSBzYW1lIHJlc3BvbnNpYmlsaXRp ZXMgaGVyZS4NCj4NCj4gTXkgInJlc3BvbnNpYmlsaXR5Iiwgc3VjaCBhcyBpdCBpcywgaXMgdG8g YnJpbmcgdXAgdGhhdCB0aGUgZG9jdW1lbnQncw0KPiB0aHJlYXQgbWl0aWdhdGlvbnMgc3VnZ2Vz dGVkIGRvbid0IHdvcmsuIEkgYW0gb25seSBhIHJlY2VudCBhbmQNCj4gcmVsdWN0YW50IHBhcnRp Y2lwYW50LCB2ZXJzdXMgdGhlIHByaW5jaXBhbHMgb2YgdGhpcyB3b3JraW5nIGdyb3VwDQo+IHdo byBoYXZlIGJlZW4gYXJvdW5kIGZvciBtYW55IHllYXJzLg0KPg0KPiBCdXQgaWYgeW91IGluc2lz dCwgaGVyZSdzIG15IGNvbmNpc2Ugc3VnZ2VzdGlvbiB0byB0aGF0IHBvaW50cyB0aGF0IEkNCj4g cmFpc2VkIG9iamVjdGlvbnMgdG86DQo+DQo+ICJObyBrbm93biBtaXRpZ2F0aW9uIGV4aXN0cy4i DQo+DQo+IE1pa2UNCj4NCj4gPg0KPiA+IFBoaWwNCj4gPg0KPiA+IE9uIDIwMTItMDEtMDMsIGF0 IDE1OjE4LCBNaWNoYWVsIFRob21hczxtaWtlQG10Y2MuY29tPiAgd3JvdGU6DQo+ID4NCj4gPj4g QmFycnkgLS0gSXQncyBub3cgYmVlbiB0d28gd2Vla3MgYW5kIEkgaGF2ZW4ndCBoZWFyZCBhbnl0 aGluZyB0bw0KPiA+PiB0aGUgb2JqZWN0aW9ucyBJIHJhaXNlZC4gSXQgaXMgbm90IG15IHJlc3Bv bnNpYmlsaXR5IHRvIGNvbWUgdXAgd2l0aA0KPiA+PiBtaXRpZ2F0aW9uIHRoYXQgd29ya3MsIGl0 J3MgdGhlIHdvcmtpbmcgZ3JvdXAncy4gSWYgdGhlcmUgaXMgbm8NCnJlYXNvbmFibGUNCj4gPj4g bWl0aWdhdGlvbiBpdCBzaG91bGQganVzdCBzYXkgdGhhdC4NCj4gPj4NCj4gPj4gTWlrZQ0KPiA+ Pg0KPiA+PiBPbiAxMi8xNi8yMDExIDA2OjU1IEFNLCBNaWNoYWVsIFRob21hcyB3cm90ZToNCj4g Pj4+IE9uIDEyLzE2LzIwMTEgMDM6MDIgQU0sIE1hcmsgTWNnbG9pbiB3cm90ZToNCj4gPj4+PiBN aWNoYWVsLA0KPiA+Pj4+DQo+ID4+Pj4gSSB3aWxsIHJldmlldyB0aGUgY29tbWVudHMgZnJvbSBQ aGlsIHdoZXJlIGhlIHN1Z2dlc3RzIHNvbWUgY2hhbmdlcw0KaW4NCj4gPj4+PiBzZWN0aW9uIDQu MS40IG9mIHRoZSB0aHJlYXQgbW9kZWwNCj4gPj4+Pg0KPiA+Pj4+IEkgYW0gdW5jbGVhciBleGFj dGx5IHdoYXQgeW91IGFyZSBwcm9wb3NpbmcuIElmIHlvdSB3YW50IHRvIHByb3Bvc2UNCmENCj4g Pj4+PiBjbGVhcmx5IHdvcmRlZCByZXZhbXAgb2YgdGhhdCBzZWN0aW9uIGluIHRoZSBuZXh0IGNv dXBsZSBvZiBkYXlzLCBJDQphbQ0KPiA+Pj4+IHdpbGxpbmcgdG8gcmV2aWV3IGFuZCBhY2NlcHQg bGVnaXRpbWF0ZSBjaGFuZ2VzLiBDbGVhcmx5IHdvcmRlZA0KbWVhbnMNCj4gPj4+PiBjb25jaXNl LCB0ZWNobmljYWxseSBhY2N1cmF0ZSBhbmQgZGV2b2lkIG9mIGFsYXJtaXN0IHBocmFzZXMNCj4g YW5kIHdvcmRzIHVzZWQNCj4gPj4+PiBvdXQgb2YgY29udGV4dCwgc3VjaCBhcyBleGlzdGVudGlh bC4gQ2FuIEkgc3VnZ2VzdCB5b3UgcmV2aWV3IHdpdGggYQ0KPiA+Pj4+IGNvbGxlYWd1ZSBiZWZv cmUgcG9zdGluZyBoZXJlLg0KPiA+Pj4gQmFycnkgLS0gSSBoYXZlIGdvbmUgdGhyb3VnaCB0aGlz IHNlY3Rpb24gYW5kIG1hZGUgY29tbWVudHMNCj4gPj4+IGFuZCB3YXMgYmxvd24gb2ZmIHNlZW1p bmdseSB3aXRob3V0IHJlYWRpbmcgdGhlbSBhdCBhbGwsIGFuZA0KPiA+Pj4gbm93IEknbSBiZWlu ZyB0b2xkIHRvIGNvbWUgdXAgd2l0aCB0ZXh0IGZvciB3aGljaCBJIGNhbiBiZSBibG93bg0KPiA+ Pj4gb2ZmIGFnYWluOiAiQ2FuIEkgc3VnZ2VzdCB5b3UgcmV2aWV3Li4uIg0KPiA+Pj4NCj4gPj4+ IFRoZSBmYWN0IG9mIHRoZSBtYXR0ZXIgaXMgdGhhdCBteSBjb21tZW50cyBzYXkgdGhhdCB0aGUN Cj4gPj4+IHRocmVhdHMgYXJlIHVuZGVyc3RhdGVkIGFuZCBtaXRpZ2F0aW9ucyB0aGF0IGFyZSBw cm9wb3NlZCBkbyBub3QNCj4gPj4+IHdvcmsuIEl0J3Mgbm90IG15IGpvYiBhbG9uZSB0byBmaXgg dGhpcy4gSXQncyB0aGUgd29ya2luZyBncm91cCdzLg0KPiA+Pj4gSW4gZmFjdCBpZiBJIHdlcmUg dG8gcHJvcG9zZSB0ZXh0LCBpdCB3b3VsZCBiZSBhbG9uZyB0aGUgbGluZXMgb2YNCj4gPj4+ICJj YW4ndCBiZSBtaXRpZ2F0ZWQiIGJlY2F1c2UgSSBkbyBub3Qga25vdyBob3cgdG8gZml4IHRoZW0u IElmDQo+ID4+PiBub2JvZHkgZWxzZSBjYW4gY29tZSB1cCB3aXRoIGEgYmV0dGVyIG1pdGlnYXRp b24sIHRoZW4gdGhhdA0KPiA+Pj4gKmlzKiB3aGF0IHNob3VsZCBiZSB0aGVyZSwgbm90IHNvbWUg aGFuZCB3YXZpbmcgbm9uc2Vuc2UgdGhhdA0KPiA+Pj4gZG9lc24ndCB3b3JrLg0KPiA+Pj4NCj4g Pj4+IE1pa2UsICJpbnN0cnVjdCB1c2Vycy4uLiIgZmVoDQo+ID4+Pg0KPiA+Pj4+IFJlZ2FyZHMN Cj4gPj4+PiBNYXJrDQo+ID4+Pj4NCj4gPj4+PiBvYXV0aC1ib3VuY2VzQGlldGYub3JnIHdyb3Rl IG9uIDE1LzEyLzIwMTEgMTg6MTU6NDU6DQo+ID4+Pj4NCj4gPj4+Pj4gRnJvbToNCj4gPj4+Pj4N Cj4gPj4+Pj4gTWljaGFlbCBUaG9tYXM8bWlrZUBtdGNjLmNvbT4NCj4gPj4+Pj4NCj4gPj4+Pj4g VG86DQo+ID4+Pj4+DQo+ID4+Pj4+IFBoaWwgSHVudDxwaGlsLmh1bnRAb3JhY2xlLmNvbT4NCj4g Pj4+Pj4NCj4gPj4+Pj4gQ2M6DQo+ID4+Pj4+DQo+ID4+Pj4+IEJhcnJ5IExlaWJhPGJhcnJ5bGVp YmFAY29tcHV0ZXIub3JnPiwgb2F1dGggV0c8b2F1dGhAaWV0Zi5vcmc+DQo+ID4+Pj4+DQo+ID4+ Pj4+IERhdGU6DQo+ID4+Pj4+DQo+ID4+Pj4+IDE1LzEyLzIwMTEgMTg6MTYNCj4gPj4+Pj4NCj4g Pj4+Pj4gU3ViamVjdDoNCj4gPj4+Pj4NCj4gPj4+Pj4gUmU6IFtPQVVUSC1XR10gV0dMQyBvbiBk cmFmdC1pZXRmLW9hdXRoLXYyLXRocmVhdG1vZGVsLTAxLCBlbmRzIDkNCkRlYw0KPiA+Pj4+IDIw MTENCj4gPj4+Pj4gU2VudCBieToNCj4gPj4+Pj4NCj4gPj4+Pj4gb2F1dGgtYm91bmNlc0BpZXRm Lm9yZw0KPiA+Pj4+Pg0KPiA+Pj4+PiBPbiAxMi8xNS8yMDExIDA5OjU0IEFNLCBQaGlsIEh1bnQg d3JvdGU6DQo+ID4+Pj4+PiBOb3RlOiBvbmUgY2hhbmdlIHJlY29tbWVuZGVkIGJlbG93Li4uDQo+ ID4+Pj4+Pg0KPiA+Pj4+Pj4gV2l0aCByZWdhcmRzIHRvIDQuMS404oCmDQo+ID4+Pj4+PiA0LjEu NC4gIFRocmVhdDogRW5kLXVzZXIgY3JlZGVudGlhbHMgcGhpc2hlZCB1c2luZyBjb21wcm9taXNl ZCBvcg0KPiA+Pj4+Pj4gICAgICAgICAgIGVtYmVkZGVkIGJyb3dzZXINCj4gPj4+Pj4+DQo+ID4+ Pj4+PiAgICAgIEEgbWFsaWNpb3VzIGFwcGxpY2F0aW9uIGNvdWxkIGF0dGVtcHQgdG8gcGhpc2gg ZW5kLXVzZXINCnBhc3N3b3Jkcw0KPiA+Pj4+IGJ5DQo+ID4+Pj4+PiAgICAgIG1pc3VzaW5nIGFu IGVtYmVkZGVkIGJyb3dzZXIgaW4gdGhlIGVuZC11c2VyDQo+IGF1dGhvcml6YXRpb24gcHJvY2Vz cywNCj4gPj4+Pj4+ICAgICAgb3IgYnkgcHJlc2VudGluZyBpdHMgb3duIHVzZXItaW50ZXJmYWNl IGluc3RlYWQgb2YNCj4gYWxsb3dpbmcgdHJ1c3RlZA0KPiA+Pj4+Pj4gICAgICBzeXN0ZW0gYnJv d3NlciB0byByZW5kZXIgdGhlIGF1dGhvcml6YXRpb24gdXNlciBpbnRlcmZhY2UuDQpCeQ0KPiA+ Pj4+IGRvaW5nDQo+ID4+Pj4+PiAgICAgIHNvLCB0aGUgdXN1YWwgdmlzdWFsIHRydXN0IG1lY2hh bmlzbXMgbWF5IGJlIGJ5cGFzc2VkIChlLmcuDQpUTFMNCj4gPj4+Pj4+ICAgICAgY29uZmlybWF0 aW9uLCB3ZWIgc2l0ZSBtZWNoYW5pc21zKS4gIEJ5IHVzaW5nIGFuIGVtYmVkZGVkIG9yDQo+ID4+ Pj4gaW50ZXJuYWwNCj4gPj4+Pj4+ICAgICAgY2xpZW50IGFwcGxpY2F0aW9uIHVzZXIgaW50ZXJm YWNlLCB0aGUgY2xpZW50IGFwcGxpY2F0aW9uIGhhcw0KPiA+Pj4+IGFjY2Vzcw0KPiA+Pj4+Pj4g ICAgICB0byBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIGl0IHNob3VsZCBub3QgaGF2ZSBhY2Nlc3Mg dG8gKGUuZy4NCnVpZC8NCj4gPj4+Pj4+ICAgICAgcGFzc3dvcmQpLg0KPiA+Pj4+Pj4NCj4gPj4+ Pj4+DQo+ID4+Pj4+PiBbbWF0XSBJIHRoaW5rIGl0J3MgYWxzbyB3b3J0aCBtZW50aW9uaW5nIGVp dGhlciBoZXJlLCBvciBpbg0KYW5vdGhlcg0KPiA+Pj4+Pj4gdGhyZWF0IHRoYXQgdGhlcmUgaXMg YSBmdXJ0aGVyIHNvY2lhbCBlbmdpbmVlcmluZyBtaXN1c2UvYXR0YWNrDQp3aGVyZQ0KPiA+Pj4+ IGFuDQo+ID4+Pj4+PiBhcHAgb2ZmZXJzL2RlbWFuZHMgdG8ga2VlcCB5b3VyIGNyZWRlbnRpYWxz IHNvIHRoYXQgeW91IGRvbid0IGhhdmUNCnRvDQo+ID4+Pj4gZ28NCj4gPj4+Pj4+IHRocm91Z2gg dGhlIGF1dGhvcml6YXRpb24gcmlnbWFyb2xlLiBVc2VycyBhcmUgYWxyZWFkeSBjb25kaXRpb25l ZA0KdG8NCj4gPj4+Pj4+IGdpdmUgdGhlaXIgY3JlZGVudGlhbHMgdXAgdG8gZG8gdGhpbmdzIC0t IGp1c3QgdGhpcyBtb3JuaW5nIEkNCj4gPj4+Pj4gbm90aWNlZCBmYWNlYm9vaw0KPiA+Pj4+Pj4g YXNraW5nIGZvciBteSBlbWFpbCBwYXNzd29yZCB3aGljaCB0aGV5IHByb21pc2Ugd2l0aCBzdWdh ciBvbiB0b3ANCnRvDQo+ID4+Pj4gbm90DQo+ID4+Pj4+PiBzdG9yZS4gSXQgbWlnaHQgYmUgd29y dGggbWVudGlvbmluZyB0aGF0IHRoaW5ncyBsaWtlIENBUFRDSEEgY291bGQNCmJlDQo+ID4+Pj4+ PiBkZXBsb3llZCB0byBkZWZlbmQgYWdhaW5zdCB0aGF0IHNvcnQgb2YgYXR0YWNrL21pc3VzZS4N Cj4gPj4+Pj4+DQo+ID4+Pj4+PiBbUGhpbF0gSSBkb24ndCB0aGluayB3ZSBuZWVkIHRvIHJlYWxs eSBhZGQgbXVjaCBoZXJlLiBXZSBjb3VsZA0KPiA+Pj4+PiB3cml0ZSB3aG9sZSBlc3NheXMgb24g dGhpcyB0b3BpYyBhbmQgbGlrZWx5IHdpbGwuDQo+ID4+Pj4+PiBJIHRoaW5rIHRoZSBwb2ludCBp cyBzaW1wbHkgdG8gZWR1Y2F0ZSB0aGUgY2xpZW50IGRldmVsb3BlciB0aGF0DQo+ID4+Pj4+IHRo ZXJlIGlzIG5vIG5lZWQgZm9yIGEgY2xpZW50IGFwcGxpY2F0aW9uIHRvIGV2ZXIgaGF2ZSBhY2Nl c3MgdG8gYQ0KPiA+Pj4+PiByYXcgdWlkL3Bhc3N3b3JkIChvciBhbnkgb3RoZXIgdXNlciBjcmVk ZW50aWFsKS4NCj4gPj4+Pj4+IFsvUGhpXQ0KPiA+Pj4+Pj4NCj4gPj4+Pj4gUmVtZW1iZXI6IEkg Y2FtZSBoZXJlIG5vdCB1bmRlcnN0YW5kaW5nIHdoZXRoZXIgdGhpcyB0aHJlYXQgd2FzDQpyZWFs IG9yDQo+ID4+Pj4gbm90Lg0KPiA+Pj4+PiBBIHRocmVhdCBkb2N1bWVudCB0aGF0IGNhbid0IGJl IGJvdGhlcmVkIHRvIGVsYWJvcmF0ZSBvbiBvbmUgb2YgdGhlDQo+ID4+Pj4gYmlnZ2VzdA0KPiA+ Pj4+PiBleGlzdGVudGlhbCAgdGhyZWF0cyB0byB0aGUgcHJvdG9jb2wgaXMgd29ydGhsZXNzLiBU aGUgd2F5IGl0IGlzDQp3b3JkZWQNCj4gPj4+Pj4gbm93IGRvZXMNCj4gPj4+Pj4gbm90IG1ha2Ug aXQgY3J5c3RhbCBjbGVhciB0aGF0LCB5ZXMsIHRoaXMgbWVhbnMgVUlXZWJWaWV3J3MgaW4NCmlQ aG9uZQ0KPiA+Pj4+PiBhcHBzLCBldGMgdG9vLg0KPiA+Pj4+PiBJdCBzaG91bGQgYmVjYXVzZSBp dCBuZWVkcyB0byBzY3JlYW06IFRISVMgVEhSRUFUIEFQUExJRVMgVE8gWU9VLA0KQVVUSA0KPiA+ Pj4+PiBTRVJWRVIuDQo+ID4+Pj4+DQo+ID4+Pj4+DQo+ID4+Pj4+PiBbc25pcF0NCj4gPj4+Pj4+ DQo+ID4+Pj4+PiAgICAgIENvdW50ZXJtZWFzdXJlczoNCj4gPj4+Pj4+DQo+ID4+Pj4+PiAgICAg IG8gIENsaWVudCBkZXZlbG9wZXJzIGFuZCBlbmQtdXNlciBjYW4gYmUgZWR1Y2F0ZWQgdG8gdHJ1 c3QgYW4NCj4gPj4+Pj4+ICAgICAgICAgZXh0ZXJuYWwgU3lzdGVtLUJyb3dzZXIgb25seS4NCj4g Pj4+Pj4+DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gW21hdF0gSSBhc3N1bWUgdGhhdCB0aGlzIGlzIGlu IGhlcmUganVzdCBmb3IgdGhlIGFtdXNlbWVudCBmYWN0b3INCj4gPj4+PiBiZWNhdXNlDQo+ID4+ Pj4+PiBpdCBpcyBub3QgYSBjcmVkaWJsZSBjb3VudGVybWVhc3VyZS4NCj4gPj4+Pj4+DQo+ID4+ Pj4+PiBbUGhpbF0gSSBhZ3JlZSwgRmlyZWZveCByZWNlbnRseSBkZW1vbnN0cmF0ZWQgaG93IHBv b3JseSB1c2Vycw0KPiA+Pj4+PiByZWNvZ25pemUgdGhlIHNlY3VyaXR5IHNpZ25hbHMgaW4gdGhl IGJyb3dzZXIgYnkgZHJvcHBpbmcgdGhlDQoibG9jayINCj4gPj4+Pj4gaWNvbiB3aXRob3V0IGFu bm91bmNlbWVudC4gV2hlbiBJIGZvdW5kIG91dCwgSSBoYWQgYWxyZWFkeSBiZWVuDQo+ID4+Pj4+ IHVzaW5nIGl0IGZvciBzb21lIHRpbWUgYW5kIGhhZG4ndCBub3RpY2VkLiAgVGhpcyBjb3VudGVy IG1lYXN1cmUNCj4gPj4+Pj4gc2hvdWxkIGJlIGNoYW5nZWQgdG86DQo+ID4+Pj4+PiBvIFRoZSBP QXV0aCBmbG93IGlzIGRlc2lnbmVkIHNvIHRoYXQgY2xpZW50IGFwcGxpY2F0aW9ucyBuZXZlcg0K PiA+Pj4+PiBuZWVkIHRvIGtub3cgdXNlciBwYXNzd29yZHMuIFdoZXJlIHBvc3NpYmxlIENsaWVu dCBhcHBsaWNhdGlvbnMNCj4gPj4+Pj4gU0hPVUxEIGF2b2lkIGRpcmVjdGx5IGFza2luZyBmb3Ig dXNlciBjcmVkZW50aWFscyBkdXJpbmcgYW4NCj4gPj4+Pj4gYXV0aG9yaXphdGlvbiBmbG93Lg0K PiA+Pj4+Pj4gWy9QaGlsXQ0KPiA+Pj4+Pj4NCj4gPj4+Pj4gVGhlIGJhc2ljIHByb2JsZW0gaGVy ZSBpcyB0aGF0IHRoZSBjbGllbnQgYXBwIGlzIG5vdCB0cnVzdGVkLiBTbyBpZg0KaXQncw0KPiA+ Pj4+PiBhIGJhZA0KPiA+Pj4+PiBhY3RvciB0aGlzIGFkbW9uaXRpb24gd2lsbCBiZSBpZ25vcmVk LiBJZiBpdCdzIGEgZ29vZCBhY3RvciwgdGhlcmUNCj4gPj4+Pj4gd2Fzbid0IGEgdGhyZWF0DQo+ ID4+Pj4+IGluIGZpcnN0IHBsYWNlLiBTbyB0aGUgbWl0aWdhdGlvbiBjb21wbGV0ZWx5IG1pc3Nl cyB0aGUgbWFyay4NCj4gPj4+Pj4NCj4gPj4+Pj4+ICAgICAgbyAgQ2xpZW50IGFwcGxpY2F0aW9u cyBjb3VsZCBiZSB2YWxpZGF0ZWQgcHJpb3IgcHVibGljYXRpb24NCmluIGENCj4gPj4+Pj4+ICAg ICAgICAgYXBwbGljYXRpb24gbWFya2V0Lg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IFttYXRdIEhvdyB3 b3VsZCB0aGlzIGJlIGRvbmUgaW4gcHJhY3RpY2U/DQo+ID4+Pj4+PiBbUGhpbF0gSSB0aGluayB0 aGlzIG5lZWRzIHRvIGNoYW5nZSB0bzoNCj4gPj4+Pj4+DQo+ID4+Pj4+PiBvIENsaWVudCBhcHBs aWNhdGlvbnMgY291bGQgYmUgdmFsaWRhdGVkIGZvciBhY2NlcHRhYmxlIHByYWN0aWNlcw0KPiA+ Pj4+PiBieSB0aGUgUmVzb3VyY2UgU2l0ZSBwcm92aWRlciBwcmlvciB0byBpc3N1aW5nIHByb2R1 Y3Rpb24gQ2xpZW50DQo+ID4+Pj4gQ3JlZGVudGlhbHMuDQo+ID4+Pj4+IFdoZW4sIGV4YWN0bHks IGNhbiB3ZSBleHBlY3QgdG8gc2VlIHRoaXMgaW4gdGhlIGZpZWxkPyBOZWl0aGVyDQpUd2l0dGVy DQo+ID4+Pj4+IG9yIEZhY2Vib29rDQo+ID4+Pj4+IGRvIHRoaXMuIEFuZCBldmVuIGlmIHRoZXkg d2VyZSBzbyBpbmNsaW5lZCwgdGhlIGRyYWZ0IHByb3ZpZGVzDQpleGFjdGx5DQo+ID4+Pj4+IHpl cm8gZ3VpZGFuY2UNCj4gPj4+Pj4gYXMgdG8gd2hhdCBleGFjdGx5IHRoYXQgInZhbGlkYXRlZCIg bWlnaHQgbWVhbiBpbiBwcmFjdGljZS4gVGhlIHdheQ0KSQ0KPiA+Pj4+PiByZWFkIHRoaXMgaXM6 DQo+ID4+Pj4+ICJ3ZSBkb24ndCBrbm93IGhvdyB0byBtaXRpZ2F0ZSB0aGlzIi4NCj4gPj4+Pj4+ IFsvUGhpbF0NCj4gPj4+Pj4+ICAgICAgbyAgQ2xpZW50IGRldmVsb3BlcnMgc2hvdWxkIG5vdCBj b2xsZWN0IGF1dGhlbnRpY2F0aW9uDQppbmZvcm1hdGlvbg0KPiA+Pj4+Pj4gICAgICAgICBkaXJl Y3RseSBmcm9tIHVzZXJzIGFuZCBzaG91bGQgaW5zdGVhZCB1c2UgcmVkaXJlY3RzDQo+IHRvIGFu ZCBiYWNrDQo+ID4+Pj4+PiAgICAgICAgIGZyb20gYSB0cnVzdGVkIGV4dGVybmFsIHN5c3RlbS1i cm93c2VyLg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBbbWF0XSBIb3cgd291bGQgdGhl IHJlc291cmNlL2F1dGhlbnRpY2F0aW9uIHNlcnZlciBlbmZvcmNlIHN1Y2ggYQ0KPiA+Pj4+IHRo aW5nPw0KPiA+Pj4+Pj4gW1BoaWxdIFRoaXMgaXMgYSBiZXN0IHByYWN0aWNlIGZvciB0aGUgY2xp ZW50IGRldmVsb3Blci4gW1BoaWxdDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4NCj4gPj4+Pj4gSSBkb24n dCBldmVuIGtub3cgd2hhdCB0aGF0IG1lYW5zIGluIHRoZSBjb250ZXh0IG9mIGVtYmVkZGVkIGFw cHMuDQo+ID4+Pj4+IEhhcyBhbnlib2R5IGV2ZW4gdHJpZWQgdGhpcz8gQXQgdGhlIHZlcnkgbGVh c3QsIGFuIGV4YW1wbGUgZmxvdw0KbWlnaHQNCj4gPj4+Pj4gYmUgdXNlZnVsIGZvciB0aGUgdW5p bml0aWF0ZWQgY2xpZW50IGRldmVsb3Blci4NCj4gPj4+Pj4NCj4gPj4+Pj4gTWlrZQ0KPiA+Pj4+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pj4+ PiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4gPj4+Pj4gT0F1dGhAaWV0Zi5vcmcNCj4gPj4+Pj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KPiA+Pj4+Pg0KPiA+Pj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4+IE9B dXRoIG1haWxpbmcgbGlzdA0KPiA+Pj4gT0F1dGhAaWV0Zi5vcmcNCj4gPj4+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCj4gPj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4gT0F1dGggbWFpbGluZyBsaXN0DQo+ ID4+IE9BdXRoQGlldGYub3JnDQo+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vb2F1dGgNCj4= From mike@mtcc.com Wed Jan 4 11:38:33 2012 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 457B111E8095; Wed, 4 Jan 2012 11:38:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wy4oGL0A4ewF; Wed, 4 Jan 2012 11:38:32 -0800 (PST) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 1126E11E808F; Wed, 4 Jan 2012 11:38:32 -0800 (PST) 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 q04JcM9q016967 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 4 Jan 2012 11:38:23 -0800 Message-ID: <4F04AAAE.6080702@mtcc.com> Date: Wed, 04 Jan 2012 11:38:22 -0800 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: Mark Mcgloin References: <8AB6F5CC-E9A2-4A07-9AA0-83FB7C67A221@oracle.com> <4EEA3951.5010904@mtcc.com> <4EEB5BDD.7080401@mtcc.com> <4F038CB9.1040403@mtcc.com> <4F0394D6.1090006@mtcc.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9821; t=1325705906; x=1326569906; 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]=20WGLC=20on=20draft-ietf-oau th-v2-threatmodel-01,=20ends=209=0A=20Dec=202011 |Sender:=20 |To:=20Mark=20Mcgloin=20 |Content-Type:=20text/plain=3B=20charset=3DUTF-8=3B=20forma t=3Dflowed |Content-Transfer-Encoding:=208bit |MIME-Version:=201.0; bh=hfyL+NK8ICEEd5ke10njhIJsp1oSOlNrqRzQtZNy1/c=; b=N8uM+EDNpAwF/GPEl+84P9LjGQSpw1czx/w4Tkl0f2xd9S0JYRRN62BfEo 3HRaSsDbWn6Po7GjHaWTKXsff37YrmTPiMYZ5wMiDKxGQ6qjkxVkkSQq8v6s E6xQDv4XRW3zm6V2K/QikIAgsQkC1DpKquOAeNxS9/sBLwsVEdW7s=; 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: Barry Leiba , oauth WG , "oauth-bounces@ietf.org" Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011 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, 04 Jan 2012 19:38:33 -0000 On 01/04/2012 03:42 AM, Mark Mcgloin wrote: > Hi Michael > > Can you clearly word the threat for which this countermeasure (or lack of) > applies I've already done that in my original last call comments. Given that you rejected my comments out of hand, it doesn't appear that it was for lack of clarity. Mike, rather put off by the attitude of the editors in this wg > > > thanks > Mark > > Michael Thomas wrote on 03/01/2012 23:52:54: > >> From: >> >> Michael Thomas >> >> To: >> >> Phillip Hunt >> >> Cc: >> >> Mark Mcgloin/Ireland/IBM@IBMIE, Barry Leiba >> , oauth WG, "oauth- >> bounces@ietf.org" >> >> Date: >> >> 03/01/2012 23:53 >> >> Subject: >> >> Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec > 2011 >> On 01/03/2012 03:46 PM, Phillip Hunt wrote: >>> -1. I think you should be suggesting alternative text at this >> stage. We all have same responsibilities here. >> >> My "responsibility", such as it is, is to bring up that the document's >> threat mitigations suggested don't work. I am only a recent and >> reluctant participant, versus the principals of this working group >> who have been around for many years. >> >> But if you insist, here's my concise suggestion to that points that I >> raised objections to: >> >> "No known mitigation exists." >> >> Mike >> >>> Phil >>> >>> On 2012-01-03, at 15:18, Michael Thomas wrote: >>> >>>> Barry -- It's now been two weeks and I haven't heard anything to >>>> the objections I raised. It is not my responsibility to come up with >>>> mitigation that works, it's the working group's. If there is no > reasonable >>>> mitigation it should just say that. >>>> >>>> Mike >>>> >>>> On 12/16/2011 06:55 AM, Michael Thomas wrote: >>>>> On 12/16/2011 03:02 AM, Mark Mcgloin wrote: >>>>>> Michael, >>>>>> >>>>>> I will review the comments from Phil where he suggests some changes > in >>>>>> section 4.1.4 of the threat model >>>>>> >>>>>> I am unclear exactly what you are proposing. If you want to propose > a >>>>>> clearly worded revamp of that section in the next couple of days, I > am >>>>>> willing to review and accept legitimate changes. Clearly worded > means >>>>>> concise, technically accurate and devoid of alarmist phrases >> and words used >>>>>> out of context, such as existential. Can I suggest you review with a >>>>>> colleague before posting here. >>>>> Barry -- I have gone through this section and made comments >>>>> and was blown off seemingly without reading them at all, and >>>>> now I'm being told to come up with text for which I can be blown >>>>> off again: "Can I suggest you review..." >>>>> >>>>> The fact of the matter is that my comments say that the >>>>> threats are understated and mitigations that are proposed do not >>>>> work. It's not my job alone to fix this. It's the working group's. >>>>> In fact if I were to propose text, it would be along the lines of >>>>> "can't be mitigated" because I do not know how to fix them. If >>>>> nobody else can come up with a better mitigation, then that >>>>> *is* what should be there, not some hand waving nonsense that >>>>> doesn't work. >>>>> >>>>> Mike, "instruct users..." feh >>>>> >>>>>> Regards >>>>>> Mark >>>>>> >>>>>> oauth-bounces@ietf.org wrote on 15/12/2011 18:15:45: >>>>>> >>>>>>> From: >>>>>>> >>>>>>> Michael Thomas >>>>>>> >>>>>>> To: >>>>>>> >>>>>>> Phil Hunt >>>>>>> >>>>>>> Cc: >>>>>>> >>>>>>> Barry Leiba, oauth WG >>>>>>> >>>>>>> Date: >>>>>>> >>>>>>> 15/12/2011 18:16 >>>>>>> >>>>>>> Subject: >>>>>>> >>>>>>> Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 > Dec >>>>>> 2011 >>>>>>> Sent by: >>>>>>> >>>>>>> oauth-bounces@ietf.org >>>>>>> >>>>>>> On 12/15/2011 09:54 AM, Phil Hunt wrote: >>>>>>>> Note: one change recommended below... >>>>>>>> >>>>>>>> With regards to 4.1.4… >>>>>>>> 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. >>>>>>>> >>>>>>>> [Phil] I don't think we need to really add much here. We could >>>>>>> write whole essays on this topic and likely will. >>>>>>>> I think the point is simply to educate the client developer that >>>>>>> there is no need for a client application to ever have access to a >>>>>>> raw uid/password (or any other user credential). >>>>>>>> [/Phi] >>>>>>>> >>>>>>> Remember: I came here not understanding whether this threat was > real or >>>>>> not. >>>>>>> A threat document that can't be bothered to elaborate on one of the >>>>>> biggest >>>>>>> existential threats to the protocol is worthless. The way it is > worded >>>>>>> now does >>>>>>> not make it crystal clear that, yes, this means UIWebView's in > iPhone >>>>>>> apps, etc too. >>>>>>> It should because it needs to scream: THIS THREAT APPLIES TO YOU, > AUTH >>>>>>> SERVER. >>>>>>> >>>>>>> >>>>>>>> [snip] >>>>>>>> >>>>>>>> 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. >>>>>>>> >>>>>>>> [Phil] I agree, Firefox recently demonstrated how poorly users >>>>>>> recognize the security signals in the browser by dropping the > "lock" >>>>>>> icon without announcement. When I found out, I had already been >>>>>>> using it for some time and hadn't noticed. This counter measure >>>>>>> should be changed to: >>>>>>>> o The OAuth flow is designed so that client applications never >>>>>>> need to know user passwords. Where possible Client applications >>>>>>> SHOULD avoid directly asking for user credentials during an >>>>>>> authorization flow. >>>>>>>> [/Phil] >>>>>>>> >>>>>>> The basic problem here is that the client app is not trusted. So if > it's >>>>>>> a bad >>>>>>> actor this admonition will be ignored. If it's a good actor, there >>>>>>> wasn't a threat >>>>>>> in first place. So the mitigation completely misses the mark. >>>>>>> >>>>>>>> o Client applications could be validated prior publication > in a >>>>>>>> application market. >>>>>>>> >>>>>>>> [mat] How would this be done in practice? >>>>>>>> [Phil] I think this needs to change to: >>>>>>>> >>>>>>>> o Client applications could be validated for acceptable practices >>>>>>> by the Resource Site provider prior to issuing production Client >>>>>> Credentials. >>>>>>> When, exactly, can we expect to see this in the field? Neither > Twitter >>>>>>> or Facebook >>>>>>> do this. And even if they were so inclined, the draft provides > exactly >>>>>>> zero guidance >>>>>>> as to what exactly that "validated" might mean in practice. The way > I >>>>>>> read this is: >>>>>>> "we don't know how to mitigate this". >>>>>>>> [/Phil] >>>>>>>> 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? >>>>>>>> [Phil] This is a best practice for the client developer. [Phil] >>>>>>>> >>>>>>>> >>>>>>> I don't even know what that means in the context of embedded apps. >>>>>>> Has anybody even tried this? At the very least, an example flow > might >>>>>>> be useful for the uninitiated client developer. >>>>>>> >>>>>>> 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 > > From stpeter@stpeter.im Wed Jan 4 11:47:51 2012 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 45D3111E8089; Wed, 4 Jan 2012 11:47:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.969 X-Spam-Level: X-Spam-Status: No, score=-102.969 tagged_above=-999 required=5 tests=[AWL=-0.370, 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 Jy5xyIIndspg; Wed, 4 Jan 2012 11:47:50 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id A36A811E8088; Wed, 4 Jan 2012 11:47:50 -0800 (PST) Received: from normz.cisco.com (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7FFF44009B; Wed, 4 Jan 2012 12:56:29 -0700 (MST) Message-ID: <4F04ACE4.1070006@stpeter.im> Date: Wed, 04 Jan 2012 12:47:48 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Michael Thomas References: <8AB6F5CC-E9A2-4A07-9AA0-83FB7C67A221@oracle.com> <4EEA3951.5010904@mtcc.com> <4EEB5BDD.7080401@mtcc.com> <4F038CB9.1040403@mtcc.com> <4F0394D6.1090006@mtcc.com> <4F04AAAE.6080702@mtcc.com> In-Reply-To: <4F04AAAE.6080702@mtcc.com> X-Enigmail-Version: 1.3.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Barry Leiba , oauth WG , "oauth-bounces@ietf.org" Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011 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, 04 Jan 2012 19:47:51 -0000 On 1/4/12 12:38 PM, Michael Thomas wrote: > On 01/04/2012 03:42 AM, Mark Mcgloin wrote: >> Hi Michael >> >> Can you clearly word the threat for which this countermeasure (or lack >> of) >> applies > > I've already done that in my original last call comments. Given that you > rejected my comments out of hand, it doesn't appear that it was for > lack of clarity. > > Mike, rather put off by the attitude of the editors in this wg Mike: In my experience, the IETF tradition is not to passively complain, but to actively contribute. Thus if I don't like the fact that there's no specification for some feature or protocol I care about, it's my responsibility to write an Internet-Draft to fill that gap. Similarly, if I have concerns about someone else's Internet-Draft, it's incumbent on me to propose new or alternative text. Sure, I could wait for the authors, editors, working group chairs, or area directors to take action, but you will have much greater success if you actively contribute. Just my gram of silver... Peter -- Peter Saint-Andre http://stpeter.im/ From mike@mtcc.com Wed Jan 4 12:05:31 2012 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 215E51F0C3E; Wed, 4 Jan 2012 12:05:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QsDfDiI+LWFj; Wed, 4 Jan 2012 12:05:30 -0800 (PST) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 56A431F0C3C; Wed, 4 Jan 2012 12:05:30 -0800 (PST) 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 q04K5Lk8026221 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 4 Jan 2012 12:05:22 -0800 Message-ID: <4F04B101.3070708@mtcc.com> Date: Wed, 04 Jan 2012 12:05:21 -0800 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: Peter Saint-Andre References: <8AB6F5CC-E9A2-4A07-9AA0-83FB7C67A221@oracle.com> <4EEA3951.5010904@mtcc.com> <4EEB5BDD.7080401@mtcc.com> <4F038CB9.1040403@mtcc.com> <4F0394D6.1090006@mtcc.com> <4F04AAAE.6080702@mtcc.com> <4F04ACE4.1070006@stpeter.im> In-Reply-To: <4F04ACE4.1070006@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1675; t=1325707523; x=1326571523; 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]=20WGLC=20on=20draft-ietf-oau th-v2-threatmodel-01,=20ends=209=0A=20Dec=202011 |Sender:=20 |To:=20Peter=20Saint-Andre=20 |Content-Type:=20text/plain=3B=20charset=3DUTF-8=3B=20forma t=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=Rmlpa4wSO2U/+O26EBxEq02+Vqz5jhLHz2nfWyypSVA=; b=EHyyvoov1qrD98wn57RjJum/8ak35Ik/6KsPF/ncohrAzpOCuTraL6LQ0f s4YicNHak3pAwKVDd8jZmvfL1gN0ms04OC/4X/+NJccxRHA8tjTQL6OW5lOM 3hQjY6oFTqwNApE5/GmyiUOVMuCaM3FnmUr1EeOEcz2ETo58mHNpc=; 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: Barry Leiba , oauth WG , "oauth-bounces@ietf.org" Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011 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, 04 Jan 2012 20:05:31 -0000 On 01/04/2012 11:47 AM, Peter Saint-Andre wrote: > I've already done that in my original last call comments. Given that you > rejected my comments out of hand, it doesn't appear that it was for > lack of clarity. > > Mike, rather put off by the attitude of the editors in this wg > Mike: > > In my experience, the IETF tradition is not to passively complain, but > to actively contribute. Thus if I don't like the fact that there's no > specification for some feature or protocol I care about, it's my > responsibility to write an Internet-Draft to fill that gap. Similarly, > if I have concerns about someone else's Internet-Draft, it's incumbent > on me to propose new or alternative text. Sure, I could wait for the > authors, editors, working group chairs, or area directors to take > action, but you will have much greater success if you actively contribute. > I am not an IETF noob. The problem here is that I DO NOT KNOW HOW TO MITIGATE THE THREATS I brought up as inadequately mitigated in the threat draft. I don't know how I can state that more plainly. I would *hope* that the participants of this working group who have been working on this for years could do a better job. But if they can't then the threat draft should just say that there is no known defense instead of feel-good things like "educate users". And I completely disagree that this isn't "active" participation. It denigrates draft reviewers as being lesser participants. Nor does it match IETF reality: cross area reviewers typically just point out the problems and leave it to the working group participants to work it out. Same goes for an IESG DISCUSS. Mike From mark.mcgloin@ie.ibm.com Wed Jan 4 12:34:37 2012 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 CDB5011E80A6 for ; Wed, 4 Jan 2012 12:34:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 V7McZ3bMgRsu for ; Wed, 4 Jan 2012 12:34:37 -0800 (PST) Received: from e06smtp17.uk.ibm.com (e06smtp17.uk.ibm.com [195.75.94.113]) by ietfa.amsl.com (Postfix) with ESMTP id C76F111E80A1 for ; Wed, 4 Jan 2012 12:34:36 -0800 (PST) Received: from /spool/local by e06smtp17.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 4 Jan 2012 20:34:35 -0000 Received: from d06nrmr1707.portsmouth.uk.ibm.com ([9.149.39.225]) by e06smtp17.uk.ibm.com ([192.168.101.147]) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 4 Jan 2012 20:34:32 -0000 Received: from d06av06.portsmouth.uk.ibm.com (d06av06.portsmouth.uk.ibm.com [9.149.37.217]) by d06nrmr1707.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q04KYWgt1777896; Wed, 4 Jan 2012 20:34:32 GMT Received: from d06av06.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av06.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q04KYNaj028414; Wed, 4 Jan 2012 13:34:24 -0700 Received: from d06ml091.portsmouth.uk.ibm.com (d06ml091.portsmouth.uk.ibm.com [9.149.104.170]) by d06av06.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q04KYNoJ028411; Wed, 4 Jan 2012 13:34:23 -0700 In-Reply-To: <4F04B101.3070708@mtcc.com> References: <8AB6F5CC-E9A2-4A07-9AA0-83FB7C67A221@oracle.com> <4EEA3951.5010904@mtcc.com> <4EEB5BDD.7080401@mtcc.com> <4F038CB9.1040403@mtcc.com> <4F0394D6.1090006@mtcc.com> <4F04AAAE.6080702@mtcc.com> <4F04ACE4.1070006@stpeter.im> <4F04B101.3070708@mtcc.com> X-KeepSent: 0587BA9E:B7B40207-8025797B:00702BFB; type=4; name=$KeepSent To: Michael Thomas X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 Message-ID: From: Mark Mcgloin Date: Wed, 4 Jan 2012 20:34:21 +0000 X-MIMETrack: Serialize by Router on D06ML091/06/M/IBM(Release 8.5.2FP1 ZX852FP1HF12|September 28, 2011) at 04/01/2012 20:34:26 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII x-cbid: 12010420-0542-0000-0000-0000009284F6 Cc: Barry Leiba , oauth WG , "oauth-bounces@ietf.org" Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011 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, 04 Jan 2012 20:34:37 -0000 Hi Michael I have asked you to clearly describe the threat, not the mitigation. It obviously was either not clear or convincing the first time and I am not going to start digging through emails when you clearly understand it. Regards Mark Michael Thomas wrote on 04/01/2012 20:05:21: > From: > > Michael Thomas > > To: > > Peter Saint-Andre > > Cc: > > Mark Mcgloin/Ireland/IBM@IBMIE, Barry Leiba > , oauth WG , "oauth- > bounces@ietf.org" > > Date: > > 04/01/2012 20:07 > > Subject: > > Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011 > > On 01/04/2012 11:47 AM, Peter Saint-Andre wrote: > > I've already done that in my original last call comments. Given that you > > rejected my comments out of hand, it doesn't appear that it was for > > lack of clarity. > > > > Mike, rather put off by the attitude of the editors in this wg > > Mike: > > > > In my experience, the IETF tradition is not to passively complain, but > > to actively contribute. Thus if I don't like the fact that there's no > > specification for some feature or protocol I care about, it's my > > responsibility to write an Internet-Draft to fill that gap. Similarly, > > if I have concerns about someone else's Internet-Draft, it's incumbent > > on me to propose new or alternative text. Sure, I could wait for the > > authors, editors, working group chairs, or area directors to take > > action, but you will have much greater success if you actively contribute. > > > > I am not an IETF noob. The problem here is that I DO NOT KNOW > HOW TO MITIGATE THE THREATS I brought up as inadequately > mitigated in the threat draft. I don't know how I can state that more > plainly. I would *hope* that the participants of this working group who > have been working on this for years could do a better job. But if they > can't then the threat draft should just say that there is no known defense > instead of feel-good things like "educate users". > > And I completely disagree that this isn't "active" participation. It > denigrates draft reviewers as being lesser participants. Nor does it > match IETF reality: cross area reviewers typically just point out the > problems and leave it to the working group participants to work it > out. Same goes for an IESG DISCUSS. > > Mike > From barryleiba@gmail.com Wed Jan 4 12:41:19 2012 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 50D9B11E80A1 for ; Wed, 4 Jan 2012 12:41:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.717 X-Spam-Level: X-Spam-Status: No, score=-102.717 tagged_above=-999 required=5 tests=[AWL=0.260, 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 36MMiLYGNxtg for ; Wed, 4 Jan 2012 12:41:18 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id BC82511E809F for ; Wed, 4 Jan 2012 12:41:18 -0800 (PST) Received: by ggnk5 with SMTP id k5so11874607ggn.31 for ; Wed, 04 Jan 2012 12:41:18 -0800 (PST) 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; bh=lwRkxyE7QM0IA29dl2IjU52plVoAKNpqYmKrf6+hsWY=; b=s4lVkc7vCEiYVqLQ8+GuLWJTBH41gvtokbCkzDgd9HKoI1lnpnq1w1pa89IiLzFSGF ABWB6QVZXPc7+1+CF6T3dqJ9dIQZOBrqJsU0s1Z7/7c8lX4RDa0imZIQNYROQiMD78CI 7RukU9NvDoL0Nhep/BD/2D+oo+uOV928FKnLw= MIME-Version: 1.0 Received: by 10.101.23.12 with SMTP id a12mr8788607anj.17.1325709678342; Wed, 04 Jan 2012 12:41:18 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.236.46.169 with HTTP; Wed, 4 Jan 2012 12:41:18 -0800 (PST) In-Reply-To: References: <8AB6F5CC-E9A2-4A07-9AA0-83FB7C67A221@oracle.com> <4EEA3951.5010904@mtcc.com> <4EEB5BDD.7080401@mtcc.com> <4F038CB9.1040403@mtcc.com> <4F0394D6.1090006@mtcc.com> <4F04AAAE.6080702@mtcc.com> <4F04ACE4.1070006@stpeter.im> <4F04B101.3070708@mtcc.com> Date: Wed, 4 Jan 2012 15:41:18 -0500 X-Google-Sender-Auth: XbvdpnkJM3mVARZpYoGeCBJJtgM Message-ID: From: Barry Leiba To: Mark Mcgloin Content-Type: text/plain; charset=ISO-8859-1 Cc: oauth WG Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011 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, 04 Jan 2012 20:41:19 -0000 > I have asked you to clearly describe the threat, not the mitigation. > > It obviously was either not clear or convincing the first time and I am not > going to start digging through emails when you clearly understand it. To try to shortcut this: Mike did lay it out clearly, I think, in his first note (which I linked at the beginning of this thread), and that should be the only one that needs to be read to understand his point. The basic point is that the OAuth framework relies on both the end user and the authorization server being able to trust the user's UA. If that winds up being a compromised browser or a native application that the user perhaps unwisely installed, all the security in the framework goes out the window, because an untrustworthy UA can fiddle with pretty much everything. Mike's note said much more than that, but I think I've encapsulated things in an oversimplified version above. I agree that this is something that needs to be made very clear... and that I don't see any way to mitigate it -- it's basically an aspect of what we're working with here. I don't think this is a difficult issue to document, and perhaps two paragraphs should be enough to do it. Identifying the right place and the right two paragraphs should be something that a combination of Mike and the documnet editors can do, if you can do it without getting on each others' nerves. :-) Barry From mike@mtcc.com Wed Jan 4 13:07:08 2012 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 7E61111E80C3 for ; Wed, 4 Jan 2012 13:07:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28GYQEX9jMAo for ; Wed, 4 Jan 2012 13:07:07 -0800 (PST) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id C697311E80BE for ; Wed, 4 Jan 2012 13:07:07 -0800 (PST) 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 q04L6uq8015751 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 4 Jan 2012 13:06:58 -0800 Message-ID: <4F04BF70.3010501@mtcc.com> Date: Wed, 04 Jan 2012 13:06:56 -0800 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: Barry Leiba References: <8AB6F5CC-E9A2-4A07-9AA0-83FB7C67A221@oracle.com> <4EEA3951.5010904@mtcc.com> <4EEB5BDD.7080401@mtcc.com> <4F038CB9.1040403@mtcc.com> <4F0394D6.1090006@mtcc.com> <4F04AAAE.6080702@mtcc.com> <4F04ACE4.1070006@stpeter.im> <4F04B101.3070708@mtcc.com> In-Reply-To: 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=1214; t=1325711220; x=1326575220; 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]=20WGLC=20on=20draft-ietf-oau th-v2-threatmodel-01,=20ends=209=0A=20Dec=202011 |Sender:=20 |To:=20Barry=20Leiba=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=Rmeh/B6y1HZDBaJ1BLD/LP8I5lgMPuv0i9Ad9P6bR+E=; b=h4B54LSTQ+DejKVHzkO6ft+paFm5McyObzkG1ZULojhQs7L9Kda062xbjS cxAQM6QLUNjTEYYJoczO6bbNPVAAorOeg6s2RU41lxcGsaB86/w/FNPINzTP 8y6NS8h35zmSl1lX6UAuoc7Ce6FXp/d3Ai6XUmtvKYgzV6CG0cnrE=; 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 WG Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011 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, 04 Jan 2012 21:07:08 -0000 On 01/04/2012 12:41 PM, Barry Leiba wrote: > up being a compromised browser or a native application that the user > perhaps unwisely installed, all the security in the framework goes out ^^^^^^^^^ > the window, because an untrustworthy UA can fiddle with pretty much > everything. > I think the "perhaps unwisely" goes to the heart of my objection. You might as well be talking about "perhaps unwisely" driving a car, or "perhaps unwisely" eating food: the reality is that people download apps by the *billions*. When I was initially blown off, many of the participants including document editors implied that only idiots get apps for their phones. That is *completely* unhelpful as the reality is that OAUTH's use is hugely if not primarily deployed in that sort of environment. This is a threat that cuts to the very heart of what OAUTH is, and purports to defend against: keeping user credentials out of the hands of an untrusted third party. If there really aren't any good ways to mitigate this in an app environment, why is OAUTH being deployed so aggressively there? Shouldn't the threat draft say in blinking bold: "DEPLOYING OAUTH IN NATIVE APPS CONSIDERED HARMFUL"? Mike From ve7jtb@ve7jtb.com Wed Jan 4 13:40:30 2012 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 AF0A111E80CA for ; Wed, 4 Jan 2012 13:40:30 -0800 (PST) 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 GcIZc5QUuvbQ for ; Wed, 4 Jan 2012 13:40:29 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id CB6C711E80C3 for ; Wed, 4 Jan 2012 13:40:28 -0800 (PST) Received: by yenm7 with SMTP id m7so10694064yen.31 for ; Wed, 04 Jan 2012 13:40:27 -0800 (PST) Received: by 10.100.244.7 with SMTP id r7mr17077266anh.10.1325713227181; Wed, 04 Jan 2012 13:40:27 -0800 (PST) Received: from [192.168.1.213] ([190.22.74.206]) by mx.google.com with ESMTPS id 3sm20950483ank.6.2012.01.04.13.40.21 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 04 Jan 2012 13:40:25 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/signed; boundary="Apple-Mail=_D3BA592D-451B-4992-AE08-2C7005B64389"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <1325623068.88228.YahooMailNeo@web31816.mail.mud.yahoo.com> Date: Wed, 4 Jan 2012 18:40:01 -0300 Message-Id: <5E5EA7F9-B4A0-4DCB-801C-3C0F4EC36A1E@ve7jtb.com> References: <4E1F6AAD24975D4BA5B16804296739435F763122@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739435F772D1D@TK5EX14MBXC283.redmond.corp.microsoft.com> <4EEF13F1.7030409@gmx.de> <4E1F6AAD24975D4BA5B16804296739435F78F5BB@TK5EX14MBXC283.redmond.corp.microsoft.com> <4EFD91B4.5050904@gmx.de> <4E1F6AAD24975D4BA5B16804296739435F790386@TK5EX14MBXC283.redmond.corp.microsoft.com> <1325619340.463.YahooMailNeo@web31808.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B16804296739435F7936E7@TK5EX14MBXC283.redmond.corp.microsoft.com> <1325620772.48511.YahooMailNeo@web31802.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B16804296739435F79376F@TK5EX14MBXC283.redmond.corp.microsoft.com> <1325621624.9908.YahooMailNeo@web31808.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B16804296739435F793829@TK5EX14MBXC283.redmond.corp.microsoft.com> <1325623068.88228.YahooMailNeo@web31816.mail.mud.yahoo.com> To: William Mills X-Mailer: Apple Mail (2.1251.1) Cc: Julian Reschke , Barry Leiba , Mark Nottingham , OAuth WG Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft 15? 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, 04 Jan 2012 21:40:30 -0000 --Apple-Mail=_D3BA592D-451B-4992-AE08-2C7005B64389 Content-Type: multipart/alternative; boundary="Apple-Mail=_04B9746F-B6F3-4145-89FB-F1BF2D68CC37" --Apple-Mail=_04B9746F-B6F3-4145-89FB-F1BF2D68CC37 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 You are correct. the Core spec should include this. However for one = reason or another it is not in the core spec and probably will not be, = given that it is in last call. One way or other we need to identify the correct answer. John B. On 2012-01-03, at 5:37 PM, William Mills wrote: > OK, then the core spec should. >=20 > From: Mike Jones > To: William Mills ; Julian Reschke = =20 > Cc: Mark Nottingham ; Barry Leiba = ; OAuth WG =20 > Sent: Tuesday, January 3, 2012 12:20 PM > Subject: RE: [OAUTH-WG] auth-param syntax, was: OK to post OAuth = Bearer draft 15? >=20 > Sorry, I should have been more precise. The Core spec doesn=92t = define how to transmit these fields in the WWW-Authenticate response = header field. The Bearer spec does. > =20 > -- = Mike > =20 > From: William Mills [mailto:wmills@yahoo-inc.com]=20 > Sent: Tuesday, January 03, 2012 12:14 PM > To: Mike Jones; Julian Reschke > Cc: Mark Nottingham; Barry Leiba; OAuth WG > Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth = Bearer draft 15? > =20 > http://tools.ietf.org/html/draft-ietf-oauth-v2-22#section-11.2.2 = certainly has these as predefined registered parameters. If the = definition there isn't strong enough, or in that spec, we should fix = that. That is where these should be defined. > =20 > From: Mike Jones > To: William Mills ; Julian Reschke = =20 > Cc: Mark Nottingham ; Barry Leiba = ; OAuth WG =20 > Sent: Tuesday, January 3, 2012 12:00 PM > Subject: RE: [OAUTH-WG] auth-param syntax, was: OK to post OAuth = Bearer draft 15? > The core spec doesn=92t include these parameters. > =20 > From: William Mills [mailto:wmills@yahoo-inc.com]=20 > Sent: Tuesday, January 03, 2012 12:00 PM > To: Mike Jones; Julian Reschke > Cc: Mark Nottingham; Barry Leiba; OAuth WG > Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth = Bearer draft 15? > =20 > Why is Bearer dealing with this at all? the BNF for that stuff should = be part of the core spec, and additional values perhaps defined in = Bearer. > =20 > From: Mike Jones > To: William Mills ; Julian Reschke = =20 > Cc: Mark Nottingham ; Barry Leiba = ; OAuth WG =20 > Sent: Tuesday, January 3, 2012 11:46 AM > Subject: RE: [OAUTH-WG] auth-param syntax, was: OK to post OAuth = Bearer draft 15? > This is about the syntax for the scope, error, and error_description = parameters. The pertinent text from Section 3 is: > =20 > Producers of "scope" strings MUST NOT use characters outside the = set > %x21 / %x23-5B / %x5D-7E for representing the scope values and %x20 > for the delimiter. Producers of "error" and "error_description" > strings MUST NOT use characters outside the set %x20-21 / %x23-5B / > %x5D-7E for representing these values. Producers of "error-uri" > strings MUST NOT use characters outside the set %x21 / %x23-5B / > %x5D-7E for representing these values. Furthermore, "error-uri" > strings MUST conform to the URI-Reference syntax. In all these > cases, no character quoting will occur, as senders are prohibited > from using the %5C ('\') character. > =20 > Cheers, > -- Mike > =20 > From: William Mills [mailto:wmills@yahoo-inc.com]=20 > Sent: Tuesday, January 03, 2012 11:36 AM > To: Mike Jones; Julian Reschke > Cc: Mark Nottingham; Barry Leiba; OAuth WG > Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth = Bearer draft 15? > =20 > Is all this only around the scope parameter? My mail cited below is = with regards to the character set for a valid scope parameter, which we = should be able to define and then lean on the HTTPbis spec for the = actual parameter syntax. > =20 > From: Mike Jones > To: Julian Reschke =20 > Cc: Mark Nottingham ; Barry Leiba = ; OAuth WG =20 > Sent: Friday, December 30, 2011 3:19 PM > Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth = Bearer draft 15? >=20 > I did already back the statement that this is the working group = consensus with the e-mails attached in this note sent to you on December = 12, 2011: > - http://www.ietf.org/mail-archive/web/oauth/current/msg08042.html >=20 > But since that apparently wasn't convincing to you that this working = group decision represents more than "just me disagreeing with you", here = are references to individual messages referenced in the above e-mail: > - Eran Hammer-Lahav: = http://www.ietf.org/mail-archive/web/oauth/current/msg07698.html > - John Bradley: = http://www.ietf.org/mail-archive/web/oauth/current/msg07699.html > - William Mills: = http://www.ietf.org/mail-archive/web/oauth/current/msg07700.html > - Mike Jones: = http://www.ietf.org/mail-archive/web/oauth/current/msg07701.html > - Phil Hunt: = http://www.ietf.org/mail-archive/web/oauth/current/msg07702.html > - Justin Richer: = http://www.ietf.org/mail-archive/web/oauth/current/msg07692.html >=20 > As for your assertion that the specs are in conflict, yes, the Bearer = spec includes a different decision than a RECOMMENDED clause in the = HTTPbis spec (which was added after the Bearer text was already in = place). However, it is not violating any MUST clauses in the HTTPbis = spec. Given that no MUSTS are violated, I don't see it mandatory for = this tension to be resolved in favor of one spec or the other in order = for both to be approved as RFCs. I look forward to seeing that happen = soon in both cases (and for the OAuth core spec as well). >=20 > Best wishes, > -- Mike >=20 > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de]=20 > Sent: Friday, December 30, 2011 2:26 AM > To: Mike Jones > Cc: Barry Leiba; Mark Nottingham; OAuth WG > Subject: Re: auth-param syntax, was: [OAUTH-WG] OK to post OAuth = Bearer draft 15? >=20 > On 2011-12-29 22:18, Mike Jones wrote: > > You proposed, Julian "3. Do not specify the ABNF. The ABNF of the = WWW-Authenticate is defined in HTTPbis. Just state the names of the = parameters, their syntax *after* parsing and their semantics." > > > > About some of Mark Nottingham's comments, Barry wrote "Let me point = out that "this represents working-group consensus" is not always a valid = response. If the working group has actually considered the *issue*, = that might be OK. But if there's consensus for the chosen solution and = someone brings up a *new* issue with it, that issue needs to be = addressed anew." > > > > Relative to these two statements, I believe that I should remark at = this point that your proposed semantics of only considering the syntax = after potential quoting was explicitly considered earlier by the working = group and rejected. The consensus, instead, was for the present "no = quoting will occur for legal inputs" semantics. >=20 > It would be helpful if you could back this statement with pointers to = mails. As far as I can tell it's just you disagreeing with me. >=20 > Back to the facts: >=20 > a) the bearer spec defines an HTTP authentication scheme, and = normatively refers to HTTPbis Part7 for that >=20 > b) HTTPbis recommends new scheme definitions not to have their own = ABNF, as the header field syntax is defined by HTTPbis, not the = individual scheme >=20 > c) the bearer spec defines it's own ABNF nevertheless >=20 > So the two specs are in conflict, and we should resolve the conflict = one way or the other. >=20 > If you disagree with the recommendation in HTTPbis, then you really = really should come over to HTTPbis WG and argue your point of view. >=20 > If you agree with it, but think that the bearer spec can't follow the = recommendation, then it would be good to explain the reasoning = (optimally in the spec). >=20 > If you agree with it, and think the bearer spec *could* follow it, = then... change it, by all means. >=20 > Anyway, if this issue isn't resolved before IETF LC then it will be = raised again at that time. >=20 >=20 > > I believe that in the New Year the chairs and area directors will = need to decide how to proceed on this issue. (The working group = consensus, as I see it, is already both well-informed and clear on this = point, but I understand that that's not the only consideration.) It = would be good to see the spec finished shortly. > > ... >=20 > Best regards, Julian >=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 --Apple-Mail=_04B9746F-B6F3-4145-89FB-F1BF2D68CC37 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 You = are correct.  the Core spec should include this.  However for = one reason or another it is not in the core spec and probably will not = be, given that it is in last call.

One way or other = we need to identify the correct answer.

John = B.

On 2012-01-03, at 5:37 PM, William Mills = wrote:

OK, then the core spec = should.

= From: Mike Jones <Michael.Jones@microsoft.com>
To: William = Mills <wmills@yahoo-inc.com>; = Julian Reschke <julian.reschke@gmx.de> =
Cc: Mark Nottingham = <mnot@mnot.net>; Barry Leiba = <barryleiba@computer.org>; = OAuth WG <oauth@ietf.org> =
Sent: Tuesday, = January 3, 2012 12:20 PM
Subject: RE: [OAUTH-WG] auth-param syntax, was: OK to = post OAuth Bearer draft 15?
=20 =20
Sorry, I should have been more = precise.  The Core spec doesn=92t define how to transmit these = fields in the WWW-Authenticate response header field.  The Bearer spec does.
=20
 
=20
     &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;         -- Mike
=20=
 
=20
From: William Mills [mailto:wmills@yahoo-inc.com]
Sent: Tuesday, January 03, 2012 12:14 PM
To: Mike Jones; Julian Reschke
Cc: Mark Nottingham; Barry Leiba; OAuth WG
Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth = Bearer draft 15?
=20
 
=20
= http://tools.ietf.org/html/draft-ietf-oauth-v2-22#section-11.2.2 certainly has these as predefined registered parameters.  If the = definition there isn't strong enough, or in that spec, we should fix = that.  That is where these should be defined.
=20
 
=20
From: Mike Jones <Michael.Jones@microsoft.com>
To: William Mills <wmills@yahoo-inc.com>; = Julian Reschke <julian.reschke@gmx.de>
Cc: Mark Nottingham <mnot@mnot.net>; Barry Leiba <barryleiba@computer.org>; = OAuth WG <oauth@ietf.org>
Sent: Tuesday, January 3, 2012 12:00 PM
Subject: RE: [OAUTH-WG] auth-param syntax, was: OK to post OAuth = Bearer draft 15?
=20
The core spec doesn=92t = include these parameters.
= =20
 
=20
From: William Mills [mailto:wmills@yahoo-inc.com= ]
Sent: Tuesday, January 03, 2012 12:00 PM
To: Mike Jones; Julian Reschke
Cc: Mark Nottingham; Barry Leiba; OAuth WG
Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth = Bearer draft 15?
=20
 
=20
Why is Bearer dealing with this = at all?  the BNF for that stuff should be part of the core spec, = and additional values perhaps defined in Bearer.
=20
 
=20
From: Mike Jones <Michael.Jones@microsoft.com>
To: William Mills <wmills@yahoo-inc.com>; = Julian Reschke <julian.reschke@gmx.de>
Cc: Mark Nottingham <mnot@mnot.net>; Barry Leiba <barryleiba@computer.org>; = OAuth WG <oauth@ietf.org>
Sent: Tuesday, January 3, 2012 11:46 AM
Subject: RE: [OAUTH-WG] auth-param syntax, was: OK to post OAuth = Bearer draft 15?
=20
This is about the syntax for = the scope, error, and error_description parameters.  The pertinent = text from Section 3 is:
=20
 
=20
   = Producers of "scope" strings MUST NOT use characters outside the = set
=20
   %x21 / = %x23-5B / %x5D-7E for representing the scope values and %x20
=20
   for the = delimiter.  Producers of "error" and = "error_description"
=20
   strings = MUST NOT use characters outside the set %x20-21 / %x23-5B /
=20
   %x5D-7E = for representing these values.  Producers of = "error-uri"
=20
   strings = MUST NOT use characters outside the set %x21 / %x23-5B /
=20
   %x5D-7E = for representing these values.  Furthermore, = "error-uri"
=20
   strings = MUST conform to the URI-Reference syntax.  In all these
=20
   cases, = no character quoting will occur, as senders are prohibited
=20
   from = using the %5C ('\') character.
=20
 
=20
     &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;     Cheers,
=20
     &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;     -- Mike
=20
 
=20
From: William Mills [mailto:wmills@yahoo-inc.com= ]
Sent: Tuesday, January 03, 2012 11:36 AM
To: Mike Jones; Julian Reschke
Cc: Mark Nottingham; Barry Leiba; OAuth WG
Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth = Bearer draft 15?
=20
 
=20
Is all this only around the = scope parameter?  My mail cited below is with regards to the = character set for a valid scope parameter, which we should be able to = define and then lean on the HTTPbis spec for the actual parameter = syntax.
=20
 
=20
From: Mike Jones <Michael.Jones@microsoft.com>
To: Julian Reschke <julian.reschke@gmx.de>
Cc: Mark Nottingham <mnot@mnot.net>; Barry Leiba <barryleiba@computer.org>; = OAuth WG <oauth@ietf.org>
Sent: Friday, December 30, 2011 3:19 PM
Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth = Bearer draft 15?

I did already back the statement that this is the working group = consensus with the e-mails attached in this note sent to you on December = 12, 2011:
  - = http://www.ietf.org/mail-archive/web/oauth/current/msg08042.html

But since that apparently wasn't convincing to you that this working = group decision represents more than "just me disagreeing with you", here = are references to individual messages referenced in the above = e-mail:
  - Eran Hammer-Lahav: = http://www.ietf.org/mail-archive/web/oauth/current/msg07698.html
  - John Bradley:  = http://www.ietf.org/mail-archive/web/oauth/current/msg07699.html
  - William Mills:  = http://www.ietf.org/mail-archive/web/oauth/current/msg07700.html
  - Mike Jones:  = http://www.ietf.org/mail-archive/web/oauth/current/msg07701.html
  - Phil Hunt:  = http://www.ietf.org/mail-archive/web/oauth/current/msg07702.html
  - Justin Richer:  = http://www.ietf.org/mail-archive/web/oauth/current/msg07692.html

As for your assertion that the specs are in conflict, yes, the Bearer = spec includes a different decision than a RECOMMENDED clause in the = HTTPbis spec (which was added after the Bearer text was already in = place).  However, it is not violating any MUST clauses in the HTTPbis spec.  Given that no MUSTS are violated, I don't = see it mandatory for this tension to be resolved in favor of one spec or = the other in order for both to be approved as RFCs.  I look forward = to seeing that happen soon in both cases (and for the OAuth core spec as well).

            =     Best wishes,
            =     -- Mike

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]
Sent: Friday, December 30, 2011 2:26 AM
To: Mike Jones
Cc: Barry Leiba; Mark Nottingham; OAuth WG
Subject: Re: auth-param syntax, was: [OAUTH-WG] OK to post OAuth Bearer = draft 15?

On 2011-12-29 22:18, Mike Jones wrote:
> You proposed, Julian "3. Do not specify the ABNF. The ABNF of the = WWW-Authenticate is defined in HTTPbis. Just state the names of the = parameters, their syntax *after* parsing and their semantics."
>
> About some of Mark Nottingham's comments, Barry wrote "Let me point = out that "this represents working-group consensus" is not always a valid = response.  If the working group has actually considered the = *issue*, that might be OK.  But if there's consensus for the chosen solution and someone brings up a *new* issue with it, that = issue needs to be addressed anew."
>
> Relative to these two statements, I believe that I should remark at = this point that your proposed semantics of only considering the syntax = after potential quoting was explicitly considered earlier by the working = group and rejected.  The consensus, instead, was for the present "no quoting will occur for legal inputs" = semantics.

It would be helpful if you could back this statement with pointers to = mails. As far as I can tell it's just you disagreeing with me.

Back to the facts:

a) the bearer spec defines an HTTP authentication scheme, and = normatively refers to HTTPbis Part7 for that

b) HTTPbis recommends new scheme definitions not to have their own ABNF, = as the header field syntax is defined by HTTPbis, not the individual = scheme

c) the bearer spec defines it's own ABNF nevertheless

So the two specs are in conflict, and we should resolve the conflict one = way or the other.

If you disagree with the recommendation in HTTPbis, then you really = really should come over to HTTPbis WG and argue your point of view.

If you agree with it, but think that the bearer spec can't follow the = recommendation, then it would be good to explain the reasoning = (optimally in the spec).

If you agree with it, and think the bearer spec *could* follow it, = then... change it, by all means.

Anyway, if this issue isn't resolved before IETF LC then it will be = raised again at that time.


> I believe that in the New Year the chairs and area directors will = need to decide how to proceed on this issue.  (The working group = consensus, as I see it, is already both well-informed and clear on this = point, but I understand that that's not the only consideration.)  It would be good to see the spec finished shortly.
> ...

Best regards, Julian



_______________________________________________
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

= --Apple-Mail=_04B9746F-B6F3-4145-89FB-F1BF2D68CC37-- --Apple-Mail=_D3BA592D-451B-4992-AE08-2C7005B64389 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 DgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjAx MDQyMTQwMDJaMCMGCSqGSIb3DQEJBDEWBBRoeeW4L9Sf9qk2/fePwyV3qVKwmDCBpAYJKwYBBAGC NxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgZDMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzANBgkqhkiG9w0BAQEFAASC AQAdVAOm3YnC0Z4si4EKyhHHOODQqR0lPP9H+GULA61mTWssBXWTbGQKA01ssJqmgpwMRwqP4o7M MbltkJLL7Ksl/85uY/SVc8Nk/33G+d8xG9QwCFOuiRqeW0KBOlP6SWUcrNMHLUnx7jY38Pjfbzjz EEnJazBcOGntvuOkww7sKnlywqUY6KE3ObBka6MAUus+neYB1VJXUQ+oTtGNpfF8DJfvNoDvm/t4 TUcczX2kS3J+huGC6Aldv0mzVynqlCAK016BVRsJawrGpSWfwmoCwvEUx8HF2Irk01c1MjsAnRJh jwPKnW2Fs+CkQksfXG+1bJc2yjo+3pTjFRw1NISyAAAAAAAA --Apple-Mail=_D3BA592D-451B-4992-AE08-2C7005B64389-- From julian.reschke@gmx.de Wed Jan 4 14:01:26 2012 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 83C7C11E80C5 for ; Wed, 4 Jan 2012 14:01:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.918 X-Spam-Level: X-Spam-Status: No, score=-103.918 tagged_above=-999 required=5 tests=[AWL=-1.319, 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 w7XhKjjsjJZi for ; Wed, 4 Jan 2012 14:01:26 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 90EFE11E80A6 for ; Wed, 4 Jan 2012 14:01:25 -0800 (PST) Received: (qmail invoked by alias); 04 Jan 2012 22:01:19 -0000 Received: from p5DCC2522.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.37.34] by mail.gmx.net (mp008) with SMTP; 04 Jan 2012 23:01:19 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19Omr1pGglOPkqZch8E3Du/BWTpTIMEkbdtISaVVd 4NlfqySadGcw/0 Message-ID: <4F04CC2D.1080805@gmx.de> Date: Wed, 04 Jan 2012 23:01:17 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: John Bradley References: <4E1F6AAD24975D4BA5B16804296739435F763122@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739435F772D1D@TK5EX14MBXC283.redmond.corp.microsoft.com> <4EEF13F1.7030409@gmx.de> <4E1F6AAD24975D4BA5B16804296739435F78F5BB@TK5EX14MBXC283.redmond.corp.microsoft.com> <4EFD91B4.5050904@gmx.de> <4E1F6AAD24975D4BA5B16804296739435F790386@TK5EX14MBXC283.redmond.corp.microsoft.com> <1325619340.463.YahooMailNeo@web31808.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B16804296739435F7936E7@TK5EX14MBXC283.redmond.corp.microsoft.com> <1325620772.48511.YahooMailNeo@web31802.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B16804296739435F79376F@TK5EX14MBXC283.redmond.corp.microsoft.com> <1325621624.9908.YahooMailNeo@web31808.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B16804296739435F793829@TK5EX14MBXC283.redmond.corp.microsoft.com> <1325623068.88228.YahooMailNeo@web31816.mail.mud.yahoo.com> <5E5EA7F9-B4A0-4DCB-801C-3C0F4EC36A1E@ve7jtb.c om> In-Reply-To: <5E5EA7F9-B4A0-4DCB-801C-3C0F4EC36A1E@ve7jtb.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Barry Leiba , Mark Nottingham , OAuth WG Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft 15? 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, 04 Jan 2012 22:01:26 -0000 On 2012-01-04 22:40, John Bradley wrote: > You are correct. the Core spec should include this. However for one > reason or another it is not in the core spec and probably will not be, > given that it is in last call. > ... The datatracker says: "AD Evaluation::Revised ID Needed" () As far as I recall, this includes other changes needed by the bearer spec. Best regards, Julian From ve7jtb@ve7jtb.com Wed Jan 4 14:11:11 2012 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 4DE9521F85B3 for ; Wed, 4 Jan 2012 14:11:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nnfSQ6QMBE3k for ; Wed, 4 Jan 2012 14:11:10 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2954B21F85AF for ; Wed, 4 Jan 2012 14:10:47 -0800 (PST) Received: by ggnk5 with SMTP id k5so11913423ggn.31 for ; Wed, 04 Jan 2012 14:10:47 -0800 (PST) Received: by 10.101.174.1 with SMTP id b1mr23181379anp.1.1325715047355; Wed, 04 Jan 2012 14:10:47 -0800 (PST) Received: from [192.168.1.213] ([190.22.74.206]) by mx.google.com with ESMTPS id s12sm140055004and.15.2012.01.04.14.10.42 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 04 Jan 2012 14:10:46 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/signed; boundary="Apple-Mail=_F644511A-14A4-4C49-9753-B4D687C19782"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <4F04CC2D.1080805@gmx.de> Date: Wed, 4 Jan 2012 19:10:38 -0300 Message-Id: <7570AAA5-3C7B-409B-99AE-BC9C91F729FB@ve7jtb.com> References: <4E1F6AAD24975D4BA5B16804296739435F763122@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739435F772D1D@TK5EX14MBXC283.redmond.corp.microsoft.com> <4EEF13F1.7030409@gmx.de> <4E1F6AAD24975D4BA5B16804296739435F78F5BB@TK5EX14MBXC283.redmond.corp.microsoft.com> <4EFD91B4.5050904@gmx.de> <4E1F6AAD24975D4BA5B16804296739435F790386@TK5EX14MBXC283.redmond.corp.microsoft.com> <1325619340.463.YahooMailNeo@web31808.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B16804296739435F7936E7@TK5EX14MBXC283.redmond.corp.microsoft.com> <1325620772.48511.YahooMailNeo@web31802.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B16804296739435F79376F@TK5EX14MBXC283.redmond.corp.microsoft.com> <1325621624.9908.YahooMailNeo@web31808.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B16804296739435F793829@TK5EX14MBXC283.redmond.corp.microsoft.com> <1325623068.88228.YahooMailNeo@web31816.mail.mud.yahoo.com> <5E5EA7F9-B4A0-4DCB-801C-3C0F4EC36A1E@ve7jtb.c om> <4F04CC2D.1080805@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1251.1) Cc: Barry Leiba , Mark Nottingham , OAuth WG Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft 15? 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, 04 Jan 2012 22:11:11 -0000 --Apple-Mail=_F644511A-14A4-4C49-9753-B4D687C19782 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Don't get me wrong, I agree that it should be in core. I just don't want to hold up core for something that only bearer seems = to care about. If there is consensus that it should be fixed in core then lets do that = rather than leaving it up to bearer, MAC and token types not yet = imagined to do it independently. John B. On 2012-01-04, at 7:01 PM, Julian Reschke wrote: > On 2012-01-04 22:40, John Bradley wrote: >> You are correct. the Core spec should include this. However for one >> reason or another it is not in the core spec and probably will not = be, >> given that it is in last call. >> ... >=20 > The datatracker says: >=20 > "AD Evaluation::Revised ID Needed" = () >=20 > As far as I recall, this includes other changes needed by the bearer = spec. >=20 > Best regards, Julian --Apple-Mail=_F644511A-14A4-4C49-9753-B4D687C19782 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 DgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjAx MDQyMjEwMzlaMCMGCSqGSIb3DQEJBDEWBBS0Ermf1F8OcExra2/j/MQabJL8gzCBpAYJKwYBBAGC NxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgZDMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzANBgkqhkiG9w0BAQEFAASC AQAGO/fEpzG6G6itri8NdzKumXErmyfFscUDOhlzjHMSJ2YEDr6VvOhr3ijt4bXboH/pn67THzj5 ppdVUm4J/csLpZVP5HKqjoV0NVlrTvmRZ7svD0gwoMbvlRYs4toucf9P2SLbqeiC8IGlwRUBJGCn 99XqXTR+kId6ONH9iZvOJKdrELF7AZ6agM4wtErzNZMTkH4opycd5vaVMCzvJCWWdDztZ/3/TkgV K1Aul0zECV5vdVKU6fUJ2EZa8KpadwcdDejsZ7U7vVeONna5tIwyaj3rZtLhxslH7aDAFHj3l0Mx 1JDgF1Nzh5Yr5OC+JJF1Vrf7iUGIorD8LWyxiodqAAAAAAAA --Apple-Mail=_F644511A-14A4-4C49-9753-B4D687C19782-- From torsten@lodderstedt.net Wed Jan 4 14:15:00 2012 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 C973711E80D8 for ; Wed, 4 Jan 2012 14:15:00 -0800 (PST) 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 wjOjkFD6B8jZ for ; Wed, 4 Jan 2012 14:15:00 -0800 (PST) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.26]) by ietfa.amsl.com (Postfix) with ESMTP id E2CE911E80B6 for ; Wed, 4 Jan 2012 14:14:59 -0800 (PST) Received: from [79.253.13.18] (helo=[192.168.71.41]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1RiZ6n-0002QE-8v; Wed, 04 Jan 2012 23:14:57 +0100 Message-ID: <4F04CF60.1050000@lodderstedt.net> Date: Wed, 04 Jan 2012 23:14:56 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Michael Thomas References: <8AB6F5CC-E9A2-4A07-9AA0-83FB7C67A221@oracle.com> <4EEA3951.5010904@mtcc.com> <4EEB5BDD.7080401@mtcc.com> <4F038CB9.1040403@mtcc.com> <4F0394D6.1090006@mtcc.com> <4F04AAAE.6080702@mtcc.com> <4F04ACE4.1070006@stpeter.im> <4F04B101.3070708@mtcc.com> <4F04BF70.3010501@mtcc.com> In-Reply-To: <4F04BF70.3010501@mtcc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: Barry Leiba , oauth WG Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011 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, 04 Jan 2012 22:15:00 -0000 Hi Michael, Am 04.01.2012 22:06, schrieb Michael Thomas: > I think the "perhaps unwisely" goes to the heart of my objection. You > might as well be talking about "perhaps unwisely" driving a car, > or "perhaps unwisely" eating food: the reality is that people download > apps by the *billions*. When I was initially blown off, many of the > participants including document editors implied that only idiots get > apps for their phones. That is *completely* unhelpful as the reality > is that OAUTH's use is hugely if not primarily deployed in that sort of > environment. I fully agree with you. That's why the core spec and the threat document both consider native apps. > > This is a threat that cuts to the very heart of what OAUTH is, and > purports > to defend against: keeping user credentials out of the hands of an > untrusted third party. If there really aren't any good ways to > mitigate this > in an app environment, why is OAUTH being deployed so aggressively there? > Shouldn't the threat draft say in blinking bold: "DEPLOYING OAUTH > IN NATIVE APPS CONSIDERED HARMFUL"? You lost me. Is the situation getting any worse with OAuth? I don't think so. I think the situation is getting better, probably not as you might expect. The key question is: Why do we aim on "keeping user credentials out of the hands of an untrusted third party"? 1) To prevent phishing or 2) to prevent leakage of end-user credentials due to inappropriate handling or weak defence on the 3rd party? wrt 1) I don't think so. I don't see how an authorization server shall validate the authenticity and trustworthiness of a client-side application. We already state this in section 4.4.1.4. of the threat document. ----------------------- It is not the task of the authorization server to protect the end-user's device from malicious software. This is the responsibility of the platform running on the particular device probably in cooperation with other components of the respective ecosystem (e.g. an application management infrastructure). The sole responsibility of the authorization server is to control access to the end-user's resources living in resource servers and to prevent unauthorized access to them. ----------------------- wrt 2) Yes, I think that's the reason. And OAuth is a appropriate protocol to achieve this goal, even for mobile apps. Why? A typical mobile application consists of the app itself on the device and a corresponding backend service storing user data and implementing business and integration logic. Let's assume this application features address book import from other service providers. W/o OAuth, the app would gather the end-user's credential for a certain address book service and pass it to its backend service. This service in turn uses this credentials to access the service provider's API. So in such a scenario the following parties get in touch with the user credentials: - the app - the app's backend service - the address book resource server What threats do you see here? And which is most likely to occur? My favorite is an attack against the log files or the database of the backend service in order to obtain the end-users passwords for the resource server. Why? Because the cost/benefit ratio for an attacker is much better then attacking any app installation on a device and the protective measure on the resource server might be more appropriate then on the client side (backend service). OAuth mitigates this kind of attack by reducing the number of parties handling user credentials to the authorization server and the user agent. So even if the app itself would be the user agent (which is not recommended), it would directly interact with the authorization server and the app's backend service would use tokens instead of end-user credentials. Moreover, the recommended way is to let the app delegate the flow to a trusted system component on the user's device, such as the system browser or an account manager. In that case, the 3rd party is not getting in touch with the user credentials at all. I think the key question is whether anyone expects OAuth to solve the phishing problem. I don't think this is its main purpose, but it could facilitate to overcome the habit to enter user credentials everywhere. And this in turn may contribute to the fight against phishing. regards, Torsten. > Mike > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From Michael.Jones@microsoft.com Wed Jan 4 14:17:16 2012 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 0B47321F85C2 for ; Wed, 4 Jan 2012 14:17:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.529 X-Spam-Level: X-Spam-Status: No, score=-3.529 tagged_above=-999 required=5 tests=[AWL=0.069, 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 FRA-ZI6fqHk5 for ; Wed, 4 Jan 2012 14:17:09 -0800 (PST) Received: from AM1EHSOBE004.bigfish.com (am1ehsobe004.messaging.microsoft.com [213.199.154.207]) by ietfa.amsl.com (Postfix) with ESMTP id CFC4421F85BF for ; Wed, 4 Jan 2012 14:17:08 -0800 (PST) Received: from mail38-am1-R.bigfish.com (10.3.201.251) by AM1EHSOBE004.bigfish.com (10.3.204.24) with Microsoft SMTP Server id 14.1.225.23; Wed, 4 Jan 2012 22:17:08 +0000 Received: from mail38-am1 (localhost [127.0.0.1]) by mail38-am1-R.bigfish.com (Postfix) with ESMTP id DC146180180; Wed, 4 Jan 2012 22:17:07 +0000 (UTC) X-SpamScore: -48 X-BigFish: VS-48(zz9371I1415J2174M936eKc85fh146fK542M1432N98dKzz1202hzz8275ch1033IL8275bh8275dhz2fh2a8h668h839h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC106.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail38-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC106.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail38-am1 (localhost.localdomain [127.0.0.1]) by mail38-am1 (MessageSwitch) id 1325715426798943_13152; Wed, 4 Jan 2012 22:17:06 +0000 (UTC) Received: from AM1EHSMHS001.bigfish.com (unknown [10.3.201.240]) by mail38-am1.bigfish.com (Postfix) with ESMTP id 9753E5E0049; Wed, 4 Jan 2012 22:17:06 +0000 (UTC) Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS001.bigfish.com (10.3.207.101) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 4 Jan 2012 22:17:04 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.180]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.02.0247.005; Wed, 4 Jan 2012 14:16:59 -0800 From: Mike Jones To: John Bradley , William Mills Thread-Topic: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft 15? Thread-Index: AQHMyk7k0nsxP6uHFU2ycTUC8uzaDZX7CnqQgACLbwD//3oSIIAAieYA//97QxCAAIt2AIABo7eA//9/gHA= Date: Wed, 4 Jan 2012 22:17:02 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739435F7A9464@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739435F763122@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739435F772D1D@TK5EX14MBXC283.redmond.corp.microsoft.com> <4EEF13F1.7030409@gmx.de> <4E1F6AAD24975D4BA5B16804296739435F78F5BB@TK5EX14MBXC283.redmond.corp.microsoft.com> <4EFD91B4.5050904@gmx.de> <4E1F6AAD24975D4BA5B16804296739435F790386@TK5EX14MBXC283.redmond.corp.microsoft.com> <1325619340.463.YahooMailNeo@web31808.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B16804296739435F7936E7@TK5EX14MBXC283.redmond.corp.microsoft.com> <1325620772.48511.YahooMailNeo@web31802.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B16804296739435F79376F@TK5EX14MBXC283.redmond.corp.microsoft.com> <1325621624.9908.YahooMailNeo@web31808.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B16804296739435F793829@TK5EX14MBXC283.redmond.corp.microsoft.com> <1325623068.88228.YahooMailNeo@web31816.mail.mud.yahoo.com> <5E5EA7F9-B4A0-4DCB-801C-3C0F4EC36A1E@ve7jtb.com> In-Reply-To: <5E5EA7F9-B4A0-4DCB-801C-3C0F4EC36A1E@ve7jtb.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.73] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739435F7A9464TK5EX14MBXC284r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: Julian Reschke , Mark Nottingham , Barry Leiba , OAuth WG Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft 15? 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, 04 Jan 2012 22:17:16 -0000 --_000_4E1F6AAD24975D4BA5B16804296739435F7A9464TK5EX14MBXC284r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There are actually two parts to "this" as I see it: 1. Defining the syntax for the acceptable contents of the scope, error, er= ror_description, and error_uri parameters. 2. Defining the means by which these values are transmitted in WWW-Authent= icate response header fields for Bearer tokens. I would be fine seeing part 1 added to the core spec. (In fact, there is a= tracked issue OAuth ticket 27 requiring that this occur for the scope parameter.) Given that the= core spec is, by design, agnostic of the method used to access protected r= esource (including being agnostic of the use of the WWW-Authenticate field = by the Bearer spec), I believe that it would be inappropriate to add part 2= to the core spec. Cheers, -- Mike From: John Bradley [mailto:ve7jtb@ve7jtb.com] Sent: Wednesday, January 04, 2012 1:40 PM To: William Mills Cc: Mike Jones; Julian Reschke; Mark Nottingham; Barry Leiba; OAuth WG Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer dra= ft 15? You are correct. the Core spec should include this. However for one reaso= n or another it is not in the core spec and probably will not be, given tha= t it is in last call. One way or other we need to identify the correct answer. John B. On 2012-01-03, at 5:37 PM, William Mills wrote: OK, then the core spec should. ________________________________ From: Mike Jones > To: William Mills >; Juli= an Reschke > Cc: Mark Nottingham >; Barry Leiba >; OAuth WG > Sent: Tuesday, January 3, 2012 12:20 PM Subject: RE: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer dra= ft 15? Sorry, I should have been more precise. The Core spec doesn't define how t= o transmit these fields in the WWW-Authenticate response header field. The= Bearer spec does. -- Mike From: William Mills [mailto:wmills@yahoo-inc.com] Sent: Tuesday, January 03, 2012 12:14 PM To: Mike Jones; Julian Reschke Cc: Mark Nottingham; Barry Leiba; OAuth WG Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer dra= ft 15? http://tools.ietf.org/html/draft-ietf-oauth-v2-22#section-11.2.2 certainly = has these as predefined registered parameters. If the definition there isn= 't strong enough, or in that spec, we should fix that. That is where these= should be defined. ________________________________ From: Mike Jones > To: William Mills >; Juli= an Reschke > Cc: Mark Nottingham >; Barry Leiba >; OAuth WG > Sent: Tuesday, January 3, 2012 12:00 PM Subject: RE: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer dra= ft 15? The core spec doesn't include these parameters. From: William Mills [mailto:wmills@yahoo-inc.com] Sent: Tuesday, January 03, 2012 12:00 PM To: Mike Jones; Julian Reschke Cc: Mark Nottingham; Barry Leiba; OAuth WG Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer dra= ft 15? Why is Bearer dealing with this at all? the BNF for that stuff should be p= art of the core spec, and additional values perhaps defined in Bearer. ________________________________ From: Mike Jones > To: William Mills >; Juli= an Reschke > Cc: Mark Nottingham >; Barry Leiba >; OAuth WG > Sent: Tuesday, January 3, 2012 11:46 AM Subject: RE: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer dra= ft 15? This is about the syntax for the scope, error, and error_description parame= ters. The pertinent text from Section 3 is: Producers of "scope" strings MUST NOT use characters outside the set %x21 / %x23-5B / %x5D-7E for representing the scope values and %x20 for the delimiter. Producers of "error" and "error_description" strings MUST NOT use characters outside the set %x20-21 / %x23-5B / %x5D-7E for representing these values. Producers of "error-uri" strings MUST NOT use characters outside the set %x21 / %x23-5B / %x5D-7E for representing these values. Furthermore, "error-uri" strings MUST conform to the URI-Reference syntax. In all these cases, no character quoting will occur, as senders are prohibited from using the %5C ('\') character. Cheers, -- Mike From: William Mills [mailto:wmills@yahoo-inc.com] Sent: Tuesday, January 03, 2012 11:36 AM To: Mike Jones; Julian Reschke Cc: Mark Nottingham; Barry Leiba; OAuth WG Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer dra= ft 15? Is all this only around the scope parameter? My mail cited below is with r= egards to the character set for a valid scope parameter, which we should be= able to define and then lean on the HTTPbis spec for the actual parameter = syntax. ________________________________ From: Mike Jones > To: Julian Reschke > Cc: Mark Nottingham >; Barry Leiba >; OAuth WG > Sent: Friday, December 30, 2011 3:19 PM Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer dra= ft 15? I did already back the statement that this is the working group consensus w= ith the e-mails attached in this note sent to you on December 12, 2011: - http://www.ietf.org/mail-archive/web/oauth/current/msg08042.html But since that apparently wasn't convincing to you that this working group = decision represents more than "just me disagreeing with you", here are refe= rences to individual messages referenced in the above e-mail: - Eran Hammer-Lahav: http://www.ietf.org/mail-archive/web/oauth/current/m= sg07698.html - John Bradley: http://www.ietf.org/mail-archive/web/oauth/current/msg07= 699.html - William Mills: http://www.ietf.org/mail-archive/web/oauth/current/msg0= 7700.html - Mike Jones: http://www.ietf.org/mail-archive/web/oauth/current/msg0770= 1.html - Phil Hunt: http://www.ietf.org/mail-archive/web/oauth/current/msg07702= .html - Justin Richer: http://www.ietf.org/mail-archive/web/oauth/current/msg0= 7692.html As for your assertion that the specs are in conflict, yes, the Bearer spec = includes a different decision than a RECOMMENDED clause in the HTTPbis spec= (which was added after the Bearer text was already in place). However, it= is not violating any MUST clauses in the HTTPbis spec. Given that no MUST= S are violated, I don't see it mandatory for this tension to be resolved in= favor of one spec or the other in order for both to be approved as RFCs. = I look forward to seeing that happen soon in both cases (and for the OAuth = core spec as well). Best wishes, -- Mike -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Friday, December 30, 2011 2:26 AM To: Mike Jones Cc: Barry Leiba; Mark Nottingham; OAuth WG Subject: Re: auth-param syntax, was: [OAUTH-WG] OK to post OAuth Bearer dra= ft 15? On 2011-12-29 22:18, Mike Jones wrote: > You proposed, Julian "3. Do not specify the ABNF. The ABNF of the WWW-Aut= henticate is defined in HTTPbis. Just state the names of the parameters, th= eir syntax *after* parsing and their semantics." > > About some of Mark Nottingham's comments, Barry wrote "Let me point out t= hat "this represents working-group consensus" is not always a valid respons= e. If the working group has actually considered the *issue*, that might be= OK. But if there's consensus for the chosen solution and someone brings u= p a *new* issue with it, that issue needs to be addressed anew." > > Relative to these two statements, I believe that I should remark at this = point that your proposed semantics of only considering the syntax after pot= ential quoting was explicitly considered earlier by the working group and r= ejected. The consensus, instead, was for the present "no quoting will occu= r for legal inputs" semantics. It would be helpful if you could back this statement with pointers to mails= . As far as I can tell it's just you disagreeing with me. Back to the facts: a) the bearer spec defines an HTTP authentication scheme, and normatively r= efers to HTTPbis Part7 for that b) HTTPbis recommends new scheme definitions not to have their own ABNF, as= the header field syntax is defined by HTTPbis, not the individual scheme c) the bearer spec defines it's own ABNF nevertheless So the two specs are in conflict, and we should resolve the conflict one wa= y or the other. If you disagree with the recommendation in HTTPbis, then you really really = should come over to HTTPbis WG and argue your point of view. If you agree with it, but think that the bearer spec can't follow the recom= mendation, then it would be good to explain the reasoning (optimally in the= spec). If you agree with it, and think the bearer spec *could* follow it, then... = change it, by all means. Anyway, if this issue isn't resolved before IETF LC then it will be raised = again at that time. > I believe that in the New Year the chairs and area directors will need to= decide how to proceed on this issue. (The working group consensus, as I s= ee it, is already both well-informed and clear on this point, but I underst= and that that's not the only consideration.) It would be good to see the s= pec finished shortly. > ... 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 --_000_4E1F6AAD24975D4BA5B16804296739435F7A9464TK5EX14MBXC284r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

There are actually two pa= rts to “this” as I see it:

1.  Defining the syn= tax for the acceptable contents of the scope, error, error_description, and= error_uri parameters.

2.  Defining the mea= ns by which these values are transmitted in WWW-Authenticate response heade= r fields for Bearer tokens.

 <= /p>

I would be fine seeing pa= rt 1 added to the core spec.  (In fact, there is a tracked issue OAuth ticket= 27 requiring that this occur for the scope parameter.)  Given tha= t the core spec is, by design, agnostic of the method used to access protec= ted resource (including being agnostic of the use of the WWW-Authenticate field by the Bearer spec), I believe th= at it would be inappropriate to add part 2 to the core spec.

 <= /p>

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;         Cheers,

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

 <= /p>

From: John Bra= dley [mailto:ve7jtb@ve7jtb.com]
Sent: Wednesday, January 04, 2012 1:40 PM
To: William Mills
Cc: Mike Jones; Julian Reschke; Mark Nottingham; Barry Leiba; OAuth = WG
Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bea= rer draft 15?

 

You are correct.  the Core spec should include = this.  However for one reason or another it is not in the core spec an= d probably will not be, given that it is in last call.

 

One way or other we need to identify the correct ans= wer.

 

John B.

 

On 2012-01-03, at 5:37 PM, William Mills wrote:=



OK, then the core s= pec should.

 

<= span style=3D"font-size:10.0pt;font-family:"Arial","sans-ser= if";color:black">From: Mike Jones &l= t;Michael.Jones@microsoft.co= m>
To: William Mills <wmills= @yahoo-inc.com>; Julian Reschke <julian.reschke@gmx.de>
Cc: Mark Nottingham <mnot@mnot.n= et>; Barry Leiba <barr= yleiba@computer.org>; OAuth WG <oauth@ietf.org>
Sent: Tuesday, January 3, 2012 12:20 PM
Subject: RE: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bea= rer draft 15?

Sorry, I should have been more precise.  The Cor= e spec doesn’t define how to transmit these fields in the WWW-Authent= icate response header field.  The Bearer spec does.

 <= /span>

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

 <= /span>

From: William Mills [mailto:wmills@yahoo-inc.c= om]
Sent: Tuesday, January 03, 2012 12:14 PM
To: Mike Jones; Julian Reschke
Cc: Mark Nottingham; Barry Leiba; OAuth WG
Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bea= rer draft 15?

 

http://tools.ietf.org/html/draft-ietf-oauth-v2-22#sec= tion-11.2.2 certainly has these as predefined registered parameters.  If the definition there isn't strong enough, = or in that spec, we should fix that.  That is where these should be de= fined.

 

From: Mike Jones <Michael.Jones@microsoft.com>
To: William Mills <wmills@yahoo-inc.com>; Julian Reschke <julian.reschke@gmx.de>
Cc: Mark Nottingham <mnot@mnot.net>; Barry Leiba <barryleiba@computer.org>; OAuth WG &= lt;oauth@ietf.org&g= t;
Sent: Tuesday, January 3, 2012 12:00 PM
Subject: RE: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bea= rer draft 15?

The core spec doesn’t include these parameters.=

 <= /span>

From: William Mills [mailto:= wmills@yahoo-inc.com]
Sent: Tuesday, January 03, 2012 12:00 PM
To: Mike Jones; Julian Reschke
Cc: Mark Nottingham; Barry Leiba; OAuth WG
Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bea= rer draft 15?

 

Why is Bearer dealing with this at all?  the BNF f= or that stuff should be part of the core spec, and additional values perhap= s defined in Bearer.

 

From: Mike Jones <Michael.Jones@microsoft.com>
To: William Mills <wmills@yahoo-inc.com>; Julian Reschke <julian.reschke@gmx.de>
Cc: Mark Nottingham <mnot@mnot.net>; Barry Leiba <barryleiba@computer.org>; OAuth WG &= lt;oauth@ietf.org&g= t;
Sent: Tuesday, January 3, 2012 11:46 AM
Subject: RE: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bea= rer draft 15?

This is about the syntax for the scope, error, and er= ror_description parameters.  The pertinent text from Section 3 is:

 <= /span>

   Producers of "scope&quo= t; strings MUST NOT use characters outside the set

   %x21 / %x23-5B / %x5D-7E for= representing the scope values and %x20<= o:p>

   for the delimiter.  Pro= ducers of "error" and "error_description"

   strings MUST NOT use charact= ers outside the set %x20-21 / %x23-5B /<= o:p>

   %x5D-7E for representing the= se values.  Producers of "error-uri"

   strings MUST NOT use charact= ers outside the set %x21 / %x23-5B /

   %x5D-7E for representing the= se values.  Furthermore, "error-uri"

   strings MUST conform to the = URI-Reference syntax.  In all these=

   cases, no character quoting = will occur, as senders are prohibited

   from using the %5C ('\') cha= racter.

 <= /span>

         = ;            &n= bsp;            = ;            &n= bsp;            = ; Cheers,

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

 <= /span>

From: William Mills [mailto:= wmills@yahoo-inc.com]
Sent: Tuesday, January 03, 2012 11:36 AM
To: Mike Jones; Julian Reschke
Cc: Mark Nottingham; Barry Leiba; OAuth WG
Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bea= rer draft 15?

 

Is all this only around the scope parameter?  My m= ail cited below is with regards to the character set for a valid scope para= meter, which we should be able to define and then lean on the HTTPbis spec for the actual parameter syntax.

 

From: Mike Jones <Michael.Jones@microsoft.com>
To: Julian Reschke <julian.reschke@gmx.de>
Cc: Mark Nottingham <mnot@mnot.net>; Barry Leiba <barryleiba@computer.org>; OAuth WG &= lt;oauth@ietf.org&g= t;
Sent: Friday, December 30, 2011 3:19 PM
Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bea= rer draft 15?

I did already back the statement that this is the working group consensus w= ith the e-mails attached in this note sent to you on December 12, 2011:
  - http://www.ietf.org/mail-archive/web/oauth/current/msg08042.html

But since that apparently wasn't convincing to you that this working group = decision represents more than "just me disagreeing with you", her= e are references to individual messages referenced in the above e-mail:
  - Eran Hammer-Lahav: http://www.ietf.org/mail-archive/web/oauth/current/msg07698.html
  - John Bradley:  http://www.ietf.org/mail-archive/web/oauth/current/msg07699.html
  - William Mills:  http://www.ietf.org/mail-archive/web/oauth/current/msg07700.html
  - Mike Jones:  http://www.ietf.org/mail-archive/web/oauth/current/msg07701.html
  - Phil Hunt:  http://www.ietf.org/mail-archive/web/oauth/current/msg07702.html
  - Justin Richer:  http://www.ietf.org/mail-archive/web/oauth/current/msg07692.html

As for your assertion that the specs are in conflict, yes, the Bearer spec = includes a different decision than a RECOMMENDED clause in the HTTPbis spec= (which was added after the Bearer text was already in place).  Howeve= r, it is not violating any MUST clauses in the HTTPbis spec.  Given that no MUSTS are violated, I don't see i= t mandatory for this tension to be resolved in favor of one spec or the oth= er in order for both to be approved as RFCs.  I look forward to seeing= that happen soon in both cases (and for the OAuth core spec as well).

               = Best wishes,
               = -- Mike

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]
Sent: Friday, December 30, 2011 2:26 AM
To: Mike Jones
Cc: Barry Leiba; Mark Nottingham; OAuth WG
Subject: Re: auth-param syntax, was: [OAUTH-WG] OK to post OAuth Bearer dra= ft 15?

On 2011-12-29 22:18, Mike Jones wrote:
> You proposed, Julian "3. Do not specify the ABNF. The ABNF of the= WWW-Authenticate is defined in HTTPbis. Just state the names of the parame= ters, their syntax *after* parsing and their semantics."
>
> About some of Mark Nottingham's comments, Barry wrote "Let me poi= nt out that "this represents working-group consensus" is not alwa= ys a valid response.  If the working group has actually considered the= *issue*, that might be OK.  But if there's consensus for the chosen solution and someone brings up a *new* issue with it, that issu= e needs to be addressed anew."
>
> Relative to these two statements, I believe that I should remark at th= is point that your proposed semantics of only considering the syntax after = potential quoting was explicitly considered earlier by the working group an= d rejected.  The consensus, instead, was for the present "no quoting will occur for legal inputs" sem= antics.

It would be helpful if you could back this statement with pointers to mails= . As far as I can tell it's just you disagreeing with me.

Back to the facts:

a) the bearer spec defines an HTTP authentication scheme, and normatively r= efers to HTTPbis Part7 for that

b) HTTPbis recommends new scheme definitions not to have their own ABNF, as= the header field syntax is defined by HTTPbis, not the individual scheme
c) the bearer spec defines it's own ABNF nevertheless

So the two specs are in conflict, and we should resolve the conflict one wa= y or the other.

If you disagree with the recommendation in HTTPbis, then you really really = should come over to HTTPbis WG and argue your point of view.

If you agree with it, but think that the bearer spec can't follow the recom= mendation, then it would be good to explain the reasoning (optimally in the= spec).

If you agree with it, and think the bearer spec *could* follow it, then... = change it, by all means.

Anyway, if this issue isn't resolved before IETF LC then it will be raised = again at that time.


> I believe that in the New Year the chairs and area directors will need= to decide how to proceed on this issue.  (The working group consensus= , as I see it, is already both well-informed and clear on this point, but I= understand that that's not the only consideration.)  It would be good to see the spec finished shortly.
> ...

Best regards, Julian



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

 

 

 

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

 

--_000_4E1F6AAD24975D4BA5B16804296739435F7A9464TK5EX14MBXC284r_-- From julian.reschke@gmx.de Wed Jan 4 14:22:17 2012 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 D904B21F860F for ; Wed, 4 Jan 2012 14:22:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.824 X-Spam-Level: X-Spam-Status: No, score=-103.824 tagged_above=-999 required=5 tests=[AWL=-1.225, 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 RIIgKXY50Fz8 for ; Wed, 4 Jan 2012 14:22:13 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id B5A3721F860E for ; Wed, 4 Jan 2012 14:22:12 -0800 (PST) Received: (qmail invoked by alias); 04 Jan 2012 22:22:11 -0000 Received: from p5DCC2522.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.37.34] by mail.gmx.net (mp025) with SMTP; 04 Jan 2012 23:22:11 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX188hSpHTu48pbSk2G1IsW89G1i+1LpxPXdY3KtVqI h9iIkIvMuiHjfC Message-ID: <4F04D111.9060702@gmx.de> Date: Wed, 04 Jan 2012 23:22:09 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Mike Jones References: <4E1F6AAD24975D4BA5B16804296739435F763122@TK5EX14MBXC283.redmond.corp.microsoft.com> <4EEF13F1.7030409@gmx.de> <4E1F6AAD24975D4BA5B16804296739435F78F5BB@TK5EX14MBXC283.redmond.corp.microsoft.com> <4EFD91B4.5050904@gmx.de> <4E1F6AAD24975D4BA5B16804296739435F790386@TK5EX14MBXC283.redmond.corp.microsoft.com> <1325619340.463.YahooMailNeo@web31808.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B16804296739435F7936E7@TK5EX14MBXC283.redmond.corp.microsoft.com> <1325620772.48511.YahooMailNeo@web31802.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B16804296739435F79376F@TK5EX14MBXC283.redmond.corp.microsoft.com> <1325621624.9908.YahooMailNeo@web31808.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B16804296739435F793829@TK5EX14MBXC283.redmond.corp.microsoft.com> <1325623068.88228.YahooMailNeo@web31816.mail.mud.yahoo.com> <5E5EA7F9-B4A0-4DCB-801C-3C0F4EC36A1E@ve7jtb.com> <4E1F6AAD24975D4BA5B16804296739435F7A9464@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739435F7A9464@TK5EX14MBXC284.redmond.corp.microsoft.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: Barry Leiba , Mark Nottingham , OAuth WG Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft 15? 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, 04 Jan 2012 22:22:17 -0000 On 2012-01-04 23:17, Mike Jones wrote: > There are actually two parts to “this” as I see it: > > 1. Defining the syntax for the acceptable contents of the scope, error, > error_description, and error_uri parameters. > > 2. Defining the means by which these values are transmitted in > WWW-Authenticate response header fields for Bearer tokens. > > I would be fine seeing part 1 added to the core spec. (In fact, there is > a tracked issue OAuth ticket 27 > requiring that this > occur for the scope parameter.) Given that the core spec is, by design, > agnostic of the method used to access protected resource (including > being agnostic of the use of the WWW-Authenticate field by the Bearer > spec), I believe that it would be inappropriate to add part 2 to the > core spec. > ... +1 From mike@mtcc.com Wed Jan 4 15:40:25 2012 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 9807621F873A for ; Wed, 4 Jan 2012 15:40:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id itytFqMXvw36 for ; Wed, 4 Jan 2012 15:40:24 -0800 (PST) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 89AF221F8715 for ; Wed, 4 Jan 2012 15:40:24 -0800 (PST) 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 q04NeIal004115 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 4 Jan 2012 15:40:19 -0800 Message-ID: <4F04E362.5070406@mtcc.com> Date: Wed, 04 Jan 2012 15:40:18 -0800 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: <8AB6F5CC-E9A2-4A07-9AA0-83FB7C67A221@oracle.com> <4EEA3951.5010904@mtcc.com> <4EEB5BDD.7080401@mtcc.com> <4F038CB9.1040403@mtcc.com> <4F0394D6.1090006@mtcc.com> <4F04AAAE.6080702@mtcc.com> <4F04ACE4.1070006@stpeter.im> <4F04B101.3070708@mtcc.com> <4F04BF70.3010501@mtcc.com> <4F04CF60.1050000@lodderstedt.net> In-Reply-To: <4F04CF60.1050000@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=8112; t=1325720421; x=1326584421; 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]=20WGLC=20on=20draft-ietf-oau th-v2-threatmodel-01,=20ends=209=0A=20Dec=202011 |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=IkQUin8GIGKtkEXMqJht9qxVjyial+GeoIQCGGy0lL4=; b=YtLz5lAlYYw9FTim3dxq51tSgyq8E+DJ0/o9xGN38xFqvXXTUl4ju4sVqT 5MBN1P2SGvjqINaaBr5VD4efSXiMLoIWMTmMxJ9QVy56UEjcelZG+f7YZEhR l9ys3zYTRSV9lDdq48pZfzXJDjvAs8cp+pMwH8d2zZYlv5a3meMLY=; 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: Barry Leiba , oauth WG Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011 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, 04 Jan 2012 23:40:25 -0000 On 01/04/2012 02:14 PM, Torsten Lodderstedt wrote: > Hi Michael, > > Am 04.01.2012 22:06, schrieb Michael Thomas: >> I think the "perhaps unwisely" goes to the heart of my objection. You >> might as well be talking about "perhaps unwisely" driving a car, >> or "perhaps unwisely" eating food: the reality is that people download >> apps by the *billions*. When I was initially blown off, many of the >> participants including document editors implied that only idiots get >> apps for their phones. That is *completely* unhelpful as the reality >> is that OAUTH's use is hugely if not primarily deployed in that sort of >> environment. > > I fully agree with you. That's why the core spec and the threat document both consider native apps. > >> >> This is a threat that cuts to the very heart of what OAUTH is, and purports >> to defend against: keeping user credentials out of the hands of an >> untrusted third party. If there really aren't any good ways to mitigate this >> in an app environment, why is OAUTH being deployed so aggressively there? >> Shouldn't the threat draft say in blinking bold: "DEPLOYING OAUTH >> IN NATIVE APPS CONSIDERED HARMFUL"? > > You lost me. Is the situation getting any worse with OAuth? I don't think so. I think the situation is getting better, probably not as you might expect. My concern is that putting on a veneer of "security" will lull people into thinking "Oh, it's safe to enter my credentials here because this is really twitterbook, not evilapp!". When I had to ask them directly to put their twitterbook credentials into my app, there at least wasn't any confusion that I had access to them. Realistically, what you've done is protected the credentials from the good guys and not changed much for a motivated bad guy. Is that an improvement? I'll buy that it's generally bad practice for good guys with most likely bad security chops to be storing credentials, but I'm guessing that the original OAUTH motivation was more toward thwarting bad guys. > > The key question is: Why do we aim on "keeping user credentials out of the hands of an untrusted third party"? > > 1) To prevent phishing or 2) to prevent leakage of end-user credentials due to inappropriate handling or weak defence on the 3rd party? > > wrt 1) I don't think so. I don't see how an authorization server shall validate the authenticity and trustworthiness of a client-side application. We already state this in section 4.4.1.4. of the threat document. The draft says: o Client applications could be validated prior publication in a application market. I asked -- and didn't get a response -- about how exactly that might be done. I suspect that in practice for the twitterbook universe that there is no way that scales. So the reality here seems to be there isn't an answer for the Internet at large, and the threats document should just say that mitigation MAY be possible in very narrow use cases where code reviews, and other heavy handed analysis can be performed, but for the general case there is no mitigation. As far as 4.4.1.4 goes, I'd say that the counter measures really don't help except maybe for auditing. If that's what they're really about, the draft should make that explicit. Also on the subject of 4.4.1.4, this bullet: o If the authorization server automatically authenticates the end- user, it may nevertheless require some user input in order to prevent screen scraping. Examples are CAPTCHAs or user-specific secret like PIN codes. I'm very skeptical because a native environment is a social engineering nirvana. The CAPTCHA could easily be shown to the user and they'd blissfully solve it just like they do any other one. > > ----------------------- > It is not the task of the authorization server to protect > the end-user's device from malicious software. This is the > responsibility of the platform running on the particular device > probably in cooperation with other components of the respective > ecosystem (e.g. an application management infrastructure). The sole > responsibility of the authorization server is to control access to > the end-user's resources living in resource servers and to prevent > unauthorized access to them. > ----------------------- I assume that it's in the authorization server's _interest_ to not divulge user credentials to potentially evil third parties. If it's not, why would you go to the trouble of implementing OAUTH at all? This is what's so troubling to me. The point is to keep user credentials away from bad guys, but when shown how OAUTH in widely deployed scenarios fails to do that, the response I get from the working group is "Not Our Problem". Well it *is* your problem insofar as you are not advising the twitterbooks to disallow native apps as clients, for example. > > wrt 2) Yes, I think that's the reason. And OAuth is a appropriate protocol to achieve this goal, even for mobile apps. Why? > > A typical mobile application consists of the app itself on the device and a corresponding backend service storing user data and implementing business and integration logic. Let's assume this application features address book import from other service providers. W/o OAuth, the app would gather the end-user's credential for a certain address book service and pass it to its backend service. This service in turn uses this credentials to access the service provider's API. So in such a scenario the following parties get in touch with the user credentials: > - the app > - the app's backend service > - the address book resource server With native mobile apps, the client (= app & app backend) isn't it plenty enough to be seriously scary if they can screen scrape the credentials with impunity? What problem was solved again? > > What threats do you see here? And which is most likely to occur? My favorite is an attack against the log files or the database of the backend service in order to obtain the end-users passwords for the resource server. Why? Because the cost/benefit ratio for an attacker is much better then attacking any app installation on a device and the protective measure on the resource server might be more appropriate then on the client side (backend service). Botnets prove that either is a successful business model. This isn't a zero sum game, after all. > OAuth mitigates this kind of attack by reducing the number of parties handling user credentials to the authorization server and the user agent. So even if the app itself would be the user agent (which is not recommended), Not recommended? It's messed up even thinking of it that way. The app is potentially *evil*. It really doesn't care what the IETF RECOMMENDS. If it's useful for it to be the UA, it's going to do just exactly that. > it would directly interact with the authorization server and the app's backend service would use tokens instead of end-user credentials. The problem here is the capture of end user credentials. I believe that OAUTH defends pretty well in the trusted desktop browser scenario it set out to solve for. I do not believe that it does that in the new reality of native apps, and embedded webviews. | Moreover, the recommended way is to let the app delegate the flow to a trusted system | component on the user's device, such as the system browser or an account manager. In that | case, the 3rd party is not getting in touch with the user credentials at all. Again, the Bad Guys are specifically and completely uninterested in being good and sending it to a trusted component. They will disregard this RECOMMEND faster than you can type it. > > I think the key question is whether anyone expects OAuth to solve the phishing problem. I don't think this is its main purpose, but it could facilitate to overcome the habit to enter user credentials everywhere. And this in turn may contribute to the fight against phishing. There's much more to this than just phishing. Mike From wmills@yahoo-inc.com Wed Jan 4 15:43:06 2012 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 6BDC311E8089 for ; Wed, 4 Jan 2012 15:43:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.018 X-Spam-Level: X-Spam-Status: No, score=-17.018 tagged_above=-999 required=5 tests=[AWL=0.580, 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 tfv5bMJs01i1 for ; Wed, 4 Jan 2012 15:43:05 -0800 (PST) Received: from nm3.bullet.mail.bf1.yahoo.com (nm3.bullet.mail.bf1.yahoo.com [98.139.212.162]) by ietfa.amsl.com (Postfix) with SMTP id 4E25111E80C1 for ; Wed, 4 Jan 2012 15:43:05 -0800 (PST) Received: from [98.139.215.140] by nm3.bullet.mail.bf1.yahoo.com with NNFMP; 04 Jan 2012 23:42:57 -0000 Received: from [98.139.212.247] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 04 Jan 2012 23:42:57 -0000 Received: from [127.0.0.1] by omp1056.mail.bf1.yahoo.com with NNFMP; 04 Jan 2012 23:42:57 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 314030.22965.bm@omp1056.mail.bf1.yahoo.com Received: (qmail 44293 invoked by uid 60001); 4 Jan 2012 23:42:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1325720576; bh=EFUQBEN8uPHI0auUojmNg1Mn/JvoSR6gvXjHHsRw16k=; 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=Ls3dIwQO1sDCqFdOGtTXL4UDCAOUPNBinIg3TVEM1TJFUMoDrxrIeNOmOVbd9aJRL6qszV0+G3gNGZ34CqtvQsNmsufYlvOop7hykBBox4AmdeIoDOoeW982BAa6bxRMewB3Og9FTMZAQpviomg4OIcLVro7EjfRIz+46uKuAkY= 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=U1C9k9Y6RTKIA1GDNZMYlD5qr8OAMBt+yH8tfXPuJS+T7ZbR5LNvhTyoREi8QfXzxNO6MI3BId7aiqWNcqhSou46HSMhAOZD/rZQxtmu+6D1U37Dbyl9tSGVik73jAYpenGVlldgy1/QjfzZpdxAKmLVaIAjyAsgZQAzPtDXBfk=; X-YMail-OSG: wPf4towVM1kzKMkfG6Gm_gW87dMkgYcR.CvgTvs.IEEAFTl 6j39pZ07fObz8keH5RWZNi_uK6b.jrOqDB7Sv0DPEu3Dku8bLleizgZCbVhu fVKYpfJxMMv2WFeAn3SUVC0VaFlYFbE5NL0LNIQp.HAKoptJMVSqKYz4.0fB C.NhwGwM4gcv8Wbo5MbU9OG8VFofUgRs6o5qxf.s1aLg_CRr50zQhxJXtlf7 J5i1zwHxWmJ0JZNTiyQZD10CUfS.t1VcsFN5TODGe6lqhygjdV4j6gAG1Y6s N3DQEsnmNGnEQKy0rpUx4.GEeWUlojmsV3VowqLaHmKNUfLW43n0s1hjclq2 hNcJwh9eCrf6Y14JRkQcQJUbEmTP71o7XuMi54htZCGatP3E7ML4Kq0qCkhr iXHBMHJ3VhJojheNz5sMZ.KW.cfHxcglIje94UjZU Received: from [209.131.62.113] by web31816.mail.mud.yahoo.com via HTTP; Wed, 04 Jan 2012 15:42:56 PST X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.116.331537 References: <8AB6F5CC-E9A2-4A07-9AA0-83FB7C67A221@oracle.com> <4EEA3951.5010904@mtcc.com> <4EEB5BDD.7080401@mtcc.com> <4F038CB9.1040403@mtcc.com> <4F0394D6.1090006@mtcc.com> <4F04AAAE.6080702@mtcc.com> <4F04ACE4.1070006@stpeter.im> <4F04B101.3070708@mtcc.com> <4F04BF70.3010501@mtcc.com> Message-ID: <1325720576.43079.YahooMailNeo@web31816.mail.mud.yahoo.com> Date: Wed, 4 Jan 2012 15:42:56 -0800 (PST) From: William Mills To: Michael Thomas , Barry Leiba In-Reply-To: <4F04BF70.3010501@mtcc.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1238014912-1525551451-1325720576=:43079" Cc: oauth WG Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011 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, 04 Jan 2012 23:43:06 -0000 ---1238014912-1525551451-1325720576=:43079 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I think the threat draft should simply say, "OAuth does not and can not pro= tect the user against credential compromise as a result of phishing, malwar= e, social engineering, or machine compromise."=0A=0AGet rid of the fancy rh= etoric, we don't need to explain a lot more than this.=A0 =0A=0A=0AI don't = agree that OAuth purports to solve these problems. What it solves is limiti= ng the credentials granted to allow the user more control and limited damag= e in the event of credential misuse.=0A=0A=0A-bill=0A=0A=0A=0A_____________= ___________________=0A From: Michael Thomas =0ATo: Barry Lei= ba =0ACc: oauth WG =0ASent: Wedn= esday, January 4, 2012 1:06 PM=0ASubject: Re: [OAUTH-WG] WGLC on draft-ietf= -oauth-v2-threatmodel-01, ends 9 Dec 2011=0A =0AOn 01/04/2012 12:41 PM, Bar= ry Leiba wrote:=0A> up being a compromised browser or a native application = that the user=0A> perhaps unwisely installed, all the security in the frame= work goes out=0A=A0 =A0 ^^^^^^^^^=0A> the window, because an untrustworthy = UA can fiddle with pretty much=0A> everything.=0A>=0A=0AI think the "perhap= s unwisely" goes to the heart of my objection. You=0Amight as well be talki= ng about "perhaps unwisely" driving a car,=0Aor "perhaps unwisely" eating f= ood: the reality is that people download=0Aapps by the *billions*.=A0 When = I was initially blown off, many of the=0Aparticipants including document ed= itors implied that only idiots get=0Aapps for their phones. That is *comple= tely* unhelpful as the reality=0Ais that OAUTH's use is hugely if not prima= rily deployed in that sort of=0Aenvironment.=0A=0AThis is a threat that cut= s to the very heart of what OAUTH is, and purports=0Ato defend against: kee= ping user credentials out of the hands of an=0Auntrusted third party. If th= ere really aren't any good ways to mitigate this=0Ain an app environment, w= hy is OAUTH being deployed so aggressively there?=0AShouldn't the threat dr= aft say in blinking bold: "DEPLOYING OAUTH=0AIN NATIVE APPS CONSIDERED HARM= FUL"?=0A=0AMike=0A_______________________________________________=0AOAuth m= ailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/oauth ---1238014912-1525551451-1325720576=:43079 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I think the threat draft should simply say, "OAuth does not and can not p= rotect the user against credential compromise as a result of phishing, malw= are, social engineering, or machine compromise."

Get rid of the fancy rhetoric, we don't need to ex= plain a lot more than this. 

I don't agree that OAuth purports to solve these problems. W= hat it solves is limiting the credentials granted to allow the user more co= ntrol and limited damage in the event of credential misuse.

-bill

From: Mi= chael Thomas <mike@mtcc.com>
Cc: oauth WG <oauth@ietf.org> =
Sent: Wednesday, Janu= ary 4, 2012 1:06 PM
Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 De= c 2011
=0AOn 01/04/2012 12:41 PM, Barry Leiba wrote:
>= ; up being a compromised browser or a native application that the user
&= gt; perhaps unwisely installed, all the security in the framework goes out<= br>    ^^^^^^^^^
> the window, because an untrustworthy UA = can fiddle with pretty much
> everything.
>

I think the = "perhaps unwisely" goes to the heart of my objection. You
might as well = be talking about "perhaps unwisely" driving a car,
or "perhaps unwisely"= eating food: the reality is that people download
apps by the *billions*= .  When I was initially blown off, many of the
participants includi= ng document editors implied that only idiots get
apps for their phones. = That is *completely* unhelpful as the reality
is that OAUTH's use is hug= ely if not primarily deployed in that sort of
environment.

This i= s a threat that cuts to the very heart of what OAUTH is, and purports
to= defend against: keeping user credentials out of the hands of an
untrusted third party. = If there really aren't any good ways to mitigate this
in an app environm= ent, why is OAUTH being deployed so aggressively there?
Shouldn't the th= reat draft say in blinking bold: "DEPLOYING OAUTH
IN NATIVE APPS CONSIDE= RED HARMFUL"?

Mike
______________________________________________= _
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listi= nfo/oauth


---1238014912-1525551451-1325720576=:43079-- From wmills@yahoo-inc.com Wed Jan 4 15:43:41 2012 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 A962211E8089 for ; Wed, 4 Jan 2012 15:43:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.082 X-Spam-Level: X-Spam-Status: No, score=-17.082 tagged_above=-999 required=5 tests=[AWL=0.516, 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 1Gb7wAHFScZS for ; Wed, 4 Jan 2012 15:43:40 -0800 (PST) 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 A599C11E809C for ; Wed, 4 Jan 2012 15:43:39 -0800 (PST) Received: from [98.139.212.146] by nm37.bullet.mail.bf1.yahoo.com with NNFMP; 04 Jan 2012 23:43:36 -0000 Received: from [98.139.212.245] by tm3.bullet.mail.bf1.yahoo.com with NNFMP; 04 Jan 2012 23:43:36 -0000 Received: from [127.0.0.1] by omp1054.mail.bf1.yahoo.com with NNFMP; 04 Jan 2012 23:43:36 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 547157.3379.bm@omp1054.mail.bf1.yahoo.com Received: (qmail 91244 invoked by uid 60001); 4 Jan 2012 23:43:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1325720615; bh=qA2TUBm+j7qQoRByHlhuDNJScqh9AAzjt9HglNqWtAw=; 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=LDRzDogU00CsqUqxy+f559kIomrffodka6887+ei+IhcFgEzoqEcBNlUl9nZoH/RjQ10NIPXxDgm+82k6P6PMJw8DGMZH5GqTPQjtGzt8cfHWMbdxwaJA+z6Y7YoevT9OvU67ROD9vHq1YdKuKRneovhBlskv0ELo8kzZmTU6aY= 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=dkPZymUNQvJX2kn4a/E3oXNnztA87mW4uK9NGYXWisvgK3zrplawNGyPvUYqMQJmGFj0PbmHjOlAdGSTUbeILylCbTkmIZAoK9gSrLGU5l+NbGCKDcPG6J9tcjgjzJ3SgptXixJe6vlo30LSlc9jORbhE5//NwydGHbRmNN+mxA=; X-YMail-OSG: m.LMdbQVM1lF7fV4FNv9NWmlnIOKkufyT7.gPzdawr_S.wq YTrAkkR5xIytfxbRW9_BrSXOJ1srfA6g3c7oI6lkV0x9knjmV6bddjWBfqSx 4j3VCA5C2ttHtaEAw7d0yV3KBasT3d4dHlZO5_kT4dfM67Mao41Oly3DQCuo dMTK_eM_68jOWfp5ygJ4TC2u6LsWYQCP8ZzebvXQrkzjn6E3F5tnZbVnEWf_ rTZBwl9gngJOtCVAeJeLQgJfB2nYQxtVa2OqLLHaA3F3BuOq1YxBYGp5H2FH KH_aOW8JYIzbrMrhM0SshyE_OulrR82gSLbXVT5k3.6j9MrScs2XGQNC7jkr 1ryl_CEsQkOF3BQmNF02wbBWXS8irDAUeJevOyuvXQxbTMSWGCKBh5rjt7Ib .ExJeFz2Z8HJcfnKNLyJH0m.00fbS_6.sZQ-- Received: from [209.131.62.113] by web31806.mail.mud.yahoo.com via HTTP; Wed, 04 Jan 2012 15:43:35 PST X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.116.331537 References: <4E1F6AAD24975D4BA5B16804296739435F763122@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739435F772D1D@TK5EX14MBXC283.redmond.corp.microsoft.com> <4EEF13F1.7030409@gmx.de> <4E1F6AAD24975D4BA5B16804296739435F78F5BB@TK5EX14MBXC283.redmond.corp.microsoft.com> <4EFD91B4.5050904@gmx.de> <4E1F6AAD24975D4BA5B16804296739435F790386@TK5EX14MBXC283.redmond.corp.microsoft.com> <1325619340.463.YahooMailNeo@web31808.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B16804296739435F7936E7@TK5EX14MBXC283.redmond.corp.microsoft.com> <1325620772.48511.YahooMailNeo@web31802.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B16804296739435F79376F@TK5EX14MBXC283.redmond.corp.microsoft.com> <1325621624.9908.YahooMailNeo@web31808.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B16804296739435F793829@TK5EX14MBXC283.redmond.corp.microsoft.com> <1325623068.88228.YahooMailNeo@web31816.mail.mud.yahoo.com> <5E5EA7F9-B4A0-4DCB-801C-3C0F4EC36A1E@ve7jtb.c om> Message-ID: <1325720615.35382.YahooMailNeo@web31806.mail.mud.yahoo.com> Date: Wed, 4 Jan 2012 15:43:35 -0800 (PST) From: William Mills To: John Bradley In-Reply-To: <5E5EA7F9-B4A0-4DCB-801C-3C0F4EC36A1E@ve7jtb.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1055047407-2147252340-1325720615=:35382" Cc: Julian Reschke , Barry Leiba , Mark Nottingham , OAuth WG Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft 15? 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, 04 Jan 2012 23:43:41 -0000 ---1055047407-2147252340-1325720615=:35382 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Then we need to make this a last call issue.=0A=0A=0A=0A___________________= _____________=0A From: John Bradley =0ATo: William Mills= =0ACc: Mike Jones ; Ju= lian Reschke ; Mark Nottingham ; Barr= y Leiba ; OAuth WG =0ASent: Wedne= sday, January 4, 2012 1:40 PM=0ASubject: Re: [OAUTH-WG] auth-param syntax, = was: OK to post OAuth Bearer draft 15?=0A =0A=0AYou are correct. =C2=A0the= Core spec should include this. =C2=A0However for one reason or another it = is not in the core spec and probably will not be, given that it is in last = call.=0A=0AOne way or other we need to identify the correct answer.=0A=0AJo= hn B.=0A=0A=0AOn 2012-01-03, at 5:37 PM, William Mills wrote:=0A=0AOK, then= the core spec should.=0A>=0A>=0A>=0A>________________________________=0A> = From: Mike Jones =0A>To: William Mills ; Julian Reschke =0A>Cc: Mark Nottin= gham ; Barry Leiba ; OAuth WG =0A>Sent: Tuesday, January 3, 2012 12:20 PM=0A>Subject: RE: [OA= UTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft 15?=0A> =0A>= =0A> =0A>Sorry, I should have been more precise.=C2=A0 The Core spec doesn= =E2=80=99t define how to transmit these fields in the WWW-Authenticate resp= onse header field.=C2=A0 The Bearer spec does.=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=0A>From:William Mills [mailto:wmills@yahoo-inc.com] =0A>Sent: Tuesda= y, January 03, 2012 12:14 PM=0A>To: Mike Jones; Julian Reschke=0A>Cc: Mark = Nottingham; Barry Leiba; OAuth WG=0A>Subject: Re: [OAUTH-WG] auth-param syn= tax, was: OK to post OAuth Bearer draft 15?=0A>=C2=A0=0A>http://tools.ietf.= org/html/draft-ietf-oauth-v2-22#section-11.2.2 certainly has these as prede= fined registered parameters.=C2=A0 If the definition there isn't strong eno= ugh, or in that spec, we should fix that.=C2=A0 That is where these should = be defined.=0A>=C2=A0=0A>=0A>________________________________=0A> =0A>From:= Mike Jones =0A>To: William Mills ; Julian Reschke =0A>Cc: Mark Nottingham <= mnot@mnot.net>; Barry Leiba ; OAuth WG =0A>Sent: Tuesday, January 3, 2012 12:00 PM=0A>Subject: RE: [OAUTH-WG= ] auth-param syntax, was: OK to post OAuth Bearer draft 15?=0A>The core spe= c doesn=E2=80=99t include these parameters.=0A>=C2=A0=0A>From:William Mills= [mailto:wmills@yahoo-inc.com] =0A>Sent: Tuesday, January 03, 2012 12:00 PM= =0A>To: Mike Jones; Julian Reschke=0A>Cc: Mark Nottingham; Barry Leiba; OAu= th WG=0A>Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth B= earer draft 15?=0A>=C2=A0=0A>Why is Bearer dealing with this at all?=C2=A0 = the BNF for that stuff should be part of the core spec, and additional valu= es perhaps defined in Bearer.=0A>=C2=A0=0A>=0A>____________________________= ____=0A> =0A>From:Mike Jones =0A>To: William M= ills ; Julian Reschke =0A>Cc:= Mark Nottingham ; Barry Leiba ; OA= uth WG =0A>Sent: Tuesday, January 3, 2012 11:46 AM=0A>Subj= ect: RE: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft 1= 5?=0A>This is about the syntax for the scope, error, and error_description = parameters.=C2=A0 The pertinent text from Section 3 is:=0A>=C2=A0=0A>=C2=A0= =C2=A0 Producers of "scope" strings MUST NOT use characters outside the set= =0A>=C2=A0=C2=A0 %x21 / %x23-5B / %x5D-7E for representing the scope values= and %x20=0A>=C2=A0=C2=A0 for the delimiter.=C2=A0 Producers of "error" and= "error_description"=0A>=C2=A0=C2=A0 strings MUST NOT use characters outsid= e the set %x20-21 / %x23-5B /=0A>=C2=A0=C2=A0 %x5D-7E for representing thes= e values.=C2=A0 Producers of "error-uri"=0A>=C2=A0=C2=A0 strings MUST NOT u= se characters outside the set %x21 / %x23-5B /=0A>=C2=A0=C2=A0 %x5D-7E for = representing these values.=C2=A0 Furthermore, "error-uri"=0A>=C2=A0=C2=A0 s= trings MUST conform to the URI-Reference syntax.=C2=A0 In all these=0A>=C2= =A0=C2=A0 cases, no character quoting will occur, as senders are prohibited= =0A>=C2=A0=C2=A0 from using the %5C ('\') character.=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 Cheers,=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>From:William Mill= s [mailto:wmills@yahoo-inc.com] =0A>Sent: Tuesday, January 03, 2012 11:36 A= M=0A>To: Mike Jones; Julian Reschke=0A>Cc: Mark Nottingham; Barry Leiba; OA= uth WG=0A>Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth = Bearer draft 15?=0A>=C2=A0=0A>Is all this only around the scope parameter?= =C2=A0 My mail cited below is with regards to the character set for a valid= scope parameter, which we should be able to define and then lean on the HT= TPbis spec for the actual parameter syntax.=0A>=C2=A0=0A>=0A>______________= __________________=0A> =0A>From:Mike Jones =0A= >To: Julian Reschke =0A>Cc: Mark Nottingham ; Barry Leiba ; OAuth WG = =0A>Sent: Friday, December 30, 2011 3:19 PM=0A>Subject: Re: [OAUTH-WG] auth= -param syntax, was: OK to post OAuth Bearer draft 15?=0A>=0A>I did already = back the statement that this is the working group consensus with the e-mail= s attached in this note sent to you on December 12, 2011:=0A>=C2=A0 - http:= //www.ietf.org/mail-archive/web/oauth/current/msg08042.html=0A>=0A>But sinc= e that apparently wasn't convincing to you that this working group decision= represents more than "just me disagreeing with you", here are references t= o individual messages referenced in the above e-mail:=0A>=C2=A0 - Eran Hamm= er-Lahav: http://www.ietf.org/mail-archive/web/oauth/current/msg07698.html= =0A>=C2=A0 - John Bradley:=C2=A0 http://www.ietf.org/mail-archive/web/oauth= /current/msg07699.html=0A>=C2=A0 - William Mills:=C2=A0 http://www.ietf.org= /mail-archive/web/oauth/current/msg07700.html=0A>=C2=A0 - Mike Jones:=C2=A0= http://www.ietf.org/mail-archive/web/oauth/current/msg07701.html=0A>=C2=A0= - Phil Hunt:=C2=A0 http://www.ietf.org/mail-archive/web/oauth/current/msg0= 7702.html=0A>=C2=A0 - Justin Richer:=C2=A0 http://www.ietf.org/mail-archive= /web/oauth/current/msg07692.html=0A>=0A>As for your assertion that the spec= s are in conflict, yes, the Bearer spec includes a different decision than = a RECOMMENDED clause in the HTTPbis spec (which was added after the Bearer = text was already in place).=C2=A0 However, it is not violating any MUST cla= uses=0A in the HTTPbis spec.=C2=A0 Given that no MUSTS are violated, I don'= t see it mandatory for this tension to be resolved in favor of one spec or = the other in order for both to be approved as RFCs.=C2=A0 I look forward to= seeing that happen soon in both cases (and for the=0A OAuth core spec as w= ell).=0A>=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 Best wishes,=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 -- Mike=0A>=0A>-----Original Message----= -=0A>From: Julian Reschke [mailto:julian.reschke@gmx.de] =0A>Sent: Friday, = December 30, 2011 2:26 AM=0A>To: Mike Jones=0A>Cc: Barry Leiba; Mark Nottin= gham; OAuth WG=0A>Subject: Re: auth-param syntax, was: [OAUTH-WG] OK to pos= t OAuth Bearer draft 15?=0A>=0A>On 2011-12-29 22:18, Mike Jones wrote:=0A>>= You proposed, Julian "3. Do not specify the ABNF. The ABNF of the WWW-Auth= enticate is defined in HTTPbis. Just state the names of the parameters, the= ir syntax *after* parsing and their semantics."=0A>>=0A>> About some of Mar= k Nottingham's comments, Barry wrote "Let me point out that "this represent= s working-group consensus" is not always a valid response.=C2=A0 If the wor= king group has actually considered the *issue*, that might be OK.=C2=A0 But= if there's consensus for=0A the chosen solution and someone brings up a *n= ew* issue with it, that issue needs to be addressed anew."=0A>>=0A>> Relati= ve to these two statements, I believe that I should remark at this point th= at your proposed semantics of only considering the syntax after potential q= uoting was explicitly considered earlier by the working group and rejected.= =C2=A0 The consensus, instead,=0A was for the present "no quoting will occu= r for legal inputs" semantics.=0A>=0A>It would be helpful if you could back= this statement with pointers to mails. As far as I can tell it's just you = disagreeing with me.=0A>=0A>Back to the facts:=0A>=0A>a) the bearer spec de= fines an HTTP authentication scheme, and normatively refers to HTTPbis Part= 7 for that=0A>=0A>b) HTTPbis recommends new scheme definitions not to have = their own ABNF, as the header field syntax is defined by HTTPbis, not the i= ndividual scheme=0A>=0A>c) the bearer spec defines it's own ABNF neverthele= ss=0A>=0A>So the two specs are in conflict, and we should resolve the confl= ict one way or the other.=0A>=0A>If you disagree with the recommendation in= HTTPbis, then you really really should come over to HTTPbis WG and argue y= our point of view.=0A>=0A>If you agree with it, but think that the bearer s= pec can't follow the recommendation, then it would be good to explain the r= easoning (optimally in the spec).=0A>=0A>If you agree with it, and think th= e bearer spec *could* follow it, then... change it, by all means.=0A>=0A>An= yway, if this issue isn't resolved before IETF LC then it will be raised ag= ain at that time.=0A>=0A>=0A>> I believe that in the New Year the chairs an= d area directors will need to decide how to proceed on this issue.=C2=A0 (T= he working group consensus, as I see it, is already both well-informed and = clear on this point, but I understand that that's not the only consideratio= n.)=C2=A0=0A It would be good to see the spec finished shortly.=0A>> ...=0A= >=0A>Best regards, Julian=0A>=0A>=0A>=0A>__________________________________= _____________=0A>OAuth mailing list=0A>OAuth@ietf.org=0A>https://www.ietf.o= rg/mailman/listinfo/oauth=0A>=C2=A0=0A>=C2=A0=0A>=0A>______________________= _________________________=0A>OAuth mailing list=0A>OAuth@ietf.org=0A>https:= //www.ietf.org/mailman/listinfo/oauth=0A> ---1055047407-2147252340-1325720615=:35382 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Then we need to make this a last call issue.

<= hr size=3D"1"> From: John = Bradley <ve7jtb@ve7jtb.com>
To: William Mills <wmills@yahoo-inc.com>
Cc: Mike Jones <Michael.Jones@micro= soft.com>; Julian Reschke <julian.reschke@gmx.de>; Mark Nottingham= <mnot@mnot.net>; Barry Leiba <barryleiba@computer.org>; OAuth = WG <oauth@ietf.org>
Sent:<= /span> Wednesday, January 4, 2012 1:40 PM
Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post O= Auth Bearer draft 15?
=0A
You= are correct.  the Core spec should include this.  However for on= e reason or another it is not in the core spec and probably will not be, gi= ven that it is in last call.

One way or other we need to= identify the correct answer.

John B.
On 2012-01-03, at 5:37 PM, William Mills wrote:

=
OK, then th= e core spec should.

From: Mike Jones <Michael.Jones@microsoft= .com>
To: Willia= m Mills <wmills@yahoo-inc.com>; Julian Reschke <julian.= reschke@gmx.de>
Cc:<= /b> Mark Nottingham <mnot@mnot.net>; Ba= rry Leiba <barryleiba@comp= uter.org>; OAuth WG <oauth@ietf.org>
Sent: Tuesday, January 3, 2012 12:20 PM Subject: RE: [OAUTH-WG] = auth-param syntax, was: OK to post OAuth Bearer draft 15?
= =0A
=0A=0A =0A =0A=0A=0A
=0A
=0A
Sorry, I should have been more precise.  The Core spec= doesn=E2=80=99t define how to transmit these fields in the WWW-Authenticat= e response header field.  The Bearer=0A spec does.
=0A  
=0A
     &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;        -- Mike
=0A  
=0A
=0A
=0A
From: William Mills [mailto:wmills@yahoo-inc.com]=0A<= br>=0ASent: Tuesday, January 03, 2012 12:14 PM
=0ATo: Mike= Jones; Julian Reschke
=0ACc: Mark Nottingham; Barry Leiba; OAuth= WG
=0ASubject: Re: [OAUTH-WG] auth-param syntax, was: OK to post= OAuth Bearer draft 15?
=0A
=0A
=0A
 
=0A
=0A
=0A
http://tools.ietf.org/html/draft-ietf-oauth-v2-22#section-1= 1.2.2=0A certainly has these as predefined registered parameters.  If = the definition there isn't strong enough, or in that spec, we should fix th= at.  That is where these should be defined.
=0A
=0A<= div>=0A
 
=0A
= =0A
=0A
=0A
=0A=0A
=0A
=0A
F= rom: Mike Jones &l= t;Michael.Jones@micro= soft.com>
=0ATo: William Mills <wmills@yahoo-inc.com>; Julian Reschke <julian.reschke@gmx.de>=0A
=0ACc: Mark Nottingham <mnot@mnot.net>= ;; Barry Leiba <barryleiba= @computer.org>; OAuth WG <oauth@ietf.= org>=0A
=0ASent: Tuesday, January 3, 2012 12:00 PM
=0A<= b>Subject: RE: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bear= er draft 15?
=0A
=0A
=0A
=0A
=0A
The core spec doesn=E2=80=99t include these parameters.
=0A
=0A
=0A
  =0A
=0A
=0A
=0A
=0A
From: Will= iam Mills=0A[mail= to:wmills@yahoo-inc.com]
=0ASent: Tuesday, January 03, 2012 = 12:00 PM
=0ATo: Mike Jones; Julian Reschke
=0ACc: Mark = Nottingham; Barry Leiba; OAuth WG
=0ASubject: Re: [OAUTH-WG] auth= -param syntax, was: OK to post OAuth Bearer draft 15?
=0A
=0A
=0A
=0A
=0A
 
=0A
=0A
=0A
=0A
=0A
Why is Bearer dealing with this at all?  = the BNF for that stuff should be part of the core spec, and additional valu= es perhaps defined in Bearer. =0A
=0A
=0A
=0A
=0A
 
=0A
=0A=0A
=0A
=0A
=0A=0A
=0A<= /span>
=0A
=0A
From: Mike Jones <Michael.Jones@microsoft.com>
=0ATo: William Mills <wmills@yahoo-inc.com>; Julian = Reschke <julian.reschke@gmx.de= >=0A
=0ACc: Mark Nottingham <= mnot@mnot.net>; Barry Leiba <barryleiba@computer.org>; OAuth WG <oauth@ietf.org>=0A
=0ASent: Tuesday, January 3, 2= 012 11:46 AM
=0ASubject: RE: [OAUTH-WG] auth-param syntax, was: O= K to post OAuth Bearer draft 15?=
=0A
=0A
=0A
=0A
=0A
=0A=0A
This is about the syntax for th= e scope, error, and error_description parameters.  The pertinent text = from=0A=0ASection 3 is:
=0A
=0A
=0A
=0A
= =0A
 
=0A
=0A
=0A
=0A
=0A
   Producers of "scope" strings= MUST NOT use characters outside the set
=0A
=0A
=0A
=0A
=0A
   %x21 / %x23-5B / %x5D-7E for represe= nting the scope values and %x20<= /div> =0A
=0A
=0A
=0A
=0A
   for the delimiter.  Producers of "error"= and "error_description"
= =0A
=0A
=0A
=0A
=0A
   strings MUST NOT use characters outside the set %x2= 0-21 / %x23-5B /
=0A
= =0A
=0A
=0A
=0A
   %x5D-7E for representing these values.  Producers of "e= rror-uri"
=0A
=0A=0A
=0A
=0A
 = ;  strings MUST NOT use characters outside the set %x21 / %x23-5B /
=0A
=0A
=0A
= =0A
=0A
   %x= 5D-7E for representing these values.  Furthermore, "error-uri"<= span style=3D"color:black;">
=0A
=0A
=0A
=0A=0A
   strings M= UST conform to the URI-Reference syntax.  In all these
=0A
=0A
=0A
=0A
=0A   cases, no chara= cter quoting will occur, as senders are prohibited
=0A
=0A
=0A
=0A
=0A
   from using the %5C ('\') c= haracter.
=0A
=0A=0A
=0A
=0A
 
=0A
=0A
=0A
=0A
= =0A
     &nb= sp;            =             &nb= sp;            =             &nb= sp;    Cheers, =0A
=0A
=0A
=0A
=0A
           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;          -- Mike<= span style=3D"color:black;">
=0A
=0A
=0A
=0A=0A
 
=0A
=0A
=0A
=0A
=0A
=0A<= div>=0A
From: William Mills=0A[mailto:wmills@yahoo-inc.com]=0A
= =0ASent: Tuesday, January 03, 2012 11:36 AM
=0ATo: Mike Jo= nes; Julian Reschke
=0ACc: Mark Nottingham; Barry Leiba; OAuth WG=
=0ASubject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OA= uth Bearer draft 15?
=0A=0A
=0A
=0A
=0A
=0A
=0A
 = ;
=0A
=0A
=0A
=0A
=0A
=0A
=0A
Is all this only around the scope parameter?&= nbsp; My mail cited below is with regards to the character set for a valid = scope parameter, which we should be able to define and=0A then lean on the = HTTPbis spec for the actual parameter syntax.
=0A
=0A
=0A
=0A
=0A
=0A
=0A<= div class=3D"yiv1439935353MsoNormal" style=3D"background:white;"> 
=0A
=0A
=0A
=0A
=0A
=0A
=0A=0A
=0A
=0A
=0A
=0A
From: Mike Jones <Michael.Jones@microsoft.com>
=0ATo: Julian Res= chke <julian.reschke@gmx.de>=0A
=0ACc: Mark Nottingham <m= not@mnot.net>; Barry Leiba <barryleiba@computer.org>; OAuth WG <oauth@ietf.org>=0A
=0ASent: Friday, December 30, 2= 011 3:19 PM
=0ASubject: Re: [OAUTH-WG] auth-param syntax, was: OK= to post OAuth Bearer draft 15?
=0A<= br>=0AI did already back the statement that this is the working group conse= nsus with the e-mails attached in this note sent to you on December 12, 201= 1:
=0A  - http://www.ietf.org/= mail-archive/web/oauth/current/msg08042.html
=0A
=0ABut since tha= t apparently wasn't convincing to you that this working group decision repr= esents more than "just me disagreeing with you", here are references to ind= ividual messages referenced in the above e-mail:
=0A  - Eran Hammer= -Lahav: =0Ahttp://www.ietf.org/mail-ar= chive/web/oauth/current/msg07698.html
=0A  - John Bradley: = ; =0Ahttp://www.ietf.org/mail-archive/= web/oauth/current/msg07699.html
=0A  - William Mills:  =0Ahttp://www.ietf.org/mail-archive/web/o= auth/current/msg07700.html
=0A  - Mike Jones:  =0Ahttp://www.ietf.org/mail-archive/web/oauth/cur= rent/msg07701.html
=0A  - Phil Hunt:  =0Ahttp://www.ietf.org/mail-archive/web/oauth/current/msg0= 7702.html
=0A  - Justin Richer:  =0Ahttp://www.ietf.org/mail-archive/web/oauth/current/msg07692.= html
=0A
=0AAs for your assertion that the specs are in conflict,= yes, the Bearer spec includes a different decision than a RECOMMENDED clau= se in the HTTPbis spec (which was added after the Bearer text was already i= n place).  However, it is not violating any MUST clauses=0A in the HTT= Pbis spec.  Given that no MUSTS are violated, I don't see it mandatory= for this tension to be resolved in favor of one spec or the other in order= for both to be approved as RFCs.  I look forward to seeing that happe= n soon in both cases (and for the=0A OAuth core spec as well).
=0A
= =0A              &nb= sp; Best wishes,
=0A          &n= bsp;     -- Mike
=0A
=0A-----Original Message-----
= =0AFrom: Julian Reschke [mailto:j= ulian.reschke@gmx.de]=0A
=0ASent: Friday, December 30, 2011 2:26 AM<= br>=0ATo: Mike Jones
=0ACc: Barry Leiba; Mark Nottingham; OAuth WG
= =0ASubject: Re: auth-param syntax, was: [OAUTH-WG] OK to post OAuth Bearer = draft 15?
=0A
=0AOn 2011-12-29 22:18, Mike Jones wrote:
=0A> Yo= u proposed, Julian "3. Do not specify the ABNF. The ABNF of the WWW-Authent= icate is defined in HTTPbis. Just state the names of the parameters, their = syntax *after* parsing and their semantics."
=0A>
=0A> About so= me of Mark Nottingham's comments, Barry wrote "Let me point out that "this = represents working-group consensus" is not always a valid response.  I= f the working group has actually considered the *issue*, that might be OK.&= nbsp; But if there's consensus for=0A the chosen solution and someone bring= s up a *new* issue with it, that issue needs to be addressed anew."
=0A&= gt;
=0A> Relative to these two statements, I believe that I should re= mark at this point that your proposed semantics of only considering the syn= tax after potential quoting was explicitly considered earlier by the workin= g group and rejected.  The consensus, instead,=0A was for the present = "no quoting will occur for legal inputs" semantics.
=0A
=0AIt would b= e helpful if you could back this statement with pointers to mails. As far a= s I can tell it's just you disagreeing with me.
=0A
=0ABack to the fa= cts:
=0A
=0Aa) the bearer spec defines an HTTP authentication scheme,= and normatively refers to HTTPbis Part7 for that
=0A
=0Ab) HTTPbis r= ecommends new scheme definitions not to have their own ABNF, as the header = field syntax is defined by HTTPbis, not the individual scheme
=0A
=0A= c) the bearer spec defines it's own ABNF nevertheless
=0A
=0ASo the t= wo specs are in conflict, and we should resolve the conflict one way or the= other.
=0A
=0AIf you disagree with the recommendation in HTTPbis, th= en you really really should come over to HTTPbis WG and argue your point of= view.
=0A
=0AIf you agree with it, but think that the bearer spec ca= n't follow the recommendation, then it would be good to explain the reasoni= ng (optimally in the spec).
=0A
=0AIf you agree with it, and think th= e bearer spec *could* follow it, then... change it, by all means.
=0A=0AAnyway, if this issue isn't resolved before IETF LC then it will be rai= sed again at that time.
=0A
=0A
=0A> I believe that in the New = Year the chairs and area directors will need to decide how to proceed on th= is issue.  (The working group consensus, as I see it, is already both = well-informed and clear on this point, but I understand that that's not the= only consideration.) =0A It would be good to see the spec finished sh= ortly.
=0A> ...
=0A
=0ABest regards, Julian
=0A
=0A
= =0A
=0A_______________________________________________
=0AOAuth maili= ng list
=0AOAuth@ietf.org
=0Ahttps://www.ietf.org/mailman/listinfo/oauth
=0A<= /div>=0A
=0A
=0A
=0A
=0A
=0A
=0A
=0A=0A
 
= =0A
=0A
=0A
=0A
=0A
=0A
=0A
=0A
 
=0A
=0A
=0A=
=0A
=0A
=0A=0A


___= ____________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/l= istinfo/oauth



<= /div>
---1055047407-2147252340-1325720615=:35382-- From wmills@yahoo-inc.com Wed Jan 4 15:44:43 2012 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 EEE2211E80D8 for ; Wed, 4 Jan 2012 15:44:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.134 X-Spam-Level: X-Spam-Status: No, score=-17.134 tagged_above=-999 required=5 tests=[AWL=0.464, 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 EQzSlzHfbmWo for ; Wed, 4 Jan 2012 15:44:42 -0800 (PST) Received: from nm18-vm1.bullet.mail.ne1.yahoo.com (nm18-vm1.bullet.mail.ne1.yahoo.com [98.138.91.64]) by ietfa.amsl.com (Postfix) with SMTP id 237E711E809C for ; Wed, 4 Jan 2012 15:44:42 -0800 (PST) Received: from [98.138.90.51] by nm18.bullet.mail.ne1.yahoo.com with NNFMP; 04 Jan 2012 23:44:41 -0000 Received: from [98.138.89.197] by tm4.bullet.mail.ne1.yahoo.com with NNFMP; 04 Jan 2012 23:44:41 -0000 Received: from [127.0.0.1] by omp1055.mail.ne1.yahoo.com with NNFMP; 04 Jan 2012 23:44:41 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 601877.50041.bm@omp1055.mail.ne1.yahoo.com Received: (qmail 91527 invoked by uid 60001); 4 Jan 2012 23:44:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1325720681; bh=UImjXNXsMg+65GLFQC9wTB1uOJ7DRbIzm5jtPoazNws=; 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=EROMus+lhRTq9YR7HnrC4JwPMWxUq9LWDatCRrqHa45HbPMd03OFhJfcko2Itsy3Ztcse8Bh+HWKR6IGD2+QrQpHdtwVTXZ+u9nBRH7fvpIvFl20wuxgtXT4MdZhVhZNB6CkLFd8ss9AeOPheE8IlVRTVtBx4rQN8VSPAleXxM4= 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=V7UytCSBG574q6sqPYzbRvAntNZHqe1bculEbg7MQZ0Bs39xJ/8o0ZEd753O/925lHhL3O/BQFAbpwNdC7x+xSrr/cINl4vvrw3D3+S9oOW/6aRp54KcDbV2KDHUFoh4enTuLszUb7YIXPtUnTdI1d3PpXFqbWQw9CX3bo3ZJVs=; X-YMail-OSG: jolLFeUVM1lb7oQmnHDAxZHp_q84dCJ0cK80sXpKv2BNF1Z clHTf8xf.fPGoa.oDaasAmr6AG.EfCrVNWs5V5a0GsZq6kmYZnyBdPknDhda 5f9TM2zE5aSkkAYVTT0eWWdPeITWGCCxdOf17y8G1KDLYgmkPueN.mE6wZiV hkPUta8xIFsGuP1u_BVkueTSLXXOwXNz.je45kKlZMpyI9yw3YVWXbswaRnb WCJ5ozMQrUZIMtXbbauCgEin1fYWbOguYTsX9faQBbUBXjf0SQ5SfIEtmK5l 0iRVbN8eXh62PSQntzX3b7ei_ns3LyPusWGHgOD33RB6wXXdIxYu44CURkYz J6rmOdYzvc3AYYeSLBNSOMJbtUIFR_lFMrHzjDawGYgxHFKIEoRfnBkeB7.x DIEZR1rD75E0zDylFYhJJJs.dMTBMF.zma5Y- Received: from [209.131.62.113] by web31806.mail.mud.yahoo.com via HTTP; Wed, 04 Jan 2012 15:44:41 PST X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.116.331537 References: <4E1F6AAD24975D4BA5B16804296739435F763122@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739435F772D1D@TK5EX14MBXC283.redmond.corp.microsoft.com> <4EEF13F1.7030409@gmx.de> <4E1F6AAD24975D4BA5B16804296739435F78F5BB@TK5EX14MBXC283.redmond.corp.microsoft.com> <4EFD91B4.5050904@gmx.de> <4E1F6AAD24975D4BA5B16804296739435F790386@TK5EX14MBXC283.redmond.corp.microsoft.com> <1325619340.463.YahooMailNeo@web31808.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B16804296739435F7936E7@TK5EX14MBXC283.redmond.corp.microsoft.com> <1325620772.48511.YahooMailNeo@web31802.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B16804296739435F79376F@TK5EX14MBXC283.redmond.corp.microsoft.com> <1325621624.9908.YahooMailNeo@web31808.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B16804296739435F793829@TK5EX14MBXC283.redmond.corp.microsoft.com> <1325623068.88228.YahooMailNeo@web31816.mail.mud.yahoo.com> <5E5EA7F9-B4A0-4DCB-801C-3C0F4EC36A1E@ve7jtb.! com> <4F04CC2D.1080805@gmx.de> <7570AAA5-3C7B-409B-99AE-BC9C91F729FB@ve7jtb.com> Message-ID: <1325720681.35382.YahooMailNeo@web31806.mail.mud.yahoo.com> Date: Wed, 4 Jan 2012 15:44:41 -0800 (PST) From: William Mills To: John Bradley , Julian Reschke In-Reply-To: <7570AAA5-3C7B-409B-99AE-BC9C91F729FB@ve7jtb.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1055047407-1354576934-1325720681=:35382" Cc: Mark Nottingham , Barry Leiba , OAuth WG Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft 15? 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, 04 Jan 2012 23:44:43 -0000 ---1055047407-1354576934-1325720681=:35382 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Does Bearer really have to go there?=A0 Can it simply be pulled form Bearer= ?=0A=0A=0A=0A________________________________=0A From: John Bradley =0ATo: Julian Reschke =0ACc: William Mi= lls ; Barry Leiba ; Mark Not= tingham ; OAuth WG =0ASent: Wednesday, Janu= ary 4, 2012 2:10 PM=0ASubject: Re: [OAUTH-WG] auth-param syntax, was: OK t= o post OAuth Bearer draft 15?=0A =0ADon't get me wrong, I agree that it sho= uld be in core.=0A=0AI just don't want to hold up core for something that o= nly bearer seems to care about.=0A=0AIf there is consensus that it should b= e fixed in core then lets do that rather than leaving it up to bearer,=A0 M= AC and token types not yet imagined to do it independently.=0A=0AJohn B.=0A= On 2012-01-04, at 7:01 PM, Julian Reschke wrote:=0A=0A> On 2012-01-04 22:40= , John Bradley wrote:=0A>> You are correct. the Core spec should include th= is. However for one=0A>> reason or another it is not in the core spec and p= robably will not be,=0A>> given that it is in last call.=0A>> ...=0A> =0A> = The datatracker says:=0A> =0A> "AD Evaluation::Revised ID Needed" ()=0A> =0A> As far as I recal= l, this includes other changes needed by the bearer spec.=0A> =0A> Best reg= ards, Julian ---1055047407-1354576934-1325720681=:35382 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Does Bearer really have to go there?  Can it simply be pulled form B= earer?

From: John Bradley <ve7jtb@ve7jtb.com>
<= b>To: Julian Reschke <juli= an.reschke@gmx.de>
Cc:<= /b> William Mills <wmills@yahoo-inc.com>; Barry Leiba <barryleiba@= computer.org>; Mark Nottingham <mnot@mnot.net>; OAuth WG <oauth= @ietf.org>
Sent: W= ednesday, January 4, 2012 2:10 PM
Subject:= Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer= draft 15?
=0ADon't get me wrong, I agree that it should be= in core.

I just don't want to hold up core for something that only = bearer seems to care about.

If there is consensus that it should be = fixed in core then lets do that rather than leaving it up to bearer,  = MAC and token types not yet imagined to do it independently.

John B.=
On 2012-01-04, at 7:01 PM, Julian Reschke wrote:

> On 2012-01= -04 22:40, John Bradley wrote:
>> You are correct. the Core spec s= hould include this. However for one
>> reason or another it is not= in the core spec and probably will not be,
>> given that it is in= last call.
>> ...
>
> The datatracker says:
> =
> "AD Evaluation::Revised ID Needed" (<https://datatrack= er.ietf.org/doc/draft-ietf-oauth-v2/>)
>
> As far as I = recall, this includes other changes needed by the bearer spec.
>
> Best regards, Julian


---1055047407-1354576934-1325720681=:35382-- From wmills@yahoo-inc.com Wed Jan 4 15:50:30 2012 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 7DC8021F8551 for ; Wed, 4 Jan 2012 15:50:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.176 X-Spam-Level: X-Spam-Status: No, score=-17.176 tagged_above=-999 required=5 tests=[AWL=0.422, 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 7NkyRRvPIiFE for ; Wed, 4 Jan 2012 15:50:28 -0800 (PST) Received: from nm36-vm1.bullet.mail.ne1.yahoo.com (nm36-vm1.bullet.mail.ne1.yahoo.com [98.138.229.113]) by ietfa.amsl.com (Postfix) with SMTP id 8F62721F8550 for ; Wed, 4 Jan 2012 15:50:28 -0800 (PST) Received: from [98.138.90.52] by nm36.bullet.mail.ne1.yahoo.com with NNFMP; 04 Jan 2012 23:50:21 -0000 Received: from [98.138.226.162] by tm5.bullet.mail.ne1.yahoo.com with NNFMP; 04 Jan 2012 23:50:21 -0000 Received: from [127.0.0.1] by omp1063.mail.ne1.yahoo.com with NNFMP; 04 Jan 2012 23:50:21 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 250123.43633.bm@omp1063.mail.ne1.yahoo.com Received: (qmail 93316 invoked by uid 60001); 4 Jan 2012 23:50:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1325721020; bh=19gLpPI74emlsidf6n1YhVfbb5TlRJIerQ1u26eFRjk=; 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=qImZbDX0YKfcTgAJhiLDfSdP9j6vgkjC9oDb2Re3Azsa5TQn+F9PVyIKkNRu7EQDvSxQ7d38hjC9KhM6s6Jo65XGx+TUwAxzZHmohhkovCXUi/QSL8MRt1zMyqyMInISXZKe6VMij6fZtpTxM1QNyBukjwVPw3qCvFQFYzPoYPI= 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=XnfCeKUjG+jBwsCLiI2F69F7tGyeD9FThd+peiq1kWyrh6JcM0jlKC83TJ4/38ywoXdIQpoDRssFl9KPIGfrPn1kTutGiPDowZovh/pqewv5zpBcCPvBEMmcLBNBMv8ji3Nu2fsbjOxLXD0xvmUQM/Zj8wRHG5jB9moJL4S9C+E=; X-YMail-OSG: 8uWKDRMVM1lp7r9q9TzVLZ8iWtjcfF8OyZ3qfV4M6Gk4pfo PEBSKrj.39FsMsdMLmeZfopLdwWRiSMR2iHFH1uk.IpHYkkhUIy.vR3GFbkh LuozEBw4uQmje96EkmjBoG0Ufvw7EKe__oXGUoBcyCayOm5tB7ysWriWQhyX FtcECLrvEGXJ74bYKbTTy.OiOSnnMPzpRD6tskooeNtd1t8CDMnRqHGhf.VL Folaq5bRi2j3UevP7Qwx5Hq9GqxlDru2Ikptt0wpai2ufM_b66AnNkTsHqaz JcP52VNNQBYxPyIY_axkbamMmTpg5S2SqlMBaVx_Q_FN9cMHrLnqLI824yBI Nccm8Os48WouOOQj4ushnZ6FyWyZeAilU.bvRFfZ7hOcQnMAEBKFZWdwJkeG QmV05Wbu0HnT2eYqFqJhHfyU7LSObv19FUInytyIaCTI- Received: from [209.131.62.113] by web31812.mail.mud.yahoo.com via HTTP; Wed, 04 Jan 2012 15:50:20 PST X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.116.331537 References: <8AB6F5CC-E9A2-4A07-9AA0-83FB7C67A221@oracle.com> <4EEA3951.5010904@mtcc.com> <4EEB5BDD.7080401@mtcc.com> <4F038CB9.1040403@mtcc.com> <4F0394D6.1090006@mtcc.com> <4F04AAAE.6080702@mtcc.com> <4F04ACE4.1070006@stpeter.im> <4F04B101.3070708@mtcc.com> <4F04BF70.3010501@mtcc.com> <4F04CF60.1050000@lodderstedt.net> <4F04E362.5070406@mtcc.com> Message-ID: <1325721020.62165.YahooMailNeo@web31812.mail.mud.yahoo.com> Date: Wed, 4 Jan 2012 15:50:20 -0800 (PST) From: William Mills To: Michael Thomas , Torsten Lodderstedt In-Reply-To: <4F04E362.5070406@mtcc.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1458549034-739163065-1325721020=:62165" Cc: Barry Leiba , oauth WG Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011 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, 04 Jan 2012 23:50:30 -0000 --1458549034-739163065-1325721020=:62165 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =A0 "=A0 o=A0 Client applications could be validated prior publication in a= =0A=A0 =A0 =A0 application market."=0A=0AShould just be struck.=A0 Michael= is correct that it's fluff, and unenforceable.=A0 There are too many app m= arketplaces, opensource projects, etc. to make this a useful suggestion.=0A= =0A=0A=0A________________________________=0A From: Michael Thomas =0ATo: Torsten Lodderstedt =0ACc: Barry Lei= ba ; oauth WG =0ASent: Wednesday,= January 4, 2012 3:40 PM=0ASubject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth= -v2-threatmodel-01, ends 9 Dec 2011=0A =0AOn 01/04/2012 02:14 PM, Torsten L= odderstedt wrote:=0A> Hi Michael,=0A>=0A> Am 04.01.2012 22:06, schrieb Mich= ael Thomas:=0A>> I think the "perhaps unwisely" goes to the heart of my obj= ection. You=0A>> might as well be talking about "perhaps unwisely" driving = a car,=0A>> or "perhaps unwisely" eating food: the reality is that people d= ownload=0A>> apps by the *billions*.=A0 When I was initially blown off, man= y of the=0A>> participants including document editors implied that only idi= ots get=0A>> apps for their phones. That is *completely* unhelpful as the r= eality=0A>> is that OAUTH's use is hugely if not primarily deployed in that= sort of=0A>> environment.=0A>=0A> I fully agree with you. That's why the c= ore spec and the threat document both consider native apps.=0A>=0A>>=0A>> T= his is a threat that cuts to the very heart of what OAUTH is, and purports= =0A>> to defend against: keeping user credentials out of the hands of an=0A= >> untrusted third party. If there really aren't any good ways to mitigate = this=0A>> in an app environment, why is OAUTH being deployed so aggressivel= y there?=0A>> Shouldn't the threat draft say in blinking bold: "DEPLOYING O= AUTH=0A>> IN NATIVE APPS CONSIDERED HARMFUL"?=0A>=0A> You lost me. Is the s= ituation getting any worse with OAuth? I don't think so. I think the situat= ion is getting better, probably not as you might expect.=0A=0AMy concern is= that putting on a veneer of "security" will lull people into=0Athinking "O= h, it's safe to enter my credentials here because this is really=0Atwitterb= ook, not evilapp!". When I had to ask them directly to put their=0Atwitterb= ook credentials into my app, there at least wasn't any confusion=0Athat I h= ad access to them.=0A=0ARealistically, what you've done is protected the cr= edentials from the good=0Aguys and not changed much for a motivated bad guy= . Is that an improvement?=0AI'll buy that it's generally bad practice for g= ood guys with most likely bad=0Asecurity chops to=A0 be storing credentials= , but I'm guessing that the original=0AOAUTH motivation was more toward thw= arting bad guys.=0A=0A>=0A> The key question is: Why do we aim on "keeping = user credentials out of the hands of an untrusted third party"?=0A>=0A> 1) = To prevent phishing or 2) to prevent leakage of end-user credentials due to= inappropriate handling or weak defence on the 3rd party?=0A>=0A> wrt 1) I = don't think so. I don't see how an authorization server shall validate the = authenticity and trustworthiness of a client-side application. We already s= tate this in section 4.4.1.4. of the threat document.=0A=0AThe draft says:= =0A=0A=A0 o=A0 Client applications could be validated prior publication in = a=0A=A0 =A0 =A0 application market.=0A=0AI asked -- and didn't get a respo= nse -- about how exactly that might be done. I suspect=0Athat in practice f= or the twitterbook universe that there is no way that scales. So the=0Areal= ity here seems to be there isn't an answer for the Internet at large, and t= he threats=0Adocument should just say that mitigation MAY be possible in ve= ry narrow use cases where=0Acode reviews, and other heavy handed analysis c= an be performed, but for the general case=0Athere is no mitigation.=0A=0AAs= far as 4.4.1.4 goes, I'd say that the counter measures really don't help e= xcept=0Amaybe for auditing. If that's what they're really about, the draft = should make that=0Aexplicit.=0A=0AAlso on the subject of 4.4.1.4, this bull= et:=0A=0A=0Ao=A0 If the authorization server automatically authenticates th= e end-=0A=A0 =A0 =A0 user, it may nevertheless require some user input in = order to=0A=A0 =A0 =A0 prevent screen scraping.=A0 Examples are CAPTCHAs o= r user-specific=0A=A0 =A0 =A0 secret like PIN codes.=0A=0A=0AI'm very skep= tical because a native environment is a social engineering nirvana.=0AThe C= APTCHA could easily be shown to the user and they'd blissfully solve it jus= t=0Alike they do any other one.=0A=0A=0A=0A=0A>=0A> -----------------------= =0A> It is not the task of the authorization server to protect=0A>=A0 =A0 t= he end-user's device from malicious software.=A0 This is the=0A>=A0 =A0 res= ponsibility of the platform running on the particular device=0A>=A0 =A0 pro= bably in cooperation with other components of the respective=0A>=A0 =A0 eco= system (e.g. an application management infrastructure).=A0 The sole=0A>=A0 = =A0 responsibility of the authorization server is to control access to=0A>= =A0 =A0 the end-user's resources living in resource servers and to prevent= =0A>=A0 =A0 unauthorized access to them.=0A> -----------------------=0A=0AI= assume that it's in the authorization server's _interest_ to not divulge= =0Auser credentials to potentially evil third parties. If it's not, why wou= ld you=0Ago to the trouble of implementing OAUTH at all?=0A=0AThis is what'= s so troubling to me. The point is to keep user credentials away=0Afrom bad= guys, but when shown how OAUTH in widely deployed scenarios fails=0Ato do = that, the response I get from the working group is "Not Our Problem".=0AWel= l it *is* your problem insofar as you are not advising the twitterbooks to= =0Adisallow native apps as clients, for example.=0A=0A>=0A> wrt 2) Yes, I t= hink that's the reason. And OAuth is a appropriate protocol to achieve this= goal, even for mobile apps. Why?=0A>=0A> A typical mobile application cons= ists of the app itself on the device and a corresponding backend service st= oring user data and implementing business and integration logic. Let's assu= me this application features address book import from other service provide= rs. W/o OAuth, the app would gather the end-user's credential for a certain= address book service and pass it to its backend service. This service in t= urn uses this credentials to access the service provider's API. So in such = a scenario the following parties get in touch with the user credentials:=0A= > - the app=0A> - the app's backend service=0A> - the address book resource= server=0A=0AWith native mobile apps, the client (=3D app & app backend) is= n't it plenty=0Aenough to be seriously scary if they can screen scrape the = credentials=0Awith impunity? What problem was solved again?=0A=0A>=0A> What= threats do you see here? And which is most likely to occur? My favorite is= an attack against the log files or the database of the backend service in = order to obtain the end-users passwords for the resource server. Why? Becau= se the cost/benefit ratio for an attacker is much better then attacking any= app installation on a device and the protective measure on the resource se= rver might be more appropriate then on the client side (backend service).= =0A=0ABotnets prove that either is a successful business model. This isn't = a zero=0Asum game, after all.=0A=0A> OAuth mitigates this kind of attack by= reducing the number of parties handling user credentials to the authorizat= ion server and the user agent. So even if the app itself would be the user = agent (which is not recommended), =0A=0ANot recommended? It's messed up eve= n thinking of it that way. The app is potentially=0A*evil*. It really doesn= 't care what the IETF RECOMMENDS. If it's useful for it to be the=0AUA, it'= s going to do just exactly that.=0A=0A> it would directly interact with the= authorization server and the app's backend service would use tokens instea= d of end-user credentials.=0A=0AThe problem here is the capture of end user= credentials. I believe that OAUTH=0Adefends pretty well in the trusted des= ktop browser scenario it set out to solve=0Afor. I do not believe that it d= oes that in the new reality of native apps, and embedded=0Awebviews.=0A=0A|= Moreover, the recommended way is to let the app delegate the flow to a tru= sted system=0A| component on the user's device, such as the system browser = or an account manager. In that=0A| case, the 3rd party is not getting in to= uch with the user credentials at all.=0A=0AAgain, the Bad Guys are specific= ally and completely uninterested in being good and=0Asending it to a truste= d component. They will disregard this RECOMMEND faster=0Athan you can type = it.=0A>=0A> I think the key question is whether anyone expects OAuth to sol= ve the phishing problem. I don't think this is its main purpose, but it cou= ld facilitate to overcome the habit to enter user credentials everywhere. A= nd this in turn may contribute to the fight against phishing.=0A=0AThere's = much more to this than just phishing.=0A=0AMike=0A_________________________= ______________________=0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps://www.= ietf.org/mailman/listinfo/oauth --1458549034-739163065-1325721020=:62165 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
  "  o  Client applications could be validated prio= r publication in a
      application market."
=
Should just be struck.  Michael is correct that it's fl= uff, and unenforceable.  There are too many app marketplaces, opensour= ce projects, etc. to make this a useful suggestion.

From: Michael= Thomas <mike@mtcc.com>
To:= Torsten Lodderstedt <torsten@lodderstedt.net>
Cc: Barry Leiba <barryleiba@com= puter.org>; oauth WG <oauth@ietf.org>
Sent: Wednesday, January 4, 2012 3:40 PM
<= span style=3D"font-weight: bold;">Subject: Re: [OAUTH-WG] WGLC o= n draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011
=0AOn= 01/04/2012 02:14 PM, Torsten Lodderstedt wrote:
> Hi Michael,
>= ;
> Am 04.01.2012 22:06, schrieb Michael Thomas:
>> I think = the "perhaps unwisely" goes to the heart of my objection. You
>> m= ight as well be talking about "perhaps unwisely" driving a car,
>>= or "perhaps unwisely" eating food: the reality is that people download
= >> apps by the *billions*.  When I was initially blown off, many= of the
>> participants including document editors implied that on= ly idiots get
>> apps for their phones. That is *completely* unhel= pful as the reality
>> is that OAUTH's use is hugely if not primar= ily deployed in that sort of
>> environment.
>
> I ful= ly agree with you. That's why the core spec and the threat document both co= nsider native apps.
>
>>
>> This is a threat that c= uts to the very heart of what OAUTH is, and purports
>> to defend against: keeping user credentials out of the hands of an
>= > untrusted third party. If there really aren't any good ways to mitigat= e this
>> in an app environment, why is OAUTH being deployed so ag= gressively there?
>> Shouldn't the threat draft say in blinking bo= ld: "DEPLOYING OAUTH
>> IN NATIVE APPS CONSIDERED HARMFUL"?
>= ;
> You lost me. Is the situation getting any worse with OAuth? I don= 't think so. I think the situation is getting better, probably not as you m= ight expect.

My concern is that putting on a veneer of "security" wi= ll lull people into
thinking "Oh, it's safe to enter my credentials here= because this is really
twitterbook, not evilapp!". When I had to ask th= em directly to put their
twitterbook credentials into my app, there at l= east wasn't any confusion
that I had access to them.

Realisticall= y, what you've done is protected the credentials from the good
guys and not changed much for a motivated bad guy. Is that an impr= ovement?
I'll buy that it's generally bad practice for good guys with mo= st likely bad
security chops to  be storing credentials, but I'm gu= essing that the original
OAUTH motivation was more toward thwarting bad = guys.

>
> The key question is: Why do we aim on "keeping us= er credentials out of the hands of an untrusted third party"?
>
&g= t; 1) To prevent phishing or 2) to prevent leakage of end-user credentials = due to inappropriate handling or weak defence on the 3rd party?
>
= > wrt 1) I don't think so. I don't see how an authorization server shall= validate the authenticity and trustworthiness of a client-side application= . We already state this in section 4.4.1.4. of the threat document.

= The draft says:

  o  Client applications could be validate= d prior publication in a
      application market.

I asked -- and didn't get a response -- about how exactly t= hat might be done. I suspect
that in practice for the twitterbook univer= se that there is no way that scales. So the
reality here seems to be the= re isn't an answer for the Internet at large, and the threats
document s= hould just say that mitigation MAY be possible in very narrow use cases whe= re
code reviews, and other heavy handed analysis can be performed, but f= or the general case
there is no mitigation.

As far as 4.4.1.4 goe= s, I'd say that the counter measures really don't help except
maybe for = auditing. If that's what they're really about, the draft should make thatexplicit.

Also on the subject of 4.4.1.4, this bullet:


= o  If the authorization server automatically authenticates the end-      user, it may nevertheless require some user input in= order to
      prevent screen scraping.  Examples are CAPTCHAs or user-specific
      secret lik= e PIN codes.


I'm very skeptical because a native environment is = a social engineering nirvana.
The CAPTCHA could easily be shown to the u= ser and they'd blissfully solve it just
like they do any other one.
<= br>


>
> -----------------------
> It is not the t= ask of the authorization server to protect
>    the end-use= r's device from malicious software.  This is the
>    = responsibility of the platform running on the particular device
>&nbs= p;   probably in cooperation with other components of the respective>    ecosystem (e.g. an application management infrastructur= e).  The sole
>    responsibility of the authorization= server is to control access to
>    the end-user's resourc= es living in resource servers and to prevent
>    unauthorized access to them.
> -----------------------

I assu= me that it's in the authorization server's _interest_ to not divulge
use= r credentials to potentially evil third parties. If it's not, why would you=
go to the trouble of implementing OAUTH at all?

This is what's s= o troubling to me. The point is to keep user credentials away
from bad g= uys, but when shown how OAUTH in widely deployed scenarios fails
to do t= hat, the response I get from the working group is "Not Our Problem".
Wel= l it *is* your problem insofar as you are not advising the twitterbooks to<= br>disallow native apps as clients, for example.

>
> wrt 2)= Yes, I think that's the reason. And OAuth is a appropriate protocol to ach= ieve this goal, even for mobile apps. Why?
>
> A typical mobile= application consists of the app itself on the device and a corresponding b= ackend service storing user data and implementing business and integration logic. Let's assume this application features address book imp= ort from other service providers. W/o OAuth, the app would gather the end-u= ser's credential for a certain address book service and pass it to its back= end service. This service in turn uses this credentials to access the servi= ce provider's API. So in such a scenario the following parties get in touch= with the user credentials:
> - the app
> - the app's backend s= ervice
> - the address book resource server

With native mobile= apps, the client (=3D app & app backend) isn't it plenty
enough to = be seriously scary if they can screen scrape the credentials
with impuni= ty? What problem was solved again?

>
> What threats do you = see here? And which is most likely to occur? My favorite is an attack again= st the log files or the database of the backend service in order to obtain = the end-users passwords for the resource server. Why? Because the cost/benefit ratio for an attacker is much better then attacking any app i= nstallation on a device and the protective measure on the resource server m= ight be more appropriate then on the client side (backend service).

= Botnets prove that either is a successful business model. This isn't a zero=
sum game, after all.

> OAuth mitigates this kind of attack by= reducing the number of parties handling user credentials to the authorizat= ion server and the user agent. So even if the app itself would be the user = agent (which is not recommended),

Not recommended? It's messed up e= ven thinking of it that way. The app is potentially
*evil*. It really do= esn't care what the IETF RECOMMENDS. If it's useful for it to be the
UA,= it's going to do just exactly that.

> it would directly interact= with the authorization server and the app's backend service would use toke= ns instead of end-user credentials.

The problem here is the capture of end user credentials. I believe that OAUTH
defends pretty we= ll in the trusted desktop browser scenario it set out to solve
for. I do= not believe that it does that in the new reality of native apps, and embed= ded
webviews.

| Moreover, the recommended way is to let the app d= elegate the flow to a trusted system
| component on the user's device, s= uch as the system browser or an account manager. In that
| case, the 3rd= party is not getting in touch with the user credentials at all.

Aga= in, the Bad Guys are specifically and completely uninterested in being good= and
sending it to a trusted component. They will disregard this RECOMME= ND faster
than you can type it.
>
> I think the key question= is whether anyone expects OAuth to solve the phishing problem. I don't thi= nk this is its main purpose, but it could facilitate to overcome the habit = to enter user credentials everywhere. And this in turn may contribute to the fight against phishing.

There's much more to this= than just phishing.

Mike
_______________________________________= ________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailma= n/listinfo/oauth


--1458549034-739163065-1325721020=:62165-- From mike@mtcc.com Wed Jan 4 15:58:23 2012 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 6CCD911E80A2 for ; Wed, 4 Jan 2012 15:58:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rknKEtWecQjU for ; Wed, 4 Jan 2012 15:58:22 -0800 (PST) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 839E311E80B9 for ; Wed, 4 Jan 2012 15:58:22 -0800 (PST) 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 q04NwJD2010520 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 4 Jan 2012 15:58:19 -0800 Message-ID: <4F04E79B.1030604@mtcc.com> Date: Wed, 04 Jan 2012 15:58:19 -0800 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: <8AB6F5CC-E9A2-4A07-9AA0-83FB7C67A221@oracle.com> <4EEA3951.5010904@mtcc.com> <4EEB5BDD.7080401@mtcc.com> <4F038CB9.1040403@mtcc.com> <4F0394D6.1090006@mtcc.com> <4F04AAAE.6080702@mtcc.com> <4F04ACE4.1070006@stpeter.im> <4F04B101.3070708@mtcc.com> <4F04BF70.3010501@mtcc.com> <1325720576.43079.YahooMailNeo@web31816.mail.mud.yahoo.com> In-Reply-To: <1325720576.43079.YahooMailNeo@web31816.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3884; t=1325721500; x=1326585500; 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]=20WGLC=20on=20draft-ietf-oau th-v2-threatmodel-01,=20ends=209=0A=20Dec=202011 |Sender:=20 |To:=20William=20Mills=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=RtQt8+LXLvWWVJCxm03UNsMuPyJSiNUrQARYApK8wYc=; b=rgWz86pRaOLdnGfr77fUayQnTYek6fqfc3bkcUCyYuxvhepYFJ0I2M1Nas auljZz02MbrppzY32hqPXQuBV42SK7V6oAFc5Dli4PbQ0NzAXXCasNv6Ph6f bqK440VdYIgaq7pVzvWbpeJKiuPuMisaqBWxIVCUQPgYpvEybvHTE=; 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: Barry Leiba , oauth WG Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011 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, 04 Jan 2012 23:58:23 -0000 On 01/04/2012 03:42 PM, William Mills wrote: > I think the threat draft should simply say, "OAuth does not and can not= protect the user against credential compromise as a result of phishing, = malware, social engineering, or machine compromise." I could live with something like this, but I think it needs to be much mo= re explicit that it applies to any authentication service that allows native= apps as clients with no form of strong app vetting. It may even be useful to point to a c= ouple of large deployments who are at risk from this, like, oh say, twitterbook. If this draft doesn't take a strong stand against that practice, it's doi= ng nothing more than giving a wink and a nod that what twitterbook is currently doin= g is safe. That's bad, but I suspect it's the elephant in the room. Mike > > Get rid of the fancy rhetoric, we don't need to explain a lot more than= this. > > I don't agree that OAuth purports to solve these problems. What it solv= es is limiting the credentials granted to allow the user more control and= limited damage in the event of credential misuse. > > -bill > > -----------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= ------------------------------------------- > *From:* Michael Thomas > *To:* Barry Leiba > *Cc:* oauth WG > *Sent:* Wednesday, January 4, 2012 1:06 PM > *Subject:* Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, e= nds 9 Dec 2011 > > On 01/04/2012 12:41 PM, Barry Leiba wrote: > > up being a compromised browser or a native application that the user > > perhaps unwisely installed, all the security in the framework goes ou= t > ^^^^^^^^^ > > the window, because an untrustworthy UA can fiddle with pretty much > > everything. > > > > I think the "perhaps unwisely" goes to the heart of my objection. You > might as well be talking about "perhaps unwisely" driving a car, > or "perhaps unwisely" eating food: the reality is that people download > apps by the *billions*. When I was initially blown off, many of the > participants including document editors implied that only idiots get > apps for their phones. That is *completely* unhelpful as the reality > is that OAUTH's use is hugely if not primarily deployed in that sort of= > environment. > > This is a threat that cuts to the very heart of what OAUTH is, and purp= orts > to defend against: keeping user credentials out of the hands of an > untrusted third party. If there really aren't any good ways to mitigate= this > in an app environment, why is OAUTH being deployed so aggressively ther= e? > Shouldn't the threat draft say in blinking bold: "DEPLOYING OAUTH > IN NATIVE APPS CONSIDERED HARMFUL"? > > Mike > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From eran@hueniverse.com Wed Jan 4 16:05:21 2012 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 D901711E80D7 for ; Wed, 4 Jan 2012 16:05:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kuGWNAoKxp2T for ; Wed, 4 Jan 2012 16:05:21 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 5F84D11E80D6 for ; Wed, 4 Jan 2012 16:05:21 -0800 (PST) Received: (qmail 21495 invoked from network); 5 Jan 2012 00:05:15 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 5 Jan 2012 00:05:15 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 4 Jan 2012 17:05:14 -0700 From: Eran Hammer-Lahav To: Michael Thomas , Torsten Lodderstedt Date: Wed, 4 Jan 2012 17:05:04 -0700 Thread-Topic: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011 Thread-Index: AczLOj5/vFTqXYWhQJWpkTNRCwYjxwAAdI6Q Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453A72D09B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <8AB6F5CC-E9A2-4A07-9AA0-83FB7C67A221@oracle.com> <4EEA3951.5010904@mtcc.com> <4EEB5BDD.7080401@mtcc.com> <4F038CB9.1040403@mtcc.com> <4F0394D6.1090006@mtcc.com> <4F04AAAE.6080702@mtcc.com> <4F04ACE4.1070006@stpeter.im> <4F04B101.3070708@mtcc.com> <4F04BF70.3010501@mtcc.com> <4F04CF60.1050000@lodderstedt.net> <4F04E362.5070406@mtcc.com> In-Reply-To: <4F04E362.5070406@mtcc.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: Barry Leiba , oauth WG Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011 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, 05 Jan 2012 00:05:22 -0000 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Michael Thomas > Sent: Wednesday, January 04, 2012 3:40 PM > My concern is that putting on a veneer of "security" will lull people int= o > thinking "Oh, it's safe to enter my credentials here because this is real= ly > twitterbook, not evilapp!". When I had to ask them directly to put their > twitterbook credentials into my app, there at least wasn't any confusion = that > I had access to them. This is ridiculous (e.g. the fact we are still discussing this). First, end users know nothing about security or OAuth. Second, evil apps ca= n create this veneer of security by faking a redirection flow with or witho= ut OAuth. Suggesting that OAuth (which is a de-facto web pattern for over a= decade) makes anything worse is patently false. The only thing we can possibly add to the threat model document is to menti= on that "OAuth does not provide any protection against malicious applicatio= ns and that the end user is solely responsible for the trustworthiness of a= ny native application installed". That is accurate (and completely obvious = to the target audience of this document). It is not very helpful but if it = will make you feel better (since no one else here seems to share your conce= rns), I have no objection to such one line added. And again, to highlight the absurdity of your security claim, it is equally= important to warn developers in earthquake-prone countries to put enough d= istance between the Approve and Deny buttons so that the user will not acci= dentally hit Approve during a tremor. EHL =20 From mike@mtcc.com Wed Jan 4 16:39:23 2012 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 4585A11E80EA for ; Wed, 4 Jan 2012 16:39:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f6bgHZstwi18 for ; Wed, 4 Jan 2012 16:39:22 -0800 (PST) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 6C58511E80D7 for ; Wed, 4 Jan 2012 16:39:22 -0800 (PST) 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 q050dG1R024772 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 4 Jan 2012 16:39:16 -0800 Message-ID: <4F04F134.5050409@mtcc.com> Date: Wed, 04 Jan 2012 16:39:16 -0800 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: Eran Hammer-Lahav References: <8AB6F5CC-E9A2-4A07-9AA0-83FB7C67A221@oracle.com> <4EEA3951.5010904@mtcc.com> <4EEB5BDD.7080401@mtcc.com> <4F038CB9.1040403@mtcc.com> <4F0394D6.1090006@mtcc.com> <4F04AAAE.6080702@mtcc.com> <4F04ACE4.1070006@stpeter.im> <4F04B101.3070708@mtcc.com> <4F04BF70.3010501@mtcc.com> <4F04CF60.1050000@lodderstedt.net> <4F04E362.5070406@mtcc.com> <90C41DD21FB7C64BB94121FBBC2E723453A72D09B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453A72D09B9@P3PW5EX1MB01.EX1.SECURESERVER.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=3230; t=1325723958; x=1326587958; 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]=20WGLC=20on=20draft-ietf-oau th-v2-threatmodel-01,=20ends=209=0A=20Dec=202011 |Sender:=20 |To:=20Eran=20Hammer-Lahav=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=H0Csd9lPQnrauQ4LdAODSb/6Yt2avsmimEWC9fmzVvo=; b=qcCPA4V/mspemuREXIG0ftupEVCJ4JeubPsqnzAWV9pVNFwuMHRfByTYzu 3OKYDOKFN0LStlC5803q7+dI+eHauVuBJ0DA/EtlyTxrl2IGpoIxdx8tb4Rj MDDcjrxhi+kJatca2TG1jv1h4M3zUHwDvlDu5vOas8RSYiBx07Gso=; 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 WG , Barry Leiba Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011 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, 05 Jan 2012 00:39:23 -0000 On 01/04/2012 04:05 PM, Eran Hammer-Lahav wrote: > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Michael Thomas >> Sent: Wednesday, January 04, 2012 3:40 PM >> My concern is that putting on a veneer of "security" will lull people into >> thinking "Oh, it's safe to enter my credentials here because this is really >> twitterbook, not evilapp!". When I had to ask them directly to put their >> twitterbook credentials into my app, there at least wasn't any confusion that >> I had access to them. > This is ridiculous (e.g. the fact we are still discussing this). > > First, end users know nothing about security or OAuth. Second, evil apps can create this veneer of security by faking a redirection flow with or without OAuth. Suggesting that OAuth (which is a de-facto web pattern for over a decade) makes anything worse is patently false. > > The only thing we can possibly add to the threat model document is to mention that "OAuth does not provide any protection against malicious applications and that the end user is solely responsible for the trustworthiness of any native application installed". That is accurate (and completely obvious to the target audience of this document). It is not very helpful but if it will make you feel better (since no one else here seems to share your concerns), I have no objection to such one line added. > > And again, to highlight the absurdity of your security claim, it is equally important to warn developers in earthquake-prone countries to put enough distance between the Approve and Deny buttons so that the user will not accidentally hit Approve during a tremor. > It's this kind of hostility and ad hominem that leads me to believe that you have forgotten some of your lessons in charm school. For one, I am not the only one and even if I were that would still not be a reason to shoot the messenger. Secondly it is *not* the sole responsibility of the end user: the authentication server absolutely has a part to play here too. They have to give out client keys, after all, and its their service that could be hacked. So they have as much if not more responsibility than the end user. So to Bill's request here is the text I would propose. "Native apps, not limited to, but including apps which are available on popular mobile app stores, have the potential for gaining access to the end user's credentials. This can be accomplished by gaining access to browser UI components and key logging, spoofing the look and feel of an authentication server's authentication page, and potentially many other social engineering attacks. The potential for these attacks exist in many existing OAUTH2 deployments including but not limited to Facebook and Twitter. Given these threats, authentication servers MUST NOT give clients access to authentication services -- and by extension to resource services -- unless the authentication service can thoroughly vet the trustworthiness of the client. How that vetting is achieved is outside of the scope of this document, but the current practice of freely giving client keys to any would-be OAUTH client is not sufficient." Mike From wmills@yahoo-inc.com Wed Jan 4 17:16:15 2012 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 3089F21F87CE for ; Wed, 4 Jan 2012 17:16:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.211 X-Spam-Level: X-Spam-Status: No, score=-17.211 tagged_above=-999 required=5 tests=[AWL=0.387, 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 1HxYKMR7m-0I for ; Wed, 4 Jan 2012 17:16:14 -0800 (PST) Received: from nm13-vm0.bullet.mail.ac4.yahoo.com (nm13-vm0.bullet.mail.ac4.yahoo.com [98.139.52.232]) by ietfa.amsl.com (Postfix) with SMTP id 04FAC21F87CB for ; Wed, 4 Jan 2012 17:16:13 -0800 (PST) Received: from [98.139.52.195] by nm13.bullet.mail.ac4.yahoo.com with NNFMP; 05 Jan 2012 01:16:07 -0000 Received: from [98.139.52.169] by tm8.bullet.mail.ac4.yahoo.com with NNFMP; 05 Jan 2012 01:16:07 -0000 Received: from [127.0.0.1] by omp1052.mail.ac4.yahoo.com with NNFMP; 05 Jan 2012 01:16:07 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 834142.298.bm@omp1052.mail.ac4.yahoo.com Received: (qmail 64115 invoked by uid 60001); 5 Jan 2012 01:16:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1325726167; bh=Xutx8L3IpZcT1o5luKWFEo3HRw6+n2uqsno6xXiRPsw=; 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=Q84NW9K7zWIq8hmYgivm9jh9LKyL+I5Y/lpccRk68uMzdwXJc7r6E7XsPZu3wzEFzuGIwFEcgIZ5cLyBLDR2ivR11uiX1tzCZh6dtJd1+woH2nR1EDKmuF/Ht64jxOxAXcmm+G+Qt7yIN3QcA0FrCRtEfh4cnTC4LBtUyLNja7o= 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=gNghri7Kh7+joxxVcl1DJQ+BkGA/YI2hna5+wHER7NrxL5866wMvxSmf6tlTWPEuksLHTWTXFmjz7qs/XJClSTfusqqO6bUR1rzOtSOzZLjBuoHOafgiul8oTxtSns1GEkCuZrUnC8iTWMGe9XNtB4a42CmSUniiY36DUagHQfc=; X-YMail-OSG: GCOqGFwVM1nqrwIuqEJXWXiwypo9_QnJ4GtsxFzCWgibbBt OiQ6SjK7kGgkBrIOM93kattnAfqJJc_5NhhXkM3yaPtv5P3TIsXWOXnKUCD1 PYZia4ZL6G0.xL9GP00mme8lyrkK3a76Ythm_uijDhQh2tZ_aWDRVbgrfodC Fe.u3ZeXfIxqshyNBXWzuTmeGZCT3nZSW2qwT4PGBZtXSGCF.4JjnER2fJ4L LFk_7XdZBP7AHK8iZOQXdAUNz.0KCKmr0w3LyommrVDEid6JfwdtlJGZXFV1 gXFTHnntsaS2PLY1MW1N.9dFu8wlldQW.fOY.pPOGESGOb5LVTEaXQRAFQ8i 4v6nAi_27JJdGRlbZvgOTZqnr.NYMBE_2AbHguQREkKCwWjb2LFt5Wg.OGvY iGetuQALiw2axnSA40ePi30RJVCe7WVtbRsMiD0yqxg-- Received: from [209.131.62.113] by web31813.mail.mud.yahoo.com via HTTP; Wed, 04 Jan 2012 17:16:07 PST X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.116.331537 References: <8AB6F5CC-E9A2-4A07-9AA0-83FB7C67A221@oracle.com> <4EEA3951.5010904@mtcc.com> <4EEB5BDD.7080401@mtcc.com> <4F038CB9.1040403@mtcc.com> <4F0394D6.1090006@mtcc.com> <4F04AAAE.6080702@mtcc.com> <4F04ACE4.1070006@stpeter.im> <4F04B101.3070708@mtcc.com> <4F04BF70.3010501@mtcc.com> <4F04CF60.1050000@lodderstedt.net> <4F04E362.5070406@mtcc.com> <90C41DD21FB7C64BB94121FBBC2E723453A72D09B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4F04F134.5050409@mtc c.com> Message-ID: <1325726167.42441.YahooMailNeo@web31813.mail.mud.yahoo.com> Date: Wed, 4 Jan 2012 17:16:07 -0800 (PST) From: William Mills To: Michael Thomas , Eran Hammer-Lahav In-Reply-To: <4F04F134.5050409@mtcc.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="767760015-706396534-1325726167=:42441" Cc: Barry Leiba , oauth WG Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011 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, 05 Jan 2012 01:16:15 -0000 --767760015-706396534-1325726167=:42441 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable The below is unfortunately probably a no-go:=0A=0A=0A> Given these threats,= authentication servers MUST NOT give clients access=0A> to authentication = services -- and by extension to resource services -- unless the=0A> authent= ication service can thoroughly vet the trustworthiness of the client. How= =0A> that vetting is achieved is outside of the scope of this document, but= the current=0A> practice of freely giving client keys to any would-be OAUT= H client is not sufficient."=0A=0A=0AIt's unfortunately not really a solved= problem for widely distributed clients.=A0 I attack this by spoofing a kno= wn client and the resource server or auth server can't tell the difference.= =A0 That's why I was falling back to the more brutal "this doesn't protect = you from ..." statement.=0A=0ANative mobile clients where the default exper= ience is likely to be not to spawn a browser for the interaction are going = to be a real problem too.=0A=0AAuth servers (I think that's where you get t= he best control) can do their best to keep track of what clients a user has= authenticated and prompt the user on a new client, but it's still up to th= e user to make sure they're not being lied to, and in practice this is only= marginally effective (and tends in fact to slow adoption with a "scary" me= ssage, so product type folks don't like it). =0A=0A=0A-bill=0A=0A=0A=0A=0A_= _______________________________=0A From: Michael Thomas =0AT= o: Eran Hammer-Lahav =0ACc: oauth WG = ; Barry Leiba =0ASent: Wednesday, January 4, 2012= 4:39 PM=0ASubject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-= 01, ends 9 Dec 2011=0A =0AOn 01/04/2012 04:05 PM, Eran Hammer-Lahav wrote:= =0A>=0A>> -----Original Message-----=0A>> From: oauth-bounces@ietf.org [mai= lto:oauth-bounces@ietf.org] On Behalf=0A>> Of Michael Thomas=0A>> Sent: Wed= nesday, January 04, 2012 3:40 PM=0A>> My concern is that putting on a venee= r of "security" will lull people into=0A>> thinking "Oh, it's safe to enter= my credentials here because this is really=0A>> twitterbook, not evilapp!"= . When I had to ask them directly to put their=0A>> twitterbook credentials= into my app, there at least wasn't any confusion that=0A>> I had access to= them.=0A> This is ridiculous (e.g. the fact we are still discussing this).= =0A>=0A> First, end users know nothing about security or OAuth. Second, evi= l apps can create this veneer of security by faking a redirection flow with= or without OAuth. Suggesting that OAuth (which is a de-facto web pattern f= or over a decade) makes anything worse is patently false.=0A>=0A> The only = thing we can possibly add to the threat model document is to mention that "= OAuth does not provide any protection against malicious applications and th= at the end user is solely responsible for the trustworthiness of any native= application installed". That is accurate (and completely obvious to the ta= rget audience of this document). It is not very helpful but if it will make= you feel better (since no one else here seems to share your concerns), I h= ave no objection to such one line added.=0A>=0A> And again, to highlight th= e absurdity of your security claim, it is equally important to warn develop= ers in earthquake-prone countries to put enough distance between the Approv= e and Deny buttons so that the user will not accidentally hit Approve durin= g a tremor.=0A>=0A=0AIt's this kind of hostility and ad hominem that leads = me to believe that=0Ayou have forgotten some of your lessons in charm schoo= l.=0A=0AFor one, I am not the only one and even if I were that would still = not be=0Aa reason to shoot the messenger. Secondly it is *not* the sole res= ponsibility=0Aof the end user: the authentication server absolutely has a p= art to play=0Ahere too. They have to give out client keys, after all, and i= ts their service=0Athat could be hacked. So they have as much if not more r= esponsibility=0Athan the end user.=0A=0ASo to Bill's request here is the te= xt I would propose.=0A=0A"Native apps, not limited to, but including apps w= hich are available on popular=0Amobile app stores, have the potential for g= aining access to the end user's credentials.=0AThis can be accomplished by = gaining access to browser UI components and key logging,=0Aspoofing the loo= k and feel of an authentication server's authentication page, and=0Apotenti= ally many other social engineering attacks. The potential for these attacks= =0Aexist in many existing OAUTH2 deployments including but not limited to F= acebook=0Aand Twitter.=0A=0AGiven these threats, authentication servers MUS= T NOT give clients access=0Ato authentication services -- and by extension = to resource services -- unless the=0Aauthentication service can thoroughly = vet the trustworthiness of the client. How=0Athat vetting is achieved is ou= tside of the scope of this document, but the current=0Apractice of freely g= iving client keys to any would-be OAUTH client is not sufficient."=0A=0AMik= e=0A_______________________________________________=0AOAuth mailing list=0A= OAuth@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/oauth --767760015-706396534-1325726167=:42441 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
The = below is unfortunately probably a no-go:

> = Given these threats, authentication servers MUST NOT give clients access> to authentication services -- and by extension to resource services -= - unless the
> authentication service can thoroughly vet the trustwor= thiness of the client. How
> that vetting is achieved is outside of t= he scope of this document, but the current
> practice of freely givin= g client keys to any would-be OAUTH client is not sufficient."

It's unfortunately not really a solved problem for widely = distributed clients.  I attack this by spoofing a known client and the= resource server or auth server can't tell the difference.  That's why= I was falling back to the more brutal "this doesn't protect you from ..." statement.

Native mobile clients where the d= efault experience is likely to be not to spawn a browser for the interactio= n are going to be a real problem too.

Auth servers= (I think that's where you get the best control) can do their best to keep = track of what clients a user has authenticated and prompt the user on a new= client, but it's still up to the user to make sure they're not being lied = to, and in practice this is only marginally effective (and tends in fact to= slow adoption with a "scary" message, so product type folks don't like it)= .

-bill



From:= Michael Thomas <mike@mtcc.com>
To: Eran Hammer-Lahav <eran@hueniverse.com>
Cc: oauth WG <oauth@ietf.org= >; Barry Leiba <barryleiba@computer.org>
Sent: Wednesday, January 4, 2012 4:39 PM
<= b>Subject: Re: [OAUTH-WG] WGL= C on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011
= =0AOn 01/04/2012 04:05 PM, Eran Hammer-Lahav wrote:
>
>> ---= --Original Message-----
>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
>> Of Mi= chael Thomas
>> Sent: Wednesday, January 04, 2012 3:40 PM
>&= gt; My concern is that putting on a veneer of "security" will lull people i= nto
>> thinking "Oh, it's safe to enter my credentials here becaus= e this is really
>> twitterbook, not evilapp!". When I had to ask = them directly to put their
>> twitterbook credentials into my app,= there at least wasn't any confusion that
>> I had access to them.=
> This is ridiculous (e.g. the fact we are still discussing this).>
> First, end users know nothing about security or OAuth. Secon= d, evil apps can create this veneer of security by faking a redirection flow = with or without OAuth. Suggesting that OAuth (which is a de-facto web patte= rn for over a decade) makes anything worse is patently false.
>
&g= t; The only thing we can possibly add to the threat model document is to me= ntion that "OAuth does not provide any protection against malicious applica= tions and that the end user is solely responsible for the trustworthiness o= f any native application installed". That is accurate (and completely obvio= us to the target audience of this document). It is not very helpful but if = it will make you feel better (since no one else here seems to share your co= ncerns), I have no objection to such one line added.
>
> And ag= ain, to highlight the absurdity of your security claim, it is equally impor= tant to warn developers in earthquake-prone countries to put enough distanc= e between the Approve and Deny buttons so that the user will not accidentally hit Approve during a tremor.
>

It's this kind of= hostility and ad hominem that leads me to believe that
you have forgott= en some of your lessons in charm school.

For one, I am not the only = one and even if I were that would still not be
a reason to shoot the mes= senger. Secondly it is *not* the sole responsibility
of the end user: th= e authentication server absolutely has a part to play
here too. They hav= e to give out client keys, after all, and its their service
that could b= e hacked. So they have as much if not more responsibility
than the end u= ser.

So to Bill's request here is the text I would propose.

"= Native apps, not limited to, but including apps which are available on popu= lar
mobile app stores, have the potential for gaining access to the end = user's credentials.
This can be accomplished by gaining access to browse= r UI components and key logging,
spoofing the look and feel of an authentication server's authentication page, and
potentially many other= social engineering attacks. The potential for these attacks
exist in ma= ny existing OAUTH2 deployments including but not limited to Facebook
and= Twitter.

Given these threats, authentication servers MUST NOT give = clients access
to authentication services -- and by extension to resourc= e services -- unless the
authentication service can thoroughly vet the t= rustworthiness of the client. How
that vetting is achieved is outside of= the scope of this document, but the current
practice of freely giving c= lient keys to any would-be OAUTH client is not sufficient."

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


--767760015-706396534-1325726167=:42441-- From mike@mtcc.com Wed Jan 4 17:39:37 2012 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 4BD1721F85E4 for ; Wed, 4 Jan 2012 17:39:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wPxik03JZ3GA for ; Wed, 4 Jan 2012 17:39:36 -0800 (PST) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 4C85F21F85CD for ; Wed, 4 Jan 2012 17:39:36 -0800 (PST) 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 q051dV1o012967 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 4 Jan 2012 17:39:32 -0800 Message-ID: <4F04FF53.5040002@mtcc.com> Date: Wed, 04 Jan 2012 17:39:31 -0800 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: <8AB6F5CC-E9A2-4A07-9AA0-83FB7C67A221@oracle.com> <4EEA3951.5010904@mtcc.com> <4EEB5BDD.7080401@mtcc.com> <4F038CB9.1040403@mtcc.com> <4F0394D6.1090006@mtcc.com> <4F04AAAE.6080702@mtcc.com> <4F04ACE4.1070006@stpeter.im> <4F04B101.3070708@mtcc.com> <4F04BF70.3010501@mtcc.com> <4F04CF60.1050000@lodderstedt.net> <4F04E362.5070406@mtcc.com> <90C41DD21FB7C64BB94121FBBC2E723453A72D09B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4F04F134.5050409@mtcc.com> <1325726167.42441.YahooMailNeo@web31813.mail.mud.yahoo.com> In-Reply-To: <1325726167.42441.YahooMailNeo@web31813.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7338; t=1325727573; x=1326591573; 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]=20WGLC=20on=20draft-ietf-oau th-v2-threatmodel-01,=20ends=209=0A=20Dec=202011 |Sender:=20 |To:=20William=20Mills=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=IlwxcvgGI4N05vpfAhnABlig5EsvT3qPlMdFqExzGxo=; b=QYvkg4hU1SxHCzOBiR0zLpXEmBzwmZ714vLksVfIVq441VF3z0zqKdZVKb bnjBBcyUUpW95NKi3YdYTpxNJt7TfGEwJsBtKJzypB7QUfv1MGcBibmEyBrK 4Dv3k8vHYZtbvgE1OdiBvtzrBNa4rMFZvkhHIAEwjwpeNQ9VuI0hA=; 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: Barry Leiba , oauth WG Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011 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, 05 Jan 2012 01:39:37 -0000 On 01/04/2012 05:16 PM, William Mills wrote: > The below is unfortunately probably a no-go: > > > Given these threats, authentication servers MUST NOT give clients acc= ess > > to authentication services -- and by extension to resource services -= - unless the > > authentication service can thoroughly vet the trustworthiness of the = client. How > > that vetting is achieved is outside of the scope of this document, bu= t the current > > practice of freely giving client keys to any would-be OAUTH client is= not sufficient." > > It's unfortunately not really a solved problem for widely distributed c= lients. I attack this by spoofing a known client and the resource server= or auth server can't tell the difference. That's why I was falling back= to the more brutal "this doesn't protect you from ..." statement. So what you're saying is that it's even worse than what I wrote, which is pretty confining as to what clients an auth server should have a relationship with. I guess that's progress. A known client whose client keys are compromised is certainly a threat, but it at least requires one more step beyond just freely getting client keys from the auth service. On phone apps with no backend, for example, it's problematic to keep that key secret, but for clients that have backe= nd servers it's not as bad. Part of the vetting process could be "clients MU= ST NOT store client keys in a program that can be disassembled trivially lik= e a phone app". This may already be in this draft though, so apologies if I didn't see it. I guess I'd rather there not be a blanket MUST NOT -- I hope it doesn't come down to that -- but they way I'm reading you is that it will come down to just that. Mike > > Native mobile clients where the default experience is likely to be not = to spawn a browser for the interaction are going to be a real problem too= =2E > > Auth servers (I think that's where you get the best control) can do the= ir best to keep track of what clients a user has authenticated and prompt= the user on a new client, but it's still up to the user to make sure the= y're not being lied to, and in practice this is only marginally effective= (and tends in fact to slow adoption with a "scary" message, so product t= ype folks don't like it). > > -bill > > > > -----------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= ------------------------------------------- > *From:* Michael Thomas > *To:* Eran Hammer-Lahav > *Cc:* oauth WG ; Barry Leiba > *Sent:* Wednesday, January 4, 2012 4:39 PM > *Subject:* Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, e= nds 9 Dec 2011 > > On 01/04/2012 04:05 PM, Eran Hammer-Lahav wrote: > > > >> -----Original Message----- > >> From: oauth-bounces@ietf.org [mailto= :oauth-bounces@ietf.org ] On Behalf > >> Of Michael Thomas > >> Sent: Wednesday, January 04, 2012 3:40 PM > >> My concern is that putting on a veneer of "security" will lull peopl= e into > >> thinking "Oh, it's safe to enter my credentials here because this is= really > >> twitterbook, not evilapp!". When I had to ask them directly to put t= heir > >> twitterbook credentials into my app, there at least wasn't any confu= sion that > >> I had access to them. > > This is ridiculous (e.g. the fact we are still discussing this). > > > > First, end users know nothing about security or OAuth. Second, evil a= pps can create this veneer of security by faking a redirection flow with = or without OAuth. Suggesting that OAuth (which is a de-facto web pattern = for over a decade) makes anything worse is patently false. > > > > The only thing we can possibly add to the threat model document is to= mention that "OAuth does not provide any protection against malicious ap= plications and that the end user is solely responsible for the trustworth= iness of any native application installed". That is accurate (and complet= ely obvious to the target audience of this document). It is not very help= ful but if it will make you feel better (since no one else here seems to = share your concerns), I have no objection to such one line added. > > > > And again, to highlight the absurdity of your security claim, it is e= qually important to warn developers in earthquake-prone countries to put = enough distance between the Approve and Deny buttons so that the user wil= l not accidentally hit Approve during a tremor. > > > > It's this kind of hostility and ad hominem that leads me to believe tha= t > you have forgotten some of your lessons in charm school. > > For one, I am not the only one and even if I were that would still not = be > a reason to shoot the messenger. Secondly it is *not* the sole responsi= bility > of the end user: the authentication server absolutely has a part to pla= y > here too. They have to give out client keys, after all, and its their s= ervice > that could be hacked. So they have as much if not more responsibility > than the end user. > > So to Bill's request here is the text I would propose. > > "Native apps, not limited to, but including apps which are available on= popular > mobile app stores, have the potential for gaining access to the end use= r's credentials. > This can be accomplished by gaining access to browser UI components and= key logging, > spoofing the look and feel of an authentication server's authentication= page, and > potentially many other social engineering attacks. The potential for th= ese attacks > exist in many existing OAUTH2 deployments including but not limited to = Facebook > and Twitter. > > Given these threats, authentication servers MUST NOT give clients acces= s > to authentication services -- and by extension to resource services -- = unless the > authentication service can thoroughly vet the trustworthiness of the cl= ient. How > that vetting is achieved is outside of the scope of this document, but = the current > practice of freely giving client keys to any would-be OAUTH client is n= ot sufficient." > > Mike > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From mark.mcgloin@ie.ibm.com Thu Jan 5 06:02:05 2012 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 F23B121F881B for ; Thu, 5 Jan 2012 06:02:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 RluVFpl3zxlq for ; Thu, 5 Jan 2012 06:02:05 -0800 (PST) Received: from e06smtp11.uk.ibm.com (e06smtp11.uk.ibm.com [195.75.94.107]) by ietfa.amsl.com (Postfix) with ESMTP id B916521F8817 for ; Thu, 5 Jan 2012 06:02:04 -0800 (PST) Received: from /spool/local by e06smtp11.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 5 Jan 2012 14:02:02 -0000 Received: from d06nrmr1707.portsmouth.uk.ibm.com ([9.149.39.225]) by e06smtp11.uk.ibm.com ([192.168.101.141]) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 5 Jan 2012 14:02:01 -0000 Received: from d06av06.portsmouth.uk.ibm.com (d06av06.portsmouth.uk.ibm.com [9.149.37.217]) by d06nrmr1707.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q05E20Jk2539646 for ; Thu, 5 Jan 2012 14:02:00 GMT Received: from d06av06.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av06.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q05E1qLu009279 for ; Thu, 5 Jan 2012 07:01:52 -0700 Received: from d06ml091.portsmouth.uk.ibm.com (d06ml091.portsmouth.uk.ibm.com [9.149.104.170]) by d06av06.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q05E1qF8009274 for ; Thu, 5 Jan 2012 07:01:52 -0700 In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453A72D09B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <8AB6F5CC-E9A2-4A07-9AA0-83FB7C67A221@oracle.com> <4EEA3951.5010904@mtcc.com> <4EEB5BDD.7080401@mtcc.com> <4F038CB9.1040403@mtcc.com> <4F0394D6.1090006@mtcc.com> <4F04AAAE.6080702@mtcc.com> <4F04ACE4.1070006@stpeter.im> <4F04B101.3070708@mtcc.com> <4F04BF70.3 <90C41DD21FB7C64BB94121FBBC2E723453A72D09B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-KeepSent: 8B311AA2:ACF026F4-8025797C:00460040; type=4; name=$KeepSent To: OAuth WG X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 Message-ID: From: Mark Mcgloin Date: Thu, 5 Jan 2012 14:01:56 +0000 X-MIMETrack: Serialize by Router on D06ML091/06/M/IBM(Release 8.5.2FP1 ZX852FP1HF12|September 28, 2011) at 05/01/2012 14:01:55 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII x-cbid: 12010514-5024-0000-0000-0000014487BB Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011 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, 05 Jan 2012 14:02:06 -0000 Having read the suggested wording from Eran, William and Michael, I think Eran's description is the most succinct and relevant: "OAuth does not provide any protection against malicious applications and that the end user is solely responsible for the trustworthiness of any native application installed" @William: The threat has been described in the context of installing malicious apps so the wording above it more applicable @Michael: It has been repeated many times that we should only address security issues specific to Oauth, and Oauth does not make things worse if a user installs a malicious client. If you want to continue the discussion, please email me directly and we can revert to this forum if you still think your point is relevant Section 4.1.4 of the threat model will be updated as below. Remember the threat model is just offering advice on best practices. 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). 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: 1. The OAuth flow is designed so that client applications never need to know user passwords. Client applications SHOULD avoid directly asking users for the their credentials. In addition, end users could be educated about phishing attacks and best practices, such as only accessing trusted clients, as OAuth does not provide any protection against malicious applications and the end user is solely responsible for the trustworthiness of any native application installed 2. Client applications could be validated prior to publication in an application market for users to access. That validation is out of scope for OAuth but could include validating that the client application handles user authentication in an appropriate way 3. Client developers should not write client applications that collect authentication information directly from users and should instead delegate this task to a trusted system component, e.g. the system-browser. Regards Mark oauth-bounces@ietf.org wrote on 05/01/2012 00:05:04: > From: > > Eran Hammer-Lahav > > To: > > Michael Thomas , Torsten Lodderstedt > > Cc: > > Barry Leiba , oauth WG > > Date: > > 05/01/2012 00:05 > > Subject: > > Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011 > > Sent by: > > oauth-bounces@ietf.org > > > > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > > Of Michael Thomas > > Sent: Wednesday, January 04, 2012 3:40 PM > > > My concern is that putting on a veneer of "security" will lull people into > > thinking "Oh, it's safe to enter my credentials here because this is really > > twitterbook, not evilapp!". When I had to ask them directly to put their > > twitterbook credentials into my app, there at least wasn't any > confusion that > > I had access to them. > > This is ridiculous (e.g. the fact we are still discussing this). > > First, end users know nothing about security or OAuth. Second, evil > apps can create this veneer of security by faking a redirection flow > with or without OAuth. Suggesting that OAuth (which is a de-facto > web pattern for over a decade) makes anything worse is patently false. > > The only thing we can possibly add to the threat model document is > to mention that "OAuth does not provide any protection against > malicious applications and that the end user is solely responsible > for the trustworthiness of any native application installed". That > is accurate (and completely obvious to the target audience of this > document). It is not very helpful but if it will make you feel > better (since no one else here seems to share your concerns), I have > no objection to such one line added. > > And again, to highlight the absurdity of your security claim, it is > equally important to warn developers in earthquake-prone countries > to put enough distance between the Approve and Deny buttons so that > the user will not accidentally hit Approve during a tremor. > > EHL > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From mark.mcgloin@ie.ibm.com Thu Jan 5 06:03:53 2012 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 04AF821F882B for ; Thu, 5 Jan 2012 06:03:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, 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 p+zhbg+f7wpi for ; Thu, 5 Jan 2012 06:03:52 -0800 (PST) Received: from e06smtp10.uk.ibm.com (e06smtp10.uk.ibm.com [195.75.94.106]) by ietfa.amsl.com (Postfix) with ESMTP id 69A2B21F8684 for ; Thu, 5 Jan 2012 06:03:51 -0800 (PST) Received: from /spool/local by e06smtp10.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 5 Jan 2012 14:03:50 -0000 Received: from d06nrmr1707.portsmouth.uk.ibm.com ([9.149.39.225]) by e06smtp10.uk.ibm.com ([192.168.101.140]) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 5 Jan 2012 14:03:48 -0000 Received: from d06av06.portsmouth.uk.ibm.com (d06av06.portsmouth.uk.ibm.com [9.149.37.217]) by d06nrmr1707.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q05E3lna1777674; Thu, 5 Jan 2012 14:03:47 GMT Received: from d06av06.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av06.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q05E3bLw013071; Thu, 5 Jan 2012 07:03:38 -0700 Received: from d06ml091.portsmouth.uk.ibm.com (d06ml091.portsmouth.uk.ibm.com [9.149.104.170]) by d06av06.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q05E3bKu013063; Thu, 5 Jan 2012 07:03:37 -0700 In-Reply-To: <1325721020.62165.YahooMailNeo@web31812.mail.mud.yahoo.com> References: <8AB6F5CC-E9A2-4A07-9AA0-83FB7C67A221@oracle.com> <4EEA3951.5010904@mtcc.com> <4EEB5BDD.7080401@mtcc.com> <4F038CB9.1040403@mtcc.com> <4F0394D6.1090006@mtcc.com> <4F04AAAE.6080702@mtcc.com> <4F04ACE4.1070006@stpeter.im> <4F04B101.3070708@mtcc.com> <4F04BF70.3 <1325721020.62165.YahooMailNeo@web31812.mail.mud.yahoo.com> X-KeepSent: AD11189B:B32C550F-8025797C:004BC346; type=4; name=$KeepSent To: William Mills X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 Message-ID: From: Mark Mcgloin Date: Thu, 5 Jan 2012 14:03:41 +0000 X-MIMETrack: Serialize by Router on D06ML091/06/M/IBM(Release 8.5.2FP1 ZX852FP1HF12|September 28, 2011) at 05/01/2012 14:03:40 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII x-cbid: 12010514-4966-0000-0000-000001107CA9 Cc: oauth-bounces@ietf.org, Barry Leiba , oauth WG Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011 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, 05 Jan 2012 14:03:53 -0000 Why do you think this William? Apple does it? Google android market had to pull 30 apps recently because they contained malware. There are automated tools that will do some sanity checks on apps and it is only advice, i.e. 'could' Mark > William Mills > > " o Client applications could be validated prior publication in a > application market." > > Should just be struck. Michael is correct that it's fluff, and > unenforceable. There are too many app marketplaces, opensource > projects, etc. to make this a useful suggestion. > > From: Michael Thomas > To: Torsten Lodderstedt > Cc: Barry Leiba ; oauth WG > Sent: Wednesday, January 4, 2012 3:40 PM > Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, > ends 9 Dec 2011 > > On 01/04/2012 02:14 PM, Torsten Lodderstedt wrote: > > Hi Michael, > > > > Am 04.01.2012 22:06, schrieb Michael Thomas: > >> I think the "perhaps unwisely" goes to the heart of my objection. You > >> might as well be talking about "perhaps unwisely" driving a car, > >> or "perhaps unwisely" eating food: the reality is that people download > >> apps by the *billions*. When I was initially blown off, many of the > >> participants including document editors implied that only idiots get > >> apps for their phones. That is *completely* unhelpful as the reality > >> is that OAUTH's use is hugely if not primarily deployed in that sort of > >> environment. > > > > I fully agree with you. That's why the core spec and the threat > document both consider native apps. > > > >> > >> This is a threat that cuts to the very heart of what OAUTH is, and purports > >> to defend against: keeping user credentials out of the hands of an > >> untrusted third party. If there really aren't any good ways to > mitigate this > >> in an app environment, why is OAUTH being deployed so aggressively there? > >> Shouldn't the threat draft say in blinking bold: "DEPLOYING OAUTH > >> IN NATIVE APPS CONSIDERED HARMFUL"? > > > > You lost me. Is the situation getting any worse with OAuth? I > don't think so. I think the situation is getting better, probably > not as you might expect. > > My concern is that putting on a veneer of "security" will lull people into > thinking "Oh, it's safe to enter my credentials here because this is really > twitterbook, not evilapp!". When I had to ask them directly to put their > twitterbook credentials into my app, there at least wasn't any confusion > that I had access to them. > > Realistically, what you've done is protected the credentials from the good > guys and not changed much for a motivated bad guy. Is that an improvement? > I'll buy that it's generally bad practice for good guys with most likely bad > security chops to be storing credentials, but I'm guessing that the original > OAUTH motivation was more toward thwarting bad guys. > > > > > The key question is: Why do we aim on "keeping user credentials > out of the hands of an untrusted third party"? > > > > 1) To prevent phishing or 2) to prevent leakage of end-user > credentials due to inappropriate handling or weak defence on the 3rd party? > > > > wrt 1) I don't think so. I don't see how an authorization server > shall validate the authenticity and trustworthiness of a client-side > application. We already state this in section 4.4.1.4. of the threatdocument. > > The draft says: > > o Client applications could be validated prior publication in a > application market. > > I asked -- and didn't get a response -- about how exactly that might > be done. I suspect > that in practice for the twitterbook universe that there is no way > that scales. So the > reality here seems to be there isn't an answer for the Internet at > large, and the threats > document should just say that mitigation MAY be possible in very > narrow use cases where > code reviews, and other heavy handed analysis can be performed, but > for the general case > there is no mitigation. > > As far as 4.4.1.4 goes, I'd say that the counter measures really > don't help except > maybe for auditing. If that's what they're really about, the draft > should make that > explicit. > > Also on the subject of 4.4.1.4, this bullet: > > > o If the authorization server automatically authenticates the end- > user, it may nevertheless require some user input in order to > prevent screen scraping. Examples are CAPTCHAs or user-specific > secret like PIN codes. > > > I'm very skeptical because a native environment is a social > engineering nirvana. > The CAPTCHA could easily be shown to the user and they'd blissfully > solve it just > like they do any other one. > > > > > > > > ----------------------- > > It is not the task of the authorization server to protect > > the end-user's device from malicious software. This is the > > responsibility of the platform running on the particular device > > probably in cooperation with other components of the respective > > ecosystem (e.g. an application management infrastructure). The sole > > responsibility of the authorization server is to control access to > > the end-user's resources living in resource servers and to prevent > > unauthorized access to them. > > ----------------------- > > I assume that it's in the authorization server's _interest_ to not divulge > user credentials to potentially evil third parties. If it's not, whywould you > go to the trouble of implementing OAUTH at all? > > This is what's so troubling to me. The point is to keep user credentials away > from bad guys, but when shown how OAUTH in widely deployed scenarios fails > to do that, the response I get from the working group is "Not Our Problem". > Well it *is* your problem insofar as you are not advising the twitterbooks to > disallow native apps as clients, for example. > > > > > wrt 2) Yes, I think that's the reason. And OAuth is a appropriate > protocol to achieve this goal, even for mobile apps. Why? > > > > A typical mobile application consists of the app itself on the > device and a corresponding backend service storing user data and > implementing business and integration logic. Let's assume this > application features address book import from other service > providers. W/o OAuth, the app would gather the end-user's credential > for a certain address book service and pass it to its backend > service. This service in turn uses this credentials to access the > service provider's API. So in such a scenario the following parties > get in touch with the user credentials: > > - the app > > - the app's backend service > > - the address book resource server > > With native mobile apps, the client (= app & app backend) isn't it plenty > enough to be seriously scary if they can screen scrape the credentials > with impunity? What problem was solved again? > > > > > What threats do you see here? And which is most likely to occur? > My favorite is an attack against the log files or the database of > the backend service in order to obtain the end-users passwords for > the resource server. Why? Because the cost/benefit ratio for an > attacker is much better then attacking any app installation on a > device and the protective measure on the resource server might be > more appropriate then on the client side (backend service). > > Botnets prove that either is a successful business model. This isn't a zero > sum game, after all. > > > OAuth mitigates this kind of attack by reducing the number of > parties handling user credentials to the authorization server and > the user agent. So even if the app itself would be the user agent > (which is not recommended), > > Not recommended? It's messed up even thinking of it that way. The > app is potentially > *evil*. It really doesn't care what the IETF RECOMMENDS. If it's > useful for it to be the > UA, it's going to do just exactly that. > > > it would directly interact with the authorization server and the > app's backend service would use tokens instead of end-user credentials. > > The problem here is the capture of end user credentials. I believe that OAUTH > defends pretty well in the trusted desktop browser scenario it set > out to solve > for. I do not believe that it does that in the new reality of native > apps, and embedded > webviews. > > | Moreover, the recommended way is to let the app delegate the flow > to a trusted system > | component on the user's device, such as the system browser or an > account manager. In that > | case, the 3rd party is not getting in touch with the user > credentials at all. > > Again, the Bad Guys are specifically and completely uninterested in > being good and > sending it to a trusted component. They will disregard this RECOMMEND faster > than you can type it. > > > > I think the key question is whether anyone expects OAuth to solve > the phishing problem. I don't think this is its main purpose, but it > could facilitate to overcome the habit to enter user credentials > everywhere. And this in turn may contribute to the fight against phishing. > > There's much more to this than just phishing. > > 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 mike@mtcc.com Thu Jan 5 07:39:24 2012 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 45DBD21F875F for ; Thu, 5 Jan 2012 07:39:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dq9RClJcQFRv for ; Thu, 5 Jan 2012 07:39:23 -0800 (PST) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 31C3121F8716 for ; Thu, 5 Jan 2012 07:39:23 -0800 (PST) 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 q05FR853007228 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 5 Jan 2012 07:27:08 -0800 Message-ID: <4F05C14C.30801@mtcc.com> Date: Thu, 05 Jan 2012 07:27:08 -0800 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: Mark Mcgloin References: <8AB6F5CC-E9A2-4A07-9AA0-83FB7C67A221@oracle.com> <4EEA3951.5010904@mtcc.com> <4EEB5BDD.7080401@mtcc.com> <4F038CB9.1040403@mtcc.com> <4F0394D6.1090006@mtcc.com> <4F04AAAE.6080702@mtcc.com> <4F04ACE4.1070006@stpeter.im> <4F04B101.3070708@mtcc.com> <4F04BF70.3 <90C41DD21FB7C64BB94121FBBC2E723453A72D09B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: 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=6791; t=1325777292; x=1326641292; 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]=20WGLC=20on=20draft-ietf-oau th-v2-threatmodel-01,=20ends=209=0A=20Dec=202011 |Sender:=20 |To:=20Mark=20Mcgloin=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=GEmbL4N5Tzq9THBqKlOoh4JtfqbwkSZcp+wquMC9DQw=; b=Dsdq17c2VssUVtV8Kyq4O+wDi2w9rg27RYReFPTdV/eF7Qc87ffqVzKGEl kjWHOf38dGMzaKw3okjjEvuwlxDL52a3mCYzkGyv0CIAZBgif2bb0ok9W8Sh 0V543tCN5DwjPoAxHLinpLnvO56uk6U3CKPvZmDZkvW36sXhNU8Ts=; 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 WG Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011 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, 05 Jan 2012 15:39:24 -0000 The wording you propose is unacceptable. It is a rehash of the same misleading nonsense that is in there now. In particular #1 and #3 that say in effect "bad guys really should be good" are silly and unhelpful. #2 has possibilities, but in its current form gives absolutely no guidance as to what might be done; mine at least explicitly said that the status quo is unacceptable. I also completely object to the notion that the authentication service has no part in protecting itself. It has complete control over who it allows to register as a client, and as written Eran's text contradicts #2's possibility of mitigation -- even if William thinks it's hopeless (as I read him). If William is right the appropriate guidance is that authentication services MUST NOT enroll clients that use untrusted browsers. Putting this on the end users shoulders is useless and should be a reason that the IESG should just reject the protocol. I also object to not *explicitly* pointing out that native apps mean apps from App stores, markets, etc. and the general problem that users cannot know a priori whether an app is malicious or not. I don't see why this is even controversial -- unless your aim is to hide that uncomfortable fact. This is a threat document, not a marketing puff piece. Downplaying threats does nobody any good. Except bad guys. Mike On 01/05/2012 06:01 AM, Mark Mcgloin wrote: > Having read the suggested wording from Eran, William and Michael, I think > Eran's description is the most succinct and relevant: "OAuth does not > provide any protection against malicious applications and that the end user > is solely responsible for the trustworthiness of any native application > installed" > @William: The threat has been described in the context of installing > malicious apps so the wording above it more applicable > @Michael: It has been repeated many times that we should only address > security issues specific to Oauth, and Oauth does not make things worse if > a user installs a malicious client. If you want to continue the discussion, > please email me directly and we can revert to this forum if you still think > your point is relevant > > Section 4.1.4 of the threat model will be updated as below. Remember the > threat model is just offering advice on best practices. > > > 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). > > 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: > > 1. The OAuth flow is designed so that client applications never need to > know user passwords. Client applications SHOULD avoid directly asking users > for the their credentials. In addition, end users could be educated about > phishing attacks and best practices, such as only accessing trusted > clients, as OAuth does not provide any protection against malicious > applications and the end user is solely responsible for the trustworthiness > of any native application installed > > 2. Client applications could be validated prior to publication in an > application market for users to access. That validation is out of scope for > OAuth but could include validating that the client application handles user > authentication in an appropriate way > > 3. Client developers should not write client applications that collect > authentication information directly from users and should instead delegate > this task to a trusted system component, e.g. the system-browser. > > Regards > Mark > > oauth-bounces@ietf.org wrote on 05/01/2012 00:05:04: > >> From: >> >> Eran Hammer-Lahav >> >> To: >> >> Michael Thomas, Torsten Lodderstedt > >> Cc: >> >> Barry Leiba, oauth WG >> >> Date: >> >> 05/01/2012 00:05 >> >> Subject: >> >> Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec > 2011 >> Sent by: >> >> oauth-bounces@ietf.org >> >> >> >>> -----Original Message----- >>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >>> Of Michael Thomas >>> Sent: Wednesday, January 04, 2012 3:40 PM >>> My concern is that putting on a veneer of "security" will lull people > into >>> thinking "Oh, it's safe to enter my credentials here because this is > really >>> twitterbook, not evilapp!". When I had to ask them directly to put > their >>> twitterbook credentials into my app, there at least wasn't any >> confusion that >>> I had access to them. >> This is ridiculous (e.g. the fact we are still discussing this). >> >> First, end users know nothing about security or OAuth. Second, evil >> apps can create this veneer of security by faking a redirection flow >> with or without OAuth. Suggesting that OAuth (which is a de-facto >> web pattern for over a decade) makes anything worse is patently false. >> >> The only thing we can possibly add to the threat model document is >> to mention that "OAuth does not provide any protection against >> malicious applications and that the end user is solely responsible >> for the trustworthiness of any native application installed". That >> is accurate (and completely obvious to the target audience of this >> document). It is not very helpful but if it will make you feel >> better (since no one else here seems to share your concerns), I have >> no objection to such one line added. >> >> And again, to highlight the absurdity of your security claim, it is >> equally important to warn developers in earthquake-prone countries >> to put enough distance between the Approve and Deny buttons so that >> the user will not accidentally hit Approve during a tremor. >> >> EHL >> >> >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From jricher@mitre.org Thu Jan 5 07:55:19 2012 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 7901321F8800 for ; Thu, 5 Jan 2012 07:55:19 -0800 (PST) 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.001, 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 dTHehpYDC9SW for ; Thu, 5 Jan 2012 07:55:18 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 5404621F870C for ; Thu, 5 Jan 2012 07:55:18 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id B3B9621B0A71 for ; Thu, 5 Jan 2012 10:55:13 -0500 (EST) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 8675521B0A39 for ; Thu, 5 Jan 2012 10:55:13 -0500 (EST) Received: from [129.83.50.12] (129.83.31.51) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.1.339.1; Thu, 5 Jan 2012 10:55:13 -0500 Message-ID: <4F05C7B8.4070204@mitre.org> Date: Thu, 5 Jan 2012 10:54:32 -0500 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: References: <8AB6F5CC-E9A2-4A07-9AA0-83FB7C67A221@oracle.com> <4EEA3951.5010904@mtcc.com> <4EEB5BDD.7080401@mtcc.com> <4F038CB9.1040403@mtcc.com> <4F0394D6.1090006@mtcc.com> <4F04AAAE.6080702@mtcc.com> <4F04ACE4.1070006@stpeter.im> <4F04B101.3070708@mtcc.com> <4F04BF70.3010501@mtcc.com> <1325720576.43079.YahooMailNeo@web31816.mail.mud.yahoo.com> <4F04E79B.1030604@mtcc.com> In-Reply-To: <4F04E79B.1030604@mtcc.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Originating-IP: [129.83.31.51] Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011 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, 05 Jan 2012 15:55:19 -0000 I'm OK with the threat document including a line this this, or Eran's=20 proposed text, in the introduction to what OAuth can and can't do. It's=20 important to set scope appropriately. (and I am very sorry for that pun) However, the contention about native apps that Mike brings up is=20 misleading for one key reason: if the user's browser is compromised=20 (which is the attack vector in question), then all OAuth-backed webapps=20 will *also* be compromised, since the bad party can just grab the data=20 on its way to the screen. And if the user downloads malware masquerading = as a good app (which OAuth *can* protect against by using client secrets = in some circumstances and trusted callback urls in others), and they=20 approve the bad app, then they're hosed too. So, no, OAuth won't protect you against malware-infested browsers or=20 against phishing. It significantly reduces but does not eliminate=20 security threats, and (a point that hasn't been brought up) it=20 significantly eases the cleanup burden on users and service providers in = the case of a breach. If this really is a confusing point to people, we=20 can say that in the threat document, and Bill's text would do that,=20 without the addendum about native clients. I believe that the native=20 client text that speaks about embedded vs. external browsers is already=20 clear on this matter -- but if someone has better text (as in,=20 "paragraph X should say the following exact words", not "it needs to be=20 better"), then we can incorporate it. Even so, I do think it's clear from what text we already have. It would=20 be superfluous but not burdensome to add extra text into the threat=20 model document (not core) as has been proposed here by Bill and=20 previously be Eran. -- Justin On 01/04/2012 06:58 PM, Michael Thomas wrote: > On 01/04/2012 03:42 PM, William Mills wrote: >> I think the threat draft should simply say, "OAuth does not and can=20 >> not protect the user against credential compromise as a result of=20 >> phishing, malware, social engineering, or machine compromise." > > I could live with something like this, but I think it needs to be much = > more > explicit that it applies to any authentication service that allows=20 > native apps as clients > with no form of strong app vetting. It may even be useful to point to=20 > a couple of > large deployments who are at risk from this, like, oh say, twitterbook.= > > If this draft doesn't take a strong stand against that practice, it's=20 > doing nothing > more than giving a wink and a nod that what twitterbook is currently=20 > doing is safe. > That's bad, but I suspect it's the elephant in the room. > > Mike > >> >> Get rid of the fancy rhetoric, we don't need to explain a lot more=20 >> than this. >> >> I don't agree that OAuth purports to solve these problems. What it=20 >> solves is limiting the credentials granted to allow the user more=20 >> control and limited damage in the event of credential misuse. >> >> -bill >> >> ----------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= ------------------------------------------=20 >> > --=20 >> *From:* Michael Thomas >> *To:* Barry Leiba >> *Cc:* oauth WG >> *Sent:* Wednesday, January 4, 2012 1:06 PM >> *Subject:* Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, = >> ends 9 Dec 2011 >> >> On 01/04/2012 12:41 PM, Barry Leiba wrote: >> > up being a compromised browser or a native application that the user= >> > perhaps unwisely installed, all the security in the framework goes o= ut >> ^^^^^^^^^ >> > the window, because an untrustworthy UA can fiddle with pretty much >> > everything. >> > >> >> I think the "perhaps unwisely" goes to the heart of my objection. You >> might as well be talking about "perhaps unwisely" driving a car, >> or "perhaps unwisely" eating food: the reality is that people download= >> apps by the *billions*. When I was initially blown off, many of the >> participants including document editors implied that only idiots get >> apps for their phones. That is *completely* unhelpful as the reality >> is that OAUTH's use is hugely if not primarily deployed in that sort o= f >> environment. >> >> This is a threat that cuts to the very heart of what OAUTH is, and=20 >> purports >> to defend against: keeping user credentials out of the hands of an >> untrusted third party. If there really aren't any good ways to=20 >> mitigate this >> in an app environment, why is OAUTH being deployed so aggressively=20 >> there? >> Shouldn't the threat draft say in blinking bold: "DEPLOYING OAUTH >> IN NATIVE APPS CONSIDERED HARMFUL"? >> >> 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 mike@mtcc.com Thu Jan 5 08:21:53 2012 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 00EEA21F86CA for ; Thu, 5 Jan 2012 08:21:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OGPPVcyCDEWA for ; Thu, 5 Jan 2012 08:21:52 -0800 (PST) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 67AFD21F863C for ; Thu, 5 Jan 2012 08:21:50 -0800 (PST) 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 q05GLmI1026201 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 5 Jan 2012 08:21:48 -0800 Message-ID: <4F05CE1C.4060401@mtcc.com> Date: Thu, 05 Jan 2012 08:21:48 -0800 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: Justin Richer References: <8AB6F5CC-E9A2-4A07-9AA0-83FB7C67A221@oracle.com> <4EEA3951.5010904@mtcc.com> <4EEB5BDD.7080401@mtcc.com> <4F038CB9.1040403@mtcc.com> <4F0394D6.1090006@mtcc.com> <4F04AAAE.6080702@mtcc.com> <4F04ACE4.1070006@stpeter.im> <4F04B101.3070708@mtcc.com> <4F04BF70.3010501@mtcc.com> <1325720576.43079.YahooMailNeo@web31816.mail.mud.yahoo.com> <4F04E79B.1030604@mtcc.com> <4F05C7B8.4070204@mitre.org> In-Reply-To: <4F05C7B8.4070204@mitre.org> 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=1102; t=1325780510; x=1326644510; 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]=20WGLC=20on=20draft-ietf-oau th-v2-threatmodel-01,=20ends=209=0A=20Dec=202011 |Sender:=20 |To:=20Justin=20Richer=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=+cvQ3Ov3kKi2JY+rLgctr5sLndJzqtRzDgYEdMG38xk=; b=k1otN1+FjG5jcyrFF/pZWRo1wAqB3nqbZ3J52lEwQ920kNun58JKkjqjV4 ffDPI+mwIXj1gBDMy5GMw3fT6/fKUeNB93XohSjwzn+7mE3FUepncyvs+JWd /wAWCbTmvYX0ezyz7is/kWrqJTcuDCMNnfxC8BpZVb7eV0vP2c2H0=; 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] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011 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, 05 Jan 2012 16:21:53 -0000 On 01/05/2012 07:54 AM, Justin Richer wrote: > > However, the contention about native apps that Mike brings up is misleading for one key reason: if the user's browser is compromised (which is the attack vector in question), then all OAuth-backed webapps will *also* be compromised, since the bad party can just grab the data on its way to the screen. And if the user downloads malware masquerading as a good app (which OAuth *can* protect against by using client secrets in some circumstances and trusted callback urls in others), and they approve the bad app, then they're hosed too. There's a big difference between a compromised browser and a native app with an embedded browser. The first is considered harmful and browsers already take steps to insure they do not remain infected through updates, etc. The second is working as intended. | Even so, I do think it's clear from what text we already have. Remember: the reason that I am here at all is precisely because it was *not* clear. It's why I find the belligerence I've been afforded from the beginning so mystifying. Mike From wmills@yahoo-inc.com Thu Jan 5 08:29:08 2012 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 4E1C021F86BD for ; Thu, 5 Jan 2012 08:29:08 -0800 (PST) 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 wzi19uEmIhWO for ; Thu, 5 Jan 2012 08:29:07 -0800 (PST) Received: from nm15.bullet.mail.sp2.yahoo.com (nm15.bullet.mail.sp2.yahoo.com [98.139.91.85]) by ietfa.amsl.com (Postfix) with SMTP id 4BB8B21F8737 for ; Thu, 5 Jan 2012 08:29:06 -0800 (PST) Received: from [98.139.91.63] by nm15.bullet.mail.sp2.yahoo.com with NNFMP; 05 Jan 2012 16:29:03 -0000 Received: from [72.30.22.203] by tm3.bullet.mail.sp2.yahoo.com with NNFMP; 05 Jan 2012 16:29:03 -0000 Received: from [127.0.0.1] by omp1065.mail.sp2.yahoo.com with NNFMP; 05 Jan 2012 16:29:03 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 525599.17146.bm@omp1065.mail.sp2.yahoo.com Received: (qmail 81411 invoked by uid 60001); 5 Jan 2012 16:29:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1325780942; bh=K54ceFwYQuKBw6lr8ouvP1waYkvAjUwZEQrUfcag0PE=; 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=km5URfMoR0WBCe4geLJpSDbFDQmgf9myV13Kms+EoIYSfWPv1A7MprCNBN+ZoIoQV6aC75kjA4OZVSpZgWGexVXJZhloD0elUdmfY3PhFrWpiyfeZ2zzZnngVo1AGEbVrUKWXAKf9N6WO1SIYyQ1XHdddckQgzr5ARS6rpYdii4= 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=OHnKmOwfAbayM4JF8RGgWW5z32w3nFI6uMslMS4NKa1vrkoXJAGh9QHsSopVaDHj5J242TmykiR4W53bws5Z4xyqtfxqV5VKuqTZ1TY7nubAnaI8SgI1iX9IIzWTlCBvYeo0pLx4N9ZnWnKUeFitu7dABeNnnToMgkb8lo+n0+c=; X-YMail-OSG: h.Qn.5cVM1nuM88PAZQ6jJevFpWJfjKDFeV9viAfiYdnS2r KeIyTAPidLdgnGIzv6lYd8nYJkHyZeneQtL5r8Uwbw8CbAwrlH7EB0pfWoum DDH0VqnnvyFedwq9MC0gxG8y5qIEDsgrBq71QDN50sS8JBHvMrW55tq7O5vS hmtf15.tzhWUIg6uZFRFVZcK.XxyvU8ROfDkyf0Pq91RRAq1OFhwvlysOk.I iw8IL2TJwPHefIHasqSLDjVm2qNkVGE.8xvLUhccIrtJ9fHmAqWniYhNLCB5 aOZFupPzCMt8HwJsvC414fqfw6S1LXf.YQ80_4Ka6PjlKnXfBc1DxDN1eWSj _orIT3X5inU6FgxnS1dFGaVi.pwMtJg750YgYYVPJ0muOClZu0QCQyrfMkg0 2jGMbm4hwk_a8EjJtnA-- Received: from [99.31.212.42] by web31809.mail.mud.yahoo.com via HTTP; Thu, 05 Jan 2012 08:29:02 PST X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.116.331537 References: <8AB6F5CC-E9A2-4A07-9AA0-83FB7C67A221@oracle.com> <4EEA3951.5010904@mtcc.com> <4EEB5BDD.7080401@mtcc.com> <4F038CB9.1040403@mtcc.com> <4F0394D6.1090006@mtcc.com> <4F04AAAE.6080702@mtcc.com> <4F04ACE4.1070006@stpeter.im> <4F04B101.3070708@mtcc.com> <4F04BF70.3 <90C41DD21FB7C64BB94121FBBC2E723453A72D09B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> Message-ID: <1325780942.63316.YahooMailNeo@web31809.mail.mud.yahoo.com> Date: Thu, 5 Jan 2012 08:29:02 -0800 (PST) From: William Mills To: Mark Mcgloin , OAuth WG In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1395015409-1746656220-1325780942=:63316" Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011 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, 05 Jan 2012 16:29:08 -0000 ---1395015409-1746656220-1325780942=:63316 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable There's going to be a whole class of apps tat will be in violation of "Clie= nt applications SHOULD avoid directly asking users for the their =0Acredent= ials.".=A0 We know that already, because the password grant exists =0Aand w= e have real use cases for it.=A0 I think we should strikes that =0Asentence= and move that idea to #3 (soon to be #2)=0A=0A=0AI think point 2 should be= struck, it's pointless.=A0 What would matter here is whether the user can = check that the app has been validated, and =0Awe're not defining that.=0A= =0A=0AI would change #3 (now #2?) to:=0A=A0=A0 3. It is RECOMMENDED that cl= ient applications use the web based authentication =0A=A0=A0 flow, this tak= es advantage of a more trusted system component, e.g. the system =0A=A0=A0 = browser, and provides a consistent authentication experience for the user= =0A=A0=A0 across applications.=A0 The user is then always presenting their = credential to a=0A=A0=A0 known and trusted web page.=A0 Collection and use = of primary authentication from=0A=A0=A0 the user by client applications is = NOT RECOMMENDED.=0A=0ARegards,=0A=0A-bill=0A=0AP.S. hit the wrong key earli= er and replied only to Mark with this.=A0 Should have hit the list.=A0 Sorr= y Mark.=0A=0A=0A=0A________________________________=0A From: Mark Mcgloin <= mark.mcgloin@ie.ibm.com>=0ATo: OAuth WG =0ASent: Thursday,= January 5, 2012 6:01 AM=0ASubject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth= -v2-threatmodel-01, ends 9 Dec 2011=0A =0AHaving read the suggested wording= from Eran, William and Michael, I think=0AEran's description is the most s= uccinct and relevant: "OAuth does not=0Aprovide any protection against mali= cious applications and that the end user=0Ais solely responsible for the tr= ustworthiness of any native application=0Ainstalled"=0A@William: The threat= has been described in the context of installing=0Amalicious apps so the wo= rding above it more applicable=0A@Michael: It has been repeated many times = that we should only address=0Asecurity issues specific to Oauth, and Oauth = does not make things worse if=0Aa user installs a malicious client. If you = want to continue the discussion,=0Aplease email me directly and we can reve= rt to this forum if you still think=0Ayour point is relevant=0A=0ASection 4= .1.4 of the threat model will be updated as below. Remember the=0Athreat mo= del is just offering advice on best practices.=0A=0A=0AThreat: End-user cre= dentials phished using compromised or=A0 embedded browser=0A=0AA malicious = application could attempt to phish end-user passwords by=0Amisusing an embe= dded browser in the end-user authorization process, or by=0Apresenting its = own user-interface instead of allowing trusted system=0Abrowser to render t= he authorization user interface.=A0 By doing so, the usual=0Avisual trust m= echanisms may be bypassed (e.g.=A0 TLS confirmation, web site=0Amechanisms)= .=A0 By using an embedded or internal client application user=0Ainterface, = the client application has access to additional information it=0Ashould not= have access to (e.g. uid/password).=0A=0AImpact: If the client application= or the communication is compromised, the=0Auser would not be aware and all= information in the authorization exchange=0Acould be captured such as user= name and password.=0A=0ACountermeasures:=0A=0A1. The OAuth flow is designed= so that client applications never need to=0Aknow user passwords. Client ap= plications SHOULD avoid directly asking users=0Afor the their credentials. = In addition, end users could be educated about=0Aphishing attacks and best = practices, such as only accessing trusted=0Aclients, as OAuth does not prov= ide any protection against malicious=0Aapplications and the end user is sol= ely responsible for the trustworthiness=0Aof any native application install= ed=0A=0A2. Client applications could be validated prior to publication in a= n=0Aapplication market for users to access. That validation is out of scope= for=0AOAuth but could include validating that the client application handl= es user=0Aauthentication in an appropriate way=0A=0A3. Client developers sh= ould not write client applications that collect=0Aauthentication informatio= n directly from users and should instead delegate=0Athis task to a trusted = system component, e.g. the system-browser.=0A=0ARegards=0AMark=0A=0Aoauth-b= ounces@ietf.org wrote on 05/01/2012 00:05:04:=0A=0A> From:=0A>=0A> Eran Ham= mer-Lahav =0A>=0A> To:=0A>=0A> Michael Thomas , Torsten Lodderstedt=0A=0A>=0A> Cc:=0A>=0A= > Barry Leiba , oauth WG =0A>=0A> = Date:=0A>=0A> 05/01/2012 00:05=0A>=0A> Subject:=0A>=0A> Re: [OAUTH-WG] WGLC= on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec=0A2011=0A>=0A> Sent by:= =0A>=0A> oauth-bounces@ietf.org=0A>=0A>=0A>=0A> > -----Original Message----= -=0A> > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Beh= alf=0A> > Of Michael Thomas=0A> > Sent: Wednesday, January 04, 2012 3:40 PM= =0A>=0A> > My concern is that putting on a veneer of "security" will lull p= eople=0Ainto=0A> > thinking "Oh, it's safe to enter my credentials here bec= ause this is=0Areally=0A> > twitterbook, not evilapp!". When I had to ask t= hem directly to put=0Atheir=0A> > twitterbook credentials into my app, ther= e at least wasn't any=0A> confusion that=0A> > I had access to them.=0A>=0A= > This is ridiculous (e.g. the fact we are still discussing this).=0A>=0A> = First, end users know nothing about security or OAuth. Second, evil=0A> app= s can create this veneer of security by faking a redirection flow=0A> with = or without OAuth. Suggesting that OAuth (which is a de-facto=0A> web patter= n for over a decade) makes anything worse is patently false.=0A>=0A> The on= ly thing we can possibly add to the threat model document is=0A> to mention= that "OAuth does not provide any protection against=0A> malicious applicat= ions and that the end user is solely responsible=0A> for the trustworthines= s of any native application installed". That=0A> is accurate (and completel= y obvious to the target audience of this=0A> document). It is not very help= ful but if it will make you feel=0A> better (since no one else here seems t= o share your concerns), I have=0A> no objection to such one line added.=0A>= =0A> And again, to highlight the absurdity of your security claim, it is=0A= > equally important to warn developers in earthquake-prone countries=0A> to= put enough distance between the Approve and Deny buttons so that=0A> the u= ser will not accidentally hit Approve during a tremor.=0A>=0A> EHL=0A>=0A>= =0A>=0A>=0A>=0A> _______________________________________________=0A> OAuth = mailing list=0A> OAuth@ietf.org=0A> https://www.ietf.org/mailman/listinfo/o= auth=0A>=0A=0A_______________________________________________=0AOAuth maili= ng list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/oauth ---1395015409-1746656220-1325780942=:63316 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
There's going to be a whole class of apps tat will be in violation of "Client=0A applications SHOULD avoid directly asking users for the thei= r =0Acredentials.".  We know that already, because the password grant = exists =0Aand we have real use cases for it.  I think we should strike= s that =0Asentence and move that idea to #3 (soon to be #2)
<= br>
I=0A think point 2 should be struck, it's pointless.  Wh= at would matter here=0A is whether the user can check that the app has been= validated, and =0Awe're not defining that.

I = would change #3 (now #2?) to:

   3. It is REC= OMMENDED that client applications use the web based authentication
&nbs= p;  flow, this takes advantage of a more trusted system component, e.g= . the system=0A
   browser, and provides a consistent authent= ication experience for the user
   across applications.  = The user is then always presenting their credential to a
   kn= own and trusted web page.  Collection and use of primary authenticatio= n from
   the user by client applications is NOT RECOMMENDED.<= br>
Regards,

-bill

P.S. hit the wrong key earlier and repl= ied only to Mark with this.  Should have hit the list.  Sorry Mar= k.

From= : Mark Mcgloin <mark.mcgloin@ie.ibm.com>
To: OAuth WG <oauth@ietf.org> Sent: Thursday, January 5, 2012 6:= 01 AM
Subject: Re: [OA= UTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011

=0AHaving read the suggested wording from Eran, William and Michae= l, I think
Eran's description is the most succinct and relevant: "OAuth = does not
provide any protection against malicious applications and that = the end user
is solely responsible for the trustworthiness of any native= application
installed"
@William: The threat has been described in th= e context of installing
malicious apps so the wording above it more appl= icable
@Michael: It has been repeated many times that we should only add= ress
security issues specific to Oauth, and Oauth does not make things w= orse if
a user installs a malicious client. If you want to continue the = discussion,
please email me directly and we can revert to this forum if = you still think
your point is relevant

Section 4.1.4 of the threa= t model will be updated as below. Remember the
threat model is just offe= ring advice on best practices.


Threat: End-user credentials phis= hed using compromised or  embedded browser

A malicious application= could attempt to phish end-user passwords by
misusing an embedded brows= er in the end-user authorization process, or by
presenting its own user-= interface instead of allowing trusted system
browser to render the autho= rization user interface.  By doing so, the usual
visual trust mecha= nisms may be bypassed (e.g.  TLS confirmation, web site
mechanisms)= .  By using an embedded or internal client application user
interfa= ce, the client application has access to additional information it
shoul= d not have access to (e.g. uid/password).

Impact: If the client appl= ication or the communication is compromised, the
user would not be aware= and all information in the authorization exchange
could be captured suc= h as username and password.

Countermeasures:

1. The OAuth flo= w is designed so that client applications never need to
know user passwords. Client applications SHOULD avoid directly asking users
for t= he their credentials. In addition, end users could be educated about
phi= shing attacks and best practices, such as only accessing trusted
clients= , as OAuth does not provide any protection against malicious
application= s and the end user is solely responsible for the trustworthiness
of any = native application installed

2. Client applications could be validat= ed prior to publication in an
application market for users to access. Th= at validation is out of scope for
OAuth but could include validating tha= t the client application handles user
authentication in an appropriate w= ay

3. Client developers should not write client applications that co= llect
authentication information directly from users and should instead = delegate
this task to a trusted system component, e.g. the system-browse= r.

Regards
Mark

oauth-bounces@ietf.org wrote on 05/01/2012 00:05:04:

>= From:
>
> Eran Hammer-Lahav <eran@hueniverse.com>=
>
> To:
>
> Michael Thomas <mike@mtcc.com>, Torst= en Lodderstedt
<torsten@lodderstedt.net>
>> Cc:
>
> Barry Leiba <barryleiba@computer.or= g>, oauth WG <oauth@ietf.org>
>
> Date:
>
&g= t; 05/01/2012 00:05
>
> Subject:
>
> Re: [OAUTH-WG]= WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec
2011
>
> Sen= t by:
>
> oauth-bounces@ietf.org
>
>>
> > -----Original Message-----
> > From: = oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf
> > Of Michael Thomas
> > Sent: Wednesday, January= 04, 2012 3:40 PM
>
> > My concern is that putting on a vene= er of "security" will lull people
into
> > thinking "Oh, it's s= afe to enter my credentials here because this is
really
> > twi= tterbook, not evilapp!". When I had to ask them directly to put
their> > twitterbook credentials into my app, there at least wasn't any
> confusion that
> > I had access to them.
>
&= gt; This is ridiculous (e.g. the fact we are still discussing this).
>= ;
> First, end users know nothing about security or OAuth. Second, ev= il
> apps can create this veneer of security by faking a redirection = flow
> with or without OAuth. Suggesting that OAuth (which is a de-fa= cto
> web pattern for over a decade) makes anything worse is patently= false.
>
> The only thing we can possibly add to the threat mo= del document is
> to mention that "OAuth does not provide any protect= ion against
> malicious applications and that the end user is solely = responsible
> for the trustworthiness of any native application insta= lled". That
> is accurate (and completely obvious to the target audie= nce of this
> document). It is not very helpful but if it will make y= ou feel
> better (since no one else here seems to share your concerns), I have
> no objection to such one line added.
>
= > And again, to highlight the absurdity of your security claim, it is> equally important to warn developers in earthquake-prone countries> to put enough distance between the Approve and Deny buttons so that> the user will not accidentally hit Approve during a tremor.
><= br>> EHL
>
>
>
>
>
> _______________= ________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth
>

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

<= br>
---1395015409-1746656220-1325780942=:63316-- From wmills@yahoo-inc.com Thu Jan 5 08:37:58 2012 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 F154621F8775 for ; Thu, 5 Jan 2012 08:37:57 -0800 (PST) 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 UT8HgUyRzOY9 for ; Thu, 5 Jan 2012 08:37:56 -0800 (PST) Received: from nm8-vm0.bullet.mail.bf1.yahoo.com (nm8-vm0.bullet.mail.bf1.yahoo.com [98.139.213.95]) by ietfa.amsl.com (Postfix) with SMTP id A40B321F86E5 for ; Thu, 5 Jan 2012 08:37:43 -0800 (PST) Received: from [98.139.212.150] by nm8.bullet.mail.bf1.yahoo.com with NNFMP; 05 Jan 2012 16:37:40 -0000 Received: from [98.139.212.214] by tm7.bullet.mail.bf1.yahoo.com with NNFMP; 05 Jan 2012 16:37:40 -0000 Received: from [127.0.0.1] by omp1023.mail.bf1.yahoo.com with NNFMP; 05 Jan 2012 16:37:40 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 730874.59001.bm@omp1023.mail.bf1.yahoo.com Received: (qmail 38365 invoked by uid 60001); 5 Jan 2012 16:37:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1325781460; bh=PT2UBUFgqHm2HZDBqCf5SU+oJL1Lu2WuogaFf4NCXfA=; 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=XPU9E5egsF4PB77mlluEi/S1678eP5v3PlcXcBApexAF5agl3vySp4G2xSRd96bP7TU+na3yynSigurwsEALgVexiaB5QBkMws9BCeNDxB5Iazt4inpjndUamn1m8L5kYY8eOfXQLTBror1BUxrk+k+qcNE2AomOHVau/Twv4hE= 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=AATRb3B54uSrutMH6gVtjnkoRa4PtAnqsagSy8GvDBrk1wdbf/TC4R/7gYZZc8yUywg4FGzaXpVUo1+nkZftCrlx3NiK2VhxAU2Q3qz5g5AKLLE5XpXZidQHytJJy0d4pMb2UZMZbwsF71MFSaRA3eKDzkvWWozwp5TLldbhwdA=; X-YMail-OSG: BLv4Y.wVM1nCZm4mKqLdfOHhw8O35FDWK41tbEExi.fogVV nFEn33sDwhjesudmVVrgAlT.L5rxqAYuCptkUlRDOhy2kjB0vs8JbyxOx5Wx kl1jtQS72PZf4oLyJS2ROrvzEJsWrjHImGQyZ5.9nNgxLaKPx9ZxhNmA2Pn9 q2fJfvspSrYR8Bfgw7JxzVwKZYVhlFr3AZbEnkq4BLjjFBAGSwXyqxHTVLIB p2VsfvM2yegtOW6ygq0zKNO7BYma2nM5gKkxZZ53fPjzAa1omvsy.4wCA6qc eEm0pRDWCwxa5esJdIYretEwDcgLVBqoPxJoOA3kkGZYAEB5QWYUkxB2mPCk ycEsN.njB0JdAnEc6t5ZV5UBAFvjurB6zs4O3MhMRVj8dS3xA2.5IAo1vI7z HcMxdJTia.icqOKLOF0CS Received: from [99.31.212.42] by web31803.mail.mud.yahoo.com via HTTP; Thu, 05 Jan 2012 08:37:39 PST X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.116.331537 References: <8AB6F5CC-E9A2-4A07-9AA0-83FB7C67A221@oracle.com> <4EEA3951.5010904@mtcc.com> <4EEB5BDD.7080401@mtcc.com> <4F038CB9.1040403@mtcc.com> <4F0394D6.1090006@mtcc.com> <4F04AAAE.6080702@mtcc.com> <4F04ACE4.1070006@stpeter.im> <4F04B101.3070708@mtcc.com> <4F04BF70.3 <1325721020.62165.YahooMailNeo@web31812.mail.mud.yahoo.com> Message-ID: <1325781459.27034.YahooMailNeo@web31803.mail.mud.yahoo.com> Date: Thu, 5 Jan 2012 08:37:39 -0800 (PST) From: William Mills To: Mark Mcgloin In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1502656925-1179057022-1325781459=:27034" Cc: "oauth-bounces@ietf.org" , Barry Leiba , oauth WG Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011 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, 05 Jan 2012 16:37:58 -0000 --1502656925-1179057022-1325781459=:27034 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable It relies on the marketplace to do this.=A0 The current model is that apps = are not validated first, they are pulled if found to be hostile.=A0=A0 You'= re making a recommendation here about how an app marketplace should behave = to be trustworthy, and I think that's beyond the scope of users and client = developers here.=A0 We're already saying users should only install trustwor= thy applications.=0A=0A=0A=0A________________________________=0A From: Mark= Mcgloin =0ATo: William Mills =0ACc: Barry Leiba ; Michael Thomas ; oauth WG ; oauth-bounces@ietf.org; Torsten Loddersted= t =0ASent: Thursday, January 5, 2012 6:03 AM=0ASu= bject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 De= c 2011=0A =0AWhy do you think this William? Apple does it? Google android m= arket had to=0Apull 30 apps recently because they contained malware. There = are automated=0Atools that will do some sanity checks on apps and it is onl= y advice, i.e.=0A'could'=0A=0AMark=0A=0A> William Mills =0A>=0A>=A0 "=A0 o=A0 Client applications could be validated prior publ= ication in a=0A>=A0 =A0 =A0 application market."=0A>=0A> Should just be st= ruck.=A0 Michael is correct that it's fluff, and=0A> unenforceable.=A0 Ther= e are too many app marketplaces, opensource=0A> projects, etc. to make this= a useful suggestion.=0A>=0A> From: Michael Thomas =0A> To: = Torsten Lodderstedt =0A> Cc: Barry Leiba ; oauth WG =0A> Sent: Wednesday, January 4,= 2012 3:40 PM=0A> Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threa= tmodel-01,=0A> ends 9 Dec 2011=0A>=0A> On 01/04/2012 02:14 PM, Torsten Lodd= erstedt wrote:=0A> > Hi Michael,=0A> >=0A> > Am 04.01.2012 22:06, schrieb M= ichael Thomas:=0A> >> I think the "perhaps unwisely" goes to the heart of m= y objection. You=0A> >> might as well be talking about "perhaps unwisely" d= riving a car,=0A> >> or "perhaps unwisely" eating food: the reality is that= people download=0A> >> apps by the *billions*.=A0 When I was initially blo= wn off, many of the=0A> >> participants including document editors implied = that only idiots get=0A> >> apps for their phones. That is *completely* unh= elpful as the reality=0A> >> is that OAUTH's use is hugely if not primarily= deployed in that sort=0Aof=0A> >> environment.=0A> >=0A> > I fully agree w= ith you. That's why the core spec and the threat=0A> document both consider= native apps.=0A> >=0A> >>=0A> >> This is a threat that cuts to the very he= art of what OAUTH is, and=0Apurports=0A> >> to defend against: keeping user= credentials out of the hands of an=0A> >> untrusted third party. If there = really aren't any good ways to=0A> mitigate this=0A> >> in an app environme= nt, why is OAUTH being deployed so aggressively=0Athere?=0A> >> Shouldn't t= he threat draft say in blinking bold: "DEPLOYING OAUTH=0A> >> IN NATIVE APP= S CONSIDERED HARMFUL"?=0A> >=0A> > You lost me. Is the situation getting an= y worse with OAuth? I=0A> don't think so. I think the situation is getting = better, probably=0A> not as you might expect.=0A>=0A> My concern is that pu= tting on a veneer of "security" will lull people=0Ainto=0A> thinking "Oh, i= t's safe to enter my credentials here because this is=0Areally=0A> twitterb= ook, not evilapp!". When I had to ask them directly to put their=0A> twitte= rbook credentials into my app, there at least wasn't any confusion=0A> that= I had access to them.=0A>=0A> Realistically, what you've done is protected= the credentials from the=0Agood=0A> guys and not changed much for a motiva= ted bad guy. Is that an=0Aimprovement?=0A> I'll buy that it's generally bad= practice for good guys with most likely=0Abad=0A> security chops to=A0 be = storing credentials, but I'm guessing that the=0Aoriginal=0A> OAUTH motivat= ion was more toward thwarting bad guys.=0A>=0A> >=0A> > The key question is= : Why do we aim on "keeping user credentials=0A> out of the hands of an unt= rusted third party"?=0A> >=0A> > 1) To prevent phishing or 2) to prevent le= akage of end-user=0A> credentials due to inappropriate handling or weak def= ence on the 3rd=0Aparty?=0A> >=0A> > wrt 1) I don't think so. I don't see h= ow an authorization server=0A> shall validate the authenticity and trustwor= thiness of a client-side=0A> application. We already state this in section = 4.4.1.4. of the=0Athreatdocument.=0A>=0A> The draft says:=0A>=0A>=A0 o=A0 = Client applications could be validated prior publication in a=0A>=A0 =A0 = =A0 application market.=0A>=0A> I asked -- and didn't get a response -- ab= out how exactly that might=0A> be done. I suspect=0A> that in practice for = the twitterbook universe that there is no way=0A> that scales. So the=0A> r= eality here seems to be there isn't an answer for the Internet at=0A> large= , and the threats=0A> document should just say that mitigation MAY be possi= ble in very=0A> narrow use cases where=0A> code reviews, and other heavy ha= nded analysis can be performed, but=0A> for the general case=0A> there is n= o mitigation.=0A>=0A> As far as 4.4.1.4 goes, I'd say that the counter meas= ures really=0A> don't help except=0A> maybe for auditing. If that's what th= ey're really about, the draft=0A> should make that=0A> explicit.=0A>=0A> Al= so on the subject of 4.4.1.4, this bullet:=0A>=0A>=0A> o=A0 If the authoriz= ation server automatically authenticates the end-=0A>=A0 =A0 =A0 user, it = may nevertheless require some user input in order to=0A>=A0 =A0 =A0 preven= t screen scraping.=A0 Examples are CAPTCHAs or user-specific=0A>=A0 =A0 =A0= secret like PIN codes.=0A>=0A>=0A> I'm very skeptical because a native en= vironment is a social=0A> engineering nirvana.=0A> The CAPTCHA could easily= be shown to the user and they'd blissfully=0A> solve it just=0A> like they= do any other one.=0A>=0A>=0A>=0A>=0A> >=0A> > -----------------------=0A> = > It is not the task of the authorization server to protect=0A> >=A0 =A0 th= e end-user's device from malicious software.=A0 This is the=0A> >=A0 =A0 re= sponsibility of the platform running on the particular device=0A> >=A0 =A0 = probably in cooperation with other components of the respective=0A> >=A0 = =A0 ecosystem (e.g. an application management infrastructure).=A0 The sole= =0A> >=A0 =A0 responsibility of the authorization server is to control acce= ss to=0A> >=A0 =A0 the end-user's resources living in resource servers and = to prevent=0A> >=A0 =A0 unauthorized access to them.=0A> > ----------------= -------=0A>=0A> I assume that it's in the authorization server's _interest_= to not=0Adivulge=0A> user credentials to potentially evil third parties. I= f it's not, whywould=0Ayou=0A> go to the trouble of implementing OAUTH at a= ll?=0A>=0A> This is what's so troubling to me. The point is to keep user cr= edentials=0Aaway=0A> from bad guys, but when shown how OAUTH in widely depl= oyed scenarios=0Afails=0A> to do that, the response I get from the working = group is "Not Our=0AProblem".=0A> Well it *is* your problem insofar as you = are not advising the=0Atwitterbooks to=0A> disallow native apps as clients,= for example.=0A>=0A> >=0A> > wrt 2) Yes, I think that's the reason. And OA= uth is a appropriate=0A> protocol to achieve this goal, even for mobile app= s. Why?=0A> >=0A> > A typical mobile application consists of the app itself= on the=0A> device and a corresponding backend service storing user data an= d=0A> implementing business and integration logic. Let's assume this=0A> ap= plication features address book import from other service=0A> providers. W/= o OAuth, the app would gather the end-user's credential=0A> for a certain a= ddress book service and pass it to its backend=0A> service. This service in= turn uses this credentials to access the=0A> service provider's API. So in= such a scenario the following parties=0A> get in touch with the user crede= ntials:=0A> > - the app=0A> > - the app's backend service=0A> > - the addre= ss book resource server=0A>=0A> With native mobile apps, the client (=3D ap= p & app backend) isn't it plenty=0A> enough to be seriously scary if they c= an screen scrape the credentials=0A> with impunity? What problem was solved= again?=0A>=0A> >=0A> > What threats do you see here? And which is most lik= ely to occur?=0A> My favorite is an attack against the log files or the dat= abase of=0A> the backend service in order to obtain the end-users passwords= for=0A> the resource server. Why? Because the cost/benefit ratio for an=0A= > attacker is much better then attacking any app installation on a=0A> devi= ce and the protective measure on the resource server might be=0A> more appr= opriate then on the client side (backend service).=0A>=0A> Botnets prove th= at either is a successful business model. This isn't a=0Azero=0A> sum game,= after all.=0A>=0A> > OAuth mitigates this kind of attack by reducing the n= umber of=0A> parties handling user credentials to the authorization server = and=0A> the user agent. So even if the app itself would be the user agent= =0A> (which is not recommended),=0A>=0A> Not recommended? It's messed up ev= en thinking of it that way. The=0A> app is potentially=0A> *evil*. It reall= y doesn't care what the IETF RECOMMENDS. If it's=0A> useful for it to be th= e=0A> UA, it's going to do just exactly that.=0A>=0A> > it would directly i= nteract with the authorization server and the=0A> app's backend service wou= ld use tokens instead of end-user credentials.=0A>=0A> The problem here is = the capture of end user credentials. I believe that=0AOAUTH=0A> defends pre= tty well in the trusted desktop browser scenario it set=0A> out to solve=0A= > for. I do not believe that it does that in the new reality of native=0A> = apps, and embedded=0A> webviews.=0A>=0A> | Moreover, the recommended way is= to let the app delegate the flow=0A> to a trusted system=0A> | component o= n the user's device, such as the system browser or an=0A> account manager. = In that=0A> | case, the 3rd party is not getting in touch with the user=0A>= credentials at all.=0A>=0A> Again, the Bad Guys are specifically and compl= etely uninterested in=0A> being good and=0A> sending it to a trusted compon= ent. They will disregard this RECOMMEND=0Afaster=0A> than you can type it.= =0A> >=0A> > I think the key question is whether anyone expects OAuth to so= lve=0A> the phishing problem. I don't think this is its main purpose, but i= t=0A> could facilitate to overcome the habit to enter user credentials=0A> = everywhere. And this in turn may contribute to the fight against=0Aphishing= .=0A>=0A> There's much more to this than just phishing.=0A>=0A> Mike=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> OAuth@= ietf.org=0A> https://www.ietf.org/mailman/listinfo/oauth --1502656925-1179057022-1325781459=:27034 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
It relies on the marketplace to do this.  The current model is that = apps are not validated first, they are pulled if found to be hostile. =   You're making a recommendation here about how an app marketplace sho= uld behave to be trustworthy, and I think that's beyond the scope of users = and client developers here.  We're already saying users should only in= stall trustworthy applications.

= From: Mark Mcgloin <mar= k.mcgloin@ie.ibm.com>
To: William Mills <wmills@yahoo-inc.com>
Cc: Barry Leiba <barryleiba@computer.org>; Mich= ael Thomas <mike@mtcc.com>; oauth WG <oauth@ietf.org>; oauth-bo= unces@ietf.org; Torsten Lodderstedt <torsten@lodderstedt.net>
Sent: Thursday, January 5, 2= 012 6:03 AM
Subject: R= e: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011
=0AWhy do you think this William? Apple does it? Google andr= oid market had to
pull 30 apps recently because they contained malware. = There are automated
tools that will do some sanity checks on apps and it= is only advice, i.e.
'could'

Mark

> William Mills <= wmills@yahoo-inc.com>
>
>  "  o  Cl= ient applications could be validated prior publication in a
>  &= nbsp;   application market."
>
> Should just be struck.&n= bsp; Michael is correct that it's fluff, and
> unenforceable.  T= here are too many app marketplaces, opensource
> projects, etc. to ma= ke this a useful suggestion.
>
> From: Michael Thomas <mike@mtcc.com<= /a>>
> To: Torsten Lodderstedt <torsten@lodderstedt.net>> Cc: Barry Leiba <barryleiba@computer.org>; oauth= WG <oauth@ietf.org>
> Sent: Wednesday, January 4, 2012 3:40 PM> Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01,> ends 9 Dec 2011
>
> On 01/04/2012 02:14 PM, Torsten Lodd= erstedt wrote:
> > Hi Michael,
> >
> > Am 04.01.= 2012 22:06, schrieb Michael Thomas:
> >> I think the "perhaps u= nwisely" goes to the heart of my objection. You
> >> might as w= ell be talking about "perhaps unwisely" driving a car,
> >> or = "perhaps unwisely" eating food: the reality is that people download
>= >> apps by the *billions*.  When I was initially blown off, man= y of the
> >> participants including document editors implied th= at only idiots get
> >> apps for their phones. That is *complet= ely* unhelpful as the reality
> >> is that OAUTH's use is hugel= y if not primarily deployed in that sort
of
> >> environment= .
> >
> > I fully agree with you. That's why the core spe= c and the threat
> document both consider native apps.
> >> >>
> >> This is a threat that cuts to the very hea= rt of what OAUTH is, and
purports
> >> to defend against: ke= eping user credentials out of the hands of an
> >> untrusted th= ird party. If there really aren't any good ways to
> mitigate this> >> in an app environment, why is OAUTH being deployed so aggres= sively
there?
> >> Shouldn't the threat draft say in blinkin= g bold: "DEPLOYING OAUTH
> >> IN NATIVE APPS CONSIDERED HARMFUL"?
> >
> > You lost me. Is the situation getting = any worse with OAuth? I
> don't think so. I think the situation is ge= tting better, probably
> not as you might expect.
>
> My = concern is that putting on a veneer of "security" will lull people
into<= br>> thinking "Oh, it's safe to enter my credentials here because this i= s
really
> twitterbook, not evilapp!". When I had to ask them dire= ctly to put their
> twitterbook credentials into my app, there at lea= st wasn't any confusion
> that I had access to them.
>
> = Realistically, what you've done is protected the credentials from the
go= od
> guys and not changed much for a motivated bad guy. Is that animprovement?
> I'll buy that it's generally bad practice for good gu= ys with most likely
bad
> security chops to  be storing crede= ntials, but I'm guessing that the
original
> OAUTH motivation was more toward thwarting bad guys.
>
> >
>= ; > The key question is: Why do we aim on "keeping user credentials
&= gt; out of the hands of an untrusted third party"?
> >
> >= ; 1) To prevent phishing or 2) to prevent leakage of end-user
> crede= ntials due to inappropriate handling or weak defence on the 3rd
party?> >
> > wrt 1) I don't think so. I don't see how an author= ization server
> shall validate the authenticity and trustworthiness = of a client-side
> application. We already state this in section 4.4.= 1.4. of the
threatdocument.
>
> The draft says:
>
&= gt;  o  Client applications could be validated prior publication= in a
>      application market.
>
> I as= ked -- and didn't get a response -- about how exactly that might
> be= done. I suspect
> that in practice for the twitterbook universe that there is no way
> that scales. So the
> reality = here seems to be there isn't an answer for the Internet at
> large, a= nd the threats
> document should just say that mitigation MAY be poss= ible in very
> narrow use cases where
> code reviews, and other= heavy handed analysis can be performed, but
> for the general case> there is no mitigation.
>
> As far as 4.4.1.4 goes, I'd = say that the counter measures really
> don't help except
> mayb= e for auditing. If that's what they're really about, the draft
> shou= ld make that
> explicit.
>
> Also on the subject of 4.4.1= .4, this bullet:
>
>
> o  If the authorization serve= r automatically authenticates the end-
>      user, i= t may nevertheless require some user input in order to
>   =   prevent screen scraping.  Examples are CAPTCHAs or user-specific
>      secret like PIN codes.
><= br>>
> I'm very skeptical because a native environment is a social=
> engineering nirvana.
> The CAPTCHA could easily be shown to = the user and they'd blissfully
> solve it just
> like they do a= ny other one.
>
>
>
>
> >
> > ---= --------------------
> > It is not the task of the authorization s= erver to protect
> >    the end-user's device from malic= ious software.  This is the
> >    responsibility o= f the platform running on the particular device
> >    p= robably in cooperation with other components of the respective
> >=     ecosystem (e.g. an application management infrastructure).&nb= sp; The sole
> >    responsibility of the authorization = server is to control access to
> >    the end-user's resources living in resource servers and to prevent
> >= ;    unauthorized access to them.
> > ------------------= -----
>
> I assume that it's in the authorization server's _int= erest_ to not
divulge
> user credentials to potentially evil third= parties. If it's not, whywould
you
> go to the trouble of impleme= nting OAUTH at all?
>
> This is what's so troubling to me. The = point is to keep user credentials
away
> from bad guys, but when s= hown how OAUTH in widely deployed scenarios
fails
> to do that, th= e response I get from the working group is "Not Our
Problem".
> We= ll it *is* your problem insofar as you are not advising the
twitterbooks= to
> disallow native apps as clients, for example.
>
> &= gt;
> > wrt 2) Yes, I think that's the reason. And OAuth is a appr= opriate
> protocol to achieve this goal, even for mobile apps. Why?
> >
> > A typical mobile application consists of th= e app itself on the
> device and a corresponding backend service stor= ing user data and
> implementing business and integration logic. Let'= s assume this
> application features address book import from other s= ervice
> providers. W/o OAuth, the app would gather the end-user's cr= edential
> for a certain address book service and pass it to its back= end
> service. This service in turn uses this credentials to access t= he
> service provider's API. So in such a scenario the following part= ies
> get in touch with the user credentials:
> > - the app<= br>> > - the app's backend service
> > - the address book re= source server
>
> With native mobile apps, the client (=3D app = & app backend) isn't it plenty
> enough to be seriously scary if = they can screen scrape the credentials
> with impunity? What problem was solved again?
>
> >
> > What threats d= o you see here? And which is most likely to occur?
> My favorite is a= n attack against the log files or the database of
> the backend servi= ce in order to obtain the end-users passwords for
> the resource serv= er. Why? Because the cost/benefit ratio for an
> attacker is much bet= ter then attacking any app installation on a
> device and the protect= ive measure on the resource server might be
> more appropriate then o= n the client side (backend service).
>
> Botnets prove that eit= her is a successful business model. This isn't a
zero
> sum game, = after all.
>
> > OAuth mitigates this kind of attack by redu= cing the number of
> parties handling user credentials to the authori= zation server and
> the user agent. So even if the app itself would b= e the user agent
> (which is not recommended),
>
> Not recommended? It's messed up even thinking of it that way. The
> = app is potentially
> *evil*. It really doesn't care what the IETF REC= OMMENDS. If it's
> useful for it to be the
> UA, it's going to = do just exactly that.
>
> > it would directly interact with = the authorization server and the
> app's backend service would use to= kens instead of end-user credentials.
>
> The problem here is t= he capture of end user credentials. I believe that
OAUTH
> defends= pretty well in the trusted desktop browser scenario it set
> out to = solve
> for. I do not believe that it does that in the new reality of= native
> apps, and embedded
> webviews.
>
> | More= over, the recommended way is to let the app delegate the flow
> to a = trusted system
> | component on the user's device, such as the system= browser or an
> account manager. In that
> | case, the 3rd party is not getting in touch with the user
> credentials at all= .
>
> Again, the Bad Guys are specifically and completely unint= erested in
> being good and
> sending it to a trusted component= . They will disregard this RECOMMEND
faster
> than you can type it= .
> >
> > I think the key question is whether anyone expe= cts OAuth to solve
> the phishing problem. I don't think this is its = main purpose, but it
> could facilitate to overcome the habit to ente= r user credentials
> everywhere. And this in turn may contribute to t= he fight against
phishing.
>
> There's much more to this tha= n just phishing.
>
> Mike
> _____________________________= __________________
> OAuth mailing list
> OAuth@ietf.org
> <= a href=3D"https://www.ietf.org/mailman/listinfo/oauth" target=3D"_blank">https://www.ietf.org/mailman/listinfo/oauth
><= br>> _______________________________________________
> OAuth maili= ng list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oa= uth



--1502656925-1179057022-1325781459=:27034-- From mike@mtcc.com Thu Jan 5 08:48:15 2012 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 2E35C21F86D1; Thu, 5 Jan 2012 08:48:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] 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 ZYZeRiNEGbpQ; Thu, 5 Jan 2012 08:48:14 -0800 (PST) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 1285621F87E7; Thu, 5 Jan 2012 08:48:14 -0800 (PST) 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 q05Gm72X002801 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 5 Jan 2012 08:48:07 -0800 Message-ID: <4F05D447.9070902@mtcc.com> Date: Thu, 05 Jan 2012 08:48:07 -0800 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: <8AB6F5CC-E9A2-4A07-9AA0-83FB7C67A221@oracle.com> <4EEA3951.5010904@mtcc.com> <4EEB5BDD.7080401@mtcc.com> <4F038CB9.1040403@mtcc.com> <4F0394D6.1090006@mtcc.com> <4F04AAAE.6080702@mtcc.com> <4F04ACE4.1070006@stpeter.im> <4F04B101.3070708@mtcc.com> <4F04BF70.3 <1325721020.62165.YahooMailNeo@web31812.mail.mud.yahoo.com> <1325781459.27034.YahooMailNeo@web31803.mail.mud.yahoo.com> In-Reply-To: <1325781459.27034.YahooMailNeo@web31803.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=12899; t=1325782088; x=1326646088; 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]=20WGLC=20on=20draft-ietf-oau th-v2-threatmodel-01,=20ends=209=0A=20Dec=202011 |Sender:=20 |To:=20William=20Mills=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=h654B6V8I1ksKCFBVfR4oZgUb5NSiwAZDaDsNhBRP7Y=; b=jw+NaCjmFG8+XgjY25dddMVhsga5XYilq/odamhfCfQDrgZvNoOfOA9MF8 TKS2F9vXZUOw5PxspxHJYCj26ikm/rion+JaugExxgR/qG0qEzWMKg+qgyHt fdod+Lg0Fl/7+2IM7afpMQ4HVutbKyQa3UPuyx+ZcjYf5n0x5BIU0=; 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: Barry Leiba , oauth WG , "oauth-bounces@ietf.org" Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011 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, 05 Jan 2012 16:48:15 -0000 On 01/05/2012 08:37 AM, William Mills wrote: > It relies on the marketplace to do this. The current model is that app= s are not validated first, they are pulled if found to be hostile. You'= re making a recommendation here about how an app marketplace should behav= e to be trustworthy, and I think that's beyond the scope of users and cli= ent developers here. We're already saying users should only install trus= tworthy applications. First, asking users to only install "trustworthy" application is a comple= tely useless recommendation: how do they know? How does anybody on this list know, in fact? Second: I don't think that the suggestion should be that the markets do this vetting -- they won't because they aren't fate shared. The auth serv= er, on the other hand, has the ability to not enroll clients. That at least is plausible rather than the completely implausible suggestion that billions of users educate themselves on millions of apps. Mike > > -----------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= ------------------------------------------- > *From:* Mark Mcgloin > *To:* William Mills > *Cc:* Barry Leiba ; Michael Thomas ; oauth WG ; oauth-bounces@ietf.org; Torsten Lodderst= edt > *Sent:* Thursday, January 5, 2012 6:03 AM > *Subject:* Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, e= nds 9 Dec 2011 > > Why do you think this William? Apple does it? Google android market had= to > pull 30 apps recently because they contained malware. There are automat= ed > tools that will do some sanity checks on apps and it is only advice, i.= e. > 'could' > > Mark > > > William Mills > > > > > " o Client applications could be validated prior publication in a > > application market." > > > > Should just be struck. Michael is correct that it's fluff, and > > unenforceable. There are too many app marketplaces, opensource > > projects, etc. to make this a useful suggestion. > > > > From: Michael Thomas > > > To: Torsten Lodderstedt > > > Cc: Barry Leiba >; oauth WG > > > Sent: Wednesday, January 4, 2012 3:40 PM > > Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, > > ends 9 Dec 2011 > > > > On 01/04/2012 02:14 PM, Torsten Lodderstedt wrote: > > > Hi Michael, > > > > > > Am 04.01.2012 22:06, schrieb Michael Thomas: > > >> I think the "perhaps unwisely" goes to the heart of my objection. = You > > >> might as well be talking about "perhaps unwisely" driving a car, > > >> or "perhaps unwisely" eating food: the reality is that people down= load > > >> apps by the *billions*. When I was initially blown off, many of t= he > > >> participants including document editors implied that only idiots g= et > > >> apps for their phones. That is *completely* unhelpful as the reali= ty > > >> is that OAUTH's use is hugely if not primarily deployed in that so= rt > of > > >> environment. > > > > > > I fully agree with you. That's why the core spec and the threat > > document both consider native apps. > > > > > >> > > >> This is a threat that cuts to the very heart of what OAUTH is, and= > purports > > >> to defend against: keeping user credentials out of the hands of an= > > >> untrusted third party. If there really aren't any good ways to > > mitigate this > > >> in an app environment, why is OAUTH being deployed so aggressively= > there? > > >> Shouldn't the threat draft say in blinking bold: "DEPLOYING OAUTH > > >> IN NATIVE APPS CONSIDERED HARMFUL"? > > > > > > You lost me. Is the situation getting any worse with OAuth? I > > don't think so. I think the situation is getting better, probably > > not as you might expect. > > > > My concern is that putting on a veneer of "security" will lull people= > into > > thinking "Oh, it's safe to enter my credentials here because this is > really > > twitterbook, not evilapp!". When I had to ask them directly to put th= eir > > twitterbook credentials into my app, there at least wasn't any confus= ion > > that I had access to them. > > > > Realistically, what you've done is protected the credentials from the= > good > > guys and not changed much for a motivated bad guy. Is that an > improvement? > > I'll buy that it's generally bad practice for good guys with most lik= ely > bad > > security chops to be storing credentials, but I'm guessing that the > original > > OAUTH motivation was more toward thwarting bad guys. > > > > > > > > The key question is: Why do we aim on "keeping user credentials > > out of the hands of an untrusted third party"? > > > > > > 1) To prevent phishing or 2) to prevent leakage of end-user > > credentials due to inappropriate handling or weak defence on the 3rd > party? > > > > > > wrt 1) I don't think so. I don't see how an authorization server > > shall validate the authenticity and trustworthiness of a client-side > > application. We already state this in section 4.4.1.4. of the > threatdocument. > > > > The draft says: > > > > o Client applications could be validated prior publication in a > > application market. > > > > I asked -- and didn't get a response -- about how exactly that might > > be done. I suspect > > that in practice for the twitterbook universe that there is no way > > that scales. So the > > reality here seems to be there isn't an answer for the Internet at > > large, and the threats > > document should just say that mitigation MAY be possible in very > > narrow use cases where > > code reviews, and other heavy handed analysis can be performed, but > > for the general case > > there is no mitigation. > > > > As far as 4.4.1.4 goes, I'd say that the counter measures really > > don't help except > > maybe for auditing. If that's what they're really about, the draft > > should make that > > explicit. > > > > Also on the subject of 4.4.1.4, this bullet: > > > > > > o If the authorization server automatically authenticates the end- > > user, it may nevertheless require some user input in order to > > prevent screen scraping. Examples are CAPTCHAs or user-specific= > > secret like PIN codes. > > > > > > I'm very skeptical because a native environment is a social > > engineering nirvana. > > The CAPTCHA could easily be shown to the user and they'd blissfully > > solve it just > > like they do any other one. > > > > > > > > > > > > > > ----------------------- > > > It is not the task of the authorization server to protect > > > the end-user's device from malicious software. This is the > > > responsibility of the platform running on the particular device > > > probably in cooperation with other components of the respective > > > ecosystem (e.g. an application management infrastructure). The = sole > > > responsibility of the authorization server is to control access = to > > > the end-user's resources living in resource servers and to preve= nt > > > unauthorized access to them. > > > ----------------------- > > > > I assume that it's in the authorization server's _interest_ to not > divulge > > user credentials to potentially evil third parties. If it's not, whyw= ould > you > > go to the trouble of implementing OAUTH at all? > > > > This is what's so troubling to me. The point is to keep user credenti= als > away > > from bad guys, but when shown how OAUTH in widely deployed scenarios > fails > > to do that, the response I get from the working group is "Not Our > Problem". > > Well it *is* your problem insofar as you are not advising the > twitterbooks to > > disallow native apps as clients, for example. > > > > > > > > wrt 2) Yes, I think that's the reason. And OAuth is a appropriate > > protocol to achieve this goal, even for mobile apps. Why? > > > > > > A typical mobile application consists of the app itself on the > > device and a corresponding backend service storing user data and > > implementing business and integration logic. Let's assume this > > application features address book import from other service > > providers. W/o OAuth, the app would gather the end-user's credential > > for a certain address book service and pass it to its backend > > service. This service in turn uses this credentials to access the > > service provider's API. So in such a scenario the following parties > > get in touch with the user credentials: > > > - the app > > > - the app's backend service > > > - the address book resource server > > > > With native mobile apps, the client (=3D app & app backend) isn't it = plenty > > enough to be seriously scary if they can screen scrape the credential= s > > with impunity? What problem was solved again? > > > > > > > > What threats do you see here? And which is most likely to occur? > > My favorite is an attack against the log files or the database of > > the backend service in order to obtain the end-users passwords for > > the resource server. Why? Because the cost/benefit ratio for an > > attacker is much better then attacking any app installation on a > > device and the protective measure on the resource server might be > > more appropriate then on the client side (backend service). > > > > Botnets prove that either is a successful business model. This isn't = a > zero > > sum game, after all. > > > > > OAuth mitigates this kind of attack by reducing the number of > > parties handling user credentials to the authorization server and > > the user agent. So even if the app itself would be the user agent > > (which is not recommended), > > > > Not recommended? It's messed up even thinking of it that way. The > > app is potentially > > *evil*. It really doesn't care what the IETF RECOMMENDS. If it's > > useful for it to be the > > UA, it's going to do just exactly that. > > > > > it would directly interact with the authorization server and the > > app's backend service would use tokens instead of end-user credential= s. > > > > The problem here is the capture of end user credentials. I believe th= at > OAUTH > > defends pretty well in the trusted desktop browser scenario it set > > out to solve > > for. I do not believe that it does that in the new reality of native > > apps, and embedded > > webviews. > > > > | Moreover, the recommended way is to let the app delegate the flow > > to a trusted system > > | component on the user's device, such as the system browser or an > > account manager. In that > > | case, the 3rd party is not getting in touch with the user > > credentials at all. > > > > Again, the Bad Guys are specifically and completely uninterested in > > being good and > > sending it to a trusted component. They will disregard this RECOMMEND= > faster > > than you can type it. > > > > > > I think the key question is whether anyone expects OAuth to solve > > the phishing problem. I don't think this is its main purpose, but it > > could facilitate to overcome the habit to enter user credentials > > everywhere. And this in turn may contribute to the fight against > phishing. > > > > There's much more to this than just phishing. > > > > 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 gffletch@aol.com Thu Jan 5 09:11:49 2012 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 9720921F87B9; Thu, 5 Jan 2012 09:11:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.142 X-Spam-Level: X-Spam-Status: No, score=-1.142 tagged_above=-999 required=5 tests=[AWL=1.142, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] 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 hjYhQuoZz539; Thu, 5 Jan 2012 09:11:45 -0800 (PST) Received: from imr-da04.mx.aol.com (imr-da04.mx.aol.com [205.188.105.146]) by ietfa.amsl.com (Postfix) with ESMTP id 40C7321F875F; Thu, 5 Jan 2012 09:11:45 -0800 (PST) Received: from mtaout-db05.r1000.mx.aol.com (mtaout-db05.r1000.mx.aol.com [172.29.51.197]) by imr-da04.mx.aol.com (8.14.1/8.14.1) with ESMTP id q05HBKnb017943; Thu, 5 Jan 2012 12:11:20 -0500 Received: from palantir.office.aol.com (palantir.office.aol.com [10.181.186.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-db05.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 75E25E00022C; Thu, 5 Jan 2012 12:11:19 -0500 (EST) Message-ID: <4F05D9B3.9000200@aol.com> Date: Thu, 05 Jan 2012 12:11:15 -0500 From: George Fletcher Organization: AOL LLC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Michael Thomas References: <8AB6F5CC-E9A2-4A07-9AA0-83FB7C67A221@oracle.com> <4EEA3951.5010904@mtcc.com> <4EEB5BDD.7080401@mtcc.com> <4F038CB9.1040403@mtcc.com> <4F0394D6.1090006@mtcc.com> <4F04AAAE.6080702@mtcc.com> <4F04ACE4.1070006@stpeter.im> <4F04B101.3070708@mtcc.com> <4F04BF70.3 <1325721020.62165.YahooMailNeo@web31812.mail.mud.yahoo.com> <1325781459.27034.YahooMailNeo@web31803.mail.mud.yahoo.com> <4F05D447.9070902@mtcc.com> In-Reply-To: <4F05D447.9070902@mtcc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20110426; t=1325783480; bh=aFXZhPLa1GM2684G18ZgSDR+CcLNNXjAmqvkXdIxdlA=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=AOc/7X/VlGJbkbWgHzAfCFJ034VvJrEFZ7kjeXi+tLMTdhUBFsIdQ5YxocOi2xKOt COdbzk/HV4o7+z2wxCgBkVvnWrdnAFnAqPhA09PrelOCjqFz1De7QTNuwoWscs5ekC dCdhhhm1kQzfr7LfSnfajdro5Q+nhH9j8efDu6P4= X-AOL-SCOLL-SCORE: 0:2:443649792:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d33c54f05d9b72bf4 X-AOL-IP: 10.181.186.254 Cc: Barry Leiba , oauth WG , "oauth-bounces@ietf.org" Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011 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, 05 Jan 2012 17:11:49 -0000 The problem is that even if the Authorization Server only gives out=20 credentials to "trusted clients", those clients can be "hacked" and the=20 credentials compromised allowing for impersonation of the "trusted=20 client". Obviously, protecting the credentials is easier if the client=20 is a web server with the appropriate security measures in place. However, that isn't the only use case that needs to be solved. Rich=20 desktop applications and mobile applications also need access to the=20 user's protected resources. The issue here is that clients (in the vast=20 majority of cases) can't be trusted. This means that all rich desktop/mobile app models currently in the=20 field are flawed (if we are trying to protect the user from a malicious=20 client). OAuth is specifically NOT trying to solve the "client=20 trustworthiness" problem. Personally, I don't see how to solve this=20 problem without "trusted hardware" in the client and that isn't yet=20 widely deployed. However, as others have pointed out, OAuth doesn't make the existing=20 situation worse (i.e. users are just as likely without OAuth to download = malicious code to their computers/devices and be phished). However, with = more "good" applications moving to OAuth, the situation generally=20 improves for the user, because their credentials are stored in fewer=20 places. It might even push the "bad guys" to having to implement=20 malicious apps as other methods of getting the user's credentials are=20 significantly reduced. From a threat model perspective, while OAuth doesn't solve this=20 specific threat, the use of OAuth overall improves the security of the us= er. My 2 cents:) On 1/5/12 11:48 AM, Michael Thomas wrote: > > Second: I don't think that the suggestion should be that the markets do= > this vetting -- they won't because they aren't fate shared. The auth=20 > server, > on the other hand, has the ability to not enroll clients. That at least= > is plausible rather than the completely implausible suggestion that > billions of users educate themselves on millions of apps. > > Mike > >> >> ----------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= ------------------------------------------=20 >> > --=20 >> *From:* Mark Mcgloin >> *To:* William Mills >> *Cc:* Barry Leiba ; Michael Thomas=20 >> ; oauth WG ; oauth-bounces@ietf.org;=20 >> Torsten Lodderstedt >> *Sent:* Thursday, January 5, 2012 6:03 AM >> *Subject:* Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, = >> ends 9 Dec 2011 >> >> Why do you think this William? Apple does it? Google android market=20 >> had to >> pull 30 apps recently because they contained malware. There are=20 >> automated >> tools that will do some sanity checks on apps and it is only advice,=20 >> i.e. >> 'could' >> >> Mark >> >> > William Mills > >> > >> > " o Client applications could be validated prior publication in a= >> > application market." >> > >> > Should just be struck. Michael is correct that it's fluff, and >> > unenforceable. There are too many app marketplaces, opensource >> > projects, etc. to make this a useful suggestion. >> > >> > From: Michael Thomas > >> > To: Torsten Lodderstedt > > >> > Cc: Barry Leiba > >; oauth WG > > >> > Sent: Wednesday, January 4, 2012 3:40 PM >> > Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, >> > ends 9 Dec 2011 >> > >> > On 01/04/2012 02:14 PM, Torsten Lodderstedt wrote: >> > > Hi Michael, >> > > >> > > Am 04.01.2012 22:06, schrieb Michael Thomas: >> > >> I think the "perhaps unwisely" goes to the heart of my=20 >> objection. You >> > >> might as well be talking about "perhaps unwisely" driving a car, >> > >> or "perhaps unwisely" eating food: the reality is that people=20 >> download >> > >> apps by the *billions*. When I was initially blown off, many of = >> the >> > >> participants including document editors implied that only idiots = >> get >> > >> apps for their phones. That is *completely* unhelpful as the=20 >> reality >> > >> is that OAUTH's use is hugely if not primarily deployed in that=20 >> sort >> of >> > >> environment. >> > > >> > > I fully agree with you. That's why the core spec and the threat >> > document both consider native apps. >> > > >> > >> >> > >> This is a threat that cuts to the very heart of what OAUTH is, an= d >> purports >> > >> to defend against: keeping user credentials out of the hands of a= n >> > >> untrusted third party. If there really aren't any good ways to >> > mitigate this >> > >> in an app environment, why is OAUTH being deployed so aggressivel= y >> there? >> > >> Shouldn't the threat draft say in blinking bold: "DEPLOYING OAUTH= >> > >> IN NATIVE APPS CONSIDERED HARMFUL"? >> > > >> > > You lost me. Is the situation getting any worse with OAuth? I >> > don't think so. I think the situation is getting better, probably >> > not as you might expect. >> > >> > My concern is that putting on a veneer of "security" will lull peopl= e >> into >> > thinking "Oh, it's safe to enter my credentials here because this is= >> really >> > twitterbook, not evilapp!". When I had to ask them directly to put=20 >> their >> > twitterbook credentials into my app, there at least wasn't any=20 >> confusion >> > that I had access to them. >> > >> > Realistically, what you've done is protected the credentials from th= e >> good >> > guys and not changed much for a motivated bad guy. Is that an >> improvement? >> > I'll buy that it's generally bad practice for good guys with most=20 >> likely >> bad >> > security chops to be storing credentials, but I'm guessing that the= >> original >> > OAUTH motivation was more toward thwarting bad guys. >> > >> > > >> > > The key question is: Why do we aim on "keeping user credentials >> > out of the hands of an untrusted third party"? >> > > >> > > 1) To prevent phishing or 2) to prevent leakage of end-user >> > credentials due to inappropriate handling or weak defence on the 3rd= >> party? >> > > >> > > wrt 1) I don't think so. I don't see how an authorization server >> > shall validate the authenticity and trustworthiness of a client-side= >> > application. We already state this in section 4.4.1.4. of the >> threatdocument. >> > >> > The draft says: >> > >> > o Client applications could be validated prior publication in a >> > application market. >> > >> > I asked -- and didn't get a response -- about how exactly that might= >> > be done. I suspect >> > that in practice for the twitterbook universe that there is no way >> > that scales. So the >> > reality here seems to be there isn't an answer for the Internet at >> > large, and the threats >> > document should just say that mitigation MAY be possible in very >> > narrow use cases where >> > code reviews, and other heavy handed analysis can be performed, but >> > for the general case >> > there is no mitigation. >> > >> > As far as 4.4.1.4 goes, I'd say that the counter measures really >> > don't help except >> > maybe for auditing. If that's what they're really about, the draft >> > should make that >> > explicit. >> > >> > Also on the subject of 4.4.1.4, this bullet: >> > >> > >> > o If the authorization server automatically authenticates the end- >> > user, it may nevertheless require some user input in order to >> > prevent screen scraping. Examples are CAPTCHAs or user-specifi= c >> > secret like PIN codes. >> > >> > >> > I'm very skeptical because a native environment is a social >> > engineering nirvana. >> > The CAPTCHA could easily be shown to the user and they'd blissfully >> > solve it just >> > like they do any other one. >> > >> > >> > >> > >> > > >> > > ----------------------- >> > > It is not the task of the authorization server to protect >> > > the end-user's device from malicious software. This is the >> > > responsibility of the platform running on the particular device= >> > > probably in cooperation with other components of the respective= >> > > ecosystem (e.g. an application management infrastructure). =20 >> The sole >> > > responsibility of the authorization server is to control=20 >> access to >> > > the end-user's resources living in resource servers and to=20 >> prevent >> > > unauthorized access to them. >> > > ----------------------- >> > >> > I assume that it's in the authorization server's _interest_ to not >> divulge >> > user credentials to potentially evil third parties. If it's not,=20 >> whywould >> you >> > go to the trouble of implementing OAUTH at all? >> > >> > This is what's so troubling to me. The point is to keep user=20 >> credentials >> away >> > from bad guys, but when shown how OAUTH in widely deployed scenarios= >> fails >> > to do that, the response I get from the working group is "Not Our >> Problem". >> > Well it *is* your problem insofar as you are not advising the >> twitterbooks to >> > disallow native apps as clients, for example. >> > >> > > >> > > wrt 2) Yes, I think that's the reason. And OAuth is a appropriate >> > protocol to achieve this goal, even for mobile apps. Why? >> > > >> > > A typical mobile application consists of the app itself on the >> > device and a corresponding backend service storing user data and >> > implementing business and integration logic. Let's assume this >> > application features address book import from other service >> > providers. W/o OAuth, the app would gather the end-user's credential= >> > for a certain address book service and pass it to its backend >> > service. This service in turn uses this credentials to access the >> > service provider's API. So in such a scenario the following parties >> > get in touch with the user credentials: >> > > - the app >> > > - the app's backend service >> > > - the address book resource server >> > >> > With native mobile apps, the client (=3D app & app backend) isn't it= =20 >> plenty >> > enough to be seriously scary if they can screen scrape the credentia= ls >> > with impunity? What problem was solved again? >> > >> > > >> > > What threats do you see here? And which is most likely to occur? >> > My favorite is an attack against the log files or the database of >> > the backend service in order to obtain the end-users passwords for >> > the resource server. Why? Because the cost/benefit ratio for an >> > attacker is much better then attacking any app installation on a >> > device and the protective measure on the resource server might be >> > more appropriate then on the client side (backend service). >> > >> > Botnets prove that either is a successful business model. This isn't= a >> zero >> > sum game, after all. >> > >> > > OAuth mitigates this kind of attack by reducing the number of >> > parties handling user credentials to the authorization server and >> > the user agent. So even if the app itself would be the user agent >> > (which is not recommended), >> > >> > Not recommended? It's messed up even thinking of it that way. The >> > app is potentially >> > *evil*. It really doesn't care what the IETF RECOMMENDS. If it's >> > useful for it to be the >> > UA, it's going to do just exactly that. >> > >> > > it would directly interact with the authorization server and the >> > app's backend service would use tokens instead of end-user=20 >> credentials. >> > >> > The problem here is the capture of end user credentials. I believe=20 >> that >> OAUTH >> > defends pretty well in the trusted desktop browser scenario it set >> > out to solve >> > for. I do not believe that it does that in the new reality of native= >> > apps, and embedded >> > webviews. >> > >> > | Moreover, the recommended way is to let the app delegate the flow >> > to a trusted system >> > | component on the user's device, such as the system browser or an >> > account manager. In that >> > | case, the 3rd party is not getting in touch with the user >> > credentials at all. >> > >> > Again, the Bad Guys are specifically and completely uninterested in >> > being good and >> > sending it to a trusted component. They will disregard this RECOMMEN= D >> faster >> > than you can type it. >> > > >> > > I think the key question is whether anyone expects OAuth to solve >> > the phishing problem. I don't think this is its main purpose, but it= >> > could facilitate to overcome the habit to enter user credentials >> > everywhere. And this in turn may contribute to the fight against >> phishing. >> > >> > There's much more to this than just phishing. >> > >> > 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 > From medkarim.esskalli@gmail.com Fri Jan 6 03:06:07 2012 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 AB5B521F8919 for ; Fri, 6 Jan 2012 03:06:07 -0800 (PST) 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 VrapQLMeLGBS for ; Fri, 6 Jan 2012 03:06:07 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id DB20721F8911 for ; Fri, 6 Jan 2012 03:06:06 -0800 (PST) Received: by laah2 with SMTP id h2so529576laa.31 for ; Fri, 06 Jan 2012 03:06:05 -0800 (PST) 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=W02A4fKL6X3yCQgYb6mADkadOgk6Ccbkenragq6lE6Y=; b=k55GgC7MQp+DG4nGZXGpJMERVoylIG4/Rupe1MAhDORpVSpRdQIt0mHjzmaBRZtDOH PZB0tO0GixdJzStMZXl5itI12vNYam3D7PbZF6wEFwDxA3Rah8YnRDP/SI+8WyonLRO+ 3LH7/FY7WF73sLypqcoaXXpFiBBH3WQfjA/4g= MIME-Version: 1.0 Received: by 10.112.85.129 with SMTP id h1mr1042245lbz.84.1325847965894; Fri, 06 Jan 2012 03:06:05 -0800 (PST) Received: by 10.152.42.72 with HTTP; Fri, 6 Jan 2012 03:06:05 -0800 (PST) Date: Fri, 6 Jan 2012 12:06:05 +0100 Message-ID: From: Karim To: oauth@ietf.org Content-Type: multipart/alternative; boundary=f46d0401683908876804b5da0914 Subject: [OAUTH-WG] OAuth2 security considerations for client_id 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, 06 Jan 2012 11:06:08 -0000 --f46d0401683908876804b5da0914 Content-Type: text/plain; charset=ISO-8859-1 Hello, When using User-agent flow with OAuth2 for mobile platform, there is no way for Authorization server to authenticate the client_id of the application. So, anyone can impersonate my app by copying the client_id (and so get all access tokens on my behalf), and this is applicable to Facebook, Foursquare,... This is not managed by OAuth2 ? Or I missed something ? For Web applications (Web server flow), access token is stored on the server side, and the client is authenticated using secret key. -- Karim --f46d0401683908876804b5da0914 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello,

When using User-agent flow with OAuth2= for mobile platform, there is no way for Authorization server to authentic= ate the client_id of the application.

So, anyone c= an impersonate my app by copying the client_id (and so get all access token= s on my behalf), and this is applicable to Facebook, Foursquare,...

This is not managed by OAuth2 ? Or I missed something ?=

For Web applications (Web server flow), access to= ken is stored on the server side, and the client is authenticated using sec= ret key.

--
Karim

--f46d0401683908876804b5da0914-- From torsten@lodderstedt.net Fri Jan 6 05:22:04 2012 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 A63B221F87EF for ; Fri, 6 Jan 2012 05:22:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[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 CnBMEwnkvpf8 for ; Fri, 6 Jan 2012 05:22:04 -0800 (PST) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.29]) by ietfa.amsl.com (Postfix) with ESMTP id E0EFC21F85B6 for ; Fri, 6 Jan 2012 05:22:03 -0800 (PST) Received: from [80.187.107.54] (helo=[10.223.181.27]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.68) (envelope-from ) id 1Rj9k9-0005my-AI; Fri, 06 Jan 2012 14:22:01 +0100 References: User-Agent: K-9 Mail for Android In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----5WNUD2RWEZCFB1KRA5LQWRQFTTCXFV" From: Torsten Lodderstedt Date: Fri, 06 Jan 2012 14:21:45 +0100 To: Karim ,oauth@ietf.org Message-ID: <0f4aff4b-9fcc-4077-9fca-a068ebf97dd4@email.android.com> X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Subject: Re: [OAUTH-WG] OAuth2 security considerations for client_id 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, 06 Jan 2012 13:22:04 -0000 ------5WNUD2RWEZCFB1KRA5LQWRQFTTCXFV Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi, your observation is correct. OAuth security considerations recommend not to rely on secrets for authenticating mobile apps (aka native apps) but to manage them as so-called public clients. Please take a look onto section 10 of the core spec for further details. regards, Torsten. Karim schrieb: Hello, When using User-agent flow with OAuth2 for mobile platform, there is no way for Authorization server to authenticate the client_id of the application. So, anyone can impersonate my app by copying the client_id (and so get all access tokens on my behalf), and this is applicable to Facebook, Foursquare,... This is not managed by OAuth2 ? Or I missed something ? For Web applications (Web server flow), access token is stored on the server side, and the client is authenticated using secret key. -- Karim ------5WNUD2RWEZCFB1KRA5LQWRQFTTCXFV Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi,

your observation is correct. OAuth security considerations recommend not to rely on secrets for authenticating mobile apps (aka native apps) but to manage them as so-called public clients. Please take a look onto section 10 of the core spec for further details.

regards,
Torsten.



Karim <medkarim.esskalli@gmail.com> schrieb:
Hello,

When using User-agent flow with OAuth2 for mobile platform, there is no way for Authorization server to authenticate the client_id of the application.

So, anyone can impersonate my app by copying the client_id (and so get all access tokens on my behalf), and this is applicable to Facebook, Foursquare,...

This is not managed by OAuth2 ? Or I missed something ?

For Web applications (Web server flow), access token is stored on the server side, and the client is authenticated using secret key.

--
Karim

------5WNUD2RWEZCFB1KRA5LQWRQFTTCXFV-- From wmills@yahoo-inc.com Fri Jan 6 09:34:38 2012 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 7B6D721F873C for ; Fri, 6 Jan 2012 09:34:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.598 X-Spam-Level: X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mb2ysbI-hM7k for ; Fri, 6 Jan 2012 09:34:37 -0800 (PST) Received: from nm23.bullet.mail.ac4.yahoo.com (nm23.bullet.mail.ac4.yahoo.com [98.139.52.220]) by ietfa.amsl.com (Postfix) with SMTP id 74F3821F86F9 for ; Fri, 6 Jan 2012 09:34:36 -0800 (PST) Received: from [98.139.52.189] by nm23.bullet.mail.ac4.yahoo.com with NNFMP; 06 Jan 2012 17:34:30 -0000 Received: from [98.139.52.177] by tm2.bullet.mail.ac4.yahoo.com with NNFMP; 06 Jan 2012 17:34:29 -0000 Received: from [127.0.0.1] by omp1060.mail.ac4.yahoo.com with NNFMP; 06 Jan 2012 17:34:29 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 984899.85095.bm@omp1060.mail.ac4.yahoo.com Received: (qmail 64336 invoked by uid 60001); 6 Jan 2012 17:34:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1325871269; bh=pP9FL8Ach89YWfCirdG9YtZL5+P0epajFPaTAIDcWiU=; 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=mL/kMEvusVvdzAoicoC80ZRE9iPGMngMzy3e7sxUK/06ee+n693tchi9/l5J0o/xvqk9Bwt7ruGy08Qzn9B7R4B9djNV18N6Co4U8QRQBAsUhhioP3+yZLw3HGoGjTPz+gF2LIRVAY0rGv79hTarME8k/EFB9Y6LpqfVSe5IOf8= 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=IAz8zY48l4YmOiUKxNis9G031P8FIpbf4zzam7nEr3H8RBl4bUr5XM+d2BZctJoecn3O6sZS9f94HNmSGldbN5+tk5jDIdf6D4TS1/eXmK+pNuwffh3KPohX6/JnIMo8kWzvMQZZcWU9Eau0VNi/oVmvSFp8up6Z7gBzV+QZeUY=; X-YMail-OSG: .OYlgyMVM1n_XabHW8mwNeszcYcYybo.EDyiFEtqhl0Kkbt Xrhu3MqFbzLAyskm274sKivij8qYLi9IrmlZjP6dLan9UU9Y7UfEx0Y9tKA0 tRz4CWQtOta3ewTZU9yxplReD0rcg7HrzzV7h3MF3ThyBwFpHxhSJyIiPqcd rvClKDImD56nMLBHAKNyvtnlTtwhm_XmVRCkIKSbAuVpjK4KKDSNjU.NMZm7 KTRXY6qaUVSbfueRQH.zLI43ENxAbGGs6FE7O7sSPbyfCYuC7MP.phzp0RmR IQ7WHvFsBsFZB.M.EgbaHXwJs2ccu9ZD4I2koeKw2bkgjyaAM5t3ZiVPH_1g N3K8mEM87wn47SRg0CbZTXtwYOWPgQ7ba_sUARWOuTVQ624q8ixDRSC_InE2 sHKsb8KdJAvs9a1JmU0ORkLuOu2TLe.saV4vT Received: from [67.72.118.219] by web31809.mail.mud.yahoo.com via HTTP; Fri, 06 Jan 2012 09:34:28 PST X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.116.331537 References: <0f4aff4b-9fcc-4077-9fca-a068ebf97dd4@email.android.com> Message-ID: <1325871268.64118.YahooMailNeo@web31809.mail.mud.yahoo.com> Date: Fri, 6 Jan 2012 09:34:28 -0800 (PST) From: William Mills To: Torsten Lodderstedt , Karim , "oauth@ietf.org" In-Reply-To: <0f4aff4b-9fcc-4077-9fca-a068ebf97dd4@email.android.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1395015409-1758934852-1325871268=:64118" Subject: Re: [OAUTH-WG] OAuth2 security considerations for client_id 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, 06 Jan 2012 17:34:38 -0000 ---1395015409-1758934852-1325871268=:64118 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Yeah, certainly for Mobile clients this is true.=A0 There are classes of cl= ients (server to server implementations notably) where clientID can be a pr= oper secret and be usefule for client validation.=0A=0A=0A=0A______________= __________________=0A From: Torsten Lodderstedt = =0ATo: Karim ; oauth@ietf.org =0ASent: Friday,= January 6, 2012 5:21 AM=0ASubject: Re: [OAUTH-WG] OAuth2 security consider= ations for client_id=0A =0A=0AHi,=0A=0Ayour observation is correct. OAuth s= ecurity considerations recommend not to rely on secrets for authenticating = mobile apps (aka native apps) but to manage them as so-called public client= s. Please take a look onto section 10 of the core spec for further details.= =0A=0Aregards,=0ATorsten.=0A=0A=0A=0A=0AKarim = schrieb:=0AHello,=0A>=0A>=0A>When using User-agent flow with OAuth2 for mo= bile platform, there is no way for Authorization server to authenticate the= client_id of the application.=0A>=0A>=0A>So, anyone can impersonate my app= by copying the client_id (and so get all access tokens on my behalf), and = this is applicable to Facebook, Foursquare,...=0A>=0A>=0A>This is not manag= ed by OAuth2 ? Or I missed something ?=0A>=0A>=0A>For Web applications (Web= server flow), access token is stored on the server side, and the client is= authenticated using secret key.=0A>=0A>-- =0A>Karim=0A>=0A>=0A____________= ___________________________________=0AOAuth mailing list=0AOAuth@ietf.org= =0Ahttps://www.ietf.org/mailman/listinfo/oauth ---1395015409-1758934852-1325871268=:64118 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Yeah, certainly for Mobile clients this is true.  There are classes = of clients (server to server implementations notably) where clientID can be= a proper secret and be usefule for client validation.

From:<= /b> Torsten Lodderstedt <torsten@lodderstedt.net>
To: Karim <medkarim.esskalli@gmail.co= m>; oauth@ietf.org
Sent: Friday, January 6, 2012 5:21 AM
Subject: Re: [OAUTH-WG] OAuth2 security considerations f= or client_id
=0A
=0A Hi,
=0A
= =0Ayour observation is correct. OAuth security considerations recommend not= to rely on secrets for authenticating mobile apps (aka native apps) but to= manage them as so-called public clients. Please take a look onto section 1= 0 of the core spec for further details.
=0A
=0Aregards,
=0ATorsten= .


=0A
=0AKarim <med= karim.esskalli@gmail.com> schrieb:
=0A
Hello,

When usi= ng User-agent flow with OAuth2 for mobile platform, there is no way for Aut= horization server to authenticate the client_id of the application.

So, anyone can impersonate my app by copying the client_i= d (and so get all access tokens on my behalf), and this is applicable to Fa= cebook, Foursquare,...
=0A

This is not managed by O= Auth2 ? Or I missed something ?

For Web applicatio= ns (Web server flow), access token is stored on the server side, and the cl= ient is authenticated using secret key.
=0A

--
Karim=
=0A

__________________________________________= _____
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/l= istinfo/oauth


---1395015409-1758934852-1325871268=:64118-- From jricher@mitre.org Fri Jan 6 09:45:05 2012 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 E518921F876D for ; Fri, 6 Jan 2012 09:45:05 -0800 (PST) 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 FOJdluQAji-J for ; Fri, 6 Jan 2012 09:45:05 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id E1D7321F8769 for ; Fri, 6 Jan 2012 09:45:04 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id BABE221B0EB1 for ; Fri, 6 Jan 2012 12:45:03 -0500 (EST) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 8DA7221B0E45 for ; Fri, 6 Jan 2012 12:45:03 -0500 (EST) Received: from [129.83.50.12] (129.83.31.51) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.1.339.1; Fri, 6 Jan 2012 12:45:03 -0500 Message-ID: <4F0732F5.7030703@mitre.org> Date: Fri, 6 Jan 2012 12:44:21 -0500 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: References: <0f4aff4b-9fcc-4077-9fca-a068ebf97dd4@email.android.com> <1325871268.64118.YahooMailNeo@web31809.mail.mud.yahoo.com> In-Reply-To: <1325871268.64118.YahooMailNeo@web31809.mail.mud.yahoo.com> Content-Type: multipart/alternative; boundary="------------040708030005010206010601" X-Originating-IP: [129.83.31.51] Subject: Re: [OAUTH-WG] OAuth2 security considerations for client_id 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, 06 Jan 2012 17:45:06 -0000 --------------040708030005010206010601 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit The important thing to realize here is that just having the client_id doesn't get you access tokens, and it certainly doesn't give you access to all access tokens issued to that client_id in the past. It does allow for a phishing scenario in that it will let you try to impersonate a known-good client by copying the client_id, but each individual user will still have to authorize the fake client in order for it to get a new access token. But keep in mind that this doesn't expose the user's actual credentials to the application (on mobile especially, assuming use of external browsers trusted by the platform -- as has been discussed on the list here, a bad application could always embed a browser and try to steal your credentials directly, but they can do that anyway without OAuth). The mitigation and cleanup of fake clients like this is also simpler, since you can revoke tokens without much cost to users and service providers. These reasons are why it's suggested to use the authorization code flow with mobile apps, just without a client_secret. You can lessen the attack vector by using a trusted and preregistered callback_uri, and there's even been some discussion about how to do that with cloud services handling the callbacks for trusted applications on the platform. -- Justin On 01/06/2012 12:34 PM, William Mills wrote: > Yeah, certainly for Mobile clients this is true. There are classes of > clients (server to server implementations notably) where clientID can > be a proper secret and be usefule for client validation. > > ------------------------------------------------------------------------ > *From:* Torsten Lodderstedt > *To:* Karim ; oauth@ietf.org > *Sent:* Friday, January 6, 2012 5:21 AM > *Subject:* Re: [OAUTH-WG] OAuth2 security considerations for client_id > > Hi, > > your observation is correct. OAuth security considerations recommend > not to rely on secrets for authenticating mobile apps (aka native > apps) but to manage them as so-called public clients. Please take a > look onto section 10 of the core spec for further details. > > regards, > Torsten. > > > > Karim schrieb: > > Hello, > > When using User-agent flow with OAuth2 for mobile platform, there > is no way for Authorization server to authenticate the client_id > of the application. > > So, anyone can impersonate my app by copying the client_id (and so > get all access tokens on my behalf), and this is applicable to > Facebook, Foursquare,... > > This is not managed by OAuth2 ? Or I missed something ? > > For Web applications (Web server flow), access token is stored on > the server side, and the client is authenticated using secret key. > > -- > Karim > > > _______________________________________________ > 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 --------------040708030005010206010601 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit The important thing to realize here is that just having the client_id doesn't get you access tokens, and it certainly doesn't give you access to all access tokens issued to that client_id in the past. It does allow for a phishing scenario in that it will let you try to impersonate a known-good client by copying the client_id, but each individual user will still have to authorize the fake client in order for it to get a new access token.

But keep in mind that this doesn't expose the user's actual credentials to the application (on mobile especially, assuming use of external browsers trusted by the platform -- as has been discussed on the list here, a bad application could always embed a browser and try to steal your credentials directly, but they can do that anyway without OAuth). The mitigation and cleanup of fake clients like this is also simpler, since you can revoke tokens without much cost to users and service providers.

These reasons are why it's suggested to use the authorization code flow with mobile apps, just without a client_secret. You can lessen the attack vector by using a trusted and preregistered callback_uri, and there's even been some discussion about how to do that with cloud services handling the callbacks for trusted applications on the platform.

 -- Justin

On 01/06/2012 12:34 PM, William Mills wrote:
Yeah, certainly for Mobile clients this is true.  There are classes of clients (server to server implementations notably) where clientID can be a proper secret and be usefule for client validation.

From: Torsten Lodderstedt <torsten@lodderstedt.net>
To: Karim <medkarim.esskalli@gmail.com>; oauth@ietf.org
Sent: Friday, January 6, 2012 5:21 AM
Subject: Re: [OAUTH-WG] OAuth2 security considerations for client_id
Hi,

your observation is correct. OAuth security considerations recommend not to rely on secrets for authenticating mobile apps (aka native apps) but to manage them as so-called public clients. Please take a look onto section 10 of the core spec for further details.

regards,
Torsten.



Karim <medkarim.esskalli@gmail.com> schrieb:
Hello,

When using User-agent flow with OAuth2 for mobile platform, there is no way for Authorization server to authenticate the client_id of the application.

So, anyone can impersonate my app by copying the client_id (and so get all access tokens on my behalf), and this is applicable to Facebook, Foursquare,...

This is not managed by OAuth2 ? Or I missed something ?

For Web applications (Web server flow), access token is stored on the server side, and the client is authenticated using secret key.

--
Karim


_______________________________________________
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

--------------040708030005010206010601-- From paul.madsen@gmail.com Fri Jan 6 09:48:26 2012 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 72DE921F896B for ; Fri, 6 Jan 2012 09:48:26 -0800 (PST) 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 mZi18sbSFyrP for ; Fri, 6 Jan 2012 09:48:25 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9AEFE21F8769 for ; Fri, 6 Jan 2012 09:48:25 -0800 (PST) Received: by vcbfk13 with SMTP id fk13so1520160vcb.31 for ; Fri, 06 Jan 2012 09:48:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=zulfVYOUNOxhLPRW6MjJ3v6NjvAcX93RORJK0peEV4k=; b=wswliGpXhHf1dowZXxjthtsBI4jPNwUXmtjQrHtFyAWigHB5IxBzpZw0BZo9BY34cG J97G9I5n1mSQKFNrqCyQjzADOuVWMbul0SRrqFRgOV2yOFVTgoS4ttwCRePH8V2OP+xU y5ZMIdKdUu8K5ZQuU4hcouMLbmV76MdP7h+fg= Received: by 10.220.149.135 with SMTP id t7mr4227712vcv.34.1325872105142; Fri, 06 Jan 2012 09:48:25 -0800 (PST) Received: from pmadsen-mbp.local (CPE0022b0cb82b4-CM0012256eb4b4.cpe.net.cable.rogers.com. [72.136.168.159]) by mx.google.com with ESMTPS id bj19sm18197781vdc.16.2012.01.06.09.48.23 (version=SSLv3 cipher=OTHER); Fri, 06 Jan 2012 09:48:24 -0800 (PST) Message-ID: <4F0733E6.2000308@gmail.com> Date: Fri, 06 Jan 2012 12:48:22 -0500 From: Paul Madsen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: William Mills References: <0f4aff4b-9fcc-4077-9fca-a068ebf97dd4@email.android.com> <1325871268.64118.YahooMailNeo@web31809.mail.mud.yahoo.com> In-Reply-To: <1325871268.64118.YahooMailNeo@web31809.mail.mud.yahoo.com> Content-Type: multipart/alternative; boundary="------------040205070105040705070908" Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth2 security considerations for client_id 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, 06 Jan 2012 17:48:26 -0000 This is a multi-part message in MIME format. --------------040205070105040705070908 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit William, presumably you meant 'client_secret'? And is it fair to say that this reflects the current reality (of app distribution channels & OS protections) more so than any inherent mobile client limitation? paul On 1/6/12 12:34 PM, William Mills wrote: > Yeah, certainly for Mobile clients this is true. There are classes of > clients (server to server implementations notably) where clientID can > be a proper secret and be usefule for client validation. > > ------------------------------------------------------------------------ > *From:* Torsten Lodderstedt > *To:* Karim ; oauth@ietf.org > *Sent:* Friday, January 6, 2012 5:21 AM > *Subject:* Re: [OAUTH-WG] OAuth2 security considerations for client_id > > Hi, > > your observation is correct. OAuth security considerations recommend > not to rely on secrets for authenticating mobile apps (aka native > apps) but to manage them as so-called public clients. Please take a > look onto section 10 of the core spec for further details. > > regards, > Torsten. > > > > Karim schrieb: > > Hello, > > When using User-agent flow with OAuth2 for mobile platform, there > is no way for Authorization server to authenticate the client_id > of the application. > > So, anyone can impersonate my app by copying the client_id (and so > get all access tokens on my behalf), and this is applicable to > Facebook, Foursquare,... > > This is not managed by OAuth2 ? Or I missed something ? > > For Web applications (Web server flow), access token is stored on > the server side, and the client is authenticated using secret key. > > -- > Karim > > > _______________________________________________ > 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 --------------040205070105040705070908 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit William, presumably you meant 'client_secret'?

And is it fair to say that this reflects the current reality (of app distribution channels & OS protections) more so than any inherent mobile client limitation?

paul

On 1/6/12 12:34 PM, William Mills wrote:
Yeah, certainly for Mobile clients this is true.  There are classes of clients (server to server implementations notably) where clientID can be a proper secret and be usefule for client validation.

From: Torsten Lodderstedt <torsten@lodderstedt.net>
To: Karim <medkarim.esskalli@gmail.com>; oauth@ietf.org
Sent: Friday, January 6, 2012 5:21 AM
Subject: Re: [OAUTH-WG] OAuth2 security considerations for client_id
Hi,

your observation is correct. OAuth security considerations recommend not to rely on secrets for authenticating mobile apps (aka native apps) but to manage them as so-called public clients. Please take a look onto section 10 of the core spec for further details.

regards,
Torsten.



Karim <medkarim.esskalli@gmail.com> schrieb:
Hello,

When using User-agent flow with OAuth2 for mobile platform, there is no way for Authorization server to authenticate the client_id of the application.

So, anyone can impersonate my app by copying the client_id (and so get all access tokens on my behalf), and this is applicable to Facebook, Foursquare,...

This is not managed by OAuth2 ? Or I missed something ?

For Web applications (Web server flow), access token is stored on the server side, and the client is authenticated using secret key.

--
Karim


_______________________________________________
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
--------------040205070105040705070908-- From wmills@yahoo-inc.com Fri Jan 6 10:24:30 2012 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 1109621F85BD for ; Fri, 6 Jan 2012 10:24:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.241 X-Spam-Level: X-Spam-Status: No, score=-17.241 tagged_above=-999 required=5 tests=[AWL=0.357, 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 Nt56CsRtnnyb for ; Fri, 6 Jan 2012 10:24:28 -0800 (PST) Received: from nm15.bullet.mail.sp2.yahoo.com (nm15.bullet.mail.sp2.yahoo.com [98.139.91.85]) by ietfa.amsl.com (Postfix) with SMTP id CE99621F84EB for ; Fri, 6 Jan 2012 10:24:28 -0800 (PST) Received: from [98.139.91.69] by nm15.bullet.mail.sp2.yahoo.com with NNFMP; 06 Jan 2012 18:24:28 -0000 Received: from [98.139.91.42] by tm9.bullet.mail.sp2.yahoo.com with NNFMP; 06 Jan 2012 18:24:28 -0000 Received: from [127.0.0.1] by omp1042.mail.sp2.yahoo.com with NNFMP; 06 Jan 2012 18:24:28 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 745492.83603.bm@omp1042.mail.sp2.yahoo.com Received: (qmail 25561 invoked by uid 60001); 6 Jan 2012 18:24:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1325874268; bh=XCBK3h2GpU4ZQgkETPzvttYTIi2qYITcd1V+2Ptkgos=; 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=W74WlPG2fkOlC7FRu0KHX8ProRO6JMuLZdBxQOKHwC9ag1H4UQExVNxY73Ewv0pXEtaz0CyYl+2REpVmYsDoXvTKuYIwfYVdhgyYbtxG5LYRL6HUbwmSolo4YavmWJjlClTvZW+6GBDlv/6+x9bL5QjLlciWq5m/9YoGE0QASA8= 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=ZsrBBxMGw/TKnwwOjMXPvu1X6QiwDRUbnz7SBeABMhqlIoelevVHgi2ptKM+e5cWZGIsGap1In7kPD+zgyi3zTCCf0UI5nrVF8v1JtRJuCMtMIDfKe4bnQ010zejGu0cVSDPHX2A1KcJkOOOdLdgpcbDddHc1EqhAkQD7AU9rYM=; X-YMail-OSG: lkrKetAVM1lOPHzCDY36NMRrFGivRFWfizIs30iZ_WkjFhp lRZQVmnLIDQED4BHT4Pu_YNKSr04A2pztU8xCEfesHUrE4QgF_JJDI0OY1fM c7JtOshlbt.8Ves2D5JDMTPef3Cb9xSZbkK6sJFC0xdQMrtycRSJe.h2MJeA 9JQhcEWnIo2oj4t0mCP8WNIBNy0jR6wQix.BqYGC0w_bLGK_720LPJL0jOqi Hso0Zqm7B_l.nKrBWXRv.rAKYS36Ps6XxHwcQIpHYnmFi6_hGkvrD73RODHG 4UGJzI21t1JOXLWFSbR5Zfsy5g.QF2.Y942xsDzVkpDmT3nCoorIKSmVrdrK GH22dV94h361oxesPpknBFMDKQ6kvJiHcw31T1uvZ7X5imWi8zNGaUTwoOSP JaIDja7gtpEdGXURngU6QN3vGKK2O2SMV8IsS2g-- Received: from [209.131.62.115] by web31807.mail.mud.yahoo.com via HTTP; Fri, 06 Jan 2012 10:24:28 PST X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.116.331537 References: <0f4aff4b-9fcc-4077-9fca-a068ebf97dd4@email.android.com> <1325871268.64118.YahooMailNeo@web31809.mail.mud.yahoo.com> <4F0733E6.2000308@gmail.com> Message-ID: <1325874268.38071.YahooMailNeo@web31807.mail.mud.yahoo.com> Date: Fri, 6 Jan 2012 10:24:28 -0800 (PST) From: William Mills To: Paul Madsen In-Reply-To: <4F0733E6.2000308@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-125733401-1557728781-1325874268=:38071" Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth2 security considerations for client_id 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, 06 Jan 2012 18:24:30 -0000 ---125733401-1557728781-1325874268=:38071 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Yeah, I sure did.=A0 Client ID being the moral equivalent of user agent str= ing in a browser.=0A=0A=0A=0A________________________________=0A From: Paul= Madsen =0ATo: William Mills = =0ACc: Torsten Lodderstedt ; Karim ; "oauth@ietf.org" =0ASent: Friday, January = 6, 2012 9:48 AM=0ASubject: Re: [OAUTH-WG] OAuth2 security considerations fo= r client_id=0A =0A=0AWilliam, presumably you meant 'client_secret'?=0A=0AAn= d is it fair to say that this reflects the current reality (of app=0A di= stribution channels & OS protections) more so than any=0A inherent mobil= e client limitation?=0A=0Apaul=0A=0AOn 1/6/12 12:34 PM, William Mills wrote= : =0AYeah, certainly for Mobile clients this is true.=A0 There are classes = of clients (server to server implementations notably) where clientID can be= a proper secret and be usefule for client validation.=0A>=0A>=0A>=0A>=0A>_= _______________________________=0A> From: Torsten Lodderstedt =0A>To: Karim ; oauth@ietf.org =0A= >Sent: Friday, January 6, 2012 5:21 AM=0A>Subject: Re: [OAUTH-WG] OAuth2 se= curity considerations for client_id=0A> =0A>=0A>Hi,=0A>=0A>your observation= is correct. OAuth security considerations=0A recommend not to= rely on secrets for authenticating mobile=0A apps (aka native= apps) but to manage them as so-called=0A public clients. Plea= se take a look onto section 10 of the=0A core spec for further= details.=0A>=0A>regards,=0A>Torsten.=0A>=0A>=0A>=0A>=0A>Karim schrieb: =0A>Hello,=0A>>=0A>>=0A>>When using User-agent f= low with OAuth2 for mobile platform, there is no way for Authorization serv= er to authenticate the client_id of the application.=0A>>=0A>>=0A>>So, anyo= ne can impersonate my app by copying the client_id (and so get all access t= okens on my behalf), and this is applicable to Facebook, Foursquare,...=0A>= >=0A>>=0A>>This is not managed by OAuth2 ? Or I missed something ?=0A>>=0A>= >=0A>>For Web applications (Web server flow), access token is stored on the= server side, and the client is authenticated using secret key.=0A>>=0A>>= =0A-- =0A>>Karim=0A>>=0A>>=0A>_____________________________________________= __=0A>OAuth mailing list=0A>OAuth@ietf.org=0A>https://www.ietf.org/mailman/= listinfo/oauth=0A>=0A>=0A>=0A>=0A>=0A>_____________________________________= __________=0AOAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman= /listinfo/oauth ---125733401-1557728781-1325874268=:38071 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Yeah, I sure did.  Client ID being the moral equivalent of user agen= t string in a browser.

From: Paul Madsen <paul.madsen@g= mail.com>
To: Willi= am Mills <wmills@yahoo-inc.com>
Cc: Torsten Lodderstedt <torsten@lodderstedt.net>; Ka= rim <medkarim.esskalli@gmail.com>; "oauth@ietf.org" <oauth@ietf.or= g>
Sent: Friday, J= anuary 6, 2012 9:48 AM
Subject:= Re: [OAUTH-WG] OAuth2 security considerations for client_id
 =0A
=0A =0A=0A =0A =0A
=0A William, presumably you meant 'client_secret'?
=0A =
=0A And is it fair to say that this reflects the current reality (= of app=0A distribution channels & OS protections) more so than any= =0A inherent mobile client limitation?
=0A
=0A paul
=0A =
=0A On 1/6/12 12:34 PM, William Mills wrote:=0A
=0A
= =0A
Yeah, certainly for Mobile clients this is true. = ;=0A There are classes of clients (server to server=0A = implementations notably) where clientID can be a proper=0A sec= ret and be usefule for client validation.
=0A
=0A =

=0A
=0A
=0A =
=0A
= From:=0A Tors= ten Lodderstedt <torsten@lodderstedt.net>
=0A = To: Karim=0A = <medkarim.esskalli@gmail.com>; = oauth@ietf.org
=0A Sent:=0A Friday, January 6, 2012 5:21 AM
=0A = Subject:=0A = Re: [OAUTH-WG] OAuth2 security considerations for=0A = client_id
=0A
=0A
Hi,
=0A
=0A your observation is co= rrect. OAuth security considerations=0A recommend not to rely = on secrets for authenticating mobile=0A apps (aka native apps)= but to manage them as so-called=0A public clients. Please tak= e a look onto section 10 of the=0A core spec for further detai= ls.
=0A
=0A regards,
=0A T= orsten.
=0A
=0A

=0A
=0A Karim <medkarim.esskalli@gmail.com> schrieb:=0A =
=0A =
Hello,
=0A

=0A =
=0A
When using User-agent flow with OA= uth2 for mobile=0A platform, there is no way for Authori= zation server=0A to authenticate the client_id of the ap= plication.
=0A

=0A
= =0A
So, anyone can impersonate my app by copying the= =0A client_id (and so get all access tokens on my=0A = behalf), and this is applicable to Facebook,=0A = Foursquare,...
=0A

=0A =
=0A
This is not managed by OAuth2 ? Or I mi= ssed=0A something ?
=0A

= =0A
=0A
For Web applications (= Web server flow), access=0A token is stored on the serve= r side, and the client=0A is authenticated using secret = key.
=0A

=0A
=0A = --
=0A Karim
=0A
= =0A
=0A
=0A =0A
=0A ________________________________________= _______
=0A OAuth mailing list
=0A OAuth@ietf.org
=0A https:= //www.ietf.org/mailman/listinfo/oauth
=0A
=0A =
=0A
=0A
=0A
=0A
=0A=
=0A =
=0A 
_______________________________________________=0AOAu=
th mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/oauth=0A<=
/pre>=0A
=0A
=0A=0A


---125733401-1557728781-1325874268=:38071-- From medkarim.esskalli@gmail.com Fri Jan 6 10:48:53 2012 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 6726F21F89E9 for ; Fri, 6 Jan 2012 10:48:53 -0800 (PST) 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 Y-JFUOPdrq2d for ; Fri, 6 Jan 2012 10:48:52 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0A5DC21F89E6 for ; Fri, 6 Jan 2012 10:48:51 -0800 (PST) Received: by laah2 with SMTP id h2so692015laa.31 for ; Fri, 06 Jan 2012 10:48:51 -0800 (PST) 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=e7EBJKMNLD4KCNXiZpdWyZpCfhVzgOABXrgf8K2qY9E=; b=YmqzWlwegIQafJdNPuZ6Xvf9EY4dIAtn+gwai/puzKTyVR/3fZ3CeN12+Loqeh3kmm k4r+HTt3srGoPjS0B72TtVBIRRhu8I2KlZRM2j9ML7bGIJuN8btIPLqT23w/G8OC9+NQ 7UyUwQWPv6RJxX5Dy8c2+IM4y+N/EKBX57JYI= MIME-Version: 1.0 Received: by 10.152.130.5 with SMTP id oa5mr2825044lab.49.1325875731003; Fri, 06 Jan 2012 10:48:51 -0800 (PST) Received: by 10.152.42.72 with HTTP; Fri, 6 Jan 2012 10:48:50 -0800 (PST) In-Reply-To: <4F0732F5.7030703@mitre.org> References: <0f4aff4b-9fcc-4077-9fca-a068ebf97dd4@email.android.com> <1325871268.64118.YahooMailNeo@web31809.mail.mud.yahoo.com> <4F0732F5.7030703@mitre.org> Date: Fri, 6 Jan 2012 19:48:50 +0100 Message-ID: From: Karim To: Justin Richer Content-Type: multipart/alternative; boundary=f46d04339e42f6791004b5e07ff6 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth2 security considerations for client_id 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, 06 Jan 2012 18:48:53 -0000 --f46d04339e42f6791004b5e07ff6 Content-Type: text/plain; charset=ISO-8859-1 The term "trusted client" is not applicable to mobile devices as they cannot keep secret. I agree that the "attacker" actions are limited even if he "discovered" the client_id, actually he can do nothing as you pointed : He needs approval from end user's to access their data, but how to alert them (educate them) about the risks of phishing attacks.... We have no choice but to trust authorization servers to detect (this is possible ?) any malicious use of client_id and to prevent end-user's each time they are going to approve sharing data. On 6 January 2012 18:44, Justin Richer wrote: > The important thing to realize here is that just having the client_id > doesn't get you access tokens, and it certainly doesn't give you access to > all access tokens issued to that client_id in the past. It does allow for a > phishing scenario in that it will let you try to impersonate a known-good > client by copying the client_id, but each individual user will still have > to authorize the fake client in order for it to get a new access token. > > But keep in mind that this doesn't expose the user's actual credentials to > the application (on mobile especially, assuming use of external browsers > trusted by the platform -- as has been discussed on the list here, a bad > application could always embed a browser and try to steal your credentials > directly, but they can do that anyway without OAuth). The mitigation and > cleanup of fake clients like this is also simpler, since you can revoke > tokens without much cost to users and service providers. > > These reasons are why it's suggested to use the authorization code flow > with mobile apps, just without a client_secret. You can lessen the attack > vector by using a trusted and preregistered callback_uri, and there's even > been some discussion about how to do that with cloud services handling the > callbacks for trusted applications on the platform. > > -- Justin > > > On 01/06/2012 12:34 PM, William Mills wrote: > > Yeah, certainly for Mobile clients this is true. There are classes of > clients (server to server implementations notably) where clientID can be a > proper secret and be usefule for client validation. > > ------------------------------ > *From:* Torsten Lodderstedt > *To:* Karim ; > oauth@ietf.org > *Sent:* Friday, January 6, 2012 5:21 AM > *Subject:* Re: [OAUTH-WG] OAuth2 security considerations for client_id > > Hi, > > your observation is correct. OAuth security considerations recommend not > to rely on secrets for authenticating mobile apps (aka native apps) but to > manage them as so-called public clients. Please take a look onto section 10 > of the core spec for further details. > > regards, > Torsten. > > > > Karim schrieb: > > Hello, > > When using User-agent flow with OAuth2 for mobile platform, there is no > way for Authorization server to authenticate the client_id of the > application. > > So, anyone can impersonate my app by copying the client_id (and so get > all access tokens on my behalf), and this is applicable to Facebook, > Foursquare,... > > This is not managed by OAuth2 ? Or I missed something ? > > For Web applications (Web server flow), access token is stored on the > server side, and the client is authenticated using secret key. > > -- > Karim > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- Karim --f46d04339e42f6791004b5e07ff6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The term "trusted client" is not applicable to mobile devices as = they cannot keep secret.
I agree that the "attacker" actions are limited even if he "= discovered" the=20 client_id, actually he can do nothing as you pointed :
He needs approva= l from end user's to access their data, but how to alert them (educate = them) about the risks of phishing attacks....
We have no choice but to t= rust authorization servers to detect (this is possible ?) any malicious use= of client_id and to prevent end-user's each time they are going to app= rove sharing data.


On 6 January 2012 18:44, Justin Richer <= span dir=3D"ltr"><jricher@mitre.org= > wrote:
=20 =20 =20
The important thing to realize here is that just having the client_id doesn't get you access tokens, and it certainly doesn'= ;t give you access to all access tokens issued to that client_id in the past. It does allow for a phishing scenario in that it will let you try to impersonate a known-good client by copying the client_id, but each individual user will still have to authorize the fake client in order for it to get a new access token.

But keep in mind that this doesn't expose the user's actual credentials to the application (on mobile especially, assuming use of external browsers trusted by the platform -- as has been discussed on the list here, a bad application could always embed a browser and try to steal your credentials directly, but they can do that anyway without OAuth). The mitigation and cleanup of fake clients like this is also simpler, since you can revoke tokens without much cost to users and service providers.

These reasons are why it's suggested to use the authorization code flow with mobile apps, just without a client_secret. You can lessen the attack vector by using a trusted and preregistered callback_uri, and there's even been some discussion about how to do that with cloud services handling the callbacks for trusted applications on the platform.

=A0-- Justin


On 01/06/2012 12:34 PM, William Mills wrote:
=20
Yeah, certainly for Mobile clients this is true.=A0 There are classes of clients (server to server implementations notably) where clientID can be a proper secret and be usefule for client validation.

From: Torsten Lodderstedt <torsten@lodderstedt.net>
To: Karim <medkarim.esskalli@gmail.com>; oauth@ietf.org
Sent: Friday, January 6, 2012 5:21 AM
Subject: Re: [OAUTH-WG] OAuth2 security considerations for client_id
Hi,

your observation is correct. OAuth security considerations recommend not to rely on secrets for authenticating mobile apps (aka native apps) but to manage them as so-called public clients. Please take a look onto section 10 of the core spec for further details.

regards,
Torsten.



Karim <medkarim.esskalli@gmail.com> schrieb:
Hello,

When using User-agent flow with OAuth2 for mobile platform, there is no way for Authorization server to authenticate the client_id of the application.

So, anyone can impersonate my app by copying the client_id (and so get all access tokens on my behalf), and this is applicable to Facebook, Foursquare,...

This is not managed by OAuth2 ? Or I missed something ?

For Web applications (Web server flow), access token is stored on the server side, and the client is authenticated using secret key.

--
Karim


_______________________________________________
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




--
Karim

--f46d04339e42f6791004b5e07ff6-- From eran@hueniverse.com Fri Jan 6 22:39:06 2012 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 A1B2B21F8579 for ; Fri, 6 Jan 2012 22:39:06 -0800 (PST) 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, MIME_8BIT_HEADER=0.3] 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 FUCORJKXkHqY for ; Fri, 6 Jan 2012 22:39:04 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id ACC7721F8540 for ; Fri, 6 Jan 2012 22:39:04 -0800 (PST) Received: (qmail 30499 invoked from network); 7 Jan 2012 06:39:02 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 7 Jan 2012 06:39:02 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Fri, 6 Jan 2012 23:39:01 -0700 From: Eran Hammer-Lahav To: =?iso-8859-1?Q?Andr=E9_DeMarre?= , OAuth WG Date: Fri, 6 Jan 2012 23:38:46 -0700 Thread-Topic: [OAUTH-WG] Fwd: secdir review of draft-ietf-oauth-v2 Thread-Index: Acx4A9ErG1XoqpU8S1iuvVokuiykZRVAyVJg Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453A72D0C29@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E6E4FEA.7090100@sunet.se> <4E6E735D.3050806@cs.tcd.ie> <90C41DD21FB7C64BB94121FBBC2E72345213D92D60@P3PW5EX1MB01.EX1.SECURESERVER.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Fwd: secdir review of draft-ietf-oauth-v2 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, 07 Jan 2012 06:39:06 -0000 Simply added to the first paragraph: The authorization server MUST support the HTTP Basic authenticat= ion scheme for authenticating clients which were issued a client password. EHL > -----Original Message----- > From: Andr=E9 DeMarre [mailto:andredemarre@gmail.com] > Sent: Tuesday, September 20, 2011 7:12 PM > To: Eran Hammer-Lahav; OAuth WG > Subject: Re: [OAUTH-WG] Fwd: secdir review of draft-ietf-oauth-v2 > > > If the server issues clients with password credentials it MUST support = HTTP > Basic (this is the flip side of 'the client MAY use HTTP Basic') and shou= ld only > support the client_secret parameter if it has clients incapable of using = HTTP > Basic. > > Very well. Without changing the meaning, I think the community would be > well served by appending paragraph 2 of Section 2.3 as follows: > ---- > Confidential clients are typically issued (or establish) a set of > client credentials used for authenticating with the authorization > server (e.g. password, public/private key pair). If clients are > issued passwords, the authorization server MUST support the HTTP > Basic authentication scheme as defined in [RFC2617] and described > by Section 2.3.1. > ---- > This helps to communicate that authorization servers are only required to > support HTTP Basic if they issue client passwords. > > Andre > > On Tue, Sep 20, 2011 at 3:20 PM, Eran Hammer-Lahav > wrote: > > If the server issues clients with password credentials it MUST support = HTTP > Basic (this is the flip side of 'the client MAY use HTTP Basic') and shou= ld only > support the client_secret parameter if it has clients incapable of using = HTTP > Basic. > > > > This language has been tweaked to reach a delicate balance. I'm not > inclined to touch it. > > > > EHL > > > >> -----Original Message----- > >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >> Behalf Of Andr=E9 DeMarre > >> Sent: Wednesday, September 14, 2011 5:25 PM > >> To: OAuth WG > >> Subject: Re: [OAUTH-WG] Fwd: secdir review of draft-ietf-oauth-v2 > >> > >> I agree that stating "Clients in possession of a client password MAY > >> use the HTTP Basic authentication scheme" [Section 2.3.1 paragraph 1] > >> implies that authorization servers MUST support HTTP basic > >> authentication, but such is never asserted. Instead, it says "The > >> authorization server MAY accept any form of client authentication > >> meeting its security requirements." [Section 2.3 paragraph 1] This is > somewhat contradictory. > >> > >> I can understand that requiring a specific method of client > >> authentication is desirable for maximum interoperability, but this > >> would be problematic for authorization server implementations that > >> wish to enforce stronger security than HTTP Basic. Such > >> implementations would be forced to deviate from the specification. In > >> particular, implementations which choose MAC access tokens instead of > >> Bearer tokens may wish to add a layer of security to defend against > >> improperly configured TLS connections, or to protect clients who conne= ct > to the wrong server. > >> [http://hueniverse.com/2010/09/oauth-bearer-tokens-are-a-terrible-ide > >> a/] Such implementations will also find HTTP Basic undesirable for > >> client authentication. To require a form of client authentication > >> that isn't universally sufficient could become a source of criticism > >> and deter adoption of OAuth 2.0. > >> > >> I think the best solution is to clarify section 2.3.1 as follows: > >> --- > >> Clients in possession of client credentials MAY use any form of > >> authentication scheme supported by the authorization server. > >> --- > >> And then follow with the existing example that demonstrates HTTP Basic= . > >> > >> Regards, > >> Andre DeMarre > >> > >> On Tue, Sep 13, 2011 at 4:52 PM, Greg Brail wrote: > >> > I would like to add my support to the comments below on section > >> > 2.3, specifically 2.3.1. > >> > > >> > It is clear to me from reading section 2.3 that clients MAY use > >> > HTTP basic, or they MAY include client_id and client_secret in the > >> > request body -- however, the latter is not recommended. > >> > > >> > It is not clear what the authorization server MUST support. IMHO, > >> > that leads us to a situation in which there is no > >> > universally-agreed set of authentication technology that all > >> > programmers can assume is going to work, which means that > >> > interoperability will be difficult as some authorization servers > >> > will support Basic, others will support the request body, and others= will > do neither in favor of something else. > >> > > >> > I would prefer that we make both HTTP basic AND the request body > >> > mechanisms in this section both required on the server side, thus > >> > giving the client the option of choosing one or the other. That > >> > would mean re-writing the beginning of section 2.3.1 as shown below. > >> > > >> > If I have missed other discussion on this topic I apologize. If > >> > there is already consensus to make the "message body" > >> > authentication optional rather than required for the authorization > >> > SERVER then I would still recommend that we make HTTP Basic a MUST > >> > in order to allow easier interop. > >> > > >> > Proposed change to 2.3.1: > >> > > >> > ---- > >> > > >> > The authorization server MUST support the HTTP Basic authentication > >> > scheme as defined in [RFC2617] as a way to identify clients. The > >> > client identifier is used as the username, and the client password > >> > is used as the password. > >> > > >> > For example (extra line breaks are for display purposes only): > >> > > >> > Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW > >> > > >> > Alternatively, the authorization server MUST also allow the client > >> > to include the client credentials in the request body using the > >> > following > >> > parameters: > >> > > >> > client_id > >> > REQUIRED. The client identifier issued to the client > >> > during > >> > the registration process described by Section 2.2. > >> > client_secret > >> > REQUIRED. The client secret. The client MAY omit the > >> > parameter if the client secret is an empty string. > >> > > >> > Clients in possession of a client password MAY use either mechanism > >> > in order to authenticate with the authorization server. However, > >> > including the client credentials in the request body using the two > >> > parameters is NOT RECOMMENDED, and should be limited to clients > >> > unable to directly utilize the HTTP Basic authentication scheme (or > >> > other password-based HTTP authentication schemes). > >> > > >> > (Rest of section remains as-is with the paragraph beginning "For > >> > example...") > >> > > >> > Gregory Brail | Technology | Apigee | +1-650-937-9302 > >> > > >> > On Mon, Sep 12, 2011 at 2:02 PM, Stephen Farrell > >> > wrote: > >> >> > >> >> FYI, probably best for the WG to see/process these secdir comments > >> >> as appropriate. I've not read 'em in detail myself yet, so as Leif > >> >> says, feel free to react as appropriate. > >> >> > >> >> S. > >> >> > >> >> PS: Thanks Leif for reviewing this. > >> >> > >> >> -------- Original Message -------- > >> >> Subject: secdir review of draft-ietf-oauth-v2 > >> >> Date: Mon, 12 Sep 2011 20:31:06 +0200 > >> >> From: Leif Johansson > >> >> To: draft-ietf-oauth-v2@tools.ietf.org, secdir@ietf.org, > >> >> iesg@ietf.org > >> >> > >> >> -----BEGIN PGP SIGNED MESSAGE----- > >> >> Hash: SHA1 > >> >> > >> >> > >> >> Security review of OAUTH 2.0 core: draft-ietf-oauth-v2-21 > >> >> > >> >> Do not be alarmed. I have reviewed this document as part of the > >> >> security directorate's ongoing effort to review all IETF documents > >> >> being processed by the IESG. These comments were written > >> >> primarily for the benefit of the security area directors. > >> >> Document editors and WG chairs should treat these comments just > >> >> like any other last call comments. > >> >> > >> >> This review is rather lengthy. This should not be interpreted as > >> >> anything beyond a desire to do a thorough review. > >> >> > >> >> It may well be that I have stumbled on things already covered on > >> >> the list. If so I apologize and ask that you silently ignore such b= its. > >> >> Also I have included things that are not directly security related > >> >> but that I found problematic for other reasons. > >> >> > >> >> The notes are presented in the order I wrote them down. > >> >> > >> >> ** General observations: > >> >> > >> >> POST and/or GET > >> >> > >> >> Examples are sometimes POST and sometimes GET. In many cases it is > >> >> not clear to me from the surrounding text if both POST and GET are > >> >> allowed or if only one is mandated. Illustrating with both a GET > >> >> _and_ POST example in the cases where both are supported would > >> >> help or make the method explicit in the text before the example. > >> >> > >> >> The P-word > >> >> > >> >> The term 'password' is sprinkled throughout the document, > >> >> sometimes as in "client password" or "resource owner password > >> >> credentials" and I suspect that sometimes it is password as in 'an > >> >> example of a credential type' and in other cases it is password as > >> >> in 'plain old password'. This needs to be cleared up throughout > >> >> (I've included some examples below). > >> >> > >> >> Normative Language > >> >> > >> >> I've often found myself wanting more normative language often to > >> >> replace existing but less precise text. I've called out some > >> >> important cases below. > >> >> > >> >> Unknown parameters > >> >> > >> >> The sentence "The client SHOULD ignore unrecognized response > >> parameters" > >> >> occurs in several places. First of all I would argue that this has > >> >> to be a MUST if you want to be able to guarantee extensibility. > >> >> Secondly there are some error responses that are triggered by > >> >> unsupported request parameters. This seems like an inconsistency. > >> >> > >> >> ** Specifics > >> >> > >> >> 1.1 Roles > >> >> > >> >> Forward references to the sections where the roles are defined > >> >> would improve readability. > >> >> > >> >> As an illustration of an alternative model for the authorization > >> >> server maybe an informative reference to UMA would be illustrative > >> here. > >> >> > >> >> 1.2 Protocol Flow > >> >> > >> >> (A) talks about 'an intermediary such as an authorization server.' > >> >> it isn't clear it me if this refers to a separate authorization > >> >> server or if it is the same authorization server that is referenced= in (B). > >> >> > >> >> 1.3.3 Resource Owner Password Credentials > >> >> > >> >> When I first read this I thought - why not talk about Resource > >> >> Owner Credentials - in fact there is a parenthesis there "(e.g a > >> >> username and password)" that seems to indicate that other > >> >> credentials could be supported. > >> >> > >> >> This needs to be cleared up. Either its username and password and > >> >> nothing else or there is a way to support things like Negotiate or > >> >> X.509-based credentials in which case it should really be Resource > >> >> Owner Credentials with no reference to passwords other than as as > >> >> an example of one possible credential type. > >> >> > >> >> 1.4 Access Token > >> >> > >> >> first paragraph: "The string is usually opaque". This should be > >> >> reformulated as normative language. In fact I would have liked > >> >> guidance on generating those tokens (which has been brought up on > >> >> the > >> >> list) possibly as part of an implementation-guide. > >> >> > >> >> 1.5 Refresh Token > >> >> > >> >> Why is the refresh token not simply treated as an access token for > >> >> the access token resource in the authorization server? This would > >> >> seem to simplify the model a bit by removing a type of token whose > >> >> semantic (at least to this reviewer) is a duplication of a normal > >> >> access token for a particular type of resource. > >> >> > >> >> Also in the first paragraph: "(access tokens may have a shorter > >> >> lifetime and fewer permissions". Why not try to write normative > >> >> language here - there are security implications of allowing a > >> >> refresh token to get more permissions (say) than the original acces= s > token. > >> >> > >> >> 2.1 Client types > >> >> > >> >> I find the terminology public/confidential somewhat counter-intuiti= ve. > >> >> An app you have on your personal device is 'public' while a shared > >> >> cloud service is 'confidential'...hmm... > >> >> > >> >> This section also lacks normative language which isn't good. There > >> >> should be language defining the behavior of public and > >> >> confidential client aswell as the three profiles. > >> >> > >> >> For instance under native application we have "It is assumed that > >> >> any client authentication credentials included in the application > >> >> can be extracted". This should really be normative language. Some > >> >> of what I am looking for can be found in section 2.3 but it isn't > >> >> clear to me that it covers the definition of the profiles. > >> >> > >> >> 2.3.1 Client Password > >> >> > >> >> There is also some confusion here about what the client must > >> >> implement and what the server must implement wrt the use of > >> >> client_id. I read the text as trying to say that Servers SHOULD > >> >> support both and clients SHOULD only do Basic. > >> >> > >> >> This section also seems to have been the product of a partial > >> >> s/password/credential/g operation. Either OAUTH is only meant to > >> >> use Basic and passwords or we want to cover all/most HTTP > >> >> authentication methods and credentials and then section 2.3.2 > >> >> (which feels like an > >> >> afterthought) needs to get folded into 2.3.1 and the normative > >> >> language (and examples!) need some work to cover at least X.509s > >> >> and perhaps even Negotiate. > >> >> > >> >> Personally I would try to fold 2.3.1 and 2.3.2 into one section > >> >> and say that servers MUST support Basic and > client_id+client_password. > >> >> Servers MAY support any HTTP authentication method with a mapping > >> >> to > >> client_id. > >> >> If a client supports username+passwords it SHOULD do Basic and if > >> >> it supports other HTTP authentication methods it MUST NOT use > >> >> client_password for anything and MUST follow normal HTTP > >> >> authentication method negotiation. > >> >> > >> >> Finally, everywhere there is negotiation there must imho be some > >> >> mention/discussion/protection of downgrade attacks. > >> >> > >> >> 3.1 Authorization Endpoints > >> >> > >> >> 6th paragraph: "The authorization server SHOULD ignore > >> >> unrecognized request parameters". This formulation returns in > >> >> several places in the document and I don't understand why it isn't > >> >> a MUST - after all doesn't extensibility depend on this? > >> >> > >> >> 3.1.1 Response Type > >> >> > >> >> The response_type parameter is REQURED but its absence SHOULD > >> >> result in an error. Why not MUST? > >> >> > >> >> 3.1.2 Redirection Endpoint > >> >> > >> >> There should be a clear normative specification for how to match > >> >> endpoints. There are traces of this in various parts of the > >> >> document when matching is discussed. I recommend making a concise > >> >> definition in one place (namely here) and referencing this > >> >> throughout. Since this comparison has security implications it > >> >> should be a priority for the specification to be air-tight. > >> >> > >> >> 3.1.2.2 Registration Requirements > >> >> > >> >> "(the client MAY use the state request parameter to achieve > >> >> per-request customization)". Doesn't this overload its use for > >> >> CSRF- > >> protection? > >> >> > >> >> 3.1.2.4 Invalid Endpoint > >> >> > >> >> "The authorization server SHOULD NOT redirect...". Why isn't this > >> >> a MUST NOT? > >> >> > >> >> 3.1.2.5 Endpoint Content > >> >> > >> >> This section basically seems to say "Serve with server-side code > >> >> not with html or client-side code". If this is the case then I > >> >> suggest reformulate to say precisely that using normative language. > >> >> > >> >> The use of the word "script" could perhaps also be made less > >> >> ambiguous since in this case it could refer to both server-side > >> >> code aswell as in-browser code. > >> >> > >> >> 3.2.1 Client Authentication > >> >> > >> >> The phrase "clients issued client credentials" could be rephrased > >> >> to make less violence on English - perhaps "clients that have been > >> >> issued with client credentials", unless that is not the intended > >> >> meaning in which case I argue for something easier to understand > >> >> ;-) > >> >> > >> >> The second bullet: Using client credentials more often also > >> >> exposes them more which might be worth mentioning aswell. > >> >> > >> >> 4. Obtaining Authorization > >> >> > >> >> Perhaps not critical but the term 'password credentials' occurs in > >> >> the first paragraph and this doesn't seem compatible with resource > >> >> owner authentication being out of scope. It could just be that it > >> >> should read 'resource owner credentials' but it could also signal > >> >> an underlying assumption about username and password being used > >> >> for resource owner authentication. In either case I thing its best > >> >> to avoid the use of the word 'password' to avoid any confusion. > >> >> > >> >> 4.1 Authorization Code > >> >> > >> >> (C) - "using the redirection URI provided earlier" should perhaps > >> >> read "using the redirection URI provided earlier or associated > >> >> with the client in client registration" > >> >> > >> >> > >> >> 4.1.1 and 4.1.2 Authorization Request/Authorization Response > >> >> > >> >> The redirect_uri is listed as OPTIONAL with a reference to 3.1.2 > >> >> but there is no mention in 4.1.2 how to handle the case when the > >> >> redirect_uri is not present. I believe the assumption is that the > >> >> redirect_uri is either resent or part of client registration but > >> >> that needs to be made explicit in that case. > >> >> > >> >> This may apply to other uses of the redirect_uri parameter eg in 4.= 2.1. > >> >> > >> >> Furthermore in 4.2.2 "code" I suggest the following > >> >> re-formulatation of the last sentence: "The client MUST NOT use an > >> >> authorization code for more than one request. If an authorization > >> >> code is re-used, the authorization server should treat that as a > >> >> replay attack and SHOULD revoke all tokens associated with the clie= nt." > (i.e loose the "attempt" > >> >> bit which carries no real meaning) > >> >> > >> >> Also note that this is potentially a DOS attack should a single > >> >> authz code leak. > >> >> > >> >> 4.1.2.1 Error Response > >> >> > >> >> First paragraph, last sentence "and MUST NOT automatically redirect= ". > >> >> In the light of how willing users normally are to click on links > >> >> presented to them I would strengthen this to "MUST prevent the > >> >> user from following the redirect URI" > >> >> > >> >> In the definition of the invalid_request parameter I don't > >> >> understand how unsupported parameters can generate an error since > >> >> endpoints should ignore unsupported parameters (in order to support > extensibility). > >> >> > >> >> 4.1.3 Access Token Request > >> >> > >> >> "require client authentication for confidential clients or for any > >> >> client issued client credentials (or with other authentication > >> >> requirements)" > >> >> > >> >> This text seems unnecessarily convoluted. Isn't enough to say that > >> >> if you have issued credentials to a client you MUST require > >> >> authentication from that client? This applies equally to the other > >> >> sections where client authentication is an issue (eg 4.3.2). > >> >> > >> >> Also cf my comment on 3.1.2 for the discussion of matching > >> >> redirect_uri in the last bullet: ".. and that their values are > >> >> identical". Is this really meant to mean identical? > >> >> > >> >> 4.2 Implicit Grant > >> >> > >> >> The parenthesis "(it does not support the issuance of refresh token= s)" > >> >> sounds like it should really be normative language, "refresh > >> >> tokens MUST NOT be issues for implicit grant" because afaiu you > >> >> could easily extend "fragment-transport" to include a > >> >> refresh-token, so it isn't a technically motivated constraint, righ= t? > >> >> > >> >> In (D) I would like to have a normative reference to a document > >> >> that specifies browser behavior for URL fragments since this is a > >> >> critical security dependency for this grant type. > >> >> > >> >> 4.4 Client Credentials > >> >> > >> >> I think the text should note that this model effectively implies > >> >> that the client is able to impersonate all users which has the > >> >> potential for worse security problems than if the client has > >> >> access to individual user passwords. > >> >> > >> >> 6 Refreshing an Access Token > >> >> > >> >> scope - The term "lesser than" is intuitive but imprecise. I > >> >> suggest "MUST NOT include any scope not originally granted by the > >> >> resource > >> owner". > >> >> > >> >> 7.1 and 8.1 Access Token Types > >> >> > >> >> The section 7.1 lists two definitions of access token types and > >> >> provides a couple of examples but doesn't provide any constraints > >> >> on future development of access tokens except in 8.1 where it is > >> >> implied that not all access token types would be associated with > >> >> HTTP authentication mechanisms. Are there really no constraints on > >> >> access token types that should be captured? > >> >> > >> >> 10.6 Authorization Code Redirection URI Manipulation > >> >> > >> >> Suggest replace the word 'familiar' with 'trusted' in the first > >> >> sentence of the second paragraph. The notion of trust opens up > >> >> several boat loads of worm but it is the correct term here I think. > >> >> > >> >> In the third paragraph "the same as" wrt redirection URIs occur > >> >> and this needs to be defined (cf comments on 3.1.2 above). > >> >> > >> >> Finally "The authorization server MUST require public clients and > >> >> SHOULD require confidential clients to register their redirection > >> >> URI". I am missing a discussion of why the two types of client > >> >> differ wrt this attack vector. > >> >> > >> >> 10.10 Credentials Guessing Attack > >> >> > >> >> I found myself wanting implementation advice for how to generate > >> >> good tokens at this point. This has been raised on the list too. > >> >> The same goes for how to generate good CSRF cookies where the "(eg > >> >> a hash of the session cookie..." feels like it is implementation > >> >> advice yearning to come out of the closet. > >> >> > >> >> > >> >> Thats it. > >> >> > >> >> Cheers Leif > >> >> -----BEGIN PGP SIGNATURE----- > >> >> Version: GnuPG v1.4.11 (GNU/Linux) > >> >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > >> >> > >> >> > >> > iEYEARECAAYFAk5uT+YACgkQ8Jx8FtbMZncXQgCfZmTlzuESq0plfpkceQN1ont > >> E > >> >> a1QAoIEcg06GYK+6Fn4y40cTL1jQ+KmS > >> >> =3Dox42 > >> >> -----END PGP SIGNATURE----- > >> >> > >> >> _______________________________________________ > >> >> OAuth mailing list > >> >> OAuth@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/oauth > >> > _______________________________________________ > >> > OAuth mailing list > >> > OAuth@ietf.org > >> > https://www.ietf.org/mailman/listinfo/oauth > >> > > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > From eran@hueniverse.com Fri Jan 6 22:51:00 2012 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 5827311E8075 for ; Fri, 6 Jan 2012 22:51:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 8hJoLgp+Bzf2 for ; Fri, 6 Jan 2012 22:50:59 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id C6BF111E8072 for ; Fri, 6 Jan 2012 22:50:59 -0800 (PST) Received: (qmail 27766 invoked from network); 7 Jan 2012 06:50:59 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 7 Jan 2012 06:50:59 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Fri, 6 Jan 2012 23:50:59 -0700 From: Eran Hammer-Lahav To: Leif Johansson , OAuth WG Date: Fri, 6 Jan 2012 23:50:45 -0700 Thread-Topic: secdir review of draft-ietf-oauth-v2 Thread-Index: AcxxejcLK5M7cRirTtqV4b97NCZawwGWSTgQAAPAPYAVSTVQ4A== Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453A72D0C2A@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E6E4FEA.7090100@sunet.se> <90C41DD21FB7C64BB94121FBBC2E72345213D92D5A@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72345213D92D5A@P3PW5EX1MB01.EX1.SECURESERVER.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] secdir review of draft-ietf-oauth-v2 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, 07 Jan 2012 06:51:00 -0000 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Eran Hammer-Lahav > Sent: Tuesday, September 20, 2011 3:13 PM > > 3.1.1 Response Type > > > > The response_type parameter is REQURED but its absence SHOULD result > > in an error. Why not MUST? Changes to MUST. > > 3.1.2.4 Invalid Endpoint > > > > "The authorization server SHOULD NOT redirect...". Why isn't this a > > MUST NOT? >=20 > I'm ok with MUST NOT - any objections? This one is actually tricky. I don't like the current text (mine) because u= ntrusted is a useless qualifier here. The point is that redirecting to unre= gistered endpoints can lead to the abuse of the endpoint as an open redirec= tor. Because we actually support unregistered callbacks, we can't say MUST = NOT. I am removing the 'untrusted' part but leaving the SHOULD NOT as is. EHL From eran@hueniverse.com Fri Jan 6 22:57:33 2012 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 0094F11E8079 for ; Fri, 6 Jan 2012 22:57:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 8LVOIajmpu6v for ; Fri, 6 Jan 2012 22:57:31 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 29CF711E8074 for ; Fri, 6 Jan 2012 22:57:26 -0800 (PST) Received: (qmail 32230 invoked from network); 7 Jan 2012 06:57:25 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 7 Jan 2012 06:57:25 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Fri, 6 Jan 2012 23:57:24 -0700 From: Eran Hammer-Lahav To: "eran@sled.com" , Leif Johansson , OAuth WG Date: Fri, 6 Jan 2012 23:57:11 -0700 Thread-Topic: secdir review of draft-ietf-oauth-v2 Thread-Index: AcxxejcLK5M7cRirTtqV4b97NCZawwGWSTgQAAPAPYAVSZe9UA== Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453A72D0C2B@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E6E4FEA.7090100@sunet.se> <90C41DD21FB7C64BB94121FBBC2E72345213D92D5A@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72345213D92D5A@P3PW5EX1MB01.EX1.SECURESERVER.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] secdir review of draft-ietf-oauth-v2 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, 07 Jan 2012 06:57:33 -0000 I have not seen any follow up to the open issues and will be closing them o= n my editor's list. This doesn't mean they are closed, just that I will not= be addressing them without someone raising them again on the list. Since n= one of them are in the tracker, this email is the only record I know of lis= ting them (and their status/response). EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Eran Hammer-Lahav > Sent: Tuesday, September 20, 2011 3:13 PM > To: Leif Johansson; OAuth WG > Subject: Re: [OAUTH-WG] secdir review of draft-ietf-oauth-v2 > > (+OAuth WG, -everyone else) > > Thanks Leif. > > See comments inline. Whatever issues are still open will be addressed alo= ng > with the rest of the IETF LC feedback. > > EHL > > > > -----Original Message----- > > From: Leif Johansson [mailto:leifj@sunet.se] > > Sent: Monday, September 12, 2011 11:31 AM > > > ** General observations: > > > > POST and/or GET > > > > Examples are sometimes POST and sometimes GET. In many cases it is not > > clear to me from the surrounding text if both POST and GET are allowed > > or if only one is mandated. Illustrating with both a GET _and_ POST > > example in the cases where both are supported would help or make the > > method explicit in the text before the example. > > > > The P-word > > > > The term 'password' is sprinkled throughout the document, sometimes as > > in "client password" or "resource owner password credentials" and I > > suspect that sometimes it is password as in 'an example of a > > credential type' and in other cases it is password as in 'plain old > > password'. This needs to be cleared up throughout (I've included some > examples below). > > > > Normative Language > > > > I've often found myself wanting more normative language often to > > replace existing but less precise text. I've called out some important = cases > below. > > > > Unknown parameters > > > > The sentence "The client SHOULD ignore unrecognized response > > parameters" > > occurs in several places. First of all I would argue that this has to > > be a MUST if you want to be able to guarantee extensibility. Secondly > > there are some error responses that are triggered by unsupported > > request parameters. This seems like an inconsistency. > > > > ** Specifics > > > > 1.1 Roles > > > > Forward references to the sections where the roles are defined would > > improve readability. > > What sections? That's the only place these roles are defined. > > > As an illustration of an alternative model for the authorization > > server maybe an informative reference to UMA would be illustrative here= . > > A reference to UMA would be confusing in this document. > > > 1.2 Protocol Flow > > > > (A) talks about 'an intermediary such as an authorization server.' it > > isn't clear it me if this refers to a separate authorization server or > > if it is the same authorization server that is referenced in (B). > > Changed to: > > (A) The client requests authorization from the resource own= er. The > authorization request > can be made directly to the resource owner (as shown), or p= referably > indirectly via > the authorization server as an intermediary. > > > 1.3.3 Resource Owner Password Credentials > > > > When I first read this I thought - why not talk about Resource Owner > > Credentials - in fact there is a parenthesis there "(e.g a username > > and password)" that seems to indicate that other credentials could be > supported. > > > > This needs to be cleared up. Either its username and password and > > nothing else or there is a way to support things like Negotiate or > > X.509-based credentials in which case it should really be Resource > > Owner Credentials with no reference to passwords other than as as an > > example of one possible credential type. > > Changed to: > > (i.e. username and password) > > This is explicitly just for username and password. Other types require an > extension. > > > 1.4 Access Token > > > > first paragraph: "The string is usually opaque". This should be > > reformulated as normative language. In fact I would have liked > > guidance on generating those tokens (which has been brought up on the > > list) possibly as part of an implementation-guide. > > There is not requirement for the string to be opaque, but the general > architecture assumes it is. Otherwise, please suggest language. > > > 1.5 Refresh Token > > > > Why is the refresh token not simply treated as an access token for the > > access token resource in the authorization server? This would seem to > > simplify the model a bit by removing a type of token whose semantic > > (at least to this > > reviewer) is a duplication of a normal access token for a particular > > type of resource. > > Simpler architecture but probably more confusing to many developers. > > > Also in the first paragraph: "(access tokens may have a shorter > > lifetime and fewer permissions". Why not try to write normative > > language here - there are security implications of allowing a refresh > > token to get more permissions > > (say) than the original access token. > > This was discussed before and we could not reach consensus. > > > 2.1 Client types > > > > I find the terminology public/confidential somewhat counter-intuitive. > > An app you have on your personal device is 'public' while a shared > > cloud service is 'confidential'...hmm... > > These are the best terms we could come up with. Not intuitive but well > defined. > > > This section also lacks normative language which isn't good. There > > should be language defining the behavior of public and confidential > > client aswell as the three profiles. > > > > For instance under native application we have "It is assumed that any > > client authentication credentials included in the application can be > > extracted". This should really be normative language. Some of what I > > am looking for can be found in section 2.3 but it isn't clear to me > > that it covers the definition of the profiles. > > Please suggest text. > > > 2.3.1 Client Password > > > > There is also some confusion here about what the client must implement > > and what the server must implement wrt the use of client_id. I read > > the text as trying to say that Servers SHOULD support both and clients > > SHOULD only do Basic. > > We could not reach consensus beyond this. This language was carefully > crafted to work around the disagreements about what is required and what > is not. > > > This section also seems to have been the product of a partial > > s/password/credential/g operation. Either OAUTH is only meant to use > > Basic and passwords or we want to cover all/most HTTP authentication > > methods and credentials and then section 2.3.2 (which feels like an > > afterthought) needs to get folded into 2.3.1 and the normative > > language (and examples!) need some work to cover at least X.509s and > > perhaps even Negotiate. > > When we say password we mean 'plain old password'. Any other types of > credentials are not covered by design. > > > Personally I would try to fold 2.3.1 and 2.3.2 into one section and > > say that servers MUST support Basic and client_id+client_password. > > Servers MAY support any HTTP authentication method with a mapping to > client_id. > > If a client supports username+passwords it SHOULD do Basic and if it > > supports other HTTP authentication methods it MUST NOT use > > client_password for anything and MUST follow normal HTTP > > authentication method negotiation. > > > > Finally, everywhere there is negotiation there must imho be some > > mention/discussion/protection of downgrade attacks. > > Downgrade attacks security section sounds useful. Text? > > > 3.1 Authorization Endpoints > > > > 6th paragraph: "The authorization server SHOULD ignore unrecognized > > request parameters". This formulation returns in several places in the > > document and I don't understand why it isn't a MUST - after all > > doesn't extensibility depend on this? > > I don't have an objection, but extensibility isn't currently required. > > > 3.1.1 Response Type > > > > The response_type parameter is REQURED but its absence SHOULD result > > in an error. Why not MUST? > > This is an OAuth 1.0 legacy of not mandating a particular error behavior. > MUST seems like the right language - any objections? > > > 3.1.2 Redirection Endpoint > > > > There should be a clear normative specification for how to match > endpoints. > > There are traces of this in various parts of the document when > > matching is discussed. I recommend making a concise definition in one > > place (namely > > here) and referencing this throughout. Since this comparison has > > security implications it should be a priority for the specification to = be air- > tight. > > This has been discussed by the WG and no consensus was reached. We can > reconsider if someone submits proposed text. > > > 3.1.2.2 Registration Requirements > > > > "(the client MAY use the state request parameter to achieve > > per-request customization)". Doesn't this overload its use for CSRF- > protection? > > Yep. That's intentional. > > > 3.1.2.4 Invalid Endpoint > > > > "The authorization server SHOULD NOT redirect...". Why isn't this a > > MUST NOT? > > I'm ok with MUST NOT - any objections? > > > 3.1.2.5 Endpoint Content > > > > This section basically seems to say "Serve with server-side code not > > with html or client-side code". If this is the case then I suggest > > reformulate to say precisely that using normative language. > > > > The use of the word "script" could perhaps also be made less ambiguous > > since in this case it could refer to both server-side code aswell as > > in-browser code. > > This is only about the HTML response sent back to the user-agent. This is > about including something like 'Share on Twitter/Facebook' widget on a pa= ge > with an access token in the URI fragment (which has caused tokens to leak= to > Twitter in some cases). > > > 3.2.1 Client Authentication > > > > The phrase "clients issued client credentials" could be rephrased to > > make less violence on English - perhaps "clients that have been issued > > with client credentials", unless that is not the intended meaning in > > which case I argue for something easier to understand ;-) > > Ok. > > > The second bullet: Using client credentials more often also exposes > > them more which might be worth mentioning aswell. > > Proposed text? > > > 4. Obtaining Authorization > > > > Perhaps not critical but the term 'password credentials' occurs in the > > first paragraph and this doesn't seem compatible with resource owner > > authentication being out of scope. It could just be that it should > > read 'resource owner credentials' but it could also signal an > > underlying assumption about username and password being used for > > resource owner authentication. In either case I thing its best to > > avoid the use of the word 'password' to avoid any confusion. > > Password is intentional. This is a special case for passwords. > > > 4.1 Authorization Code > > > > (C) - "using the redirection URI provided earlier" should perhaps read > > "using the redirection URI provided earlier or associated with the > > client in client registration" > > Changed to: > > Assuming the resource owner grants access, the authorizatio= n server > redirects the > user-agent back to the client using the redirection URI pro= vided earlier > (in the > request or during client registration). The redirection URI= includes an > authorization > code and any local state provided by the client earlier. > > > 4.1.1 and 4.1.2 Authorization Request/Authorization Response > > > > The redirect_uri is listed as OPTIONAL with a reference to 3.1.2 but > > there is no mention in 4.1.2 how to handle the case when the > > redirect_uri is not present. I believe the assumption is that the > > redirect_uri is either resent or part of client registration but that n= eeds to > be made explicit in that case. > > 3.1.2 describe how to handle this parameter. > > > This may apply to other uses of the redirect_uri parameter eg in 4.2.1. > > > > Furthermore in 4.2.2 "code" I suggest the following re-formulatation > > of the last sentence: "The client MUST NOT use an authorization code > > for more than one request. If an authorization code is re-used, the > > authorization server should treat that as a replay attack and SHOULD > > revoke all tokens associated with the client." (i.e loose the "attempt" > > bit which carries no real meaning) > > Changed to server MUST not allow reuse based on previous feedback. Not > sure treating it as an attack is the right language, but the normative la= nguage > is the same either way (about revoking tokens). > > > Also note that this is potentially a DOS attack should a single authz c= ode > leak. > > Explain? > > > 4.1.2.1 Error Response > > > > First paragraph, last sentence "and MUST NOT automatically redirect". > > In the light of how willing users normally are to click on links > > presented to them I would strengthen this to "MUST prevent the user > > from following the redirect URI" > > Not sure what you mean. > > > In the definition of the invalid_request parameter I don't understand > > how unsupported parameters can generate an error since endpoints > > should ignore unsupported parameters (in order to support extensibility= ). > > Good catch. Dropped 'unsupported parameter' part. > > > 4.1.3 Access Token Request > > > > "require client authentication for confidential clients or for any > > client issued client credentials (or with other authentication requirem= ents)" > > > > This text seems unnecessarily convoluted. Isn't enough to say that if > > you have issued credentials to a client you MUST require > > authentication from that client? This applies equally to the other > > sections where client authentication is an issue (eg 4.3.2). > > I felt it was important to call out confidential clients explicitly, but = I agree that > if we require issuing credentials to such clients, this can be made simpl= er. > What do other think? The same end result, but different emphasis. > > > Also cf my comment on 3.1.2 for the discussion of matching > > redirect_uri in the last bullet: ".. and that their values are > > identical". Is this really meant to mean identical? > > Here yes. String comparison. > > > 4.2 Implicit Grant > > > > The parenthesis "(it does not support the issuance of refresh tokens)" > > sounds like it should really be normative language, "refresh tokens > > MUST NOT be issues for implicit grant" because afaiu you could easily > > extend "fragment-transport" to include a refresh-token, so it isn't a > > technically motivated constraint, right? > > Instead I added this to 4.2.2: > > The authorization server MUST NOT issue a refresh token. > > > In (D) I would like to have a normative reference to a document that > > specifies browser behavior for URL fragments since this is a critical > > security dependency for this grant type. > > That's RFC2616. Seems odd to reference it here. > > > 4.4 Client Credentials > > > > I think the text should note that this model effectively implies that > > the client is able to impersonate all users which has the potential > > for worse security problems than if the client has access to individual= user > passwords. > > Worse how? You can't use this with resource owner password. > > > 6 Refreshing an Access Token > > > > scope - The term "lesser than" is intuitive but imprecise. I suggest > > "MUST NOT include any scope not originally granted by the resource > owner". > > Ok. > > > 7.1 and 8.1 Access Token Types > > > > The section 7.1 lists two definitions of access token types and > > provides a couple of examples but doesn't provide any constraints on > > future development of access tokens except in 8.1 where it is implied > > that not all access token types would be associated with HTTP > > authentication mechanisms. Are there really no constraints on access > > token types that should be captured? > > None suggested. > > > 10.6 Authorization Code Redirection URI Manipulation > > > > Suggest replace the word 'familiar' with 'trusted' in the first > > sentence of the second paragraph. The notion of trust opens up several > > boat loads of worm but it is the correct term here I think. > > Ok. > > > In the third paragraph "the same as" wrt redirection URIs occur and > > this needs to be defined (cf comments on 3.1.2 above). > > Changed to identical. > > > Finally "The authorization server MUST require public clients and > > SHOULD require confidential clients to register their redirection > > URI". I am missing a discussion of why the two types of client differ w= rt this > attack vector. > > Public clients rely on the registration to provide a minimal level of cli= ent > identification while confidential clients are later authenticated which c= an > mitigate redirection URI manipulation. > > > 10.10 Credentials Guessing Attack > > > > I found myself wanting implementation advice for how to generate good > > tokens at this point. This has been raised on the list too. The same > > goes for how to generate good CSRF cookies where the "(eg a hash of > > the session cookie..." feels like it is implementation advice yearning > > to come out of the closet. > > Need someone to suggest text. > > EHL > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Fri Jan 6 23:00:21 2012 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 AE0FE21F8493 for ; Fri, 6 Jan 2012 23:00:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.037, 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 ZPbajdTWb4E9 for ; Fri, 6 Jan 2012 23:00:19 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 757C621F848F for ; Fri, 6 Jan 2012 23:00:19 -0800 (PST) Received: (qmail 18946 invoked from network); 7 Jan 2012 07:00:19 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.47) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 7 Jan 2012 07:00:18 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT005.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Sat, 7 Jan 2012 00:00:17 -0700 From: Eran Hammer-Lahav To: OAuth WG Date: Sat, 7 Jan 2012 00:00:05 -0700 Thread-Topic: draft-ietf-oauth-v2: Doubt about chapter 4.2 Thread-Index: AczNCcrvh91EGUT+SiKWZiGBaG8kvQ== Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453A72D0C2C@P3PW5EX1MB01.EX1.SECURESERVER.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_90C41DD21FB7C64BB94121FBBC2E723453A72D0C2CP3PW5EX1MB01E_" MIME-Version: 1.0 Cc: DIEGO GONZALEZ MARTINEZ Subject: [OAUTH-WG] FW: draft-ietf-oauth-v2: Doubt about chapter 4.2 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, 07 Jan 2012 07:00:21 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723453A72D0C2CP3PW5EX1MB01E_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sending to the right place. EHL From: DIEGO GONZALEZ MARTINEZ [mailto:diegog@tid.es] Sent: Friday, October 07, 2011 1:35 AM To: draft-ietf-oauth-v2@tools.ietf.org Subject: draft-ietf-oauth-v2: Doubt about chapter 4.2 Hello, My name is Diego Gonz=E1lez, I work in Telef=F3nica R&D and I'm following O= Auth 2.0 works as we're using OAuth in Telef=F3nica's APIs exposure program= s (e.g.: BlueVia). I as well participate in OMA activities for using OAuth = to access OMA standard APIs. I'm Reading through OAuth 2.0 draft and I have a doubt. In chapter 4.2.1 for Implicit Grant I can see the following example: GET /authorize?response_type=3Dtoken&client_id=3Ds6BhdRkqt3&state=3Dxyz &redirect_uri=3Dhttps%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1 Host: server.example.com Then in chapter 4.2.2 I see the following example: HTTP/1.1 302 Found Location: http://example.com/rd#access_token=3D2YotnFZFEjr1zCsicMWpAA &state=3Dxyz&token_type=3Dexample&expires_in=3D3600 The first I thought is that this is just a misalignment within examples and= second example should look like https://client.example.com/cb. Is it? But then I got the following doubt. Would it make sense for every Client to= be redirected to a known web hosted by the resource provider? I mean a set= of clients trying to gain access to a Resource, and being always redirecte= d to the same web-hosted resource offered by resource provider, not to the = web-client hosted resource. E.g.: redirect every client using Implicit Grant to https://server.com/acce= ssTokenScriptisHereforEveryOne, no matter what the redirect_uri was. Do you think this make sense? Or there are some security problems I am not = taking into account. Kind regards, Diego Diego Gonz=E1lez Mart=EDnez Telef=F3nica Investigaci=F3n y Desarrollo Iniciativa NeoSDP e-mail: diegog@tid.es Phone: +34 983 36 75 97 ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at. http://www.tid.es/ES/PAGINAS/disclaimer.aspx --_000_90C41DD21FB7C64BB94121FBBC2E723453A72D0C2CP3PW5EX1MB01E_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Sending to the right place.

 

EHL

 

 

From: DIEGO GONZALEZ MARTINEZ [mai= lto:diegog@tid.es]
Sent: Friday, October 07, 2011 1:35 AM
= To: draft-ietf-oauth-v2@tools.ietf.org
Subject: draft-ietf-oa= uth-v2: Doubt about chapter 4.2

 

Hello,

My name is Diego Gonz=E1lez, I work in Telef=F3nica R= &D and I’m following OAuth 2.0 works as we’re using OAuth i= n Telef=F3nica’s APIs exposure programs (e.g.: BlueVia). I as well pa= rticipate in OMA activities for using OAuth to access OMA standard APIs.

I’m Reading through OAuth 2.0 draft = and I have a doubt.

 

In chapter 4.2.1 for Implicit Grant I can see the fol= lowing example:

GET /authorize?response_type=3Dtoken&client_id=3Ds6BhdRkqt3&= state=3Dxyz

        &redirect_uri=3Dhttps%3A%2F%2Fclient%2= Eexample%2Ecom%2Fcb HTTP/1.1

    Host: server.example.c= om

 

Then in chapter 4.2.2 I see the following example:<= /p>

HTTP/1.1 302 Found
 &nbs=
p;   Location: http://example.com/rd#access_token=3D2YotnFZFEjr1zCsicMWpAA
        &=
nbsp;      &state=3Dxyz&token_type=3Dexamp=
le&expires_in=3D3600

&= nbsp;

 

The first I thought is that this is just a misalignment within examples = and second example should look like https://client.example.com/cb. Is it?

 

But then I got the following= doubt. Would it make sense for every Client to be redirected to a known we= b hosted by the resource provider? I mean a set of clients trying to gain a= ccess to a Resource, and being always redirected to the same web-hosted res= ource offered by resource provider, not to the web-client hosted resource.<= o:p>

E.g.: redirect every client using Implic= it Grant to https://server.com/accessTokenScriptisHereforEveryOne, no matter wha= t the redirect_uri was.

Do you think thi= s make sense? Or there are some security problems I am not taking into acco= unt.

 

Kind regards,

    = Diego

 

 

 

Diego Gonz=E1lez M= art=EDnez
Telef=F3nica Investigaci=F3n= y Desarrollo
Iniciativa NeoSDP
e-mail: diegog@tid.e= s
Phone: +34 983 36 75 97<= /span>

 =

 

Este = mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra= pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enlace s= ituado m=E1s abajo.
This message is intended exclusively for its address= ee. We only send and receive email on the basis of the terms set out at.http://www.tid.es= /ES/PAGINAS/disclaimer.aspx

= --_000_90C41DD21FB7C64BB94121FBBC2E723453A72D0C2CP3PW5EX1MB01E_-- From wmills@yahoo-inc.com Fri Jan 6 23:22:23 2012 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 C17E621F8516 for ; Fri, 6 Jan 2012 23:22:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.266 X-Spam-Level: X-Spam-Status: No, score=-17.266 tagged_above=-999 required=5 tests=[AWL=0.332, 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 wvkEy8SMQ8ee for ; Fri, 6 Jan 2012 23:22:21 -0800 (PST) Received: from nm1.bullet.mail.sp2.yahoo.com (nm1.bullet.mail.sp2.yahoo.com [98.139.91.71]) by ietfa.amsl.com (Postfix) with SMTP id 289D121F850F for ; Fri, 6 Jan 2012 23:22:20 -0800 (PST) Received: from [98.139.91.65] by nm1.bullet.mail.sp2.yahoo.com with NNFMP; 07 Jan 2012 07:22:13 -0000 Received: from [98.139.91.31] by tm5.bullet.mail.sp2.yahoo.com with NNFMP; 07 Jan 2012 07:22:13 -0000 Received: from [127.0.0.1] by omp1031.mail.sp2.yahoo.com with NNFMP; 07 Jan 2012 07:22:13 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 940096.26433.bm@omp1031.mail.sp2.yahoo.com Received: (qmail 46217 invoked by uid 60001); 7 Jan 2012 07:22:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1325920933; bh=V55S2marW7ULWcP5dT4seUFjGy8xy7lj3BQN738r6Y0=; 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=mmeM8nIytk2VZZ8AWkLu/B7xeFMqzogomgHOxsH+aJEClFXciSvEmCACpHjADekt2F+RO6lZrLI9qqAuLKWgD/i/KQlal4c/T0ZgzSQmpl24SLoGJNExM3bL7oPXDT8bWZUvNzAnbK1x/J7sE7Id9S3bdcHEDTecQFhcp/IXuVY= 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=GSB+gJqsvhvQaRMUrLzVQhWFwNDJOMOxmePQ7ER4bye0OXYRhbUa1gZI/eURit6DH8D1IZyiO6b9EJaBmk5lDHhI0vBNx/5OXyLjhxDZErDFaes053toUh5gwOYpBVW5mWaAQUZIYLLYdmwwzQ0FE0Rey/2OC0W3qk1fhAOxyuk=; X-YMail-OSG: UjEEK98VM1kvqLg3a_wwxiqb3dzHI7DYFGR4H7WikgWSZrS aArOLhZbHt06i5FxWvXN4Q86Cfcn0Ly9mU2fiOL7Tsa_rkH8u2cMQ02Q3W78 LwPZLZRqysTOqcGPwNaNl6qWDUp0sw0Zbf8fBu8AflLkncnFvb8t04w30QQG B.xpmXCfci._s7JvOW2wCkC3TcWKdiz8LVoUGiCz7Ru8gl7uK8KwqY01Oa_s lG68Uwe3mUH4fiZDhxjpCxuNrO1xuMuek5s8z2yxPMPsKHPUOa.PqUT7GNny qLvsMuob9L3ri1svN9WUVWV4UXxszwnjYhjMwJEq9gls7jqlB8vY4CIs4cuL i0vSsPzEsJbGyF1J6Y3hViMweg1_3p1gu3ERAKcah.j6Qgb2X9TemeJV_09r II7kpV_kWDf_97XGs6hy.Q529xQ-- Received: from [209.131.62.115] by web31804.mail.mud.yahoo.com via HTTP; Fri, 06 Jan 2012 23:22:13 PST X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.116.331537 References: <4E6E4FEA.7090100@sunet.se> <90C41DD21FB7C64BB94121FBBC2E72345213D92D5A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723453A72D0C2B@P3PW5EX1MB01.EX1.SECURESERVER.NET> Message-ID: <1325920933.19255.YahooMailNeo@web31804.mail.mud.yahoo.com> Date: Fri, 6 Jan 2012 23:22:13 -0800 (PST) From: William Mills To: Eran Hammer-Lahav , "eran@sled.com" , Leif Johansson , OAuth WG In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453A72D0C2B@P3PW5EX1MB01.EX1.SECURESERVER.NET> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="835683298-1501530307-1325920933=:19255" Subject: Re: [OAUTH-WG] secdir review of draft-ietf-oauth-v2 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, 07 Jan 2012 07:22:23 -0000 --835683298-1501530307-1325920933=:19255 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I think the only thing there I'd say might still want to get done is:=0A=0A= > > 10.10 Credentials Guessing Attack=0A> >=0A> > I found myself wanting im= plementation advice for how to generate good=0A> > tokens at this point. Th= is has been raised on the list too. The same=0A> > goes for how to generate= good CSRF cookies where the "(eg a hash of=0A> > the session cookie..." fe= els like it is implementation advice yearning=0A> > to come out of the clos= et.=0A>=0A> Need someone to suggest text.=0A=0ADidn't we get CSRF text in t= here?=0A=0A=0A=0A________________________________=0A From: Eran Hammer-Laha= v =0ATo: "eran@sled.com" ; Leif Johanss= on ; OAuth WG =0ASent: Friday, January 6, = 2012 10:57 PM=0ASubject: Re: [OAUTH-WG] secdir review of draft-ietf-oauth-v= 2=0A =0AI have not seen any follow up to the open issues and will be closin= g them on my editor's list. This doesn't mean they are closed, just that I = will not be addressing them without someone raising them again on the list.= Since none of them are in the tracker, this email is the only record I kno= w of listing them (and their status/response).=0A=0AEHL=0A=0A> -----Origina= l Message-----=0A> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.= org] On Behalf=0A> Of Eran Hammer-Lahav=0A> Sent: Tuesday, September 20, 20= 11 3:13 PM=0A> To: Leif Johansson; OAuth WG=0A> Subject: Re: [OAUTH-WG] sec= dir review of draft-ietf-oauth-v2=0A>=0A> (+OAuth WG, -everyone else)=0A>= =0A> Thanks Leif.=0A>=0A> See comments inline. Whatever issues are still op= en will be addressed along=0A> with the rest of the IETF LC feedback.=0A>= =0A> EHL=0A>=0A>=0A> > -----Original Message-----=0A> > From: Leif Johansso= n [mailto:leifj@sunet.se]=0A> > Sent: Monday, September 12, 2011 11:31 AM= =0A>=0A> > ** General observations:=0A> >=0A> > POST and/or GET=0A> >=0A> >= Examples are sometimes POST and sometimes GET. In many cases it is not=0A>= > clear to me from the surrounding text if both POST and GET are allowed= =0A> > or if only one is mandated. Illustrating with both a GET _and_ POST= =0A> > example in the cases where both are supported would help or make the= =0A> > method explicit in the text before the example.=0A> >=0A> > The P-wo= rd=0A> >=0A> > The term 'password' is sprinkled throughout the document, so= metimes as=0A> > in "client password" or "resource owner password credentia= ls" and I=0A> > suspect that sometimes it is password as in 'an example of = a=0A> > credential type' and in other cases it is password as in 'plain old= =0A> > password'. This needs to be cleared up throughout (I've included som= e=0A> examples below).=0A> >=0A> > Normative Language=0A> >=0A> > I've ofte= n found myself wanting more normative language often to=0A> > replace exist= ing but less precise text. I've called out some important cases=0A> below.= =0A> >=0A> > Unknown parameters=0A> >=0A> > The sentence "The client SHOULD= ignore unrecognized response=0A> > parameters"=0A> > occurs in several pla= ces. First of all I would argue that this has to=0A> > be a MUST if you wan= t to be able to guarantee extensibility. Secondly=0A> > there are some erro= r responses that are triggered by unsupported=0A> > request parameters. Thi= s seems like an inconsistency.=0A> >=0A> > ** Specifics=0A> >=0A> > 1.1 Rol= es=0A> >=0A> > Forward references to the sections where the roles are defin= ed would=0A> > improve readability.=0A>=0A> What sections? That's the only = place these roles are defined.=0A>=0A> > As an illustration of an alternati= ve model for the authorization=0A> > server maybe an informative reference = to UMA would be illustrative here.=0A>=0A> A reference to UMA would be conf= using in this document.=0A>=0A> > 1.2 Protocol Flow=0A> >=0A> > (A) talks a= bout 'an intermediary such as an authorization server.' it=0A> > isn't clea= r it me if this refers to a separate authorization server or=0A> > if it is= the same authorization server that is referenced in (B).=0A>=0A> Changed t= o:=0A>=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 (A) The client requests authorizatio= n from the resource owner. The=0A> authorization request=0A>=A0 =A0 =A0 =A0= =A0 =A0 =A0 can be made directly to the resource owner (as shown), or pre= ferably=0A> indirectly via=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 the authorizatio= n server as an intermediary.=0A>=0A> > 1.3.3 Resource Owner Password Creden= tials=0A> >=0A> > When I first read this I thought - why not talk about Res= ource Owner=0A> > Credentials - in fact there is a parenthesis there "(e.g = a username=0A> > and password)" that seems to indicate that other credentia= ls could be=0A> supported.=0A> >=0A> > This needs to be cleared up. Either = its username and password and=0A> > nothing else or there is a way to suppo= rt things like Negotiate or=0A> > X.509-based credentials in which case it = should really be Resource=0A> > Owner Credentials with no reference to pass= words other than as as an=0A> > example of one possible credential type.=0A= >=0A> Changed to:=0A>=0A>=A0 =A0 =A0 =A0 (i.e. username and password)=0A>= =0A> This is explicitly just for username and password. Other types require= an=0A> extension.=0A>=0A> > 1.4 Access Token=0A> >=0A> > first paragraph: = "The string is usually opaque". This should be=0A> > reformulated as normat= ive language. In fact I would have liked=0A> > guidance on generating those= tokens (which has been brought up on the=0A> > list) possibly as part of a= n implementation-guide.=0A>=0A> There is not requirement for the string to = be opaque, but the general=0A> architecture assumes it is. Otherwise, pleas= e suggest language.=0A>=0A> > 1.5 Refresh Token=0A> >=0A> > Why is the refr= esh token not simply treated as an access token for the=0A> > access token = resource in the authorization server? This would seem to=0A> > simplify the= model a bit by removing a type of token whose semantic=0A> > (at least to = this=0A> > reviewer) is a duplication of a normal access token for a partic= ular=0A> > type of resource.=0A>=0A> Simpler architecture but probably more= confusing to many developers.=0A>=0A> > Also in the first paragraph: "(acc= ess tokens may have a shorter=0A> > lifetime and fewer permissions". Why no= t try to write normative=0A> > language here - there are security implicati= ons of allowing a refresh=0A> > token to get more permissions=0A> > (say) t= han the original access token.=0A>=0A> This was discussed before and we cou= ld not reach consensus.=0A>=0A> > 2.1 Client types=0A> >=0A> > I find the t= erminology public/confidential somewhat counter-intuitive.=0A> > An app you= have on your personal device is 'public' while a shared=0A> > cloud servic= e is 'confidential'...hmm...=0A>=0A> These are the best terms we could come= up with. Not intuitive but well=0A> defined.=0A>=0A> > This section also l= acks normative language which isn't good. There=0A> > should be language de= fining the behavior of public and confidential=0A> > client aswell as the t= hree profiles.=0A> >=0A> > For instance under native application we have "I= t is assumed that any=0A> > client authentication credentials included in t= he application can be=0A> > extracted". This should really be normative lan= guage. Some of what I=0A> > am looking for can be found in section 2.3 but = it isn't clear to me=0A> > that it covers the definition of the profiles.= =0A>=0A> Please suggest text.=0A>=0A> > 2.3.1 Client Password=0A> >=0A> > T= here is also some confusion here about what the client must implement=0A> >= and what the server must implement wrt the use of client_id. I read=0A> > = the text as trying to say that Servers SHOULD support both and clients=0A> = > SHOULD only do Basic.=0A>=0A> We could not reach consensus beyond this. T= his language was carefully=0A> crafted to work around the disagreements abo= ut what is required and what=0A> is not.=0A>=0A> > This section also seems = to have been the product of a partial=0A> > s/password/credential/g operati= on. Either OAUTH is only meant to use=0A> > Basic and passwords or we want = to cover all/most HTTP authentication=0A> > methods and credentials and the= n section 2.3.2 (which feels like an=0A> > afterthought) needs to get folde= d into 2.3.1 and the normative=0A> > language (and examples!) need some wor= k to cover at least X.509s and=0A> > perhaps even Negotiate.=0A>=0A> When w= e say password we mean 'plain old password'. Any other types of=0A> credent= ials are not covered by design.=0A>=0A> > Personally I would try to fold 2.= 3.1 and 2.3.2 into one section and=0A> > say that servers MUST support Basi= c and client_id+client_password.=0A> > Servers MAY support any HTTP authent= ication method with a mapping to=0A> client_id.=0A> > If a client supports = username+passwords it SHOULD do Basic and if it=0A> > supports other HTTP a= uthentication methods it MUST NOT use=0A> > client_password for anything an= d MUST follow normal HTTP=0A> > authentication method negotiation.=0A> >=0A= > > Finally, everywhere there is negotiation there must imho be some=0A> > = mention/discussion/protection of downgrade attacks.=0A>=0A> Downgrade attac= ks security section sounds useful. Text?=0A>=0A> > 3.1 Authorization Endpoi= nts=0A> >=0A> > 6th paragraph: "The authorization server SHOULD ignore unre= cognized=0A> > request parameters". This formulation returns in several pla= ces in the=0A> > document and I don't understand why it isn't a MUST - afte= r all=0A> > doesn't extensibility depend on this?=0A>=0A> I don't have an o= bjection, but extensibility isn't currently required.=0A>=0A> > 3.1.1 Respo= nse Type=0A> >=0A> > The response_type parameter is REQURED but its absence= SHOULD result=0A> > in an error. Why not MUST?=0A>=0A> This is an OAuth 1.= 0 legacy of not mandating a particular error behavior.=0A> MUST seems like = the right language - any objections?=0A>=0A> > 3.1.2 Redirection Endpoint= =0A> >=0A> > There should be a clear normative specification for how to=A0 = match=0A> endpoints.=0A> > There are traces of this in various parts of the= document when=0A> > matching is discussed. I recommend making a concise de= finition in one=0A> > place (namely=0A> > here) and referencing this throug= hout. Since this comparison has=0A> > security implications it should be a = priority for the specification to be air-=0A> tight.=0A>=0A> This has been = discussed by the WG and no consensus was reached. We can=0A> reconsider if = someone submits proposed text.=0A>=0A> > 3.1.2.2 Registration Requirements= =0A> >=0A> > "(the client MAY use the state request parameter to achieve=0A= > > per-request customization)". Doesn't this overload its use for CSRF-=0A= > protection?=0A>=0A> Yep. That's intentional.=0A>=0A> > 3.1.2.4 Invalid En= dpoint=0A> >=0A> > "The authorization server SHOULD NOT redirect...". Why i= sn't this a=0A> > MUST NOT?=0A>=0A> I'm ok with MUST NOT - any objections?= =0A>=0A> > 3.1.2.5 Endpoint Content=0A> >=0A> > This section basically seem= s to say "Serve with server-side code not=0A> > with html or client-side co= de". If this is the case then I suggest=0A> > reformulate to say precisely = that using normative language.=0A> >=0A> > The use of the word "script" cou= ld perhaps also be made less ambiguous=0A> > since in this case it could re= fer to both server-side code aswell as=0A> > in-browser code.=0A>=0A> This = is only about the HTML response sent back to the user-agent. This is=0A> ab= out including something like 'Share on Twitter/Facebook' widget on a page= =0A> with an access token in the URI fragment (which has caused tokens to l= eak to=0A> Twitter in some cases).=0A>=0A> > 3.2.1 Client Authentication=0A= > >=0A> > The phrase "clients issued client credentials" could be rephrased= to=0A> > make less violence on English - perhaps "clients that have been i= ssued=0A> > with client credentials", unless that is not the intended meani= ng in=0A> > which case I argue for something easier to understand ;-)=0A>= =0A> Ok.=0A>=0A> > The second bullet: Using client credentials more often a= lso exposes=0A> > them more which might be worth mentioning aswell.=0A>=0A>= Proposed text?=0A>=0A> > 4. Obtaining Authorization=0A> >=0A> > Perhaps no= t critical but the term 'password credentials' occurs in the=0A> > first pa= ragraph and this doesn't seem compatible with resource owner=0A> > authenti= cation being out of scope. It could just be that it should=0A> > read 'reso= urce owner credentials' but it could also signal an=0A> > underlying assump= tion about username and password being used for=0A> > resource owner authen= tication. In either case I thing its best to=0A> > avoid the use of the wor= d 'password' to avoid any confusion.=0A>=0A> Password is intentional. This = is a special case for passwords.=0A>=0A> > 4.1 Authorization Code=0A> >=0A>= > (C) - "using the redirection URI provided earlier" should perhaps read= =0A> > "using the redirection URI provided earlier or associated with the= =0A> > client in client registration"=0A>=0A> Changed to:=0A>=0A>=A0 =A0 = =A0 =A0 =A0 =A0 =A0 Assuming the resource owner grants access, the authori= zation server=0A> redirects the=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 user-agent = back to the client using the redirection URI provided earlier=0A> (in the= =0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 request or during client registration). Th= e redirection URI includes an=0A> authorization=0A>=A0 =A0 =A0 =A0 =A0 =A0 = =A0 code and any local state provided by the client earlier.=0A>=0A> > 4.1= .1 and 4.1.2 Authorization Request/Authorization Response=0A> >=0A> > The r= edirect_uri is listed as OPTIONAL with a reference to 3.1.2 but=0A> > there= is no mention in 4.1.2 how to handle the case when the=0A> > redirect_uri = is not present. I believe the assumption is that the=0A> > redirect_uri is = either resent or part of client registration but that needs to=0A> be made = explicit in that case.=0A>=0A> 3.1.2 describe how to handle this parameter.= =0A>=0A> > This may apply to other uses of the redirect_uri parameter eg in= 4.2.1.=0A> >=0A> > Furthermore in 4.2.2 "code" I suggest the following re-= formulatation=0A> > of the last sentence: "The client MUST NOT use an autho= rization code=0A> > for more than one request. If an authorization code is = re-used, the=0A> > authorization server should treat that as a replay attac= k and SHOULD=0A> > revoke all tokens associated with the client." (i.e loos= e the "attempt"=0A> > bit which carries no real meaning)=0A>=0A> Changed to= server MUST not allow reuse based on previous feedback. Not=0A> sure treat= ing it as an attack is the right language, but the normative language=0A> i= s the same either way (about revoking tokens).=0A>=0A> > Also note that thi= s is potentially a DOS attack should a single authz code=0A> leak.=0A>=0A> = Explain?=0A>=0A> > 4.1.2.1 Error Response=0A> >=0A> > First paragraph, last= sentence "and MUST NOT automatically redirect".=0A> > In the light of how = willing users normally are to click on links=0A> > presented to them I woul= d strengthen this to "MUST prevent the user=0A> > from following the redire= ct URI"=0A>=0A> Not sure what you mean.=0A>=0A> > In the definition of the = invalid_request parameter I don't understand=0A> > how unsupported paramete= rs can generate an error since endpoints=0A> > should ignore unsupported pa= rameters (in order to support extensibility).=0A>=0A> Good catch. Dropped '= unsupported parameter' part.=0A>=0A> > 4.1.3 Access Token Request=0A> >=0A>= > "require client authentication for confidential clients or for any=0A> >= client issued client credentials (or with other authentication requirement= s)"=0A> >=0A> > This text seems unnecessarily convoluted. Isn't enough to s= ay that if=0A> > you have issued credentials to a client you MUST require= =0A> > authentication from that client? This applies equally to the other= =0A> > sections where client authentication is an issue (eg 4.3.2).=0A>=0A>= I felt it was important to call out confidential clients explicitly, but I= agree that=0A> if we require issuing credentials to such clients, this can= be made simpler.=0A> What do other think? The same end result, but differe= nt emphasis.=0A>=0A> > Also cf my comment on 3.1.2 for the discussion of ma= tching=0A> > redirect_uri in the last bullet: ".. and that their values are= =0A> > identical". Is this really meant to mean identical?=0A>=0A> Here yes= . String comparison.=0A>=0A> > 4.2 Implicit Grant=0A> >=0A> > The parenthes= is "(it does not support the issuance of refresh tokens)"=0A> > sounds like= it should really be normative language, "refresh tokens=0A> > MUST NOT be = issues for implicit grant" because afaiu you could easily=0A> > extend "fra= gment-transport" to include a refresh-token, so it isn't a=0A> > technicall= y motivated constraint, right?=0A>=0A> Instead I added this to 4.2.2:=0A>= =0A>=A0 =A0 =A0 =A0 =A0 =A0 The authorization server MUST NOT issue a refr= esh token.=0A>=0A> > In (D) I would like to have a normative reference to a= document that=0A> > specifies browser behavior for URL fragments since thi= s is a critical=0A> > security dependency for this grant type.=0A>=0A> That= 's RFC2616. Seems odd to reference it here.=0A>=0A> > 4.4 Client Credential= s=0A> >=0A> > I think the text should note that this model effectively impl= ies that=0A> > the client is able to impersonate all users which has the po= tential=0A> > for worse security problems than if the client has access to = individual user=0A> passwords.=0A>=0A> Worse how? You can't use this with r= esource owner password.=0A>=0A> > 6 Refreshing an Access Token=0A> >=0A> > = scope - The term "lesser than" is intuitive but imprecise. I suggest=0A> > = "MUST NOT include any scope not originally granted by the resource=0A> owne= r".=0A>=0A> Ok.=0A>=0A> > 7.1 and 8.1 Access Token Types=0A> >=0A> > The se= ction 7.1 lists two definitions of access token types and=0A> > provides a = couple of examples but doesn't provide any constraints on=0A> > future deve= lopment of access tokens except in 8.1 where it is implied=0A> > that not a= ll access token types would be associated with HTTP=0A> > authentication me= chanisms. Are there really no constraints on access=0A> > token types that = should be captured?=0A>=0A> None suggested.=0A>=0A> > 10.6 Authorization Co= de Redirection URI Manipulation=0A> >=0A> > Suggest replace the word 'famil= iar' with 'trusted' in the first=0A> > sentence of the second paragraph. Th= e notion of trust opens up several=0A> > boat loads of worm but it is the c= orrect term here I think.=0A>=0A> Ok.=0A>=0A> > In the third paragraph "the= same as" wrt redirection URIs occur and=0A> > this needs to be defined (cf= comments on 3.1.2 above).=0A>=0A> Changed to identical.=0A>=0A> > Finally = "The authorization server MUST require public clients and=0A> > SHOULD requ= ire confidential clients to register their redirection=0A> > URI". I am mis= sing a discussion of why the two types of client differ wrt this=0A> attack= vector.=0A>=0A> Public clients rely on the registration to provide a minim= al level of client=0A> identification while confidential clients are later = authenticated which can=0A> mitigate redirection URI manipulation.=0A>=0A> = > 10.10 Credentials Guessing Attack=0A> >=0A> > I found myself wanting impl= ementation advice for how to generate good=0A> > tokens at this point. This= has been raised on the list too. The same=0A> > goes for how to generate g= ood CSRF cookies where the "(eg a hash of=0A> > the session cookie..." feel= s like it is implementation advice yearning=0A> > to come out of the closet= .=0A>=0A> Need someone to suggest text.=0A>=0A> EHL=0A>=0A> _______________= ________________________________=0A> OAuth mailing list=0A> OAuth@ietf.org= =0A> https://www.ietf.org/mailman/listinfo/oauth=0A________________________= _______________________=0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps://www= .ietf.org/mailman/listinfo/oauth --835683298-1501530307-1325920933=:19255 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I think the only thing there I'd say might still want to get done is:

> > 10.10 Credentials Guess= ing Attack
> >
> > I found myself wanting implementation = advice for how to generate good
> > tokens at this point. This has= been raised on the list too. The same
> > goes for how to generat= e good CSRF cookies where the "(eg a hash of
> > the session cooki= e..." feels like it is implementation advice yearning
> > to come = out of the closet.
>
> Need someone to suggest text.
=
Didn't we get CSRF text in there?

=
From: Eran H= ammer-Lahav <eran@hueniverse.com>
To: "eran@sled.com" <eran@sled.com>; Leif Johansson= <leifj@sunet.se>; OAuth WG <oauth@ietf.org>
Sent: Friday, January 6, 2012 10:57 PM<= br> Subject: Re: [OAUTH-WG= ] secdir review of draft-ietf-oauth-v2
=0AI have not seen a= ny follow up to the open issues and will be closing them on my editor's lis= t. This doesn't mean they are closed, just that I will not be addressing th= em without someone raising them again on the list. Since none of them are i= n the tracker, this email is the only record I know of listing them (and th= eir status/response).

EHL

> -----Original Message-----
= > From: oauth-bounces@ietf.org [mailto:oauth-bounc= es@ietf.org] On Behalf
> Of Eran Hammer-Lahav
> Sent: Tuesd= ay, September 20, 2011 3:13 PM
> To: Leif Johansson; OAuth WG
>= Subject: Re: [OAUTH-WG] secdir review of draft-ietf-oauth-v2
>
&g= t; (+OAuth WG, -everyone else)
>
> Thanks Leif.
>
>= See comments inline. Whatever issues are still open will be addressed along
> with the rest of the IETF LC feedback.
><= br>> EHL
>
>
> > -----Original Message-----
>= > From: Leif Johansson [mailto:leifj@sunet.se]
> > Sent: Monday, = September 12, 2011 11:31 AM
>
> > ** General observations:> >
> > POST and/or GET
> >
> > Examples= are sometimes POST and sometimes GET. In many cases it is not
> >= clear to me from the surrounding text if both POST and GET are allowed
= > > or if only one is mandated. Illustrating with both a GET _and_ PO= ST
> > example in the cases where both are supported would help or= make the
> > method explicit in the text before the example.
&= gt; >
> > The P-word
> >
> > The term 'passwo= rd' is sprinkled throughout the document, sometimes as
> > in "client password" or "resource owner password credentials" and I
> &= gt; suspect that sometimes it is password as in 'an example of a
> &g= t; credential type' and in other cases it is password as in 'plain old
&= gt; > password'. This needs to be cleared up throughout (I've included s= ome
> examples below).
> >
> > Normative Language> >
> > I've often found myself wanting more normative lan= guage often to
> > replace existing but less precise text. I've ca= lled out some important cases
> below.
> >
> > Unkn= own parameters
> >
> > The sentence "The client SHOULD ig= nore unrecognized response
> > parameters"
> > occurs in = several places. First of all I would argue that this has to
> > be= a MUST if you want to be able to guarantee extensibility. Secondly
>= > there are some error responses that are triggered by unsupported
> > request parameters. This seems like an inconsiste= ncy.
> >
> > ** Specifics
> >
> > 1.1 R= oles
> >
> > Forward references to the sections where the= roles are defined would
> > improve readability.
>
> = What sections? That's the only place these roles are defined.
>
&g= t; > As an illustration of an alternative model for the authorization> > server maybe an informative reference to UMA would be illustrati= ve here.
>
> A reference to UMA would be confusing in this docu= ment.
>
> > 1.2 Protocol Flow
> >
> > (A) = talks about 'an intermediary such as an authorization server.' it
> &= gt; isn't clear it me if this refers to a separate authorization server or<= br>> > if it is the same authorization server that is referenced in (= B).
>
> Changed to:
>
>              (A) The client requests authorization from th= e resource owner. The
> authorization request
>    &n= bsp;         can be made directly to the resource owne= r (as shown), or preferably
> indirectly via
>    &nb= sp;         the authorization server as an intermediar= y.
>
> > 1.3.3 Resource Owner Password Credentials
> &= gt;
> > When I first read this I thought - why not talk about Reso= urce Owner
> > Credentials - in fact there is a parenthesis there = "(e.g a username
> > and password)" that seems to indicate that ot= her credentials could be
> supported.
> >
> > This = needs to be cleared up. Either its username and password and
> > n= othing else or there is a way to support things like Negotiate or
> &= gt; X.509-based credentials in which case it should really be Resource
> > Owner Credentials with no reference to passwords oth= er than as as an
> > example of one possible credential type.
&= gt;
> Changed to:
>
>        (i.e. u= sername and password)
>
> This is explicitly just for username = and password. Other types require an
> extension.
>
> >= ; 1.4 Access Token
> >
> > first paragraph: "The string i= s usually opaque". This should be
> > reformulated as normative la= nguage. In fact I would have liked
> > guidance on generating thos= e tokens (which has been brought up on the
> > list) possibly as p= art of an implementation-guide.
>
> There is not requirement fo= r the string to be opaque, but the general
> architecture assumes it = is. Otherwise, please suggest language.
>
> > 1.5 Refresh To= ken
> >
> > Why is the refresh token not simply treated as an access token for the
> > access token resource in t= he authorization server? This would seem to
> > simplify the model= a bit by removing a type of token whose semantic
> > (at least to= this
> > reviewer) is a duplication of a normal access token for = a particular
> > type of resource.
>
> Simpler archite= cture but probably more confusing to many developers.
>
> > = Also in the first paragraph: "(access tokens may have a shorter
> >= ; lifetime and fewer permissions". Why not try to write normative
> &= gt; language here - there are security implications of allowing a refresh> > token to get more permissions
> > (say) than the origi= nal access token.
>
> This was discussed before and we could no= t reach consensus.
>
> > 2.1 Client types
> >
&g= t; > I find the terminology public/confidential somewhat counter-intuitive.
> > An app you have on your personal device is= 'public' while a shared
> > cloud service is 'confidential'...hmm= ...
>
> These are the best terms we could come up with. Not int= uitive but well
> defined.
>
> > This section also lac= ks normative language which isn't good. There
> > should be langua= ge defining the behavior of public and confidential
> > client asw= ell as the three profiles.
> >
> > For instance under nat= ive application we have "It is assumed that any
> > client authent= ication credentials included in the application can be
> > extract= ed". This should really be normative language. Some of what I
> > = am looking for can be found in section 2.3 but it isn't clear to me
>= > that it covers the definition of the profiles.
>
> Please= suggest text.
>
> > 2.3.1 Client Password
> >
> > There is also some confusion here about what the client = must implement
> > and what the server must implement wrt the use = of client_id. I read
> > the text as trying to say that Servers SH= OULD support both and clients
> > SHOULD only do Basic.
>> We could not reach consensus beyond this. This language was carefully=
> crafted to work around the disagreements about what is required an= d what
> is not.
>
> > This section also seems to have= been the product of a partial
> > s/password/credential/g operati= on. Either OAUTH is only meant to use
> > Basic and passwords or w= e want to cover all/most HTTP authentication
> > methods and crede= ntials and then section 2.3.2 (which feels like an
> > afterthough= t) needs to get folded into 2.3.1 and the normative
> > language (= and examples!) need some work to cover at least X.509s and
> > perhaps even Negotiate.
>
> When we say password we mean = 'plain old password'. Any other types of
> credentials are not covere= d by design.
>
> > Personally I would try to fold 2.3.1 and = 2.3.2 into one section and
> > say that servers MUST support Basic= and client_id+client_password.
> > Servers MAY support any HTTP a= uthentication method with a mapping to
> client_id.
> > If a= client supports username+passwords it SHOULD do Basic and if it
> &g= t; supports other HTTP authentication methods it MUST NOT use
> > = client_password for anything and MUST follow normal HTTP
> > authe= ntication method negotiation.
> >
> > Finally, everywhere= there is negotiation there must imho be some
> > mention/discussi= on/protection of downgrade attacks.
>
> Downgrade attacks secur= ity section sounds useful. Text?
>
> > 3.1 Authorization Endpoints
> >
> > 6th paragraph: "The auth= orization server SHOULD ignore unrecognized
> > request parameters= ". This formulation returns in several places in the
> > document = and I don't understand why it isn't a MUST - after all
> > doesn't= extensibility depend on this?
>
> I don't have an objection, b= ut extensibility isn't currently required.
>
> > 3.1.1 Respo= nse Type
> >
> > The response_type parameter is REQURED b= ut its absence SHOULD result
> > in an error. Why not MUST?
>= ;
> This is an OAuth 1.0 legacy of not mandating a particular error b= ehavior.
> MUST seems like the right language - any objections?
&g= t;
> > 3.1.2 Redirection Endpoint
> >
> > There = should be a clear normative specification for how to  match
> en= dpoints.
> > There are traces of this in various parts of the document when
> > matching is discussed. I recommend making a= concise definition in one
> > place (namely
> > here) an= d referencing this throughout. Since this comparison has
> > secur= ity implications it should be a priority for the specification to be air-> tight.
>
> This has been discussed by the WG and no cons= ensus was reached. We can
> reconsider if someone submits proposed te= xt.
>
> > 3.1.2.2 Registration Requirements
> >
= > > "(the client MAY use the state request parameter to achieve
&g= t; > per-request customization)". Doesn't this overload its use for CSRF= -
> protection?
>
> Yep. That's intentional.
>
&= gt; > 3.1.2.4 Invalid Endpoint
> >
> > "The authorizat= ion server SHOULD NOT redirect...". Why isn't this a
> > MUST NOT?=
>
> I'm ok with MUST NOT - any objections?
>
> > 3.1.2.5 Endpoint Content
> >
= > > This section basically seems to say "Serve with server-side code = not
> > with html or client-side code". If this is the case then I= suggest
> > reformulate to say precisely that using normative lan= guage.
> >
> > The use of the word "script" could perhaps= also be made less ambiguous
> > since in this case it could refer= to both server-side code aswell as
> > in-browser code.
>> This is only about the HTML response sent back to the user-agent. Th= is is
> about including something like 'Share on Twitter/Facebook' wi= dget on a page
> with an access token in the URI fragment (which has = caused tokens to leak to
> Twitter in some cases).
>
> &g= t; 3.2.1 Client Authentication
> >
> > The phrase "client= s issued client credentials" could be rephrased to
> > make less violence on English - perhaps "clients that have been issued
> = > with client credentials", unless that is not the intended meaning in> > which case I argue for something easier to understand ;-)
&g= t;
> Ok.
>
> > The second bullet: Using client credent= ials more often also exposes
> > them more which might be worth me= ntioning aswell.
>
> Proposed text?
>
> > 4. Obt= aining Authorization
> >
> > Perhaps not critical but the= term 'password credentials' occurs in the
> > first paragraph and= this doesn't seem compatible with resource owner
> > authenticati= on being out of scope. It could just be that it should
> > read 'r= esource owner credentials' but it could also signal an
> > underly= ing assumption about username and password being used for
> > reso= urce owner authentication. In either case I thing its best to
> > avoid the use of the word 'password' to avoid any confusio= n.
>
> Password is intentional. This is a special case for pass= words.
>
> > 4.1 Authorization Code
> >
> >= ; (C) - "using the redirection URI provided earlier" should perhaps read> > "using the redirection URI provided earlier or associated with t= he
> > client in client registration"
>
> Changed to:<= br>>
>              Assuming t= he resource owner grants access, the authorization server
> redirects= the
>              user-agent ba= ck to the client using the redirection URI provided earlier
> (in the=
>              request or during= client registration). The redirection URI includes an
> authorizatio= n
>              code and any local state provided by the client earlier.
>
> > 4.1.1= and 4.1.2 Authorization Request/Authorization Response
> >
>= ; > The redirect_uri is listed as OPTIONAL with a reference to 3.1.2 but=
> > there is no mention in 4.1.2 how to handle the case when the<= br>> > redirect_uri is not present. I believe the assumption is that = the
> > redirect_uri is either resent or part of client registrati= on but that needs to
> be made explicit in that case.
>
>= 3.1.2 describe how to handle this parameter.
>
> > This may= apply to other uses of the redirect_uri parameter eg in 4.2.1.
> >= ;
> > Furthermore in 4.2.2 "code" I suggest the following re-formu= latation
> > of the last sentence: "The client MUST NOT use an aut= horization code
> > for more than one request. If an authorization= code is re-used, the
> > authorization server should treat that as a replay attack and SHOULD
> > revoke all tokens associat= ed with the client." (i.e loose the "attempt"
> > bit which carrie= s no real meaning)
>
> Changed to server MUST not allow reuse b= ased on previous feedback. Not
> sure treating it as an attack is the= right language, but the normative language
> is the same either way = (about revoking tokens).
>
> > Also note that this is potent= ially a DOS attack should a single authz code
> leak.
>
>= Explain?
>
> > 4.1.2.1 Error Response
> >
> = > First paragraph, last sentence "and MUST NOT automatically redirect".<= br>> > In the light of how willing users normally are to click on lin= ks
> > presented to them I would strengthen this to "MUST prevent = the user
> > from following the redirect URI"
>
> Not = sure what you mean.
>
> > In the definition of the invalid_request parameter I don't understand
> > how unsupported = parameters can generate an error since endpoints
> > should ignore= unsupported parameters (in order to support extensibility).
>
>= ; Good catch. Dropped 'unsupported parameter' part.
>
> > 4.= 1.3 Access Token Request
> >
> > "require client authenti= cation for confidential clients or for any
> > client issued clien= t credentials (or with other authentication requirements)"
> >
= > > This text seems unnecessarily convoluted. Isn't enough to say tha= t if
> > you have issued credentials to a client you MUST require<= br>> > authentication from that client? This applies equally to the o= ther
> > sections where client authentication is an issue (eg 4.3.= 2).
>
> I felt it was important to call out confidential client= s explicitly, but I agree that
> if we require issuing credentials to such clients, this can be made simpler.
> What do oth= er think? The same end result, but different emphasis.
>
> >= Also cf my comment on 3.1.2 for the discussion of matching
> > re= direct_uri in the last bullet: ".. and that their values are
> > i= dentical". Is this really meant to mean identical?
>
> Here yes= . String comparison.
>
> > 4.2 Implicit Grant
> >> > The parenthesis "(it does not support the issuance of refresh t= okens)"
> > sounds like it should really be normative language, "r= efresh tokens
> > MUST NOT be issues for implicit grant" because a= faiu you could easily
> > extend "fragment-transport" to include a= refresh-token, so it isn't a
> > technically motivated constraint= , right?
>
> Instead I added this to 4.2.2:
>
>&nbs= p;           The authorization server MUST NOT issue a refresh token.
>
> > In (D) I would like to hav= e a normative reference to a document that
> > specifies browser b= ehavior for URL fragments since this is a critical
> > security de= pendency for this grant type.
>
> That's RFC2616. Seems odd to = reference it here.
>
> > 4.4 Client Credentials
> >=
> > I think the text should note that this model effectively impl= ies that
> > the client is able to impersonate all users which has= the potential
> > for worse security problems than if the client = has access to individual user
> passwords.
>
> Worse how?= You can't use this with resource owner password.
>
> > 6 Re= freshing an Access Token
> >
> > scope - The term "lesser= than" is intuitive but imprecise. I suggest
> > "MUST NOT include= any scope not originally granted by the resource
> owner".
>
> Ok.
>
> > 7.1 and 8.1 Access Token = Types
> >
> > The section 7.1 lists two definitions of ac= cess token types and
> > provides a couple of examples but doesn't= provide any constraints on
> > future development of access token= s except in 8.1 where it is implied
> > that not all access token = types would be associated with HTTP
> > authentication mechanisms.= Are there really no constraints on access
> > token types that sh= ould be captured?
>
> None suggested.
>
> > 10.6= Authorization Code Redirection URI Manipulation
> >
> > = Suggest replace the word 'familiar' with 'trusted' in the first
> >= ; sentence of the second paragraph. The notion of trust opens up several> > boat loads of worm but it is the correct term here I think.
&= gt;
> Ok.
>
> > In the third paragraph "the same as" wrt redirection URIs occur and
> > this needs to be defi= ned (cf comments on 3.1.2 above).
>
> Changed to identical.
= >
> > Finally "The authorization server MUST require public cli= ents and
> > SHOULD require confidential clients to register their= redirection
> > URI". I am missing a discussion of why the two ty= pes of client differ wrt this
> attack vector.
>
> Public= clients rely on the registration to provide a minimal level of client
&= gt; identification while confidential clients are later authenticated which= can
> mitigate redirection URI manipulation.
>
> > 10= .10 Credentials Guessing Attack
> >
> > I found myself wa= nting implementation advice for how to generate good
> > tokens at= this point. This has been raised on the list too. The same
> > go= es for how to generate good CSRF cookies where the "(eg a hash of
> > the session cookie..." feels like it is implementation adv= ice yearning
> > to come out of the closet.
>
> Need s= omeone to suggest text.
>
> EHL
>
> _______________= ________________________________
> 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


=
--835683298-1501530307-1325920933=:19255-- From agksmehx@gmail.com Sun Jan 8 14:12:51 2012 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 7911621F852E for ; Sun, 8 Jan 2012 14:12:51 -0800 (PST) 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 K3FSsdAP-MD6 for ; Sun, 8 Jan 2012 14:12:51 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id DE9FF21F852D for ; Sun, 8 Jan 2012 14:12:50 -0800 (PST) Received: by yhpp56 with SMTP id p56so234692yhp.31 for ; Sun, 08 Jan 2012 14:12:50 -0800 (PST) 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=50MkcGwA/dSwwkI98NECvCoEFKJN8UhGGetSjy9lVbY=; b=S2i/WeGVBVAsB9lrtzvR0SBWgg2RIzzUTr2VpwXwoL3oDiAY7Q0Nja+u+cAfIIh6eD 9YVuuP0AiYcfbEEQJap+MIH2BggcHmjEDwhb44maquEX//etu+tG9FlcOViB9XRE6U5N uPDXnGkHOVH64Uy3GlRRYLWME+gxrXLJpVSH0= MIME-Version: 1.0 Received: by 10.236.131.45 with SMTP id l33mr3230075yhi.66.1326060770412; Sun, 08 Jan 2012 14:12:50 -0800 (PST) Received: by 10.236.110.140 with HTTP; Sun, 8 Jan 2012 14:12:50 -0800 (PST) Date: Sun, 8 Jan 2012 14:12:50 -0800 Message-ID: From: agks mehx To: oauth@ietf.org Content-Type: multipart/alternative; boundary=20cf301b65b12bc96004b60b950a Subject: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification 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, 08 Jan 2012 22:13:39 -0000 --20cf301b65b12bc96004b60b950a Content-Type: text/plain; charset=ISO-8859-1 My client implementation per latest draft did not work against a major vendor's server implementation. This was because the vendor REQUIRES the scope parameter in the initial request. If I do not supply the scope parameter, it calls back the URL with an error response stating that the request is invalid: error=invalid_request&error_description=Missing+required+parameter:+scope I reported this to the vendor and the vendor claims that the IETF draft specification says scope is OPTIONAL and that means the vendor is free to make it required in a conforming implementation. After a careful reading of the relevant sections of the draft specification, I do not believe that is what is the intent of the specification. It says "OPTIONAL" is to be interpreted per RFC2119, which in turn says: "an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.)" This leads me to believe that if I do not supply scope I should not get an error -- I may not be able to perform any API calls but I should get a token back that proves to me that the user was *some* user at the vendor. Could you please clarify or disambiguate? --20cf301b65b12bc96004b60b950a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable My client implementation per latest draft did not work against a major vend= or's server implementation.

This was because the ven= dor REQUIRES the scope parameter in the initial request. =A0If I do not sup= ply the scope parameter, it calls back the URL with an error response stati= ng that the request is invalid:

error=3Dinvalid_request&error_description=3DMissing= +required+parameter:+scope

I reported this to the = vendor and the vendor claims that the IETF draft specification says scope i= s OPTIONAL and that means the vendor is free to make it required in a confo= rming implementation.

After a careful reading of the relevant sections of the= draft specification, I do not believe that is what is the intent of the sp= ecification. =A0It says "OPTIONAL" is to be interpreted per RFC21= 19, which in turn says: "an implementation which does include a partic= ular option MUST be prepared to interoperate with another implementation wh= ich does not include the option (except, of course, for the feature the opt= ion provides.)"

This leads me to believe that if I do not supply scope = I should not get an error -- I may not be able to perform any API calls but= I should get a token back that proves to me that the user was *some* user = at the vendor.

Could you please clarify or disambiguate?
--20cf301b65b12bc96004b60b950a-- From andreas.solberg@uninett.no Mon Jan 9 00:43:19 2012 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 85AC921F8697 for ; Mon, 9 Jan 2012 00:43:19 -0800 (PST) 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.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 DM+AnpGFxMAK for ; Mon, 9 Jan 2012 00:43:18 -0800 (PST) Received: from epost.uninett.no (epost.uninett.no [IPv6:2001:700:0:526:158:38:180:100]) by ietfa.amsl.com (Postfix) with ESMTP id 6C00C21F856A for ; Mon, 9 Jan 2012 00:43:18 -0800 (PST) Received: from dmanso-11.uninett.no (dmanso-11.uninett.no [158.38.62.67]) by epost.uninett.no (Postfix) with ESMTPS id B1948336145 for ; Mon, 9 Jan 2012 09:43:17 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/signed; boundary="Apple-Mail=_6474D1F6-54A1-4585-9557-442305072ECA"; protocol="application/pkcs7-signature"; micalg=sha1 From: =?iso-8859-1?Q?Andreas_=C5kre_Solberg?= Resent-From: =?iso-8859-1?Q?Andreas_=C5kre_Solberg?= Date: Mon, 9 Jan 2012 09:41:21 +0100 Resent-Date: Mon, 9 Jan 2012 09:43:17 +0100 Resent-To: oauth@ietf.org Message-Id: <048EBD85-F1B7-436F-953F-3E22DEC44DE3@uninett.no> To: oauth@ietf.org X-Mailer: Apple Mail (2.1251.1) Resent-Message-Id: <20120109084317.B1948336145@epost.uninett.no> Subject: [OAUTH-WG] Detecting revoked token in OAuth 2.0 client libraries 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, 09 Jan 2012 08:43:19 -0000 --Apple-Mail=_6474D1F6-54A1-4585-9557-442305072ECA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, I'm trying to do an OAuth 2.0 library, and got a question: I cannot find a standardized way for an OAuth protected endpoint to = report to the client that the Token is not valid (expired or revoked). = As a library developer, I'd like to take away as much of possible of the = OAuth logic from the application. I need a way to distinguish = applicaiton specific protocol errors, from OAuth related errors on = protected endpoints. If the library could detect this, it could also in example do refresh = the token automatically, and even start a new flow if neccessary. I'm sorry if the answer is obvious.=20 Another question on token validity; the optional expires_in parameter. = If I would like to indicate permanent validity, how can I express that? = I assume that if I leave the parameter out it is not possible to = distinguish between 'undefined / not specified' and 'infitite'. Putting = the semanthics into a specific scope could off course work, but lack the = feature of beeing standardized between providers. Andreas= --Apple-Mail=_6474D1F6-54A1-4585-9557-442305072ECA Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOazCCBIow ggNyoAMCAQICECf06hH0eobEbp27bqkXBwcwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0Ux FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0 d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wNTA2MDcwODA5MTBa Fw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNh bHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0 dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0 aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmF pPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJk xIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2q L+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAs vIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMe oYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4HhMIHeMB8GA1UdIwQYMBaAFK29mHo0tCb3 +sQmVO8DveAky1QaMB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMC AQYwDwYDVR0TAQH/BAUwAwEB/zB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kb2Nh LmNvbS9BZGRUcnVzdEV4dGVybmFsQ0FSb290LmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21vZG8u bmV0L0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAZ2IkRbyis pgCi54fBm5AD236hEv0e8+LwAamUVEJrmgnEoG3XkJIEA2Z5Q3H8+G+v23ZF4jcaPd3kWQR4rBz0 g0bzes9bhHIt5UbBuhgRKfPLSXmHPLptBZ2kbWhPrXIUNqi5sf2/z3/wpGqUNVCPz4FtVbHdWTBK 322gnGQfSXzvNrv042n0+DmPWq1LhTq3Du3Tzw1EovsEv+QvcI4l+1pUBrPQxLxtjftzMizpm4Qk LdZ/kXpoAlAfDj9N6cz1u2fo3BwuO/xOzf4CjuOoEwqlJkRl6RDyTVKnrtw+ymsyXEFs/vVdoOr/ 0fqbhlhtPZZH5f4ulQTCAMyOofK7MIIE2jCCA8KgAwIBAgIQXf9Q6v4PU0aIn4BBj+dCyDANBgkq hkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExh a2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8v d3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBFbWFpbDAeFw0wOTA1MTgwMDAwMDBaFw0yODEyMzEyMzU5NTlaMEQxCzAJBgNV BAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExJDAiBgNVBAMTG1RFUkVOQSBlU2NpZW5jZSBQZXJzb25h bCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMS8JX3N71kEq3QnKbZjiu/ENXCh RgivblCbG3F4lwKFwDX/kBgRZvozORSepBL3Pe4FLIHn9y0uNnhDDjm2f3p0w8tVPy+zy8M3auGV AyMbsyKYE4NYMF+sPJFF020LLsvRkWGyynH6wokMewnWkr+jgRcRVSDfN4GfHiYJHdIXGUPLi5kl dEFb5jIq0KdT3NIhjc2Rz3ts9Mn+0OXSBmsaYUIbgJEH3BRJJzsKirLiO2kIhMuBmde6FB/YfpJj vfYtMfqVTs02DZnvEbqtSvuoxHi5fFo+yPUIMsCpBceMGiiPMLoXo/G54genuPtVv59iWtUUDwi0 E5nSEnla8P0CAwEAAaOCAVswggFXMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0G A1UdDgQWBBTIiXOZp11RFlNFVHyjwjl8y9eqgTAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgw BgEB/wIBADAmBgNVHSAEHzAdMA0GCysGAQQBsjEBAgIdMAwGCiqGSIb3TAUCAgUwWAYDVR0fBFEw TzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3QuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0 aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbwYIKwYBBQUHAQEEYzBhMDgGCCsGAQUFBzAChixodHRw Oi8vY3J0LnVzZXJ0cnVzdC5jb20vVVROQUFBQ2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0 cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG9w0BAQUFAAOCAQEACBekHPkVa7AZYW+gSON6 JO9BVZqgUHDYI9VThkpnjujaVhYYLBsYIYm6mCTuVjTjF4YmvSFa1BmTSuphdE22xISNR+7KLmVt NpOYseKSZojiTnt1x15EaSHcEmow/GGA/g/wndLcfq7lwlNNC3CDYVZF+z3fcvYCQnXriIqYV2D1 n6JySbF6PkFnNcNVKw0HNejGK9W6h3mAdOeSNr1GgXouKeJqvuEXEzV8FqQlMy9h7s7JUuBA29O+ OVrPz0wU5X/FQ1eLTblajsIPBk3eyEmdgXO65D+YpZM8WU7bmzXf/k2/VaHpZMNFfKyPfEfROvFO ddmQZ0DosS+eFy9cNTCCBPswggPjoAMCAQICEQCbXV9Tn+I7grzQTh0VEN6kMA0GCSqGSIb3DQEB BQUAMEQxCzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExJDAiBgNVBAMTG1RFUkVOQSBlU2Np ZW5jZSBQZXJzb25hbCBDQTAeFw0xMTA3MDUwMDAwMDBaFw0xMjA4MDMyMzU5NTlaMIGUMRMwEQYK CZImiZPyLGQBGRYDb3JnMRYwFAYKCZImiZPyLGQBGRYGdGVyZW5hMRMwEQYKCZImiZPyLGQBGRYD dGNzMQswCQYDVQQGEwJOTzEQMA4GA1UEChMHVU5JTkVUVDExMC8GA1UEAxQoQW5kcmVhcyBhYWty ZSBTb2xiZXJnIGFuZHJlYXNAdW5pbmV0dC5ubzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAL8ukoshERFAc4JLOA7WhazD4rpQPdboyAtCuynZUBW2s6NYPH6IuU25CcRldKJIzkBa9/A5 +rmD5r2Evsbdnt91VSU8FR9J73BMHPT7HywD4Y3Rv/h/kb6xkLCgoRAoCPlZDepR6TvUWH1PulII IlbtBMarsrfEUFGuntLIJQA5yH7WysiV0wHGygb+P1KiSDJd4/v3OBilAAg7zwRNJJ5ihmcW24Jx ZX3hQU9KV5ZXb2IxohUwTscYEGBPMoOPe62uQlj2MNiTYaXHX3QH4QZzD4v6MU5qxMSFXxdOfb09 lft3GF+c3PpybQ1T3GpKsSbEcA5FVSMb7HnC67V+5p8CAwEAAaOCAZUwggGRMB8GA1UdIwQYMBaA FMiJc5mnXVEWU0VUfKPCOXzL16qBMB0GA1UdDgQWBBQkb3UBIHXOvsZSkUyjDMTSzXPavDAOBgNV HQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIw JgYDVR0gBB8wHTANBgsrBgEEAbIxAQICHTAMBgoqhkiG90wFAgIFMEcGA1UdHwRAMD4wPKA6oDiG Nmh0dHA6Ly9jcmwudGNzLnRlcmVuYS5vcmcvVEVSRU5BZVNjaWVuY2VQZXJzb25hbENBLmNybDB6 BggrBgEFBQcBAQRuMGwwQgYIKwYBBQUHMAKGNmh0dHA6Ly9jcnQudGNzLnRlcmVuYS5vcmcvVEVS RU5BZVNjaWVuY2VQZXJzb25hbENBLmNydDAmBggrBgEFBQcwAYYaaHR0cDovL29jc3AudGNzLnRl cmVuYS5vcmcwJQYDVR0RBB4wHIEaYW5kcmVhcy5zb2xiZXJnQHVuaW5ldHQubm8wDQYJKoZIhvcN AQEFBQADggEBAKLxPqSWPfTshbrMWi2qGgUW9eXsVU5Lq31WSJfqN79TVyi4ipHSPE4uKFZOe7ZK AehMM+XNgk59nxpkcPmvksNsY98dk78NyH4dgybY5NLurWptkFbP9npcvBeneb3MEQXDLXfc0MuX daES6X3bxwhqe1nXKsyTFtIe8FBETf6Y+DSfaYY69rL0Vl6yJiDnz5ZYLoXOAr5xZtTbqx/yP9nC yXc5kSR7R2RJIzQ427/sXX4+BK6/rafXaFpMiPjBdOeHMAnT4HBdCtaEk1gjlsxrf5boVlq3MSww DaDMGyCZhhKUmMJ6Uvh/jUeHkxGiw6KxSmRemNSi5FEKBIJ+cQsxggK3MIICswIBATBZMEQxCzAJ BgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExJDAiBgNVBAMTG1RFUkVOQSBlU2NpZW5jZSBQZXJz b25hbCBDQQIRAJtdX1Of4juCvNBOHRUQ3qQwCQYFKw4DAhoFAKCCATMwGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIwMTA5MDg0MzE4WjAjBgkqhkiG9w0BCQQxFgQU CDveqA56oybvmkR0gGNO52D3RbcwaAYJKwYBBAGCNxAEMVswWTBEMQswCQYDVQQGEwJOTDEPMA0G A1UEChMGVEVSRU5BMSQwIgYDVQQDExtURVJFTkEgZVNjaWVuY2UgUGVyc29uYWwgQ0ECEQCbXV9T n+I7grzQTh0VEN6kMGoGCyqGSIb3DQEJEAILMVugWTBEMQswCQYDVQQGEwJOTDEPMA0GA1UEChMG VEVSRU5BMSQwIgYDVQQDExtURVJFTkEgZVNjaWVuY2UgUGVyc29uYWwgQ0ECEQCbXV9Tn+I7grzQ Th0VEN6kMA0GCSqGSIb3DQEBAQUABIIBAIm4S6ZHUqptNwsDmvg3zNJIrs1hwRFZLptuR6O1Vbl7 3oe6514QXdqagC2nA8sPUwv/gr2QpUHqCLdxX5Bwu4+6kNXzRCtuVHpLAnmSbU38586nJRcWDrue hiJ9B8fyqZKQXbl8tYUkKYBxSNBAMO+7dZkJSpzMI/XG8jqlRbdICQfygq/8quEn+9SBnLcECX9u zxZO4aSu6dbfiQoe9XQu55PXKO2arnxZN+cVA3+OzzkMS5E1NO28leUpjzZBknpOxg6FMNKZ+/2P r3F3Y2AQ2SoSd/Hs3tCraqI5ljPnlksIKzvA6UiAO8IO1UcEuaQGHGApnsbAYd2/iHH+aZEAAAAA AAA= --Apple-Mail=_6474D1F6-54A1-4585-9557-442305072ECA-- From andreas.solberg@uninett.no Mon Jan 9 00:41:25 2012 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 4B2F921F852C for ; Mon, 9 Jan 2012 00:41:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-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 GHl6hxkC6rEn for ; Mon, 9 Jan 2012 00:41:24 -0800 (PST) Received: from epost.uninett.no (epost.uninett.no [IPv6:2001:700:0:526:158:38:180:100]) by ietfa.amsl.com (Postfix) with ESMTP id C439621F8555 for ; Mon, 9 Jan 2012 00:41:22 -0800 (PST) Received: from dmanso-11.uninett.no (dmanso-11.uninett.no [IPv6:2001:700:1:0:ea06:88ff:fecf:91f7]) by epost.uninett.no (Postfix) with ESMTPS id 4C3F93360A5 for ; Mon, 9 Jan 2012 09:41:21 +0100 (CET) From: =?iso-8859-1?Q?Andreas_=C5kre_Solberg?= Content-Type: multipart/signed; boundary="Apple-Mail=_D005CD31-6E2B-4120-8EC1-35D849A5B4DA"; protocol="application/pkcs7-signature"; micalg=sha1 Date: Mon, 9 Jan 2012 09:41:21 +0100 Message-Id: <048EBD85-F1B7-436F-953F-3E22DEC44DE3@uninett.no> To: oauth@ietf.org Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) X-Mailman-Approved-At: Mon, 09 Jan 2012 06:14:24 -0800 Subject: [OAUTH-WG] Detecting revoked token in OAuth 2.0 client libraries 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, 09 Jan 2012 08:41:25 -0000 --Apple-Mail=_D005CD31-6E2B-4120-8EC1-35D849A5B4DA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, I'm trying to do an OAuth 2.0 library, and got a question: I cannot find a standardized way for an OAuth protected endpoint to = report to the client that the Token is not valid (expired or revoked). = As a library developer, I'd like to take away as much of possible of the = OAuth logic from the application. I need a way to distinguish = applicaiton specific protocol errors, from OAuth related errors on = protected endpoints. If the library could detect this, it could also in example do refresh = the token automatically, and even start a new flow if neccessary. I'm sorry if the answer is obvious.=20 Another question on token validity; the optional expires_in parameter. = If I would like to indicate permanent validity, how can I express that? = I assume that if I leave the parameter out it is not possible to = distinguish between 'undefined / not specified' and 'infitite'. Putting = the semanthics into a specific scope could off course work, but lack the = feature of beeing standardized between providers. Andreas= --Apple-Mail=_D005CD31-6E2B-4120-8EC1-35D849A5B4DA Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOazCCBIow ggNyoAMCAQICECf06hH0eobEbp27bqkXBwcwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0Ux FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0 d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wNTA2MDcwODA5MTBa Fw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNh bHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0 dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0 aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmF pPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJk xIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2q L+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAs vIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMe oYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4HhMIHeMB8GA1UdIwQYMBaAFK29mHo0tCb3 +sQmVO8DveAky1QaMB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMC AQYwDwYDVR0TAQH/BAUwAwEB/zB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kb2Nh LmNvbS9BZGRUcnVzdEV4dGVybmFsQ0FSb290LmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21vZG8u bmV0L0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAZ2IkRbyis pgCi54fBm5AD236hEv0e8+LwAamUVEJrmgnEoG3XkJIEA2Z5Q3H8+G+v23ZF4jcaPd3kWQR4rBz0 g0bzes9bhHIt5UbBuhgRKfPLSXmHPLptBZ2kbWhPrXIUNqi5sf2/z3/wpGqUNVCPz4FtVbHdWTBK 322gnGQfSXzvNrv042n0+DmPWq1LhTq3Du3Tzw1EovsEv+QvcI4l+1pUBrPQxLxtjftzMizpm4Qk LdZ/kXpoAlAfDj9N6cz1u2fo3BwuO/xOzf4CjuOoEwqlJkRl6RDyTVKnrtw+ymsyXEFs/vVdoOr/ 0fqbhlhtPZZH5f4ulQTCAMyOofK7MIIE2jCCA8KgAwIBAgIQXf9Q6v4PU0aIn4BBj+dCyDANBgkq hkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExh a2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8v d3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBFbWFpbDAeFw0wOTA1MTgwMDAwMDBaFw0yODEyMzEyMzU5NTlaMEQxCzAJBgNV BAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExJDAiBgNVBAMTG1RFUkVOQSBlU2NpZW5jZSBQZXJzb25h bCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMS8JX3N71kEq3QnKbZjiu/ENXCh RgivblCbG3F4lwKFwDX/kBgRZvozORSepBL3Pe4FLIHn9y0uNnhDDjm2f3p0w8tVPy+zy8M3auGV AyMbsyKYE4NYMF+sPJFF020LLsvRkWGyynH6wokMewnWkr+jgRcRVSDfN4GfHiYJHdIXGUPLi5kl dEFb5jIq0KdT3NIhjc2Rz3ts9Mn+0OXSBmsaYUIbgJEH3BRJJzsKirLiO2kIhMuBmde6FB/YfpJj vfYtMfqVTs02DZnvEbqtSvuoxHi5fFo+yPUIMsCpBceMGiiPMLoXo/G54genuPtVv59iWtUUDwi0 E5nSEnla8P0CAwEAAaOCAVswggFXMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0G A1UdDgQWBBTIiXOZp11RFlNFVHyjwjl8y9eqgTAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgw BgEB/wIBADAmBgNVHSAEHzAdMA0GCysGAQQBsjEBAgIdMAwGCiqGSIb3TAUCAgUwWAYDVR0fBFEw TzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3QuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0 aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbwYIKwYBBQUHAQEEYzBhMDgGCCsGAQUFBzAChixodHRw Oi8vY3J0LnVzZXJ0cnVzdC5jb20vVVROQUFBQ2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0 cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG9w0BAQUFAAOCAQEACBekHPkVa7AZYW+gSON6 JO9BVZqgUHDYI9VThkpnjujaVhYYLBsYIYm6mCTuVjTjF4YmvSFa1BmTSuphdE22xISNR+7KLmVt NpOYseKSZojiTnt1x15EaSHcEmow/GGA/g/wndLcfq7lwlNNC3CDYVZF+z3fcvYCQnXriIqYV2D1 n6JySbF6PkFnNcNVKw0HNejGK9W6h3mAdOeSNr1GgXouKeJqvuEXEzV8FqQlMy9h7s7JUuBA29O+ OVrPz0wU5X/FQ1eLTblajsIPBk3eyEmdgXO65D+YpZM8WU7bmzXf/k2/VaHpZMNFfKyPfEfROvFO ddmQZ0DosS+eFy9cNTCCBPswggPjoAMCAQICEQCbXV9Tn+I7grzQTh0VEN6kMA0GCSqGSIb3DQEB BQUAMEQxCzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExJDAiBgNVBAMTG1RFUkVOQSBlU2Np ZW5jZSBQZXJzb25hbCBDQTAeFw0xMTA3MDUwMDAwMDBaFw0xMjA4MDMyMzU5NTlaMIGUMRMwEQYK CZImiZPyLGQBGRYDb3JnMRYwFAYKCZImiZPyLGQBGRYGdGVyZW5hMRMwEQYKCZImiZPyLGQBGRYD dGNzMQswCQYDVQQGEwJOTzEQMA4GA1UEChMHVU5JTkVUVDExMC8GA1UEAxQoQW5kcmVhcyBhYWty ZSBTb2xiZXJnIGFuZHJlYXNAdW5pbmV0dC5ubzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAL8ukoshERFAc4JLOA7WhazD4rpQPdboyAtCuynZUBW2s6NYPH6IuU25CcRldKJIzkBa9/A5 +rmD5r2Evsbdnt91VSU8FR9J73BMHPT7HywD4Y3Rv/h/kb6xkLCgoRAoCPlZDepR6TvUWH1PulII IlbtBMarsrfEUFGuntLIJQA5yH7WysiV0wHGygb+P1KiSDJd4/v3OBilAAg7zwRNJJ5ihmcW24Jx ZX3hQU9KV5ZXb2IxohUwTscYEGBPMoOPe62uQlj2MNiTYaXHX3QH4QZzD4v6MU5qxMSFXxdOfb09 lft3GF+c3PpybQ1T3GpKsSbEcA5FVSMb7HnC67V+5p8CAwEAAaOCAZUwggGRMB8GA1UdIwQYMBaA FMiJc5mnXVEWU0VUfKPCOXzL16qBMB0GA1UdDgQWBBQkb3UBIHXOvsZSkUyjDMTSzXPavDAOBgNV HQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIw JgYDVR0gBB8wHTANBgsrBgEEAbIxAQICHTAMBgoqhkiG90wFAgIFMEcGA1UdHwRAMD4wPKA6oDiG Nmh0dHA6Ly9jcmwudGNzLnRlcmVuYS5vcmcvVEVSRU5BZVNjaWVuY2VQZXJzb25hbENBLmNybDB6 BggrBgEFBQcBAQRuMGwwQgYIKwYBBQUHMAKGNmh0dHA6Ly9jcnQudGNzLnRlcmVuYS5vcmcvVEVS RU5BZVNjaWVuY2VQZXJzb25hbENBLmNydDAmBggrBgEFBQcwAYYaaHR0cDovL29jc3AudGNzLnRl cmVuYS5vcmcwJQYDVR0RBB4wHIEaYW5kcmVhcy5zb2xiZXJnQHVuaW5ldHQubm8wDQYJKoZIhvcN AQEFBQADggEBAKLxPqSWPfTshbrMWi2qGgUW9eXsVU5Lq31WSJfqN79TVyi4ipHSPE4uKFZOe7ZK AehMM+XNgk59nxpkcPmvksNsY98dk78NyH4dgybY5NLurWptkFbP9npcvBeneb3MEQXDLXfc0MuX daES6X3bxwhqe1nXKsyTFtIe8FBETf6Y+DSfaYY69rL0Vl6yJiDnz5ZYLoXOAr5xZtTbqx/yP9nC yXc5kSR7R2RJIzQ427/sXX4+BK6/rafXaFpMiPjBdOeHMAnT4HBdCtaEk1gjlsxrf5boVlq3MSww DaDMGyCZhhKUmMJ6Uvh/jUeHkxGiw6KxSmRemNSi5FEKBIJ+cQsxggK3MIICswIBATBZMEQxCzAJ BgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExJDAiBgNVBAMTG1RFUkVOQSBlU2NpZW5jZSBQZXJz b25hbCBDQQIRAJtdX1Of4juCvNBOHRUQ3qQwCQYFKw4DAhoFAKCCATMwGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIwMTA5MDg0MTIxWjAjBgkqhkiG9w0BCQQxFgQU CDveqA56oybvmkR0gGNO52D3RbcwaAYJKwYBBAGCNxAEMVswWTBEMQswCQYDVQQGEwJOTDEPMA0G A1UEChMGVEVSRU5BMSQwIgYDVQQDExtURVJFTkEgZVNjaWVuY2UgUGVyc29uYWwgQ0ECEQCbXV9T n+I7grzQTh0VEN6kMGoGCyqGSIb3DQEJEAILMVugWTBEMQswCQYDVQQGEwJOTDEPMA0GA1UEChMG VEVSRU5BMSQwIgYDVQQDExtURVJFTkEgZVNjaWVuY2UgUGVyc29uYWwgQ0ECEQCbXV9Tn+I7grzQ Th0VEN6kMA0GCSqGSIb3DQEBAQUABIIBAGHDQYDrTSGUtIvKivZvxLupWmuJol+5lxwGmbBy1SdK LRAriaY6PVQFzZraD3K9uViVfvf+5nBtQBhJwfFuRSpQzNsXhrq0UTOwu03oN5DeC+d7oTZiNfl+ 7GVf0RNmwaEbjowhpdNxryFjWkZl6X2PDhbL96rtFMvev0loVX1hGAi/p/UHhgY0q8TVcxWYiV69 LAhzN1BhxcO2eg2sQhiMB3l9xiZWKTPEm7epRiibxQI2GIH/e59Ztm/tfBYbn3zW8BhR8qj9pNTl bV4AC8hBUdk+8K1wX1M5vMM5YwEeDjLTY77cTX689n080QtMfPqRQOPBZa4Xt5stTx63rG4AAAAA AAA= --Apple-Mail=_D005CD31-6E2B-4120-8EC1-35D849A5B4DA-- From bart@all4students.nl Mon Jan 9 06:23:15 2012 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 BE0E521F875E for ; Mon, 9 Jan 2012 06:23:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.204 X-Spam-Level: X-Spam-Status: No, score=-0.204 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3] 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 onVKzkTnlf1O for ; Mon, 9 Jan 2012 06:23:11 -0800 (PST) Received: from mx-out14.all4students.nl (mx-out14.all4students.nl [89.188.22.31]) by ietfa.amsl.com (Postfix) with ESMTP id 282F421F874F for ; Mon, 9 Jan 2012 06:23:03 -0800 (PST) Received: from mx-out14.all4students.nl (localhost [127.0.0.1]) by mx-out14.all4students.nl (Postfix) with ESMTP id CC31C9443A for ; Mon, 9 Jan 2012 15:23:01 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=studenten.net; h= mime-version:content-type:content-transfer-encoding:subject:date :message-id:in-reply-to:references:from:to; s=selector1; bh=V1Gt yNCECjE78YVDqeE+x0xkras=; b=LCaxcwLT8VDN8o89Z3603kX/HTxt2h4KNZBL hgZuRvOSnX4jyIcAdXfqMJQmk2WoAdC1vNiPLVdi3666yZfauQuHy1t7EZE2njK0 xgnGL+8MQr1pILOikXAg6cfUuAX6lxSNehkMVqnY67hyZpbPTAGBsEzJTyW091xD LNu0WD8= Received: from all4students.nl (ip189-178-172-82.adsl2.static.versatel.nl [82.172.178.189]) by mx-out14.all4students.nl (Postfix) with ESMTP id 57BA694436; Mon, 9 Jan 2012 15:23:01 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 9 Jan 2012 15:22:55 +0100 Message-ID: In-Reply-To: <048EBD85-F1B7-436F-953F-3E22DEC44DE3@uninett.no> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] Detecting revoked token in OAuth 2.0 client libraries Thread-Index: AczO2Qcm574cmqAXTGCVUoDrpJiR5QAAAuew References: <048EBD85-F1B7-436F-953F-3E22DEC44DE3@uninett.no> From: "Bart Wiegmans" To: =?iso-8859-1?Q?Andreas_=C5kre_Solberg?= , Subject: Re: [OAUTH-WG] Detecting revoked token in OAuth 2.0 client libraries 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, 09 Jan 2012 14:23:15 -0000 Hi, As far as I know, the implementation of API endpoints is outside of the = specification of OAuth.=20 But the specification of Bearer Tokens state that the endpoint must = return the HTTP 403 (Access Denied) status code, along with a = WWW-Authenticate: Bearer response header. That should be enough to = determine token invalidity.=20 With kind regards, Bart Wiegmans -----Oorspronkelijk bericht----- Van: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] Namens = Andreas =C5kre Solberg Verzonden: maandag 9 januari 2012 9:41 Aan: oauth@ietf.org Onderwerp: [OAUTH-WG] Detecting revoked token in OAuth 2.0 client = libraries Hi, I'm trying to do an OAuth 2.0 library, and got a question: I cannot find a standardized way for an OAuth protected endpoint to = report to the client that the Token is not valid (expired or revoked). = As a library developer, I'd like to take away as much of possible of the = OAuth logic from the application. I need a way to distinguish = applicaiton specific protocol errors, from OAuth related errors on = protected endpoints. If the library could detect this, it could also in example do refresh = the token automatically, and even start a new flow if neccessary. I'm sorry if the answer is obvious.=20 Another question on token validity; the optional expires_in parameter. = If I would like to indicate permanent validity, how can I express that? = I assume that if I leave the parameter out it is not possible to = distinguish between 'undefined / not specified' and 'infitite'. Putting = the semanthics into a specific scope could off course work, but lack the = feature of beeing standardized between providers. Andreas From sm@resistor.net Mon Jan 9 07:47:13 2012 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 D797321F883C for ; Mon, 9 Jan 2012 07:47:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 jlYqJZ0+V3J2 for ; Mon, 9 Jan 2012 07:47:09 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id CCCBB21F883B for ; Mon, 9 Jan 2012 07:47:08 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q09Fkx4F027938 for ; Mon, 9 Jan 2012 07:47:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1326124026; i=@resistor.net; bh=wU9x+7Tk18vv55FDBudrPhzqgG05MBAsyleQ6bxQvm8=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=dToc00YBTJRmIGnhmNSo0TWRZaulVcW4GTAxF1crjMAHv1QQOkI7UnllsFMuKs99n kar5yyYdMMn5B5yZBb0mSTVABeDKeS0RqxmlNgSQ6lfjbKhbO6ETA60lHCX9J1Rrrb lY3NvWayekaQcsNfj7V6z4yNh3xT3fyC0f94UcjM= Message-Id: <6.2.5.6.2.20120109070921.0aec8d00@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 09 Jan 2012 07:39:02 -0800 To: oauth@ietf.org From: SM In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification 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, 09 Jan 2012 15:47:13 -0000 At 14:12 08-01-2012, agks mehx wrote: >I reported this to the vendor and the vendor claims that the IETF >draft specification says scope is OPTIONAL and that means the vendor >is free to make it required in a conforming implementation. If a bit is said to be optional, it means that it will not cause any interoperability issues if that bit is added or not added. If the vendor claims that the bit is required in a conforming implementation, they are free to do so as the decision about what conforms of what does not conform is theirs alone. From your message, it is not clear whether you are: (i) Asking for a clarification in a specification; or (ii) Trying to resolve a disagreement with a vendor. Regards, -sm From eran@hueniverse.com Mon Jan 9 08:05:05 2012 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 32E5D21F8516 for ; Mon, 9 Jan 2012 08:05:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.030, 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 BS5OpVpZr1vb for ; Mon, 9 Jan 2012 08:05:03 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 56C0611E8072 for ; Mon, 9 Jan 2012 08:05:03 -0800 (PST) Received: (qmail 12445 invoked from network); 9 Jan 2012 16:05:02 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.47) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 9 Jan 2012 16:05:02 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT005.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Mon, 9 Jan 2012 09:04:51 -0700 From: Eran Hammer To: agks mehx , "oauth@ietf.org" Date: Mon, 9 Jan 2012 09:04:35 -0700 Thread-Topic: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification Thread-Index: AczOUskvVDrfg5X0SKe4DupMHiv9+wAlRqSA Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453A72D0CF1@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723453A72D0CF1P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification 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, 09 Jan 2012 16:05:05 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723453A72D0CF1P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In general, you are correct. However in this case, since OAuth 2.0 does not= attempt to guarantee interop between a generic client and any vendor, the = vendor has the right to define its own requirements as long as they are wit= hin the spec boundaries. For example, a vendor can define a missing or empty scope to mean no scope = and reject the request. That's allowed since the definition of scope is lef= t for the vendor to define. Personally, I would not write a server implementation with this behavior an= d instead define a default scope that's sufficient in most cases. EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of a= gks mehx Sent: Sunday, January 08, 2012 2:13 PM To: oauth@ietf.org Subject: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specifica= tion My client implementation per latest draft did not work against a major vend= or's server implementation. This was because the vendor REQUIRES the scope parameter in the initial req= uest. If I do not supply the scope parameter, it calls back the URL with a= n error response stating that the request is invalid: error=3Dinvalid_request&error_description=3DMissing+required+parameter:+sco= pe I reported this to the vendor and the vendor claims that the IETF draft spe= cification says scope is OPTIONAL and that means the vendor is free to make= it required in a conforming implementation. After a careful reading of the relevant sections of the draft specification= , I do not believe that is what is the intent of the specification. It say= s "OPTIONAL" is to be interpreted per RFC2119, which in turn says: "an impl= ementation which does include a particular option MUST be prepared to inter= operate with another implementation which does not include the option (exce= pt, of course, for the feature the option provides.)" This leads me to believe that if I do not supply scope I should not get an = error -- I may not be able to perform any API calls but I should get a toke= n back that proves to me that the user was *some* user at the vendor. Could you please clarify or disambiguate? --_000_90C41DD21FB7C64BB94121FBBC2E723453A72D0CF1P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In genera= l, you are correct. However in this case, since OAuth 2.0 does not attempt = to guarantee interop between a generic client and any vendor, the vendor ha= s the right to define its own requirements as long as they are within the s= pec boundaries.

 = ;

For example, a vendor can def= ine a missing or empty scope to mean no scope and reject the request. That&= #8217;s allowed since the definition of scope is left for the vendor to def= ine.

 

Personally, I would not write a server i= mplementation with this behavior and instead define a default scope that= 217;s sufficient in most cases.

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

EHL

 

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] = On Behalf Of agks mehx
Sent: Sunday, January 08, 2012 2:13= PM
To: oauth@ietf.org
Subject: [OAUTH-WG] Seeking Clar= ification: Potential Ambiguity in Specification

=

 

My cli= ent implementation per latest draft did not work against a major vendor's s= erver implementation.

 

This was because the vendor REQUIRE= S the scope parameter in the initial request.  If I do not supply the = scope parameter, it calls back the URL with an error response stating that = the request is invalid:

=  

error=3Dinvalid_request&= ;error_description=3DMissing+required+parameter:+scope

=

 

I reported this to the vendor and the vendor claims that the IETF draft= specification says scope is OPTIONAL and that means the vendor is free to = make it required in a conforming implementation.

<= p class=3DMsoNormal> 

Af= ter a careful reading of the relevant sections of the draft specification, = I do not believe that is what is the intent of the specification.  It = says "OPTIONAL" is to be interpreted per RFC2119, which in turn s= ays: "an implementation which does include a particular option MUST be= prepared to interoperate with another implementation which does not includ= e the option (except, of course, for the feature the option provides.)"= ;

 

=

This leads me to believe that if I do not supply = scope I should not get an error -- I may not be able to perform any API cal= ls but I should get a token back that proves to me that the user was *some*= user at the vendor.

&nb= sp;

Could you please clarify or di= sambiguate?

= --_000_90C41DD21FB7C64BB94121FBBC2E723453A72D0CF1P3PW5EX1MB01E_-- From eran@hueniverse.com Mon Jan 9 08:11:51 2012 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 D424521F8715 for ; Mon, 9 Jan 2012 08:11:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.025, 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 hnHNcHS10ktr for ; Mon, 9 Jan 2012 08:11:47 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id D505321F86CC for ; Mon, 9 Jan 2012 08:11:46 -0800 (PST) Received: (qmail 29807 invoked from network); 9 Jan 2012 16:11:45 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.46) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 9 Jan 2012 16:11:42 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT004.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Mon, 9 Jan 2012 09:11:31 -0700 From: Eran Hammer To: Antonio Sanso , OAuth WG Date: Mon, 9 Jan 2012 09:11:15 -0700 Thread-Topic: Error code for access token request Thread-Index: AczHH/oz+E6plhXyQYi/VbPh53dC0wHyTzcg Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453A72D0CF5@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4A1DD0C1-77F2-4824-973A-25F225D94F93@adobe.com> In-Reply-To: <4A1DD0C1-77F2-4824-973A-25F225D94F93@adobe.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_90C41DD21FB7C64BB94121FBBC2E723453A72D0CF5P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Error code for access token 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: Mon, 09 Jan 2012 16:11:52 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723453A72D0CF5P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just return HTTP 5xx. We needed the special error code because of the redir= ection flow. EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of A= ntonio Sanso Sent: Friday, December 30, 2011 10:22 AM To: OAuth WG Subject: [OAUTH-WG] Error code for access token request Hi *, Error response for Authorization Request defines some kind of server error = code response: server_error The authorization server encountered an unexpected condition which prevented it from fulfilling the request. as in [0]. I was wondering if would be possible/useful having same for error code for = access token request [1] WDYT? Regards Antonio [0] http://tools.ietf.org/html/draft-ietf-oauth-v2-22#section-4.1.2.1 [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-22#section-5.2 --_000_90C41DD21FB7C64BB94121FBBC2E723453A72D0CF5P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Just retu= rn HTTP 5xx. We needed the special error code because of the redirection fl= ow.

 

EHL

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Beh= alf Of Antonio Sanso
Sent: Friday, December 30, 2011 10:22 AM=
To: OAuth WG
Subject: [OAUTH-WG] Error code for access= token request

&= nbsp;

Hi *,

 

Error response = for Authorization Request defines some kind of server error code response:<= o:p>

 

server_error
      &nbs=
p;        The authorization server encou=
ntered an unexpected
     &nb=
sp;         condition which prevent=
ed it from fulfilling the request.
 
as in [0].
 
<= /div>
I was wondering if would be possible/useful having same for error code for=
 access token request [1]
 
WDYT?
<= /div>
 
Regards=
=

=
 
Antonio
 
 
[1] =
;=
http://tools.ietf.org/html/draft-ietf-oauth-v2-22#section-5.2
= --_000_90C41DD21FB7C64BB94121FBBC2E723453A72D0CF5P3PW5EX1MB01E_-- From eran@hueniverse.com Mon Jan 9 08:18:15 2012 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 54CFF21F874C for ; Mon, 9 Jan 2012 08:18:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.021, 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 hfSrP7E70QKy for ; Mon, 9 Jan 2012 08:18:13 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 7143721F86CC for ; Mon, 9 Jan 2012 08:18:13 -0800 (PST) Received: (qmail 23328 invoked from network); 9 Jan 2012 16:18:05 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 9 Jan 2012 16:18:05 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Mon, 9 Jan 2012 09:17:47 -0700 From: Eran Hammer To: Paul Madsen , "oauth@ietf.org" Date: Mon, 9 Jan 2012 09:17:30 -0700 Thread-Topic: [OAUTH-WG] Native clients & 'confidentiality' Thread-Index: Acy+SHHUaIAU0l0SRtauDe1MldDRHAQoUXLg Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453A72D0CFA@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4EEF2BC4.7020409@gmail.com> In-Reply-To: <4EEF2BC4.7020409@gmail.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_90C41DD21FB7C64BB94121FBBC2E723453A72D0CFAP3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Native clients & 'confidentiality' 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, 09 Jan 2012 16:18:15 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723453A72D0CFAP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The text is pretty straight forward in its intentions. A confidential clien= t must had a secret - what's open is how well the secret needs to be protec= ted (e.g. hard to extract) to qualify as 'capable of keeping' secrets. You = can require all clients to be confidential, but without specifying what qua= lifies as confidential, this requirement is pretty useless. It eliminates c= lients without secrets, or open source clients with the client id hardcoded= and visible, but some can claim that a obfuscated secret in a native appli= cation binary is good enough. They will be wrong, but the spec allows them = to make that decision. EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of P= aul Madsen Sent: Monday, December 19, 2011 4:19 AM To: oauth@ietf.org Subject: [OAUTH-WG] Native clients & 'confidentiality' Hi, the Online Media Authorization Protocol (OMAP) is a (as yet unreleased)= profile of OAuth 2.0 for online delivery of video content based on a user'= s subscriptions (the TV Everywhere use case) We want to support both server & native mobile clients. It is for the secon= d class of clients that I'd appreciate some clarification of 'confidentiali= ty' as defined in OAuth 2. OAuth 2 distinguishes confidential & public clients based on their ability = to secure the credentials they'd use to authenticate to an AS - confidentia= l clients can protect those credentials, public clients can't. Notwithstanding the above definition, the spec gives a degree of discretion= to the AS The client type designation is based on the authorization server's definition of secure authentication and its acceptable exposure levels of client credentials. Give this discretion, is it practical for the OMAP spec to stipulate that '= All Clients (both server & native mobile), MUST be confidential', ie let ea= ch individual OMAP AS specify its own requirements of clients and their abi= lity to securely authenticate? Is this consistent with the OAuth definition of confidentiality? Thanks Paul --_000_90C41DD21FB7C64BB94121FBBC2E723453A72D0CFAP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= The text is pretty straight forward in its intentions. A confidentia= l client must had a secret – what’s open is how well the secret= needs to be protected (e.g. hard to extract) to qualify as ‘capable = of keeping’ secrets. You can require all clients to be confidential, = but without specifying what qualifies as confidential, this requirement is = pretty useless. It eliminates clients without secrets, or open source clien= ts with the client id hardcoded and visible, but some can claim that a obfu= scated secret in a native application binary is good enough. They will be w= rong, but the spec allows them to make that decision.

=

 

EHL

 

From:<= /span> oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] = On Behalf Of Paul Madsen
Sent: Monday, December 19, 2011 4= :19 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Native cl= ients & 'confidentiality'

 

Hi, the Online Media Authorization Protocol (OMAP)= is a (as yet unreleased) profile of OAuth 2.0 for online delivery of video= content based on a user's subscriptions (the TV Everywhere use case)
We want to support both server & native mobile clients. It is for the= second class of clients that I'd appreciate some clarification of 'confide= ntiality' as defined in OAuth 2.

OAuth 2 distinguishes confidential = & public clients based on their ability to secure the credentials they'= d use to authenticate to an AS - confidential clients can protect those cre= dentials, public clients can't.

Notwithstanding the above definition= , the spec gives a degree of discretion to the AS


   The client type designation is based on the authorizatio=
n server's
<=
span style=3D'font-size:12.0pt'>   definition of secure authentic=
ation and its acceptable exposure
   levels =
of client credentials.
 
<= pre style=3D'page-break-before:always'> 

Give this discretion, is it practical for the OMAP spec to stipulate that 'All Client= s (both server & native mobile), MUST be confidential', ie let each ind= ividual OMAP AS specify its own requirements of clients and their ability t= o securely authenticate?

Is this consistent with the OAuth definiti= on of confidentiality?

Thanks

Paul








= --_000_90C41DD21FB7C64BB94121FBBC2E723453A72D0CFAP3PW5EX1MB01E_-- From torsten@lodderstedt.net Mon Jan 9 08:36:24 2012 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 BA71E11E808A for ; Mon, 9 Jan 2012 08:36:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] 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 3+A3CSZPkM5e for ; Mon, 9 Jan 2012 08:36:20 -0800 (PST) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.29.24]) by ietfa.amsl.com (Postfix) with ESMTP id 6B1F111E8094 for ; Mon, 9 Jan 2012 08:36:20 -0800 (PST) Received: from [80.187.107.161] (helo=[10.157.17.71]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.68) (envelope-from ) id 1RkICn-0000pm-Dh; Mon, 09 Jan 2012 17:36:18 +0100 References: <048EBD85-F1B7-436F-953F-3E22DEC44DE3@uninett.no> User-Agent: K-9 Mail for Android In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----GY4GB910UE8IFXL9KNDJ68ABT1T4QO" From: Torsten Lodderstedt Date: Mon, 09 Jan 2012 17:35:55 +0100 To: Bart Wiegmans , =?ISO-8859-1?Q?Andreas_=C5kre_Solberg?= , oauth@ietf.org Message-ID: <986f3503-15f9-4c1e-a974-e571060fe367@email.android.com> X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Subject: Re: [OAUTH-WG] Detecting revoked token in OAuth 2.0 client libraries 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, 09 Jan 2012 16:36:24 -0000 ------GY4GB910UE8IFXL9KNDJ68ABT1T4QO Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi, an invalid token should cause the server to reply with status code 401. regards, Torsten. Bart Wiegmans schrieb: Hi, As far as I know, the implementation of API endpoints is outside of the specification of OAuth. But the specification of Bearer Tokens state that the endpoint must return the HTTP 403 (Access Denied) status code, along with a WWW-Authenticate: Bearer response header. That should be enough to determine token invalidity. With kind regards, Bart Wiegmans -----Oorspronkelijk bericht----- Van: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] Namens Andreas Ã…kre Solberg Verzonden: maandag 9 januari 2012 9:41 Aan: oauth@ietf.org Onderwerp: [OAUTH-WG] Detecting revoked token in OAuth 2.0 client libraries Hi, I'm trying to do an OAuth 2.0 library, and got a question: I cannot find a standardized way for an OAuth protected endpoint to report to the client that the Token is not valid (expired or revoked). As a library developer, I'd like to take away as much of possible of the OAuth logic from the application. I need a way to distinguish applicaiton specific protocol errors, from OAuth related errors on protected endpoints. If the library could detect this, it could also in example do refresh the token automatically, and even start a new flow if neccessary. I'm sorry if the answer is obvious. Another question on token validity; the optional expires_in parameter. If I would like to indicate permanent validity, how can I express that? I assume that if I leave the parameter out it is not possible to distinguish between 'undefined / not specified' and 'infitite'. Putting the semanthics into a specific scope could off course work, but lack the feature of beeing standardized between providers. Andreas _____________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ------GY4GB910UE8IFXL9KNDJ68ABT1T4QO Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi,

an invalid token should cause the server to reply with status code 401.

regards,
Torsten.



Bart Wiegmans <bart@all4students.nl> schrieb:
Hi,

As far as I know, the implementation of API endpoints is outside of the specification of OAuth. 
But the specification of Bearer Tokens state that the endpoint must return the HTTP 403 (Access Denied) status code, along with a WWW-Authenticate: Bearer response header. That should be enough to determine token invalidity. 

With kind regards,
Bart Wiegmans


-----Oorspronkelijk bericht-----
Van: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] Namens Andreas Ã…kre Solberg
Verzonden: maandag 9 januari 2012 9:41
Aan: oauth@ietf.org
Onderwerp: [OAUTH-WG] Detecting revoked token in OAuth 2.0 client libraries

Hi,

I'm trying to do an OAuth 2.0 library, and got a question:

I cannot find a standardized way for an OAuth protected endpoint to report to the client that the Token is not valid (expired 
 or
revoked). As a library developer, I'd like to take away as much of possible of the OAuth logic from the application. I need a way to distinguish applicaiton specific protocol errors, from OAuth related errors on protected endpoints.

If the library could detect this, it could also in example do refresh the token automatically, and even start a new flow if neccessary.

I'm sorry if the answer is obvious. 

Another question on token validity; the optional expires_in parameter. If I would like to indicate permanent validity, how can I express that? I assume that if I leave the parameter out it is not possible to distinguish between 'undefined / not specified' and 'infitite'. Putting the semanthics into a specific scope could off course work, but lack the feature of beeing standardized between providers.

Andreas

OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
------GY4GB910UE8IFXL9KNDJ68ABT1T4QO-- From andreassolberg@gmail.com Mon Jan 9 09:06:39 2012 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 2F80011E8097 for ; Mon, 9 Jan 2012 09:06:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 nIx9nMjZQ-uk for ; Mon, 9 Jan 2012 09:06:38 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4020B11E8095 for ; Mon, 9 Jan 2012 09:06:37 -0800 (PST) Received: by laah2 with SMTP id h2so1749072laa.31 for ; Mon, 09 Jan 2012 09:06:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=6pvzhU32mUl0cpZavzX2HssH0UgkKTF1v9nRgMc8iOY=; b=S6PMwP8i9JG4ynhIB8iSI9vCK2m0oWV518IhlWh9W2TK1/yft3jIjmIlK4LXBOSypa B8G0n9tuuCf1n6WyHz8lT4Ya3nZ+0nqSwubWord5jFtIEAlT9rj35xUfzSuDeMfLR1Dk pBrnvg+fl/ermSahkB8ZOWV8dOuM5yUA1hUVQ= Received: by 10.112.26.37 with SMTP id i5mr3570809lbg.41.1326128796965; Mon, 09 Jan 2012 09:06:36 -0800 (PST) Received: from [192.168.10.100] (94-246-37.42.3p.ntebredband.no. [94.246.37.42]) by mx.google.com with ESMTPS id oy18sm48747452lab.3.2012.01.09.09.06.35 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 09 Jan 2012 09:06:36 -0800 (PST) Sender: =?UTF-8?Q?Andreas_=C3=85kre_Solberg?= Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_F20766BD-6EE8-4678-A0C9-6269794A1B74" From: =?iso-8859-1?Q?Andreas_=C5kre_Solberg?= In-Reply-To: <986f3503-15f9-4c1e-a974-e571060fe367@email.android.com> Date: Mon, 9 Jan 2012 18:06:34 +0100 Message-Id: <5A0231BF-F41C-43FD-8643-479A5543BAC0@uninett.no> References: <048EBD85-F1B7-436F-953F-3E22DEC44DE3@uninett.no> <986f3503-15f9-4c1e-a974-e571060fe367@email.android.com> To: Torsten Lodderstedt X-Mailer: Apple Mail (2.1251.1) Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Detecting revoked token in OAuth 2.0 client libraries 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, 09 Jan 2012 17:07:50 -0000 --Apple-Mail=_F20766BD-6EE8-4678-A0C9-6269794A1B74 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Den 9. jan.2012 kl. 17:35 skrev Torsten Lodderstedt: > Hi, > > an invalid token should cause the server to reply with status code 401. Thanks for the tip, both of you. Andreas --Apple-Mail=_F20766BD-6EE8-4678-A0C9-6269794A1B74 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hi,

an = invalid token should cause the server to reply with status code = 401.

Thanks for the tip, both of = you.


Andreas
= --Apple-Mail=_F20766BD-6EE8-4678-A0C9-6269794A1B74-- From paul.madsen@gmail.com Mon Jan 9 10:54:52 2012 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 A423021F84D6 for ; Mon, 9 Jan 2012 10:54:52 -0800 (PST) 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 27YT0nhrWkul for ; Mon, 9 Jan 2012 10:54:51 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE3121F8493 for ; Mon, 9 Jan 2012 10:54:51 -0800 (PST) Received: by ghbg18 with SMTP id g18so1957368ghb.31 for ; Mon, 09 Jan 2012 10:54:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=4VvNii2s4qGAYxT7+A82miNY/MzY65gYP6SOpylK+1k=; b=WPRpp9aELDX01m0Ve4xnQieNRD5K5NiI9mLTsgFO/FR7ZtTuy0mRbCHnpFGMnP7Xo4 Ar+s47aZ3WMJ+OJE6tU3gix1XEQiZB6qwGKVub8H0MEPoPbh2Wx8eT58RqhT/m8zuUMo GJARdOO0Rj3xmvZlZlNwjRonVFmRQ1FtERDiw= Received: by 10.100.244.37 with SMTP id r37mr7105532anh.11.1326135290698; Mon, 09 Jan 2012 10:54:50 -0800 (PST) Received: from pmadsen-mbp.local ([209.226.201.250]) by mx.google.com with ESMTPS id i6sm3922139and.3.2012.01.09.10.54.48 (version=SSLv3 cipher=OTHER); Mon, 09 Jan 2012 10:54:49 -0800 (PST) Message-ID: <4F0B37F8.9040204@gmail.com> Date: Mon, 09 Jan 2012 13:54:48 -0500 From: Paul Madsen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Eran Hammer References: <4EEF2BC4.7020409@gmail.com> <90C41DD21FB7C64BB94121FBBC2E723453A72D0CFA@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453A72D0CFA@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: multipart/alternative; boundary="------------040407060902040404000209" Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Native clients & 'confidentiality' 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, 09 Jan 2012 18:54:52 -0000 This is a multi-part message in MIME format. --------------040407060902040404000209 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Thanks Eran and others for their responses FWIW & FYI, OMAP decided to phrase requirements more directly in terms of authentication to the AS (MUST for web app clients & SHOULD for native clients) rather than use the confidential/public distinction. Thanks again for your input Paul On 1/9/12 11:17 AM, Eran Hammer wrote: > > The text is pretty straight forward in its intentions. A confidential > client must had a secret -- what's open is how well the secret needs > to be protected (e.g. hard to extract) to qualify as 'capable of > keeping' secrets. You can require all clients to be confidential, but > without specifying what qualifies as confidential, this requirement is > pretty useless. It eliminates clients without secrets, or open source > clients with the client id hardcoded and visible, but some can claim > that a obfuscated secret in a native application binary is good > enough. They will be wrong, but the spec allows them to make that > decision. > > EHL > > *From:*oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On > Behalf Of *Paul Madsen > *Sent:* Monday, December 19, 2011 4:19 AM > *To:* oauth@ietf.org > *Subject:* [OAUTH-WG] Native clients & 'confidentiality' > > Hi, the Online Media Authorization Protocol (OMAP) is a (as yet > unreleased) profile of OAuth 2.0 for online delivery of video content > based on a user's subscriptions (the TV Everywhere use case) > > We want to support both server & native mobile clients. It is for the > second class of clients that I'd appreciate some clarification of > 'confidentiality' as defined in OAuth 2. > > OAuth 2 distinguishes confidential & public clients based on their > ability to secure the credentials they'd use to authenticate to an AS > - confidential clients can protect those credentials, public clients > can't. > > Notwithstanding the above definition, the spec gives a degree of > discretion to the AS > > > The client type designation is based on the authorization server's > definition of secure authentication and its acceptable exposure > levels of client credentials. > > > > Give this discretion, is itpractical for the OMAP spec to stipulate > that 'All Clients (both server & native mobile), MUST be > confidential', ie let each individual OMAP AS specify its own > requirements of clients and their ability to securely authenticate? > > Is this consistent with the OAuth definition of confidentiality? > > Thanks > > Paul > > > > > > > > --------------040407060902040404000209 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Thanks Eran and others for their responses

FWIW & FYI, OMAP decided to phrase requirements more directly in terms of authentication to the AS (MUST for web app clients & SHOULD for native clients) rather than use the confidential/public distinction.

Thanks again for your input

Paul

On 1/9/12 11:17 AM, Eran Hammer wrote:

The text is pretty straight forward in its intentions. A confidential client must had a secret – what’s open is how well the secret needs to be protected (e.g. hard to extract) to qualify as ‘capable of keeping’ secrets. You can require all clients to be confidential, but without specifying what qualifies as confidential, this requirement is pretty useless. It eliminates clients without secrets, or open source clients with the client id hardcoded and visible, but some can claim that a obfuscated secret in a native application binary is good enough. They will be wrong, but the spec allows them to make that decision.

 

EHL

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Paul Madsen
Sent: Monday, December 19, 2011 4:19 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Native clients & 'confidentiality'

 

Hi, the Online Media Authorization Protocol (OMAP) is a (as yet unreleased) profile of OAuth 2.0 for online delivery of video content based on a user's subscriptions (the TV Everywhere use case)

We want to support both server & native mobile clients. It is for the second class of clients that I'd appreciate some clarification of 'confidentiality' as defined in OAuth 2.

OAuth 2 distinguishes confidential & public clients based on their ability to secure the credentials they'd use to authenticate to an AS - confidential clients can protect those credentials, public clients can't.

Notwithstanding the above definition, the spec gives a degree of discretion to the AS


   The client type designation is based on the authorization server's
   definition of secure authentication and its acceptable exposure
   levels of client credentials.
 
 

Give this discretion, is it practical for the OMAP spec to stipulate that 'All Clients (both server & native mobile), MUST be confidential', ie let each individual OMAP AS specify its own requirements of clients and their ability to securely authenticate?

Is this consistent with the OAuth definition of confidentiality?

Thanks

Paul








--------------040407060902040404000209-- From agksmehx@gmail.com Mon Jan 9 16:17:50 2012 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 0579111E80C8 for ; Mon, 9 Jan 2012 16:17:50 -0800 (PST) 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 dOewf686h2NL for ; Mon, 9 Jan 2012 16:17:48 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id A87B511E8080 for ; Mon, 9 Jan 2012 16:17:48 -0800 (PST) Received: by yenl8 with SMTP id l8so1472559yen.31 for ; Mon, 09 Jan 2012 16:17:48 -0800 (PST) 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 :content-type; bh=kuFJjf8rMrPv+Igmww0frQzabjEc5dJJ6y5TMg1OP/g=; b=TZ16ertSeG2mNvZu931hwt5g7p5QnB1fAFaJyBjd9fOGbyXETjzsT842xPj156fPnI /24Z58lRSWOC4/4DeMWUG7RyJa0CnDAtLup5TlEN5aM7BHTFthfFbIj2qLiQAkLEaVdK UGhEsiZxi2pIccDVzlEKhYX3xs/N1eo8kbqxg= MIME-Version: 1.0 Received: by 10.236.148.36 with SMTP id u24mr23627415yhj.49.1326154668192; Mon, 09 Jan 2012 16:17:48 -0800 (PST) Received: by 10.236.67.41 with HTTP; Mon, 9 Jan 2012 16:17:48 -0800 (PST) In-Reply-To: <6.2.5.6.2.20120109153323.0ab3bf80@resistor.net> References: <6.2.5.6.2.20120109070921.0aec8d00@resistor.net> <6.2.5.6.2.20120109153323.0ab3bf80@resistor.net> Date: Mon, 9 Jan 2012 16:17:48 -0800 Message-ID: From: agks mehx To: SM , Eran Hammer , oauth@ietf.org Content-Type: multipart/alternative; boundary=20cf303a32cbea33a404b62171a5 Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification 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, 10 Jan 2012 00:17:50 -0000 --20cf303a32cbea33a404b62171a5 Content-Type: text/plain; charset=ISO-8859-1 Hi SM and Eran, I am confused again, after re-reading Eran's response, whether or not an implementation that rejects *missing* (as opposed to empty) scope is conformant or not. (Eran, your response was a bit ambiguous on whether an implementation is free to error out on an missing scope parameter or not -- I can clearly see it is free to error out on an empty scope parameter, but that's a different situation than the one I am concerned about.) The vendor definitely gives a higher priority to claiming conformance and I believe they would change their implementation, but they believe they are conformant. I do feel the IETF Working Group should make this part of the spec less ambiguous -- why not just make 'scope' REQUIRED and end the misery? Or, make it clear that an implementation is not conformant to the spec if it requires optional parameters? Additionally, I will resend a use-case for the no-scope parameter because my earlier reply unintentionally went privately to Eran and not to the list: I can suggest a spec modification that says that an implementation MUST accept a request without a scope parameter, in which case one possibility for an implementing server is to return an access token or code that does not allow any operations. The purpose of this otherwise "useless" token/code is that the OAuth server confirms that the user is *some* user without any information on *which* user it is. (If the user is not authenticated by the vendor then of course no valid token/code is returned.) An example might help: Facebook, when it started, would manage social networks based on college email domain -- harvard.edu, etc. Facebook used to do it by asking for your email address and sending a confirmation mail. But what if I wanted to tell Facebook just the fact that I was at foo.edu but I did not want to share my email address with Facebook, or any other unique identifier? If the spec required implementations to work without a scope parameter, it would solve this use case perfectly. Facebook wouldn't really care about my school email address or unique id -- I could use my non-school personal email and all Facebook wanted to know was whether I should be in that school network or not simply by using the barebones no-scope OAuth request. Vendors do not lose anything if the spec requires such no-scope requests to be fulfilled. They are merely confirming that a user is *some* user with the user's consent. There are valid cases on the client side such as determining network membership without needing network identity. And it cleans out the optional semantics of scope. Users win in that they have a way to confirm network membership without having to reveal a unique identifier. Clients win in that users will be more willing to confirm network membership if they are not also required to reveal a unique identitfier. This is off-the-cuff but I will be very happy to formalize it and present it to the list. I hope the essential concept made it through my writing! A. On Mon, Jan 9, 2012 at 3:47 PM, SM wrote: > Hello, > > At 15:14 09-01-2012, agks mehx wrote: > >> Thank you for the response. If I understand correctly, the vendor is >> correctly that their implementation conforms to the specification even >> though it rejects requests that do not specify the scope parameter. That >> answers my question. >> > > The better answer is from Eran ( http://www.ietf.org/mail-** > archive/web/oauth/current/**msg08194.html). > > > Whether I was asking for (i) a clarification; or (ii) trying to resolve a >> disagreement. I think I was trying to verify whether indeed there was a >> disagreement. I. e. whether my understanding of the specification was >> correct or not. It seems I was mistaken in understanding the spec. >> > > See comment below. > > > There is no disagreement with the vendor at this point because the two >> responses from this list indicate that the vendor is right. (I still don't >> understand why scope isn't made a required parameter in the specification >> so that such confusion can be avoided, but that's a minor point.) >> > > You locked in on the term "optional" without going into the details of the > draft. I would not claim conformance with a specification if my API > specifies that the optional parts are required as someone writing an > implementation from the draft will run into the same problem as you. > Saying that the vendor is wrong will not get them to fix it. > > Regards, > -sm > --20cf303a32cbea33a404b62171a5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi SM and Eran,

I am confused again, after re-reading Er= an's response, whether or not an implementation that rejects *missing* = (as opposed to empty) scope is conformant or not. =A0(Eran, your response w= as a bit ambiguous on whether an implementation is free to error out on an = missing scope parameter or not -- I can clearly see it is free to error out= on an empty scope parameter, but that's a different situation than the= one I am concerned about.)

The vendor definitely gives a higher priority to claimi= ng conformance and I believe they would change their implementation, but th= ey believe they are conformant.

I do feel the IETF= Working Group should make this part of the spec less ambiguous -- why not = just make 'scope' REQUIRED and end the misery? =A0Or, make it clear= that an implementation is not conformant to the spec if it requires option= al parameters?

Additionally, I will resend a use-case for the no-scope= parameter because my earlier reply unintentionally went privately to Eran = and not to the list:

I can suggest a spec modification that says that an implementation MUST acc= ept a request without a scope parameter, in which case one possibility for = an implementing server is to return an access token or code that does not a= llow any operations. =A0The purpose of this otherwise "useless" t= oken/code is that the OAuth server confirms that the user is *some* user wi= thout any information on *which* user it is. =A0(If the user is not authent= icated by the vendor then of course no valid token/code is returned.)

An example might help: =A0Fac= ebook, when it started, would manage social networks based on college email= domain --=A0harvard.edu, etc. =A0Facebook used to do it by asking = for your email address and sending a confirmation mail. =A0But what if I wa= nted to tell Facebook just the fact that I was at=A0foo.edu=A0but I did= not want to share my email address with Facebook, or any other unique iden= tifier? =A0If the spec required implementations to work without a scope par= ameter, it would solve this use case perfectly. =A0Facebook wouldn't re= ally care about my school email address or unique id -- I could use my non-= school personal email and all Facebook wanted to know was whether I should = be in that school network or not simply by using the barebones no-scope OAu= th request.

Vendors do not lose anything = if the spec requires such no-scope requests to be fulfilled. They are merel= y confirming that a user is *some* user with the user's consent. =A0The= re are valid cases on the client side such as determining network membershi= p without needing network identity. =A0And it cleans out the optional seman= tics of scope.

Users win in that they have a= way to confirm network membership without having to reveal a unique identi= fier.

Clients win in that users wil= l be more willing to confirm network membership if they are not also requir= ed to reveal a unique identitfier.

This is off-the-cuff but I wi= ll be very happy to formalize it and present it to the list. =A0I hope the = essential concept made it through my writing!

A.

On Mo= n, Jan 9, 2012 at 3:47 PM, SM <sm@resistor.net> wrote:
Hello,

At 15:14 09-01-2012, agks mehx wrote:
Thank you for the response. =A0If I understand correctly, the vendor is cor= rectly that their implementation conforms to the specification even though = it rejects requests that do not specify the scope parameter. =A0That answer= s my question.

The better answer is from Eran ( http://www.ietf.org/ma= il-archive/web/oauth/current/msg08194.html ).


Whether I was asking for (i) a clarification; or (ii) trying to resolve a d= isagreement. =A0I think I was trying to verify whether indeed there was a d= isagreement. I. e. whether my understanding of the specification was correc= t or not. =A0It seems I was mistaken in understanding the spec.

See comment below.


There is no disagreement with the vendor at this point because the two resp= onses from this list indicate that the vendor is right. =A0(I still don'= ;t understand why scope isn't made a required parameter in the specific= ation so that such confusion can be avoided, but that's a minor point.)=

You locked in on the term "optional" without going into the detai= ls of the draft. =A0I would not claim conformance with a specification if m= y API specifies that the optional parts are required as someone writing an = implementation from the draft will run into the same problem as you. =A0Say= ing that the vendor is wrong will not get them to fix it.

Regards,
-sm

--20cf303a32cbea33a404b62171a5-- From wmills@yahoo-inc.com Mon Jan 9 16:53:12 2012 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 5BA0B11E809B for ; Mon, 9 Jan 2012 16:53:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.288 X-Spam-Level: X-Spam-Status: No, score=-17.288 tagged_above=-999 required=5 tests=[AWL=0.310, 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 g3hmIJA6TV3i for ; Mon, 9 Jan 2012 16:53:11 -0800 (PST) Received: from nm38-vm7.bullet.mail.ne1.yahoo.com (nm38-vm7.bullet.mail.ne1.yahoo.com [98.138.229.151]) by ietfa.amsl.com (Postfix) with SMTP id E8CE411E8080 for ; Mon, 9 Jan 2012 16:53:10 -0800 (PST) Received: from [98.138.90.56] by nm38.bullet.mail.ne1.yahoo.com with NNFMP; 10 Jan 2012 00:53:07 -0000 Received: from [98.138.226.162] by tm9.bullet.mail.ne1.yahoo.com with NNFMP; 10 Jan 2012 00:53:07 -0000 Received: from [127.0.0.1] by omp1063.mail.ne1.yahoo.com with NNFMP; 10 Jan 2012 00:53:07 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 76021.11565.bm@omp1063.mail.ne1.yahoo.com Received: (qmail 17141 invoked by uid 60001); 10 Jan 2012 00:53:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1326156786; bh=gEPf2b6Aqa9I8xJVkgtWbLxZpJ55jRcpAyTrtdsyOcM=; 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=DXCcQIMTGQ167ciZOel3JOyH086RSlMLOp//aqGQ0SW3QXIR3STnwvzUrlPAQn4k4yxBIoei+r+QVCmDv0qjSu2bSzT00al6zsq4pq1kUj4Rix3VON8H9jgiCdPxKWLjNd7nc9PQOf1zIii+dUVsw99IqTNHU4GLqtGizbSKxcM= 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=Ob2++AidifAcpklz2VIeOQOz2Km3eqFi2gGPHgugZm4MCPbI5cVz08VCqk2a+w8nlOnAmCWubeWO/r0fagBIQFKOsfZlOgkYI7OjkvKMdFDqoXiuxPfl3MZYoEuqy0ebF7RXilFIq4t6NPefXwoiuB84XmbsqTChPtqMkhhfCrw=; X-YMail-OSG: LVZVf1QVM1mBhlHp4hhUuUe2mBK23NWC3xlyypH02JtYhoh plTmpeWHycbNLtgEMOb2QHHUhI10JeJW1sgAa4kpJe69euq12s3Smwf20Woh Su28gpEQjYikRICWp.eaIpRUwIqiBEzAg5BnOtX2jHFc4D1SG7NI4VSgyv4e m9hyGgfjSMJRti1ExtHmr99NbugHWNrhQT0xOvZFz1COy8qDU4jUBOb6tJau hKt0BDMb5wIXvJNCDhDP7zbgmwFdX9OZXL0cAjjcVC_4XQZZUuAxGDzIkzO5 gNu8M9PMUvJA0k_EHe0JXuNwEHsmxVkbOJVGsseYfcwOqsRR7twXExMEq0Rk _WmQXpafDNIMmg3DA..z9_4iBo6xFYzMVNEu.5jceOZ.YHEQ87mgeFLoKZ2d .rzHmJOJTQZ3ksELZQXF_0MUlQNRRWYEU2nwZPlzYmzAqnH8oQIjw0kxNqTX jt5AdPoyX8OSPwV1X6rIKRrW5bGaO4yCFpw4u3.f6TYYUpdwsncXHd4mQBcL tRLFBsTXt967bgC5olo_DAKAp1RC5fDZds8gn0gaplYudeFfGlG9ywOQKtxP Bul1ee.AfoCNCXIjlLdYe7xCpQq0emRn9_Nug Received: from [209.131.62.113] by web31812.mail.mud.yahoo.com via HTTP; Mon, 09 Jan 2012 16:53:06 PST X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.116.331537 References: <6.2.5.6.2.20120109070921.0aec8d00@resistor.net> <6.2.5.6.2.20120109153323.0ab3bf80@resistor.net> Message-ID: <1326156786.88572.YahooMailNeo@web31812.mail.mud.yahoo.com> Date: Mon, 9 Jan 2012 16:53:06 -0800 (PST) From: William Mills To: agks mehx , SM , Eran Hammer , "oauth@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1458549034-83657671-1326156786=:88572" Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification 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, 10 Jan 2012 00:53:12 -0000 --1458549034-83657671-1326156786=:88572 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable There are definitely use cases for un-scoped credentials, which the impleme= ntations I have seen implement as an empty scope.=A0 Are you worried specif= ically about the scope parameter in the HTTP requests, or as represented in= the credential used to access the PR?=0A=0A=0A=0A_________________________= _______=0A From: agks mehx =0ATo: SM ;= Eran Hammer ; oauth@ietf.org =0ASent: Monday, January= 9, 2012 4:17 PM=0ASubject: Re: [OAUTH-WG] Seeking Clarification: Potential= Ambiguity in Specification=0A =0A=0AHi SM and Eran,=0A=0AI am confused aga= in, after re-reading Eran's response, whether or not an implementation that= rejects *missing* (as opposed to empty) scope is conformant or not. =A0(Er= an, your response was a bit ambiguous on whether an implementation is free = to error out on an missing scope parameter or not -- I can clearly see it i= s free to error out on an empty scope parameter, but that's a different sit= uation than the one I am concerned about.)=0A=0A=0AThe vendor definitely gi= ves a higher priority to claiming conformance and I believe they would chan= ge their implementation, but they believe they are conformant.=0A=0AI do fe= el the IETF Working Group should make this part of the spec less ambiguous = -- why not just make 'scope' REQUIRED and end the misery? =A0Or, make it cl= ear that an implementation is not conformant to the spec if it requires opt= ional parameters?=0A=0AAdditionally, I will resend a use-case for the no-sc= ope parameter because my earlier reply unintentionally went privately to Er= an and not to the list:=0A=0AI can suggest a spec modification that says th= at an implementation MUST accept a request without a scope parameter, in wh= ich case one possibility for an implementing server is to return an access = token or code that does not allow any operations. =A0The purpose of this ot= herwise "useless" token/code is that the OAuth server confirms that the use= r is *some* user without any information on *which* user it is. =A0(If the = user is not authenticated by the vendor then of course no valid token/code = is returned.)=0A=0AAn example might help: =A0Facebook, when it started, wou= ld manage social networks based on college email domain --=A0harvard.edu, e= tc. =A0Facebook used to do it by asking for your email address and sending = a confirmation mail. =A0But what if I wanted to tell Facebook just the fact= that I was at=A0foo.edu=A0but I did not want to share my email address wit= h Facebook, or any other unique identifier? =A0If the spec required impleme= ntations to work without a scope parameter, it would solve this use case pe= rfectly. =A0Facebook wouldn't really care about my school email address or = unique id -- I could use my non-school personal email and all Facebook want= ed to know was whether I should be in that school network or not simply by = using the barebones no-scope OAuth request.=0A=0AVendors do not lose anythi= ng if the spec requires such no-scope requests to be fulfilled. They are me= rely confirming that a user is *some* user with the user's consent. =A0Ther= e are valid cases on the client side such as determining network membership= without needing network identity. =A0And it cleans out the optional semant= ics of scope.=0A=0AUsers win in that they have a way to confirm network mem= bership without having to reveal a unique identifier.=0A=0AClients win in t= hat users will be more willing to confirm network membership if they are no= t also required to reveal a unique identitfier.=0A=0AThis is off-the-cuff b= ut I will be very happy to formalize it and present it to the list. =A0I ho= pe the essential concept made it through my writing!=0A=0AA.=0A=0A=0AOn Mon= , Jan 9, 2012 at 3:47 PM, SM wrote:=0A=0AHello,=0A>=0A>At= 15:14 09-01-2012, agks mehx wrote:=0A>=0A>Thank you for the response. =A0I= f I understand correctly, the vendor is correctly that their implementation= conforms to the specification even though it rejects requests that do not = specify the scope parameter. =A0That answers my question.=0A>>=0A>=0AThe be= tter answer is from Eran ( http://www.ietf.org/mail-archive/web/oauth/curre= nt/msg08194.html ).=0A>=0A>=0A>=0A>Whether I was asking for (i) a clarifica= tion; or (ii) trying to resolve a disagreement. =A0I think I was trying to = verify whether indeed there was a disagreement. I. e. whether my understand= ing of the specification was correct or not. =A0It seems I was mistaken in = understanding the spec.=0A>>=0A>=0ASee comment below.=0A>=0A>=0A>=0A>There = is no disagreement with the vendor at this point because the two responses = from this list indicate that the vendor is right. =A0(I still don't underst= and why scope isn't made a required parameter in the specification so that = such confusion can be avoided, but that's a minor point.)=0A>>=0A>=0AYou lo= cked in on the term "optional" without going into the details of the draft.= =A0I would not claim conformance with a specification if my API specifies = that the optional parts are required as someone writing an implementation f= rom the draft will run into the same problem as you. =A0Saying that the ven= dor is wrong will not get them to fix it.=0A>=0A>Regards,=0A>-sm =0A>=0A=0A= _______________________________________________=0AOAuth mailing list=0AOAut= h@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/oauth --1458549034-83657671-1326156786=:88572 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable --1458549034-83657671-1326156786=:88572-- From agksmehx@gmail.com Mon Jan 9 17:44:37 2012 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 2219111E80A1 for ; Mon, 9 Jan 2012 17:44:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.156 X-Spam-Level: X-Spam-Status: No, score=-3.156 tagged_above=-999 required=5 tests=[AWL=-0.442, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, 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 dXpIGaKyFhiv for ; Mon, 9 Jan 2012 17:44:36 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id CB7E111E809B for ; Mon, 9 Jan 2012 17:44:35 -0800 (PST) Received: by yenl8 with SMTP id l8so1514575yen.31 for ; Mon, 09 Jan 2012 17:44:35 -0800 (PST) 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=C9cg+spXjy+0CjafyweqLasWwCocNO3OFfSt95wBzi0=; b=CK087W1jM2xehWqy0wIZvXPpVluoGJD24EtoNDk5Sk31AbFmEEHm3BO2vZZiZIn4kC ohD8pHuS8yQx4Gaj3x0QH29Z1ruRn7RlWyVg1coaZ85xW3+y/IsrFbGNaGIr+jQIPC6p gZHgQjJpuxea0vjD2G0Efq0rJD1h6TrrxQAWw= MIME-Version: 1.0 Received: by 10.236.183.200 with SMTP id q48mr150283yhm.49.1326159875446; Mon, 09 Jan 2012 17:44:35 -0800 (PST) Received: by 10.236.67.41 with HTTP; Mon, 9 Jan 2012 17:44:35 -0800 (PST) In-Reply-To: <1326156786.88572.YahooMailNeo@web31812.mail.mud.yahoo.com> References: <6.2.5.6.2.20120109070921.0aec8d00@resistor.net> <6.2.5.6.2.20120109153323.0ab3bf80@resistor.net> <1326156786.88572.YahooMailNeo@web31812.mail.mud.yahoo.com> Date: Mon, 9 Jan 2012 17:44:35 -0800 Message-ID: From: agks mehx To: William Mills , oauth@ietf.org Content-Type: multipart/alternative; boundary=20cf305b13da4a985804b622a8ce Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification 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, 10 Jan 2012 01:44:37 -0000 --20cf305b13da4a985804b622a8ce Content-Type: text/plain; charset=ISO-8859-1 scope parameter in the HTTP requests. Two choices stand out to me: (a) keep the scope parameter truly optional which implies requiring all implementations to implement un-scoped credentials; (b) make the scope parameter REQUIRED thus removing the confusion and letting implementations choose whether or not they want to allow an empty scope. The former, (a), imposes a little bit of extra work for implementations but benefits users, clients, and arguably implementations, by allowing the un-scoped credentials use-case. The latter, (b), merely improves the quality of the specification -- I do not see what purpose is served by calling the scope parameter OPTIONAL when vendors are free to require it as they please and still claim conformance. On Mon, Jan 9, 2012 at 4:53 PM, William Mills wrote: > There are definitely use cases for un-scoped credentials, which the > implementations I have seen implement as an empty scope. Are you worried > specifically about the scope parameter in the HTTP requests, or as > represented in the credential used to access the PR? > > ------------------------------ > *From:* agks mehx > *To:* SM ; Eran Hammer ; > oauth@ietf.org > *Sent:* Monday, January 9, 2012 4:17 PM > *Subject:* Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in > Specification > > Hi SM and Eran, > > I am confused again, after re-reading Eran's response, whether or not an > implementation that rejects *missing* (as opposed to empty) scope is > conformant or not. (Eran, your response was a bit ambiguous on whether an > implementation is free to error out on an missing scope parameter or not -- > I can clearly see it is free to error out on an empty scope parameter, but > that's a different situation than the one I am concerned about.) > > The vendor definitely gives a higher priority to claiming conformance and > I believe they would change their implementation, but they believe they are > conformant. > > I do feel the IETF Working Group should make this part of the spec less > ambiguous -- why not just make 'scope' REQUIRED and end the misery? Or, > make it clear that an implementation is not conformant to the spec if it > requires optional parameters? > > Additionally, I will resend a use-case for the no-scope parameter because > my earlier reply unintentionally went privately to Eran and not to the list: > > I can suggest a spec modification that says that an implementation MUST > accept a request without a scope parameter, in which case one possibility > for an implementing server is to return an access token or code that does > not allow any operations. The purpose of this otherwise "useless" > token/code is that the OAuth server confirms that the user is *some* user > without any information on *which* user it is. (If the user is not > authenticated by the vendor then of course no valid token/code is returned.) > > An example might help: Facebook, when it started, would manage social > networks based on college email domain -- harvard.edu, etc. Facebook > used to do it by asking for your email address and sending a confirmation > mail. But what if I wanted to tell Facebook just the fact that I was at > foo.edu but I did not want to share my email address with Facebook, or > any other unique identifier? If the spec required implementations to work > without a scope parameter, it would solve this use case perfectly. > Facebook wouldn't really care about my school email address or unique id > -- I could use my non-school personal email and all Facebook wanted to know > was whether I should be in that school network or not simply by using the > barebones no-scope OAuth request. > > Vendors do not lose anything if the spec requires such no-scope requests > to be fulfilled. They are merely confirming that a user is *some* user with > the user's consent. There are valid cases on the client side such as > determining network membership without needing network identity. And it > cleans out the optional semantics of scope. > > Users win in that they have a way to confirm network membership without > having to reveal a unique identifier. > > Clients win in that users will be more willing to confirm network > membership if they are not also required to reveal a unique identitfier. > > This is off-the-cuff but I will be very happy to formalize it and present > it to the list. I hope the essential concept made it through my writing! > > A. > > On Mon, Jan 9, 2012 at 3:47 PM, SM wrote: > > Hello, > > At 15:14 09-01-2012, agks mehx wrote: > > Thank you for the response. If I understand correctly, the vendor is > correctly that their implementation conforms to the specification even > though it rejects requests that do not specify the scope parameter. That > answers my question. > > > The better answer is from Eran ( > http://www.ietf.org/mail-archive/web/oauth/current/msg08194.html ). > > > Whether I was asking for (i) a clarification; or (ii) trying to resolve a > disagreement. I think I was trying to verify whether indeed there was a > disagreement. I. e. whether my understanding of the specification was > correct or not. It seems I was mistaken in understanding the spec. > > > See comment below. > > > There is no disagreement with the vendor at this point because the two > responses from this list indicate that the vendor is right. (I still don't > understand why scope isn't made a required parameter in the specification > so that such confusion can be avoided, but that's a minor point.) > > > You locked in on the term "optional" without going into the details of the > draft. I would not claim conformance with a specification if my API > specifies that the optional parts are required as someone writing an > implementation from the draft will run into the same problem as you. > Saying that the vendor is wrong will not get them to fix it. > > Regards, > -sm > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > --20cf305b13da4a985804b622a8ce Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable scope parameter in t= he HTTP requests.

Two choices stand out to me: =A0(a) ke= ep the scope parameter truly optional which implies requiring all implement= ations to implement un-scoped credentials; =A0(b) make the scope parameter = REQUIRED thus removing the confusion and letting implementations choose whe= ther or not they want to allow an empty scope.

The former, (a), imposes a little bit of extra work for= implementations but benefits users, clients, and arguably implementations,= by allowing the un-scoped credentials use-case.

The latter, (b), merely improves the quality of the specification -- I do n= ot see what purpose is served by calling the scope parameter OPTIONAL when = vendors are free to require it as they please and still claim conformance.<= /div>

On Mon, Jan 9, 2012 at 4:53 PM, William= Mills <wmills= @yahoo-inc.com> wrote:
There are d= efinitely use cases for un-scoped credentials, which the implementations I = have seen implement as an empty scope.=A0 Are you worried specifically abou= t the scope parameter in the HTTP requests, or as represented in the creden= tial used to access the PR?

From: agks mehx <agksmehx@gmail.com>= ;
To: SM <sm@resistor.net>; Eran Ham= mer <eran@hueni= verse.com>; oaut= h@ietf.org
Sent: Monday, January 9, 2012 4:17 PM
Su= bject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity= in Specification

Hi SM and Eran,

I am confused again, after re-readi= ng Eran's response, whether or not an implementation that rejects *miss= ing* (as opposed to empty) scope is conformant or not. =A0(Eran, your respo= nse was a bit ambiguous on whether an implementation is free to error out o= n an missing scope parameter or not -- I can clearly see it is free to erro= r out on an empty scope parameter, but that's a different situation tha= n the one I am concerned about.)

The vendor definitely gives a higher priority to claimi= ng conformance and I believe they would change their implementation, but th= ey believe they are conformant.

I do feel the IETF= Working Group should make this part of the spec less ambiguous -- why not = just make 'scope' REQUIRED and end the misery? =A0Or, make it clear= that an implementation is not conformant to the spec if it requires option= al parameters?

Additionally, I will resend a use-case for the no-scope= parameter because my earlier reply unintentionally went privately to Eran = and not to the list:

I can suggest a spec modification that says that an implementation MUST acc= ept a request without a scope parameter, in which case one possibility for = an implementing server is to return an access token or code that does not a= llow any operations. =A0The purpose of this otherwise "useless" t= oken/code is that the OAuth server confirms that the user is *some* user wi= thout any information on *which* user it is. =A0(If the user is not authent= icated by the vendor then of course no valid token/code is returned.)

An example might help: =A0Fac= ebook, when it started, would manage social networks based on college email= domain --=A0harvard.edu, etc. =A0Facebook used to= do it by asking for your email address and sending a confirmation mail. = =A0But what if I wanted to tell Facebook just the fact that I was at=A0foo.edu=A0but I did not want to share my email address wit= h Facebook, or any other unique identifier? =A0If the spec required impleme= ntations to work without a scope parameter, it would solve this use case pe= rfectly. =A0Facebook wouldn't really care about my school email address or unique id -- I could use my non-school personal email and= all Facebook wanted to know was whether I should be in that school network= or not simply by using the barebones no-scope OAuth request.

Vendors do not lose anything = if the spec requires such no-scope requests to be fulfilled. They are merel= y confirming that a user is *some* user with the user's consent. =A0The= re are valid cases on the client side such as determining network membershi= p without needing network identity. =A0And it cleans out the optional seman= tics of scope.

Users win in that they have a= way to confirm network membership without having to reveal a unique identi= fier.

Clients win in that users wil= l be more willing to confirm network membership if they are not also requir= ed to reveal a unique identitfier.

This is off-the-cuff but I wi= ll be very happy to formalize it and present it to the list. =A0I hope the = essential concept made it through my writing!

A.

On Mon, Jan 9, 2012 at 3:47= PM, SM <sm@resistor.net> wrote:
Hello,

At 15:14 09-01-2012, agks mehx wrote:
Thank you for the response. =A0If I understand correctly, the vendor is cor= rectly that their implementation conforms to the specification even though = it rejects requests that do not specify the scope parameter. =A0That answer= s my question.

The better answer is from Eran ( http://www.ietf.org/ma= il-archive/web/oauth/current/msg08194.html ).


Whether I was asking for (i) a clarification; or (ii) trying to resolve a d= isagreement. =A0I think I was trying to verify whether indeed there was a d= isagreement. I. e. whether my understanding of the specification was correc= t or not. =A0It seems I was mistaken in understanding the spec.

See comment below.


There is no disagreement with the vendor at this point because the two resp= onses from this list indicate that the vendor is right. =A0(I still don'= ;t understand why scope isn't made a required parameter in the specific= ation so that such confusion can be avoided, but that's a minor point.)=

You locked in on the term "optional" without going into the detai= ls of the draft. =A0I would not claim conformance with a specification if m= y API specifies that the optional parts are required as someone writing an = implementation from the draft will run into the same problem as you. =A0Say= ing that the vendor is wrong will not get them to fix it.

Regards,
-sm

There are definitely use cases for un-scoped credentials, which the imple= mentations I have seen implement as an empty scope.  Are you worried s= pecifically about the scope parameter in the HTTP requests, or as represent= ed in the credential used to access the PR?

=
From: agks meh= x <agksmehx@gmail.com>
To:<= /span> SM <sm@resistor.net>; Eran Hammer <eran@hueniverse.com&= gt;; oauth@ietf.org
Sent:= Monday, January 9, 2012 4:17 PM
= Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambigui= ty in Specification
=0A
Hi SM and E= ran,

I am confused again, after re-reading Eran's respon= se, whether or not an implementation that rejects *missing* (as opposed to = empty) scope is conformant or not.  (Eran, your response was a bit amb= iguous on whether an implementation is free to error out on an missing scop= e parameter or not -- I can clearly see it is free to error out on an empty= scope parameter, but that's a different situation than the one I am concer= ned about.)
=0A

The vendor definitely gives a higher = priority to claiming conformance and I believe they would change their impl= ementation, but they believe they are conformant.

= I do feel the IETF Working Group should make this part of the spec less amb= iguous -- why not just make 'scope' REQUIRED and end the misery?  Or, = make it clear that an implementation is not conformant to the spec if it re= quires optional parameters?
=0A

Additionally, I wil= l resend a use-case for the no-scope parameter because my earlier reply uni= ntentionally went privately to Eran and not to the list:

=0AI can suggest a spec modification that says t= hat an implementation MUST accept a request without a scope parameter, in w= hich case one possibility for an implementing server is to return an access= token or code that does not allow any operations.  The purpose of thi= s otherwise "useless" token/code is that the OAuth server confirms that the= user is *some* user without any information on *which* user it is.  (= If the user is not authenticated by the vendor then of course no valid toke= n/code is returned.)
=0A

An example might help:  Facebook, when it started, would manage so= cial networks based on college email domain -- h= arvard.edu, etc.  Facebook used to do it by asking for your email = address and sending a confirmation mail.  But what if I wanted to tell= Facebook just the fact that I was at foo.edu&nb= sp;but I did not want to share my email address with Facebook, or any other= unique identifier?  If the spec required implementations to work with= out a scope parameter, it would solve this use case perfectly.  Facebo= ok wouldn't really care about my school email address or unique id -- I could use my non-school personal email and= all Facebook wanted to know was whether I should be in that school network= or not simply by using the barebones no-scope OAuth request.
=0A

Vendors do not lose anything i= f the spec requires such no-scope requests to be fulfilled. They are merely= confirming that a user is *some* user with the user's consent.  There= are valid cases on the client side such as determining network membership = without needing network identity.  And it cleans out the optional sema= ntics of scope.
=0A

U= sers win in that they have a way to confirm network membership without havi= ng to reveal a unique identifier.
=0A

Clients win in that users will be more willing to confirm = network membership if they are not also required to reveal a unique identit= fier.
=0A

This is off= -the-cuff but I will be very happy to formalize it and present it to the li= st.  I hope the essential concept made it through my writing!
=0A=

A.

On Mon, Jan 9, 2012 at 3:47 PM, SM <sm@resistor.net> wrote:
=0AHello,

=0A= At 15:14 09-01-2012, agks mehx wrote:
=0A
=0AThank you for the response.  If I understand correctly= , the vendor is correctly that their implementation conforms to the specifi= cation even though it rejects requests that do not specify the scope parame= ter.  That answers my question.
=0A=0A
=0A
=0A= The better answer is from Eran ( http://www.ietf.org/mail-archive/web/oauth= /current/msg08194.html ).
=0A
=0A
=0A=0AWhether I was asking for (i) a = clarification; or (ii) trying to resolve a disagreement.  I think I wa= s trying to verify whether indeed there was a disagreement. I. e. whether m= y understanding of the specification was correct or not.  It seems I w= as mistaken in understanding the spec.
=0A=0A
=0A
= =0ASee comment below.

=0A
=0A=0AThere is no disagreement with the vend= or at this point because the two responses from this list indicate that the= vendor is right.  (I still don't understand why scope isn't made a re= quired parameter in the specification so that such confusion can be avoided= , but that's a minor point.)
=0A=0A=0A
=0AYou lock= ed in on the term "optional" without going into the details of the draft. &= nbsp;I would not claim conformance with a specification if my API specifies= that the optional parts are required as someone writing an implementation = from the draft will run into the same problem as you.  Saying that the= vendor is wrong will not get them to fix it.
=0A=0A
=0ARegards,
<= font color=3D"#888888">=0A-sm
=0A

=0A

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



___________________________________= ____________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/o= auth



--20cf305b13da4a985804b622a8ce-- From wmills@yahoo-inc.com Mon Jan 9 17:52:01 2012 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 4344821F8516 for ; Mon, 9 Jan 2012 17:52:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.866 X-Spam-Level: X-Spam-Status: No, score=-16.866 tagged_above=-999 required=5 tests=[AWL=-0.152, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, 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 ohyWgC1jjzby for ; Mon, 9 Jan 2012 17:52:00 -0800 (PST) Received: from nm1.bullet.mail.bf1.yahoo.com (nm1.bullet.mail.bf1.yahoo.com [98.139.212.160]) by ietfa.amsl.com (Postfix) with SMTP id 9BF4D21F8495 for ; Mon, 9 Jan 2012 17:51:59 -0800 (PST) Received: from [98.139.212.152] by nm1.bullet.mail.bf1.yahoo.com with NNFMP; 10 Jan 2012 01:51:54 -0000 Received: from [98.139.212.224] by tm9.bullet.mail.bf1.yahoo.com with NNFMP; 10 Jan 2012 01:51:54 -0000 Received: from [127.0.0.1] by omp1033.mail.bf1.yahoo.com with NNFMP; 10 Jan 2012 01:51:54 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 835069.68993.bm@omp1033.mail.bf1.yahoo.com Received: (qmail 87497 invoked by uid 60001); 10 Jan 2012 01:51:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1326160314; bh=l+OkoHejSmKNj7oLYCVtrGDRKSgjX7/FYB+bCX6K2Zs=; 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=JIcWEsk/cmn9FrfggxAU/NGIxrMJDyJ29gtjsdGrh/GSgA4ODzNLhoCQzNDJBfPRG/7T392u7D7J4u34rv3/uDhoLx5zKSERZOO+NVkEsWR7QgWcwdKA4MgiAqhjunV6BBeQw5KFAN9sQLu/fnUVkvomVO4zaXGd80f1UPkrB0I= 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=E8186VWPtX3lD7Gcr7V6KSeD2Sg6AkxYkutF1YcZeLqmYTi5XKHDu39srOX6i0QBCs+4WxQicZjQ4qmblFKjTL5SVEn3dnh0Iq6/o2ZpzvCLNQixpJ8da7Bco3y8UHlav53SsPg2rBdX5uJb2trMZs4OJ5C3dD6pgRTAKOhRBeU=; X-YMail-OSG: gh44ENkVM1n77yVMfra3Iu7VFJNj9LpAPpAhCrRYNhBBypv laecv40HHFqizgrIRqUwFlGCZlfdBQV7CLdVaeEcbx98GyI1Bt77gi0iHJeC fOgntxbu8x7_CpdOV5WrlhiShXKCLpttOlVBVomk1.dafEHZ.ti0t8L9rb1O afbaEs8cCPqsxI3g8mWyKIW8DvsgljYWZtb9AR5bnJZu_67mEPT6j1k2xM5p d.vk_cpCxruph59S8AKLt7sEvhC6LxsqAwMX4__mZ2D45ouewZfCA3x6ZGpi O2t8E7_DFdI8ZjoonYvK3cqWiKGv8gV.FE3XC08fl0q83lus9BaKUel5nQDl FEXFcF9Qsu.kN3X7.j7kf2m0QyPFCIV48tR6kBTjod75qv4wJAqjZJZ_iPct yau4cLOeYpv0FoIkC9lRBixBSPT.Jp2gyRvhgRNUbm02Q6j5ANyjidPMVZuM YKW_cPDJw6rfIO_ei7qCU8aiN7siVR.lbQEgwupD8Cmz4XEjyJK2PAyqtESo gz_2zg_iikppFXZh0qGFr7BajRHndlK_kG4EuWcyTplj.qTasZ9aL4Ae5i6l BumZzCQ8bNqykRs4yFIS_1HeO5AwtXh8nIW2. Received: from [209.131.62.113] by web31806.mail.mud.yahoo.com via HTTP; Mon, 09 Jan 2012 17:51:54 PST X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.116.331537 References: <6.2.5.6.2.20120109070921.0aec8d00@resistor.net> <6.2.5.6.2.20120109153323.0ab3bf80@resistor.net> <1326156786.88572.YahooMailNeo@web31812.mail.mud.yahoo.com> Message-ID: <1326160314.71861.YahooMailNeo@web31806.mail.mud.yahoo.com> Date: Mon, 9 Jan 2012 17:51:54 -0800 (PST) From: William Mills To: agks mehx , "oauth@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1055047407-1813656947-1326160314=:71861" Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification 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, 10 Jan 2012 01:52:01 -0000 ---1055047407-1813656947-1326160314=:71861 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Re your "a" below: No, implementations may issue scoped credentials if they= have a default scope.=A0 It says elsewhere in the spec that the scope issu= ed by the server may not match the requested scope, which is why the server= returns a scope value.=A0 This is for informational purposes only for the = client so it can know what scopes it should already have.=0A=0A=0AYou don't= have to support empty scopes, and it would be completely valid for the aut= h server to reject a request for an unknown scope, which could include the = empty scope if the auth server doesn't support it.=0A=0A-bill=0A=0A=0A_____= ___________________________=0A From: agks mehx =0ATo: W= illiam Mills ; oauth@ietf.org =0ACc: SM ; Eran Hammer =0ASent: Monday, January 9, 2012 5:= 44 PM=0ASubject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity = in Specification=0A =0A=0Ascope parameter in the HTTP requests.=0A=0ATwo ch= oices stand out to me: =A0(a) keep the scope parameter truly optional which= implies requiring all implementations to implement un-scoped credentials; = =A0(b) make the scope parameter REQUIRED thus removing the confusion and le= tting implementations choose whether or not they want to allow an empty sco= pe.=0A=0AThe former, (a), imposes a little bit of extra work for implementa= tions but benefits users, clients, and arguably implementations, by allowin= g the un-scoped credentials use-case.=0A=0AThe latter, (b), merely improves= the quality of the specification -- I do not see what purpose is served by= calling the scope parameter OPTIONAL when vendors are free to require it a= s they please and still claim conformance.=0A=0A=0AOn Mon, Jan 9, 2012 at 4= :53 PM, William Mills wrote:=0A=0AThere are definite= ly use cases for un-scoped credentials, which the implementations I have se= en implement as an empty scope.=A0 Are you worried specifically about the s= cope parameter in the HTTP requests, or as represented in the credential us= ed to access the PR?=0A>=0A>=0A>=0A>=0A>________________________________=0A= > From: agks mehx =0A>To: SM ; Eran Ha= mmer ; oauth@ietf.org =0A>Sent: Monday, January 9, 201= 2 4:17 PM=0A>Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambig= uity in Specification=0A>=0A>=0A>=0A>Hi SM and Eran,=0A>=0A>=0A>I am confus= ed again, after re-reading Eran's response, whether or not an implementatio= n that rejects *missing* (as opposed to empty) scope is conformant or not. = =A0(Eran, your response was a bit ambiguous on whether an implementation is= free to error out on an missing scope parameter or not -- I can clearly se= e it is free to error out on an empty scope parameter, but that's a differe= nt situation than the one I am concerned about.)=0A>=0A>=0A>=0A>The vendor = definitely gives a higher priority to claiming conformance and I believe th= ey would change their implementation, but they believe they are conformant.= =0A>=0A>=0A>I do feel the IETF Working Group should make this part of the s= pec less ambiguous -- why not just make 'scope' REQUIRED and end the misery= ? =A0Or, make it clear that an implementation is not conformant to the spec= if it requires optional parameters?=0A>=0A>=0A>Additionally, I will resend= a use-case for the no-scope parameter because my earlier reply unintention= ally went privately to Eran and not to the list:=0A>=0A>=0A>I can suggest a= spec modification that says that an implementation MUST accept a request w= ithout a scope parameter, in which case one possibility for an implementing= server is to return an access token or code that does not allow any operat= ions. =A0The purpose of this otherwise "useless" token/code is that the OAu= th server confirms that the user is *some* user without any information on = *which* user it is. =A0(If the user is not authenticated by the vendor then= of course no valid token/code is returned.)=0A>=0A>=0A>An example might he= lp: =A0Facebook, when it started, would manage social networks based on col= lege email domain --=A0harvard.edu, etc. =A0Facebook used to do it by askin= g for your email address and sending a confirmation mail. =A0But what if I = wanted to tell Facebook just the fact that I was at=A0foo.edu=A0but I did n= ot want to share my email address with Facebook, or any other unique identi= fier? =A0If the spec required implementations to work without a scope param= eter, it would solve this use case perfectly. =A0Facebook wouldn't really c= are about my school email address or unique id -- I could use my non-school= personal email and all Facebook wanted to know was whether I should be in = that school network or not simply by using the barebones no-scope OAuth req= uest.=0A>=0A>=0A>Vendors do not lose anything if the spec requires such no-= scope requests to be fulfilled. They are merely confirming that a user is *= some* user with the user's consent. =A0There are valid cases on the client = side such as determining network membership without needing network identit= y. =A0And it cleans out the optional semantics of scope.=0A>=0A>=0A>Users w= in in that they have a way to confirm network membership without having to = reveal a unique identifier.=0A>=0A>=0A>Clients win in that users will be mo= re willing to confirm network membership if they are not also required to r= eveal a unique identitfier.=0A>=0A>=0A>This is off-the-cuff but I will be v= ery happy to formalize it and present it to the list. =A0I hope the essenti= al concept made it through my writing!=0A>=0A>=0A>A.=0A>=0A>=0A>On Mon, Jan= 9, 2012 at 3:47 PM, SM wrote:=0A>=0A>Hello,=0A>>=0A>>At = 15:14 09-01-2012, agks mehx wrote:=0A>>=0A>>Thank you for the response. =A0= If I understand correctly, the vendor is correctly that their implementatio= n conforms to the specification even though it rejects requests that do not= specify the scope parameter. =A0That answers my question.=0A>>>=0A>>=0AThe= better answer is from Eran ( http://www.ietf.org/mail-archive/web/oauth/cu= rrent/msg08194.html ).=0A>>=0A>>=0A>>=0A>>Whether I was asking for (i) a cl= arification; or (ii) trying to resolve a disagreement. =A0I think I was try= ing to verify whether indeed there was a disagreement. I. e. whether my und= erstanding of the specification was correct or not. =A0It seems I was mista= ken in understanding the spec.=0A>>>=0A>>=0ASee comment below.=0A>>=0A>>=0A= >>=0A>>There is no disagreement with the vendor at this point because the t= wo responses from this list indicate that the vendor is right. =A0(I still = don't understand why scope isn't made a required parameter in the specifica= tion so that such confusion can be avoided, but that's a minor point.)=0A>>= >=0A>>=0AYou locked in on the term "optional" without going into the detail= s of the draft. =A0I would not claim conformance with a specification if my= API specifies that the optional parts are required as someone writing an i= mplementation from the draft will run into the same problem as you. =A0Sayi= ng that the vendor is wrong will not get them to fix it.=0A>>=0A>>Regards,= =0A>>-sm =0A>>=0A>=0A>=0A>_______________________________________________= =0A>OAuth mailing list=0A>OAuth@ietf.org=0A>https://www.ietf.org/mailman/li= stinfo/oauth=0A>=0A>=0A> ---1055047407-1813656947-1326160314=:71861 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Re your "a" below: No, implementations may issue scoped credentials if th= ey have a default scope.  It says elsewhere in the spec that the scope= issued by the server may not match the requested scope, which is why the s= erver returns a scope value.  This is for informational purposes only = for the client so it can know what scopes it should already have.

You don't have to support empty scopes, and it w= ould be completely valid for the auth server to reject a request for an unk= nown scope, which could include the empty scope if the auth server doesn't = support it.

-bill

From: a= gks mehx <agksmehx@gmail.com>
To: William Mills <wmills@yahoo-inc.com>; oauth@ietf.or= g
Cc: SM <sm@resist= or.net>; Eran Hammer <eran@hueniverse.com>
Sent: Monday, January 9, 2012 5:44 PM
Subject: Re: [OAUTH-WG] Seek= ing Clarification: Potential Ambiguity in Specification
=
=0A
sc= ope parameter in the HTTP requests.

Two choices s= tand out to me:  (a) keep the scope parameter truly optional which imp= lies requiring all implementations to implement un-scoped credentials; &nbs= p;(b) make the scope parameter REQUIRED thus removing the confusion and let= ting implementations choose whether or not they want to allow an empty scop= e.
=0A

The former, (a), imposes a little bit of ext= ra work for implementations but benefits users, clients, and arguably imple= mentations, by allowing the un-scoped credentials use-case.

<= /div>
=0AThe latter, (b), merely improves the quality of the specificat= ion -- I do not see what purpose is served by calling the scope parameter O= PTIONAL when vendors are free to require it as they please and still claim = conformance.
=0A

On Mo= n, Jan 9, 2012 at 4:53 PM, William Mills <wmills@yahoo-inc.com> wrote:
<= blockquote class=3D"yiv1201578104gmail_quote" style=3D"margin:0 0 0 .8ex;bo= rder-left:1px #ccc solid;padding-left:1ex;">=0A
There are definitely use cases for= un-scoped credentials, which the implementations I have seen implement as = an empty scope.  Are you worried specifically about the scope paramete= r in the HTTP requests, or as represented in the credential used to access = the PR?
=0A

<= font face=3D"Arial">
=0A From: agks mehx <agksm= ehx@gmail.com>
To: SM <sm@resistor.net>; Eran Hamme= r <eran@hueniverse.com>; oauth@ietf.org
=0A Sent:=0A Monday, January 9, 2012 4:17 PM
= Subject: Re: [OAUTH-WG] Seekin= g Clarification: Potential Ambiguity in Specification
=

=0A
Hi SM and Eran,

<= /div>
I am confused again, after re-reading Eran's response, whether or= not an implementation that rejects *missing* (as opposed to empty) scope i= s conformant or not.  (Eran, your response was a bit ambiguous on whet= her an implementation is free to error out on an missing scope parameter or= not -- I can clearly see it is free to error out on an empty scope paramet= er, but that's a different situation than the one I am concerned about.)=0A=0A

The vendor definitely gives a higher priority to= claiming conformance and I believe they would change their implementation,= but they believe they are conformant.

I do feel t= he IETF Working Group should make this part of the spec less ambiguous -- w= hy not just make 'scope' REQUIRED and end the misery?  Or, make it cle= ar that an implementation is not conformant to the spec if it requires opti= onal parameters?
=0A=0A

Additionally, I will resend= a use-case for the no-scope parameter because my earlier reply unintention= ally went privately to Eran and not to the list:

<= div style=3D"font-family:arial, sans-serif;font-size:13px;background-color:= rgb(255,255,255);">=0A=0AI can suggest a spec modification that says that a= n implementation MUST accept a request without a scope parameter, in which = case one possibility for an implementing server is to return an access toke= n or code that does not allow any operations.  The purpose of this oth= erwise "useless" token/code is that the OAuth server confirms that the user= is *some* user without any information on *which* user it is.  (If th= e user is not authenticated by the vendor then of course no valid token/cod= e is returned.)
=0A=0A

har= vard.edu, etc.  Facebook used to do it by asking for your email ad= dress and sending a confirmation mail.  But what if I wanted to tell F= acebook just the fact that I was at foo.edu = ;but I did not want to share my email address with Facebook, or any other u= nique identifier?  If the spec required implementations to work withou= t a scope parameter, it would solve this use case perfectly.  Facebook= wouldn't really care about my school=0A email address or unique id -- I co= uld use my non-school personal email and all Facebook wanted to know was wh= ether I should be in that school network or not simply by using the barebon= es no-scope OAuth request.
=0A

Vendors do not lose anything if the spec requires such no-scope r= equests to be fulfilled. They are merely confirming that a user is *some* u= ser with the user's consent.  There are valid cases on the client side= such as determining network membership without needing network identity. &= nbsp;And it cleans out the optional semantics of scope.
=0A=0A

Users win in that they have a way= to confirm network membership without having to reveal a unique identifier= .
=0A=0A

Clients win = in that users will be more willing to confirm network membership if they ar= e not also required to reveal a unique identitfier.
=0A=0A

This is off-the-cuff but I will be = very happy to formalize it and present it to the list.  I hope the ess= ential concept made it through my writing!
=0A=0A

=
A.

On Mon, Jan 9, 2012 at 3:47 PM, SM <sm@resistor.net> wrote= :
=0A=0AHello,

=0AAt 15:14 09-01-2012, agks mehx wrote= :
=0A
=0AThank you for the response.  If I understand corr= ectly, the vendor is correctly that their implementation conforms to the sp= ecification even though it rejects requests that do not specify the scope p= arameter.  That answers my question.
=0A=0A=0A
=0A
<= /div>=0AThe better answer is from Eran ( http://www.ietf.org/mail-archive/web/oauth/current/msg08194.html ).<= div>=0A
=0A
=0A
=0AWhether I was asking for (i) a clarificat= ion; or (ii) trying to resolve a disagreement.  I think I was trying t= o verify whether indeed there was a disagreement. I. e. whether my understa= nding of the specification was correct or not.  It seems I was mistake= n in understanding the spec.
=0A=0A=0A
=0A
=0ASee c= omment below.

=0A
=0A
=0AThere is no disagreement with = the vendor at this point because the two responses from this list indicate = that the vendor is right.  (I still don't understand why scope isn't m= ade a required parameter in the specification so that such confusion can be= avoided, but that's a minor point.)
=0A=0A=0A
=0A
= =0AYou locked in on the term "optional" without going into the details of t= he draft.  I would not claim conformance with a specification if my AP= I specifies that the optional parts are required as someone writing an impl= ementation from the draft will run into the same problem as you.  Sayi= ng that the vendor is wrong will not get them to fix it.
=0A=0A=0A
= =0ARegards,
=0A-sm
=0A

=0A

_______________________________________________
OAuth mailing list
<= a rel=3D"nofollow" ymailto=3D"mailto:OAuth@ietf.org" target=3D"_blank" href= =3D"mailto:OAuth@ietf.org">OAuth@ietf.org
https://ww= w.ietf.org/mailman/listinfo/oauth
=0A

<= /div>

=0A


---1055047407-1813656947-1326160314=:71861-- From agksmehx@gmail.com Mon Jan 9 17:57:40 2012 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 14DC911E809B for ; Mon, 9 Jan 2012 17:57:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.046 X-Spam-Level: X-Spam-Status: No, score=-3.046 tagged_above=-999 required=5 tests=[AWL=-0.331, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, 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 l9ecovlX1R22 for ; Mon, 9 Jan 2012 17:57:38 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 811A011E8080 for ; Mon, 9 Jan 2012 17:57:38 -0800 (PST) Received: by ghbg18 with SMTP id g18so2179246ghb.31 for ; Mon, 09 Jan 2012 17:57:38 -0800 (PST) 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=JOLeJroFbpKYHh+9H/ev6yYcajixvkV7ywSACW2bxHo=; b=q9vfJwYuAb+IJb0VlaSpUSaQJJJDsZhGero8IKMiY7qoCmbJ5CpkNDMMTOSntZBUco OrNMQ8dXJohqVhMNvLZj9q5X7c5Q2WseEw0rA4/DMTekHN0YqhwDTWCbHrNGWvJEtfFx UzeGw52PuwXHR9YgQNoSS2Zi5/RGmkcbQexB8= MIME-Version: 1.0 Received: by 10.236.183.200 with SMTP id q48mr173475yhm.49.1326160657399; Mon, 09 Jan 2012 17:57:37 -0800 (PST) Received: by 10.236.67.41 with HTTP; Mon, 9 Jan 2012 17:57:36 -0800 (PST) In-Reply-To: <1326160314.71861.YahooMailNeo@web31806.mail.mud.yahoo.com> References: <6.2.5.6.2.20120109070921.0aec8d00@resistor.net> <6.2.5.6.2.20120109153323.0ab3bf80@resistor.net> <1326156786.88572.YahooMailNeo@web31812.mail.mud.yahoo.com> <1326160314.71861.YahooMailNeo@web31806.mail.mud.yahoo.com> Date: Mon, 9 Jan 2012 17:57:36 -0800 Message-ID: From: agks mehx To: William Mills , oauth@ietf.org Content-Type: multipart/alternative; boundary=20cf305b13dae640de04b622d67b Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification 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, 10 Jan 2012 01:57:40 -0000 --20cf305b13dae640de04b622d67b Content-Type: text/plain; charset=ISO-8859-1 That's fine and still consistent with the essence of (a), which is to require implementations to accept requests without a scope parameter. If an implementation chooses to issue scoped credentials, that's perfectly fine. My focus is solely on whether the scope parameter should be termed as OPTIONAL or REQUIRED within the specification. Perhaps, (b) is a better choice -- to make it REQUIRED? On Mon, Jan 9, 2012 at 5:51 PM, William Mills wrote: > Re your "a" below: No, implementations may issue scoped credentials if > they have a default scope. It says elsewhere in the spec that the scope > issued by the server may not match the requested scope, which is why the > server returns a scope value. This is for informational purposes only for > the client so it can know what scopes it should already have. > > You don't have to support empty scopes, and it would be completely valid > for the auth server to reject a request for an unknown scope, which could > include the empty scope if the auth server doesn't support it. > > -bill > > ------------------------------ > *From:* agks mehx > *To:* William Mills ; oauth@ietf.org > *Cc:* SM ; Eran Hammer > *Sent:* Monday, January 9, 2012 5:44 PM > > *Subject:* Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in > Specification > > scope parameter in the HTTP requests. > > Two choices stand out to me: (a) keep the scope parameter truly optional > which implies requiring all implementations to implement un-scoped > credentials; (b) make the scope parameter REQUIRED thus removing the > confusion and letting implementations choose whether or not they want to > allow an empty scope. > > The former, (a), imposes a little bit of extra work for implementations > but benefits users, clients, and arguably implementations, by allowing the > un-scoped credentials use-case. > > The latter, (b), merely improves the quality of the specification -- I do > not see what purpose is served by calling the scope parameter OPTIONAL when > vendors are free to require it as they please and still claim conformance. > > On Mon, Jan 9, 2012 at 4:53 PM, William Mills wrote: > > There are definitely use cases for un-scoped credentials, which the > implementations I have seen implement as an empty scope. Are you worried > specifically about the scope parameter in the HTTP requests, or as > represented in the credential used to access the PR? > > ------------------------------ > *From:* agks mehx > *To:* SM ; Eran Hammer ; > oauth@ietf.org > *Sent:* Monday, January 9, 2012 4:17 PM > *Subject:* Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in > Specification > > Hi SM and Eran, > > I am confused again, after re-reading Eran's response, whether or not an > implementation that rejects *missing* (as opposed to empty) scope is > conformant or not. (Eran, your response was a bit ambiguous on whether an > implementation is free to error out on an missing scope parameter or not -- > I can clearly see it is free to error out on an empty scope parameter, but > that's a different situation than the one I am concerned about.) > > The vendor definitely gives a higher priority to claiming conformance and > I believe they would change their implementation, but they believe they are > conformant. > > I do feel the IETF Working Group should make this part of the spec less > ambiguous -- why not just make 'scope' REQUIRED and end the misery? Or, > make it clear that an implementation is not conformant to the spec if it > requires optional parameters? > > Additionally, I will resend a use-case for the no-scope parameter because > my earlier reply unintentionally went privately to Eran and not to the list: > > I can suggest a spec modification that says that an implementation MUST > accept a request without a scope parameter, in which case one possibility > for an implementing server is to return an access token or code that does > not allow any operations. The purpose of this otherwise "useless" > token/code is that the OAuth server confirms that the user is *some* user > without any information on *which* user it is. (If the user is not > authenticated by the vendor then of course no valid token/code is returned.) > > An example might help: Facebook, when it started, would manage social > networks based on college email domain -- harvard.edu, etc. Facebook > used to do it by asking for your email address and sending a confirmation > mail. But what if I wanted to tell Facebook just the fact that I was at > foo.edu but I did not want to share my email address with Facebook, or > any other unique identifier? If the spec required implementations to work > without a scope parameter, it would solve this use case perfectly. > Facebook wouldn't really care about my school email address or unique id > -- I could use my non-school personal email and all Facebook wanted to know > was whether I should be in that school network or not simply by using the > barebones no-scope OAuth request. > > Vendors do not lose anything if the spec requires such no-scope requests > to be fulfilled. They are merely confirming that a user is *some* user with > the user's consent. There are valid cases on the client side such as > determining network membership without needing network identity. And it > cleans out the optional semantics of scope. > > Users win in that they have a way to confirm network membership without > having to reveal a unique identifier. > > Clients win in that users will be more willing to confirm network > membership if they are not also required to reveal a unique identitfier. > > This is off-the-cuff but I will be very happy to formalize it and present > it to the list. I hope the essential concept made it through my writing! > > A. > > On Mon, Jan 9, 2012 at 3:47 PM, SM wrote: > > Hello, > > At 15:14 09-01-2012, agks mehx wrote: > > Thank you for the response. If I understand correctly, the vendor is > correctly that their implementation conforms to the specification even > though it rejects requests that do not specify the scope parameter. That > answers my question. > > > The better answer is from Eran ( > http://www.ietf.org/mail-archive/web/oauth/current/msg08194.html ). > > > Whether I was asking for (i) a clarification; or (ii) trying to resolve a > disagreement. I think I was trying to verify whether indeed there was a > disagreement. I. e. whether my understanding of the specification was > correct or not. It seems I was mistaken in understanding the spec. > > > See comment below. > > > There is no disagreement with the vendor at this point because the two > responses from this list indicate that the vendor is right. (I still don't > understand why scope isn't made a required parameter in the specification > so that such confusion can be avoided, but that's a minor point.) > > > You locked in on the term "optional" without going into the details of the > draft. I would not claim conformance with a specification if my API > specifies that the optional parts are required as someone writing an > implementation from the draft will run into the same problem as you. > Saying that the vendor is wrong will not get them to fix it. > > Regards, > -sm > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > > --20cf305b13dae640de04b622d67b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable That's fine and still consistent with the essence of (a), which is to r= equire implementations to accept requests without a scope parameter. =A0If = an implementation chooses to issue scoped credentials, that's perfectly= fine.

My focus is solely on whether the scope parameter should be = termed as OPTIONAL or REQUIRED within the specification.

Perhaps, (b) is a better choice -- to make it REQUIRED?

On Mon, Jan 9, 2012 at 5:51 PM, William Mills <wmills@yahoo-inc.com> wrote:=
Re your &qu= ot;a" below: No, implementations may issue scoped credentials if they = have a default scope.=A0 It says elsewhere in the spec that the scope issue= d by the server may not match the requested scope, which is why the server = returns a scope value.=A0 This is for informational purposes only for the c= lient so it can know what scopes it should already have.

You don't have to support empty scopes= , and it would be completely valid for the auth server to reject a request = for an unknown scope, which could include the empty scope if the auth serve= r doesn't support it.

-bill

From: agks mehx <agksmehx@gmail.com>
To: William Mills <wmills@yahoo-inc.com>; = oauth@ietf.org
Cc: SM <sm@resistor.net>; Eran Hammer &l= t;eran@hueniverse.= com>
Sent: Monday, January 9, 20= 12 5:44 PM

Subject: Re: [OAUTH-WG] Seeking Clarification: Potenti= al Ambiguity in Specification

scope parameter= in the HTTP requests.

Two choices stand out to me: =A0(= a) keep the scope parameter truly optional which implies requiring all impl= ementations to implement un-scoped credentials; =A0(b) make the scope param= eter REQUIRED thus removing the confusion and letting implementations choos= e whether or not they want to allow an empty scope.

The former, (a), imposes a little bit of extra work for= implementations but benefits users, clients, and arguably implementations,= by allowing the un-scoped credentials use-case.

The latter, (b), merely improves the quality of the specification -- I do n= ot see what purpose is served by calling the scope parameter OPTIONAL when = vendors are free to require it as they please and still claim conformance.<= /div>

On Mon, Jan 9, 2012 at 4:53 PM, William Mills <wmills@yahoo-inc.com> wrote:
There are d= efinitely use cases for un-scoped credentials, which the implementations I = have seen implement as an empty scope.=A0 Are you worried specifically abou= t the scope parameter in the HTTP requests, or as represented in the creden= tial used to access the PR?

From: agks mehx <agksmehx= @gmail.com>
To: S= M <sm@resistor.net>; Eran Hammer <eran@hueniverse.com>; oauth@ietf.= org
Sent: Monday, January 9, 2012 4:17 PM
Su= bject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity= in Specification

Hi SM and Eran,

I am confused again, after re-readi= ng Eran's response, whether or not an implementation that rejects *miss= ing* (as opposed to empty) scope is conformant or not. =A0(Eran, your respo= nse was a bit ambiguous on whether an implementation is free to error out o= n an missing scope parameter or not -- I can clearly see it is free to erro= r out on an empty scope parameter, but that's a different situation tha= n the one I am concerned about.)

The vendor definitely gives a higher priority to claimi= ng conformance and I believe they would change their implementation, but th= ey believe they are conformant.

I do feel the IETF= Working Group should make this part of the spec less ambiguous -- why not = just make 'scope' REQUIRED and end the misery? =A0Or, make it clear= that an implementation is not conformant to the spec if it requires option= al parameters?

Additionally, I will resend a use-case for the no-scope= parameter because my earlier reply unintentionally went privately to Eran = and not to the list:

I can suggest a spec modification that says that an implementation MUST acc= ept a request without a scope parameter, in which case one possibility for = an implementing server is to return an access token or code that does not a= llow any operations. =A0The purpose of this otherwise "useless" t= oken/code is that the OAuth server confirms that the user is *some* user wi= thout any information on *which* user it is. =A0(If the user is not authent= icated by the vendor then of course no valid token/code is returned.)

An example might help: =A0Fac= ebook, when it started, would manage social networks based on college email= domain --=A0harvard.edu, etc. =A0Facebook used to= do it by asking for your email address and sending a confirmation mail. = =A0But what if I wanted to tell Facebook just the fact that I was at=A0foo.edu=A0but I did not want to share my email address wit= h Facebook, or any other unique identifier? =A0If the spec required impleme= ntations to work without a scope parameter, it would solve this use case pe= rfectly. =A0Facebook wouldn't really care about my school email address or unique id -- I could use my non-school personal email and= all Facebook wanted to know was whether I should be in that school network= or not simply by using the barebones no-scope OAuth request.

Vendors do not lose anything = if the spec requires such no-scope requests to be fulfilled. They are merel= y confirming that a user is *some* user with the user's consent. =A0The= re are valid cases on the client side such as determining network membershi= p without needing network identity. =A0And it cleans out the optional seman= tics of scope.

Users win in that they have a= way to confirm network membership without having to reveal a unique identi= fier.

Clients win in that users wil= l be more willing to confirm network membership if they are not also requir= ed to reveal a unique identitfier.

This is off-the-cuff but I wi= ll be very happy to formalize it and present it to the list. =A0I hope the = essential concept made it through my writing!

A.

On Mon, Jan 9, 2012 at 3:47= PM, SM <sm@resistor.net> wrote:
Hello,

At 15:14 09-01-2012, agks mehx wrote:
Thank you for the response. =A0If I understand correctly, the vendor is cor= rectly that their implementation conforms to the specification even though = it rejects requests that do not specify the scope parameter. =A0That answer= s my question.

The better answer is from Eran ( http:= //www.ietf.org/mail-archive/web/oauth/current/msg08194.html ).


Whether I was asking for (i) a clarification; or (ii) trying to resolve a d= isagreement. =A0I think I was trying to verify whether indeed there was a d= isagreement. I. e. whether my understanding of the specification was correc= t or not. =A0It seems I was mistaken in understanding the spec.

See comment below.


There is no disagreement with the vendor at this point because the two resp= onses from this list indicate that the vendor is right. =A0(I still don'= ;t understand why scope isn't made a required parameter in the specific= ation so that such confusion can be avoided, but that's a minor point.)=

You locked in on the term "optional" without going into the detai= ls of the draft. =A0I would not claim conformance with a specification if m= y API specifies that the optional parts are required as someone writing an = implementation from the draft will run into the same problem as you. =A0Say= ing that the vendor is wrong will not get them to fix it.

Regards,
-sm


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





--20cf305b13dae640de04b622d67b-- From wmills@yahoo-inc.com Mon Jan 9 18:24:43 2012 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 B638D21F84FC for ; Mon, 9 Jan 2012 18:24:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.857 X-Spam-Level: X-Spam-Status: No, score=-16.857 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, 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 4F50ic+H9r4v for ; Mon, 9 Jan 2012 18:24:42 -0800 (PST) Received: from nm24.bullet.mail.ac4.yahoo.com (nm24.bullet.mail.ac4.yahoo.com [98.139.52.221]) by ietfa.amsl.com (Postfix) with SMTP id 39B3F21F8504 for ; Mon, 9 Jan 2012 18:24:41 -0800 (PST) Received: from [98.139.52.193] by nm24.bullet.mail.ac4.yahoo.com with NNFMP; 10 Jan 2012 02:24:36 -0000 Received: from [98.139.52.146] by tm6.bullet.mail.ac4.yahoo.com with NNFMP; 10 Jan 2012 02:24:36 -0000 Received: from [127.0.0.1] by omp1029.mail.ac4.yahoo.com with NNFMP; 10 Jan 2012 02:24:36 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 668376.25464.bm@omp1029.mail.ac4.yahoo.com Received: (qmail 45798 invoked by uid 60001); 10 Jan 2012 02:24:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1326162276; bh=ImoA8D3RSJisiJ9mBfjiLKLTWGyiWdtbO0a9UaxFINY=; 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=FfRqoZDueRf96+IKlOQtUVHAPL+rU7pBA/X2tHq5g69xb/gFhdjwx5AOU3YQT/adKBba/HnK5Ff6/5Ipju1pQQsbP7jqrbJH14dG4Gw8k/i9APkDx1rIqYpM1C1Hs30AlzK/Wr99srH+X13mUI4WKnXC892MfYewksM2mRGCqSE= 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=F1s3MaaV3dIfXj5amDJylw2jMVuTh3ISWu8+ApxAMiIZOQe5ih3CDLesNpt5U3yOGSp66EsJYi1NwRiZfmHkBCEe4wKkYYyPNKon5OnGtXfjOVxhZgFhuxhlt+z1AyXCJA32PGOBKgufWK3lwtkBsu6aRpKHNPGQWxobgqvblZ4=; X-YMail-OSG: 8M7g7SUVM1lbL3vOymXyr5zSJLK_2ZKjMfuED3V.z4De4BY vj1.YezhAyAhohivu5fGI84InNubiUrysswN7fz_FsCbX651eka.GmWkIfrz mSVtMac7nqwUxqOsXQ1IFl4QJ7R5hez.MOUNXiyTdI8R3qcO7RoWQWoWqXxt egG7zUm0QnxxSgsiGx26y5zyIIUpYs4cDmuTLprYtUGDGno35Ck2BG1tOeNA hCVoI0y_56um9OW7JPszMv5U5.wTzwEFpnjlAYMlHd_tx3ryrDAI9jyNU.M0 e5fiN.ARPf95YLRbnWJX8w4mvOMN8r8o6lcBc2QZCUjDrENWnKcEy67P3sXg stNhApZ0fxv1Ia6OIEItodBFfwkRILiDmFRriocQ.oBcMMpo6WOtrgYD1ahz iZ5w4iWBAaWDhOUBUk9dz7cn72CTBYf2NkzSy_vCJw9kk5PUnizuOKYz24w2 mzeNrYPEkOLaXitmxAJrP6SYtYPObSRWMGyQaXqYXaOfagOPQjI7Fj8VD.rp ZfFQJrUyvOim3EvJs8YkYM3RubDgV6puSi85OPkEPzQ6J25UWt0f6ul6YIcb .yvHQiSavxHxlno6A4jfsxg3otgOL0CRdyEth Received: from [209.131.62.113] by web31811.mail.mud.yahoo.com via HTTP; Mon, 09 Jan 2012 18:24:36 PST X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.116.331537 References: <6.2.5.6.2.20120109070921.0aec8d00@resistor.net> <6.2.5.6.2.20120109153323.0ab3bf80@resistor.net> <1326156786.88572.YahooMailNeo@web31812.mail.mud.yahoo.com> <1326160314.71861.YahooMailNeo@web31806.mail.mud.yahoo.com> Message-ID: <1326162276.40306.YahooMailNeo@web31811.mail.mud.yahoo.com> Date: Mon, 9 Jan 2012 18:24:36 -0800 (PST) From: William Mills To: agks mehx , "oauth@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="764183289-1669497823-1326162276=:40306" Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification 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, 10 Jan 2012 02:24:43 -0000 --764183289-1669497823-1326162276=:40306 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I am just not yet convinced that it should be REQUIRED.=A0 I think the fact= that we have default language for servers to insert a NULL value for omitt= ed params is sufficient.=A0 Do we need that here too?=A0 Would that make it= clearer?=0A=0A=0A=0A________________________________=0A From: agks mehx =0ATo: William Mills ; oauth@ietf.o= rg =0ACc: SM ; Eran Hammer =0ASent: = Monday, January 9, 2012 5:57 PM=0ASubject: Re: [OAUTH-WG] Seeking Clarifica= tion: Potential Ambiguity in Specification=0A =0A=0AThat's fine and still c= onsistent with the essence of (a), which is to require implementations to a= ccept requests without a scope parameter. =A0If an implementation chooses t= o issue scoped credentials, that's perfectly fine.=0A=0AMy focus is solely = on whether the scope parameter should be termed as OPTIONAL or REQUIRED wit= hin the specification.=0A=0APerhaps, (b) is a better choice -- to make it R= EQUIRED?=0A=0A=0AOn Mon, Jan 9, 2012 at 5:51 PM, William Mills wrote:=0A=0ARe your "a" below: No, implementations may issue sco= ped credentials if they have a default scope.=A0 It says elsewhere in the s= pec that the scope issued by the server may not match the requested scope, = which is why the server returns a scope value.=A0 This is for informational= purposes only for the client so it can know what scopes it should already = have.=0A>=0A>=0A>=0A>You don't have to support empty scopes, and it would b= e completely valid for the auth server to reject a request for an unknown s= cope, which could include the empty scope if the auth server doesn't suppor= t it.=0A>=0A>=0A>-bill=0A>=0A>=0A>=0A>________________________________=0A> = From: agks mehx =0A>To: William Mills ; oauth@ietf.org =0A>Cc: SM ; Eran Hammer =0A>Sent: Monday, January 9, 2012 5:44 PM=0A>=0A>Subject: Re: [O= AUTH-WG] Seeking Clarification: Potential Ambiguity in Specification=0A> = =0A>=0A>=0A>scope parameter in the HTTP requests.=0A>=0A>=0A>Two choices st= and out to me: =A0(a) keep the scope parameter truly optional which implies= requiring all implementations to implement un-scoped credentials; =A0(b) m= ake the scope parameter REQUIRED thus removing the confusion and letting im= plementations choose whether or not they want to allow an empty scope.=0A>= =0A>=0A>The former, (a), imposes a little bit of extra work for implementat= ions but benefits users, clients, and arguably implementations, by allowing= the un-scoped credentials use-case.=0A>=0A>=0A>The latter, (b), merely imp= roves the quality of the specification -- I do not see what purpose is serv= ed by calling the scope parameter OPTIONAL when vendors are free to require= it as they please and still claim conformance.=0A>=0A>=0A>On Mon, Jan 9, 2= 012 at 4:53 PM, William Mills wrote:=0A>=0A>There ar= e definitely use cases for un-scoped credentials, which the implementations= I have seen implement as an empty scope.=A0 Are you worried specifically a= bout the scope parameter in the HTTP requests, or as represented in the cre= dential used to access the PR?=0A>>=0A>>=0A>>=0A>>=0A>>____________________= ____________=0A>> From: agks mehx =0A>>To: SM ; Eran Hammer ; oauth@ietf.org =0A>>Sent: Mond= ay, January 9, 2012 4:17 PM=0A>>Subject: Re: [OAUTH-WG] Seeking Clarificati= on: Potential Ambiguity in Specification=0A>>=0A>>=0A>>=0A>>Hi SM and Eran,= =0A>>=0A>>=0A>>I am confused again, after re-reading Eran's response, wheth= er or not an implementation that rejects *missing* (as opposed to empty) sc= ope is conformant or not. =A0(Eran, your response was a bit ambiguous on wh= ether an implementation is free to error out on an missing scope parameter = or not -- I can clearly see it is free to error out on an empty scope param= eter, but that's a different situation than the one I am concerned about.)= =0A>>=0A>>=0A>>=0A>>The vendor definitely gives a higher priority to claimi= ng conformance and I believe they would change their implementation, but th= ey believe they are conformant.=0A>>=0A>>=0A>>I do feel the IETF Working Gr= oup should make this part of the spec less ambiguous -- why not just make '= scope' REQUIRED and end the misery? =A0Or, make it clear that an implementa= tion is not conformant to the spec if it requires optional parameters?=0A>>= =0A>>=0A>>Additionally, I will resend a use-case for the no-scope parameter= because my earlier reply unintentionally went privately to Eran and not to= the list:=0A>>=0A>>=0A>>I can suggest a spec modification that says that a= n implementation MUST accept a request without a scope parameter, in which = case one possibility for an implementing server is to return an access toke= n or code that does not allow any operations. =A0The purpose of this otherw= ise "useless" token/code is that the OAuth server confirms that the user is= *some* user without any information on *which* user it is. =A0(If the user= is not authenticated by the vendor then of course no valid token/code is r= eturned.)=0A>>=0A>>=0A>>An example might help: =A0Facebook, when it started= , would manage social networks based on college email domain --=A0harvard.e= du, etc. =A0Facebook used to do it by asking for your email address and sen= ding a confirmation mail. =A0But what if I wanted to tell Facebook just the= fact that I was at=A0foo.edu=A0but I did not want to share my email addres= s with Facebook, or any other unique identifier? =A0If the spec required im= plementations to work without a scope parameter, it would solve this use ca= se perfectly. =A0Facebook wouldn't really care about my school email addres= s or unique id -- I could use my non-school personal email and all Facebook= wanted to know was whether I should be in that school network or not simpl= y by using the barebones no-scope OAuth request.=0A>>=0A>>=0A>>Vendors do n= ot lose anything if the spec requires such no-scope requests to be fulfille= d. They are merely confirming that a user is *some* user with the user's co= nsent. =A0There are valid cases on the client side such as determining netw= ork membership without needing network identity. =A0And it cleans out the o= ptional semantics of scope.=0A>>=0A>>=0A>>Users win in that they have a way= to confirm network membership without having to reveal a unique identifier= .=0A>>=0A>>=0A>>Clients win in that users will be more willing to confirm n= etwork membership if they are not also required to reveal a unique identitf= ier.=0A>>=0A>>=0A>>This is off-the-cuff but I will be very happy to formali= ze it and present it to the list. =A0I hope the essential concept made it t= hrough my writing!=0A>>=0A>>=0A>>A.=0A>>=0A>>=0A>>On Mon, Jan 9, 2012 at 3:= 47 PM, SM wrote:=0A>>=0A>>Hello,=0A>>>=0A>>>At 15:14 09-0= 1-2012, agks mehx wrote:=0A>>>=0A>>>Thank you for the response. =A0If I und= erstand correctly, the vendor is correctly that their implementation confor= ms to the specification even though it rejects requests that do not specify= the scope parameter. =A0That answers my question.=0A>>>>=0A>>>=0AThe bette= r answer is from Eran ( http://www.ietf.org/mail-archive/web/oauth/current/= msg08194.html ).=0A>>>=0A>>>=0A>>>=0A>>>Whether I was asking for (i) a clar= ification; or (ii) trying to resolve a disagreement. =A0I think I was tryin= g to verify whether indeed there was a disagreement. I. e. whether my under= standing of the specification was correct or not. =A0It seems I was mistake= n in understanding the spec.=0A>>>>=0A>>>=0ASee comment below.=0A>>>=0A>>>= =0A>>>=0A>>>There is no disagreement with the vendor at this point because = the two responses from this list indicate that the vendor is right. =A0(I s= till don't understand why scope isn't made a required parameter in the spec= ification so that such confusion can be avoided, but that's a minor point.)= =0A>>>>=0A>>>=0AYou locked in on the term "optional" without going into the= details of the draft. =A0I would not claim conformance with a specificatio= n if my API specifies that the optional parts are required as someone writi= ng an implementation from the draft will run into the same problem as you. = =A0Saying that the vendor is wrong will not get them to fix it.=0A>>>=0A>>>= Regards,=0A>>>-sm =0A>>>=0A>>=0A>>=0A>>____________________________________= ___________=0A>>OAuth mailing list=0A>>OAuth@ietf.org=0A>>https://www.ietf.= org/mailman/listinfo/oauth=0A>>=0A>>=0A>>=0A>=0A>=0A> --764183289-1669497823-1326162276=:40306 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I am just not yet convinced that it should be REQUIRED.  I think the= fact that we have default language for servers to insert a NULL value for = omitted params is sufficient.  Do we need that here too?  Would t= hat make it clearer?

From: agks mehx &l= t;agksmehx@gmail.com>
To: William Mills <wmills@yahoo-inc.com>; oauth@ietf.org
Cc: SM <sm@resistor.net>;= Eran Hammer <eran@hueniverse.com>
Sen= t: Monday, January 9, 2012 5:57 PM
Subject: Re: [OAUTH-WG] Seeking Clarification: Pote= ntial Ambiguity in Specification

=0A
That's fine and still consistent with the essence of (a), which is= to require implementations to accept requests without a scope parameter. &= nbsp;If an implementation chooses to issue scoped credentials, that's perfe= ctly fine.
=0A
My focus is solely on whether the scope pa= rameter should be termed as OPTIONAL or REQUIRED within the specification.<= /div>

Perhaps, (b) is a better choice -- to make it REQU= IRED?

=0AOn Mon, Jan 9, 2012 = at 5:51 PM, William Mills <wmills@yahoo-inc.com> wrote:
=0A
Re your "a" below: No, implementations may issue s= coped credentials if they have a default scope.  It says elsewhere in = the spec that the scope issued by the server may not match the requested sc= ope, which is why the server returns a scope value.  This is for infor= mational purposes only for the client so it can know what scopes it should = already have.
=0A

You don't have to supp= ort empty scopes, and it would be completely valid for the auth server to r= eject a request for an unknown scope, which could include the empty scope i= f the auth server doesn't support it.
=0A

-bill

=0A
From: agks mehx <agksmehx@gmail.com>
To: William Mills <wmills@yahoo-inc.com>; oa= uth@ietf.org
=0ACc:= SM <sm@resistor.net>; Eran Hammer = <eran@hueniverse.com>
= =0A Sent: Monday, January 9= , 2012 5:44 PM

Subject: Re: [OAUTH-WG] Seeking Clari= fication: Potential Ambiguity in Specification
=0A
<= /div>

=0A
scope parameter in the HTTP requests.<= div>
Two choices stand out to me:  (a) keep the scope pa= rameter truly optional which implies requiring all implementations to imple= ment un-scoped credentials;  (b) make the scope parameter REQUIRED thu= s removing the confusion and letting implementations choose whether or not = they want to allow an empty scope.
=0A=0A

The forme= r, (a), imposes a little bit of extra work for implementations but benefits= users, clients, and arguably implementations, by allowing the un-scoped cr= edentials use-case.

=0A=0AThe latter, (b), merely = improves the quality of the specification -- I do not see what purpose is s= erved by calling the scope parameter OPTIONAL when vendors are free to requ= ire it as they please and still claim conformance.
=0A=0A

On Mon, Jan 9, 2012 at 4:53 PM, William Mills <wmills@yahoo-inc.com> wrote= :
=0A=0A
There are definitely use cases for un-scoped credentials, wh= ich the implementations I have seen implement as an empty scope.  Are = you worried specifically about the scope parameter in the HTTP requests, or= as represented in the credential used to access the PR?
=0A=0A

=0A=0A From: = agks mehx <agksmehx@gmail.com>= ;
To: SM <sm@resistor.net>; Eran Hammer <eran@hueniverse.com>; oauth@ietf.org
=0A=0A Se= nt:=0A Monday, January 9, 2012 4:17 PM
Subject: Re: [OAUTH-WG] Seeking Clarification: P= otential Ambiguity in Specification

= =0A
Hi SM and Eran,

I am confused again, after re-re= ading Eran's response, whether or not an implementation that rejects *missi= ng* (as opposed to empty) scope is conformant or not.  (Eran, your res= ponse was a bit ambiguous on whether an implementation is free to error out= on an missing scope parameter or not -- I can clearly see it is free to er= ror out on an empty scope parameter, but that's a different situation than = the one I am concerned about.)
=0A=0A=0A

The vendor d= efinitely gives a higher priority to claiming conformance and I believe the= y would change their implementation, but they believe they are conformant.<= /div>

I do feel the IETF Working Group should make this = part of the spec less ambiguous -- why not just make 'scope' REQUIRED and e= nd the misery?  Or, make it clear that an implementation is not confor= mant to the spec if it requires optional parameters?
=0A=0A=0A
Additionally, I will resend a use-case for the no-scope paramet= er because my earlier reply unintentionally went privately to Eran and not = to the list:

=0A=0A=0AI can su= ggest a spec modification that says that an implementation MUST accept a re= quest without a scope parameter, in which case one possibility for an imple= menting server is to return an access token or code that does not allow any= operations.  The purpose of this otherwise "useless" token/code is th= at the OAuth server confirms that the user is *some* user without any infor= mation on *which* user it is.  (If the user is not authenticated by th= e vendor then of course no valid token/code is returned.)
=0A=0A=0A
An example might help:  = ;Facebook, when it started, would manage social networks based on college e= mail domain -- harvard.edu, etc.  Faceb= ook used to do it by asking for your email address and sending a confirmati= on mail.  But what if I wanted to tell Facebook just the fact that I w= as at foo.edu but I did not want to share m= y email address with Facebook, or any other unique identifier?  If the= spec required implementations to work without a scope parameter, it would = solve this use case perfectly.  Facebook wouldn't really care about my= school=0A email address or unique id -- I could use my non-school personal= email and all Facebook wanted to know was whether I should be in that scho= ol network or not simply by using the barebones no-scope OAuth request.=0A

Vendors do not lose = anything if the spec requires such no-scope requests to be fulfilled. They = are merely confirming that a user is *some* user with the user's consent. &= nbsp;There are valid cases on the client side such as determining network m= embership without needing network identity.  And it cleans out the opt= ional semantics of scope.
=0A=0A=0A

Users win in that they have a way to confirm network members= hip without having to reveal a unique identifier.
=0A=0A=0A

Clients win in that users will be m= ore willing to confirm network membership if they are not also required to = reveal a unique identitfier.
=0A=0A=0A

This is off-the-cuff but I will be very happy to formaliz= e it and present it to the list.  I hope the essential concept made it= through my writing!
=0A=0A=0A

A.
<= br>
On Mon, Jan 9, 2012 at 3:47 PM, SM <sm@resistor.net> wrote:
=0A= =0A=0AHello,

=0AAt 15:14 09-01-2012, agks mehx wrote:
=0A=0AThank you for the response.  If I understand correctly, the vend= or is correctly that their implementation conforms to the specification eve= n though it rejects requests that do not specify the scope parameter.  = ;That answers my question.
=0A=0A=0A=0A
=0A
=0AThe = better answer is from Eran ( http://ww= w.ietf.org/mail-archive/web/oauth/current/msg08194.html ).
=0A
= =0A
=0A
=0AWhether I was asking for (i) a clarification; or (ii= ) trying to resolve a disagreement.  I think I was trying to verify wh= ether indeed there was a disagreement. I. e. whether my understanding of th= e specification was correct or not.  It seems I was mistaken in unders= tanding the spec.
=0A=0A=0A=0A
=0A
=0ASee comment b= elow.

=0A
=0A
=0AThere is no disagreement with the vend= or at this point because the two responses from this list indicate that the= vendor is right.  (I still don't understand why scope isn't made a re= quired parameter in the specification so that such confusion can be avoided= , but that's a minor point.)
=0A=0A=0A=0A
=0A
=0AYo= u locked in on the term "optional" without going into the details of the dr= aft.  I would not claim conformance with a specification if my API spe= cifies that the optional parts are required as someone writing an implement= ation from the draft will run into the same problem as you.  Saying th= at the vendor is wrong will not get them to fix it.
=0A=0A=0A=0A
=0AR= egards,
=0A-sm
=0A
=
=0A

_____________________________= __________________
OAuth mailing list
OAu= th@ietf.org
https://www.ietf.org/mailman/listinfo/oa= uth
=0A=0A


=0A



=0A

--764183289-1669497823-1326162276=:40306-- From agksmehx@gmail.com Mon Jan 9 22:45:15 2012 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 B718821F8779 for ; Mon, 9 Jan 2012 22:45:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.979 X-Spam-Level: X-Spam-Status: No, score=-2.979 tagged_above=-999 required=5 tests=[AWL=-0.265, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, 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 pAefZgByoDDO for ; Mon, 9 Jan 2012 22:45:14 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id B821C21F8778 for ; Mon, 9 Jan 2012 22:45:13 -0800 (PST) Received: by ghbg18 with SMTP id g18so2259745ghb.31 for ; Mon, 09 Jan 2012 22:45:13 -0800 (PST) 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=XAlJ/mi8MFtiQXoN35GYDsREsLOBEWXMlemyUurJ/S8=; b=wKZyHhsn9W71GA7hQgWTA9TtPwcB4UqqUiT1KjL5ViwGBDf1FD/lJEYg0kjmaq/PYS 9otjXeu7vejIUpqJiDBPME0KQopVBhInQuPrTNPqLAOH+YL4HUQwxgkMsTJogZcek8OM bh9B9D/FAdrdtKp9G/9mN0Jsu/sKefx0kGeME= MIME-Version: 1.0 Received: by 10.236.186.9 with SMTP id v9mr24783358yhm.32.1326177913021; Mon, 09 Jan 2012 22:45:13 -0800 (PST) Received: by 10.236.67.41 with HTTP; Mon, 9 Jan 2012 22:45:12 -0800 (PST) In-Reply-To: <1326162276.40306.YahooMailNeo@web31811.mail.mud.yahoo.com> References: <6.2.5.6.2.20120109070921.0aec8d00@resistor.net> <6.2.5.6.2.20120109153323.0ab3bf80@resistor.net> <1326156786.88572.YahooMailNeo@web31812.mail.mud.yahoo.com> <1326160314.71861.YahooMailNeo@web31806.mail.mud.yahoo.com> <1326162276.40306.YahooMailNeo@web31811.mail.mud.yahoo.com> Date: Mon, 9 Jan 2012 22:45:12 -0800 Message-ID: From: agks mehx To: William Mills , Eran Hammer , oauth@ietf.org Content-Type: multipart/alternative; boundary=20cf303f6d586a25bb04b626db01 Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification 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, 10 Jan 2012 06:45:15 -0000 --20cf303f6d586a25bb04b626db01 Content-Type: text/plain; charset=ISO-8859-1 Please allow me to step-back and present the issue again in a different way: I think of Section 4.1.1 as an API specification. In my entire career as a programmer I have never encountered an API specification that said that some parameters were optional yet callers were required to specify them by implementations that claimed conformance. You all are more knowledgeable and experienced with this specification than I am, and I am not sure I am presenting my case sufficiently, but my gut instinct as a programmer tells me something is wrong with either the specification, or the implementation's claim of conformance. If you think other programmers will find themselves similarly puzzled, please fix the specification (I don't know what is the fix but I am convinced a fix is needed if implementations as discussed earlier can be said to be confirming while they require optional parameters.) Thanks for listening so far. I rest my case. On Mon, Jan 9, 2012 at 6:24 PM, William Mills wrote: > I am just not yet convinced that it should be REQUIRED. I think the fact > that we have default language for servers to insert a NULL value for > omitted params is sufficient. Do we need that here too? Would that make > it clearer? > > ------------------------------ > *From:* agks mehx > *To:* William Mills ; oauth@ietf.org > *Cc:* SM ; Eran Hammer > *Sent:* Monday, January 9, 2012 5:57 PM > > *Subject:* Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in > Specification > > That's fine and still consistent with the essence of (a), which is to > require implementations to accept requests without a scope parameter. If > an implementation chooses to issue scoped credentials, that's perfectly > fine. > > My focus is solely on whether the scope parameter should be termed as > OPTIONAL or REQUIRED within the specification. > > Perhaps, (b) is a better choice -- to make it REQUIRED? > > On Mon, Jan 9, 2012 at 5:51 PM, William Mills wrote: > > Re your "a" below: No, implementations may issue scoped credentials if > they have a default scope. It says elsewhere in the spec that the scope > issued by the server may not match the requested scope, which is why the > server returns a scope value. This is for informational purposes only for > the client so it can know what scopes it should already have. > > You don't have to support empty scopes, and it would be completely valid > for the auth server to reject a request for an unknown scope, which could > include the empty scope if the auth server doesn't support it. > > -bill > > ------------------------------ > *From:* agks mehx > *To:* William Mills ; oauth@ietf.org > *Cc:* SM ; Eran Hammer > *Sent:* Monday, January 9, 2012 5:44 PM > > *Subject:* Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in > Specification > > scope parameter in the HTTP requests. > > Two choices stand out to me: (a) keep the scope parameter truly optional > which implies requiring all implementations to implement un-scoped > credentials; (b) make the scope parameter REQUIRED thus removing the > confusion and letting implementations choose whether or not they want to > allow an empty scope. > > The former, (a), imposes a little bit of extra work for implementations > but benefits users, clients, and arguably implementations, by allowing the > un-scoped credentials use-case. > > The latter, (b), merely improves the quality of the specification -- I do > not see what purpose is served by calling the scope parameter OPTIONAL when > vendors are free to require it as they please and still claim conformance. > > On Mon, Jan 9, 2012 at 4:53 PM, William Mills wrote: > > There are definitely use cases for un-scoped credentials, which the > implementations I have seen implement as an empty scope. Are you worried > specifically about the scope parameter in the HTTP requests, or as > represented in the credential used to access the PR? > > ------------------------------ > *From:* agks mehx > *To:* SM ; Eran Hammer ; > oauth@ietf.org > *Sent:* Monday, January 9, 2012 4:17 PM > *Subject:* Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in > Specification > > Hi SM and Eran, > > I am confused again, after re-reading Eran's response, whether or not an > implementation that rejects *missing* (as opposed to empty) scope is > conformant or not. (Eran, your response was a bit ambiguous on whether an > implementation is free to error out on an missing scope parameter or not -- > I can clearly see it is free to error out on an empty scope parameter, but > that's a different situation than the one I am concerned about.) > > The vendor definitely gives a higher priority to claiming conformance and > I believe they would change their implementation, but they believe they are > conformant. > > I do feel the IETF Working Group should make this part of the spec less > ambiguous -- why not just make 'scope' REQUIRED and end the misery? Or, > make it clear that an implementation is not conformant to the spec if it > requires optional parameters? > > Additionally, I will resend a use-case for the no-scope parameter because > my earlier reply unintentionally went privately to Eran and not to the list: > > I can suggest a spec modification that says that an implementation MUST > accept a request without a scope parameter, in which case one possibility > for an implementing server is to return an access token or code that does > not allow any operations. The purpose of this otherwise "useless" > token/code is that the OAuth server confirms that the user is *some* user > without any information on *which* user it is. (If the user is not > authenticated by the vendor then of course no valid token/code is returned.) > > An example might help: Facebook, when it started, would manage social > networks based on college email domain -- harvard.edu, etc. Facebook > used to do it by asking for your email address and sending a confirmation > mail. But what if I wanted to tell Facebook just the fact that I was at > foo.edu but I did not want to share my email address with Facebook, or > any other unique identifier? If the spec required implementations to work > without a scope parameter, it would solve this use case perfectly. > Facebook wouldn't really care about my school email address or unique id > -- I could use my non-school personal email and all Facebook wanted to know > was whether I should be in that school network or not simply by using the > barebones no-scope OAuth request. > > Vendors do not lose anything if the spec requires such no-scope requests > to be fulfilled. They are merely confirming that a user is *some* user with > the user's consent. There are valid cases on the client side such as > determining network membership without needing network identity. And it > cleans out the optional semantics of scope. > > Users win in that they have a way to confirm network membership without > having to reveal a unique identifier. > > Clients win in that users will be more willing to confirm network > membership if they are not also required to reveal a unique identitfier. > > This is off-the-cuff but I will be very happy to formalize it and present > it to the list. I hope the essential concept made it through my writing! > > A. > > On Mon, Jan 9, 2012 at 3:47 PM, SM wrote: > > Hello, > > At 15:14 09-01-2012, agks mehx wrote: > > Thank you for the response. If I understand correctly, the vendor is > correctly that their implementation conforms to the specification even > though it rejects requests that do not specify the scope parameter. That > answers my question. > > > The better answer is from Eran ( > http://www.ietf.org/mail-archive/web/oauth/current/msg08194.html ). > > > Whether I was asking for (i) a clarification; or (ii) trying to resolve a > disagreement. I think I was trying to verify whether indeed there was a > disagreement. I. e. whether my understanding of the specification was > correct or not. It seems I was mistaken in understanding the spec. > > > See comment below. > > > There is no disagreement with the vendor at this point because the two > responses from this list indicate that the vendor is right. (I still don't > understand why scope isn't made a required parameter in the specification > so that such confusion can be avoided, but that's a minor point.) > > > You locked in on the term "optional" without going into the details of the > draft. I would not claim conformance with a specification if my API > specifies that the optional parts are required as someone writing an > implementation from the draft will run into the same problem as you. > Saying that the vendor is wrong will not get them to fix it. > > Regards, > -sm > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > --20cf303f6d586a25bb04b626db01 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Please allow me to step-back and present the issue again in a different way= :

I think of Section 4.1.1 as an API specification. =A0I= n my entire career as a programmer I have never encountered an API specific= ation that said that some parameters were optional yet callers were require= d to specify them by implementations that claimed conformance.

You all are more knowledgeable and experienced with thi= s specification than I am, and I am not sure I am presenting my case suffic= iently, but my gut instinct as a programmer tells me something is wrong wit= h either the specification, or the implementation's claim of conformanc= e.

If you think other programmers will find themselves sim= ilarly puzzled, please fix the specification (I don't know what is the = fix but I am convinced a fix is needed if implementations as discussed earl= ier can be said to be confirming while they require optional parameters.)

Thanks for listening so far. I rest my case.

On Mon, Jan 9, 2012 at 6:24 PM, William Mills <wmills@yahoo-inc.c= om> wrote:
I am just not yet convinced that it should be REQUIRED.=A0 I thi= nk the fact that we have default language for servers to insert a NULL valu= e for omitted params is sufficient.=A0 Do we need that here too?=A0 Would t= hat make it clearer?

From: agks= mehx <agksmehx@= gmail.com>
To: Wi= lliam Mills <w= mills@yahoo-inc.com>; oauth@ietf.org
Cc: SM <sm@resistor.net>; Eran Hammer <eran@hueniver= se.com>
Sent:<= /b> Monday, January 9, 2012 5:57 PM

<= b>Subject: Re: [OAUTH-WG] Seeki= ng Clarification: Potential Ambiguity in Specification

That's fine and still consistent with the essence of (a), which is= to require implementations to accept requests without a scope parameter. = =A0If an implementation chooses to issue scoped credentials, that's per= fectly fine.

My focus is solely on whether the scope parameter should be = termed as OPTIONAL or REQUIRED within the specification.

Perhaps, (b) is a better choice -- to make it REQUIRED?

On Mon, Jan 9, 2012 at 5:51 PM, William Mills <wmills= @yahoo-inc.com> wrote:
Re your &qu= ot;a" below: No, implementations may issue scoped credentials if they = have a default scope.=A0 It says elsewhere in the spec that the scope issue= d by the server may not match the requested scope, which is why the server = returns a scope value.=A0 This is for informational purposes only for the c= lient so it can know what scopes it should already have.

You don't have to support empty scopes= , and it would be completely valid for the auth server to reject a request = for an unknown scope, which could include the empty scope if the auth serve= r doesn't support it.

-bill

From: agks mehx <agksmehx@gmail.com>
= To: William Mills <wmills@ya= hoo-inc.com>; oauth@ietf.org
Cc: SM <sm@resistor.net>= ;; Eran Hammer <eran@hueniverse.com>
Sent: Monday, January 9, 20= 12 5:44 PM

Sub= ject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity = in Specification

scope parameter= in the HTTP requests.

Two choices stand out to me: =A0(= a) keep the scope parameter truly optional which implies requiring all impl= ementations to implement un-scoped credentials; =A0(b) make the scope param= eter REQUIRED thus removing the confusion and letting implementations choos= e whether or not they want to allow an empty scope.

The former, (a), imposes a little bit of extra work for= implementations but benefits users, clients, and arguably implementations,= by allowing the un-scoped credentials use-case.

The latter, (b), merely improves the quality of the specification -- I do n= ot see what purpose is served by calling the scope parameter OPTIONAL when = vendors are free to require it as they please and still claim conformance.<= /div>

On Mon, Jan 9, 2012 at 4:53 PM, William Mills <wmills@yahoo-inc.com> wrote:
There are d= efinitely use cases for un-scoped credentials, which the implementations I = have seen implement as an empty scope.=A0 Are you worried specifically abou= t the scope parameter in the HTTP requests, or as represented in the creden= tial used to access the PR?

From: agks mehx <agksmehx= @gmail.com>
To: S= M <sm@resistor.net>; Eran Hammer <eran@hueniverse.com>; oauth@ietf.= org
Sent: Monday, January 9, 2012 4:17 PM
Su= bject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity= in Specification

Hi SM and Eran,

I am confused again, after re-readi= ng Eran's response, whether or not an implementation that rejects *miss= ing* (as opposed to empty) scope is conformant or not. =A0(Eran, your respo= nse was a bit ambiguous on whether an implementation is free to error out o= n an missing scope parameter or not -- I can clearly see it is free to erro= r out on an empty scope parameter, but that's a different situation tha= n the one I am concerned about.)

The vendor definitely gives a higher priority to claimi= ng conformance and I believe they would change their implementation, but th= ey believe they are conformant.

I do feel the IETF= Working Group should make this part of the spec less ambiguous -- why not = just make 'scope' REQUIRED and end the misery? =A0Or, make it clear= that an implementation is not conformant to the spec if it requires option= al parameters?

Additionally, I will resend a use-case for the no-scope= parameter because my earlier reply unintentionally went privately to Eran = and not to the list:

I can suggest a spec modification that says that an implementation MUST acc= ept a request without a scope parameter, in which case one possibility for = an implementing server is to return an access token or code that does not a= llow any operations. =A0The purpose of this otherwise "useless" t= oken/code is that the OAuth server confirms that the user is *some* user wi= thout any information on *which* user it is. =A0(If the user is not authent= icated by the vendor then of course no valid token/code is returned.)

An example might help: =A0Fac= ebook, when it started, would manage social networks based on college email= domain --=A0harvard.edu, etc. =A0Facebook used to= do it by asking for your email address and sending a confirmation mail. = =A0But what if I wanted to tell Facebook just the fact that I was at=A0foo.edu=A0but I did not want to share my email address wit= h Facebook, or any other unique identifier? =A0If the spec required impleme= ntations to work without a scope parameter, it would solve this use case pe= rfectly. =A0Facebook wouldn't really care about my school email address or unique id -- I could use my non-school personal email and= all Facebook wanted to know was whether I should be in that school network= or not simply by using the barebones no-scope OAuth request.

Vendors do not lose anything = if the spec requires such no-scope requests to be fulfilled. They are merel= y confirming that a user is *some* user with the user's consent. =A0The= re are valid cases on the client side such as determining network membershi= p without needing network identity. =A0And it cleans out the optional seman= tics of scope.

Users win in that they have a= way to confirm network membership without having to reveal a unique identi= fier.

Clients win in that users wil= l be more willing to confirm network membership if they are not also requir= ed to reveal a unique identitfier.

This is off-the-cuff but I wi= ll be very happy to formalize it and present it to the list. =A0I hope the = essential concept made it through my writing!

A.

On Mon, Jan 9, 2012 at 3:47= PM, SM <sm@resistor.net> wrote:
Hello,

At 15:14 09-01-2012, agks mehx wrote:
Thank you for the response. =A0If I understand correctly, the vendor is cor= rectly that their implementation conforms to the specification even though = it rejects requests that do not specify the scope parameter. =A0That answer= s my question.

The better answer is from Eran ( http:= //www.ietf.org/mail-archive/web/oauth/current/msg08194.html ).


Whether I was asking for (i) a clarification; or (ii) trying to resolve a d= isagreement. =A0I think I was trying to verify whether indeed there was a d= isagreement. I. e. whether my understanding of the specification was correc= t or not. =A0It seems I was mistaken in understanding the spec.

See comment below.


There is no disagreement with the vendor at this point because the two resp= onses from this list indicate that the vendor is right. =A0(I still don'= ;t understand why scope isn't made a required parameter in the specific= ation so that such confusion can be avoided, but that's a minor point.)=

You locked in on the term "optional" without going into the detai= ls of the draft. =A0I would not claim conformance with a specification if m= y API specifies that the optional parts are required as someone writing an = implementation from the draft will run into the same problem as you. =A0Say= ing that the vendor is wrong will not get them to fix it.

Regards,
-sm


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







--20cf303f6d586a25bb04b626db01-- From wmills@yahoo-inc.com Tue Jan 10 09:21:03 2012 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 690BA21F878A for ; Tue, 10 Jan 2012 09:21:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.849 X-Spam-Level: X-Spam-Status: No, score=-16.849 tagged_above=-999 required=5 tests=[AWL=-0.135, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, 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 lgZs-1+vFRCQ for ; Tue, 10 Jan 2012 09:21:01 -0800 (PST) Received: from nm3-vm0.bullet.mail.sp2.yahoo.com (nm3-vm0.bullet.mail.sp2.yahoo.com [98.139.90.230]) by ietfa.amsl.com (Postfix) with SMTP id C809021F8772 for ; Tue, 10 Jan 2012 09:21:01 -0800 (PST) Received: from [98.139.91.68] by nm3.bullet.mail.sp2.yahoo.com with NNFMP; 10 Jan 2012 17:20:59 -0000 Received: from [98.139.91.8] by tm8.bullet.mail.sp2.yahoo.com with NNFMP; 10 Jan 2012 17:19:59 -0000 Received: from [127.0.0.1] by omp1008.mail.sp2.yahoo.com with NNFMP; 10 Jan 2012 17:19:59 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 103268.86968.bm@omp1008.mail.sp2.yahoo.com Received: (qmail 49706 invoked by uid 60001); 10 Jan 2012 17:19:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1326215998; bh=a3kyhsfU1TmTB7VtMN6ekKq6ukP3+m3mmW6nsfdkwGQ=; 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=ZFtmhwxpNdLy7VOPzBkleWhfWTmhgN1oWUOPSs+DPbXuAQzgglPgBpSU5Oo5EeZizE8Lu+viKeb89C67I1esW2ncKNup/sSU2Dpg7Zfm9RnDY54ZKqqYqLWv/ii7BwnQr9czY21G0IlPq6AMo5kYdkwQ7hV/ONxKPfvpUynewNA= 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=nVhjkeGzwnt+byXhUu+k0cb8xD3DcBL6kJorebomVEV30x0vLCySndcgEMymLOU0wOmz35q13LPuwu2yAu2n/X1B+oB17qF5dd8ZFWEem6pPKUQ7UY6CQBC9At5b1jDShvRl2O6lJCTikfbC37/rGF0S9hoyucIn23qd4Hi+j4s=; X-YMail-OSG: 8mi6Co4VM1kEzeMqDyfXux6mqeXlJFZYiofeIqZ6pB5Xlo2 yBOwz97w2AkBaTbECqbtmOZFAkcG645VM19sgpFqJv3m5qaV7ZsOJvsLVcWh rpQQnuZmhjahb4E0ucSk0YsfGXuUFpSH0410NjrJ7d2uQYSm8FpASH.5yBNG LqRMaISae.H_LAOgtTSLUrdMK9qjxoSrnRfMyO43ngDn1iWDhZJA4Ey2LMlF VNUmslk2FAbKK63iD6QGQItpW2Z0WKBc6bfpj8ABFQnO2BCQ504K6ApgpTPK vptf2lRXml18FDJ7SnmjxLp.zgRPPQvStm4fEoizvfUiSTkrEticBwX3uQ2l SEEcKrl89hfLdw62DIBkIIfq1bKj8tePVIUoW_CSMozyRWEgE3cxYREuydIc VQ.e5zgIVZOHpMqwcokef_PN7sEfBBpXq_Mgjf1V8VnRvNaiFe2X39MIHVGR wmYBtNkdXMWUJGvjAMNmvBqAQ.oFLbvbIBSubWtMePHt7KlQTsCDw4I1t75s LD.kVtGbO_oZ8_l8yBeJbxUE9Gw-- Received: from [209.131.62.115] by web31816.mail.mud.yahoo.com via HTTP; Tue, 10 Jan 2012 09:19:57 PST X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.116.331537 References: <6.2.5.6.2.20120109070921.0aec8d00@resistor.net> <6.2.5.6.2.20120109153323.0ab3bf80@resistor.net> <1326156786.88572.YahooMailNeo@web31812.mail.mud.yahoo.com> <1326160314.71861.YahooMailNeo@web31806.mail.mud.yahoo.com> <1326162276.40306.YahooMailNeo@web31811.mail.mud.yahoo.com> Message-ID: <1326215997.44445.YahooMailNeo@web31816.mail.mud.yahoo.com> Date: Tue, 10 Jan 2012 09:19:57 -0800 (PST) From: William Mills To: agks mehx , Eran Hammer , "oauth@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1238014912-2107763349-1326215997=:44445" Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification 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, 10 Jan 2012 17:21:03 -0000 ---1238014912-2107763349-1326215997=:44445 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable That does clear it up!=A0 If the implementation returns a proper error when= the scope is omitted then it will be in conformance.=A0 Sending an error r= esult for the empty scope is valid.=A0 =0A=0A=0A=0A________________________= ________=0A From: agks mehx =0ATo: William Mills ; Eran Hammer ; oauth@ietf.org =0ACc: = SM =0ASent: Monday, January 9, 2012 10:45 PM=0ASubject: R= e: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification= =0A =0A=0APlease allow me to step-back and present the issue again in a dif= ferent way:=0A=0AI think of Section 4.1.1 as an API specification. =A0In my= entire career as a programmer I have never encountered an API specificatio= n that said that some parameters were optional yet callers were required to= specify them by implementations that claimed conformance.=0A=0AYou all are= more knowledgeable and experienced with this specification than I am, and = I am not sure I am presenting my case sufficiently, but my gut instinct as = a programmer tells me something is wrong with either the specification, or = the implementation's claim of conformance.=0A=0AIf you think other programm= ers will find themselves similarly puzzled, please fix the specification (I= don't know what is the fix but I am convinced a fix is needed if implement= ations as discussed earlier can be said to be confirming while they require= optional parameters.)=0A=0AThanks for listening so far. I rest my case.=0A= =0A=0AOn Mon, Jan 9, 2012 at 6:24 PM, William Mills = wrote:=0A=0AI am just not yet convinced that it should be REQUIRED.=A0 I th= ink the fact that we have default language for servers to insert a NULL val= ue for omitted params is sufficient.=A0 Do we need that here too?=A0 Would = that make it clearer?=0A>=0A>=0A>=0A>=0A>________________________________= =0A> From: agks mehx =0A>To: William Mills ; oauth@ietf.org =0A>Cc: SM ; Eran Hammer =0A>Sent: Monday, January 9, 2012 5:57 PM=0A>=0A>Subject: R= e: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification= =0A> =0A>=0A>=0A>That's fine and still consistent with the essence of (a), = which is to require implementations to accept requests without a scope para= meter. =A0If an implementation chooses to issue scoped credentials, that's = perfectly fine.=0A>=0A>=0A>My focus is solely on whether the scope paramete= r should be termed as OPTIONAL or REQUIRED within the specification.=0A>=0A= >=0A>Perhaps, (b) is a better choice -- to make it REQUIRED?=0A>=0A>=0A>On = Mon, Jan 9, 2012 at 5:51 PM, William Mills wrote:=0A= >=0A>Re your "a" below: No, implementations may issue scoped credentials if= they have a default scope.=A0 It says elsewhere in the spec that the scope= issued by the server may not match the requested scope, which is why the s= erver returns a scope value.=A0 This is for informational purposes only for= the client so it can know what scopes it should already have.=0A>>=0A>>=0A= >>=0A>>You don't have to support empty scopes, and it would be completely v= alid for the auth server to reject a request for an unknown scope, which co= uld include the empty scope if the auth server doesn't support it.=0A>>=0A>= >=0A>>-bill=0A>>=0A>>=0A>>=0A>>________________________________=0A>> From: = agks mehx =0A>>To: William Mills = ; oauth@ietf.org =0A>>Cc: SM ; Eran Hammer =0A>>Sent: Monday, January 9, 2012 5:44 PM=0A>>=0A>>Subject: Re: [OA= UTH-WG] Seeking Clarification: Potential Ambiguity in Specification=0A>> = =0A>>=0A>>=0A>>scope parameter in the HTTP requests.=0A>>=0A>>=0A>>Two choi= ces stand out to me: =A0(a) keep the scope parameter truly optional which i= mplies requiring all implementations to implement un-scoped credentials; = =A0(b) make the scope parameter REQUIRED thus removing the confusion and le= tting implementations choose whether or not they want to allow an empty sco= pe.=0A>>=0A>>=0A>>The former, (a), imposes a little bit of extra work for i= mplementations but benefits users, clients, and arguably implementations, b= y allowing the un-scoped credentials use-case.=0A>>=0A>>=0A>>The latter, (b= ), merely improves the quality of the specification -- I do not see what pu= rpose is served by calling the scope parameter OPTIONAL when vendors are fr= ee to require it as they please and still claim conformance.=0A>>=0A>>=0A>>= On Mon, Jan 9, 2012 at 4:53 PM, William Mills wrote:= =0A>>=0A>>There are definitely use cases for un-scoped credentials, which t= he implementations I have seen implement as an empty scope.=A0 Are you worr= ied specifically about the scope parameter in the HTTP requests, or as repr= esented in the credential used to access the PR?=0A>>>=0A>>>=0A>>>=0A>>>=0A= >>>________________________________=0A>>> From: agks mehx =0A>>>To: SM ; Eran Hammer ; oauth= @ietf.org =0A>>>Sent: Monday, January 9, 2012 4:17 PM=0A>>>Subject: Re: [OA= UTH-WG] Seeking Clarification: Potential Ambiguity in Specification=0A>>>= =0A>>>=0A>>>=0A>>>Hi SM and Eran,=0A>>>=0A>>>=0A>>>I am confused again, aft= er re-reading Eran's response, whether or not an implementation that reject= s *missing* (as opposed to empty) scope is conformant or not. =A0(Eran, you= r response was a bit ambiguous on whether an implementation is free to erro= r out on an missing scope parameter or not -- I can clearly see it is free = to error out on an empty scope parameter, but that's a different situation = than the one I am concerned about.)=0A>>>=0A>>>=0A>>>=0A>>>The vendor defin= itely gives a higher priority to claiming conformance and I believe they wo= uld change their implementation, but they believe they are conformant.=0A>>= >=0A>>>=0A>>>I do feel the IETF Working Group should make this part of the = spec less ambiguous -- why not just make 'scope' REQUIRED and end the miser= y? =A0Or, make it clear that an implementation is not conformant to the spe= c if it requires optional parameters?=0A>>>=0A>>>=0A>>>Additionally, I will= resend a use-case for the no-scope parameter because my earlier reply unin= tentionally went privately to Eran and not to the list:=0A>>>=0A>>>=0A>>>I = can suggest a spec modification that says that an implementation MUST accep= t a request without a scope parameter, in which case one possibility for an= implementing server is to return an access token or code that does not all= ow any operations. =A0The purpose of this otherwise "useless" token/code is= that the OAuth server confirms that the user is *some* user without any in= formation on *which* user it is. =A0(If the user is not authenticated by th= e vendor then of course no valid token/code is returned.)=0A>>>=0A>>>=0A>>>= An example might help: =A0Facebook, when it started, would manage social ne= tworks based on college email domain --=A0harvard.edu, etc. =A0Facebook use= d to do it by asking for your email address and sending a confirmation mail= . =A0But what if I wanted to tell Facebook just the fact that I was at=A0fo= o.edu=A0but I did not want to share my email address with Facebook, or any = other unique identifier? =A0If the spec required implementations to work wi= thout a scope parameter, it would solve this use case perfectly. =A0Faceboo= k wouldn't really care about my school email address or unique id -- I coul= d use my non-school personal email and all Facebook wanted to know was whet= her I should be in that school network or not simply by using the barebones= no-scope OAuth request.=0A>>>=0A>>>=0A>>>Vendors do not lose anything if t= he spec requires such no-scope requests to be fulfilled. They are merely co= nfirming that a user is *some* user with the user's consent. =A0There are v= alid cases on the client side such as determining network membership withou= t needing network identity. =A0And it cleans out the optional semantics of = scope.=0A>>>=0A>>>=0A>>>Users win in that they have a way to confirm networ= k membership without having to reveal a unique identifier.=0A>>>=0A>>>=0A>>= >Clients win in that users will be more willing to confirm network membersh= ip if they are not also required to reveal a unique identitfier.=0A>>>=0A>>= >=0A>>>This is off-the-cuff but I will be very happy to formalize it and pr= esent it to the list. =A0I hope the essential concept made it through my wr= iting!=0A>>>=0A>>>=0A>>>A.=0A>>>=0A>>>=0A>>>On Mon, Jan 9, 2012 at 3:47 PM,= SM wrote:=0A>>>=0A>>>Hello,=0A>>>>=0A>>>>At 15:14 09-01-= 2012, agks mehx wrote:=0A>>>>=0A>>>>Thank you for the response. =A0If I und= erstand correctly, the vendor is correctly that their implementation confor= ms to the specification even though it rejects requests that do not specify= the scope parameter. =A0That answers my question.=0A>>>>>=0A>>>>=0AThe bet= ter answer is from Eran ( http://www.ietf.org/mail-archive/web/oauth/curren= t/msg08194.html ).=0A>>>>=0A>>>>=0A>>>>=0A>>>>Whether I was asking for (i) = a clarification; or (ii) trying to resolve a disagreement. =A0I think I was= trying to verify whether indeed there was a disagreement. I. e. whether my= understanding of the specification was correct or not. =A0It seems I was m= istaken in understanding the spec.=0A>>>>>=0A>>>>=0ASee comment below.=0A>>= >>=0A>>>>=0A>>>>=0A>>>>There is no disagreement with the vendor at this poi= nt because the two responses from this list indicate that the vendor is rig= ht. =A0(I still don't understand why scope isn't made a required parameter = in the specification so that such confusion can be avoided, but that's a mi= nor point.)=0A>>>>>=0A>>>>=0AYou locked in on the term "optional" without g= oing into the details of the draft. =A0I would not claim conformance with a= specification if my API specifies that the optional parts are required as = someone writing an implementation from the draft will run into the same pro= blem as you. =A0Saying that the vendor is wrong will not get them to fix it= .=0A>>>>=0A>>>>Regards,=0A>>>>-sm =0A>>>>=0A>>>=0A>>>=0A>>>________________= _______________________________=0A>>>OAuth mailing list=0A>>>OAuth@ietf.org= =0A>>>https://www.ietf.org/mailman/listinfo/oauth=0A>>>=0A>>>=0A>>>=0A>>=0A= >>=0A>>=0A>=0A>=0A> ---1238014912-2107763349-1326215997=:44445 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
That does clear it up!  If the implementation returns a proper error= when the scope is omitted then it will be in conformance.  Sending an= error result for the empty scope is valid. 
From: agks mehx <agksmehx@gmail.com>
To: William Mills <wmills@yahoo-inc.c= om>; Eran Hammer <eran@hueniverse.com>; oauth@ietf.org
Cc: SM <sm@resistor.net> Sent: Monday, January 9, 2012 10:4= 5 PM
Subject: Re: [OAU= TH-WG] Seeking Clarification: Potential Ambiguity in Specification

=0A
Please allow me to step-back an= d present the issue again in a different way:

I think of= Section 4.1.1 as an API specification.  In my entire career as a prog= rammer I have never encountered an API specification that said that some pa= rameters were optional yet callers were required to specify them by impleme= ntations that claimed conformance.
=0A

You all are = more knowledgeable and experienced with this specification than I am, and I= am not sure I am presenting my case sufficiently, but my gut instinct as a= programmer tells me something is wrong with either the specification, or t= he implementation's claim of conformance.
=0A

If yo= u think other programmers will find themselves similarly puzzled, please fi= x the specification (I don't know what is the fix but I am convinced a fix = is needed if implementations as discussed earlier can be said to be confirm= ing while they require optional parameters.)
=0A

Th= anks for listening so far. I rest my case.

On Mon, Jan 9, 2012 at 6:24 PM, William Mills <wmills@yahoo-inc.com&g= t; wrote:
=0A
=0A
I am just = not yet convinced that it should be REQUIRED.  I think the fact that w= e have default language for servers to insert a NULL value for omitted para= ms is sufficient.  Do we need that here too?  Would that make it = clearer?
=0A

=
=0A <= hr size=3D"1"> From: agks = mehx <agksmehx@gmail.com> To: William Mills <wmills@yahoo-inc.com>; oauth@ietf.org
=0ACc: SM <sm@resistor.n= et>; Eran Hammer=0A <eran@h= ueniverse.com>
Sent:= Monday, January 9, 2012 5:57 PM

Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specificatio= n
=0A

=0A
That's fine and still consistent with the essence of (a= ), which is to require implementations to accept requests without a scope p= arameter.  If an implementation chooses to issue scoped credentials, t= hat's perfectly fine.
=0A=0A
My focus is solely on whethe= r the scope parameter should be termed as OPTIONAL or REQUIRED within the s= pecification.

Perhaps, (b) is a better choice -- t= o make it REQUIRED?

=0A
=0AOn Mon, Jan 9, 2012 at 5:51 PM, Willi= am Mills <wmil= ls@yahoo-inc.com> wrote:
=0A=0A
Re your "a" below: No= , implementations may issue scoped credentials if they have a default scope= .  It says elsewhere in the spec that the scope issued by the server m= ay not match the requested scope, which is why the server returns a scope v= alue.  This is for informational purposes only for the client so it ca= n know what scopes it should already have.
=0A=0A

<= /div>
You don't have to support empty scopes, and it would be completel= y valid for the auth server to reject a request for an unknown scope, which= could include the empty scope if the auth server doesn't support it.
= =0A=0A

-bill

=
=0A=0A
= From: agks mehx <agksmehx@gmail.com>
To: William Mills <wmills@yahoo-inc.com>; oauth@ietf.org
=0A=0ACc: SM <sm@resistor.net&g= t;; Eran Hammer <eran@hueniverse.c= om>
=0A=0A Sent:= Monday, January 9, 2012 5:44 PM

Subject: Re: [OAUTH-WG] Seeking Clarificatio= n: Potential Ambiguity in Specification
=0A=0A

=0A
= scope parameter in the HTTP requests.

Two choices= stand out to me:  (a) keep the scope parameter truly optional which i= mplies requiring all implementations to implement un-scoped credentials; &n= bsp;(b) make the scope parameter REQUIRED thus removing the confusion and l= etting implementations choose whether or not they want to allow an empty sc= ope.
=0A=0A=0A

The former, (a), imposes a little bi= t of extra work for implementations but benefits users, clients, and arguab= ly implementations, by allowing the un-scoped credentials use-case.

=0A=0A=0AThe latter, (b), merely improves the quality of = the specification -- I do not see what purpose is served by calling the sco= pe parameter OPTIONAL when vendors are free to require it as they please an= d still claim conformance.
=0A=0A=0A

On Mon, Jan 9, 2012 = at 4:53 PM, William Mills <wmills@yahoo-inc.com> wrote:
=0A=0A= =0A
The= re are definitely use cases for un-scoped credentials, which the implementa= tions I have seen implement as an empty scope.  Are you worried specif= ically about the scope parameter in the HTTP requests, or as represented in= the credential used to access the PR?
=0A=0A=0A

= =0A=0A=0A From: agks mehx = <agksmehx@gmail.com>
<= span style=3D"font-weight:bold;">To: SM <sm@resistor.net>; Eran Hammer <eran@hueniverse.com>; oaut= h@ietf.org
=0A=0A=0A Sent:=0A Monday, January 9, 2012 4:17 PM
Subject: Re: [OAUTH-WG] Seeking Clarification: Potentia= l Ambiguity in Specification

=0A
H= i SM and Eran,

I am confused again, after re-reading Era= n's response, whether or not an implementation that rejects *missing* (as o= pposed to empty) scope is conformant or not.  (Eran, your response was= a bit ambiguous on whether an implementation is free to error out on an mi= ssing scope parameter or not -- I can clearly see it is free to error out o= n an empty scope parameter, but that's a different situation than the one I= am concerned about.)
=0A=0A=0A=0A

The vendor definit= ely gives a higher priority to claiming conformance and I believe they woul= d change their implementation, but they believe they are conformant.
<= div>
I do feel the IETF Working Group should make this part o= f the spec less ambiguous -- why not just make 'scope' REQUIRED and end the= misery?  Or, make it clear that an implementation is not conformant t= o the spec if it requires optional parameters?
=0A=0A=0A=0A

Additionally, I will resend a use-case for the no-scope parameter = because my earlier reply unintentionally went privately to Eran and not to = the list:

=0A=0A=0A=0AI can su= ggest a spec modification that says that an implementation MUST accept a re= quest without a scope parameter, in which case one possibility for an imple= menting server is to return an access token or code that does not allow any= operations.  The purpose of this otherwise "useless" token/code is th= at the OAuth server confirms that the user is *some* user without any infor= mation on *which* user it is.  (If the user is not authenticated by th= e vendor then of course no valid token/code is returned.)
=0A=0A=0A=0A=

An example might help: &n= bsp;Facebook, when it started, would manage social networks based on colleg= e email domain -- harvard.edu, etc.  Fa= cebook used to do it by asking for your email address and sending a confirm= ation mail.  But what if I wanted to tell Facebook just the fact that = I was at foo.edu but I did not want to shar= e my email address with Facebook, or any other unique identifier?  If = the spec required implementations to work without a scope parameter, it wou= ld solve this use case perfectly.  Facebook wouldn't really care about= my school=0A email address or unique id -- I could use my non-school perso= nal email and all Facebook wanted to know was whether I should be in that s= chool network or not simply by using the barebones no-scope OAuth request.<= /div>=0A

Vendors do not lo= se anything if the spec requires such no-scope requests to be fulfilled. Th= ey are merely confirming that a user is *some* user with the user's consent= .  There are valid cases on the client side such as determining networ= k membership without needing network identity.  And it cleans out the = optional semantics of scope.
=0A=0A=0A=0A

Users win in that they have a way to confirm network m= embership without having to reveal a unique identifier.
=0A=0A=0A=0A
Clients win in that users w= ill be more willing to confirm network membership if they are not also requ= ired to reveal a unique identitfier.
=0A=0A=0A=0A
<= br>
This is off-the-cuff but I will be very happy = to formalize it and present it to the list.  I hope the essential conc= ept made it through my writing!
=0A=0A=0A=0A

= A.

On Mon, Jan 9, 2012 at 3:47 PM, SM = <sm@resistor.net> wrote:
=
=0A=0A=0A=0AHello,

=0AAt 15:14 09-01-2012, agks mehx wrot= e:
=0A
=0AThank you for the response.  If I understand cor= rectly, the vendor is correctly that their implementation conforms to the s= pecification even though it rejects requests that do not specify the scope = parameter.  That answers my question.
=0A=0A=0A=0A=0A
= =0A
=0AThe better answer is from Eran ( http://www.ietf.org/mail-archive/web/oauth/current/msg08194.html= ).
=0A
=0A
=0A
=0AWhether I was asking for (i) a cl= arification; or (ii) trying to resolve a disagreement.  I think I was = trying to verify whether indeed there was a disagreement. I. e. whether my = understanding of the specification was correct or not.  It seems I was= mistaken in understanding the spec.
=0A=0A=0A=0A=0A
=0A
=
=0ASee comment below.

=0A
=0A
=0AThere is no disa= greement with the vendor at this point because the two responses from this = list indicate that the vendor is right.  (I still don't understand why= scope isn't made a required parameter in the specification so that such co= nfusion can be avoided, but that's a minor point.)
=0A=0A=0A=0A=0A=0A
=0AYou locked in on the term "optional" without going i= nto the details of the draft.  I would not claim conformance with a sp= ecification if my API specifies that the optional parts are required as som= eone writing an implementation from the draft will run into the same proble= m as you.  Saying that the vendor is wrong will not get them to fix it= .
=0A=0A=0A=0A=0A
=0ARegards,
=0A-sm
= =0A

=0A

= _______________________________________________
OAuth mailing list
OAuth@ietf.org
https://ww= w.ietf.org/mailman/listinfo/oauth
=0A=0A=0A


=0A



=0A


=

=0A

---1238014912-2107763349-1326215997=:44445-- From sm@resistor.net Tue Jan 10 10:57:48 2012 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 E7AF021F8763 for ; Tue, 10 Jan 2012 10:57:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 OlsY6085C55k for ; Tue, 10 Jan 2012 10:57:45 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id B40FF21F86EC for ; Tue, 10 Jan 2012 10:57:45 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q0AIvdHH006431 for ; Tue, 10 Jan 2012 10:57:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1326221863; i=@resistor.net; bh=aaIcmOAr9vH44IIxxrGyH+v/6abKxxxbFXv8Iz3MSlI=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=LEm2nBM9FK6jEZIoqsS/7PDZQGihBWdn/mg2ledpMYjCInuMOsItfo7XTiNKzJZUK 0etyQRBj3byu3mJ8XmNaVpcmWI/sZOry81rYGJt/kpMuDjQH1xd8iCARBmS73kbpwO 6xSs9hVe6eL5uzgrZrgGFTH9DhIWHzauhWT7zQjo= Message-Id: <6.2.5.6.2.20120110104038.099f1ba8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 10 Jan 2012 10:56:37 -0800 To: oauth@ietf.org From: SM In-Reply-To: <1326215997.44445.YahooMailNeo@web31816.mail.mud.yahoo.com> References: <6.2.5.6.2.20120109070921.0aec8d00@resistor.net> <6.2.5.6.2.20120109153323.0ab3bf80@resistor.net> <1326156786.88572.YahooMailNeo@web31812.mail.mud.yahoo.com> <1326160314.71861.YahooMailNeo@web31806.mail.mud.yahoo.com> <1326162276.40306.YahooMailNeo@web31811.mail.mud.yahoo.com> <1326215997.44445.YahooMailNeo@web31816.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification 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, 10 Jan 2012 18:57:49 -0000 At 09:19 10-01-2012, William Mills wrote: >That does clear it up! If the implementation returns a proper error >when the scope is omitted then it will be in conformance. Sending >an error result for the empty scope is valid. Yes. It is not possible to get a clear view of the specs if the discussion about "ambiguity" relies on the meaning of the word "OPTIONAL" only. If there is a problem, then clarifying text could be used to fix it instead of changing the requirements. Regards, -sm From greg@enablenetworks.com Tue Jan 10 11:24:09 2012 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 6D5D421F8797 for ; Tue, 10 Jan 2012 11:24:09 -0800 (PST) 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 Sd9dtOiOPg8v for ; Tue, 10 Jan 2012 11:24:09 -0800 (PST) Received: from na3sys009aog110.obsmtp.com (na3sys009aog110.obsmtp.com [74.125.149.203]) by ietfa.amsl.com (Postfix) with SMTP id 7D97321F855E for ; Tue, 10 Jan 2012 11:24:08 -0800 (PST) Received: from mail-ww0-f49.google.com ([74.125.82.49]) (using TLSv1) by na3sys009aob110.postini.com ([74.125.148.12]) with SMTP ID DSNKTwyQS1a9OaHRtzmda3oRtV6MmlAk/DbQ@postini.com; Tue, 10 Jan 2012 11:24:08 PST Received: by mail-ww0-f49.google.com with SMTP id dt13so2661711wgb.30 for ; Tue, 10 Jan 2012 11:23:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.180.19.130 with SMTP id f2mr5643721wie.12.1326223435408; Tue, 10 Jan 2012 11:23:55 -0800 (PST) Received: by 10.227.28.87 with HTTP; Tue, 10 Jan 2012 11:23:55 -0800 (PST) Date: Tue, 10 Jan 2012 11:23:55 -0800 Message-ID: From: Gregory Prisament To: oauth@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [OAUTH-WG] Manual Authorization Codes -- Help/Feedback requested 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, 10 Jan 2012 19:30:04 -0000 Hello, I am developing a REST API and trying to follow the OAuth 2.0 protocol for authentication, and have a few questions for you good folks. The use case I'm interested in is native applications (such as linux command-line programs) that are unable or unwilling to involve a user-agent. =A0In this case, it seems redirection-based flows ("Authorization Code" and "Implicit Grant Types") are out! =A0That leaves "Client Credentials" and "Resource Owner Credentials". "Client Credentials" do not seem appropriate because the client may be installed on multiple machines and used by different resource owners. "Resource Owner Credentials" COULD work, but I'd rather not require the resource owner to reveal their username and password. One solution, which seems reasonable to me, would be to extend OAuth2 to include another grant type called "Manual Authorization Code". Using a web browser, the resource owner would login & authenticate with the authorization server (using session log-on, etc). =A0From there they could enter an Application ID and press a button "Generate Manual Authorization Code". =A0The resource owner would then type this Manual Authorization Code into the client, and the client could exchange it for an Access Token. But before I go down this route -- writing an extension, etc.. -- I wanted the WG's feedback. =A0It seems there are a few different ways to handle this use case and was curious which you think best matches the intentions of the OAuth2 spec. POSSIBLE APPROACHES: (1) "Manual Authorization Code" extension. See description above. (2) "Client Credentials" with each resource owner registering a separate cl= ient. We could achieve a similar effect to (1) by using "Client Credentials". Say the client is a command-line program "example-client-cli", which a large number of resource owners have downloaded and installed. Each resource owner would register the client with the authorization server and configure their local install by telling it the client_id and client_secret. (3) Something else entirely? QUESTIONS FOR YOUR: (Q1) Has the WG thought about this particular use case ("CLI clients") and do you have a recommended authorization approach. (Q2) Do Manual Authorization Codes make sense? Would anyone else find it useful to have - if I were to write up an extension document for it? Thanks in advanced for you help! Cheers, Greg Prisament Software Architect PowerCloud Systems From phil.hunt@oracle.com Tue Jan 10 11:32:54 2012 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 F0CF721F8688 for ; Tue, 10 Jan 2012 11:32:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.901 X-Spam-Level: X-Spam-Status: No, score=-5.901 tagged_above=-999 required=5 tests=[AWL=0.698, 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 v-DS3JaMPi5L for ; Tue, 10 Jan 2012 11:32:54 -0800 (PST) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id 0B2FC21F873B for ; Tue, 10 Jan 2012 11:32:53 -0800 (PST) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q0AJWqo8012755 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 10 Jan 2012 19:32:53 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q0AJWpIT027766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jan 2012 19:32:52 GMT Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q0AJWplb008043; Tue, 10 Jan 2012 13:32:51 -0600 Received: from [192.168.1.8] (/24.87.204.3) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 10 Jan 2012 11:32:50 -0800 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Phil Hunt In-Reply-To: <6.2.5.6.2.20120110104038.099f1ba8@resistor.net> Date: Tue, 10 Jan 2012 11:32:48 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6.2.5.6.2.20120109070921.0aec8d00@resistor.net> <6.2.5.6.2.20120109153323.0ab3bf80@resistor.net> <1326156786.88572.YahooMailNeo@web31812.mail.mud.yahoo.com> <1326160314.71861.YahooMailNeo@web31806.mail.mud.yahoo.com> <1326162276.40306.YahooMailNeo@web31811.mail.mud.yahoo.com> <1326215997.44445.YahooMailNeo@web31816.mail.mud.yahoo.com> <6.2.5.6.2.20120110104038.099f1ba8@resistor.net> To: SM X-Mailer: Apple Mail (2.1251.1) X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4F0C9265.007F,ss=1,re=0.000,fgs=0 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification 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, 10 Jan 2012 19:32:55 -0000 The underlying issue is that there was a decision not to in any way = standardize values for scope. I agreed this was reasonable since the underlying resource APIs are = likely to be very specific requiring some degree of prior knowledge by = the client app developer. Thus the resource server OAuth infrastructure = is free to decide what are and are not acceptable values including = missing or null values for scope. I think the specification is acceptable as it is. I note that other specifications that layer on top of OAuth2 such as = OpenID Connect may choose to strictly define acceptable values for = scope. This type of layering works well in my opinion. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-01-10, at 10:56 AM, SM wrote: > At 09:19 10-01-2012, William Mills wrote: >> That does clear it up! If the implementation returns a proper error = when the scope is omitted then it will be in conformance. Sending an = error result for the empty scope is valid. >=20 > Yes. >=20 > It is not possible to get a clear view of the specs if the discussion = about "ambiguity" relies on the meaning of the word "OPTIONAL" only. If = there is a problem, then clarifying text could be used to fix it instead = of changing the requirements. >=20 > Regards, > -sm=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From jricher@mitre.org Tue Jan 10 11:48:34 2012 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 3A9EF11E8071 for ; Tue, 10 Jan 2012 11:48:34 -0800 (PST) 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.000, 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 nmMMg1zJlMHl for ; Tue, 10 Jan 2012 11:48:33 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 74F7221F8806 for ; Tue, 10 Jan 2012 11:48:33 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C0DFF21B0AF1; Tue, 10 Jan 2012 14:48:29 -0500 (EST) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id AA2FB21B0AEF; Tue, 10 Jan 2012 14:48:29 -0500 (EST) Received: from [129.83.50.12] (129.83.31.51) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.1.339.1; Tue, 10 Jan 2012 14:48:29 -0500 Message-ID: <4F0C95DE.1000401@mitre.org> Date: Tue, 10 Jan 2012 14:47:42 -0500 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: Gregory Prisament References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [129.83.31.51] Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Manual Authorization Codes -- Help/Feedback requested 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, 10 Jan 2012 19:48:34 -0000 What you're describing is the Device Flow, which was pulled out of the main document a while ago and now sits here, somewhat outdated and unloved: http://tools.ietf.org/html/draft-recordon-oauth-v2-device-00 In this, the app gives the user a short code that they enter into a URL, do the authorization there, and get a short code back. It's effectively the same as the auth code flow, but it does the dance without HTTP redirects. -- Justin On 01/10/2012 02:23 PM, Gregory Prisament wrote: > Hello, > I am developing a REST API and trying to follow the OAuth 2.0 protocol > for authentication, and have a few questions for you good folks. > > The use case I'm interested in is native applications (such as linux > command-line programs) that are unable or unwilling to involve a > user-agent. In this case, it seems redirection-based flows > ("Authorization Code" and "Implicit Grant Types") are out! That > leaves "Client Credentials" and "Resource Owner Credentials". > > "Client Credentials" do not seem appropriate because the client may be > installed on multiple machines and used by different resource owners. > > "Resource Owner Credentials" COULD work, but I'd rather not require > the resource owner to reveal their username and password. > > One solution, which seems reasonable to me, would be to extend OAuth2 > to include another grant type called "Manual Authorization Code". > Using a web browser, the resource owner would login& authenticate > with the authorization server (using session log-on, etc). From there > they could enter an Application ID and press a button "Generate Manual > Authorization Code". The resource owner would then type this Manual > Authorization Code into the client, and the client could exchange it > for an Access Token. > > But before I go down this route -- writing an extension, etc.. -- I > wanted the WG's feedback. It seems there are a few different ways to > handle this use case and was curious which you think best matches the > intentions of the OAuth2 spec. > > POSSIBLE APPROACHES: > (1) "Manual Authorization Code" extension. > See description above. > > (2) "Client Credentials" with each resource owner registering a separate client. > We could achieve a similar effect to (1) by using "Client > Credentials". Say the client is a command-line program > "example-client-cli", which a large number of resource owners have > downloaded and installed. Each resource owner would register the > client with the authorization server and configure their local install > by telling it the client_id and client_secret. > > (3) Something else entirely? > > QUESTIONS FOR YOUR: > (Q1) Has the WG thought about this particular use case ("CLI clients") > and do you have a recommended authorization approach. > (Q2) Do Manual Authorization Codes make sense? Would anyone else find > it useful to have - if I were to write up an extension document for > it? > > > Thanks in advanced for you help! > Cheers, > Greg Prisament > Software Architect > PowerCloud Systems > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Tue Jan 10 13:15:57 2012 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 9787211E807F for ; Tue, 10 Jan 2012 13:15:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 TQTM0315J1oo for ; Tue, 10 Jan 2012 13:15:56 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id CD20A11E8071 for ; Tue, 10 Jan 2012 13:15:56 -0800 (PST) Received: (qmail 12946 invoked from network); 10 Jan 2012 21:15:53 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.47) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 10 Jan 2012 21:15:53 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT005.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Tue, 10 Jan 2012 14:15:33 -0700 From: Eran Hammer To: "oauth@ietf.org" Date: Tue, 10 Jan 2012 14:15:13 -0700 Thread-Topic: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification Thread-Index: AczPzrtyNTFtRxfPRoaOekLZP1QN0wADTs4A Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453A72D0F24@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <6.2.5.6.2.20120109070921.0aec8d00@resistor.net> <6.2.5.6.2.20120109153323.0ab3bf80@resistor.net> <1326156786.88572.YahooMailNeo@web31812.mail.mud.yahoo.com> <1326160314.71861.YahooMailNeo@web31806.mail.mud.yahoo.com> <1326162276.40306.YahooMailNeo@web31811.mail.mud.yahoo.com> <1326215997.44445.YahooMailNeo@web31816.mail.mud.yahoo.com> <6.2.5.6.2.20120110104038.099f1ba8@resistor.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] Seeking Clarification: Potential Ambiguity in Specification 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, 10 Jan 2012 21:15:57 -0000 I don't think the issue here is about the scope value, but who does the OPT= IONAL designation applies to. IOW, is it optional for the server to support= /require it, or is it optional for the client to include or omit it. The intention was to make it optional for the authorization server to make = all decisions about the parameter, including making it required. But the te= xt is confusing since the text is aimed directly at the client when making = the request. We need to clarify this and the options are: 1. The client can decide if they want to include or omit the scope paramete= r. If omitted, the server must process the request using some documented de= fault scope. This default scope can be an empty scope rendering the token u= seless for anything other than verifying user authentication. 2. The server can declare scope to be a required parameter in which case th= e client must include it or the request will fail. In this case, we should = make the text clearer that clients to find out if the particular server req= uires it. #1 is better for interoperability, #2 is more in the spirit of the paramete= r discussions so far. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Phil Hunt > Sent: Tuesday, January 10, 2012 11:33 AM > To: SM > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in > Specification >=20 > The underlying issue is that there was a decision not to in any way > standardize values for scope. >=20 > I agreed this was reasonable since the underlying resource APIs are likel= y to > be very specific requiring some degree of prior knowledge by the client a= pp > developer. Thus the resource server OAuth infrastructure is free to decid= e > what are and are not acceptable values including missing or null values f= or > scope. >=20 > I think the specification is acceptable as it is. >=20 > I note that other specifications that layer on top of OAuth2 such as Open= ID > Connect may choose to strictly define acceptable values for scope. This t= ype > of layering works well in my opinion. >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >=20 >=20 > On 2012-01-10, at 10:56 AM, SM wrote: >=20 > > At 09:19 10-01-2012, William Mills wrote: > >> That does clear it up! If the implementation returns a proper error w= hen > the scope is omitted then it will be in conformance. Sending an error re= sult > for the empty scope is valid. > > > > Yes. > > > > It is not possible to get a clear view of the specs if the discussion a= bout > "ambiguity" relies on the meaning of the word "OPTIONAL" only. If there = is a > problem, then clarifying text could be used to fix it instead of changing= the > requirements. > > > > Regards, > > -sm > > _______________________________________________ > > 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 wmills@yahoo-inc.com Tue Jan 10 16:02:26 2012 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 66FB221F87FF for ; Tue, 10 Jan 2012 16:02:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.284 X-Spam-Level: X-Spam-Status: No, score=-17.284 tagged_above=-999 required=5 tests=[AWL=0.314, 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 GBNhsESSUJpd for ; Tue, 10 Jan 2012 16:02:25 -0800 (PST) Received: from nm11-vm0.bullet.mail.sp2.yahoo.com (nm11-vm0.bullet.mail.sp2.yahoo.com [98.139.91.240]) by ietfa.amsl.com (Postfix) with SMTP id 6901921F87EF for ; Tue, 10 Jan 2012 16:02:25 -0800 (PST) Received: from [98.139.91.67] by nm11.bullet.mail.sp2.yahoo.com with NNFMP; 11 Jan 2012 00:02:22 -0000 Received: from [98.139.91.14] by tm7.bullet.mail.sp2.yahoo.com with NNFMP; 11 Jan 2012 00:02:22 -0000 Received: from [127.0.0.1] by omp1014.mail.sp2.yahoo.com with NNFMP; 11 Jan 2012 00:02:22 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 249472.79588.bm@omp1014.mail.sp2.yahoo.com Received: (qmail 53687 invoked by uid 60001); 11 Jan 2012 00:02:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1326240141; bh=U3Ji+L+YD5BmAwB0kTK2LMGnRD3f89RoatcUsuQUIfo=; 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=g4v+6nVjhnocGWN/N2hfgpkCOmJykX5gvKcnbZg2tjkjDyq1Erc6reelD0yo3F6ftO0vY27wpKD8Ry3CNcxuioHpdQfYw8OSGB0NMbqrsFsUK9P5RrkMqKIBvNNX/llVZkywfhfrVcZXi43h1H5e699xANmhhrkxcvQsYQseF6A= 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=ggnwb9obD+E6jIVcdnFa04x8vH55F8Pjtig7Q4umoyXDmy/y0Un2elHc1+qez041jaPaZu0XfITzqfgGARU1rXIIxjSLXwRZckFK6WTKZAnp+qTgbMZqF0Mbjyjvi9LDNgapfSiUZXdI7H+GFeovz04+IfruYnOewZcXrvcmw08=; X-YMail-OSG: KuYkFCAVM1lVjCt5Z3MPFdI1WxeuyhScmAPOW14k6E1l2kd UMoPyNOliPE9U8KxUVvHXZTUB5qPPAwRitWcPPomG9nR4H9HeT2gyhh_ptFd _VqnEfIC13abW0ymSgGGZ.tGpUK4wxkmUroOStnjkhb1mZGbIvHnyLn0SwOK x7m4WHTOt6oXxQTXig3sE9FSi9dac3pHDlSvR6dvSamrSrU5NIJAnqGdDQvs ULYbcQWGK3n5oIfVc8yF81uSMpAmgtjRM1tayKvcafP4xohPIa83jWtg8FVm bUlf14.0eaei7820_lCONwlAJAu_cX9D6OdY_JD07naQWWPNqNYedCyQcZJk zx0B28Kbd5ZUGgurbvthbO6YrN0Saj6vPi23zHRsQD9Yi4rScP_LM_dGgFj6 u3piSZc9u3sqjHVxlOfRl7hXBzhaG3ylOVWx1lJ2cJxlgV57qETx4yXClKXB rs7fePF7lKn7gbpt6s2hEOgaZaCXdNjjdrIZeb36yF90nzp42huE- Received: from [209.131.62.113] by web31808.mail.mud.yahoo.com via HTTP; Tue, 10 Jan 2012 16:02:21 PST X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.116.331537 References: <6.2.5.6.2.20120109070921.0aec8d00@resistor.net> <6.2.5.6.2.20120109153323.0ab3bf80@resistor.net> <1326156786.88572.YahooMailNeo@web31812.mail.mud.yahoo.com> <1326160314.71861.YahooMailNeo@web31806.mail.mud.yahoo.com> <1326162276.40306.YahooMailNeo@web31811.mail.mud.yahoo.com> <1326215997.44445.YahooMailNeo@web31816.mail.mud.yahoo.com> <6.2.5.6.2.20120110104038.099f1ba8@resistor.net> <90C41DD21FB7C64BB94121FBBC2E723453A72D0F24@P3PW5EX1MB01.EX1.SECURESERVER.NET> Message-ID: <1326240141.98332.YahooMailNeo@web31808.mail.mud.yahoo.com> Date: Tue, 10 Jan 2012 16:02:21 -0800 (PST) From: William Mills To: Eran Hammer , "oauth@ietf.org" In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453A72D0F24@P3PW5EX1MB01.EX1.SECURESERVER.NET> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="258328648-394140997-1326240141=:98332" Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification 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, 11 Jan 2012 00:02:26 -0000 --258328648-394140997-1326240141=:98332 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable On your #1, I don't agree that an empty scope is useless.=A0 There are comp= arable implementations that use an empty scope to be a wildcard scope.=A0 I= 'd say, =0A=0A=0A"The client can MAY include or omit the scope =0Aparameter= . If omitted, the server must process the request using an empty scope as t= he default.=A0 The server then processes the request either issuing a grant= with it's default scope as defined by the server or failing the request in= dicating an invalid scope requested."=0A=0AThat language isn't quite right,= but I think it's clear.=0A=0A=0A=0A________________________________=0A Fro= m: Eran Hammer =0ATo: "oauth@ietf.org" =0ASent: Tuesday, January 10, 2012 1:15 PM=0ASubject: Re: [OAUTH-WG] Seek= ing Clarification: Potential Ambiguity in Specification=0A =0AI don't think= the issue here is about the scope value, but who does the OPTIONAL designa= tion applies to. IOW, is it optional for the server to support/require it, = or is it optional for the client to include or omit it.=0A=0AThe intention = was to make it optional for the authorization server to make all decisions = about the parameter, including making it required. But the text is confusin= g since the text is aimed directly at the client when making the request.= =0A=0AWe need to clarify this and the options are:=0A=0A1. The client can d= ecide if they want to include or omit the scope parameter. If omitted, the = server must process the request using some documented default scope. This d= efault scope can be an empty scope rendering the token useless for anything= other than verifying user authentication.=0A=0A2. The server can declare s= cope to be a required parameter in which case the client must include it or= the request will fail. In this case, we should make the text clearer that = clients to find out if the particular server requires it.=0A=0A#1 is better= for interoperability, #2 is more in the spirit of the parameter discussion= s so far.=0A=0AEHL=0A=0A> -----Original Message-----=0A> From: oauth-bounce= s@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf=0A> Of Phil Hunt=0A> S= ent: Tuesday, January 10, 2012 11:33 AM=0A> To: SM=0A> Cc: oauth@ietf.org= =0A> Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in= =0A> Specification=0A> =0A> The underlying issue is that there was a decisi= on not to in any way=0A> standardize values for scope.=0A> =0A> I agreed th= is was reasonable since the underlying resource APIs are likely to=0A> be v= ery specific requiring some degree of prior knowledge by the client app=0A>= developer. Thus the resource server OAuth infrastructure is free to decide= =0A> what are and are not acceptable values including missing or null value= s for=0A> scope.=0A> =0A> I think the specification is acceptable as it is.= =0A> =0A> I note that other specifications that layer on top of OAuth2 such= as OpenID=0A> Connect may choose to strictly define acceptable values for = scope. This type=0A> of layering works well in my opinion.=0A> =0A> Phil=0A= > =0A> @independentid=0A> www.independentid.com=0A> phil.hunt@oracle.com=0A= > =0A> =0A> =0A> =0A> =0A> On 2012-01-10, at 10:56 AM, SM wrote:=0A> =0A> >= At 09:19 10-01-2012, William Mills wrote:=0A> >> That does clear it up!=A0= If the implementation returns a proper error when=0A> the scope is omitted= then it will be in conformance.=A0 Sending an error result=0A> for the emp= ty scope is valid.=0A> >=0A> > Yes.=0A> >=0A> > It is not possible to get a= clear view of the specs if the discussion about=0A> "ambiguity" relies on = the meaning of the word "OPTIONAL" only.=A0 If there is a=0A> problem, then= clarifying text could be used to fix it instead of changing the=0A> requir= ements.=0A> >=0A> > Regards,=0A> > -sm=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_____________________________________= __________=0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mai= lman/listinfo/oauth --258328648-394140997-1326240141=:98332 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
On your #1, I don't agree that an empty scope is useless.  There are= comparable implementations that use an empty scope to be a wildcard scope.=   I'd say,

"The client can MAY include or omit the scope =0Aparameter. If omitted,= the server must process the request using an empty scope as the default.&n= bsp; The server then processes the request either issuing a grant with it's= default scope as defined by the server or failing the request indicating a= n invalid scope requested."

That language isn't qu= ite right, but I think it's clear.

From: Eran H= ammer <eran@hueniverse.com>
To: "oauth@ietf.org" <oauth@ietf.org>
Sent: Tuesday, January 10, 2012 1:15 PM<= br> Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification
=

=0AI don't think the issue here is about the scope valu= e, but who does the OPTIONAL designation applies to. IOW, is it optional fo= r the server to support/require it, or is it optional for the client to inc= lude or omit it.

The intention was to make it optional for the autho= rization server to make all decisions about the parameter, including making= it required. But the text is confusing since the text is aimed directly at= the client when making the request.

We need to clarify this and the= options are:

1. The client can decide if they want to include or om= it the scope parameter. If omitted, the server must process the request usi= ng some documented default scope. This default scope can be an empty scope = rendering the token useless for anything other than verifying user authenti= cation.

2. The server can declare scope to be a required parameter i= n which case the client must include it or the request will fail. In this c= ase, we should make the text clearer that clients to find out if the particular server re= quires it.

#1 is better for interoperability, #2 is more in the spir= it of the parameter discussions so far.

EHL

> -----Origina= l Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Phil Hunt
> S= ent: Tuesday, January 10, 2012 11:33 AM
> To: SM
> Cc: oauth@ietf.org<= /a>
> Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambigu= ity in
> Specification
>
> The underlying issue is that = there was a decision not to in any way
> standardize values for scope= .
>
> I agreed this was reasonable since the underlying resour= ce APIs are likely to
> be very specific requiring some degree of prior= knowledge by the client app
> developer. Thus the resource server OA= uth infrastructure is free to decide
> what are and are not acceptabl= e values including missing or null values for
> scope.
>
&g= t; I think the specification is acceptable as it is.
>
> I not= e that other specifications that layer on top of OAuth2 such as OpenID
&= gt; Connect may choose to strictly define acceptable values for scope. This= type
> of layering works well in my opinion.
>
> Phil>
> @independentid
> www.independentid.com
> phil.hunt@ora= cle.com
>
>
>
>
>
> On 2012-01= -10, at 10:56 AM, SM wrote:
>
> > At 09:19 10-01-2012, William Mills wrote:
> >> That does clear it up!  If the = implementation returns a proper error when
> the scope is omitted the= n it will be in conformance.  Sending an error result
> for the = empty scope is valid.
> >
> > Yes.
> >
> &= gt; It is not possible to get a clear view of the specs if the discussion a= bout
> "ambiguity" relies on the meaning of the word "OPTIONAL" only.=   If there is a
> problem, then clarifying text could be used to= fix it instead of changing the
> requirements.
> >
> = > Regards,
> > -sm
> > _______________________________= ________________
> > 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 listOAuth= @ietf.org
https://www.ietf.org/mailman/listinfo/oauth


=
--258328648-394140997-1326240141=:98332-- From agksmehx@gmail.com Tue Jan 10 16:18:15 2012 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 EDBD311E8093 for ; Tue, 10 Jan 2012 16:18:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.377 X-Spam-Level: X-Spam-Status: No, score=-3.377 tagged_above=-999 required=5 tests=[AWL=0.221, 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 mfa6kQrNEjcC for ; Tue, 10 Jan 2012 16:18:14 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id ACB5D11E8088 for ; Tue, 10 Jan 2012 16:18:14 -0800 (PST) Received: by yhpp56 with SMTP id p56so85466yhp.31 for ; Tue, 10 Jan 2012 16:18:12 -0800 (PST) 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 :content-type; bh=YK2ZMy51RdH8jkhTQV3rkPWcEDYvVI+qDXNkBXBgArs=; b=OV92sXjo5RS2fBjh787N45As2qye7g/fy8V0ZMEfjrRjJRSPbUbHYQXOTKEcfVNlZq y+1DO1ymDmL2SUqyg4g1SQqgPNT59CktQAa8Ul9pE0ONwL++WyHlTmTTMUqO7AJAIBku 6dcawfQW+Gc6I5fL2yfClHGiWQ1uTTRWyllT0= MIME-Version: 1.0 Received: by 10.236.155.226 with SMTP id j62mr5538107yhk.49.1326241090807; Tue, 10 Jan 2012 16:18:10 -0800 (PST) Received: by 10.236.115.68 with HTTP; Tue, 10 Jan 2012 16:18:10 -0800 (PST) In-Reply-To: <1326240141.98332.YahooMailNeo@web31808.mail.mud.yahoo.com> References: <6.2.5.6.2.20120109070921.0aec8d00@resistor.net> <6.2.5.6.2.20120109153323.0ab3bf80@resistor.net> <1326156786.88572.YahooMailNeo@web31812.mail.mud.yahoo.com> <1326160314.71861.YahooMailNeo@web31806.mail.mud.yahoo.com> <1326162276.40306.YahooMailNeo@web31811.mail.mud.yahoo.com> <1326215997.44445.YahooMailNeo@web31816.mail.mud.yahoo.com> <6.2.5.6.2.20120110104038.099f1ba8@resistor.net> <90C41DD21FB7C64BB94121FBBC2E723453A72D0F24@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1326240141.98332.YahooMailNeo@web31808.mail.mud.yahoo.com> Date: Tue, 10 Jan 2012 16:18:10 -0800 Message-ID: From: agks mehx To: William Mills , Eran Hammer , "oauth@ietf.org" Content-Type: multipart/alternative; boundary=20cf303b3c871aa73504b63591b8 Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification 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, 11 Jan 2012 00:18:16 -0000 --20cf303b3c871aa73504b63591b8 Content-Type: text/plain; charset=ISO-8859-1 Sounds very good: "... MAY include or omit the scope parameter. If omitted, the server must process the request using an empty scope as the default." On Tue, Jan 10, 2012 at 4:02 PM, William Mills wrote: > On your #1, I don't agree that an empty scope is useless. There are > comparable implementations that use an empty scope to be a wildcard scope. > I'd say, > > "The client can MAY include or omit the scope parameter. If omitted, the > server must process the request using an empty scope as the default. The > server then processes the request either issuing a grant with it's default > scope as defined by the server or failing the request indicating an invalid > scope requested." > > That language isn't quite right, but I think it's clear. > > ------------------------------ > *From:* Eran Hammer > *To:* "oauth@ietf.org" > *Sent:* Tuesday, January 10, 2012 1:15 PM > > *Subject:* Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in > Specification > > I don't think the issue here is about the scope value, but who does the > OPTIONAL designation applies to. IOW, is it optional for the server to > support/require it, or is it optional for the client to include or omit it. > > The intention was to make it optional for the authorization server to make > all decisions about the parameter, including making it required. But the > text is confusing since the text is aimed directly at the client when > making the request. > > We need to clarify this and the options are: > > 1. The client can decide if they want to include or omit the scope > parameter. If omitted, the server must process the request using some > documented default scope. This default scope can be an empty scope > rendering the token useless for anything other than verifying user > authentication. > > 2. The server can declare scope to be a required parameter in which case > the client must include it or the request will fail. In this case, we > should make the text clearer that clients to find out if the particular > server requires it. > > #1 is better for interoperability, #2 is more in the spirit of the > parameter discussions so far. > > EHL > > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > > Of Phil Hunt > > Sent: Tuesday, January 10, 2012 11:33 AM > > To: SM > > Cc: oauth@ietf.org > > Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in > > Specification > > > > The underlying issue is that there was a decision not to in any way > > standardize values for scope. > > > > I agreed this was reasonable since the underlying resource APIs are > likely to > > be very specific requiring some degree of prior knowledge by the client > app > > developer. Thus the resource server OAuth infrastructure is free to > decide > > what are and are not acceptable values including missing or null values > for > > scope. > > > > I think the specification is acceptable as it is. > > > > I note that other specifications that layer on top of OAuth2 such as > OpenID > > Connect may choose to strictly define acceptable values for scope. This > type > > of layering works well in my opinion. > > > > Phil > > > > @independentid > > www.independentid.com > > phil.hunt@oracle.com > > > > > > > > > > > > On 2012-01-10, at 10:56 AM, SM wrote: > > > > > At 09:19 10-01-2012, William Mills wrote: > > >> That does clear it up! If the implementation returns a proper error > when > > the scope is omitted then it will be in conformance. Sending an error > result > > for the empty scope is valid. > > > > > > Yes. > > > > > > It is not possible to get a clear view of the specs if the discussion > about > > "ambiguity" relies on the meaning of the word "OPTIONAL" only. If there > is a > > problem, then clarifying text could be used to fix it instead of > changing the > > requirements. > > > > > > Regards, > > > -sm > > > _______________________________________________ > > > 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 > > --20cf303b3c871aa73504b63591b8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sounds very good: "... MAY include or omit the scope paramete= r. If omitted, the server must process the request using an empty scope as = the default."

On Tue, J= an 10, 2012 at 4:02 PM, William Mills <wmills@yahoo-inc.com> wrote:
On your #1,= I don't agree that an empty scope is useless.=A0 There are comparable = implementations that use an empty scope to be a wildcard scope.=A0 I'd = say,

"The client= can MAY include or omit the scope=20 parameter. If omitted, the server must process the request using an empty s= cope as the default.=A0 The server then processes the request either issuin= g a grant with it's default scope as defined by the server or failing t= he request indicating an invalid scope requested."

That language isn't quite right, but I think it'= ;s clear.

From: Eran Hammer <eran@hueniverse.com>
To: "oauth@ietf.org" <oauth@ietf.org>
Sent: Tuesday, January 10, = 2012 1:15 PM

Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification
=

I don't think the issue here is about the scope value, but who does the= OPTIONAL designation applies to. IOW, is it optional for the server to sup= port/require it, or is it optional for the client to include or omit it.
The intention was to make it optional for the authorization server to m= ake all decisions about the parameter, including making it required. But th= e text is confusing since the text is aimed directly at the client when mak= ing the request.

We need to clarify this and the options are:

1. The client can d= ecide if they want to include or omit the scope parameter. If omitted, the = server must process the request using some documented default scope. This d= efault scope can be an empty scope rendering the token useless for anything= other than verifying user authentication.

2. The server can declare scope to be a required parameter in which cas= e the client must include it or the request will fail. In this case, we sho= uld make the text clearer that clients to find out if the particular server re= quires it.

#1 is better for interoperability, #2 is more in the spir= it of the parameter discussions so far.

EHL

> -----Origina= l Message-----
> From: oaut= h-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Phil Hunt<= br>> Sent: Tuesday, January 10, 2012 11:33 AM
> To: SM
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] Seeking Clarification: = Potential Ambiguity in
> Specification
>
> The underlyin= g issue is that there was a decision not to in any way
> standardize values for scope.
>
> I agreed this was reaso= nable since the underlying resource APIs are likely to
> be very specific requiring some degree of prior= knowledge by the client app
> developer. Thus the resource server OA= uth infrastructure is free to decide
> what are and are not acceptabl= e values including missing or null values for
> scope.
>
> I think the specification is acceptable as it = is.
>
> I note that other specifications that layer on top of = OAuth2 such as OpenID
> Connect may choose to strictly define accepta= ble values for scope. This type
> of layering works well in my opinion.
>
> Phil
> > @independentid
> www.independentid.com
> phil.hunt@oracle.com
>
>
>
>
>
> On 2012-01-10, at 10:56 A= M, SM wrote:
>
> > At 09:19 10-01-2012, William Mills wrote:
> >> That does clear it up!=A0 If the imp= lementation returns a proper error when
> the scope is omitted then i= t will be in conformance.=A0 Sending an error result
> for the empty = scope is valid.
> >
> > Yes.
> >
> > It is not possible to= get a clear view of the specs if the discussion about
> "ambigu= ity" relies on the meaning of the word "OPTIONAL" only.=A0 I= f there is a
> problem, then clarifying text could be used to fix it instead of chang= ing the
> requirements.
> >
> > Regards,
> &g= t; -sm
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mail= man/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list=
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
http= s://www.ietf.org/mailman/listinfo/oauth



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


--20cf303b3c871aa73504b63591b8-- From wmills@yahoo-inc.com Tue Jan 10 16:30:50 2012 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 5CB8621F875B for ; Tue, 10 Jan 2012 16:30:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.3 X-Spam-Level: X-Spam-Status: No, score=-17.3 tagged_above=-999 required=5 tests=[AWL=0.298, 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 WHDfCC4YV6Ce for ; Tue, 10 Jan 2012 16:30:49 -0800 (PST) Received: from nm27.bullet.mail.sp2.yahoo.com (nm27.bullet.mail.sp2.yahoo.com [98.139.91.97]) by ietfa.amsl.com (Postfix) with SMTP id 333CB21F8783 for ; Tue, 10 Jan 2012 16:30:49 -0800 (PST) Received: from [98.139.91.70] by nm27.bullet.mail.sp2.yahoo.com with NNFMP; 11 Jan 2012 00:30:49 -0000 Received: from [98.139.91.41] by tm10.bullet.mail.sp2.yahoo.com with NNFMP; 11 Jan 2012 00:30:49 -0000 Received: from [127.0.0.1] by omp1041.mail.sp2.yahoo.com with NNFMP; 11 Jan 2012 00:30:49 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 129643.78102.bm@omp1041.mail.sp2.yahoo.com Received: (qmail 62540 invoked by uid 60001); 11 Jan 2012 00:30:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1326241848; bh=mE503RP+rO+rPaFvhh0nWtjRcSaBkjVaUrG+u0jPQFg=; 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=XWUxZDCm5hvIcMmDdahc7Dt45p5YcFBSHMoiWiNRb0MypjRtGII7f1qme4eIyP/1yACYrq2lbfhoruHN3jBdK/SwRKmVD4LUyij8xOS49pUtsP1v8Di4JGutH5D7CA3fql0je+HBHs6v5/3O5/Wn56bKge1wUMJuUvpfDbK/dDg= 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=Mahm/csFQKjRYgrP4e7GGbop1WYVyEOKMuzsIBVY+EvLBqiLgxRW61RYa/tqkqdX+reiTq/Yd7X/jp/xDKWJDNA3mOF+ThBX8hJRXd/XMs5N9PqYCbMEmDbgQ5R5V1l9E98twm0JT2EFMYInmC0cEsU8Nl62O5EfWIXkBQCYiMU=; X-YMail-OSG: Kj8EJQwVM1mkBoz7o05yRBDdrgF3L6jgKquInxObJH4jk1o I2jydQekg89CR91gmnMcKsrNnLY7A4ZuoKKfG27uqoocrXueozXaVoCPqt0b BAM7c1BVsr74NTsibGrT29A1OFrROMubN_SiSQdcq0T5UAow14u1U1fbAj9. ZicmbxB.2yoJn7xIX6J7xnh8yhXaC9V8pqljpfnzVeZfjzi99MiD2AHMI9kQ pKop98pnYwBpAysRInxby7Wzr_bEwtNis5K74XxLNNrcH63CBZHgYX715HRn fG.VzLOZO4KxQPW8MFRSH5UvZd8izX2w7AmNDCOju_yoe6lhKLsZWN_DZHEb kCURzOliSfnwaCuRyVv_DmZm.Oe1iQQ0SzGsmiR32j8FWbGPH_85DAAIoxHD Q5eijZREuZ_u0JoNKXT6TI4VqLigNgfWWRqa7iCYDb.iqJnXYGsQtiQUMb4m 7db6xlc6S9_wQtk6RD1zzcAJkaVwMDBXTLlHNqz6Uw8x6KZsVwNfZJA-- Received: from [209.131.62.113] by web31804.mail.mud.yahoo.com via HTTP; Tue, 10 Jan 2012 16:30:48 PST X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.116.331537 References: <6.2.5.6.2.20120109070921.0aec8d00@resistor.net> <6.2.5.6.2.20120109153323.0ab3bf80@resistor.net> <1326156786.88572.YahooMailNeo@web31812.mail.mud.yahoo.com> <1326160314.71861.YahooMailNeo@web31806.mail.mud.yahoo.com> <1326162276.40306.YahooMailNeo@web31811.mail.mud.yahoo.com> <1326215997.44445.YahooMailNeo@web31816.mail.mud.yahoo.com> <6.2.5.6.2.20120110104038.099f1ba8@resistor.net> <90C41DD21FB7C64BB94121FBBC2E723453A72D0F24@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1326240141.98332.YahooMailNeo@web31808.mail.mud .yahoo.com> Message-ID: <1326241848.57936.YahooMailNeo@web31804.mail.mud.yahoo.com> Date: Tue, 10 Jan 2012 16:30:48 -0800 (PST) From: William Mills To: agks mehx , Eran Hammer , "oauth@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="835683298-813157043-1326241848=:57936" Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification 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, 11 Jan 2012 00:30:50 -0000 --835683298-813157043-1326241848=:57936 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Wups, there's a must in there that should be MUST.=0A=0A=0A=0A_____________= ___________________=0A From: agks mehx =0ATo: William M= ills ; Eran Hammer ; "oauth@ietf= .org" =0ASent: Tuesday, January 10, 2012 4:18 PM=0ASubject= : Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specificatio= n=0A =0A=0ASounds very good: "... MAY include or omit the scope parameter. = If omitted, the server must process the request using an empty scope as the= default."=0A=0AOn Tue, Jan 10, 2012 at 4:02 PM, William Mills wrote:=0A=0AOn your #1, I don't agree that an empty scope is use= less.=A0 There are comparable implementations that use an empty scope to be= a wildcard scope.=A0 I'd say, =0A>=0A>=0A>=0A>"The client can MAY include = or omit the scope =0Aparameter. If omitted, the server must process the req= uest using an empty scope as the default.=A0 The server then processes the = request either issuing a grant with it's default scope as defined by the se= rver or failing the request indicating an invalid scope requested."=0A>=0A>= =0A>That language isn't quite right, but I think it's clear.=0A>=0A>=0A>=0A= >=0A>________________________________=0A> From: Eran Hammer =0A>To: "oauth@ietf.org" =0A>Sent: Tuesday, January = 10, 2012 1:15 PM=0A>=0A>Subject: Re: [OAUTH-WG] Seeking Clarification: Pote= ntial Ambiguity in Specification=0A> =0A>=0A>I don't think the issue here i= s about the scope value, but who does the OPTIONAL designation applies to. = IOW, is it optional for the server to support/require it, or is it optional= for the client to include or omit it.=0A>=0A>The intention was to make it = optional for the authorization server to make all decisions about the param= eter, including making it required. But the text is confusing since the tex= t is aimed directly at the client when making the request.=0A>=0A>We need t= o clarify this and the options are:=0A>=0A>1. The client can decide if they= want to include or omit the scope parameter. If omitted, the server must p= rocess the request using some documented default scope. This default scope = can be an empty scope rendering the token useless for anything other than v= erifying user authentication.=0A>=0A>2. The server can declare scope to be = a required parameter in which case the client must include it or the reques= t will fail. In this case, we should=0A make the text clearer that clients = to find out if the particular server requires it.=0A>=0A>#1 is better for i= nteroperability, #2 is more in the spirit of the parameter discussions so f= ar.=0A>=0A>EHL=0A>=0A>> -----Original Message-----=0A>> From: oauth-bounces= @ietf.org [mailto:oauth-bounces@ietf.org] On Behalf=0A>> Of Phil Hunt=0A>> = Sent: Tuesday, January 10, 2012 11:33 AM=0A>> To: SM=0A>> Cc: oauth@ietf.or= g=0A>> Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity i= n=0A>> Specification=0A>> =0A>> The underlying issue is that there was a de= cision not to in any way=0A>> standardize values for scope.=0A>> =0A>> I ag= reed this was reasonable since the underlying resource=0A APIs are likely t= o=0A>> be very specific requiring some degree of prior knowledge by the cli= ent app=0A>> developer. Thus the resource server OAuth infrastructure is fr= ee to decide=0A>> what are and are not acceptable values including missing = or null values for=0A>> scope.=0A>> =0A>> I think the specification is acce= ptable as it is.=0A>> =0A>> I note that other specifications that layer on = top of OAuth2 such as OpenID=0A>> Connect may choose to strictly define acc= eptable values for scope. This type=0A>> of layering works well in my opini= on.=0A>> =0A>> Phil=0A>> =0A>> @independentid=0A>> www.independentid.com=0A= >> phil.hunt@oracle.com=0A>> =0A>> =0A>> =0A>> =0A>> =0A>> On 2012-01-10, a= t 10:56 AM, SM wrote:=0A>> =0A>> > At 09:19 10-01-2012,=0A William Mills wr= ote:=0A>> >> That does clear it up!=A0 If the implementation returns a prop= er error when=0A>> the scope is omitted then it will be in conformance.=A0 = Sending an error result=0A>> for the empty scope is valid.=0A>> >=0A>> > Ye= s.=0A>> >=0A>> > It is not possible to get a clear view of the specs if the= discussion about=0A>> "ambiguity" relies on the meaning of the word "OPTIO= NAL" only.=A0 If there is a=0A>> problem, then clarifying text could be use= d to fix it instead of changing the=0A>> requirements.=0A>> >=0A>> > Regard= s,=0A>> > -sm=0A>> > _______________________________________________=0A>> >= OAuth mailing list=0A>> > OAuth@ietf.org=0A>> > https://www.ietf.org/mailm= an/listinfo/oauth=0A>> =0A>>=0A ___________________________________________= ____=0A>> OAuth mailing list=0A>> OAuth@ietf.org=0A>> https://www.ietf.org/= mailman/listinfo/oauth=0A>_______________________________________________= =0A>OAuth mailing list=0A>OAuth@ietf.org=0A>https://www.ietf.org/mailman/li= stinfo/oauth=0A>=0A>=0A>=0A>_______________________________________________= =0A>OAuth mailing list=0A>OAuth@ietf.org=0A>https://www.ietf.org/mailman/li= stinfo/oauth=0A>=0A> --835683298-813157043-1326241848=:57936 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Wups, there's a must in there that should be MUST.
<= br>
From: agks mehx <agksmehx@gmail.com>
To: William Mills <wmills@yahoo-inc.c= om>; Eran Hammer <eran@hueniverse.com>; "oauth@ietf.org" <oauth= @ietf.org>
Sent: T= uesday, January 10, 2012 4:18 PM
= Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambigui= ty in Specification

=0A
Sounds very good: "... MAY include or omit the scope parameter. If om= itted, the server must process the request using an empty scope as the defa= ult."
=0A
On Tue, Jan 10, 2012 at 4:02 PM, William Mills <wmills@yahoo-inc.c= om> wrote:
=0A=
On you= r #1, I don't agree that an empty scope is useless.  There are compara= ble implementations that use an empty scope to be a wildcard scope.  I= 'd say,
=0A

"= The client can MAY include or omit the scope =0Aparameter. If omitted, the = server must process the request using an empty scope as the default.  = The server then processes the request either issuing a grant with it's defa= ult scope as defined by the server or failing the request indicating an inv= alid scope requested."
=0A

That language isn't quit= e right, but I think it's clear.

=0A
<= b>From: Eran Hammer <eran@hueniverse.com>
To: "oauth= @ietf.org" <oauth@ietf.org>
= =0A Sent: Tuesday, January = 10, 2012 1:15 PM

Subject: Re:=0A [OAUTH-WG] Seeking = Clarification: Potential Ambiguity in Specification
=

=0AI don't think = the issue here is about the scope value, but who does the OPTIONAL designat= ion applies to. IOW, is it optional for the server to support/require it, o= r is it optional for the client to include or omit it.
=0A
The intent= ion was to make it optional for the authorization server to make all decisi= ons about the parameter, including making it required. But the text is conf= using since the text is aimed directly at the client when making the reques= t.
=0A
We need to clarify this and the options are:

1. The cli= ent can decide if they want to include or omit the scope parameter. If omit= ted, the server must process the request using some documented default scop= e. This default scope can be an empty scope rendering the token useless for= anything other than verifying user authentication.
=0A
2. The server= can declare scope to be a required parameter in which case the client must= include it or the request will fail. In this case, we should=0A make the t= ext clearer that clients to find out if the particular server requires it.<= br>
#1 is better for interoperability, #2 is more in the spirit of the p= arameter discussions so far.

EHL

> -----Original Message--= ---
=0A> From: oauth-boun= ces@ietf.org [mailto:oauth-= bounces@ietf.org] On Behalf
> Of Phil Hunt
> Sent: Tuesday,= January 10, 2012 11:33 AM
=0A> To: SM
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] Seeking Clarif= ication: Potential Ambiguity in
> Specification
>
> The = underlying issue is that there was a decision not to in any way
=0A> = standardize values for scope.
>
> I agreed this was reasonable= since the underlying resource=0A APIs are likely to
> be very specif= ic requiring some degree of prior knowledge by the client app
> devel= oper. Thus the resource server OAuth infrastructure is free to decide
&g= t; what are and are not acceptable values including missing or null values = for
=0A> scope.
>
> I think the specification is accepta= ble as it is.
>
> I note that other specifications that layer = on top of OAuth2 such as OpenID
> Connect may choose to strictly defi= ne acceptable values for scope. This type
=0A> of layering works well= in my opinion.
>
> Phil
>
> @independentid
&g= t; www.independentid.com
> phil.hunt@oracle.com
=0A>
>
>
>
> =
> On 2012-01-10, at 10:56 AM, SM wrote:
>
> > At 09:= 19 10-01-2012,=0A William Mills wrote:
> >> That does clear it = up!  If the implementation returns a proper error when
> the sco= pe is omitted then it will be in conformance.  Sending an error result=
> for the empty scope is valid.
=0A> >
> > Yes.> >
> > It is not possible to get a clear view of the specs= if the discussion about
> "ambiguity" relies on the meaning of the w= ord "OPTIONAL" only.  If there is a
=0A> problem, then clarifyin= g text could be used to fix it instead of changing the
> requirements= .
> >
> > Regards,
> > -sm
> > ________= _______________________________________
=0A> > OAuth mailing list<= br>> > OAuth@ietf.org
> > = https://www.ietf.org/mailman/listinfo/oauth
=0A> =
>=0A _______________________________________________
> OAuth m= ailing list
> OAuth@ietf.org
> = https://www.ietf.org/mailman/listinfo/oauth
=0A_____= __________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.iet= f.org/mailman/listinfo/oauth
=0A

=

_______________________________________________
=0AOAuth= mailing list
=0AOAuth@ietf.org
=0Ahttps://www.ietf.org/mailman/listinfo/oauth
=0A

=0A


--835683298-813157043-1326241848=:57936-- From eran@hueniverse.com Tue Jan 10 17:24:35 2012 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 6AECE5E8005 for ; Tue, 10 Jan 2012 17:24:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.016, 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 b37yrg6R2Yo4 for ; Tue, 10 Jan 2012 17:24:32 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id CA43E5E8001 for ; Tue, 10 Jan 2012 17:24:32 -0800 (PST) Received: (qmail 18616 invoked from network); 11 Jan 2012 01:24:31 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 11 Jan 2012 01:24:31 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 10 Jan 2012 18:24:22 -0700 From: Eran Hammer To: William Mills , "oauth@ietf.org" Date: Tue, 10 Jan 2012 18:24:03 -0700 Thread-Topic: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification Thread-Index: AczP9F2keJyt2HzQRy24rtRe/YZRtgAC000A Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453A72D0F60@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <6.2.5.6.2.20120109070921.0aec8d00@resistor.net> <6.2.5.6.2.20120109153323.0ab3bf80@resistor.net> <1326156786.88572.YahooMailNeo@web31812.mail.mud.yahoo.com> <1326160314.71861.YahooMailNeo@web31806.mail.mud.yahoo.com> <1326162276.40306.YahooMailNeo@web31811.mail.mud.yahoo.com> <1326215997.44445.YahooMailNeo@web31816.mail.mud.yahoo.com> <6.2.5.6.2.20120110104038.099f1ba8@resistor.net> <90C41DD21FB7C64BB94121FBBC2E723453A72D0F24@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1326240141.98332.YahooMailNeo@web31808.mail.mud.yahoo.com> In-Reply-To: <1326240141.98332.YahooMailNeo@web31808.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_90C41DD21FB7C64BB94121FBBC2E723453A72D0F60P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification 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, 11 Jan 2012 01:24:35 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723453A72D0F60P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I don't like 'empty scope' as it is undefined. I prefer 'default scope'. EHL From: William Mills [mailto:wmills@yahoo-inc.com] Sent: Tuesday, January 10, 2012 4:02 PM To: Eran Hammer; oauth@ietf.org Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Speci= fication On your #1, I don't agree that an empty scope is useless. There are compar= able implementations that use an empty scope to be a wildcard scope. I'd s= ay, "The client can MAY include or omit the scope parameter. If omitted, the se= rver must process the request using an empty scope as the default. The ser= ver then processes the request either issuing a grant with it's default sco= pe as defined by the server or failing the request indicating an invalid sc= ope requested." That language isn't quite right, but I think it's clear. ________________________________ From: Eran Hammer > To: "oauth@ietf.org" > Sent: Tuesday, January 10, 2012 1:15 PM Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Speci= fication I don't think the issue here is about the scope value, but who does the OPT= IONAL designation applies to. IOW, is it optional for the server to support= /require it, or is it optional for the client to include or omit it. The intention was to make it optional for the authorization server to make = all decisions about the parameter, including making it required. But the te= xt is confusing since the text is aimed directly at the client when making = the request. We need to clarify this and the options are: 1. The client can decide if they want to include or omit the scope paramete= r. If omitted, the server must process the request using some documented de= fault scope. This default scope can be an empty scope rendering the token u= seless for anything other than verifying user authentication. 2. The server can declare scope to be a required parameter in which case th= e client must include it or the request will fail. In this case, we should = make the text clearer that clients to find out if the particular server req= uires it. #1 is better for interoperability, #2 is more in the spirit of the paramete= r discussions so far. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth= -bounces@ietf.org] On Behalf > Of Phil Hunt > Sent: Tuesday, January 10, 2012 11:33 AM > To: SM > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in > Specification > > The underlying issue is that there was a decision not to in any way > standardize values for scope. > > I agreed this was reasonable since the underlying resource APIs are likel= y to > be very specific requiring some degree of prior knowledge by the client a= pp > developer. Thus the resource server OAuth infrastructure is free to decid= e > what are and are not acceptable values including missing or null values f= or > scope. > > I think the specification is acceptable as it is. > > I note that other specifications that layer on top of OAuth2 such as Open= ID > Connect may choose to strictly define acceptable values for scope. This t= ype > of layering works well in my opinion. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > On 2012-01-10, at 10:56 AM, SM wrote: > > > At 09:19 10-01-2012, William Mills wrote: > >> That does clear it up! If the implementation returns a proper error w= hen > the scope is omitted then it will be in conformance. Sending an error re= sult > for the empty scope is valid. > > > > Yes. > > > > It is not possible to get a clear view of the specs if the discussion a= bout > "ambiguity" relies on the meaning of the word "OPTIONAL" only. If there = is a > problem, then clarifying text could be used to fix it instead of changing= the > requirements. > > > > Regards, > > -sm > > _______________________________________________ > > 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_90C41DD21FB7C64BB94121FBBC2E723453A72D0F60P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I donR= 17;t like ‘empty scope’ as it is undefined. I prefer ‘def= ault scope’.

&n= bsp;

EHL

<= p class=3DMsoNormal> 

From: William Mills [mailto:wmills@yahoo-inc.com]
<= b>Sent: Tuesday, January 10, 2012 4:02 PM
To: Eran Hammer; oa= uth@ietf.org
Subject: Re: [OAUTH-WG] Seeking Clarification: Poten= tial Ambiguity in Specification

 

On your #1, I don't agree that an empty scope is useless. = ; There are comparable implementations that use an empty scope to be a wild= card scope.  I'd say,

 

"The client can MAY include or om= it the scope parameter. If omitted, the server must process the request usi= ng an empty scope as the default.  The server then processes the reque= st either issuing a grant with it's default scope as defined by the server = or failing the request indicating an invalid scope requested."

&= nbsp;

 

<= b>From: Eran Hammer <eran@hueniverse.com>
To: "oauth@ietf.org" <= oauth@ietf.org>
Sent: Tuesday, January 10, 2012 1:15 PMSubject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity= in Specification

<= /div>

<= span style=3D'color:black'>
I don't think the issue here is about the sc= ope value, but who does the OPTIONAL designation applies to. IOW, is it opt= ional for the server to support/require it, or is it optional for the clien= t to include or omit it.

The intention was to make it optional for t= he authorization server to make all decisions about the parameter, includin= g making it required. But the text is confusing since the text is aimed dir= ectly at the client when making the request.

We need to clarify this= and the options are:

1. The client can decide if they want to inclu= de or omit the scope parameter. If omitted, the server must process the req= uest using some documented default scope. This default scope can be an empt= y scope rendering the token useless for anything other than verifying user = authentication.

2. The server can declare scope to be a required par= ameter in which case the client must include it or the request will fail. I= n this case, we should make the text clearer that clients to find out if th= e particular server requires it.

#1 is better for interoperability, = #2 is more in the spirit of the parameter discussions so far.

EHL
> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Phil H= unt
> Sent: Tuesday, January 10, 2012 11:33 AM
> To: SM
>= Cc: oauth@ietf.org
> Subject: = Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in
> Specif= ication
>
> The underlying issue is that there was a decision = not to in any way
> standardize values for scope.
>
> I = agreed this was reasonable since the underlying resource APIs are likely to=
> be very specific requiring some degree of prior knowledge by the c= lient app
> developer. Thus the resource server OAuth infrastructure = is free to decide
> what are and are not acceptable values including = missing or null values for
> scope.
>
> I think the spec= ification is acceptable as it is.
>
> I note that other specif= ications that layer on top of OAuth2 such as OpenID
> Connect may cho= ose to strictly define acceptable values for scope. This type
> of la= yering works well in my opinion.
>
> Phil
>
> @in= dependentid
> www.independentid.com
> phil.hunt@oracle.com
>
>
>
>
> > On 2012-01-10, at 10:56 AM, SM wrote:
>
> > At 09:19 = 10-01-2012, William Mills wrote:
> >> That does clear it up!&nb= sp; If the implementation returns a proper error when
> the scope is = omitted then it will be in conformance.  Sending an error result
&g= t; for the empty scope is valid.
> >
> > Yes.
> >= ;
> > It is not possible to get a clear view of the specs if the d= iscussion about
> "ambiguity" relies on the meaning of the = word "OPTIONAL" only.  If there is a
> problem, then c= larifying text could be used to fix it instead of changing the
> requ= irements.
> >
> > Regards,
> > -sm
> > = _______________________________________________
> > OAuth mailing = list
> > OAuth@ietf.org
&= gt; > 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_90C41DD21FB7C64BB94121FBBC2E723453A72D0F60P3PW5EX1MB01E_-- From wmills@yahoo-inc.com Tue Jan 10 23:58:03 2012 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 A5D7E21F8859 for ; Tue, 10 Jan 2012 23:58:03 -0800 (PST) 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 1SZSTKWjwCRp for ; Tue, 10 Jan 2012 23:58:02 -0800 (PST) Received: from nm24-vm0.bullet.mail.bf1.yahoo.com (nm24-vm0.bullet.mail.bf1.yahoo.com [98.139.213.161]) by ietfa.amsl.com (Postfix) with SMTP id EA59921F86E5 for ; Tue, 10 Jan 2012 23:58:01 -0800 (PST) Received: from [98.139.215.141] by nm24.bullet.mail.bf1.yahoo.com with NNFMP; 11 Jan 2012 07:57:55 -0000 Received: from [98.139.212.219] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 11 Jan 2012 07:57:55 -0000 Received: from [127.0.0.1] by omp1028.mail.bf1.yahoo.com with NNFMP; 11 Jan 2012 07:57:55 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 642210.62690.bm@omp1028.mail.bf1.yahoo.com Received: (qmail 20951 invoked by uid 60001); 11 Jan 2012 07:57:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1326268675; bh=227Ey0UN/Xco8gFOkuU7wrp0LsE/lYEAEYUQvqEB5Lo=; 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=T+n8701qS9jt4ttfDLCmPcWZ4nyLQkB6a3sSoYY5VUOSZxn2EEv4vBCgD0BttjPYYbebocPOaCNpo9RERg6b1JmShhHsbwz4BeGMvQe2wIYwBC/Jq01mNUz7R0/rV5Re7qTw9AUI7RAr06LX/PwyXduC2pzylxqUXUwxaDTd4kA= 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=n3lwya4zs8wVUeBhpSMImRunn4YhHya2rFffH5/lMS2/FzLqVaUVTRloQMym2nHPqurr6Jia7G0CopVf1vw86p+ftEQrhz6NKQhAFH21Sc8KEvN6RJzpQENipvGTIlyTU7pBTqaG7ZDGYuUzXzc3BNasNjjZQkYXFwxWfZeIK5Q=; X-YMail-OSG: MAbvGYoVM1m2UyatjaIbzKt22pE9iAHsJMC6rUqGMuETC1E LoCKRF.hbkExpA.h5ydUqMOXP1qJJ1Hvzo4on1XEGKrr1HmfhAuppthuCzul 72gspErotW.lFgL383Bz9mDSgxAughR0iZ0.xdjtLQ8ECXF5PlWuiAkbIhGI zEnZviXFeOJyu1YDpF0aEkopj_53gLRxg55wYA9gaUnvv7epcYtuxuKqOBvU xHWtz9LChPamar406lALFyTUTxzQQurCaZWtic7xZahNe31eLxYiXjeK18AL bpIQ2zybgSNGvUCiYckEcJOKAwvkhGwfAnBiqZxR0VGXu974zMPm1YR3jqke XLTI3vlnlNJ4iNAT2HbX9RahrC6ttAGtZiFoAxn21i3gbtLgO2FmJpdj3oFK AmvIfwDKHQiF6T7Y_JKfaJF2U.F6CFBWoSiG2Pr9EWw2Sp7_AK1k6TBrYGrw H.aWu08e5_0fMjjI2F4ac0NNOAEuvOA-- Received: from [99.31.212.42] by web31807.mail.mud.yahoo.com via HTTP; Tue, 10 Jan 2012 23:57:55 PST X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.116.331537 References: <6.2.5.6.2.20120109070921.0aec8d00@resistor.net> <6.2.5.6.2.20120109153323.0ab3bf80@resistor.net> <1326156786.88572.YahooMailNeo@web31812.mail.mud.yahoo.com> <1326160314.71861.YahooMailNeo@web31806.mail.mud.yahoo.com> <1326162276.40306.YahooMailNeo@web31811.mail.mud.yahoo.com> <1326215997.44445.YahooMailNeo@web31816.mail.mud.yahoo.com> <6.2.5.6.2.20120110104038.099f1ba8@resistor.net> <90C41DD21FB7C64BB94121FBBC2E723453A72D0F24@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1326240141.98332.YahooMailNeo@web31808.mail.mud .yahoo.com> <90C41DD21FB7C64BB94121FBBC2E723453A72D0F60@P3PW5EX1MB01.EX1.SECURESERVER.NET> Message-ID: <1326268674.20557.YahooMailNeo@web31807.mail.mud.yahoo.com> Date: Tue, 10 Jan 2012 23:57:54 -0800 (PST) From: William Mills To: Eran Hammer , "oauth@ietf.org" In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453A72D0F60@P3PW5EX1MB01.EX1.SECURESERVER.NET> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-125733401-2047085132-1326268675=:20557" Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification 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, 11 Jan 2012 07:58:03 -0000 ---125733401-2047085132-1326268675=:20557 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable "Null string", "empty string", or "server defined default value" all work.= =C2=A0 Default scope doesn't do it for me.=0A=0A=0A=0A_____________________= ___________=0A From: Eran Hammer =0ATo: William Mills = ; "oauth@ietf.org" =0ASent: Tuesday,= January 10, 2012 5:24 PM=0ASubject: RE: [OAUTH-WG] Seeking Clarification: = Potential Ambiguity in Specification=0A =0A=0AI don=E2=80=99t like =E2=80= =98empty scope=E2=80=99 as it is undefined. I prefer =E2=80=98default scope= =E2=80=99.=0A=C2=A0=0AEHL=0A=C2=A0=0AFrom:William Mills [mailto:wmills@yaho= o-inc.com] =0ASent: Tuesday, January 10, 2012 4:02 PM=0ATo: Eran Hammer; oa= uth@ietf.org=0ASubject: Re: [OAUTH-WG] Seeking Clarification: Potential Amb= iguity in Specification=0A=C2=A0=0AOn your #1, I don't agree that an empty = scope is useless.=C2=A0 There are comparable implementations that use an em= pty scope to be a wildcard scope.=C2=A0 I'd say, =0A=C2=A0=0A"The client ca= n MAY include or omit the scope parameter. If omitted, the server must proc= ess the request using an empty scope as the default.=C2=A0 The server then = processes the request either issuing a grant with it's default scope as def= ined by the server or failing the request indicating an invalid scope reque= sted."=0A=C2=A0=0AThat language isn't quite right, but I think it's clear.= =0A=C2=A0=0A=0A________________________________=0A=0AFrom:Eran Hammer =0ATo: "oauth@ietf.org" =0ASent: Tuesday, = January 10, 2012 1:15 PM=0ASubject: Re: [OAUTH-WG] Seeking Clarification: P= otential Ambiguity in Specification=0A=0AI don't think the issue here is ab= out the scope value, but who does the OPTIONAL designation applies to. IOW,= is it optional for the server to support/require it, or is it optional for= the client to include or omit it.=0A=0AThe intention was to make it option= al for the authorization server to make all decisions about the parameter, = including making it required. But the text is confusing since the text is a= imed directly at the client when making the request.=0A=0AWe need to clarif= y this and the options are:=0A=0A1. The client can decide if they want to i= nclude or omit the scope parameter. If omitted, the server must process the= request using some documented default scope. This default scope can be an = empty scope rendering the token useless for anything other than verifying u= ser authentication.=0A=0A2. The server can declare scope to be a required p= arameter in which case the client must include it or the request will fail.= In this case, we should make the text clearer that clients to find out if = the particular server requires it.=0A=0A#1 is better for interoperability, = #2 is more in the spirit of the parameter discussions so far.=0A=0AEHL=0A= =0A> -----Original Message-----=0A> From: oauth-bounces@ietf.org [mailto:oa= uth-bounces@ietf.org] On Behalf=0A> Of Phil Hunt=0A> Sent: Tuesday, January= 10, 2012 11:33 AM=0A> To: SM=0A> Cc: oauth@ietf.org=0A> Subject: Re: [OAUT= H-WG] Seeking Clarification: Potential Ambiguity in=0A> Specification=0A> = =0A> The underlying issue is that there was a decision not to in any way=0A= > standardize values for scope.=0A> =0A> I agreed this was reasonable since= the underlying resource APIs are likely to=0A> be very specific requiring = some degree of prior knowledge by the client app=0A> developer. Thus the re= source server OAuth infrastructure is free to decide=0A> what are and are n= ot acceptable values including missing or null values for=0A> scope.=0A> = =0A> I think the specification is acceptable as it is.=0A> =0A> I note that= other specifications that layer on top of OAuth2 such as OpenID=0A> Connec= t may choose to strictly define acceptable values for scope. This type=0A> = of layering works well in my opinion.=0A> =0A> Phil=0A> =0A> @independentid= =0A> www.independentid.com=0A> phil.hunt@oracle.com=0A> =0A> =0A> =0A> =0A>= =0A> On 2012-01-10, at 10:56 AM, SM wrote:=0A> =0A> > At 09:19 10-01-2012,= William Mills wrote:=0A> >> That does clear it up!=C2=A0 If the implementa= tion returns a proper error when=0A> the scope is omitted then it will be i= n conformance.=C2=A0 Sending an error result=0A> for the empty scope is val= id.=0A> >=0A> > Yes.=0A> >=0A> > It is not possible to get a clear view of = the specs if the discussion about=0A> "ambiguity" relies on the meaning of = the word "OPTIONAL" only.=C2=A0 If there is a=0A> problem, then clarifying = text could be used to fix it instead of changing the=0A> requirements.=0A> = >=0A> > Regards,=0A> > -sm=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_______________________________________________= =0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/listi= nfo/oauth ---125733401-2047085132-1326268675=:20557 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
"Null string", "empty string", or "server defined default value" all work= .  Default scope doesn't do it for me.

=
From: Eran Hammer <eran@hueniverse.com>
To: William Mills <wmills@yahoo-inc.com>;= "oauth@ietf.org" <oauth@ietf.org>
Sent: Tuesday, January 10, 2012 5:24 PM
Subject: RE: [OAUTH-WG] Seeking Clari= fication: Potential Ambiguity in Specification

=0A

Added the= word ‘credentials’ (e.g. “Access token credentials (as w= ell as…”) to make this clearer. IOW, when using MAC tokens, the= token secret is the part that must be protected, not the token id.

 

EHL

 

<= span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From: = oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of = Marco De Nadai
Sent: Sunday, October 30, 2011 9:44 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Security Considerations - A= ccess Tokens

&nb= sp;

Hi all,

 

i've recently n= oticed that in OAuth 2.0 draft 22, in the section 10.3 there is this statme= nt: 

 

Access token (as well as any access token= type-specific attributes) MUST be kept confidential in transit and st= orage, and only shared among the authorization server, the resource se= rvers the access token is valid for, and the client to whom the access= token is issued.

 =

BUT in OAuth 2.0 draft 22 with Au= thorization Code and MAC Access Authentication, I can request a resource wi= th Access Token sent in clear. This invalidates the "Access token (as = well as any access token type-specific attributes) MUST be kept confidentia= l in transit and storage".

 

Is it my error?

 

=

--

Marco De Nadai

 

= --_000_90C41DD21FB7C64BB94121FBBC2E723453A754C54CP3PW5EX1MB01E_-- From torsten@lodderstedt.net Mon Jan 16 11:02:37 2012 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 D251821F86AF for ; Mon, 16 Jan 2012 11:02:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[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 nHO852JJ7bm1 for ; Mon, 16 Jan 2012 11:02:36 -0800 (PST) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.29.7]) by ietfa.amsl.com (Postfix) with ESMTP id 1F07721F85EE for ; Mon, 16 Jan 2012 11:02:35 -0800 (PST) Received: from [91.2.71.70] (helo=[192.168.71.42]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1RmrpB-0000BJ-Ev; Mon, 16 Jan 2012 20:02:33 +0100 Message-ID: <4F147449.6060900@lodderstedt.net> Date: Mon, 16 Jan 2012 20:02:33 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Eran Hammer References: <90C41DD21FB7C64BB94121FBBC2E723453A754C54C@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453A754C54C@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: multipart/alternative; boundary="------------070105090903000802080709" X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: Marco De Nadai , "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, 16 Jan 2012 19:02:37 -0000 This is a multi-part message in MIME format. --------------070105090903000802080709 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit makes sense. regards, Torsten. Am 16.01.2012 20:00, schrieb Eran Hammer: > > Added the word 'credentials' (e.g. "Access token credentials (as well > as...") to make this clearer. IOW, when using MAC tokens, the token > secret is the part that must be protected, not the token id. > > EHL > > *From:*oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On > Behalf Of *Marco De Nadai > *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 > storage". > > Is it my error? > > -- > > *Marco De Nadai* > > http://www.marcodena.it/ > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------070105090903000802080709 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit makes sense.

regards,
Torsten.

Am 16.01.2012 20:00, schrieb Eran Hammer:

Added the word ‘credentials’ (e.g. “Access token credentials (as well as…”) to make this clearer. IOW, when using MAC tokens, the token secret is the part that must be protected, not the token id.

 

EHL

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Marco De Nadai
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 storage".

 

Is it my error?

 

--

Marco De Nadai

 



_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--------------070105090903000802080709-- From andredemarre@gmail.com Mon Jan 16 15:20:05 2012 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 4100521F86BE for ; Mon, 16 Jan 2012 15:20:05 -0800 (PST) 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 kXyHx47C42kK for ; Mon, 16 Jan 2012 15:20:04 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5E88021F86AF for ; Mon, 16 Jan 2012 15:20:04 -0800 (PST) Received: by iaae16 with SMTP id e16so10194064iaa.31 for ; Mon, 16 Jan 2012 15:20:04 -0800 (PST) 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=hfshg++KyPmJOT/JedZc1/AucjhNd9lVgK8hJNu0RfU=; b=tQeLjqgG9omM2xbQr7+rM2sQra546Gxr4uvA03yNU2lw7SADHMWSW+C+M+4wpVDqdB IY3TFXmADHOdxOXl+eHwwYiiQJdpaQkU9dTWI+GnNOm7OQnJdiLEeSdSJE/yFkOduwLm rAJUm5vsESVr+0WD7/9eu4UFfspnNqBEMZJF4= MIME-Version: 1.0 Received: by 10.42.29.6 with SMTP id p6mr11848268icc.44.1326756002210; Mon, 16 Jan 2012 15:20:02 -0800 (PST) Received: by 10.42.224.5 with HTTP; Mon, 16 Jan 2012 15:20:02 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453A754C534@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723453A754C534@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 16 Jan 2012 15:20:02 -0800 Message-ID: From: =?ISO-8859-1?Q?Andr=E9_DeMarre?= To: Eran Hammer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: OAuth WG 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: Mon, 16 Jan 2012 23:20:05 -0000 Eran, Yes; I think a section should be added to the security model doc. On 2011-12-16 Mark Mcgloin agreed and suggested we call it "Client Registration of phishing clients": http://www.ietf.org/mail-archive/web/oauth/current/msg08061.html I'm happy to propose the text; it might be one or two days though. Regards, Andre DeMarre On Mon, Jan 16, 2012 at 10:30 AM, Eran Hammer wrote: > Should this be added to the security model document? Is it already addres= sed there? > > EHL > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Andr=E9 DeMarre >> Sent: Tuesday, October 04, 2011 11:33 AM >> To: OAuth WG >> Subject: [OAUTH-WG] Phishing with Client Application Name Spoofing >> >> I've not seen this particular variant of phishing and client impersonati= on >> discussed. A cursory search revealed that most of the related discussion >> centers around either (a) client impersonation with stolen client creden= tials >> or (b) phishing by malicious clients directing resource owners to spoofe= d >> 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 pretendi= ng to >> be from a trustworthy source. This is not necessarily a direct vulnerabi= lity 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 aut= horization >> server. A malicious client developer registers his client application wi= th a >> name that appears to represent a legitimate organization which resource >> owners are likely to trust. Resource owners at the authorization endpoin= t >> may be misled into granting authorization when they see the authorizatio= n >> server asserting " is requesting permission to...= " >> >> Imagine someone registers a client application with an OAuth service, le= t's >> call it Foobar, and he names his client app "Google, Inc.". The Foobar >> authorization server will engage the user with "Google, Inc. is requesti= ng >> 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 t= he >> redirect URI. Some OAuth services blindly entrust client apps to customi= ze >> the authorization page in other ways. >> >> This is hard to defend against. Authorization server administrators coul= d >> police client names, but that approach gives them a burden similar to >> certificate authorities to verify organizations before issuing certifica= tes. 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 permi= ssion 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 impressio= n 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 n= ame 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 distr= ibute >> links around the web to the authorization server's authorization endpoin= t. If >> the HTTP service is a social platform, the client app might distribute l= inks using >> resource owners' accounts with the access tokens it has acquired, becomi= ng >> 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 vict= im 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 them= selves >> from traditional phishing by verifying the domain in the address bar, an= d >> perhaps checking TLS certificates, but such defenses are irrelevent here= . >> Resource owners now need to verify not only that they are on the legitim= ate >> authorization server, but to consider the trustworthyness of the link th= at >> 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 t= hey >> 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 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth From jricher@mitre.org Mon Jan 16 19:29:33 2012 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 6820921F85B5 for ; Mon, 16 Jan 2012 19:29:33 -0800 (PST) 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.000, 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 SoASp03q3Ykn for ; Mon, 16 Jan 2012 19:29:32 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id B6C4E21F85B4 for ; Mon, 16 Jan 2012 19:29:32 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id F11F221B0C38; Mon, 16 Jan 2012 22:29:26 -0500 (EST) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id DD65121B0BF6; Mon, 16 Jan 2012 22:29:26 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.158]) by IMCCAS02.MITRE.ORG ([129.83.29.79]) with mapi id 14.01.0339.001; Mon, 16 Jan 2012 22:29:26 -0500 From: "Richer, Justin P." To: Eran Hammer Thread-Topic: [OAUTH-WG] Access Token Response without expires_in Thread-Index: AczUf8kvUkdgy1nHSGOm5KixWQExDAAclWSA Date: Tue, 17 Jan 2012 03:29:26 +0000 Message-ID: References: <90C41DD21FB7C64BB94121FBBC2E723453A754C549@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453A754C549@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.15.27] Content-Type: text/plain; charset="us-ascii" Content-ID: <9E4671A2B0A14A4885F15A73006E0E55@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "wolter.eldering" , OAuth WG Subject: Re: [OAUTH-WG] Access Token Response without expires_in 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, 17 Jan 2012 03:29:33 -0000 I think #3. #1 will be a common instance, and #2 (or its variant, a limited number of u= ses) is a different expiration pattern than time that would want to have it= s own expiration parameter name. I haven't seen enough concrete use of this= pattern to warrant its own extension though.=20 Which is why I vote #3 - it's a configuration issue. Perhaps we should rath= er say that the AS "SHOULD document the token behavior in the absence of th= is parameter, which may include the token not expiring until explicitly rev= oked, expiring after a set number of uses, or other expiration behavior." T= hat's a lot of words here though. -- Justin On Jan 16, 2012, at 1:53 PM, Eran Hammer wrote: > A question came up about the access token expiration when expires_in is n= ot included in the response. This should probably be made clearer in the sp= ec. The three options are: >=20 > 1. Does not expire (but can be revoked) > 2. Single use token > 3. Defaults to whatever the authorization server decides and until revoke= d >=20 > #3 is the assumed answer given the WG history. I'll note that in the spec= , but wanted to make sure this is the explicit WG consensus. >=20 > EHL >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Mon Jan 16 22:29:43 2012 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 464E521F8584 for ; Mon, 16 Jan 2012 22:29:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.514 X-Spam-Level: X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.085, 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 eQ4xg5LP4hwr for ; Mon, 16 Jan 2012 22:29:42 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 648F621F8540 for ; Mon, 16 Jan 2012 22:29:42 -0800 (PST) Received: (qmail 14726 invoked from network); 17 Jan 2012 06:29:39 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 17 Jan 2012 06:29:39 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 16 Jan 2012 23:29:39 -0700 From: Eran Hammer To: "Richer, Justin P." Date: Mon, 16 Jan 2012 23:29:35 -0700 Thread-Topic: [OAUTH-WG] Access Token Response without expires_in Thread-Index: AczUf8kvUkdgy1nHSGOm5KixWQExDAAclWSAAAQyJIA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453A754C5B1@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723453A754C549@P3PW5EX1MB01.EX1.SECURESERVER.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: "wolter.eldering" , OAuth WG Subject: Re: [OAUTH-WG] Access Token Response without expires_in 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, 17 Jan 2012 06:29:43 -0000 How do you feel about changing expires_in from OPTIONAL to RECOMMENDED? EHL > -----Original Message----- > From: Richer, Justin P. [mailto:jricher@mitre.org] > Sent: Monday, January 16, 2012 7:29 PM > To: Eran Hammer > Cc: OAuth WG; wolter.eldering > Subject: Re: [OAUTH-WG] Access Token Response without expires_in >=20 > I think #3. >=20 > #1 will be a common instance, and #2 (or its variant, a limited number of > uses) is a different expiration pattern than time that would want to have= its > own expiration parameter name. I haven't seen enough concrete use of this > pattern to warrant its own extension though. >=20 > Which is why I vote #3 - it's a configuration issue. Perhaps we should ra= ther > say that the AS "SHOULD document the token behavior in the absence of thi= s > parameter, which may include the token not expiring until explicitly revo= ked, > expiring after a set number of uses, or other expiration behavior." That'= s a lot > of words here though. >=20 > -- Justin >=20 > On Jan 16, 2012, at 1:53 PM, Eran Hammer wrote: >=20 > > A question came up about the access token expiration when expires_in is > not included in the response. This should probably be made clearer in the > spec. The three options are: > > > > 1. Does not expire (but can be revoked) 2. Single use token 3. > > Defaults to whatever the authorization server decides and until > > revoked > > > > #3 is the assumed answer given the WG history. I'll note that in the sp= ec, > but wanted to make sure this is the explicit WG consensus. > > > > EHL > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth From aaron@parecki.com Mon Jan 16 22:36:32 2012 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 CA08421F85C4 for ; Mon, 16 Jan 2012 22:36:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTMrMPI130SJ for ; Mon, 16 Jan 2012 22:36:32 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9439421F85C0 for ; Mon, 16 Jan 2012 22:36:31 -0800 (PST) Received: by wics10 with SMTP id s10so1920035wic.31 for ; Mon, 16 Jan 2012 22:36:29 -0800 (PST) Received: by 10.180.94.97 with SMTP id db1mr25511805wib.16.1326782189594; Mon, 16 Jan 2012 22:36:29 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by mx.google.com with ESMTPS id fd1sm15141502wib.0.2012.01.16.22.36.27 (version=SSLv3 cipher=OTHER); Mon, 16 Jan 2012 22:36:28 -0800 (PST) Received: by werp11 with SMTP id p11so275432wer.31 for ; Mon, 16 Jan 2012 22:36:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.138.226 with SMTP id a76mr6278961wej.51.1326782186998; Mon, 16 Jan 2012 22:36:26 -0800 (PST) Received: by 10.223.87.204 with HTTP; Mon, 16 Jan 2012 22:36:26 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453A754C5B1@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723453A754C549@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723453A754C5B1@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 16 Jan 2012 22:36:26 -0800 Message-ID: From: Aaron Parecki To: OAuth WG Content-Type: multipart/alternative; boundary=0016e6d7ea90f34def04b6b38cec Cc: "wolter.eldering" Subject: Re: [OAUTH-WG] Access Token Response without expires_in 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, 17 Jan 2012 06:36:32 -0000 --0016e6d7ea90f34def04b6b38cec Content-Type: text/plain; charset=UTF-8 That seems like a good idea, but then it should also be explicitly stated what to do if the server issues non-expiring tokens. aaronpk On Mon, Jan 16, 2012 at 10:29 PM, Eran Hammer wrote: > How do you feel about changing expires_in from OPTIONAL to RECOMMENDED? > > EHL > > > -----Original Message----- > > From: Richer, Justin P. [mailto:jricher@mitre.org] > > Sent: Monday, January 16, 2012 7:29 PM > > To: Eran Hammer > > Cc: OAuth WG; wolter.eldering > > Subject: Re: [OAUTH-WG] Access Token Response without expires_in > > > > I think #3. > > > > #1 will be a common instance, and #2 (or its variant, a limited number of > > uses) is a different expiration pattern than time that would want to > have its > > own expiration parameter name. I haven't seen enough concrete use of this > > pattern to warrant its own extension though. > > > > Which is why I vote #3 - it's a configuration issue. Perhaps we should > rather > > say that the AS "SHOULD document the token behavior in the absence of > this > > parameter, which may include the token not expiring until explicitly > revoked, > > expiring after a set number of uses, or other expiration behavior." > That's a lot > > of words here though. > > > > -- Justin > > > > On Jan 16, 2012, at 1:53 PM, Eran Hammer wrote: > > > > > A question came up about the access token expiration when expires_in is > > not included in the response. This should probably be made clearer in the > > spec. The three options are: > > > > > > 1. Does not expire (but can be revoked) 2. Single use token 3. > > > Defaults to whatever the authorization server decides and until > > > revoked > > > > > > #3 is the assumed answer given the WG history. I'll note that in the > spec, > > but wanted to make sure this is the explicit WG consensus. > > > > > > EHL > > > > > > > > > _______________________________________________ > > > 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 > --0016e6d7ea90f34def04b6b38cec Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable That seems like a good idea, but then it should also be explicitly stated w= hat to do if the server issues non-expiring tokens.

aaro= npk


On Mon, Jan 16, 2012 at 10:2= 9 PM, Eran Hammer <eran@hueniverse.com> wrote:
How do you feel about changing expires_in fr= om OPTIONAL to RECOMMENDED?

EHL

> -----Original Message-----
> From: Richer, Justin P. [mailto:j= richer@mitre.org]
> Sent: Monday, January 16, 2012 7:29 PM
> To: Eran Hammer
> Cc: OAuth WG; wolter.eldering
> Subject: Re: [OAUTH-WG] Access Token Response without expires_in
>
> I think #3.
>
> #1 will be a common instance, and #2 (or its variant, a limited number= of
> uses) is a different expiration pattern than time that would want to h= ave its
> own expiration parameter name. I haven't seen enough concrete use = of this
> pattern to warrant its own extension though.
>
> Which is why I vote #3 - it's a configuration issue. Perhaps we sh= ould rather
> say that the AS "SHOULD document the token behavior in the absenc= e of this
> parameter, which may include the token not expiring until explicitly r= evoked,
> expiring after a set number of uses, or other expiration behavior.&quo= t; That's a lot
> of words here though.
>
> =C2=A0-- Justin
>
> On Jan 16, 2012, at 1:53 PM, Eran Hammer wrote:
>
> > A question came up about the access token expiration when expires= _in is
> not included in the response. This should probably be made clearer in = the
> spec. The three options are:
> >
> > 1. Does not expire (but can be revoked) 2. Single use token 3. > > Defaults to whatever the authorization server decides and until > > revoked
> >
> > #3 is the assumed answer given the WG history. I'll note that= in the spec,
> but wanted to make sure this is the explicit WG consensus.
> >
> > EHL
> >
> >
> > _______________________________________________
> > 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

--0016e6d7ea90f34def04b6b38cec-- From eran@hueniverse.com Mon Jan 16 22:37:50 2012 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 295B621F85CC for ; Mon, 16 Jan 2012 22:37:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.080, 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 S4EtgvwToUEt for ; Mon, 16 Jan 2012 22:37:49 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 5B35521F85C9 for ; Mon, 16 Jan 2012 22:37:49 -0800 (PST) Received: (qmail 30099 invoked from network); 17 Jan 2012 06:37:48 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 17 Jan 2012 06:37:48 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 16 Jan 2012 23:37:48 -0700 From: Eran Hammer To: Aaron Parecki , OAuth WG Date: Mon, 16 Jan 2012 23:37:44 -0700 Thread-Topic: [OAUTH-WG] Access Token Response without expires_in Thread-Index: AczU4lpyZsOLTHMlQeCb2u0/BUYeWQAABY6w Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453A754C5B3@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723453A754C549@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723453A754C5B1@P3PW5EX1MB01.EX1.SECURESERVER.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: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723453A754C5B3P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "wolter.eldering" Subject: Re: [OAUTH-WG] Access Token Response without expires_in 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, 17 Jan 2012 06:37:50 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723453A754C5B3P3PW5EX1MB01E_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SG1tLiBUaGlzIG1pZ2h0IGJlY29tZSB0b28gbXVjaCB3b3JrIGF0IHRoaXMgc3RhZ2XigKYNCg0K SGFwcHkgZm9yIHN1Z2dlc3Rpb25zIGJ1dCBJIHdvbuKAmXQgcHVyc3VlIGl0IG9uIG15IG93biBm b3Igbm93Lg0KDQpFSEwNCg0KRnJvbTogQWFyb24gUGFyZWNraSBbbWFpbHRvOmFhcm9uQHBhcmVj a2kuY29tXQ0KU2VudDogTW9uZGF5LCBKYW51YXJ5IDE2LCAyMDEyIDEwOjM2IFBNDQpUbzogT0F1 dGggV0cNCkNjOiBSaWNoZXIsIEp1c3RpbiBQLjsgd29sdGVyLmVsZGVyaW5nOyBFcmFuIEhhbW1l cg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gQWNjZXNzIFRva2VuIFJlc3BvbnNlIHdpdGhvdXQg ZXhwaXJlc19pbg0KDQpUaGF0IHNlZW1zIGxpa2UgYSBnb29kIGlkZWEsIGJ1dCB0aGVuIGl0IHNo b3VsZCBhbHNvIGJlIGV4cGxpY2l0bHkgc3RhdGVkIHdoYXQgdG8gZG8gaWYgdGhlIHNlcnZlciBp c3N1ZXMgbm9uLWV4cGlyaW5nIHRva2Vucy4NCg0KYWFyb25waw0KDQpPbiBNb24sIEphbiAxNiwg MjAxMiBhdCAxMDoyOSBQTSwgRXJhbiBIYW1tZXIgPGVyYW5AaHVlbml2ZXJzZS5jb208bWFpbHRv OmVyYW5AaHVlbml2ZXJzZS5jb20+PiB3cm90ZToNCkhvdyBkbyB5b3UgZmVlbCBhYm91dCBjaGFu Z2luZyBleHBpcmVzX2luIGZyb20gT1BUSU9OQUwgdG8gUkVDT01NRU5ERUQ/DQoNCkVITA0KDQo+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFJpY2hlciwgSnVzdGluIFAuIFtt YWlsdG86anJpY2hlckBtaXRyZS5vcmc8bWFpbHRvOmpyaWNoZXJAbWl0cmUub3JnPl0NCj4gU2Vu dDogTW9uZGF5LCBKYW51YXJ5IDE2LCAyMDEyIDc6MjkgUE0NCj4gVG86IEVyYW4gSGFtbWVyDQo+ IENjOiBPQXV0aCBXRzsgd29sdGVyLmVsZGVyaW5nDQo+IFN1YmplY3Q6IFJlOiBbT0FVVEgtV0dd IEFjY2VzcyBUb2tlbiBSZXNwb25zZSB3aXRob3V0IGV4cGlyZXNfaW4NCj4NCj4gSSB0aGluayAj My4NCj4NCj4gIzEgd2lsbCBiZSBhIGNvbW1vbiBpbnN0YW5jZSwgYW5kICMyIChvciBpdHMgdmFy aWFudCwgYSBsaW1pdGVkIG51bWJlciBvZg0KPiB1c2VzKSBpcyBhIGRpZmZlcmVudCBleHBpcmF0 aW9uIHBhdHRlcm4gdGhhbiB0aW1lIHRoYXQgd291bGQgd2FudCB0byBoYXZlIGl0cw0KPiBvd24g ZXhwaXJhdGlvbiBwYXJhbWV0ZXIgbmFtZS4gSSBoYXZlbid0IHNlZW4gZW5vdWdoIGNvbmNyZXRl IHVzZSBvZiB0aGlzDQo+IHBhdHRlcm4gdG8gd2FycmFudCBpdHMgb3duIGV4dGVuc2lvbiB0aG91 Z2guDQo+DQo+IFdoaWNoIGlzIHdoeSBJIHZvdGUgIzMgLSBpdCdzIGEgY29uZmlndXJhdGlvbiBp c3N1ZS4gUGVyaGFwcyB3ZSBzaG91bGQgcmF0aGVyDQo+IHNheSB0aGF0IHRoZSBBUyAiU0hPVUxE IGRvY3VtZW50IHRoZSB0b2tlbiBiZWhhdmlvciBpbiB0aGUgYWJzZW5jZSBvZiB0aGlzDQo+IHBh cmFtZXRlciwgd2hpY2ggbWF5IGluY2x1ZGUgdGhlIHRva2VuIG5vdCBleHBpcmluZyB1bnRpbCBl eHBsaWNpdGx5IHJldm9rZWQsDQo+IGV4cGlyaW5nIGFmdGVyIGEgc2V0IG51bWJlciBvZiB1c2Vz LCBvciBvdGhlciBleHBpcmF0aW9uIGJlaGF2aW9yLiIgVGhhdCdzIGEgbG90DQo+IG9mIHdvcmRz IGhlcmUgdGhvdWdoLg0KPg0KPiAgLS0gSnVzdGluDQo+DQo+IE9uIEphbiAxNiwgMjAxMiwgYXQg MTo1MyBQTSwgRXJhbiBIYW1tZXIgd3JvdGU6DQo+DQo+ID4gQSBxdWVzdGlvbiBjYW1lIHVwIGFi b3V0IHRoZSBhY2Nlc3MgdG9rZW4gZXhwaXJhdGlvbiB3aGVuIGV4cGlyZXNfaW4gaXMNCj4gbm90 IGluY2x1ZGVkIGluIHRoZSByZXNwb25zZS4gVGhpcyBzaG91bGQgcHJvYmFibHkgYmUgbWFkZSBj bGVhcmVyIGluIHRoZQ0KPiBzcGVjLiBUaGUgdGhyZWUgb3B0aW9ucyBhcmU6DQo+ID4NCj4gPiAx LiBEb2VzIG5vdCBleHBpcmUgKGJ1dCBjYW4gYmUgcmV2b2tlZCkgMi4gU2luZ2xlIHVzZSB0b2tl biAzLg0KPiA+IERlZmF1bHRzIHRvIHdoYXRldmVyIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBk ZWNpZGVzIGFuZCB1bnRpbA0KPiA+IHJldm9rZWQNCj4gPg0KPiA+ICMzIGlzIHRoZSBhc3N1bWVk IGFuc3dlciBnaXZlbiB0aGUgV0cgaGlzdG9yeS4gSSdsbCBub3RlIHRoYXQgaW4gdGhlIHNwZWMs DQo+IGJ1dCB3YW50ZWQgdG8gbWFrZSBzdXJlIHRoaXMgaXMgdGhlIGV4cGxpY2l0IFdHIGNvbnNl bnN1cy4NCj4gPg0KPiA+IEVITA0KPiA+DQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IE9BdXRoIG1haWxpbmcgbGlzdA0KPiA+IE9B dXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCj4gPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3Jn PG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vb2F1dGgNCg0K --_000_90C41DD21FB7C64BB94121FBBC2E723453A754C5B3P3PW5EX1MB01E_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5IGxhbmc9RU4tVVMgbGluaz1ibHVlIHZsaW5rPXB1cnBs ZT48ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xv cjojMUY0OTdEJz5IbW0uIFRoaXMgbWlnaHQgYmVjb21lIHRvbyBtdWNoIHdvcmsgYXQgdGhpcyBz dGFnZeKApjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SGFwcHkgZm9yIHN1Z2dlc3Rpb25zIGJ1dCBJIHdv buKAmXQgcHVyc3VlIGl0IG9uIG15IG93biBmb3Igbm93LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+RUhM PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMx RjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2IHN0eWxlPSdib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQn PjxkaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4nPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJp ZiInPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPiBBYXJvbiBQYXJlY2tpIFttYWlsdG86YWFyb25A cGFyZWNraS5jb21dIDxicj48Yj5TZW50OjwvYj4gTW9uZGF5LCBKYW51YXJ5IDE2LCAyMDEyIDEw OjM2IFBNPGJyPjxiPlRvOjwvYj4gT0F1dGggV0c8YnI+PGI+Q2M6PC9iPiBSaWNoZXIsIEp1c3Rp biBQLjsgd29sdGVyLmVsZGVyaW5nOyBFcmFuIEhhbW1lcjxicj48Yj5TdWJqZWN0OjwvYj4gUmU6 IFtPQVVUSC1XR10gQWNjZXNzIFRva2VuIFJlc3BvbnNlIHdpdGhvdXQgZXhwaXJlc19pbjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJz cDs8L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPlRoYXQgc2VlbXMgbGlrZSBhIGdvb2QgaWRl YSwgYnV0IHRoZW4gaXQgc2hvdWxkIGFsc28gYmUgZXhwbGljaXRseSBzdGF0ZWQgd2hhdCB0byBk byBpZiB0aGUgc2VydmVyIGlzc3VlcyBub24tZXhwaXJpbmcgdG9rZW5zLjxvOnA+PC9vOnA+PC9w PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPmFhcm9ucGs8bzpwPjwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9w PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPk9uIE1vbiwgSmFuIDE2LCAyMDEyIGF0IDEwOjI5IFBN LCBFcmFuIEhhbW1lciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVyYW5AaHVlbml2ZXJzZS5jb20iPmVy YW5AaHVlbml2ZXJzZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+SG93IGRvIHlvdSBmZWVsIGFib3V0IGNoYW5naW5nIGV4cGlyZXNfaW4gZnJvbSBP UFRJT05BTCB0byBSRUNPTU1FTkRFRD88YnI+PGJyPkVITDxvOnA+PC9vOnA+PC9wPjxkaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+PGJyPiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08 YnI+Jmd0OyBGcm9tOiBSaWNoZXIsIEp1c3RpbiBQLiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpq cmljaGVyQG1pdHJlLm9yZyI+anJpY2hlckBtaXRyZS5vcmc8L2E+XTxicj4mZ3Q7IFNlbnQ6IE1v bmRheSwgSmFudWFyeSAxNiwgMjAxMiA3OjI5IFBNPGJyPiZndDsgVG86IEVyYW4gSGFtbWVyPGJy PiZndDsgQ2M6IE9BdXRoIFdHOyB3b2x0ZXIuZWxkZXJpbmc8YnI+Jmd0OyBTdWJqZWN0OiBSZTog W09BVVRILVdHXSBBY2Nlc3MgVG9rZW4gUmVzcG9uc2Ugd2l0aG91dCBleHBpcmVzX2luPGJyPiZn dDs8YnI+Jmd0OyBJIHRoaW5rICMzLjxicj4mZ3Q7PGJyPiZndDsgIzEgd2lsbCBiZSBhIGNvbW1v biBpbnN0YW5jZSwgYW5kICMyIChvciBpdHMgdmFyaWFudCwgYSBsaW1pdGVkIG51bWJlciBvZjxi cj4mZ3Q7IHVzZXMpIGlzIGEgZGlmZmVyZW50IGV4cGlyYXRpb24gcGF0dGVybiB0aGFuIHRpbWUg dGhhdCB3b3VsZCB3YW50IHRvIGhhdmUgaXRzPGJyPiZndDsgb3duIGV4cGlyYXRpb24gcGFyYW1l dGVyIG5hbWUuIEkgaGF2ZW4ndCBzZWVuIGVub3VnaCBjb25jcmV0ZSB1c2Ugb2YgdGhpczxicj4m Z3Q7IHBhdHRlcm4gdG8gd2FycmFudCBpdHMgb3duIGV4dGVuc2lvbiB0aG91Z2guPGJyPiZndDs8 YnI+Jmd0OyBXaGljaCBpcyB3aHkgSSB2b3RlICMzIC0gaXQncyBhIGNvbmZpZ3VyYXRpb24gaXNz dWUuIFBlcmhhcHMgd2Ugc2hvdWxkIHJhdGhlcjxicj4mZ3Q7IHNheSB0aGF0IHRoZSBBUyAmcXVv dDtTSE9VTEQgZG9jdW1lbnQgdGhlIHRva2VuIGJlaGF2aW9yIGluIHRoZSBhYnNlbmNlIG9mIHRo aXM8YnI+Jmd0OyBwYXJhbWV0ZXIsIHdoaWNoIG1heSBpbmNsdWRlIHRoZSB0b2tlbiBub3QgZXhw aXJpbmcgdW50aWwgZXhwbGljaXRseSByZXZva2VkLDxicj4mZ3Q7IGV4cGlyaW5nIGFmdGVyIGEg c2V0IG51bWJlciBvZiB1c2VzLCBvciBvdGhlciBleHBpcmF0aW9uIGJlaGF2aW9yLiZxdW90OyBU aGF0J3MgYSBsb3Q8YnI+Jmd0OyBvZiB3b3JkcyBoZXJlIHRob3VnaC48YnI+Jmd0Ozxicj4mZ3Q7 ICZuYnNwOy0tIEp1c3Rpbjxicj4mZ3Q7PGJyPiZndDsgT24gSmFuIDE2LCAyMDEyLCBhdCAxOjUz IFBNLCBFcmFuIEhhbW1lciB3cm90ZTo8YnI+Jmd0Ozxicj4mZ3Q7ICZndDsgQSBxdWVzdGlvbiBj YW1lIHVwIGFib3V0IHRoZSBhY2Nlc3MgdG9rZW4gZXhwaXJhdGlvbiB3aGVuIGV4cGlyZXNfaW4g aXM8YnI+Jmd0OyBub3QgaW5jbHVkZWQgaW4gdGhlIHJlc3BvbnNlLiBUaGlzIHNob3VsZCBwcm9i YWJseSBiZSBtYWRlIGNsZWFyZXIgaW4gdGhlPGJyPiZndDsgc3BlYy4gVGhlIHRocmVlIG9wdGlv bnMgYXJlOjxicj4mZ3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7IDEuIERvZXMgbm90IGV4cGlyZSAoYnV0 IGNhbiBiZSByZXZva2VkKSAyLiBTaW5nbGUgdXNlIHRva2VuIDMuPGJyPiZndDsgJmd0OyBEZWZh dWx0cyB0byB3aGF0ZXZlciB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgZGVjaWRlcyBhbmQgdW50 aWw8YnI+Jmd0OyAmZ3Q7IHJldm9rZWQ8YnI+Jmd0OyAmZ3Q7PGJyPiZndDsgJmd0OyAjMyBpcyB0 aGUgYXNzdW1lZCBhbnN3ZXIgZ2l2ZW4gdGhlIFdHIGhpc3RvcnkuIEknbGwgbm90ZSB0aGF0IGlu IHRoZSBzcGVjLDxicj4mZ3Q7IGJ1dCB3YW50ZWQgdG8gbWFrZSBzdXJlIHRoaXMgaXMgdGhlIGV4 cGxpY2l0IFdHIGNvbnNlbnN1cy48YnI+Jmd0OyAmZ3Q7PGJyPiZndDsgJmd0OyBFSEw8YnI+Jmd0 OyAmZ3Q7PGJyPiZndDsgJmd0Ozxicj4mZ3Q7ICZndDsgX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+Jmd0OyAmZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxi cj4mZ3Q7ICZndDsgPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9y ZzwvYT48YnI+Jmd0OyAmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL29hdXRoPC9hPjxicj48YnI+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+T0F1dGggbWFpbGluZyBsaXN0PGJyPjxhIGhyZWY9Im1h aWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPjxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+ PC9wPjwvZGl2PjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpw PjwvcD48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2JvZHk+PC9odG1sPg== --_000_90C41DD21FB7C64BB94121FBBC2E723453A754C5B3P3PW5EX1MB01E_-- From aaron@parecki.com Mon Jan 16 23:07:47 2012 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 A2E6B21F85E4 for ; Mon, 16 Jan 2012 23:07:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.092 X-Spam-Level: X-Spam-Status: No, score=-2.092 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_FONT_FACE_BAD=0.884, 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 X2uJNnNP6ELg for ; Mon, 16 Jan 2012 23:07:46 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7ADA221F85B4 for ; Mon, 16 Jan 2012 23:07:46 -0800 (PST) Received: by wgbdq11 with SMTP id dq11so1073638wgb.13 for ; Mon, 16 Jan 2012 23:07:45 -0800 (PST) Received: by 10.180.94.97 with SMTP id db1mr25668049wib.16.1326784063537; Mon, 16 Jan 2012 23:07:43 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by mx.google.com with ESMTPS id l8sm26361342wiy.5.2012.01.16.23.07.41 (version=SSLv3 cipher=OTHER); Mon, 16 Jan 2012 23:07:42 -0800 (PST) Received: by wics10 with SMTP id s10so1937357wic.31 for ; Mon, 16 Jan 2012 23:07:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.180.82.41 with SMTP id f9mr25677020wiy.7.1326784061442; Mon, 16 Jan 2012 23:07:41 -0800 (PST) Received: by 10.223.87.204 with HTTP; Mon, 16 Jan 2012 23:07:41 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453A754C5B3@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723453A754C549@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723453A754C5B1@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723453A754C5B3@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 16 Jan 2012 23:07:41 -0800 Message-ID: From: Aaron Parecki To: OAuth WG Content-Type: multipart/alternative; boundary=f46d041826e6ad0c6b04b6b3fc1c Cc: "wolter.eldering" Subject: Re: [OAUTH-WG] Access Token Response without expires_in 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, 17 Jan 2012 07:07:47 -0000 --f46d041826e6ad0c6b04b6b3fc1c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Actually now I'm having second thoughts about making expires_in RECOMMENDED. Here's another attempt at a clarification: expires_in OPTIONAL. The lifetime in seconds of the access token. For example, the value "3600" denotes that the access token will expire in one hour from the time the response was generated. *If omitted, the authorization server SHOULD document the* * default expiration time or indicate that the token will not* * expire until explicitly revoked.* -aaronpk On Mon, Jan 16, 2012 at 10:37 PM, Eran Hammer wrote: > Hmm. This might become too much work at this stage=E2=80=A6**** > > ** ** > > Happy for suggestions but I won=E2=80=99t pursue it on my own for now.***= * > > ** ** > > EHL**** > > ** ** > > *From:* Aaron Parecki [mailto:aaron@parecki.com] > *Sent:* Monday, January 16, 2012 10:36 PM > *To:* OAuth WG > *Cc:* Richer, Justin P.; wolter.eldering; Eran Hammer > > *Subject:* Re: [OAUTH-WG] Access Token Response without expires_in**** > > ** ** > > That seems like a good idea, but then it should also be explicitly stated > what to do if the server issues non-expiring tokens.**** > > ** ** > > aaronpk**** > > ** ** > > On Mon, Jan 16, 2012 at 10:29 PM, Eran Hammer wrote= : > **** > > How do you feel about changing expires_in from OPTIONAL to RECOMMENDED? > > EHL**** > > > > -----Original Message----- > > From: Richer, Justin P. [mailto:jricher@mitre.org] > > Sent: Monday, January 16, 2012 7:29 PM > > To: Eran Hammer > > Cc: OAuth WG; wolter.eldering > > Subject: Re: [OAUTH-WG] Access Token Response without expires_in > > > > I think #3. > > > > #1 will be a common instance, and #2 (or its variant, a limited number = of > > uses) is a different expiration pattern than time that would want to > have its > > own expiration parameter name. I haven't seen enough concrete use of th= is > > pattern to warrant its own extension though. > > > > Which is why I vote #3 - it's a configuration issue. Perhaps we should > rather > > say that the AS "SHOULD document the token behavior in the absence of > this > > parameter, which may include the token not expiring until explicitly > revoked, > > expiring after a set number of uses, or other expiration behavior." > That's a lot > > of words here though. > > > > -- Justin > > > > On Jan 16, 2012, at 1:53 PM, Eran Hammer wrote: > > > > > A question came up about the access token expiration when expires_in = is > > not included in the response. This should probably be made clearer in t= he > > spec. The three options are: > > > > > > 1. Does not expire (but can be revoked) 2. Single use token 3. > > > Defaults to whatever the authorization server decides and until > > > revoked > > > > > > #3 is the assumed answer given the WG history. I'll note that in the > spec, > > but wanted to make sure this is the explicit WG consensus. > > > > > > EHL > > > > > > > > > _______________________________________________ > > > 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**** > > ** ** > --f46d041826e6ad0c6b04b6b3fc1c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Actually now I'm = having second thoughts about making expires_in RECOMMENDED. Here's anot= her attempt at a clarification:

expires_i= n
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0OPTIONAL. =C2=A0The lifetime in seconds of the a= ccess token. =C2=A0For
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0example, the value "3600" denotes that the access token wi= ll
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0expire in one hour from the time the response wa= s generated.
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0If omitted, the authorization server SHOULD document= the
<= b>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0default expiration time or indicate tha= t the token will not
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0expire until explicitly revoked.

=
-aaronpk


On Mon, Jan 16,= 2012 at 10:37 PM, Eran Hammer <eran@hueniverse.com> wrote:

Hmm. This mig= ht become too much work at this stage=E2=80=A6

=C2=A0

Happy for suggestio= ns but I won=E2=80=99t pursue it on my own for now.

=C2=A0

EHL

=C2=A0

From: Aaron Parecki [mailto:aaron@parecki.com]
Sent: Monday, January 16, 2012 10:36 PM
To: OAuth WG
Cc: Richer, Justin P.; wolter.eldering; Eran Hammer


Subject: Re: [OAUTH-WG] Access Token Response wit= hout expires_in

<= /u>=C2=A0

That seems like a good idea, but= then it should also be explicitly stated what to do if the server issues n= on-expiring tokens.

=C2=A0

aaronpk

=C2=A0

On = Mon, Jan 16, 2012 at 10:29 PM, Eran Hammer <eran@hueniverse.com> wrote:

How do you feel about changing expires_in from OPTIO= NAL to RECOMMENDED?

EHL


> -----Original Message-----
> From: Richer, Justin P. [= mailto:jricher@mitre= .org]
> Sent: Monday, January 16, 2012 7:29 PM
> To: Eran Hammer
>= Cc: OAuth WG; wolter.eldering
> Subject: Re: [OAUTH-WG] Access Token= Response without expires_in
>
> I think #3.
>
> #1= will be a common instance, and #2 (or its variant, a limited number of
> uses) is a different expiration pattern than time that would want to h= ave its
> own expiration parameter name. I haven't seen enough co= ncrete use of this
> pattern to warrant its own extension though.
>
> Which is why I vote #3 - it's a configuration issue. Perha= ps we should rather
> say that the AS "SHOULD document the token= behavior in the absence of this
> parameter, which may include the t= oken not expiring until explicitly revoked,
> expiring after a set number of uses, or other expiration behavior.&quo= t; That's a lot
> of words here though.
>
> =C2=A0-- = Justin
>
> On Jan 16, 2012, at 1:53 PM, Eran Hammer wrote:
&= gt;
> > A question came up about the access token expiration when expires= _in is
> not included in the response. This should probably be made c= learer in the
> spec. The three options are:
> >
> >= ; 1. Does not expire (but can be revoked) 2. Single use token 3.
> > Defaults to whatever the authorization server decides and until> > revoked
> >
> > #3 is the assumed answer give= n the WG history. I'll note that in the spec,
> but wanted to mak= e sure this is the explicit WG consensus.
> >
> > EHL
> >
> >
> > _________= ______________________________________
> > OAuth mailing list
&= gt; > OAuth@ietf.org=
> > https://www.ietf.org/mailman/listinfo/oauth

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

=C2=A0


--f46d041826e6ad0c6b04b6b3fc1c-- From eran@hueniverse.com Mon Jan 16 23:20:02 2012 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 0F56821F85CE for ; Mon, 16 Jan 2012 23:20:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.076, 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 74x0CW4+wwo9 for ; Mon, 16 Jan 2012 23:20:01 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 26BBC21F8598 for ; Mon, 16 Jan 2012 23:20:01 -0800 (PST) Received: (qmail 8997 invoked from network); 17 Jan 2012 07:20:00 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 17 Jan 2012 07:19:59 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Tue, 17 Jan 2012 00:19:59 -0700 From: Eran Hammer To: Aaron Parecki , OAuth WG Date: Tue, 17 Jan 2012 00:19:54 -0700 Thread-Topic: [OAUTH-WG] Access Token Response without expires_in Thread-Index: AczU5raFa8mUsTtlS7SDZ/Iw8bxoUQAAa+gg Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453A754C5B6@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723453A754C549@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723453A754C5B1@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723453A754C5B3@P3PW5EX1MB01.EX1.SECURESERVER.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: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723453A754C5B6P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "wolter.eldering" Subject: Re: [OAUTH-WG] Access Token Response without expires_in 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, 17 Jan 2012 07:20:02 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723453A754C5B6P3PW5EX1MB01E_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V0ZNLg0KDQpGcm9tOiBBYXJvbiBQYXJlY2tpIFttYWlsdG86YWFyb25AcGFyZWNraS5jb21dDQpT ZW50OiBNb25kYXksIEphbnVhcnkgMTYsIDIwMTIgMTE6MDggUE0NClRvOiBPQXV0aCBXRw0KQ2M6 IEVyYW4gSGFtbWVyOyBSaWNoZXIsIEp1c3RpbiBQLjsgd29sdGVyLmVsZGVyaW5nDQpTdWJqZWN0 OiBSZTogW09BVVRILVdHXSBBY2Nlc3MgVG9rZW4gUmVzcG9uc2Ugd2l0aG91dCBleHBpcmVzX2lu DQoNCkFjdHVhbGx5IG5vdyBJJ20gaGF2aW5nIHNlY29uZCB0aG91Z2h0cyBhYm91dCBtYWtpbmcg ZXhwaXJlc19pbiBSRUNPTU1FTkRFRC4gSGVyZSdzIGFub3RoZXIgYXR0ZW1wdCBhdCBhIGNsYXJp ZmljYXRpb246DQoNCmV4cGlyZXNfaW4NCiAgICAgICAgIE9QVElPTkFMLiAgVGhlIGxpZmV0aW1l IGluIHNlY29uZHMgb2YgdGhlIGFjY2VzcyB0b2tlbi4gIEZvcg0KICAgICAgICAgZXhhbXBsZSwg dGhlIHZhbHVlICIzNjAwIiBkZW5vdGVzIHRoYXQgdGhlIGFjY2VzcyB0b2tlbiB3aWxsDQogICAg ICAgICBleHBpcmUgaW4gb25lIGhvdXIgZnJvbSB0aGUgdGltZSB0aGUgcmVzcG9uc2Ugd2FzIGdl bmVyYXRlZC4NCiAgICAgICAgIElmIG9taXR0ZWQsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBT SE9VTEQgZG9jdW1lbnQgdGhlDQogICAgICAgICBkZWZhdWx0IGV4cGlyYXRpb24gdGltZSBvciBp bmRpY2F0ZSB0aGF0IHRoZSB0b2tlbiB3aWxsIG5vdA0KICAgICAgICAgZXhwaXJlIHVudGlsIGV4 cGxpY2l0bHkgcmV2b2tlZC4NCg0KLWFhcm9ucGsNCg0KT24gTW9uLCBKYW4gMTYsIDIwMTIgYXQg MTA6MzcgUE0sIEVyYW4gSGFtbWVyIDxlcmFuQGh1ZW5pdmVyc2UuY29tPG1haWx0bzplcmFuQGh1 ZW5pdmVyc2UuY29tPj4gd3JvdGU6DQpIbW0uIFRoaXMgbWlnaHQgYmVjb21lIHRvbyBtdWNoIHdv cmsgYXQgdGhpcyBzdGFnZeKApg0KDQpIYXBweSBmb3Igc3VnZ2VzdGlvbnMgYnV0IEkgd29u4oCZ dCBwdXJzdWUgaXQgb24gbXkgb3duIGZvciBub3cuDQoNCkVITA0KDQpGcm9tOiBBYXJvbiBQYXJl Y2tpIFttYWlsdG86YWFyb25AcGFyZWNraS5jb208bWFpbHRvOmFhcm9uQHBhcmVja2kuY29tPl0N ClNlbnQ6IE1vbmRheSwgSmFudWFyeSAxNiwgMjAxMiAxMDozNiBQTQ0KVG86IE9BdXRoIFdHDQpD YzogUmljaGVyLCBKdXN0aW4gUC47IHdvbHRlci5lbGRlcmluZzsgRXJhbiBIYW1tZXINCg0KU3Vi amVjdDogUmU6IFtPQVVUSC1XR10gQWNjZXNzIFRva2VuIFJlc3BvbnNlIHdpdGhvdXQgZXhwaXJl c19pbg0KDQpUaGF0IHNlZW1zIGxpa2UgYSBnb29kIGlkZWEsIGJ1dCB0aGVuIGl0IHNob3VsZCBh bHNvIGJlIGV4cGxpY2l0bHkgc3RhdGVkIHdoYXQgdG8gZG8gaWYgdGhlIHNlcnZlciBpc3N1ZXMg bm9uLWV4cGlyaW5nIHRva2Vucy4NCg0KYWFyb25waw0KDQpPbiBNb24sIEphbiAxNiwgMjAxMiBh dCAxMDoyOSBQTSwgRXJhbiBIYW1tZXIgPGVyYW5AaHVlbml2ZXJzZS5jb208bWFpbHRvOmVyYW5A aHVlbml2ZXJzZS5jb20+PiB3cm90ZToNCkhvdyBkbyB5b3UgZmVlbCBhYm91dCBjaGFuZ2luZyBl eHBpcmVzX2luIGZyb20gT1BUSU9OQUwgdG8gUkVDT01NRU5ERUQ/DQoNCkVITA0KDQo+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFJpY2hlciwgSnVzdGluIFAuIFttYWlsdG86 anJpY2hlckBtaXRyZS5vcmc8bWFpbHRvOmpyaWNoZXJAbWl0cmUub3JnPl0NCj4gU2VudDogTW9u ZGF5LCBKYW51YXJ5IDE2LCAyMDEyIDc6MjkgUE0NCj4gVG86IEVyYW4gSGFtbWVyDQo+IENjOiBP QXV0aCBXRzsgd29sdGVyLmVsZGVyaW5nDQo+IFN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIEFjY2Vz cyBUb2tlbiBSZXNwb25zZSB3aXRob3V0IGV4cGlyZXNfaW4NCj4NCj4gSSB0aGluayAjMy4NCj4N Cj4gIzEgd2lsbCBiZSBhIGNvbW1vbiBpbnN0YW5jZSwgYW5kICMyIChvciBpdHMgdmFyaWFudCwg YSBsaW1pdGVkIG51bWJlciBvZg0KPiB1c2VzKSBpcyBhIGRpZmZlcmVudCBleHBpcmF0aW9uIHBh dHRlcm4gdGhhbiB0aW1lIHRoYXQgd291bGQgd2FudCB0byBoYXZlIGl0cw0KPiBvd24gZXhwaXJh dGlvbiBwYXJhbWV0ZXIgbmFtZS4gSSBoYXZlbid0IHNlZW4gZW5vdWdoIGNvbmNyZXRlIHVzZSBv ZiB0aGlzDQo+IHBhdHRlcm4gdG8gd2FycmFudCBpdHMgb3duIGV4dGVuc2lvbiB0aG91Z2guDQo+ DQo+IFdoaWNoIGlzIHdoeSBJIHZvdGUgIzMgLSBpdCdzIGEgY29uZmlndXJhdGlvbiBpc3N1ZS4g UGVyaGFwcyB3ZSBzaG91bGQgcmF0aGVyDQo+IHNheSB0aGF0IHRoZSBBUyAiU0hPVUxEIGRvY3Vt ZW50IHRoZSB0b2tlbiBiZWhhdmlvciBpbiB0aGUgYWJzZW5jZSBvZiB0aGlzDQo+IHBhcmFtZXRl ciwgd2hpY2ggbWF5IGluY2x1ZGUgdGhlIHRva2VuIG5vdCBleHBpcmluZyB1bnRpbCBleHBsaWNp dGx5IHJldm9rZWQsDQo+IGV4cGlyaW5nIGFmdGVyIGEgc2V0IG51bWJlciBvZiB1c2VzLCBvciBv dGhlciBleHBpcmF0aW9uIGJlaGF2aW9yLiIgVGhhdCdzIGEgbG90DQo+IG9mIHdvcmRzIGhlcmUg dGhvdWdoLg0KPg0KPiAgLS0gSnVzdGluDQo+DQo+IE9uIEphbiAxNiwgMjAxMiwgYXQgMTo1MyBQ TSwgRXJhbiBIYW1tZXIgd3JvdGU6DQo+DQo+ID4gQSBxdWVzdGlvbiBjYW1lIHVwIGFib3V0IHRo ZSBhY2Nlc3MgdG9rZW4gZXhwaXJhdGlvbiB3aGVuIGV4cGlyZXNfaW4gaXMNCj4gbm90IGluY2x1 ZGVkIGluIHRoZSByZXNwb25zZS4gVGhpcyBzaG91bGQgcHJvYmFibHkgYmUgbWFkZSBjbGVhcmVy IGluIHRoZQ0KPiBzcGVjLiBUaGUgdGhyZWUgb3B0aW9ucyBhcmU6DQo+ID4NCj4gPiAxLiBEb2Vz IG5vdCBleHBpcmUgKGJ1dCBjYW4gYmUgcmV2b2tlZCkgMi4gU2luZ2xlIHVzZSB0b2tlbiAzLg0K PiA+IERlZmF1bHRzIHRvIHdoYXRldmVyIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBkZWNpZGVz IGFuZCB1bnRpbA0KPiA+IHJldm9rZWQNCj4gPg0KPiA+ICMzIGlzIHRoZSBhc3N1bWVkIGFuc3dl ciBnaXZlbiB0aGUgV0cgaGlzdG9yeS4gSSdsbCBub3RlIHRoYXQgaW4gdGhlIHNwZWMsDQo+IGJ1 dCB3YW50ZWQgdG8gbWFrZSBzdXJlIHRoaXMgaXMgdGhlIGV4cGxpY2l0IFdHIGNvbnNlbnN1cy4N Cj4gPg0KPiA+IEVITA0KPiA+DQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiA+IE9BdXRoIG1haWxpbmcgbGlzdA0KPiA+IE9BdXRoQGll dGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0 bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v b2F1dGgNCg0KDQo= --_000_90C41DD21FB7C64BB94121FBBC2E723453A754C5B6P3PW5EX1MB01E_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpw Lk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdp bjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250 LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1z dHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJz YW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4w aW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxl PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9oZWFkPjxi b2R5IGxhbmc9RU4tVVMgbGluaz1ibHVlIHZsaW5rPXB1cnBsZT48ZGl2IGNsYXNzPVdvcmRTZWN0 aW9uMT48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5XRk0uPG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQnPjxkaXY+ PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGluIDBpbiAwaW4nPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPkZy b206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToi VGFob21hIiwic2Fucy1zZXJpZiInPiBBYXJvbiBQYXJlY2tpIFttYWlsdG86YWFyb25AcGFyZWNr aS5jb21dIDxicj48Yj5TZW50OjwvYj4gTW9uZGF5LCBKYW51YXJ5IDE2LCAyMDEyIDExOjA4IFBN PGJyPjxiPlRvOjwvYj4gT0F1dGggV0c8YnI+PGI+Q2M6PC9iPiBFcmFuIEhhbW1lcjsgUmljaGVy LCBKdXN0aW4gUC47IHdvbHRlci5lbGRlcmluZzxicj48Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVU SC1XR10gQWNjZXNzIFRva2VuIFJlc3BvbnNlIHdpdGhvdXQgZXhwaXJlc19pbjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286 cD48L3A+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1p bHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPkFjdHVhbGx5IG5vdyBJJ20gaGF2aW5nIHNlY29uZCB0 aG91Z2h0cyBhYm91dCBtYWtpbmcgZXhwaXJlc19pbiBSRUNPTU1FTkRFRC4gSGVyZSdzIGFub3Ro ZXIgYXR0ZW1wdCBhdCBhIGNsYXJpZmljYXRpb246PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ291cmllciBOZXci Jz5leHBpcmVzX2luPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ291cmllciBOZXciJz4mbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7T1BUSU9OQUwuICZuYnNwO1RoZSBsaWZldGltZSBpbiBz ZWNvbmRzIG9mIHRoZSBhY2Nlc3MgdG9rZW4uICZuYnNwO0Zvcjwvc3Bhbj48bzpwPjwvbzpwPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Iic+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2V4YW1wbGUs IHRoZSB2YWx1ZSAmcXVvdDszNjAwJnF1b3Q7IGRlbm90ZXMgdGhhdCB0aGUgYWNjZXNzIHRva2Vu IHdpbGw8L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtleHBpcmUgaW4gb25lIGhvdXIgZnJvbSB0aGUgdGltZSB0aGUgcmVz cG9uc2Ugd2FzIGdlbmVyYXRlZC48L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyInPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8Yj5JZiBvbWl0dGVkLCB0aGUg YXV0aG9yaXphdGlvbiBzZXJ2ZXIgU0hPVUxEIGRvY3VtZW50IHRoZTwvYj48L3NwYW4+PG86cD48 L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2Zv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDtkZWZhdWx0IGV4cGlyYXRpb24gdGltZSBvciBpbmRpY2F0ZSB0aGF0IHRoZSB0b2tlbiB3aWxs IG5vdDwvc3Bhbj48L2I+PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtleHBpcmUgdW50aWwgZXhwbGljaXRseSByZXZva2VkLjwv c3Bhbj48L2I+PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86 cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+LWFhcm9ucGs8 bzpwPjwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0 b206MTIuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5P biBNb24sIEphbiAxNiwgMjAxMiBhdCAxMDozNyBQTSwgRXJhbiBIYW1tZXIgJmx0OzxhIGhyZWY9 Im1haWx0bzplcmFuQGh1ZW5pdmVyc2UuY29tIj5lcmFuQGh1ZW5pdmVyc2UuY29tPC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3A+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0n bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzFGNDk3RCc+SG1tLiBUaGlzIG1pZ2h0IGJlY29tZSB0b28gbXVjaCB3b3JrIGF0 IHRoaXMgc3RhZ2XigKY8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjtjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5IYXBweSBmb3Igc3VnZ2VzdGlv bnMgYnV0IEkgd29u4oCZdCBwdXJzdWUgaXQgb24gbXkgb3duIGZvciBub3cuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s b3I6IzFGNDk3RCc+RUhMPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8n PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxkaXYg c3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzow aW4gMGluIDBpbiA0LjBwdCc+PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbic+PHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byc+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gQWFyb24gUGFy ZWNraSBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzphYXJvbkBwYXJlY2tpLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPmFhcm9uQHBhcmVja2kuY29tPC9hPl0gPGJyPjxiPlNlbnQ6PC9iPiBNb25kYXksIEph bnVhcnkgMTYsIDIwMTIgMTA6MzYgUE08YnI+PGI+VG86PC9iPiBPQXV0aCBXRzxicj48Yj5DYzo8 L2I+IFJpY2hlciwgSnVzdGluIFAuOyB3b2x0ZXIuZWxkZXJpbmc7IEVyYW4gSGFtbWVyPC9zcGFu PjxvOnA+PC9vOnA+PC9wPjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PGJyPjxiPlN1Ympl Y3Q6PC9iPiBSZTogW09BVVRILVdHXSBBY2Nlc3MgVG9rZW4gUmVzcG9uc2Ugd2l0aG91dCBleHBp cmVzX2luPG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PGRpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8nPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1h bCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8nPlRoYXQgc2VlbXMgbGlrZSBhIGdvb2QgaWRlYSwgYnV0IHRoZW4gaXQgc2hvdWxkIGFsc28g YmUgZXhwbGljaXRseSBzdGF0ZWQgd2hhdCB0byBkbyBpZiB0aGUgc2VydmVyIGlzc3VlcyBub24t ZXhwaXJpbmcgdG9rZW5zLjxvOnA+PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+ Jm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9 J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz5hYXJv bnBrPG86cD48L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJn aW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Jz4mbmJzcDs8bzpwPjwvbzpwPjwv cD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPk9uIE1vbiwgSmFuIDE2LCAyMDEyIGF0IDEwOjI5 IFBNLCBFcmFuIEhhbW1lciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVyYW5AaHVlbml2ZXJzZS5jb20i IHRhcmdldD0iX2JsYW5rIj5lcmFuQGh1ZW5pdmVyc2UuY29tPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+SG93IGRvIHlvdSBmZWVsIGFib3V0IGNoYW5n aW5nIGV4cGlyZXNfaW4gZnJvbSBPUFRJT05BTCB0byBSRUNPTU1FTkRFRD88YnI+PGJyPkVITDxv OnA+PC9vOnA+PC9wPjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48YnI+Jmd0OyAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4mZ3Q7IEZyb206IFJpY2hlciwgSnVzdGluIFAuIFtt YWlsdG86PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0cmUub3JnIiB0YXJnZXQ9Il9ibGFuayI+ anJpY2hlckBtaXRyZS5vcmc8L2E+XTxicj4mZ3Q7IFNlbnQ6IE1vbmRheSwgSmFudWFyeSAxNiwg MjAxMiA3OjI5IFBNPGJyPiZndDsgVG86IEVyYW4gSGFtbWVyPGJyPiZndDsgQ2M6IE9BdXRoIFdH OyB3b2x0ZXIuZWxkZXJpbmc8YnI+Jmd0OyBTdWJqZWN0OiBSZTogW09BVVRILVdHXSBBY2Nlc3Mg VG9rZW4gUmVzcG9uc2Ugd2l0aG91dCBleHBpcmVzX2luPGJyPiZndDs8YnI+Jmd0OyBJIHRoaW5r ICMzLjxicj4mZ3Q7PGJyPiZndDsgIzEgd2lsbCBiZSBhIGNvbW1vbiBpbnN0YW5jZSwgYW5kICMy IChvciBpdHMgdmFyaWFudCwgYSBsaW1pdGVkIG51bWJlciBvZjxicj4mZ3Q7IHVzZXMpIGlzIGEg ZGlmZmVyZW50IGV4cGlyYXRpb24gcGF0dGVybiB0aGFuIHRpbWUgdGhhdCB3b3VsZCB3YW50IHRv IGhhdmUgaXRzPGJyPiZndDsgb3duIGV4cGlyYXRpb24gcGFyYW1ldGVyIG5hbWUuIEkgaGF2ZW4n dCBzZWVuIGVub3VnaCBjb25jcmV0ZSB1c2Ugb2YgdGhpczxicj4mZ3Q7IHBhdHRlcm4gdG8gd2Fy cmFudCBpdHMgb3duIGV4dGVuc2lvbiB0aG91Z2guPGJyPiZndDs8YnI+Jmd0OyBXaGljaCBpcyB3 aHkgSSB2b3RlICMzIC0gaXQncyBhIGNvbmZpZ3VyYXRpb24gaXNzdWUuIFBlcmhhcHMgd2Ugc2hv dWxkIHJhdGhlcjxicj4mZ3Q7IHNheSB0aGF0IHRoZSBBUyAmcXVvdDtTSE9VTEQgZG9jdW1lbnQg dGhlIHRva2VuIGJlaGF2aW9yIGluIHRoZSBhYnNlbmNlIG9mIHRoaXM8YnI+Jmd0OyBwYXJhbWV0 ZXIsIHdoaWNoIG1heSBpbmNsdWRlIHRoZSB0b2tlbiBub3QgZXhwaXJpbmcgdW50aWwgZXhwbGlj aXRseSByZXZva2VkLDxicj4mZ3Q7IGV4cGlyaW5nIGFmdGVyIGEgc2V0IG51bWJlciBvZiB1c2Vz LCBvciBvdGhlciBleHBpcmF0aW9uIGJlaGF2aW9yLiZxdW90OyBUaGF0J3MgYSBsb3Q8YnI+Jmd0 OyBvZiB3b3JkcyBoZXJlIHRob3VnaC48YnI+Jmd0Ozxicj4mZ3Q7ICZuYnNwOy0tIEp1c3Rpbjxi cj4mZ3Q7PGJyPiZndDsgT24gSmFuIDE2LCAyMDEyLCBhdCAxOjUzIFBNLCBFcmFuIEhhbW1lciB3 cm90ZTo8YnI+Jmd0Ozxicj4mZ3Q7ICZndDsgQSBxdWVzdGlvbiBjYW1lIHVwIGFib3V0IHRoZSBh Y2Nlc3MgdG9rZW4gZXhwaXJhdGlvbiB3aGVuIGV4cGlyZXNfaW4gaXM8YnI+Jmd0OyBub3QgaW5j bHVkZWQgaW4gdGhlIHJlc3BvbnNlLiBUaGlzIHNob3VsZCBwcm9iYWJseSBiZSBtYWRlIGNsZWFy ZXIgaW4gdGhlPGJyPiZndDsgc3BlYy4gVGhlIHRocmVlIG9wdGlvbnMgYXJlOjxicj4mZ3Q7ICZn dDs8YnI+Jmd0OyAmZ3Q7IDEuIERvZXMgbm90IGV4cGlyZSAoYnV0IGNhbiBiZSByZXZva2VkKSAy LiBTaW5nbGUgdXNlIHRva2VuIDMuPGJyPiZndDsgJmd0OyBEZWZhdWx0cyB0byB3aGF0ZXZlciB0 aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgZGVjaWRlcyBhbmQgdW50aWw8YnI+Jmd0OyAmZ3Q7IHJl dm9rZWQ8YnI+Jmd0OyAmZ3Q7PGJyPiZndDsgJmd0OyAjMyBpcyB0aGUgYXNzdW1lZCBhbnN3ZXIg Z2l2ZW4gdGhlIFdHIGhpc3RvcnkuIEknbGwgbm90ZSB0aGF0IGluIHRoZSBzcGVjLDxicj4mZ3Q7 IGJ1dCB3YW50ZWQgdG8gbWFrZSBzdXJlIHRoaXMgaXMgdGhlIGV4cGxpY2l0IFdHIGNvbnNlbnN1 cy48YnI+Jmd0OyAmZ3Q7PGJyPiZndDsgJmd0OyBFSEw8YnI+Jmd0OyAmZ3Q7PGJyPiZndDsgJmd0 Ozxicj4mZ3Q7ICZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+Jmd0OyAmZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxicj4mZ3Q7ICZndDsgPGEgaHJl Zj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8 L2E+PGJyPiZndDsgJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9vYXV0aDwvYT48YnI+PGJyPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPk9BdXRoIG1haWxpbmcgbGlzdDxicj48YSBocmVmPSJtYWls dG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+ PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8 L2E+PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+ Jm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+ PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2 PjwvZGl2PjwvYm9keT48L2h0bWw+ --_000_90C41DD21FB7C64BB94121FBBC2E723453A754C5B6P3PW5EX1MB01E_-- From Michael.Jones@microsoft.com Tue Jan 17 00:01:50 2012 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 76C7821F84D1 for ; Tue, 17 Jan 2012 00:01:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.534 X-Spam-Level: X-Spam-Status: No, score=-3.534 tagged_above=-999 required=5 tests=[AWL=0.064, 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 ztGvkb4tAVSR for ; Tue, 17 Jan 2012 00:01:49 -0800 (PST) Received: from AM1EHSOBE004.bigfish.com (am1ehsobe004.messaging.microsoft.com [213.199.154.207]) by ietfa.amsl.com (Postfix) with ESMTP id C57AE21F84CF for ; Tue, 17 Jan 2012 00:01:48 -0800 (PST) Received: from mail84-am1-R.bigfish.com (10.3.201.252) by AM1EHSOBE004.bigfish.com (10.3.204.24) with Microsoft SMTP Server id 14.1.225.23; Tue, 17 Jan 2012 08:01:43 +0000 Received: from mail84-am1 (localhost [127.0.0.1]) by mail84-am1-R.bigfish.com (Postfix) with ESMTP id B2BB940112; Tue, 17 Jan 2012 08:01:45 +0000 (UTC) X-SpamScore: -41 X-BigFish: VS-41(zz9371Ic89bh179dN542M1432Nc857h98dKzz1202hzz1033IL8275bh8275dhz2fhc1ahc1bhc1ahc1bh2a8h668h839h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-FB-SS: 13, Received-SPF: pass (mail84-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail84-am1 (localhost.localdomain [127.0.0.1]) by mail84-am1 (MessageSwitch) id 1326787305356805_31456; Tue, 17 Jan 2012 08:01:45 +0000 (UTC) Received: from AM1EHSMHS020.bigfish.com (unknown [10.3.201.249]) by mail84-am1.bigfish.com (Postfix) with ESMTP id 53C8928004A; Tue, 17 Jan 2012 08:01:45 +0000 (UTC) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS020.bigfish.com (10.3.206.23) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 17 Jan 2012 08:01:41 +0000 Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.196]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0247.005; Tue, 17 Jan 2012 00:01:33 -0800 From: Mike Jones To: Eran Hammer , Aaron Parecki , OAuth WG Thread-Topic: [OAUTH-WG] Access Token Response without expires_in Thread-Index: AczUf8kvUkdgy1nHSGOm5KixWQExDAAclWSAAAQyJIAACJ8+AAAAC6AAAAELxoAAAG06AAAPeVQA Date: Tue, 17 Jan 2012 08:01:33 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366358386@TK5EX14MBXC285.redmond.corp.microsoft.com> References: <90C41DD21FB7C64BB94121FBBC2E723453A754C549@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723453A754C5B1@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723453A754C5B3@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723453A754C5B6@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453A754C5B6@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.36] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394366358386TK5EX14MBXC285r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "wolter.eldering" Subject: Re: [OAUTH-WG] Access Token Response without expires_in 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, 17 Jan 2012 08:01:50 -0000 --_000_4E1F6AAD24975D4BA5B168042967394366358386TK5EX14MBXC285r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcyBkb2VzbuKAmXQgd29yayBmb3IgbWUsIGFzIGl0IGRvZXNu4oCZdCBtZXNoIHdlbGwgd2l0 aCB0aGUgY2FzZSBvZiB0aGUgdG9rZW4gY29udGFpbmluZyB0aGUgZXhwaXJhdGlvbiB0aW1lLiAg Rm9yIGluc3RhbmNlLCBib3RoIFNBTUwgYW5kIEpXVCB0b2tlbnMgY2FuIGNvbnRhaW4gZXhwaXJh dGlvbiB0aW1lcy4gIEluIHRoaXMgY2FzZSwgdGhlIGV4cGlyZXNfaW4gdGltZSBpcyB1bm5lY2Vz c2FyeSBhbmQgdGhlIHRva2VuIG1heSBoYXZlIG5vIGRlZmF1bHQgZXhwaXJhdGlvbiB0aW1lIGFu ZCB3aWxsIGV4cGlyZSBldmVuIHRob3VnaCBub3QgZXhwbGljaXRseSBpbnZva2VkLg0KDQpJIHdv dWxkIHJlY29tbWVuZCBubyBjaGFuZ2UgdG8gdGhlIGN1cnJlbnQgdGV4dCwgd2hpY2ggaXM6DQog ICBleHBpcmVzX2luDQogICAgICAgICBPUFRJT05BTC4gIFRoZSBsaWZldGltZSBpbiBzZWNvbmRz IG9mIHRoZSBhY2Nlc3MgdG9rZW4uICBGb3INCiAgICAgICAgIGV4YW1wbGUsIHRoZSB2YWx1ZSAi MzYwMCIgZGVub3RlcyB0aGF0IHRoZSBhY2Nlc3MgdG9rZW4gd2lsbA0KICAgICAgICAgZXhwaXJl IGluIG9uZSBob3VyIGZyb20gdGhlIHRpbWUgdGhlIHJlc3BvbnNlIHdhcyBnZW5lcmF0ZWQuDQoN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIC0tIE1pa2UNCg0KRnJvbTogb2F1dGgtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm9hdXRo LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBFcmFuIEhhbW1lcg0KU2VudDogTW9uZGF5 LCBKYW51YXJ5IDE2LCAyMDEyIDExOjIwIFBNDQpUbzogQWFyb24gUGFyZWNraTsgT0F1dGggV0cN CkNjOiB3b2x0ZXIuZWxkZXJpbmcNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIEFjY2VzcyBUb2tl biBSZXNwb25zZSB3aXRob3V0IGV4cGlyZXNfaW4NCg0KV0ZNLg0KDQpGcm9tOiBBYXJvbiBQYXJl Y2tpIFttYWlsdG86YWFyb25AcGFyZWNraS5jb21dPG1haWx0bzpbbWFpbHRvOmFhcm9uQHBhcmVj a2kuY29tXT4NClNlbnQ6IE1vbmRheSwgSmFudWFyeSAxNiwgMjAxMiAxMTowOCBQTQ0KVG86IE9B dXRoIFdHDQpDYzogRXJhbiBIYW1tZXI7IFJpY2hlciwgSnVzdGluIFAuOyB3b2x0ZXIuZWxkZXJp bmcNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIEFjY2VzcyBUb2tlbiBSZXNwb25zZSB3aXRob3V0 IGV4cGlyZXNfaW4NCg0KQWN0dWFsbHkgbm93IEknbSBoYXZpbmcgc2Vjb25kIHRob3VnaHRzIGFi b3V0IG1ha2luZyBleHBpcmVzX2luIFJFQ09NTUVOREVELiBIZXJlJ3MgYW5vdGhlciBhdHRlbXB0 IGF0IGEgY2xhcmlmaWNhdGlvbjoNCg0KZXhwaXJlc19pbg0KICAgICAgICAgT1BUSU9OQUwuICBU aGUgbGlmZXRpbWUgaW4gc2Vjb25kcyBvZiB0aGUgYWNjZXNzIHRva2VuLiAgRm9yDQogICAgICAg ICBleGFtcGxlLCB0aGUgdmFsdWUgIjM2MDAiIGRlbm90ZXMgdGhhdCB0aGUgYWNjZXNzIHRva2Vu IHdpbGwNCiAgICAgICAgIGV4cGlyZSBpbiBvbmUgaG91ciBmcm9tIHRoZSB0aW1lIHRoZSByZXNw b25zZSB3YXMgZ2VuZXJhdGVkLg0KICAgICAgICAgSWYgb21pdHRlZCwgdGhlIGF1dGhvcml6YXRp b24gc2VydmVyIFNIT1VMRCBkb2N1bWVudCB0aGUNCiAgICAgICAgIGRlZmF1bHQgZXhwaXJhdGlv biB0aW1lIG9yIGluZGljYXRlIHRoYXQgdGhlIHRva2VuIHdpbGwgbm90DQogICAgICAgICBleHBp cmUgdW50aWwgZXhwbGljaXRseSByZXZva2VkLg0KDQotYWFyb25waw0KDQpPbiBNb24sIEphbiAx NiwgMjAxMiBhdCAxMDozNyBQTSwgRXJhbiBIYW1tZXIgPGVyYW5AaHVlbml2ZXJzZS5jb208bWFp bHRvOmVyYW5AaHVlbml2ZXJzZS5jb20+PiB3cm90ZToNCkhtbS4gVGhpcyBtaWdodCBiZWNvbWUg dG9vIG11Y2ggd29yayBhdCB0aGlzIHN0YWdl4oCmDQoNCkhhcHB5IGZvciBzdWdnZXN0aW9ucyBi dXQgSSB3b27igJl0IHB1cnN1ZSBpdCBvbiBteSBvd24gZm9yIG5vdy4NCg0KRUhMDQoNCkZyb206 IEFhcm9uIFBhcmVja2kgW21haWx0bzphYXJvbkBwYXJlY2tpLmNvbTxtYWlsdG86YWFyb25AcGFy ZWNraS5jb20+XQ0KU2VudDogTW9uZGF5LCBKYW51YXJ5IDE2LCAyMDEyIDEwOjM2IFBNDQpUbzog T0F1dGggV0cNCkNjOiBSaWNoZXIsIEp1c3RpbiBQLjsgd29sdGVyLmVsZGVyaW5nOyBFcmFuIEhh bW1lcg0KDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBBY2Nlc3MgVG9rZW4gUmVzcG9uc2Ugd2l0 aG91dCBleHBpcmVzX2luDQoNClRoYXQgc2VlbXMgbGlrZSBhIGdvb2QgaWRlYSwgYnV0IHRoZW4g aXQgc2hvdWxkIGFsc28gYmUgZXhwbGljaXRseSBzdGF0ZWQgd2hhdCB0byBkbyBpZiB0aGUgc2Vy dmVyIGlzc3VlcyBub24tZXhwaXJpbmcgdG9rZW5zLg0KDQphYXJvbnBrDQoNCk9uIE1vbiwgSmFu IDE2LCAyMDEyIGF0IDEwOjI5IFBNLCBFcmFuIEhhbW1lciA8ZXJhbkBodWVuaXZlcnNlLmNvbTxt YWlsdG86ZXJhbkBodWVuaXZlcnNlLmNvbT4+IHdyb3RlOg0KSG93IGRvIHlvdSBmZWVsIGFib3V0 IGNoYW5naW5nIGV4cGlyZXNfaW4gZnJvbSBPUFRJT05BTCB0byBSRUNPTU1FTkRFRD8NCg0KRUhM DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUmljaGVyLCBKdXN0aW4g UC4gW21haWx0bzpqcmljaGVyQG1pdHJlLm9yZzxtYWlsdG86anJpY2hlckBtaXRyZS5vcmc+XQ0K PiBTZW50OiBNb25kYXksIEphbnVhcnkgMTYsIDIwMTIgNzoyOSBQTQ0KPiBUbzogRXJhbiBIYW1t ZXINCj4gQ2M6IE9BdXRoIFdHOyB3b2x0ZXIuZWxkZXJpbmcNCj4gU3ViamVjdDogUmU6IFtPQVVU SC1XR10gQWNjZXNzIFRva2VuIFJlc3BvbnNlIHdpdGhvdXQgZXhwaXJlc19pbg0KPg0KPiBJIHRo aW5rICMzLg0KPg0KPiAjMSB3aWxsIGJlIGEgY29tbW9uIGluc3RhbmNlLCBhbmQgIzIgKG9yIGl0 cyB2YXJpYW50LCBhIGxpbWl0ZWQgbnVtYmVyIG9mDQo+IHVzZXMpIGlzIGEgZGlmZmVyZW50IGV4 cGlyYXRpb24gcGF0dGVybiB0aGFuIHRpbWUgdGhhdCB3b3VsZCB3YW50IHRvIGhhdmUgaXRzDQo+ IG93biBleHBpcmF0aW9uIHBhcmFtZXRlciBuYW1lLiBJIGhhdmVuJ3Qgc2VlbiBlbm91Z2ggY29u Y3JldGUgdXNlIG9mIHRoaXMNCj4gcGF0dGVybiB0byB3YXJyYW50IGl0cyBvd24gZXh0ZW5zaW9u IHRob3VnaC4NCj4NCj4gV2hpY2ggaXMgd2h5IEkgdm90ZSAjMyAtIGl0J3MgYSBjb25maWd1cmF0 aW9uIGlzc3VlLiBQZXJoYXBzIHdlIHNob3VsZCByYXRoZXINCj4gc2F5IHRoYXQgdGhlIEFTICJT SE9VTEQgZG9jdW1lbnQgdGhlIHRva2VuIGJlaGF2aW9yIGluIHRoZSBhYnNlbmNlIG9mIHRoaXMN Cj4gcGFyYW1ldGVyLCB3aGljaCBtYXkgaW5jbHVkZSB0aGUgdG9rZW4gbm90IGV4cGlyaW5nIHVu dGlsIGV4cGxpY2l0bHkgcmV2b2tlZCwNCj4gZXhwaXJpbmcgYWZ0ZXIgYSBzZXQgbnVtYmVyIG9m IHVzZXMsIG9yIG90aGVyIGV4cGlyYXRpb24gYmVoYXZpb3IuIiBUaGF0J3MgYSBsb3QNCj4gb2Yg d29yZHMgaGVyZSB0aG91Z2guDQo+DQo+ICAtLSBKdXN0aW4NCj4NCj4gT24gSmFuIDE2LCAyMDEy LCBhdCAxOjUzIFBNLCBFcmFuIEhhbW1lciB3cm90ZToNCj4NCj4gPiBBIHF1ZXN0aW9uIGNhbWUg dXAgYWJvdXQgdGhlIGFjY2VzcyB0b2tlbiBleHBpcmF0aW9uIHdoZW4gZXhwaXJlc19pbiBpcw0K PiBub3QgaW5jbHVkZWQgaW4gdGhlIHJlc3BvbnNlLiBUaGlzIHNob3VsZCBwcm9iYWJseSBiZSBt YWRlIGNsZWFyZXIgaW4gdGhlDQo+IHNwZWMuIFRoZSB0aHJlZSBvcHRpb25zIGFyZToNCj4gPg0K PiA+IDEuIERvZXMgbm90IGV4cGlyZSAoYnV0IGNhbiBiZSByZXZva2VkKSAyLiBTaW5nbGUgdXNl IHRva2VuIDMuDQo+ID4gRGVmYXVsdHMgdG8gd2hhdGV2ZXIgdGhlIGF1dGhvcml6YXRpb24gc2Vy dmVyIGRlY2lkZXMgYW5kIHVudGlsDQo+ID4gcmV2b2tlZA0KPiA+DQo+ID4gIzMgaXMgdGhlIGFz c3VtZWQgYW5zd2VyIGdpdmVuIHRoZSBXRyBoaXN0b3J5LiBJJ2xsIG5vdGUgdGhhdCBpbiB0aGUg c3BlYywNCj4gYnV0IHdhbnRlZCB0byBtYWtlIHN1cmUgdGhpcyBpcyB0aGUgZXhwbGljaXQgV0cg Y29uc2Vuc3VzLg0KPiA+DQo+ID4gRUhMDQo+ID4NCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gT0F1dGggbWFpbGluZyBsaXN0DQo+ ID4gT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KPiA+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0 Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9vYXV0aA0KDQoNCg== --_000_4E1F6AAD24975D4BA5B168042967394366358386TK5EX14MBXC285r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnByZQ0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVk IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0FjZXRhdGUsIGxp Lk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21h Iiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6 IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYi O30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVt YWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5IVE1MUHJl Zm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7 DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1h dHRlZCI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4w aW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48 L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8 L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoaXMgZG9lc27igJl0IHdvcmsgZm9y IG1lLCBhcyBpdCBkb2VzbuKAmXQgbWVzaCB3ZWxsIHdpdGggdGhlIGNhc2Ugb2YgdGhlIHRva2Vu IGNvbnRhaW5pbmcgdGhlIGV4cGlyYXRpb24gdGltZS4mbmJzcDsgRm9yIGluc3RhbmNlLCBib3Ro IFNBTUwgYW5kIEpXVCB0b2tlbnMgY2FuIGNvbnRhaW4NCiBleHBpcmF0aW9uIHRpbWVzLiZuYnNw OyBJbiB0aGlzIGNhc2UsIHRoZSBleHBpcmVzX2luIHRpbWUgaXMgdW5uZWNlc3NhcnkgYW5kIHRo ZSB0b2tlbiBtYXkgaGF2ZSBubyBkZWZhdWx0IGV4cGlyYXRpb24gdGltZSBhbmQgd2lsbCBleHBp cmUgZXZlbiB0aG91Z2ggbm90IGV4cGxpY2l0bHkgaW52b2tlZC48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgd291bGQg cmVjb21tZW5kIG5vIGNoYW5nZSB0byB0aGUgY3VycmVudCB0ZXh0LCB3aGljaCBpczo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1i ZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBleHBpcmVzX2lu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2Ut YnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgT1BUSU9OQUwuJm5ic3A7IFRoZSBsaWZl dGltZSBpbiBzZWNvbmRzIG9mIHRoZSBhY2Nlc3MgdG9rZW4uJm5ic3A7IEZvcjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9y ZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGV4YW1wbGUsIHRoZSB2YWx1ZSAmcXVvdDszNjAwJnF1b3Q7 IGRlbm90ZXMgdGhhdCB0aGUgYWNjZXNzIHRva2VuIHdpbGw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48 c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBleHBpcmUgaW4gb25lIGhvdXIgZnJvbSB0aGUgdGltZSB0aGUgcmVzcG9uc2Ug d2FzIGdlbmVyYXRlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk ZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4gb2F1dGgtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0 Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkVyYW4gSGFtbWVyPGJyPg0KPGI+U2VudDo8L2I+ IE1vbmRheSwgSmFudWFyeSAxNiwgMjAxMiAxMToyMCBQTTxicj4NCjxiPlRvOjwvYj4gQWFyb24g UGFyZWNraTsgT0F1dGggV0c8YnI+DQo8Yj5DYzo8L2I+IHdvbHRlci5lbGRlcmluZzxicj4NCjxi PlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBBY2Nlc3MgVG9rZW4gUmVzcG9uc2Ugd2l0aG91 dCBleHBpcmVzX2luPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldGTS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gQWFyb24gUGFyZWNraQ0KPGEg aHJlZj0ibWFpbHRvOlttYWlsdG86YWFyb25AcGFyZWNraS5jb21dIj5bbWFpbHRvOmFhcm9uQHBh cmVja2kuY29tXTwvYT4gPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgSmFudWFyeSAxNiwgMjAx MiAxMTowOCBQTTxicj4NCjxiPlRvOjwvYj4gT0F1dGggV0c8YnI+DQo8Yj5DYzo8L2I+IEVyYW4g SGFtbWVyOyBSaWNoZXIsIEp1c3RpbiBQLjsgd29sdGVyLmVsZGVyaW5nPGJyPg0KPGI+U3ViamVj dDo8L2I+IFJlOiBbT0FVVEgtV0ddIEFjY2VzcyBUb2tlbiBSZXNwb25zZSB3aXRob3V0IGV4cGly ZXNfaW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5BY3R1YWxseSBub3cgSSdtIGhhdmluZyBzZWNvbmQgdGhvdWdo dHMgYWJvdXQgbWFraW5nIGV4cGlyZXNfaW4gUkVDT01NRU5ERUQuIEhlcmUncyBhbm90aGVyIGF0 dGVtcHQgYXQgYSBjbGFyaWZpY2F0aW9uOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5leHBpcmVzX2luPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7T1BUSU9OQUwuICZuYnNwO1RoZSBsaWZldGltZSBpbiBzZWNvbmRzIG9mIHRoZSBhY2Nl c3MgdG9rZW4uICZuYnNwO0Zvcjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2V4YW1wbGUs IHRoZSB2YWx1ZSAmcXVvdDszNjAwJnF1b3Q7IGRlbm90ZXMgdGhhdCB0aGUgYWNjZXNzIHRva2Vu IHdpbGw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtleHBpcmUgaW4gb25lIGhvdXIgZnJv bSB0aGUgdGltZSB0aGUgcmVzcG9uc2Ugd2FzIGdlbmVyYXRlZC48L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOzxiPklmIG9taXR0ZWQsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZl ciBTSE9VTEQgZG9jdW1lbnQgdGhlPC9iPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O2RlZmF1bHQgZXhwaXJhdGlvbiB0aW1lIG9yIGluZGljYXRlIHRoYXQgdGhlIHRva2VuIHdpbGwg bm90PC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2V4cGlyZSB1bnRpbCBleHBs aWNpdGx5IHJldm9rZWQuPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LWFhcm9ucGs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIEphbiAx NiwgMjAxMiBhdCAxMDozNyBQTSwgRXJhbiBIYW1tZXIgJmx0OzxhIGhyZWY9Im1haWx0bzplcmFu QGh1ZW5pdmVyc2UuY29tIj5lcmFuQGh1ZW5pdmVyc2UuY29tPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhtbS4gVGhpcyBtaWdodCBiZWNvbWUg dG9vIG11Y2ggd29yayBhdCB0aGlzIHN0YWdl4oCmPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGFwcHkgZm9yIHN1 Z2dlc3Rpb25zIGJ1dCBJIHdvbuKAmXQgcHVyc3VlIGl0IG9uIG15IG93biBmb3Igbm93Ljwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPkVITDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij4gQWFyb24gUGFyZWNraSBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzphYXJvbkBwYXJlY2tp LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFhcm9uQHBhcmVja2kuY29tPC9hPl0NCjxicj4NCjxiPlNl bnQ6PC9iPiBNb25kYXksIEphbnVhcnkgMTYsIDIwMTIgMTA6MzYgUE08YnI+DQo8Yj5Ubzo8L2I+ IE9BdXRoIFdHPGJyPg0KPGI+Q2M6PC9iPiBSaWNoZXIsIEp1c3RpbiBQLjsgd29sdGVyLmVsZGVy aW5nOyBFcmFuIEhhbW1lcjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIEFj Y2VzcyBUb2tlbiBSZXNwb25zZSB3aXRob3V0IGV4cGlyZXNfaW48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5U aGF0IHNlZW1zIGxpa2UgYSBnb29kIGlkZWEsIGJ1dCB0aGVuIGl0IHNob3VsZCBhbHNvIGJlIGV4 cGxpY2l0bHkgc3RhdGVkIHdoYXQgdG8gZG8gaWYgdGhlIHNlcnZlciBpc3N1ZXMgbm9uLWV4cGly aW5nIHRva2Vucy48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5hYXJvbnBrPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIE1vbiwg SmFuIDE2LCAyMDEyIGF0IDEwOjI5IFBNLCBFcmFuIEhhbW1lciAmbHQ7PGEgaHJlZj0ibWFpbHRv OmVyYW5AaHVlbml2ZXJzZS5jb20iIHRhcmdldD0iX2JsYW5rIj5lcmFuQGh1ZW5pdmVyc2UuY29t PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkhv dyBkbyB5b3UgZmVlbCBhYm91dCBjaGFuZ2luZyBleHBpcmVzX2luIGZyb20gT1BUSU9OQUwgdG8g UkVDT01NRU5ERUQ/PGJyPg0KPGJyPg0KRUhMPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGJyPg0KJmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLTxicj4NCiZndDsgRnJvbTogUmljaGVyLCBKdXN0aW4gUC4gW21haWx0bzo8YSBocmVmPSJt YWlsdG86anJpY2hlckBtaXRyZS5vcmciIHRhcmdldD0iX2JsYW5rIj5qcmljaGVyQG1pdHJlLm9y ZzwvYT5dPGJyPg0KJmd0OyBTZW50OiBNb25kYXksIEphbnVhcnkgMTYsIDIwMTIgNzoyOSBQTTxi cj4NCiZndDsgVG86IEVyYW4gSGFtbWVyPGJyPg0KJmd0OyBDYzogT0F1dGggV0c7IHdvbHRlci5l bGRlcmluZzxicj4NCiZndDsgU3ViamVjdDogUmU6IFtPQVVUSC1XR10gQWNjZXNzIFRva2VuIFJl c3BvbnNlIHdpdGhvdXQgZXhwaXJlc19pbjxicj4NCiZndDs8YnI+DQomZ3Q7IEkgdGhpbmsgIzMu PGJyPg0KJmd0Ozxicj4NCiZndDsgIzEgd2lsbCBiZSBhIGNvbW1vbiBpbnN0YW5jZSwgYW5kICMy IChvciBpdHMgdmFyaWFudCwgYSBsaW1pdGVkIG51bWJlciBvZjxicj4NCiZndDsgdXNlcykgaXMg YSBkaWZmZXJlbnQgZXhwaXJhdGlvbiBwYXR0ZXJuIHRoYW4gdGltZSB0aGF0IHdvdWxkIHdhbnQg dG8gaGF2ZSBpdHM8YnI+DQomZ3Q7IG93biBleHBpcmF0aW9uIHBhcmFtZXRlciBuYW1lLiBJIGhh dmVuJ3Qgc2VlbiBlbm91Z2ggY29uY3JldGUgdXNlIG9mIHRoaXM8YnI+DQomZ3Q7IHBhdHRlcm4g dG8gd2FycmFudCBpdHMgb3duIGV4dGVuc2lvbiB0aG91Z2guPGJyPg0KJmd0Ozxicj4NCiZndDsg V2hpY2ggaXMgd2h5IEkgdm90ZSAjMyAtIGl0J3MgYSBjb25maWd1cmF0aW9uIGlzc3VlLiBQZXJo YXBzIHdlIHNob3VsZCByYXRoZXI8YnI+DQomZ3Q7IHNheSB0aGF0IHRoZSBBUyAmcXVvdDtTSE9V TEQgZG9jdW1lbnQgdGhlIHRva2VuIGJlaGF2aW9yIGluIHRoZSBhYnNlbmNlIG9mIHRoaXM8YnI+ DQomZ3Q7IHBhcmFtZXRlciwgd2hpY2ggbWF5IGluY2x1ZGUgdGhlIHRva2VuIG5vdCBleHBpcmlu ZyB1bnRpbCBleHBsaWNpdGx5IHJldm9rZWQsPGJyPg0KJmd0OyBleHBpcmluZyBhZnRlciBhIHNl dCBudW1iZXIgb2YgdXNlcywgb3Igb3RoZXIgZXhwaXJhdGlvbiBiZWhhdmlvci4mcXVvdDsgVGhh dCdzIGEgbG90PGJyPg0KJmd0OyBvZiB3b3JkcyBoZXJlIHRob3VnaC48YnI+DQomZ3Q7PGJyPg0K Jmd0OyAmbmJzcDstLSBKdXN0aW48YnI+DQomZ3Q7PGJyPg0KJmd0OyBPbiBKYW4gMTYsIDIwMTIs IGF0IDE6NTMgUE0sIEVyYW4gSGFtbWVyIHdyb3RlOjxicj4NCiZndDs8YnI+DQomZ3Q7ICZndDsg QSBxdWVzdGlvbiBjYW1lIHVwIGFib3V0IHRoZSBhY2Nlc3MgdG9rZW4gZXhwaXJhdGlvbiB3aGVu IGV4cGlyZXNfaW4gaXM8YnI+DQomZ3Q7IG5vdCBpbmNsdWRlZCBpbiB0aGUgcmVzcG9uc2UuIFRo aXMgc2hvdWxkIHByb2JhYmx5IGJlIG1hZGUgY2xlYXJlciBpbiB0aGU8YnI+DQomZ3Q7IHNwZWMu IFRoZSB0aHJlZSBvcHRpb25zIGFyZTo8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgMS4g RG9lcyBub3QgZXhwaXJlIChidXQgY2FuIGJlIHJldm9rZWQpIDIuIFNpbmdsZSB1c2UgdG9rZW4g My48YnI+DQomZ3Q7ICZndDsgRGVmYXVsdHMgdG8gd2hhdGV2ZXIgdGhlIGF1dGhvcml6YXRpb24g c2VydmVyIGRlY2lkZXMgYW5kIHVudGlsPGJyPg0KJmd0OyAmZ3Q7IHJldm9rZWQ8YnI+DQomZ3Q7 ICZndDs8YnI+DQomZ3Q7ICZndDsgIzMgaXMgdGhlIGFzc3VtZWQgYW5zd2VyIGdpdmVuIHRoZSBX RyBoaXN0b3J5LiBJJ2xsIG5vdGUgdGhhdCBpbiB0aGUgc3BlYyw8YnI+DQomZ3Q7IGJ1dCB3YW50 ZWQgdG8gbWFrZSBzdXJlIHRoaXMgaXMgdGhlIGV4cGxpY2l0IFdHIGNvbnNlbnN1cy48YnI+DQom Z3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgRUhMPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0KJmd0OyAmZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxicj4NCiZndDsgJmd0OyA8 YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRm Lm9yZzwvYT48YnI+DQomZ3Q7ICZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+ DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBp ZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_4E1F6AAD24975D4BA5B168042967394366358386TK5EX14MBXC285r_-- From eran@hueniverse.com Tue Jan 17 00:30:16 2012 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 A9DC421F85F4 for ; Tue, 17 Jan 2012 00:30:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.072, 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 CT+in5LaQJUs for ; Tue, 17 Jan 2012 00:30:12 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 7A7B621F8575 for ; Tue, 17 Jan 2012 00:30:12 -0800 (PST) Received: (qmail 15405 invoked from network); 17 Jan 2012 08:30:10 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 17 Jan 2012 08:30:09 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Tue, 17 Jan 2012 01:30:09 -0700 From: Eran Hammer To: Mike Jones , Aaron Parecki , OAuth WG Date: Tue, 17 Jan 2012 01:30:04 -0700 Thread-Topic: [OAUTH-WG] Access Token Response without expires_in Thread-Index: AczUf8kvUkdgy1nHSGOm5KixWQExDAAclWSAAAQyJIAACJ8+AAAAC6AAAAELxoAAAG06AAAPeVQAAB3lc5A= Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453A754C5B7@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723453A754C549@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723453A754C5B1@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723453A754C5B3@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723453A754C5B6@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B168042967394366358386@TK5EX14MBXC285.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366358386@TK5EX14MBXC285.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_90C41DD21FB7C64BB94121FBBC2E723453A754C5B7P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "wolter.eldering" Subject: Re: [OAUTH-WG] Access Token Response without expires_in 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, 17 Jan 2012 08:30:16 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723453A754C5B7P3PW5EX1MB01E_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcyBpcyBjbGVhcmx5IG5vdCBhIHNvbHV0aW9uIGFzIGFjdHVhbCBpbXBsZW1lbnRhdGlvbiBm ZWVkYmFjayByYWlzZWQgdGhpcyBpc3N1ZS4gV2UgaGF2ZSB0byBkb2N1bWVudCB0aGUgbWVhbmlu ZyBvZiB0aGlzIHBhcmFtZXRlciBtaXNzaW5nLiBBbHNvLCB0aGUgZXhhbXBsZSBvZiBhIHNlbGYt Y29udGFpbmVkIHRva2VuIGRvZXMgbm90IGNvbmZsaWN0IHdpdGggYWxzbyBwcm92aWRpbmcgdGhp cyBpbmZvcm1hdGlvbiB2aWEgdGhlIHBhcmFtZXRlciB3aGVuZXZlciBwb3NzaWJsZSB0byBpbXBy b3ZlIGludGVyb3AuDQoNCknigJltIGdvaW5nIHRvIGdvIHdpdGggYWRkaW5nOiBJZiBvbWl0dGVk LCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgU0hPVUxEIHByb3ZpZGUgdGhlIGV4cGlyYXRpb24g dGltZSB2aWEgb3RoZXIgbWVhbnMgb3IgZG9jdW1lbnQgdGhlIGRlZmF1bHQgdmFsdWUuDQoNCkVI TA0KDQpGcm9tOiBNaWtlIEpvbmVzIFttYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29t XQ0KU2VudDogVHVlc2RheSwgSmFudWFyeSAxNywgMjAxMiAxMjowMiBBTQ0KVG86IEVyYW4gSGFt bWVyOyBBYXJvbiBQYXJlY2tpOyBPQXV0aCBXRw0KQ2M6IHdvbHRlci5lbGRlcmluZw0KU3ViamVj dDogUkU6IFtPQVVUSC1XR10gQWNjZXNzIFRva2VuIFJlc3BvbnNlIHdpdGhvdXQgZXhwaXJlc19p bg0KDQpUaGlzIGRvZXNu4oCZdCB3b3JrIGZvciBtZSwgYXMgaXQgZG9lc27igJl0IG1lc2ggd2Vs bCB3aXRoIHRoZSBjYXNlIG9mIHRoZSB0b2tlbiBjb250YWluaW5nIHRoZSBleHBpcmF0aW9uIHRp bWUuICBGb3IgaW5zdGFuY2UsIGJvdGggU0FNTCBhbmQgSldUIHRva2VucyBjYW4gY29udGFpbiBl eHBpcmF0aW9uIHRpbWVzLiAgSW4gdGhpcyBjYXNlLCB0aGUgZXhwaXJlc19pbiB0aW1lIGlzIHVu bmVjZXNzYXJ5IGFuZCB0aGUgdG9rZW4gbWF5IGhhdmUgbm8gZGVmYXVsdCBleHBpcmF0aW9uIHRp bWUgYW5kIHdpbGwgZXhwaXJlIGV2ZW4gdGhvdWdoIG5vdCBleHBsaWNpdGx5IGludm9rZWQuDQoN Ckkgd291bGQgcmVjb21tZW5kIG5vIGNoYW5nZSB0byB0aGUgY3VycmVudCB0ZXh0LCB3aGljaCBp czoNCiAgIGV4cGlyZXNfaW4NCiAgICAgICAgIE9QVElPTkFMLiAgVGhlIGxpZmV0aW1lIGluIHNl Y29uZHMgb2YgdGhlIGFjY2VzcyB0b2tlbi4gIEZvcg0KICAgICAgICAgZXhhbXBsZSwgdGhlIHZh bHVlICIzNjAwIiBkZW5vdGVzIHRoYXQgdGhlIGFjY2VzcyB0b2tlbiB3aWxsDQogICAgICAgICBl eHBpcmUgaW4gb25lIGhvdXIgZnJvbSB0aGUgdGltZSB0aGUgcmVzcG9uc2Ugd2FzIGdlbmVyYXRl ZC4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBvYXV0aC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpv YXV0aC1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddPG1h aWx0bzpbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddPiBPbiBCZWhhbGYgT2YgRXJhbiBI YW1tZXINClNlbnQ6IE1vbmRheSwgSmFudWFyeSAxNiwgMjAxMiAxMToyMCBQTQ0KVG86IEFhcm9u IFBhcmVja2k7IE9BdXRoIFdHDQpDYzogd29sdGVyLmVsZGVyaW5nDQpTdWJqZWN0OiBSZTogW09B VVRILVdHXSBBY2Nlc3MgVG9rZW4gUmVzcG9uc2Ugd2l0aG91dCBleHBpcmVzX2luDQoNCldGTS4N Cg0KRnJvbTogQWFyb24gUGFyZWNraSBbbWFpbHRvOmFhcm9uQHBhcmVja2kuY29tXTxtYWlsdG86 W21haWx0bzphYXJvbkBwYXJlY2tpLmNvbV0+DQpTZW50OiBNb25kYXksIEphbnVhcnkgMTYsIDIw MTIgMTE6MDggUE0NClRvOiBPQXV0aCBXRw0KQ2M6IEVyYW4gSGFtbWVyOyBSaWNoZXIsIEp1c3Rp biBQLjsgd29sdGVyLmVsZGVyaW5nDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBBY2Nlc3MgVG9r ZW4gUmVzcG9uc2Ugd2l0aG91dCBleHBpcmVzX2luDQoNCkFjdHVhbGx5IG5vdyBJJ20gaGF2aW5n IHNlY29uZCB0aG91Z2h0cyBhYm91dCBtYWtpbmcgZXhwaXJlc19pbiBSRUNPTU1FTkRFRC4gSGVy ZSdzIGFub3RoZXIgYXR0ZW1wdCBhdCBhIGNsYXJpZmljYXRpb246DQoNCmV4cGlyZXNfaW4NCiAg ICAgICAgIE9QVElPTkFMLiAgVGhlIGxpZmV0aW1lIGluIHNlY29uZHMgb2YgdGhlIGFjY2VzcyB0 b2tlbi4gIEZvcg0KICAgICAgICAgZXhhbXBsZSwgdGhlIHZhbHVlICIzNjAwIiBkZW5vdGVzIHRo YXQgdGhlIGFjY2VzcyB0b2tlbiB3aWxsDQogICAgICAgICBleHBpcmUgaW4gb25lIGhvdXIgZnJv bSB0aGUgdGltZSB0aGUgcmVzcG9uc2Ugd2FzIGdlbmVyYXRlZC4NCiAgICAgICAgIElmIG9taXR0 ZWQsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBTSE9VTEQgZG9jdW1lbnQgdGhlDQogICAgICAg ICBkZWZhdWx0IGV4cGlyYXRpb24gdGltZSBvciBpbmRpY2F0ZSB0aGF0IHRoZSB0b2tlbiB3aWxs IG5vdA0KICAgICAgICAgZXhwaXJlIHVudGlsIGV4cGxpY2l0bHkgcmV2b2tlZC4NCg0KLWFhcm9u cGsNCg0KT24gTW9uLCBKYW4gMTYsIDIwMTIgYXQgMTA6MzcgUE0sIEVyYW4gSGFtbWVyIDxlcmFu QGh1ZW5pdmVyc2UuY29tPG1haWx0bzplcmFuQGh1ZW5pdmVyc2UuY29tPj4gd3JvdGU6DQpIbW0u IFRoaXMgbWlnaHQgYmVjb21lIHRvbyBtdWNoIHdvcmsgYXQgdGhpcyBzdGFnZeKApg0KDQpIYXBw eSBmb3Igc3VnZ2VzdGlvbnMgYnV0IEkgd29u4oCZdCBwdXJzdWUgaXQgb24gbXkgb3duIGZvciBu b3cuDQoNCkVITA0KDQpGcm9tOiBBYXJvbiBQYXJlY2tpIFttYWlsdG86YWFyb25AcGFyZWNraS5j b208bWFpbHRvOmFhcm9uQHBhcmVja2kuY29tPl0NClNlbnQ6IE1vbmRheSwgSmFudWFyeSAxNiwg MjAxMiAxMDozNiBQTQ0KVG86IE9BdXRoIFdHDQpDYzogUmljaGVyLCBKdXN0aW4gUC47IHdvbHRl ci5lbGRlcmluZzsgRXJhbiBIYW1tZXINCg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gQWNjZXNz IFRva2VuIFJlc3BvbnNlIHdpdGhvdXQgZXhwaXJlc19pbg0KDQpUaGF0IHNlZW1zIGxpa2UgYSBn b29kIGlkZWEsIGJ1dCB0aGVuIGl0IHNob3VsZCBhbHNvIGJlIGV4cGxpY2l0bHkgc3RhdGVkIHdo YXQgdG8gZG8gaWYgdGhlIHNlcnZlciBpc3N1ZXMgbm9uLWV4cGlyaW5nIHRva2Vucy4NCg0KYWFy b25waw0KDQpPbiBNb24sIEphbiAxNiwgMjAxMiBhdCAxMDoyOSBQTSwgRXJhbiBIYW1tZXIgPGVy YW5AaHVlbml2ZXJzZS5jb208bWFpbHRvOmVyYW5AaHVlbml2ZXJzZS5jb20+PiB3cm90ZToNCkhv dyBkbyB5b3UgZmVlbCBhYm91dCBjaGFuZ2luZyBleHBpcmVzX2luIGZyb20gT1BUSU9OQUwgdG8g UkVDT01NRU5ERUQ/DQoNCkVITA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZy b206IFJpY2hlciwgSnVzdGluIFAuIFttYWlsdG86anJpY2hlckBtaXRyZS5vcmc8bWFpbHRvOmpy aWNoZXJAbWl0cmUub3JnPl0NCj4gU2VudDogTW9uZGF5LCBKYW51YXJ5IDE2LCAyMDEyIDc6Mjkg UE0NCj4gVG86IEVyYW4gSGFtbWVyDQo+IENjOiBPQXV0aCBXRzsgd29sdGVyLmVsZGVyaW5nDQo+ IFN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIEFjY2VzcyBUb2tlbiBSZXNwb25zZSB3aXRob3V0IGV4 cGlyZXNfaW4NCj4NCj4gSSB0aGluayAjMy4NCj4NCj4gIzEgd2lsbCBiZSBhIGNvbW1vbiBpbnN0 YW5jZSwgYW5kICMyIChvciBpdHMgdmFyaWFudCwgYSBsaW1pdGVkIG51bWJlciBvZg0KPiB1c2Vz KSBpcyBhIGRpZmZlcmVudCBleHBpcmF0aW9uIHBhdHRlcm4gdGhhbiB0aW1lIHRoYXQgd291bGQg d2FudCB0byBoYXZlIGl0cw0KPiBvd24gZXhwaXJhdGlvbiBwYXJhbWV0ZXIgbmFtZS4gSSBoYXZl bid0IHNlZW4gZW5vdWdoIGNvbmNyZXRlIHVzZSBvZiB0aGlzDQo+IHBhdHRlcm4gdG8gd2FycmFu dCBpdHMgb3duIGV4dGVuc2lvbiB0aG91Z2guDQo+DQo+IFdoaWNoIGlzIHdoeSBJIHZvdGUgIzMg LSBpdCdzIGEgY29uZmlndXJhdGlvbiBpc3N1ZS4gUGVyaGFwcyB3ZSBzaG91bGQgcmF0aGVyDQo+ IHNheSB0aGF0IHRoZSBBUyAiU0hPVUxEIGRvY3VtZW50IHRoZSB0b2tlbiBiZWhhdmlvciBpbiB0 aGUgYWJzZW5jZSBvZiB0aGlzDQo+IHBhcmFtZXRlciwgd2hpY2ggbWF5IGluY2x1ZGUgdGhlIHRv a2VuIG5vdCBleHBpcmluZyB1bnRpbCBleHBsaWNpdGx5IHJldm9rZWQsDQo+IGV4cGlyaW5nIGFm dGVyIGEgc2V0IG51bWJlciBvZiB1c2VzLCBvciBvdGhlciBleHBpcmF0aW9uIGJlaGF2aW9yLiIg VGhhdCdzIGEgbG90DQo+IG9mIHdvcmRzIGhlcmUgdGhvdWdoLg0KPg0KPiAgLS0gSnVzdGluDQo+ DQo+IE9uIEphbiAxNiwgMjAxMiwgYXQgMTo1MyBQTSwgRXJhbiBIYW1tZXIgd3JvdGU6DQo+DQo+ ID4gQSBxdWVzdGlvbiBjYW1lIHVwIGFib3V0IHRoZSBhY2Nlc3MgdG9rZW4gZXhwaXJhdGlvbiB3 aGVuIGV4cGlyZXNfaW4gaXMNCj4gbm90IGluY2x1ZGVkIGluIHRoZSByZXNwb25zZS4gVGhpcyBz aG91bGQgcHJvYmFibHkgYmUgbWFkZSBjbGVhcmVyIGluIHRoZQ0KPiBzcGVjLiBUaGUgdGhyZWUg b3B0aW9ucyBhcmU6DQo+ID4NCj4gPiAxLiBEb2VzIG5vdCBleHBpcmUgKGJ1dCBjYW4gYmUgcmV2 b2tlZCkgMi4gU2luZ2xlIHVzZSB0b2tlbiAzLg0KPiA+IERlZmF1bHRzIHRvIHdoYXRldmVyIHRo ZSBhdXRob3JpemF0aW9uIHNlcnZlciBkZWNpZGVzIGFuZCB1bnRpbA0KPiA+IHJldm9rZWQNCj4g Pg0KPiA+ICMzIGlzIHRoZSBhc3N1bWVkIGFuc3dlciBnaXZlbiB0aGUgV0cgaGlzdG9yeS4gSSds bCBub3RlIHRoYXQgaW4gdGhlIHNwZWMsDQo+IGJ1dCB3YW50ZWQgdG8gbWFrZSBzdXJlIHRoaXMg aXMgdGhlIGV4cGxpY2l0IFdHIGNvbnNlbnN1cy4NCj4gPg0KPiA+IEVITA0KPiA+DQo+ID4NCj4g PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IE9B dXRoIG1haWxpbmcgbGlzdA0KPiA+IE9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9y Zz4NCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWls aW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KDQo= --_000_90C41DD21FB7C64BB94121FBBC2E723453A754C5B7P3PW5EX1MB01E_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpw cmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZv cm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29BY2V0 YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6 IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNv LXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6 IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYi O30NCnNwYW4uRW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVt YWlsU3R5bGUyMw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjQN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+ PGJvZHkgbGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNl Y3Rpb24xPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlRoaXMgaXMg Y2xlYXJseSBub3QgYSBzb2x1dGlvbiBhcyBhY3R1YWwgaW1wbGVtZW50YXRpb24gZmVlZGJhY2sg cmFpc2VkIHRoaXMgaXNzdWUuIFdlIGhhdmUgdG8gZG9jdW1lbnQgdGhlIG1lYW5pbmcgb2YgdGhp cyBwYXJhbWV0ZXIgbWlzc2luZy4gQWxzbywgdGhlIGV4YW1wbGUgb2YgYSBzZWxmLWNvbnRhaW5l ZCB0b2tlbiBkb2VzIG5vdCBjb25mbGljdCB3aXRoIGFsc28gcHJvdmlkaW5nIHRoaXMgaW5mb3Jt YXRpb24gdmlhIHRoZSBwYXJhbWV0ZXIgd2hlbmV2ZXIgcG9zc2libGUgdG8gaW1wcm92ZSBpbnRl cm9wLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xv cjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SeKAmW0gZ29pbmcgdG8gZ28gd2l0aCBhZGRpbmc6IElm IG9taXR0ZWQsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBTSE9VTEQgcHJvdmlkZSB0aGUgZXhw aXJhdGlvbiB0aW1lIHZpYSBvdGhlciBtZWFucyBvciBkb2N1bWVudCB0aGUgZGVmYXVsdCB2YWx1 ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6 IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkVITDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Jz48ZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluJz48 cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gTWlr ZSBKb25lcyBbbWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbV0gPGJyPjxiPlNlbnQ6 PC9iPiBUdWVzZGF5LCBKYW51YXJ5IDE3LCAyMDEyIDEyOjAyIEFNPGJyPjxiPlRvOjwvYj4gRXJh biBIYW1tZXI7IEFhcm9uIFBhcmVja2k7IE9BdXRoIFdHPGJyPjxiPkNjOjwvYj4gd29sdGVyLmVs ZGVyaW5nPGJyPjxiPlN1YmplY3Q6PC9iPiBSRTogW09BVVRILVdHXSBBY2Nlc3MgVG9rZW4gUmVz cG9uc2Ugd2l0aG91dCBleHBpcmVzX2luPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5UaGlzIGRvZXNu4oCZdCB3b3JrIGZvciBtZSwgYXMg aXQgZG9lc27igJl0IG1lc2ggd2VsbCB3aXRoIHRoZSBjYXNlIG9mIHRoZSB0b2tlbiBjb250YWlu aW5nIHRoZSBleHBpcmF0aW9uIHRpbWUuJm5ic3A7IEZvciBpbnN0YW5jZSwgYm90aCBTQU1MIGFu ZCBKV1QgdG9rZW5zIGNhbiBjb250YWluIGV4cGlyYXRpb24gdGltZXMuJm5ic3A7IEluIHRoaXMg Y2FzZSwgdGhlIGV4cGlyZXNfaW4gdGltZSBpcyB1bm5lY2Vzc2FyeSBhbmQgdGhlIHRva2VuIG1h eSBoYXZlIG5vIGRlZmF1bHQgZXhwaXJhdGlvbiB0aW1lIGFuZCB3aWxsIGV4cGlyZSBldmVuIHRo b3VnaCBub3QgZXhwbGljaXRseSBpbnZva2VkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SSB3b3VsZCBy ZWNvbW1lbmQgbm8gY2hhbmdlIHRvIHRoZSBjdXJyZW50IHRleHQsIHdoaWNoIGlzOjxvOnA+PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J3BhZ2UtYnJlYWstYmVmb3Jl OmFsd2F5cyc+PHNwYW4gbGFuZz1FTiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eToiQ291cmllciBOZXciJz4mbmJzcDsmbmJzcDsgZXhwaXJlc19pbjxvOnA+PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J3BhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyc+ PHNwYW4gbGFuZz1FTiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmll ciBOZXciJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg T1BUSU9OQUwuJm5ic3A7IFRoZSBsaWZldGltZSBpbiBzZWNvbmRzIG9mIHRoZSBhY2Nlc3MgdG9r ZW4uJm5ic3A7IEZvcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J3BhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyc+PHNwYW4gbGFuZz1FTiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZXhhbXBsZSwgdGhlIHZhbHVlICZxdW90OzM2 MDAmcXVvdDsgZGVub3RlcyB0aGF0IHRoZSBhY2Nlc3MgdG9rZW4gd2lsbDxvOnA+PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J3BhZ2UtYnJlYWstYmVmb3JlOmFsd2F5 cyc+PHNwYW4gbGFuZz1FTiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291 cmllciBOZXciJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgZXhwaXJlIGluIG9uZSBob3VyIGZyb20gdGhlIHRpbWUgdGhlIHJlc3BvbnNlIHdhcyBnZW5l cmF0ZWQuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2Nv bG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbic+PHAg Y2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IDxhIGhy ZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnIj5vYXV0aC1ib3VuY2VzQGlldGYub3Jn PC9hPiA8YSBocmVmPSJtYWlsdG86W21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSI+W21h aWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXTwvYT4gPGI+T24gQmVoYWxmIE9mIDwvYj5FcmFu IEhhbW1lcjxicj48Yj5TZW50OjwvYj4gTW9uZGF5LCBKYW51YXJ5IDE2LCAyMDEyIDExOjIwIFBN PGJyPjxiPlRvOjwvYj4gQWFyb24gUGFyZWNraTsgT0F1dGggV0c8YnI+PGI+Q2M6PC9iPiB3b2x0 ZXIuZWxkZXJpbmc8YnI+PGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIEFjY2VzcyBUb2tl biBSZXNwb25zZSB3aXRob3V0IGV4cGlyZXNfaW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+ PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPldGTS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJs dWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCc+PGRpdj48ZGl2IHN0eWxlPSdib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g MGluIDBpbic+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNl cmlmIic+IEFhcm9uIFBhcmVja2kgPGEgaHJlZj0ibWFpbHRvOlttYWlsdG86YWFyb25AcGFyZWNr aS5jb21dIj5bbWFpbHRvOmFhcm9uQHBhcmVja2kuY29tXTwvYT4gPGJyPjxiPlNlbnQ6PC9iPiBN b25kYXksIEphbnVhcnkgMTYsIDIwMTIgMTE6MDggUE08YnI+PGI+VG86PC9iPiBPQXV0aCBXRzxi cj48Yj5DYzo8L2I+IEVyYW4gSGFtbWVyOyBSaWNoZXIsIEp1c3RpbiBQLjsgd29sdGVyLmVsZGVy aW5nPGJyPjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBBY2Nlc3MgVG9rZW4gUmVzcG9u c2Ugd2l0aG91dCBleHBpcmVzX2luPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48ZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+ QWN0dWFsbHkgbm93IEknbSBoYXZpbmcgc2Vjb25kIHRob3VnaHRzIGFib3V0IG1ha2luZyBleHBp cmVzX2luIFJFQ09NTUVOREVELiBIZXJlJ3MgYW5vdGhlciBhdHRlbXB0IGF0IGEgY2xhcmlmaWNh dGlvbjo8L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPmV4cGlyZXNfaW48L3NwYW4+PG86cD48 L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtP UFRJT05BTC4gJm5ic3A7VGhlIGxpZmV0aW1lIGluIHNlY29uZHMgb2YgdGhlIGFjY2VzcyB0b2tl bi4gJm5ic3A7Rm9yPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ291cmllciBOZXciJz4mbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZXhhbXBsZSwgdGhlIHZhbHVlICZxdW90OzM2MDAmcXVv dDsgZGVub3RlcyB0aGF0IHRoZSBhY2Nlc3MgdG9rZW4gd2lsbDwvc3Bhbj48bzpwPjwvbzpwPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Iic+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2V4cGlyZSBp biBvbmUgaG91ciBmcm9tIHRoZSB0aW1lIHRoZSByZXNwb25zZSB3YXMgZ2VuZXJhdGVkLjwvc3Bh bj48bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOzxiPklmIG9taXR0ZWQsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBTSE9V TEQgZG9jdW1lbnQgdGhlPC9iPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48Yj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+ Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2RlZmF1bHQgZXhwaXJhdGlvbiB0aW1l IG9yIGluZGljYXRlIHRoYXQgdGhlIHRva2VuIHdpbGwgbm90PC9zcGFuPjwvYj48bzpwPjwvbzpw PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBzdHlsZT0nZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Iic+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2V4 cGlyZSB1bnRpbCBleHBsaWNpdGx5IHJldm9rZWQuPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4tYWFyb25wazxvOnA+PC9vOnA+PC9wPjwvZGl2PjxwIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPk9uIE1vbiwgSmFuIDE2LCAyMDEyIGF0IDEw OjM3IFBNLCBFcmFuIEhhbW1lciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVyYW5AaHVlbml2ZXJzZS5j b20iPmVyYW5AaHVlbml2ZXJzZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD48ZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5IbW0uIFRo aXMgbWlnaHQgYmVjb21lIHRvbyBtdWNoIHdvcmsgYXQgdGhpcyBzdGFnZeKApjwvc3Bhbj48bzpw PjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2Nv bG9yOiMxRjQ5N0QnPkhhcHB5IGZvciBzdWdnZXN0aW9ucyBidXQgSSB3b27igJl0IHB1cnN1ZSBp dCBvbiBteSBvd24gZm9yIG5vdy48L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5FSEw8L3NwYW4+PG86 cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Jz48ZGl2Pjxk aXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBpbiAwaW4gMGluJz48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48Yj48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPkZy b206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToi VGFob21hIiwic2Fucy1zZXJpZiInPiBBYXJvbiBQYXJlY2tpIFttYWlsdG86PGEgaHJlZj0ibWFp bHRvOmFhcm9uQHBhcmVja2kuY29tIiB0YXJnZXQ9Il9ibGFuayI+YWFyb25AcGFyZWNraS5jb208 L2E+XSA8YnI+PGI+U2VudDo8L2I+IE1vbmRheSwgSmFudWFyeSAxNiwgMjAxMiAxMDozNiBQTTxi cj48Yj5Ubzo8L2I+IE9BdXRoIFdHPGJyPjxiPkNjOjwvYj4gUmljaGVyLCBKdXN0aW4gUC47IHdv bHRlci5lbGRlcmluZzsgRXJhbiBIYW1tZXI8L3NwYW4+PG86cD48L286cD48L3A+PGRpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD48YnI+PGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIEFj Y2VzcyBUb2tlbiBSZXNwb25zZSB3aXRob3V0IGV4cGlyZXNfaW48bzpwPjwvbzpwPjwvcD48L2Rp dj48L2Rpdj48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+Jm5ic3A7 PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+VGhhdCBzZWVtcyBsaWtlIGEgZ29v ZCBpZGVhLCBidXQgdGhlbiBpdCBzaG91bGQgYWxzbyBiZSBleHBsaWNpdGx5IHN0YXRlZCB3aGF0 IHRvIGRvIGlmIHRoZSBzZXJ2ZXIgaXNzdWVzIG5vbi1leHBpcmluZyB0b2tlbnMuPG86cD48L286 cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPmFhcm9ucGs8bzpwPjwvbzpwPjwvcD48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJv dHRvbToxMi4wcHQnPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byc+T24gTW9uLCBKYW4gMTYsIDIwMTIgYXQgMTA6MjkgUE0sIEVyYW4gSGFtbWVyICZsdDs8YSBo cmVmPSJtYWlsdG86ZXJhbkBodWVuaXZlcnNlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmVyYW5AaHVl bml2ZXJzZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvJz5Ib3cgZG8geW91IGZlZWwgYWJvdXQgY2hhbmdpbmcgZXhwaXJlc19pbiBmcm9tIE9QVElP TkFMIHRvIFJFQ09NTUVOREVEPzxicj48YnI+RUhMPG86cD48L286cD48L3A+PGRpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8nPjxicj4mZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJy PiZndDsgRnJvbTogUmljaGVyLCBKdXN0aW4gUC4gW21haWx0bzo8YSBocmVmPSJtYWlsdG86anJp Y2hlckBtaXRyZS5vcmciIHRhcmdldD0iX2JsYW5rIj5qcmljaGVyQG1pdHJlLm9yZzwvYT5dPGJy PiZndDsgU2VudDogTW9uZGF5LCBKYW51YXJ5IDE2LCAyMDEyIDc6MjkgUE08YnI+Jmd0OyBUbzog RXJhbiBIYW1tZXI8YnI+Jmd0OyBDYzogT0F1dGggV0c7IHdvbHRlci5lbGRlcmluZzxicj4mZ3Q7 IFN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIEFjY2VzcyBUb2tlbiBSZXNwb25zZSB3aXRob3V0IGV4 cGlyZXNfaW48YnI+Jmd0Ozxicj4mZ3Q7IEkgdGhpbmsgIzMuPGJyPiZndDs8YnI+Jmd0OyAjMSB3 aWxsIGJlIGEgY29tbW9uIGluc3RhbmNlLCBhbmQgIzIgKG9yIGl0cyB2YXJpYW50LCBhIGxpbWl0 ZWQgbnVtYmVyIG9mPGJyPiZndDsgdXNlcykgaXMgYSBkaWZmZXJlbnQgZXhwaXJhdGlvbiBwYXR0 ZXJuIHRoYW4gdGltZSB0aGF0IHdvdWxkIHdhbnQgdG8gaGF2ZSBpdHM8YnI+Jmd0OyBvd24gZXhw aXJhdGlvbiBwYXJhbWV0ZXIgbmFtZS4gSSBoYXZlbid0IHNlZW4gZW5vdWdoIGNvbmNyZXRlIHVz ZSBvZiB0aGlzPGJyPiZndDsgcGF0dGVybiB0byB3YXJyYW50IGl0cyBvd24gZXh0ZW5zaW9uIHRo b3VnaC48YnI+Jmd0Ozxicj4mZ3Q7IFdoaWNoIGlzIHdoeSBJIHZvdGUgIzMgLSBpdCdzIGEgY29u ZmlndXJhdGlvbiBpc3N1ZS4gUGVyaGFwcyB3ZSBzaG91bGQgcmF0aGVyPGJyPiZndDsgc2F5IHRo YXQgdGhlIEFTICZxdW90O1NIT1VMRCBkb2N1bWVudCB0aGUgdG9rZW4gYmVoYXZpb3IgaW4gdGhl IGFic2VuY2Ugb2YgdGhpczxicj4mZ3Q7IHBhcmFtZXRlciwgd2hpY2ggbWF5IGluY2x1ZGUgdGhl IHRva2VuIG5vdCBleHBpcmluZyB1bnRpbCBleHBsaWNpdGx5IHJldm9rZWQsPGJyPiZndDsgZXhw aXJpbmcgYWZ0ZXIgYSBzZXQgbnVtYmVyIG9mIHVzZXMsIG9yIG90aGVyIGV4cGlyYXRpb24gYmVo YXZpb3IuJnF1b3Q7IFRoYXQncyBhIGxvdDxicj4mZ3Q7IG9mIHdvcmRzIGhlcmUgdGhvdWdoLjxi cj4mZ3Q7PGJyPiZndDsgJm5ic3A7LS0gSnVzdGluPGJyPiZndDs8YnI+Jmd0OyBPbiBKYW4gMTYs IDIwMTIsIGF0IDE6NTMgUE0sIEVyYW4gSGFtbWVyIHdyb3RlOjxicj4mZ3Q7PGJyPiZndDsgJmd0 OyBBIHF1ZXN0aW9uIGNhbWUgdXAgYWJvdXQgdGhlIGFjY2VzcyB0b2tlbiBleHBpcmF0aW9uIHdo ZW4gZXhwaXJlc19pbiBpczxicj4mZ3Q7IG5vdCBpbmNsdWRlZCBpbiB0aGUgcmVzcG9uc2UuIFRo aXMgc2hvdWxkIHByb2JhYmx5IGJlIG1hZGUgY2xlYXJlciBpbiB0aGU8YnI+Jmd0OyBzcGVjLiBU aGUgdGhyZWUgb3B0aW9ucyBhcmU6PGJyPiZndDsgJmd0Ozxicj4mZ3Q7ICZndDsgMS4gRG9lcyBu b3QgZXhwaXJlIChidXQgY2FuIGJlIHJldm9rZWQpIDIuIFNpbmdsZSB1c2UgdG9rZW4gMy48YnI+ Jmd0OyAmZ3Q7IERlZmF1bHRzIHRvIHdoYXRldmVyIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBk ZWNpZGVzIGFuZCB1bnRpbDxicj4mZ3Q7ICZndDsgcmV2b2tlZDxicj4mZ3Q7ICZndDs8YnI+Jmd0 OyAmZ3Q7ICMzIGlzIHRoZSBhc3N1bWVkIGFuc3dlciBnaXZlbiB0aGUgV0cgaGlzdG9yeS4gSSds bCBub3RlIHRoYXQgaW4gdGhlIHNwZWMsPGJyPiZndDsgYnV0IHdhbnRlZCB0byBtYWtlIHN1cmUg dGhpcyBpcyB0aGUgZXhwbGljaXQgV0cgY29uc2Vuc3VzLjxicj4mZ3Q7ICZndDs8YnI+Jmd0OyAm Z3Q7IEVITDxicj4mZ3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7PGJyPiZndDsgJmd0OyBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4mZ3Q7ICZndDsgT0F1dGgg bWFpbGluZyBsaXN0PGJyPiZndDsgJmd0OyA8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+Jmd0OyAmZ3Q7IDxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2Js YW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxicj48 YnI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+T0F1 dGggbWFpbGluZyBsaXN0PGJyPjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj48YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD48L2Rpdj48 L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rp dj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29O b3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PC9ib2R5PjwvaHRt bD4= --_000_90C41DD21FB7C64BB94121FBBC2E723453A754C5B7P3PW5EX1MB01E_-- From Michael.Jones@microsoft.com Tue Jan 17 00:55:00 2012 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 C492E21F869E for ; Tue, 17 Jan 2012 00:55:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.636 X-Spam-Level: X-Spam-Status: No, score=-3.636 tagged_above=-999 required=5 tests=[AWL=-0.038, 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 fRLel73KOwu7 for ; Tue, 17 Jan 2012 00:54:56 -0800 (PST) Received: from DB3EHSOBE001.bigfish.com (db3ehsobe001.messaging.microsoft.com [213.199.154.139]) by ietfa.amsl.com (Postfix) with ESMTP id D03C421F869C for ; Tue, 17 Jan 2012 00:54:55 -0800 (PST) Received: from mail99-db3-R.bigfish.com (10.3.81.244) by DB3EHSOBE001.bigfish.com (10.3.84.21) with Microsoft SMTP Server id 14.1.225.23; Tue, 17 Jan 2012 08:54:50 +0000 Received: from mail99-db3 (localhost [127.0.0.1]) by mail99-db3-R.bigfish.com (Postfix) with ESMTP id 04F965E0100; Tue, 17 Jan 2012 08:54:51 +0000 (UTC) X-SpamScore: -41 X-BigFish: VS-41(zz9371Ic89bh179dN542M1432Nc857h98dKzz1202hzz1033IL8275bh8275dhz2fhc1ahc1bhc1ahc1bh2a8h668h839h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-FB-SS: 13, Received-SPF: pass (mail99-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC107.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail99-db3 (localhost.localdomain [127.0.0.1]) by mail99-db3 (MessageSwitch) id 1326790485556546_20648; Tue, 17 Jan 2012 08:54:45 +0000 (UTC) Received: from DB3EHSMHS007.bigfish.com (unknown [10.3.81.249]) by mail99-db3.bigfish.com (Postfix) with ESMTP id 77449220049; Tue, 17 Jan 2012 08:54:45 +0000 (UTC) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS007.bigfish.com (10.3.87.107) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 17 Jan 2012 08:54:42 +0000 Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.196]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0247.005; Tue, 17 Jan 2012 00:54:21 -0800 From: Mike Jones To: Eran Hammer , Aaron Parecki , OAuth WG Thread-Topic: [OAUTH-WG] Access Token Response without expires_in Thread-Index: AczUf8kvUkdgy1nHSGOm5KixWQExDAAclWSAAAQyJIAACJ8+AAAAC6AAAAELxoAAAG06AAAPeVQAAB3lc5AAOt2YYA== Date: Tue, 17 Jan 2012 08:54:20 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943663584A1@TK5EX14MBXC285.redmond.corp.microsoft.com> References: <90C41DD21FB7C64BB94121FBBC2E723453A754C549@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723453A754C5B1@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723453A754C5B3@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723453A754C5B6@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B168042967394366358386@TK5EX14MBXC285.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723453A754C5B7@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453A754C5B7@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.36] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943663584A1TK5EX14MBXC285r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "wolter.eldering" Subject: Re: [OAUTH-WG] Access Token Response without expires_in 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, 17 Jan 2012 08:55:00 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943663584A1TK5EX14MBXC285r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WW91ciBuZXcgd29yZGluZyBpcyBiZXR0ZXIsIGFzIGl0IGRvZXNu4oCZdCBjb25mbGljdCB3aXRo IHRoZSBwb3NzaWJpbGl0eSBvZiB0aGUgZXhwaXJhdGlvbiB0aW1lIGJlaW5nIGluIHRoZSB0b2tl bi4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBFcmFuIEhhbW1lciBbbWFpbHRvOmVyYW5AaHVlbml2 ZXJzZS5jb21dDQpTZW50OiBUdWVzZGF5LCBKYW51YXJ5IDE3LCAyMDEyIDEyOjMwIEFNDQpUbzog TWlrZSBKb25lczsgQWFyb24gUGFyZWNraTsgT0F1dGggV0cNCkNjOiB3b2x0ZXIuZWxkZXJpbmcN ClN1YmplY3Q6IFJFOiBbT0FVVEgtV0ddIEFjY2VzcyBUb2tlbiBSZXNwb25zZSB3aXRob3V0IGV4 cGlyZXNfaW4NCg0KVGhpcyBpcyBjbGVhcmx5IG5vdCBhIHNvbHV0aW9uIGFzIGFjdHVhbCBpbXBs ZW1lbnRhdGlvbiBmZWVkYmFjayByYWlzZWQgdGhpcyBpc3N1ZS4gV2UgaGF2ZSB0byBkb2N1bWVu dCB0aGUgbWVhbmluZyBvZiB0aGlzIHBhcmFtZXRlciBtaXNzaW5nLiBBbHNvLCB0aGUgZXhhbXBs ZSBvZiBhIHNlbGYtY29udGFpbmVkIHRva2VuIGRvZXMgbm90IGNvbmZsaWN0IHdpdGggYWxzbyBw cm92aWRpbmcgdGhpcyBpbmZvcm1hdGlvbiB2aWEgdGhlIHBhcmFtZXRlciB3aGVuZXZlciBwb3Nz aWJsZSB0byBpbXByb3ZlIGludGVyb3AuDQoNCknigJltIGdvaW5nIHRvIGdvIHdpdGggYWRkaW5n OiBJZiBvbWl0dGVkLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgU0hPVUxEIHByb3ZpZGUgdGhl IGV4cGlyYXRpb24gdGltZSB2aWEgb3RoZXIgbWVhbnMgb3IgZG9jdW1lbnQgdGhlIGRlZmF1bHQg dmFsdWUuDQoNCkVITA0KDQpGcm9tOiBNaWtlIEpvbmVzIFttYWlsdG86TWljaGFlbC5Kb25lc0Bt aWNyb3NvZnQuY29tXTxtYWlsdG86W21haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb21d Pg0KU2VudDogVHVlc2RheSwgSmFudWFyeSAxNywgMjAxMiAxMjowMiBBTQ0KVG86IEVyYW4gSGFt bWVyOyBBYXJvbiBQYXJlY2tpOyBPQXV0aCBXRw0KQ2M6IHdvbHRlci5lbGRlcmluZw0KU3ViamVj dDogUkU6IFtPQVVUSC1XR10gQWNjZXNzIFRva2VuIFJlc3BvbnNlIHdpdGhvdXQgZXhwaXJlc19p bg0KDQpUaGlzIGRvZXNu4oCZdCB3b3JrIGZvciBtZSwgYXMgaXQgZG9lc27igJl0IG1lc2ggd2Vs bCB3aXRoIHRoZSBjYXNlIG9mIHRoZSB0b2tlbiBjb250YWluaW5nIHRoZSBleHBpcmF0aW9uIHRp bWUuICBGb3IgaW5zdGFuY2UsIGJvdGggU0FNTCBhbmQgSldUIHRva2VucyBjYW4gY29udGFpbiBl eHBpcmF0aW9uIHRpbWVzLiAgSW4gdGhpcyBjYXNlLCB0aGUgZXhwaXJlc19pbiB0aW1lIGlzIHVu bmVjZXNzYXJ5IGFuZCB0aGUgdG9rZW4gbWF5IGhhdmUgbm8gZGVmYXVsdCBleHBpcmF0aW9uIHRp bWUgYW5kIHdpbGwgZXhwaXJlIGV2ZW4gdGhvdWdoIG5vdCBleHBsaWNpdGx5IGludm9rZWQuDQoN Ckkgd291bGQgcmVjb21tZW5kIG5vIGNoYW5nZSB0byB0aGUgY3VycmVudCB0ZXh0LCB3aGljaCBp czoNCiAgIGV4cGlyZXNfaW4NCiAgICAgICAgIE9QVElPTkFMLiAgVGhlIGxpZmV0aW1lIGluIHNl Y29uZHMgb2YgdGhlIGFjY2VzcyB0b2tlbi4gIEZvcg0KICAgICAgICAgZXhhbXBsZSwgdGhlIHZh bHVlICIzNjAwIiBkZW5vdGVzIHRoYXQgdGhlIGFjY2VzcyB0b2tlbiB3aWxsDQogICAgICAgICBl eHBpcmUgaW4gb25lIGhvdXIgZnJvbSB0aGUgdGltZSB0aGUgcmVzcG9uc2Ugd2FzIGdlbmVyYXRl ZC4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBvYXV0aC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpv YXV0aC1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddPG1h aWx0bzpbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddPiBPbiBCZWhhbGYgT2YgRXJhbiBI YW1tZXINClNlbnQ6IE1vbmRheSwgSmFudWFyeSAxNiwgMjAxMiAxMToyMCBQTQ0KVG86IEFhcm9u IFBhcmVja2k7IE9BdXRoIFdHDQpDYzogd29sdGVyLmVsZGVyaW5nDQpTdWJqZWN0OiBSZTogW09B VVRILVdHXSBBY2Nlc3MgVG9rZW4gUmVzcG9uc2Ugd2l0aG91dCBleHBpcmVzX2luDQoNCldGTS4N Cg0KRnJvbTogQWFyb24gUGFyZWNraSBbbWFpbHRvOmFhcm9uQHBhcmVja2kuY29tXTxtYWlsdG86 W21haWx0bzphYXJvbkBwYXJlY2tpLmNvbV0+DQpTZW50OiBNb25kYXksIEphbnVhcnkgMTYsIDIw MTIgMTE6MDggUE0NClRvOiBPQXV0aCBXRw0KQ2M6IEVyYW4gSGFtbWVyOyBSaWNoZXIsIEp1c3Rp biBQLjsgd29sdGVyLmVsZGVyaW5nDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBBY2Nlc3MgVG9r ZW4gUmVzcG9uc2Ugd2l0aG91dCBleHBpcmVzX2luDQoNCkFjdHVhbGx5IG5vdyBJJ20gaGF2aW5n IHNlY29uZCB0aG91Z2h0cyBhYm91dCBtYWtpbmcgZXhwaXJlc19pbiBSRUNPTU1FTkRFRC4gSGVy ZSdzIGFub3RoZXIgYXR0ZW1wdCBhdCBhIGNsYXJpZmljYXRpb246DQoNCmV4cGlyZXNfaW4NCiAg ICAgICAgIE9QVElPTkFMLiAgVGhlIGxpZmV0aW1lIGluIHNlY29uZHMgb2YgdGhlIGFjY2VzcyB0 b2tlbi4gIEZvcg0KICAgICAgICAgZXhhbXBsZSwgdGhlIHZhbHVlICIzNjAwIiBkZW5vdGVzIHRo YXQgdGhlIGFjY2VzcyB0b2tlbiB3aWxsDQogICAgICAgICBleHBpcmUgaW4gb25lIGhvdXIgZnJv bSB0aGUgdGltZSB0aGUgcmVzcG9uc2Ugd2FzIGdlbmVyYXRlZC4NCiAgICAgICAgIElmIG9taXR0 ZWQsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBTSE9VTEQgZG9jdW1lbnQgdGhlDQogICAgICAg ICBkZWZhdWx0IGV4cGlyYXRpb24gdGltZSBvciBpbmRpY2F0ZSB0aGF0IHRoZSB0b2tlbiB3aWxs IG5vdA0KICAgICAgICAgZXhwaXJlIHVudGlsIGV4cGxpY2l0bHkgcmV2b2tlZC4NCg0KLWFhcm9u cGsNCg0KT24gTW9uLCBKYW4gMTYsIDIwMTIgYXQgMTA6MzcgUE0sIEVyYW4gSGFtbWVyIDxlcmFu QGh1ZW5pdmVyc2UuY29tPG1haWx0bzplcmFuQGh1ZW5pdmVyc2UuY29tPj4gd3JvdGU6DQpIbW0u IFRoaXMgbWlnaHQgYmVjb21lIHRvbyBtdWNoIHdvcmsgYXQgdGhpcyBzdGFnZeKApg0KDQpIYXBw eSBmb3Igc3VnZ2VzdGlvbnMgYnV0IEkgd29u4oCZdCBwdXJzdWUgaXQgb24gbXkgb3duIGZvciBu b3cuDQoNCkVITA0KDQpGcm9tOiBBYXJvbiBQYXJlY2tpIFttYWlsdG86YWFyb25AcGFyZWNraS5j b208bWFpbHRvOmFhcm9uQHBhcmVja2kuY29tPl0NClNlbnQ6IE1vbmRheSwgSmFudWFyeSAxNiwg MjAxMiAxMDozNiBQTQ0KVG86IE9BdXRoIFdHDQpDYzogUmljaGVyLCBKdXN0aW4gUC47IHdvbHRl ci5lbGRlcmluZzsgRXJhbiBIYW1tZXINCg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gQWNjZXNz IFRva2VuIFJlc3BvbnNlIHdpdGhvdXQgZXhwaXJlc19pbg0KDQpUaGF0IHNlZW1zIGxpa2UgYSBn b29kIGlkZWEsIGJ1dCB0aGVuIGl0IHNob3VsZCBhbHNvIGJlIGV4cGxpY2l0bHkgc3RhdGVkIHdo YXQgdG8gZG8gaWYgdGhlIHNlcnZlciBpc3N1ZXMgbm9uLWV4cGlyaW5nIHRva2Vucy4NCg0KYWFy b25waw0KDQpPbiBNb24sIEphbiAxNiwgMjAxMiBhdCAxMDoyOSBQTSwgRXJhbiBIYW1tZXIgPGVy YW5AaHVlbml2ZXJzZS5jb208bWFpbHRvOmVyYW5AaHVlbml2ZXJzZS5jb20+PiB3cm90ZToNCkhv dyBkbyB5b3UgZmVlbCBhYm91dCBjaGFuZ2luZyBleHBpcmVzX2luIGZyb20gT1BUSU9OQUwgdG8g UkVDT01NRU5ERUQ/DQoNCkVITA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZy b206IFJpY2hlciwgSnVzdGluIFAuIFttYWlsdG86anJpY2hlckBtaXRyZS5vcmc8bWFpbHRvOmpy aWNoZXJAbWl0cmUub3JnPl0NCj4gU2VudDogTW9uZGF5LCBKYW51YXJ5IDE2LCAyMDEyIDc6Mjkg UE0NCj4gVG86IEVyYW4gSGFtbWVyDQo+IENjOiBPQXV0aCBXRzsgd29sdGVyLmVsZGVyaW5nDQo+ IFN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIEFjY2VzcyBUb2tlbiBSZXNwb25zZSB3aXRob3V0IGV4 cGlyZXNfaW4NCj4NCj4gSSB0aGluayAjMy4NCj4NCj4gIzEgd2lsbCBiZSBhIGNvbW1vbiBpbnN0 YW5jZSwgYW5kICMyIChvciBpdHMgdmFyaWFudCwgYSBsaW1pdGVkIG51bWJlciBvZg0KPiB1c2Vz KSBpcyBhIGRpZmZlcmVudCBleHBpcmF0aW9uIHBhdHRlcm4gdGhhbiB0aW1lIHRoYXQgd291bGQg d2FudCB0byBoYXZlIGl0cw0KPiBvd24gZXhwaXJhdGlvbiBwYXJhbWV0ZXIgbmFtZS4gSSBoYXZl bid0IHNlZW4gZW5vdWdoIGNvbmNyZXRlIHVzZSBvZiB0aGlzDQo+IHBhdHRlcm4gdG8gd2FycmFu dCBpdHMgb3duIGV4dGVuc2lvbiB0aG91Z2guDQo+DQo+IFdoaWNoIGlzIHdoeSBJIHZvdGUgIzMg LSBpdCdzIGEgY29uZmlndXJhdGlvbiBpc3N1ZS4gUGVyaGFwcyB3ZSBzaG91bGQgcmF0aGVyDQo+ IHNheSB0aGF0IHRoZSBBUyAiU0hPVUxEIGRvY3VtZW50IHRoZSB0b2tlbiBiZWhhdmlvciBpbiB0 aGUgYWJzZW5jZSBvZiB0aGlzDQo+IHBhcmFtZXRlciwgd2hpY2ggbWF5IGluY2x1ZGUgdGhlIHRv a2VuIG5vdCBleHBpcmluZyB1bnRpbCBleHBsaWNpdGx5IHJldm9rZWQsDQo+IGV4cGlyaW5nIGFm dGVyIGEgc2V0IG51bWJlciBvZiB1c2VzLCBvciBvdGhlciBleHBpcmF0aW9uIGJlaGF2aW9yLiIg VGhhdCdzIGEgbG90DQo+IG9mIHdvcmRzIGhlcmUgdGhvdWdoLg0KPg0KPiAgLS0gSnVzdGluDQo+ DQo+IE9uIEphbiAxNiwgMjAxMiwgYXQgMTo1MyBQTSwgRXJhbiBIYW1tZXIgd3JvdGU6DQo+DQo+ ID4gQSBxdWVzdGlvbiBjYW1lIHVwIGFib3V0IHRoZSBhY2Nlc3MgdG9rZW4gZXhwaXJhdGlvbiB3 aGVuIGV4cGlyZXNfaW4gaXMNCj4gbm90IGluY2x1ZGVkIGluIHRoZSByZXNwb25zZS4gVGhpcyBz aG91bGQgcHJvYmFibHkgYmUgbWFkZSBjbGVhcmVyIGluIHRoZQ0KPiBzcGVjLiBUaGUgdGhyZWUg b3B0aW9ucyBhcmU6DQo+ID4NCj4gPiAxLiBEb2VzIG5vdCBleHBpcmUgKGJ1dCBjYW4gYmUgcmV2 b2tlZCkgMi4gU2luZ2xlIHVzZSB0b2tlbiAzLg0KPiA+IERlZmF1bHRzIHRvIHdoYXRldmVyIHRo ZSBhdXRob3JpemF0aW9uIHNlcnZlciBkZWNpZGVzIGFuZCB1bnRpbA0KPiA+IHJldm9rZWQNCj4g Pg0KPiA+ICMzIGlzIHRoZSBhc3N1bWVkIGFuc3dlciBnaXZlbiB0aGUgV0cgaGlzdG9yeS4gSSds bCBub3RlIHRoYXQgaW4gdGhlIHNwZWMsDQo+IGJ1dCB3YW50ZWQgdG8gbWFrZSBzdXJlIHRoaXMg aXMgdGhlIGV4cGxpY2l0IFdHIGNvbnNlbnN1cy4NCj4gPg0KPiA+IEVITA0KPiA+DQo+ID4NCj4g PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IE9B dXRoIG1haWxpbmcgbGlzdA0KPiA+IE9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9y Zz4NCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWls aW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KDQo= --_000_4E1F6AAD24975D4BA5B1680429673943663584A1TK5EX14MBXC285r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnByZQ0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVk IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0FjZXRhdGUsIGxp Lk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21h Iiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUt bmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Ijt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9v biBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi QmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bh bi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHls ZTIzDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyNA0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjUNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41 aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVO LVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+WW91ciBuZXcgd29yZGluZyBpcyBiZXR0ZXIsIGFzIGl0IGRvZXNu4oCZdCBj b25mbGljdCB3aXRoIHRoZSBwb3NzaWJpbGl0eSBvZiB0aGUgZXhwaXJhdGlvbiB0aW1lIGJlaW5n IGluIHRoZSB0b2tlbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk ZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4gRXJhbiBIYW1tZXIgW21haWx0bzplcmFuQGh1ZW5pdmVyc2UuY29tXQ0KPGJyPg0K PGI+U2VudDo8L2I+IFR1ZXNkYXksIEphbnVhcnkgMTcsIDIwMTIgMTI6MzAgQU08YnI+DQo8Yj5U bzo8L2I+IE1pa2UgSm9uZXM7IEFhcm9uIFBhcmVja2k7IE9BdXRoIFdHPGJyPg0KPGI+Q2M6PC9i PiB3b2x0ZXIuZWxkZXJpbmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtPQVVUSC1XR10gQWNj ZXNzIFRva2VuIFJlc3BvbnNlIHdpdGhvdXQgZXhwaXJlc19pbjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5UaGlzIGlzIGNsZWFybHkgbm90IGEgc29sdXRpb24gYXMgYWN0dWFsIGlt cGxlbWVudGF0aW9uIGZlZWRiYWNrIHJhaXNlZCB0aGlzIGlzc3VlLiBXZSBoYXZlIHRvIGRvY3Vt ZW50IHRoZSBtZWFuaW5nIG9mIHRoaXMgcGFyYW1ldGVyIG1pc3NpbmcuIEFsc28sIHRoZSBleGFt cGxlDQogb2YgYSBzZWxmLWNvbnRhaW5lZCB0b2tlbiBkb2VzIG5vdCBjb25mbGljdCB3aXRoIGFs c28gcHJvdmlkaW5nIHRoaXMgaW5mb3JtYXRpb24gdmlhIHRoZSBwYXJhbWV0ZXIgd2hlbmV2ZXIg cG9zc2libGUgdG8gaW1wcm92ZSBpbnRlcm9wLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SeKAmW0gZ29pbmcgdG8gZ28g d2l0aCBhZGRpbmc6IElmIG9taXR0ZWQsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBTSE9VTEQg cHJvdmlkZSB0aGUgZXhwaXJhdGlvbiB0aW1lIHZpYSBvdGhlciBtZWFucyBvciBkb2N1bWVudCB0 aGUgZGVmYXVsdCB2YWx1ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkVITDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQi Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRE RiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPiBNaWtlIEpvbmVzDQo8YSBocmVmPSJtYWlsdG86W21haWx0bzpN aWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb21dIj5bbWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9z b2Z0LmNvbV08L2E+DQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgSmFudWFyeSAxNywgMjAx MiAxMjowMiBBTTxicj4NCjxiPlRvOjwvYj4gRXJhbiBIYW1tZXI7IEFhcm9uIFBhcmVja2k7IE9B dXRoIFdHPGJyPg0KPGI+Q2M6PC9iPiB3b2x0ZXIuZWxkZXJpbmc8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUkU6IFtPQVVUSC1XR10gQWNjZXNzIFRva2VuIFJlc3BvbnNlIHdpdGhvdXQgZXhwaXJlc19p bjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGlzIGRvZXNu4oCZdCB3b3JrIGZv ciBtZSwgYXMgaXQgZG9lc27igJl0IG1lc2ggd2VsbCB3aXRoIHRoZSBjYXNlIG9mIHRoZSB0b2tl biBjb250YWluaW5nIHRoZSBleHBpcmF0aW9uIHRpbWUuJm5ic3A7IEZvciBpbnN0YW5jZSwgYm90 aCBTQU1MIGFuZCBKV1QgdG9rZW5zIGNhbiBjb250YWluDQogZXhwaXJhdGlvbiB0aW1lcy4mbmJz cDsgSW4gdGhpcyBjYXNlLCB0aGUgZXhwaXJlc19pbiB0aW1lIGlzIHVubmVjZXNzYXJ5IGFuZCB0 aGUgdG9rZW4gbWF5IGhhdmUgbm8gZGVmYXVsdCBleHBpcmF0aW9uIHRpbWUgYW5kIHdpbGwgZXhw aXJlIGV2ZW4gdGhvdWdoIG5vdCBleHBsaWNpdGx5IGludm9rZWQuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHdvdWxk IHJlY29tbWVuZCBubyBjaGFuZ2UgdG8gdGhlIGN1cnJlbnQgdGV4dCwgd2hpY2ggaXM6PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWst YmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgZXhwaXJlc19p bjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJwYWdl LWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9QVElPTkFMLiZuYnNwOyBUaGUgbGlm ZXRpbWUgaW4gc2Vjb25kcyBvZiB0aGUgYWNjZXNzIHRva2VuLiZuYnNwOyBGb3I8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZv cmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBleGFtcGxlLCB0aGUgdmFsdWUgJnF1b3Q7MzYwMCZxdW90 OyBkZW5vdGVzIHRoYXQgdGhlIGFjY2VzcyB0b2tlbiB3aWxsPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+ PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgZXhwaXJlIGluIG9uZSBob3VyIGZyb20gdGhlIHRpbWUgdGhlIHJlc3BvbnNl IHdhcyBnZW5lcmF0ZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+DQo8YSBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyI+b2F1dGgt Ym91bmNlc0BpZXRmLm9yZzwvYT4gPGEgaHJlZj0ibWFpbHRvOlttYWlsdG86b2F1dGgtYm91bmNl c0BpZXRmLm9yZ10iPg0KW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXTwvYT4gPGI+T24g QmVoYWxmIE9mIDwvYj5FcmFuIEhhbW1lcjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEphbnVh cnkgMTYsIDIwMTIgMTE6MjAgUE08YnI+DQo8Yj5Ubzo8L2I+IEFhcm9uIFBhcmVja2k7IE9BdXRo IFdHPGJyPg0KPGI+Q2M6PC9iPiB3b2x0ZXIuZWxkZXJpbmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4g UmU6IFtPQVVUSC1XR10gQWNjZXNzIFRva2VuIFJlc3BvbnNlIHdpdGhvdXQgZXhwaXJlc19pbjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5XRk0uPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0 LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEFhcm9uIFBhcmVja2kNCjxhIGhyZWY9Im1haWx0bzpb bWFpbHRvOmFhcm9uQHBhcmVja2kuY29tXSI+W21haWx0bzphYXJvbkBwYXJlY2tpLmNvbV08L2E+ IDxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEphbnVhcnkgMTYsIDIwMTIgMTE6MDggUE08YnI+ DQo8Yj5Ubzo8L2I+IE9BdXRoIFdHPGJyPg0KPGI+Q2M6PC9iPiBFcmFuIEhhbW1lcjsgUmljaGVy LCBKdXN0aW4gUC47IHdvbHRlci5lbGRlcmluZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09B VVRILVdHXSBBY2Nlc3MgVG9rZW4gUmVzcG9uc2Ugd2l0aG91dCBleHBpcmVzX2luPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+QWN0dWFsbHkgbm93IEknbSBoYXZpbmcgc2Vjb25kIHRob3VnaHRzIGFib3V0IG1ha2lu ZyBleHBpcmVzX2luIFJFQ09NTUVOREVELiBIZXJlJ3MgYW5vdGhlciBhdHRlbXB0IGF0IGEgY2xh cmlmaWNhdGlvbjo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+ZXhwaXJlc19pbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO09QVElPTkFM LiAmbmJzcDtUaGUgbGlmZXRpbWUgaW4gc2Vjb25kcyBvZiB0aGUgYWNjZXNzIHRva2VuLiAmbmJz cDtGb3I8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtleGFtcGxlLCB0aGUgdmFsdWUgJnF1 b3Q7MzYwMCZxdW90OyBkZW5vdGVzIHRoYXQgdGhlIGFjY2VzcyB0b2tlbiB3aWxsPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZXhwaXJlIGluIG9uZSBob3VyIGZyb20gdGhlIHRpbWUgdGhl IHJlc3BvbnNlIHdhcyBnZW5lcmF0ZWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDs8Yj5JZiBvbWl0dGVkLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgU0hPVUxEIGRvY3Vt ZW50IHRoZTwvYj48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtkZWZhdWx0IGV4cGly YXRpb24gdGltZSBvciBpbmRpY2F0ZSB0aGF0IHRoZSB0b2tlbiB3aWxsIG5vdDwvc3Bhbj48L2I+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtleHBpcmUgdW50aWwgZXhwbGljaXRseSByZXZva2Vk Ljwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPi1hYXJvbnBrPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBKYW4gMTYsIDIwMTIgYXQgMTA6 MzcgUE0sIEVyYW4gSGFtbWVyICZsdDs8YSBocmVmPSJtYWlsdG86ZXJhbkBodWVuaXZlcnNlLmNv bSI+ZXJhbkBodWVuaXZlcnNlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5IbW0uIFRoaXMgbWlnaHQgYmVjb21lIHRvbyBtdWNoIHdvcmsg YXQgdGhpcyBzdGFnZeKApjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhhcHB5IGZvciBzdWdnZXN0aW9ucyBidXQg SSB3b27igJl0IHB1cnN1ZSBpdCBvbiBteSBvd24gZm9yIG5vdy48L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5FSEw8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEFhcm9uIFBh cmVja2kgW21haWx0bzo8YSBocmVmPSJtYWlsdG86YWFyb25AcGFyZWNraS5jb20iIHRhcmdldD0i X2JsYW5rIj5hYXJvbkBwYXJlY2tpLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5 LCBKYW51YXJ5IDE2LCAyMDEyIDEwOjM2IFBNPGJyPg0KPGI+VG86PC9iPiBPQXV0aCBXRzxicj4N CjxiPkNjOjwvYj4gUmljaGVyLCBKdXN0aW4gUC47IHdvbHRlci5lbGRlcmluZzsgRXJhbiBIYW1t ZXI8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBBY2Nlc3MgVG9rZW4gUmVz cG9uc2Ugd2l0aG91dCBleHBpcmVzX2luPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhhdCBzZWVtcyBsaWtl IGEgZ29vZCBpZGVhLCBidXQgdGhlbiBpdCBzaG91bGQgYWxzbyBiZSBleHBsaWNpdGx5IHN0YXRl ZCB3aGF0IHRvIGRvIGlmIHRoZSBzZXJ2ZXIgaXNzdWVzIG5vbi1leHBpcmluZyB0b2tlbnMuPG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+YWFyb25wazxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBNb24sIEphbiAxNiwgMjAxMiBh dCAxMDoyOSBQTSwgRXJhbiBIYW1tZXIgJmx0OzxhIGhyZWY9Im1haWx0bzplcmFuQGh1ZW5pdmVy c2UuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZXJhbkBodWVuaXZlcnNlLmNvbTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Ib3cgZG8geW91IGZlZWwg YWJvdXQgY2hhbmdpbmcgZXhwaXJlc19pbiBmcm9tIE9QVElPTkFMIHRvIFJFQ09NTUVOREVEPzxi cj4NCjxicj4NCkVITDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxicj4NCiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7 IEZyb206IFJpY2hlciwgSnVzdGluIFAuIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJA bWl0cmUub3JnIiB0YXJnZXQ9Il9ibGFuayI+anJpY2hlckBtaXRyZS5vcmc8L2E+XTxicj4NCiZn dDsgU2VudDogTW9uZGF5LCBKYW51YXJ5IDE2LCAyMDEyIDc6MjkgUE08YnI+DQomZ3Q7IFRvOiBF cmFuIEhhbW1lcjxicj4NCiZndDsgQ2M6IE9BdXRoIFdHOyB3b2x0ZXIuZWxkZXJpbmc8YnI+DQom Z3Q7IFN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIEFjY2VzcyBUb2tlbiBSZXNwb25zZSB3aXRob3V0 IGV4cGlyZXNfaW48YnI+DQomZ3Q7PGJyPg0KJmd0OyBJIHRoaW5rICMzLjxicj4NCiZndDs8YnI+ DQomZ3Q7ICMxIHdpbGwgYmUgYSBjb21tb24gaW5zdGFuY2UsIGFuZCAjMiAob3IgaXRzIHZhcmlh bnQsIGEgbGltaXRlZCBudW1iZXIgb2Y8YnI+DQomZ3Q7IHVzZXMpIGlzIGEgZGlmZmVyZW50IGV4 cGlyYXRpb24gcGF0dGVybiB0aGFuIHRpbWUgdGhhdCB3b3VsZCB3YW50IHRvIGhhdmUgaXRzPGJy Pg0KJmd0OyBvd24gZXhwaXJhdGlvbiBwYXJhbWV0ZXIgbmFtZS4gSSBoYXZlbid0IHNlZW4gZW5v dWdoIGNvbmNyZXRlIHVzZSBvZiB0aGlzPGJyPg0KJmd0OyBwYXR0ZXJuIHRvIHdhcnJhbnQgaXRz IG93biBleHRlbnNpb24gdGhvdWdoLjxicj4NCiZndDs8YnI+DQomZ3Q7IFdoaWNoIGlzIHdoeSBJ IHZvdGUgIzMgLSBpdCdzIGEgY29uZmlndXJhdGlvbiBpc3N1ZS4gUGVyaGFwcyB3ZSBzaG91bGQg cmF0aGVyPGJyPg0KJmd0OyBzYXkgdGhhdCB0aGUgQVMgJnF1b3Q7U0hPVUxEIGRvY3VtZW50IHRo ZSB0b2tlbiBiZWhhdmlvciBpbiB0aGUgYWJzZW5jZSBvZiB0aGlzPGJyPg0KJmd0OyBwYXJhbWV0 ZXIsIHdoaWNoIG1heSBpbmNsdWRlIHRoZSB0b2tlbiBub3QgZXhwaXJpbmcgdW50aWwgZXhwbGlj aXRseSByZXZva2VkLDxicj4NCiZndDsgZXhwaXJpbmcgYWZ0ZXIgYSBzZXQgbnVtYmVyIG9mIHVz ZXMsIG9yIG90aGVyIGV4cGlyYXRpb24gYmVoYXZpb3IuJnF1b3Q7IFRoYXQncyBhIGxvdDxicj4N CiZndDsgb2Ygd29yZHMgaGVyZSB0aG91Z2guPGJyPg0KJmd0Ozxicj4NCiZndDsgJm5ic3A7LS0g SnVzdGluPGJyPg0KJmd0Ozxicj4NCiZndDsgT24gSmFuIDE2LCAyMDEyLCBhdCAxOjUzIFBNLCBF cmFuIEhhbW1lciB3cm90ZTo8YnI+DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEEgcXVlc3Rpb24gY2Ft ZSB1cCBhYm91dCB0aGUgYWNjZXNzIHRva2VuIGV4cGlyYXRpb24gd2hlbiBleHBpcmVzX2luIGlz PGJyPg0KJmd0OyBub3QgaW5jbHVkZWQgaW4gdGhlIHJlc3BvbnNlLiBUaGlzIHNob3VsZCBwcm9i YWJseSBiZSBtYWRlIGNsZWFyZXIgaW4gdGhlPGJyPg0KJmd0OyBzcGVjLiBUaGUgdGhyZWUgb3B0 aW9ucyBhcmU6PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IDEuIERvZXMgbm90IGV4cGly ZSAoYnV0IGNhbiBiZSByZXZva2VkKSAyLiBTaW5nbGUgdXNlIHRva2VuIDMuPGJyPg0KJmd0OyAm Z3Q7IERlZmF1bHRzIHRvIHdoYXRldmVyIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBkZWNpZGVz IGFuZCB1bnRpbDxicj4NCiZndDsgJmd0OyByZXZva2VkPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7ICMzIGlzIHRoZSBhc3N1bWVkIGFuc3dlciBnaXZlbiB0aGUgV0cgaGlzdG9yeS4gSSds bCBub3RlIHRoYXQgaW4gdGhlIHNwZWMsPGJyPg0KJmd0OyBidXQgd2FudGVkIHRvIG1ha2Ugc3Vy ZSB0aGlzIGlzIHRoZSBleHBsaWNpdCBXRyBjb25zZW5zdXMuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7IEVITDxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0 OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZn dDsgJmd0OyBPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7ICZndDsgPGEgaHJlZj0ibWFpbHRv Ok9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0K Jmd0OyAmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v b2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL29hdXRoPC9hPjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFp bHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJy Pg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1 dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_4E1F6AAD24975D4BA5B1680429673943663584A1TK5EX14MBXC285r_-- From mark.mcgloin@ie.ibm.com Tue Jan 17 04:06:30 2012 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 6514A21F858B for ; Tue, 17 Jan 2012 04:06:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.328 X-Spam-Level: X-Spam-Status: No, score=-2.328 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 5Viia0qHyHb2 for ; Tue, 17 Jan 2012 04:06:26 -0800 (PST) Received: from e06smtp16.uk.ibm.com (e06smtp16.uk.ibm.com [195.75.94.112]) by ietfa.amsl.com (Postfix) with ESMTP id 84D2821F84D5 for ; Tue, 17 Jan 2012 04:06:23 -0800 (PST) Received: from /spool/local by e06smtp16.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 17 Jan 2012 12:06:21 -0000 Received: from d06nrmr1707.portsmouth.uk.ibm.com ([9.149.39.225]) by e06smtp16.uk.ibm.com ([192.168.101.146]) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 17 Jan 2012 12:06:19 -0000 Received: from d06av12.portsmouth.uk.ibm.com (d06av12.portsmouth.uk.ibm.com [9.149.37.247]) by d06nrmr1707.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q0HC6I9Q2666712 for ; Tue, 17 Jan 2012 12:06:18 GMT Received: from d06av12.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av12.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q0HC6I99018062 for ; Tue, 17 Jan 2012 05:06:18 -0700 Received: from d06ml091.portsmouth.uk.ibm.com (d06ml091.portsmouth.uk.ibm.com [9.149.104.170]) by d06av12.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q0HC6Hvt018047; Tue, 17 Jan 2012 05:06:18 -0700 In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E723453A754C534@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-KeepSent: 5C384B1A:F3404884-80257988:0041A466; type=4; name=$KeepSent To: =?ISO-8859-1?Q?Andr=E9_DeMarre?= X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 Message-ID: From: Mark Mcgloin Date: Tue, 17 Jan 2012 12:06:05 +0000 X-MIMETrack: Serialize by Router on D06ML091/06/M/IBM(Release 8.5.2FP1 ZX852FP1HF12|September 28, 2011) at 17/01/2012 12:06:13 MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable x-cbid: 12011712-3548-0000-0000-000000BB81E7 Cc: OAuth WG 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: Tue, 17 Jan 2012 12:06:30 -0000 Andre Please feel free to propose text, perhaps with a better title than I suggested. During our discussion on section 4.1.4 (End-user credentials= phished using compromised or embedded browser), we have decided on the= countermeasure below, albeit for a different threat - phishing client a= s opposed to client name spoofing. Your's can be a variant of this with different validation recommendations. 2. Client applications could be validated prior to publication in an application market for users to access. That validation is out of scope= for OAuth but could include validating that the client application handles = user authentication in an appropriate way Regards Mark Andr=E9 DeMarre wrote on 16/01/2012 23:20:02: > > To: > > Eran Hammer 16/01/2012 23:22 > > > Re: [OAUTH-WG] Phishing with Client Application Name Spoofing > > Eran, > > Yes; I think a section should be added to the security model doc. > > On 2011-12-16 Mark Mcgloin agreed and suggested we call it "Client > Registration of phishing clients": > http://www.ietf.org/mail-archive/web/oauth/current/msg08061.html > > I'm happy to propose the text; it might be one or two days though. > > Regards, > Andre DeMarre > > On Mon, Jan 16, 2012 at 10:30 AM, Eran Hammer wrote: > > Should this be added to the security model document? Is it already > addressed there? > > > > EHL > > > >> -----Original Message----- > >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Be= half > >> Of Andr=E9 DeMarre > >> Sent: Tuesday, October 04, 2011 11:33 AM > >> To: OAuth WG > >> Subject: [OAUTH-WG] Phishing with Client Application Name Spoofing= > >> > >> 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 servi= ce, let's > >> call it Foobar, and he names his client app "Google, Inc.". The Fo= obar > >> 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 Foob= ar 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 a= pp > >> developers can supply arbitrary, unconfirmed URIs which are shown = to the > >> resource owner as the app's website, even if the domain does not m= atch 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 administrator= s 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 owne= r > >> additional information about the client application to help them m= ake > >> informed decisions. For example, it could display all or part of t= he 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 au= th > >> 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 tempora= ry > >> credentials (aka access tokens) before sending resource owners to = the > >> authorization endpoint. Now with OAuth 2, this attack does not req= uire > >> 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 mig= ht use > >> anchor text such as "I used Google Plus to synchronize with my Foo= bar > >> 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 b= ar, and > >> perhaps checking TLS certificates, but such defenses are irreleven= t here. > >> Resource owners now need to verify not only that they are on the legitimate > >> authorization server, but to consider the trustworthyness of the l= ink that > >> referred them there. > >> > >> I'm not sure what can or should be done, but I think it's importan= t for > >> authorization server implementers to be aware of this attack. If > >> administrators are not able to authenticate client organizations,t= hen they > >> are shifting this burden to resource owners. They should do all th= ey can to > >> educate resource owners and help them make informed decisions befo= re > >> granting authorization. > >> > >> Regards, > >> Andre DeMarre > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth >= From ve7jtb@ve7jtb.com Tue Jan 17 04:47:52 2012 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 9470C21F8623 for ; Tue, 17 Jan 2012 04:47:52 -0800 (PST) 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=[AWL=-0.000, 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 LGpHCU4wF-U4 for ; Tue, 17 Jan 2012 04:47:51 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2912521F8574 for ; Tue, 17 Jan 2012 04:47:51 -0800 (PST) Received: by yenr11 with SMTP id r11so1861565yen.31 for ; Tue, 17 Jan 2012 04:47:49 -0800 (PST) Received: by 10.236.175.231 with SMTP id z67mr23768896yhl.23.1326804469635; Tue, 17 Jan 2012 04:47:49 -0800 (PST) Received: from [192.168.1.210] ([190.22.86.51]) by mx.google.com with ESMTPS id y58sm36286095yhi.17.2012.01.17.04.47.43 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 17 Jan 2012 04:47:48 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/signed; boundary="Apple-Mail=_9E0FAB29-62E3-42E5-9C40-7EAA51F05AEB"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943663584A1@TK5EX14MBXC285.redmond.corp.microsoft.com> Date: Tue, 17 Jan 2012 09:47:37 -0300 Message-Id: <0471E0F2-DB8F-4FE3-A636-53684CDA4E6C@ve7jtb.com> References: <90C41DD21FB7C64BB94121FBBC2E723453A754C549@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723453A754C5B1@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723453A754C5B3@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723453A754C5B6@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B168042967394366358386@TK5EX14MBXC285.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723453A754C5B7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B1680429673943663584A1@TK5EX14MBXC285.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1251.1) Cc: "wolter.eldering" , OAuth WG Subject: Re: [OAUTH-WG] Access Token Response without expires_in 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, 17 Jan 2012 12:47:52 -0000 --Apple-Mail=_9E0FAB29-62E3-42E5-9C40-7EAA51F05AEB Content-Type: multipart/alternative; boundary="Apple-Mail=_7C0523A8-6DE8-4E0E-BDA8-40AA8B86D6B0" --Apple-Mail=_7C0523A8-6DE8-4E0E-BDA8-40AA8B86D6B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I am OK with that. The expiration time in the token is intended for the protected resource. The client inspecting the token is a potential optimization in cases = where the JWT is not encrypted to the=20 protected resource. I think leaving it open to inspect the token or otherwise provide it in = configuration information is flexible enough. John B. On 2012-01-17, at 5:54 AM, Mike Jones wrote: > Your new wording is better, as it doesn=92t conflict with the = possibility of the expiration time being in the token. > =20 > -- Mike > =20 > From: Eran Hammer [mailto:eran@hueniverse.com]=20 > Sent: Tuesday, January 17, 2012 12:30 AM > To: Mike Jones; Aaron Parecki; OAuth WG > Cc: wolter.eldering > Subject: RE: [OAUTH-WG] Access Token Response without expires_in > =20 > This is clearly not a solution as actual implementation feedback = raised this issue. We have to document the meaning of this parameter = missing. Also, the example of a self-contained token does not conflict = with also providing this information via the parameter whenever possible = to improve interop. > =20 > I=92m going to go with adding: If omitted, the authorization server = SHOULD provide the expiration time via other means or document the = default value. > =20 > EHL > =20 > From: Mike Jones [mailto:Michael.Jones@microsoft.com]=20 > Sent: Tuesday, January 17, 2012 12:02 AM > To: Eran Hammer; Aaron Parecki; OAuth WG > Cc: wolter.eldering > Subject: RE: [OAUTH-WG] Access Token Response without expires_in > =20 > This doesn=92t work for me, as it doesn=92t mesh well with the case of = the token containing the expiration time. For instance, both SAML and = JWT tokens can contain expiration times. In this case, the expires_in = time is unnecessary and the token may have no default expiration time = and will expire even though not explicitly invoked. > =20 > I would recommend no change to the current text, which is: > expires_in > OPTIONAL. The lifetime in seconds of the access token. For > example, the value "3600" denotes that the access token will > expire in one hour from the time the response was generated. > =20 > -- Mike > =20 > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf = Of Eran Hammer > Sent: Monday, January 16, 2012 11:20 PM > To: Aaron Parecki; OAuth WG > Cc: wolter.eldering > Subject: Re: [OAUTH-WG] Access Token Response without expires_in > =20 > WFM. > =20 > From: Aaron Parecki [mailto:aaron@parecki.com]=20 > Sent: Monday, January 16, 2012 11:08 PM > To: OAuth WG > Cc: Eran Hammer; Richer, Justin P.; wolter.eldering > Subject: Re: [OAUTH-WG] Access Token Response without expires_in > =20 > Actually now I'm having second thoughts about making expires_in = RECOMMENDED. Here's another attempt at a clarification: > =20 > expires_in > OPTIONAL. The lifetime in seconds of the access token. For > example, the value "3600" denotes that the access token will > expire in one hour from the time the response was generated. > If omitted, the authorization server SHOULD document the > default expiration time or indicate that the token will not > expire until explicitly revoked. > =20 > -aaronpk > =20 >=20 > On Mon, Jan 16, 2012 at 10:37 PM, Eran Hammer = wrote: > Hmm. This might become too much work at this stage=85 > =20 > Happy for suggestions but I won=92t pursue it on my own for now. > =20 > EHL > =20 > From: Aaron Parecki [mailto:aaron@parecki.com]=20 > Sent: Monday, January 16, 2012 10:36 PM > To: OAuth WG > Cc: Richer, Justin P.; wolter.eldering; Eran Hammer >=20 > Subject: Re: [OAUTH-WG] Access Token Response without expires_in > =20 > That seems like a good idea, but then it should also be explicitly = stated what to do if the server issues non-expiring tokens. > =20 > aaronpk > =20 >=20 > On Mon, Jan 16, 2012 at 10:29 PM, Eran Hammer = wrote: > How do you feel about changing expires_in from OPTIONAL to = RECOMMENDED? >=20 > EHL >=20 > > -----Original Message----- > > From: Richer, Justin P. [mailto:jricher@mitre.org] > > Sent: Monday, January 16, 2012 7:29 PM > > To: Eran Hammer > > Cc: OAuth WG; wolter.eldering > > Subject: Re: [OAUTH-WG] Access Token Response without expires_in > > > > I think #3. > > > > #1 will be a common instance, and #2 (or its variant, a limited = number of > > uses) is a different expiration pattern than time that would want to = have its > > own expiration parameter name. I haven't seen enough concrete use of = this > > pattern to warrant its own extension though. > > > > Which is why I vote #3 - it's a configuration issue. Perhaps we = should rather > > say that the AS "SHOULD document the token behavior in the absence = of this > > parameter, which may include the token not expiring until explicitly = revoked, > > expiring after a set number of uses, or other expiration behavior." = That's a lot > > of words here though. > > > > -- Justin > > > > On Jan 16, 2012, at 1:53 PM, Eran Hammer wrote: > > > > > A question came up about the access token expiration when = expires_in is > > not included in the response. This should probably be made clearer = in the > > spec. The three options are: > > > > > > 1. Does not expire (but can be revoked) 2. Single use token 3. > > > Defaults to whatever the authorization server decides and until > > > revoked > > > > > > #3 is the assumed answer given the WG history. I'll note that in = the spec, > > but wanted to make sure this is the explicit WG consensus. > > > > > > EHL > > > > > > > > > _______________________________________________ > > > 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=_7C0523A8-6DE8-4E0E-BDA8-40AA8B86D6B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I am OK with that.

The = expiration time in the token is intended for the protected = resource.
The client inspecting the token is a potential = optimization in cases where the JWT is not encrypted to = the 
protected resource.

I think = leaving it open to inspect the token or otherwise provide it in = configuration information is flexible = enough.

John = B.


On 2012-01-17, at 5:54 AM, = Mike Jones wrote:

Your new wording is better, as it doesn=92t conflict = with the possibility of the expiration time being in the = token.
 
 
 Eran = Hammer [mailto:eran@hueniverse.com] 
Sent: Tuesday, January 17, 2012 = 12:30 AM
To: Mike Jones; Aaron Parecki; = OAuth WG
Cc: wolter.eldering
Subject= : RE: [OAUTH-WG] = Access Token Response without = expires_in
This is = clearly not a solution as actual implementation feedback raised this = issue. We have to document the meaning of this parameter missing. Also, = the example of a self-contained token does not conflict with also = providing this information via the parameter whenever possible to = improve interop.
 
I=92m going to go with adding: If = omitted, the authorization server SHOULD provide the expiration time via = other means or document the default value.
EHL
 
 oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Eran = Hammer
Sent: Monday, January 16, 2012 = 11:20 PM
To: Aaron Parecki; OAuth = WG
Cc: wolter.eldering
Subject= : Re: [OAUTH-WG] = Access Token Response without = expires_in
 
From: Aaron Parecki [mailto:aaron@parecki.com] 
Sent: Monday, January 16, 2012 = 11:08 PM
To: OAuth WG
Cc: Eran Hammer; Richer, Justin = P.; wolter.eldering
Subject: Re: [OAUTH-WG] Access Token = Response without expires_in
 
Actually now I'm having = second thoughts about making expires_in RECOMMENDED. Here's another = attempt at a clarification:
 
        =  OPTIONAL.  The lifetime in seconds of the access token. =  For
        =  example, the value "3600" denotes that the access token = will
        =  expire in one hour from the time the response was = generated.
    =      If omitted, the authorization server SHOULD = document the
  =        default expiration time or indicate that the = token will not
  =        expire until explicitly = revoked.
 

On Mon, Jan 16, 2012 = at 10:37 PM, Eran Hammer <Hmm. This might become too much = work at this stage=85
From: Aaron Parecki [mailto:aaron@parecki.com] 
Sent: Monday, January 16, 2012 = 10:36 PM
To: OAuth WG
Cc: Richer, Justin P.; = wolter.eldering; Eran Hammer

Subject: Re: [OAUTH-WG] Access Token = Response without = expires_in
 
That seems like a = good idea, but then it should also be explicitly stated what to do if = the server issues non-expiring tokens.
 
 


> -----Original Message-----
> From: Richer, = Justin P. [mailto:> parameter, which may = include the token not expiring until explicitly revoked,
> = expiring after a set number of uses, or other expiration behavior." = That's a lot
> of words here though.
>
>  -- = Justin
>
> On Jan 16, 2012, at 1:53 PM, Eran Hammer = wrote:
>
> > A question came up about the access token = expiration when expires_in is
> not included in the response. This = should probably be made clearer in the
> spec. The three options = are:
> >
> > 1. Does not expire (but can be revoked) = 2. Single use token 3.
> > Defaults to whatever the = authorization server decides and until
> > revoked
> = >
> > #3 is the assumed answer given the WG history. I'll = note that in the spec,
> but wanted to make sure this is the = explicit WG consensus.
> >
> > EHL
> = >
> >
> > = _______________________________________________
> > OAuth = mailing list
> > OAuth@ietf.org
> > OAuth@ietf.org
 
_______________________________= ________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth

= --Apple-Mail=_7C0523A8-6DE8-4E0E-BDA8-40AA8B86D6B0-- --Apple-Mail=_9E0FAB29-62E3-42E5-9C40-7EAA51F05AEB 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 DgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjAx MTcxMjQ3MzdaMCMGCSqGSIb3DQEJBDEWBBQsMFwNq03BJAoEFxMoyVgzwPVyJTCBpAYJKwYBBAGC NxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgZDMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzANBgkqhkiG9w0BAQEFAASC AQC2LgwvAjnPTTU0kPqDZoDc8ZHBrrtD91UEnnTXEm4aJPNyZgtTJeb88iCZowUnWjYYwBOYlrtA qzGMyFl+7hx55mT/Zd/DIz256ukEN8aI5/ebuPRenFU3z3F8SyyxYczbGNjDB6ml5iwbZZwRnY5Q 7gJYKR04x4gPFxlehPrEUXPJLf0rkBb4a6UoNV/uuS06ARF39l4px60B6jCPRi58jr0k8NiIR5xO luwkbCtSl4XdJgXpsZXY7Oy3DrKH7qLnE6GvH+7/p4Bh3NSkBVCpJZKv0jjMzw33My1ZI2PNyzVL GjghyZOvaDnHrHpNoDdpg2QHr+UblCD0WcW0qvCDAAAAAAAA --Apple-Mail=_9E0FAB29-62E3-42E5-9C40-7EAA51F05AEB-- From paul.madsen@gmail.com Tue Jan 17 05:23:44 2012 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 0D12521F85E4 for ; Tue, 17 Jan 2012 05:23:44 -0800 (PST) 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 1ZX-5JyxKLxM for ; Tue, 17 Jan 2012 05:23:43 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3301A21F85D5 for ; Tue, 17 Jan 2012 05:23:43 -0800 (PST) Received: by vcbfk26 with SMTP id fk26so1565255vcb.31 for ; Tue, 17 Jan 2012 05:23:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=YJ3Hmf6ETJS7nApbM/4ixPNzB/a47yeDxoNZkF39yn8=; b=fimfMEEveT5NZ4EdBkTtg52ISn28MQYSQCR3iKwjMG8CshYZWSoMSkg6xduvmx2trg rVB/eCt1CZer9iEC56qu0or3cT+PBqh0uUglkXNlAIPDdZPmXko+Cm8AIngDeLvXQ7ow 7nZzoPS27zLqo+Lv/FtOHo7zefUZhBtguFym4= Received: by 10.220.155.212 with SMTP id t20mr9936662vcw.8.1326806622724; Tue, 17 Jan 2012 05:23:42 -0800 (PST) Received: from pmadsen-mbp.local (CPE0022b0cb82b4-CM0012256eb4b4.cpe.net.cable.rogers.com. [72.136.168.159]) by mx.google.com with ESMTPS id u12sm18294555vde.4.2012.01.17.05.23.38 (version=SSLv3 cipher=OTHER); Tue, 17 Jan 2012 05:23:39 -0800 (PST) Message-ID: <4F157659.7050701@gmail.com> Date: Tue, 17 Jan 2012 08:23:37 -0500 From: Paul Madsen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "Richer, Justin P." References: <90C41DD21FB7C64BB94121FBBC2E723453A754C549@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050007080508060000070706" Cc: OAuth WG Subject: Re: [OAUTH-WG] Access Token Response without expires_in 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, 17 Jan 2012 13:23:44 -0000 This is a multi-part message in MIME format. --------------050007080508060000070706 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Separate from the question posed here, we are seeing customer demand for one-time semantics, but agree with Justin that this would best belong in a dedicated extension parameter and not the default paul On 1/16/12 10:29 PM, Richer, Justin P. wrote: > I think #3. > > #1 will be a common instance, and #2 (or its variant, a limited number of uses) is a different expiration pattern than time that would want to have its own expiration parameter name. I haven't seen enough concrete use of this pattern to warrant its own extension though. > > Which is why I vote #3 - it's a configuration issue. Perhaps we should rather say that the AS "SHOULD document the token behavior in the absence of this parameter, which may include the token not expiring until explicitly revoked, expiring after a set number of uses, or other expiration behavior." That's a lot of words here though. > > -- Justin > > On Jan 16, 2012, at 1:53 PM, Eran Hammer wrote: > >> A question came up about the access token expiration when expires_in is not included in the response. This should probably be made clearer in the spec. The three options are: >> >> 1. Does not expire (but can be revoked) >> 2. Single use token >> 3. Defaults to whatever the authorization server decides and until revoked >> >> #3 is the assumed answer given the WG history. I'll note that in the spec, but wanted to make sure this is the explicit WG consensus. >> >> EHL >> >> >> _______________________________________________ >> 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 --------------050007080508060000070706 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Separate from the question posed here, we are seeing customer demand for one-time semantics, but agree with Justin that this would best belong in a dedicated extension parameter and not the default

paul

On 1/16/12 10:29 PM, Richer, Justin P. wrote: 
I think #3.

#1 will be a common instance, and #2 (or its variant, a limited number of uses) is a different expiration pattern than time that would want to have its own expiration parameter name. I haven't seen enough concrete use of this pattern to warrant its own extension though. 

Which is why I vote #3 - it's a configuration issue. Perhaps we should rather say that the AS "SHOULD document the token behavior in the absence of this parameter, which may include the token not expiring until explicitly revoked, expiring after a set number of uses, or other expiration behavior." That's a lot of words here though.

 -- Justin

On Jan 16, 2012, at 1:53 PM, Eran Hammer wrote:


A question came up about the access token expiration when expires_in is not included in the response. This should probably be made clearer in the spec. The three options are:

1. Does not expire (but can be revoked)
2. Single use token
3. Defaults to whatever the authorization server decides and until revoked

#3 is the assumed answer given the WG history. I'll note that in the spec, but wanted to make sure this is the explicit WG consensus.

EHL


_______________________________________________
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
--------------050007080508060000070706-- From jricher@mitre.org Tue Jan 17 06:22:30 2012 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 824C121F84C2 for ; Tue, 17 Jan 2012 06:22:30 -0800 (PST) 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 vNAA-iSPZFrm for ; Tue, 17 Jan 2012 06:22:29 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id E28E721F84CF for ; Tue, 17 Jan 2012 06:22:28 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id CC97021B165F; Tue, 17 Jan 2012 09:22:27 -0500 (EST) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id BA90621B1033; Tue, 17 Jan 2012 09:22:27 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.158]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.01.0339.001; Tue, 17 Jan 2012 09:22:27 -0500 From: "Richer, Justin P." To: John Bradley , Mike Jones Thread-Topic: [OAUTH-WG] Access Token Response without expires_in Thread-Index: AczUf8kvUkdgy1nHSGOm5KixWQExDAAclWSAAAQyJIAAAlXrAAAAC58AAAELx4AAAG05AAABdGKAAAD+9QAAANj2AAAIJbeA///ESZE= Date: Tue, 17 Jan 2012 14:22:27 +0000 Message-ID: References: <90C41DD21FB7C64BB94121FBBC2E723453A754C549@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723453A754C5B1@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723453A754C5B3@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723453A754C5B6@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B168042967394366358386@TK5EX14MBXC285.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723453A754C5B7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B1680429673943663584A1@TK5EX14MBXC285.redmond.corp.microsoft.com>, <0471E0F2-DB8F-4FE3-A636-53684CDA4E6C@ve7jtb.com> In-Reply-To: <0471E0F2-DB8F-4FE3-A636-53684CDA4E6C@ve7jtb.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.52] Content-Type: multipart/alternative; boundary="_000_B33BFB58CCC8BE4998958016839DE27E09EA57IMCMBX01MITREORG_" MIME-Version: 1.0 Cc: "wolter.eldering" , OAuth WG Subject: Re: [OAUTH-WG] Access Token Response without expires_in 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, 17 Jan 2012 14:22:30 -0000 --_000_B33BFB58CCC8BE4998958016839DE27E09EA57IMCMBX01MITREORG_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Information inside the token is outside of OAuth completely, so I like Eran= 's suggestion that doesn't mention how this information would be communicat= ed. However, I would like to leave it open for different expiration semanti= cs beyond expiration time. I suggest the following text (which could probab= ly use some wordsmithing): expires_in OPTIONAL. The lifetime in seconds of the access token. For example, the value "3600" denotes that the access token will expire in one hour from the time the response was generated. If omitted, the authorization server SHOULD provide the token = expiration behavior via other means or documentation. ________________________________ From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] on behalf of John Bra= dley [ve7jtb@ve7jtb.com] Sent: Tuesday, January 17, 2012 7:47 AM To: Mike Jones Cc: wolter.eldering; OAuth WG Subject: Re: [OAUTH-WG] Access Token Response without expires_in I am OK with that. The expiration time in the token is intended for the protected resource. The client inspecting the token is a potential optimization in cases where = the JWT is not encrypted to the protected resource. I think leaving it open to inspect the token or otherwise provide it in con= figuration information is flexible enough. John B. On 2012-01-17, at 5:54 AM, Mike Jones wrote: Your new wording is better, as it doesn=92t conflict with the possibility o= f the expiration time being in the token. -- Mike From: Eran Hammer [mailto:eran@hueniverse.com] Sent: Tuesday, January 17, 2012 12:30 AM To: Mike Jones; Aaron Parecki; OAuth WG Cc: wolter.eldering Subject: RE: [OAUTH-WG] Access Token Response without expires_in This is clearly not a solution as actual implementation feedback raised thi= s issue. We have to document the meaning of this parameter missing. Also, t= he example of a self-contained token does not conflict with also providing = this information via the parameter whenever possible to improve interop. I=92m going to go with adding: If omitted, the authorization server SHOULD = provide the expiration time via other means or document the default value. EHL From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Tuesday, January 17, 2012 12:02 AM To: Eran Hammer; Aaron Parecki; OAuth WG Cc: wolter.eldering Subject: RE: [OAUTH-WG] Access Token Response without expires_in This doesn=92t work for me, as it doesn=92t mesh well with the case of the = token containing the expiration time. For instance, both SAML and JWT toke= ns can contain expiration times. In this case, the expires_in time is unne= cessary and the token may have no default expiration time and will expire e= ven though not explicitly invoked. I would recommend no change to the current text, which is: expires_in OPTIONAL. The lifetime in seconds of the access token. For example, the value "3600" denotes that the access token will expire in one hour from the time the response was generated. -- Mike From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Eran = Hammer Sent: Monday, January 16, 2012 11:20 PM To: Aaron Parecki; OAuth WG Cc: wolter.eldering Subject: Re: [OAUTH-WG] Access Token Response without expires_in WFM. From: Aaron Parecki [mailto:aaron@parecki.com] Sent: Monday, January 16, 2012 11:08 PM To: OAuth WG Cc: Eran Hammer; Richer, Justin P.; wolter.eldering Subject: Re: [OAUTH-WG] Access Token Response without expires_in Actually now I'm having second thoughts about making expires_in RECOMMENDED= . Here's another attempt at a clarification: expires_in OPTIONAL. The lifetime in seconds of the access token. For example, the value "3600" denotes that the access token will expire in one hour from the time the response was generated. If omitted, the authorization server SHOULD document the default expiration time or indicate that the token will not expire until explicitly revoked. -aaronpk On Mon, Jan 16, 2012 at 10:37 PM, Eran Hammer > wrote: Hmm. This might become too much work at this stage=85 Happy for suggestions but I won=92t pursue it on my own for now. EHL From: Aaron Parecki [mailto:aaron@parecki.com] Sent: Monday, January 16, 2012 10:36 PM To: OAuth WG Cc: Richer, Justin P.; wolter.eldering; Eran Hammer Subject: Re: [OAUTH-WG] Access Token Response without expires_in That seems like a good idea, but then it should also be explicitly stated w= hat to do if the server issues non-expiring tokens. aaronpk On Mon, Jan 16, 2012 at 10:29 PM, Eran Hammer > wrote: How do you feel about changing expires_in from OPTIONAL to RECOMMENDED? EHL > -----Original Message----- > From: Richer, Justin P. [mailto:jricher@mitre.org] > Sent: Monday, January 16, 2012 7:29 PM > To: Eran Hammer > Cc: OAuth WG; wolter.eldering > Subject: Re: [OAUTH-WG] Access Token Response without expires_in > > I think #3. > > #1 will be a common instance, and #2 (or its variant, a limited number of > uses) is a different expiration pattern than time that would want to have= its > own expiration parameter name. I haven't seen enough concrete use of this > pattern to warrant its own extension though. > > Which is why I vote #3 - it's a configuration issue. Perhaps we should ra= ther > say that the AS "SHOULD document the token behavior in the absence of thi= s > parameter, which may include the token not expiring until explicitly revo= ked, > expiring after a set number of uses, or other expiration behavior." That'= s a lot > of words here though. > > -- Justin > > On Jan 16, 2012, at 1:53 PM, Eran Hammer wrote: > > > A question came up about the access token expiration when expires_in is > not included in the response. This should probably be made clearer in the > spec. The three options are: > > > > 1. Does not expire (but can be revoked) 2. Single use token 3. > > Defaults to whatever the authorization server decides and until > > revoked > > > > #3 is the assumed answer given the WG history. I'll note that in the sp= ec, > but wanted to make sure this is the explicit WG consensus. > > > > EHL > > > > > > _______________________________________________ > > 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_B33BFB58CCC8BE4998958016839DE27E09EA57IMCMBX01MITREORG_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Information inside the token is outside of OAuth completely, so I li= ke Eran's suggestion that doesn't mention how this information would be com= municated. However, I would like to leave it open for different expiration semantics beyond expiration time. I= suggest the following text (which could probably use some wordsmithing):

If

          &n= bsp;     omitted, the authorization server SHOULD provide the token expiration behav= ior

          &n= bsp;     via other means or documentation.


From: oauth-bounces@ietf.org [oauth-bounc= es@ietf.org] on behalf of John Bradley [ve7jtb@ve7jtb.com]
Sent: Tuesday, January 17, 2012 7:47 AM
To: Mike Jones
Cc: wolter.eldering; OAuth WG
Subject: Re: [OAUTH-WG] Access Token Response without expires_in

I am OK with that.

The expiration time in the token is intended for the protected resourc= e.
The client inspecting the token is a potential optimization in cases w= here the JWT is not encrypted to the 
protected resource.

I think leaving it open to inspect the token or otherwise provide it i= n configuration information is flexible enough.

John B.


On 2012-01-17, at 5:54 AM, Mike Jones wrote:

Your new wording is better, as it doesn=92t conflict with t= he possibility of the expiration time being in the token.
 
          = ;            &n= bsp;            = ;            &n= bsp;            -- M= ike
 
From:<= span class=3D"Apple-converted-space"> Eran Hammer [mailto:eran@= hueniverse.com] 
Sent: Tuesday, Jan= uary 17, 2012 12:30 AM
To: Mike Jones; Aa= ron Parecki; OAuth WG
Cc: wolter.elderin= g
Subject: RE: [OAUT= H-WG] Access Token Response without expires_in
 
This is clearly not a solution as actual implementation fee= dback raised this issue. We have to document the meaning of this parameter = missing. Also, the example of a self-contained token does not conflict with also providing this information via the param= eter whenever possible to improve interop.
 
I=92m going to go with adding: If omitted, the authorizatio= n server SHOULD provide the expiration time via other means or document the= default value.
 
EHL
 
From:<= span class=3D"Apple-converted-space"> Mike Jones [mailto:Michael.Jones@microsoft.com] 
Sent: Tuesday, Jan= uary 17, 2012 12:02 AM
To: Eran Hammer; A= aron Parecki; OAuth WG
Cc: wolter.elderin= g
Subject: RE: [OAUT= H-WG] Access Token Response without expires_in
 
This doesn=92t work for me, as it doesn=92t mesh well with = the case of the token containing the expiration time.  For instance, b= oth SAML and JWT tokens can contain expiration times.  In this case, the expires_in time is unnecessary and the toke= n may have no default expiration time and will expire even though not expli= citly invoked.
 
I would recommend no change to the current text, which is:<= /span>
&n= bsp;  expires_in
&n= bsp;        OPTIONAL.  The lifetime= in seconds of the access token.  For
&n= bsp;        example, the value "360= 0" denotes that the access token will
&n= bsp;        expire in one hour from the = time the response was generated.
 
          = ;            &n= bsp;            = ;            &n= bsp;            -- M= ike
 
From:<= span class=3D"Apple-converted-space"> oauth-bounces@ietf.org [mailto:oauth-bo= unces@ietf.org] On Behalf Of Eran Hamme= r
Sent: Monday, Janu= ary 16, 2012 11:20 PM
To: Aaron Parecki;= OAuth WG
Cc: wolter.elderin= g
Subject: Re: [OAUT= H-WG] Access Token Response without expires_in
 
WFM.
 
From:<= span class=3D"Apple-converted-space"> Aaron Parecki [mailto:aaron@parecki.com]&n= bsp;
Sent: Monday, Janu= ary 16, 2012 11:08 PM
To: OAuth WG
Cc: Eran Hammer; R= icher, Justin P.; wolter.eldering
Subject: Re: [OAUT= H-WG] Access Token Response without expires_in
 
Actually now I'm having seco= nd thoughts about making expires_in RECOMMENDED. Here's another attempt at = a clarification:
 
expires_in
        &nb= sp;OPTIONAL.  The lifetime in seconds of the access token.  For
        &nb= sp;example, the value "3600" denotes that the access token will
        &nb= sp;expire in one hour from the time the response was generated.
        &nb= sp;If omitted, the authorization server SHOULD document the
        =  default expiration time or indicate that the token will not
        =  expire until explicitly revoked.
 
-aaronpk

 

On Mon, Jan 16, 2012 at 10:37 PM, Eran Hammer <eran@hueniverse.com> wrote:
Hmm. This might become too much work at this stage=85
 
Happy for suggestions but I won=92t pursue it on my own for= now.
 
EHL
 
From:<= span class=3D"Apple-converted-space"> Aaron Parecki [mailto:aaron@parecki.com] 
Sent: Monday, Janu= ary 16, 2012 10:36 PM
To: OAuth WG
Cc: Richer, Justin= P.; wolter.eldering; Eran Hammer

Subject: Re: [OAUT= H-WG] Access Token Response without expires_in
 
That seems like a good idea, but then it should also be explicitly stated w= hat to do if the server issues non-expiring tokens.
 
aaronpk

 

On Mon, Jan 16, 2012 at 10:29 PM, Eran Hammer <eran@hueniverse.com> wrote:
How do you feel about changing expires_in from OPTIONAL to RECOMMENDED?

EHL

> -----Original Message-----
> From: Richer, Justin P. [mailto:jricher= @mitre.org]
> Sent: Monday, January 16, 2012 7:29 PM
> To: Eran Hammer
> Cc: OAuth WG; wolter.eldering
> Subject: Re: [OAUTH-WG] Access Token Response without expires_in
>
> I think #3.
>
> #1 will be a common instance, and #2 (or its variant, a limited number= of
> uses) is a different expiration pattern than time that would want to h= ave its
> own expiration parameter name. I haven't seen enough concrete use of t= his
> pattern to warrant its own extension though.
>
> Which is why I vote #3 - it's a configuration issue. Perhaps we should= rather
> say that the AS "SHOULD document the token behavior in the absenc= e of this
> parameter, which may include the token not expiring until explicitly r= evoked,
> expiring after a set number of uses, or other expiration behavior.&quo= t; That's a lot
> of words here though.
>
>  -- Justin
>
> On Jan 16, 2012, at 1:53 PM, Eran Hammer wrote:
>
> > A question came up about the access token expiration when expires= _in is
> not included in the response. This should probably be made clearer in = the
> spec. The three options are:
> >
> > 1. Does not expire (but can be revoked) 2. Single use token 3. > > Defaults to whatever the authorization server decides and until > > revoked
> >
> > #3 is the assumed answer given the WG history. I'll note that in = the spec,
> but wanted to make sure this is the explicit WG consensus.
> >
> > EHL
> >
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oa= uth

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

--_000_B33BFB58CCC8BE4998958016839DE27E09EA57IMCMBX01MITREORG_-- From paul.madsen@gmail.com Tue Jan 17 08:48:30 2012 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 6EE0C21F86EB; Tue, 17 Jan 2012 08:48:30 -0800 (PST) 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 Mc7Zo4kzZQqn; Tue, 17 Jan 2012 08:48:29 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5F26921F86E1; Tue, 17 Jan 2012 08:48:29 -0800 (PST) Received: by lagv3 with SMTP id v3so2755575lag.31 for ; Tue, 17 Jan 2012 08:48:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=S8NsG2SwYd3TJ4ujM9I6Vf6kQi9K1NbZMGAOtLMPS4M=; b=aWLVfXUaLwkj3OuYr/ycIVIEkLVZQ0HRi2yu9quKcm7vcOHN3hgjNRthgGIPxLDhfx hmYMtJaA3xBK6DUX5j/wZiCUF4+mFjBbEJMKyJ3ZH16HfHqfZW+GVvFACONvbTsHmBfx lqor8ydI9d4CcrwZdjEHdRB5oTD0JkgpUOBKE= Received: by 10.112.25.99 with SMTP id b3mr3554823lbg.8.1326818907237; Tue, 17 Jan 2012 08:48:27 -0800 (PST) Received: from pmadsen-mbp.local (CPE0022b0cb82b4-CM0012256eb4b4.cpe.net.cable.rogers.com. [72.136.168.159]) by mx.google.com with ESMTPS id q1sm20751736lbf.15.2012.01.17.08.48.23 (version=SSLv3 cipher=OTHER); Tue, 17 Jan 2012 08:48:25 -0800 (PST) Message-ID: <4F15A655.4060404@gmail.com> Date: Tue, 17 Jan 2012 11:48:21 -0500 From: Paul Madsen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: torsten@lodderstedt.net References: <90C41DD21FB7C64BB94121FBBC2E723453A754C549@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4F157659.7050701@gmail.com> <1451834425-1326818330-cardhu_decombobulator_blackberry.rim.net-253428785-@b4.c11.bise7.blackberry> In-Reply-To: <1451834425-1326818330-cardhu_decombobulator_blackberry.rim.net-253428785-@b4.c11.bise7.blackberry> Content-Type: multipart/alternative; boundary="------------030606050504060102070709" Cc: OAuth WG , oauth-bounces@ietf.org Subject: Re: [OAUTH-WG] Access Token Response without expires_in 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, 17 Jan 2012 16:48:30 -0000 This is a multi-part message in MIME format. --------------030606050504060102070709 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Torsten, yes the use case in question is payment-based as well. Your suggestion for the client to infer one-time usage from a missing expires_in contradicts the general consensus of this thread does it not? paul On 1/17/12 11:38 AM, torsten@lodderstedt.net wrote: > Hi, > > isn't one-time semantics typically associated with certain requests on certain resources/resource types. I therefore would assume the client to know which tokens to use one-time only. The authz server should not return an expires_in paramter. We for example use one time access tokens for payment transactions. > > What would such an extension specify? > > regards, > Torsten. > Gesendet mit BlackBerry® Webmail von Telekom Deutschland > > -----Original Message----- > From: Paul Madsen > Sender: oauth-bounces@ietf.org > Date: Tue, 17 Jan 2012 08:23:37 > To: Richer, Justin P. > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Access Token Response without expires_in > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --------------030606050504060102070709 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi Torsten, yes the use case in question is payment-based as well.

Your suggestion for the client to infer one-time usage from a missing expires_in contradicts the general consensus of this thread does it not?

paul

On 1/17/12 11:38 AM, torsten@lodderstedt.net wrote: 
Hi,

isn't one-time semantics typically associated with certain requests on certain resources/resource types. I therefore would assume the client to know which tokens to use one-time only. The authz server should not return an expires_in paramter. We for example use one time access tokens for payment transactions.  

What would such an extension specify?

regards,
Torsten.
Gesendet mit BlackBerry® Webmail von Telekom Deutschland  

-----Original Message-----
From: Paul Madsen <paul.madsen@gmail.com>
Sender: oauth-bounces@ietf.org
Date: Tue, 17 Jan 2012 08:23:37 
To: Richer, Justin P.<jricher@mitre.org>
Cc: OAuth WG<oauth@ietf.org>
Subject: Re: [OAUTH-WG] Access Token Response without expires_in

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--------------030606050504060102070709-- From wmills@yahoo-inc.com Tue Jan 17 08:57:46 2012 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 5B48521F8699 for ; Tue, 17 Jan 2012 08:57:46 -0800 (PST) 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 ryMJytAlBlrQ for ; Tue, 17 Jan 2012 08:57:45 -0800 (PST) Received: from nm2-vm0.bullet.mail.sp2.yahoo.com (nm2-vm0.bullet.mail.sp2.yahoo.com [98.139.91.248]) by ietfa.amsl.com (Postfix) with SMTP id 36C5911E8081 for ; Tue, 17 Jan 2012 08:57:45 -0800 (PST) Received: from [98.139.91.66] by nm2.bullet.mail.sp2.yahoo.com with NNFMP; 17 Jan 2012 16:57:45 -0000 Received: from [98.139.91.12] by tm6.bullet.mail.sp2.yahoo.com with NNFMP; 17 Jan 2012 16:57:45 -0000 Received: from [127.0.0.1] by omp1012.mail.sp2.yahoo.com with NNFMP; 17 Jan 2012 16:57:45 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 127421.87354.bm@omp1012.mail.sp2.yahoo.com Received: (qmail 63558 invoked by uid 60001); 17 Jan 2012 16:57:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1326819464; bh=ajP7I8CFMhMwPwQCGaBprgSxL+ICE6KJe/cxvVeqLlg=; 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=NDUyyjN0FKkpxXQuP4qyHLacD5BDfY5dVDn+eyXbo3qF8RKT+xMFxlLYrJzbRA9WkOuplHBdeR3xfMa9OZIsiorPJSjMwr2+LVrbYjk6+lCBDiLAVaEYgPSsUxpltKice9rJ65T3ey+JsXE8ZnvLumkSayypt2yKFPD+d6cviVM= 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=aTYw+D2icYj/vNJn8rRWR1FtV1cdJDmPiU40/k0ZF14caWfsB7Y8bYnfLQERrs4PbUV42lnyRo66NUNbIoe/C6Rc9SfdAx0DZDs8yHg1cq4eAf7AV5kLFrdng764JZmsWz5KSl7WZlpQgAi1CHulhbN1W1ttVjRQ233uVboC9kI=; X-YMail-OSG: 7abCnFEVM1leoKrn8x5AFvRMq7gri_UV_7rSRZhCrQNKPFh m5zODl6de4sdWjlfx5waiSRigrE8ajrbd8jSFXQhQIeAdotejzw7zawpCY_e V89pWq3145rKMEgJhDmr91Lm4c5mZM8JMHzoKYdroZDVn4DWe6lxHB5e7OY8 HbenVynnNYxl.t52GGvaQa8NfMzdP8pw9DxjwW9L9aLpvyp2Ix8Jb2tVq9xj 8bsqgZLMO6Z2MYT310KGJ_0I9fC0dHC27cmoZGpC7JFS2iLouQI9yYYfIZC9 GSGUI5d3cVSfnRUcXKN5PKfBJp128lbtJgO7HCbkhI.cOcHVo0r8fsR.5kZv rTxIIPxA9MX7B93m7dhBDMaYIHXdRBlvsrTwAcCDN709HQ3rAhfFd5kTrZxz I7fxRlpTzyqc- Received: from [99.31.212.42] by web31801.mail.mud.yahoo.com via HTTP; Tue, 17 Jan 2012 08:57:43 PST X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.116.331537 References: <90C41DD21FB7C64BB94121FBBC2E723453A754C549@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723453A754C5B1@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723453A754C5B3@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723453A754C5B6@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B168042967394366358386@TK5EX14MBXC285.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723453A754C5B7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B1680429673943663584A1@TK5EX14MBXC285.redmond.corp.microsoft.com> Message-ID: <1326819463.63513.YahooMailNeo@web31801.mail.mud.yahoo.com> Date: Tue, 17 Jan 2012 08:57:43 -0800 (PST) From: William Mills To: Mike Jones , Eran Hammer , Aaron Parecki , OAuth WG In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943663584A1@TK5EX14MBXC285.redmond.corp.microsoft.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-368338466-1994465251-1326819463=:63513" Cc: "wolter.eldering" Subject: Re: [OAUTH-WG] Access Token Response without expires_in 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, 17 Jan 2012 16:57:46 -0000 ---368338466-1994465251-1326819463=:63513 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable "expires_in" is always a hint to the client about when it might expect to n= eed to renew the token.=C2=A0 It's never authoritative, so it never conflic= ts with an expiry time in the token or any other actual mechanism to expire= the token.=0A=0A=0A=0A________________________________=0A From: Mike Jones= =0ATo: Eran Hammer ; Aar= on Parecki ; OAuth WG =0ACc: wolter.eld= ering =0ASent: Tuesday, January 17, 2012= 12:54 AM=0ASubject: Re: [OAUTH-WG] Access Token Response without expires_i= n=0A =0A=0A =0AYour new wording is better, as it doesn=E2=80=99t conflict w= ith the possibility of the expiration time being in the token.=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=0AF= rom:Eran Hammer [mailto:eran@hueniverse.com] =0ASent: Tuesday, January 17, = 2012 12:30 AM=0ATo: Mike Jones; Aaron Parecki; OAuth WG=0ACc: wolter.elderi= ng=0ASubject: RE: [OAUTH-WG] Access Token Response without expires_in=0A=C2= =A0=0AThis is clearly not a solution as actual implementation feedback rais= ed this issue. We have to document the meaning of this parameter missing. A= lso, the example of a self-contained token does not conflict with also prov= iding this information via the parameter whenever possible to improve inter= op.=0A=C2=A0=0AI=E2=80=99m going to go with adding: If omitted, the authori= zation server SHOULD provide the expiration time via other means or documen= t the default value.=0A=C2=A0=0AEHL=0A=C2=A0=0AFrom:Mike Jones [mailto:Mich= ael.Jones@microsoft.com] =0ASent: Tuesday, January 17, 2012 12:02 AM=0ATo: = Eran Hammer; Aaron Parecki; OAuth WG=0ACc: wolter.eldering=0ASubject: RE: [= OAUTH-WG] Access Token Response without expires_in=0A=C2=A0=0AThis doesn=E2= =80=99t work for me, as it doesn=E2=80=99t mesh well with the case of the t= oken containing the expiration time.=C2=A0 For instance, both SAML and JWT = tokens can contain expiration times.=C2=A0 In this case, the expires_in tim= e is unnecessary and the token may have no default expiration time and will= expire even though not explicitly invoked.=0A=C2=A0=0AI would recommend no= change to the current text, which is:=0A=C2=A0=C2=A0 expires_in=0A=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 OPTIONAL.=C2=A0 The lifetime in = seconds of the access token.=C2=A0 For=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 example, the value "3600" denotes that the access token wil= l=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 expire in one hour fro= m the time the response was generated.=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=0AFrom:oauth-bounces@ietf.o= rg [mailto:oauth-bounces@ietf.org] On Behalf Of Eran Hammer=0ASent: Monday,= January 16, 2012 11:20 PM=0ATo: Aaron Parecki; OAuth WG=0ACc: wolter.elder= ing=0ASubject: Re: [OAUTH-WG] Access Token Response without expires_in=0A= =C2=A0=0AWFM.=0A=C2=A0=0AFrom:Aaron Parecki [mailto:aaron@parecki.com] =0AS= ent: Monday, January 16, 2012 11:08 PM=0ATo: OAuth WG=0ACc: Eran Hammer; Ri= cher, Justin P.; wolter.eldering=0ASubject: Re: [OAUTH-WG] Access Token Res= ponse without expires_in=0A=C2=A0=0AActually now I'm having second thoughts= about making expires_in RECOMMENDED. Here's another attempt at a clarifica= tion:=0A=C2=A0=0Aexpires_in=0A=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0OPTIONAL. = =C2=A0The lifetime in seconds of the access token. =C2=A0For=0A=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0example, the value "3600" denotes that the access t= oken will=0A=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0expire in one hour from the t= ime the response was generated.=0A=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0If omit= ted, the authorization server SHOULD document the=0A=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0default expiration time or indicate that the token will not=0A= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0expire until explicitly revoked.=0A=C2=A0= =0A-aaronpk=0A=C2=A0=0AOn Mon, Jan 16, 2012 at 10:37 PM, Eran Hammer wrote:=0AHmm. This might become too much work at this stage= =E2=80=A6=0A=C2=A0=0AHappy for suggestions but I won=E2=80=99t pursue it on= my own for now.=0A=C2=A0=0AEHL=0A=C2=A0=0AFrom:Aaron Parecki [mailto:aaron= @parecki.com] =0ASent: Monday, January 16, 2012 10:36 PM=0ATo: OAuth WG=0AC= c: Richer, Justin P.; wolter.eldering; Eran Hammer=0A=0ASubject: Re: [OAUTH= -WG] Access Token Response without expires_in=0A=C2=A0=0AThat seems like a = good idea, but then it should also be explicitly stated what to do if the s= erver issues non-expiring tokens.=0A=C2=A0=0Aaaronpk=0A=C2=A0=0AOn Mon, Jan= 16, 2012 at 10:29 PM, Eran Hammer wrote:=0AHow do yo= u feel about changing expires_in from OPTIONAL to RECOMMENDED?=0A=0AEHL=0A= =0A> -----Original Message-----=0A> From: Richer, Justin P. [mailto:jricher= @mitre.org]=0A> Sent: Monday, January 16, 2012 7:29 PM=0A> To: Eran Hammer= =0A> Cc: OAuth WG; wolter.eldering=0A> Subject: Re: [OAUTH-WG] Access Token= Response without expires_in=0A>=0A> I think #3.=0A>=0A> #1 will be a commo= n instance, and #2 (or its variant, a limited number of=0A> uses) is a diff= erent expiration pattern than time that would want to have its=0A> own expi= ration parameter name. I haven't seen enough concrete use of this=0A> patte= rn to warrant its own extension though.=0A>=0A> Which is why I vote #3 - it= 's a configuration issue. Perhaps we should rather=0A> say that the AS "SHO= ULD document the token behavior in the absence of this=0A> parameter, which= may include the token not expiring until explicitly revoked,=0A> expiring = after a set number of uses, or other expiration behavior." That's a lot=0A>= of words here though.=0A>=0A> =C2=A0-- Justin=0A>=0A> On Jan 16, 2012, at = 1:53 PM, Eran Hammer wrote:=0A>=0A> > A question came up about the access t= oken expiration when expires_in is=0A> not included in the response. This s= hould probably be made clearer in the=0A> spec. The three options are:=0A> = >=0A> > 1. Does not expire (but can be revoked) 2. Single use token 3.=0A> = > Defaults to whatever the authorization server decides and until=0A> > rev= oked=0A> >=0A> > #3 is the assumed answer given the WG history. I'll note t= hat in the spec,=0A> but wanted to make sure this is the explicit WG consen= sus.=0A> >=0A> > EHL=0A> >=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/mai= lman/listinfo/oauth=0A=C2=A0=0A=C2=A0=0A___________________________________= ____________=0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/m= ailman/listinfo/oauth ---368338466-1994465251-1326819463=:63513 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
"expires_in" is always a hint to the client about when it might expect to= need to renew the token.  It's never authoritative, so it never confl= icts with an expiry time in the token or any other actual mechanism to expi= re the token.

= From: Mike Jones <Micha= el.Jones@microsoft.com>
To: Eran Hammer <eran@hueniverse.com>; Aaron Parecki <aaron@p= arecki.com>; OAuth WG <oauth@ietf.org>
Cc: wolter.eldering <wolter.eldering@enovation.com.cn= >
Sent: Tuesday, J= anuary 17, 2012 12:54 AM
Subject:= Re: [OAUTH-WG] Access Token Response without expires_in

=0A
=0A=0A =0A =0A=0A=0A
=0A
=0A
Your new wording is better, as i= t doesn=E2=80=99t conflict with the possibility of the expiration time bein= g in the token.
=0A
 
=0A
&= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;         -- Mike
= =0A
 
=0A
=0A
=0A
From: Eran Hammer [mailto:eran@hueniverse.com]=0A<= br>=0ASent: Tuesday, January 17, 2012 12:30 AM
=0ATo: Mike= Jones; Aaron Parecki; OAuth WG
=0ACc: wolter.eldering
=0AS= ubject: RE: [OAUTH-WG] Access Token Response without expires_in<= /div> =0A
=0A
=0A
  =0A
This is clearly not a solution as actual implementation feedb= ack raised this issue. We have to document the meaning of this parameter mi= ssing. Also, the example=0A of a self-contained token does not conflict wit= h also providing this information via the parameter whenever possible to im= prove interop.
=0A
 
=0A
I= =E2=80=99m going to go with adding: If omitted, the authorization server SH= OULD provide the expiration time via other means or document the default va= lue.
=0A
 
=0A
EHL =0A
 
=0A
=0A
=0A
=0AFrom= : Mike Jones=0A[mailto:Michael.Jo= nes@microsoft.com]=0A
=0ASent: Tuesday, January 17, 2012 12:0= 2 AM
=0ATo: Eran Hammer; Aaron Parecki; OAuth WG
=0ACc:= wolter.eldering
=0ASubject: RE: [OAUTH-WG] Access Token Response= without expires_in
=0A
=0A
=0A
 
=0A
This doesn=E2=80=99t work for me, = as it doesn=E2=80=99t mesh well with the case of the token containing the e= xpiration time.  For instance, both SAML and JWT tokens can contain=0A= expiration times.  In this case, the expires_in time is unnecessary a= nd the token may have no default expiration time and will expire even thoug= h not explicitly invoked.
=0A
 
=0A=
I would recommend no change to the current text, which is:<= /div> =0A
   expires_in
=0A
         OPTIONAL.  = The lifetime in seconds of the access token.  For
=0A         example, the= value "3600" denotes that the access token will
=0A
         expire in one hour= from the time the response was generated.
=0A
 =
=0A
        &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp; -- Mike
=0A
 
=0A
=0A=0A
From:=0Aoauth-bounces@ietf.org =0A[mailto:oauth-bounces@ietf.o= rg] On Behalf Of Eran Hammer
=0ASent: Monday, January = 16, 2012 11:20 PM
=0ATo: Aaron Parecki; OAuth WG
=0ACc:= wolter.eldering
=0ASubject: Re: [OAUTH-WG] Access Token Response= without expires_in
=0A
=0A
=0A
 
=0A
WFM.
=0A
&nb= sp;
=0A
=0A
=0A
=0A
From: Aaron Parecki=0A[mailto:aaron@parecki.com]
=0ASent: Monda= y, January 16, 2012 11:08 PM
=0ATo: OAuth WG
=0ACc: Era= n Hammer; Richer, Justin P.; wolter.eldering
=0ASubject: Re: [OAU= TH-WG] Access Token Response without expires_in
=0A
=0A=0A
 
=0A
=0A
= =0A
Actually now I'm ha= ving second thoughts about making expires_in RECOMMENDED. Here's another at= tempt at a clarification:
=0A
=0A
=0A
 
=0A
=0A
=0A
expires_in
=0A
=0A
= =0A
     = ;    OPTIONAL.  The lifetime in seconds of the access token.=  For
=0A
=0A
=0A
         example, the value = "3600" denotes that the access token will
=0A
=0A
=0A=
      &= nbsp;  expire in one hour from the time the response was generated.
=0A
=0A
=0A
=0A
         If omitted, the auth= orization server SHOULD document the
=0A
=0A
=0A<= div class=3D"yiv92245379MsoNormal">     =    default expiration time or indicate that the token will not
=0A
=0A
=0A
=          expire until explicitly = revoked.
=0A
=0A
=0A
 
=0A
=0A
=0A
-aaronpk
=0A
=0A
 
=0A
=0A
On Mon, Jan 16, 2012 at 10:37 PM, Eran Hammer <eran@hueniverse.com> wrote:
=0A
=0A=0A
Hmm. This might become too much work at this stag= e=E2=80=A6
=0A
<= span style=3D"font-size:11.0pt;color:#1F497D;"> 
=0A
Happy for suggestions but I won=E2=80=99t pursue it on my ow= n for now.
=0A
<= span style=3D"font-size:11.0pt;color:#1F497D;"> 
=0A
EHL
=0A
 
= =0A
=0A
=0A
=0A
From: Aaron Parecki [mailto:aaron@parecki.com]=0A
=0ASent: Monday, January 16, 2012 10:3= 6 PM
=0ATo: OAuth WG
=0ACc: Richer, Justin P.; wolter.e= ldering; Eran Hammer
=0A
=0A
=0A

=0ASubject: Re: [OAUTH-WG] Access Token Response w= ithout expires_in
=0A
=0A
=0A
=0A
=0A
=0A=0A
 
=0A
That seems like a good idea, but the= n it should also be explicitly stated what to do if the server issues non-e= xpiring tokens.
=0A
=0A
 
=0A
=0A
=0A
aaronpk
=0A
=0A
 
=0A
=0A
On Mon, Jan 16, 2012 at 10:29 PM, Eran Hammer <= eran@hueniverse.com> wrote: =0A
How do you feel about= changing expires_in from OPTIONAL to RECOMMENDED?
=0A
=0AEHL
= =0A
=0A
=0A

=0A&g= t; -----Original Message-----
=0A> From: Richer, Justin P. [mailto:jricher@mitre.org]
=0A> Sent: Mon= day, January 16, 2012 7:29 PM
=0A> To: Eran Hammer
=0A> Cc: OAu= th WG; wolter.eldering
=0A> Subject: Re: [OAUTH-WG] Access Token Resp= onse without expires_in
=0A>
=0A> I think #3.
=0A>
=0A= > #1 will be a common instance, and #2 (or its variant, a limited number= of
=0A> uses) is a different expiration pattern than time that would= want to have its
=0A> own expiration parameter name. I haven't seen = enough concrete use of this
=0A> pattern to warrant its own extension= though.
=0A>
=0A> Which is why I vote #3 - it's a configuratio= n issue. Perhaps we should rather
=0A> say that the AS "SHOULD docume= nt the token behavior in the absence of this
=0A> parameter, which ma= y include the token not expiring until explicitly revoked,
=0A> expir= ing after a set number of uses, or other expiration behavior." That's a lot=
=0A> of words here though.
=0A>
=0A>  -- Justin
= =0A>
=0A> On Jan 16, 2012, at 1:53 PM, Eran Hammer wrote:
=0A&g= t;
=0A> > A question came up about the access token expiration whe= n expires_in is
=0A> not included in the response. This should probab= ly be made clearer in the
=0A> spec. The three options are:
=0A>= ; >
=0A> > 1. Does not expire (but can be revoked) 2. Single us= e token 3.
=0A> > Defaults to whatever the authorization server de= cides and until
=0A> > revoked
=0A> >
=0A> > #3 = is the assumed answer given the WG history. I'll note that in the spec,
= =0A> but wanted to make sure this is the explicit WG consensus.
=0A&g= t; >
=0A> > EHL
=0A> >
=0A> >
=0A> >= _______________________________________________
=0A> > OAuth mail= ing 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
=0A=0A
=0A
=0A
 =
=0A
=0A
=0A
=0A
=0A
=0A
=0A
=0A=0A
 
=0A
=0A
= =0A
=0A
=0A=0A

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


---368338466-1994465251-1326819463=:63513-- From wmills@yahoo-inc.com Tue Jan 17 09:00:28 2012 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 F32A05E8002 for ; Tue, 17 Jan 2012 09:00:27 -0800 (PST) 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 T4Px7Pqkt4hH for ; Tue, 17 Jan 2012 09:00:27 -0800 (PST) Received: from nm29-vm0.bullet.mail.ne1.yahoo.com (nm29-vm0.bullet.mail.ne1.yahoo.com [98.138.91.43]) by ietfa.amsl.com (Postfix) with SMTP id 26FF05E8001 for ; Tue, 17 Jan 2012 09:00:27 -0800 (PST) Received: from [98.138.90.53] by nm29.bullet.mail.ne1.yahoo.com with NNFMP; 17 Jan 2012 17:00:21 -0000 Received: from [98.138.89.164] by tm6.bullet.mail.ne1.yahoo.com with NNFMP; 17 Jan 2012 17:00:21 -0000 Received: from [127.0.0.1] by omp1020.mail.ne1.yahoo.com with NNFMP; 17 Jan 2012 17:00:21 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 656218.2249.bm@omp1020.mail.ne1.yahoo.com Received: (qmail 3232 invoked by uid 60001); 17 Jan 2012 17:00:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1326819621; bh=C62cGA1p53QwC0bSBR+8KOXcp01kRsviN0mUigZSuB8=; 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=P40brPAnAp8h/9jBn6EK+x1QFvgc603m3nIBR3AfELrlilxsapOITGvLr50Mj2A2ldMFzgIBb+voP+bGYvosa6jdkqm0jKw8QIveCQQYBn9jdC+r0y5AESNaHwpsWafoV2C2ld0TRKtqh55baarPpDew/7cr2cXMz57shFWn1f0= 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=I12AOlV6i5VnhrR3Ct2Yomw2IUI0nIkVhr2t45VEAxnFQHNXA8vWE20bYyuIY/xZMX6mccAUXagzbIfECl41FJTXVHMplCnIg7Myy/TY2+j8NEKSXe9IY9+0fhfCX2ZZa1FYhaJJZn2krFy50RG6vAj2kI8CiE4K1YLqjChubVA=; X-YMail-OSG: mVOZTYEVM1nEjcwjqno.WASrjeBSp90txi5_pU8gnyp3fjP f_K9B7XtVcSdaDtqRLBl0MNTgPpZeyx_yZv_HUL7fxuqHuFWfYaRTY2h5ajO uOkKQgTFsHkoXp.LD_C5j9w67z_C5nGlIKH4X0IrxLgcogoqkmPZRcZdaNri CO2tjb2aX2d_7lSCD3t9sG8r7UjesSmgGun5s0sQXrKMEfIDVpXe4AknOakN ZAgnsixYyJC1I7tr8nCQR0wFzHeqa_2nQ_aJgU3L93IrwsVaTqAWnQWWKN0T 2_1ehiMJXnrvaosEu3kG33aCBWxkXt6J5P4FWl_65Sdh8ZcKUGD5Va_V0bJS fKEKoHAWswRagBU0qDQoZw_C5SV_UAabHAFMgpEq.cf1c6fWsIpiXs41H0tS RherBgwb.NBJihA-- Received: from [99.31.212.42] by web31804.mail.mud.yahoo.com via HTTP; Tue, 17 Jan 2012 09:00:20 PST X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.116.331537 References: <90C41DD21FB7C64BB94121FBBC2E723453A754C549@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4F157659.7050701@gmail.com> Message-ID: <1326819620.50670.YahooMailNeo@web31804.mail.mud.yahoo.com> Date: Tue, 17 Jan 2012 09:00:20 -0800 (PST) From: William Mills To: Paul Madsen , "Richer, Justin P." In-Reply-To: <4F157659.7050701@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="835683298-925136788-1326819620=:50670" Cc: OAuth WG Subject: Re: [OAUTH-WG] Access Token Response without expires_in 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, 17 Jan 2012 17:00:28 -0000 --835683298-925136788-1326819620=:50670 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Does this require an extension?=A0 That seems something easy to overload on= scope.=0A=0A=0A=0A________________________________=0A From: Paul Madsen =0ATo: "Richer, Justin P." =0ACc: = OAuth WG =0ASent: Tuesday, January 17, 2012 5:23 AM=0ASubj= ect: Re: [OAUTH-WG] Access Token Response without expires_in=0A =0A=0ASepar= ate from the question posed here, we are seeing customer demand for one-tim= e semantics, but agree with Justin that this would best belong in a dedicat= ed extension parameter and not the default =0A=0Apaul=0A=0AOn 1/16/12 10:29= PM, Richer, Justin P. wrote: =0AI think #3. #1 will be a common instance, = and #2 (or its variant, a limited number of uses) is a different expiration= pattern than time that would want to have its own expiration parameter nam= e. I haven't seen enough concrete use of this pattern to warrant its own ex= tension though. Which is why I vote #3 - it's a configuration issue. Perha= ps we should rather say that the AS "SHOULD document the token behavior in = the absence of this parameter, which may include the token not expiring unt= il explicitly revoked, expiring after a set number of uses, or other expira= tion behavior." That's a lot of words here though. -- Justin On Jan 16, 201= 2, at 1:53 PM, Eran Hammer wrote: =0A>A question came up about the access t= oken expiration when expires_in is not included in the response. This shoul= d probably be made clearer in the spec. The three options are: 1. Does not = expire (but can be revoked)=0A2. Single use token=0A3. Defaults to whatever= the authorization server decides and until revoked #3 is the assumed answe= r given the WG history. I'll note that in the spec, but wanted to make sure= this is the explicit WG consensus. EHL ___________________________________= ____________=0AOAuth mailing list OAuth@ietf.org https://www.ietf.org/mailm= an/listinfo/oauth =0A>_______________________________________________=0AOAu= th mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth = =0A_______________________________________________=0AOAuth mailing list=0AO= Auth@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/oauth --835683298-925136788-1326819620=:50670 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable 
error
         REQUIRED.  A single error code from the following:
Which one is appropriate in case of server error? I cannot see a= ny that would suite...

Thanks in advance

Antonio
Does= this require an extension?  That seems something easy to overload on = scope.

From: Paul Madsen <paul.madsen@gmail.= com>
To: "Richer, J= ustin P." <jricher@mitre.org>
Cc: OAuth WG <oauth@ietf.org>
Sent: Tuesday, January 17, 2012 5:23 AM
Subject: Re: [OAUTH-WG] Acce= ss Token Response without expires_in

=0A
=0A = =0A=0A =0A =0A
=0A Separate from the que= stion posed here, we are=0A seeing customer demand for one-time semant= ics, but agree with=0A Justin that this would best belong in a dedicat= ed extension=0A parameter and not the default
=0A
=0A = paul
=0A
=0A On 1/16/12 10:29 PM, Richer, Justin P. w= rote:=0A
=0A 
I think #3.=0A=0A#1 wil=
l be a common instance, and #2 (or its variant, a limited number of uses) i=
s a different expiration pattern than time that would want to have its own =
expiration parameter name. I haven't seen enough concrete use of this patte=
rn to warrant its own extension though. =0A=0AWhich is why I vote #3 - it's=
 a configuration issue. Perhaps we should rather say that the AS "SHOULD do=
cument the token behavior in the absence of this parameter, which may inclu=
de the token not expiring until explicitly revoked, expiring after a set nu=
mber of uses, or other expiration behavior." That's a lot of words here tho=
ugh.=0A=0A -- Justin=0A=0AOn Jan 16, 2012, at 1:53 PM, Eran Hammer wrote:=
=0A=0A
=0A
=0A 
A question c=
ame up about the access token expiration when expires_in is not included in=
 the response. This should probably be made clearer in the spec. The three =
options are:=0A=0A1. Does not expire (but can be revoked)=0A2. Single use t=
oken=0A3. Defaults to whatever the authorization server decides and until r=
evoked=0A=0A#3 is the assumed answer given the WG history. I'll note that i=
n the spec, but wanted to make sure this is the explicit WG consensus.=0A=
=0AEHL=0A=0A=0A_______________________________________________=0AOAuth mail=
ing list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/oauth=0A
= =0A
=0A 
_______________________________________=
________=0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo=
/oauth=0A
=0A
=0A
=0A=0A

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


--835683298-925136788-1326819620=:50670-- From jricher@mitre.org Tue Jan 17 09:03:21 2012 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 1CFB621F870F for ; Tue, 17 Jan 2012 09:03:21 -0800 (PST) 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 esd4NXMdAEWL for ; Tue, 17 Jan 2012 09:03:20 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8691821F8606 for ; Tue, 17 Jan 2012 09:03:17 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id EB4F921B176C; Tue, 17 Jan 2012 12:03:16 -0500 (EST) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 8B4AC21B1760; Tue, 17 Jan 2012 12:03:16 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.158]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.01.0339.001; Tue, 17 Jan 2012 12:03:15 -0500 From: "Richer, Justin P." To: William Mills , Paul Madsen Thread-Topic: [OAUTH-WG] Access Token Response without expires_in Thread-Index: AczUf8kvUkdgy1nHSGOm5KixWQExDAAclWSAABTAkIAAB5GZAP//rNWx Date: Tue, 17 Jan 2012 17:03:15 +0000 Message-ID: References: <90C41DD21FB7C64BB94121FBBC2E723453A754C549@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4F157659.7050701@gmail.com>, <1326819620.50670.YahooMailNeo@web31804.mail.mud.yahoo.com> In-Reply-To: <1326819620.50670.YahooMailNeo@web31804.mail.mud.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.52] Content-Type: multipart/alternative; boundary="_000_B33BFB58CCC8BE4998958016839DE27E09EBE7IMCMBX01MITREORG_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Access Token Response without expires_in 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, 17 Jan 2012 17:03:21 -0000 --_000_B33BFB58CCC8BE4998958016839DE27E09EBE7IMCMBX01MITREORG_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It's a hint to the client so that well-behaved clients don't need to fail w= ith a limited use token to know that it's probably bad. It lets you throw i= t away and re-auth early. -- Justin ________________________________ From: William Mills [wmills@yahoo-inc.com] Sent: Tuesday, January 17, 2012 12:00 PM To: Paul Madsen; Richer, Justin P. Cc: OAuth WG Subject: Re: [OAUTH-WG] Access Token Response without expires_in Does this require an extension? That seems something easy to overload on s= cope. ________________________________ From: Paul Madsen To: "Richer, Justin P." Cc: OAuth WG Sent: Tuesday, January 17, 2012 5:23 AM Subject: Re: [OAUTH-WG] Access Token Response without expires_in Separate from the question posed here, we are seeing customer demand for on= e-time semantics, but agree with Justin that this would best belong in a de= dicated extension parameter and not the default paul On 1/16/12 10:29 PM, Richer, Justin P. wrote: I think #3. #1 will be a common instance, and #2 (or its variant, a limited number of u= ses) is a different expiration pattern than time that would want to have it= s own expiration parameter name. I haven't seen enough concrete use of this= pattern to warrant its own extension though. Which is why I vote #3 - it's a configuration issue. Perhaps we should rath= er say that the AS "SHOULD document the token behavior in the absence of th= is parameter, which may include the token not expiring until explicitly rev= oked, expiring after a set number of uses, or other expiration behavior." T= hat's a lot of words here though. -- Justin On Jan 16, 2012, at 1:53 PM, Eran Hammer wrote: A question came up about the access token expiration when expires_in is not= included in the response. This should probably be made clearer in the spec= . The three options are: 1. Does not expire (but can be revoked) 2. Single use token 3. Defaults to whatever the authorization server decides and until revoked #3 is the assumed answer given the WG history. I'll note that in the spec, = but wanted to make sure this is the explicit WG consensus. EHL _______________________________________________ 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_B33BFB58CCC8BE4998958016839DE27E09EBE7IMCMBX01MITREORG_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
It's a hint to the client so that well-behaved clients don't need to= fail with a limited use token to know that it's probably bad. It lets you = throw it away and re-auth early.

 -- Justin

From: William Mills [wmills@yahoo-inc.com= ]
Sent: Tuesday, January 17, 2012 12:00 PM
To: Paul Madsen; Richer, Justin P.
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Access Token Response without expires_in

Does this require an extension?  That seems something easy to ove= rload on scope.

From: Paul Madsen <paul= .madsen@gmail.com>
To: "Richer, Justin P= ." <jricher@mitre.org>
Cc: OAuth WG <oauth@iet= f.org>
Sent: Tuesday, January 17,= 2012 5:23 AM
Subject: Re: [OAUTH-WG] Ac= cess Token Response without expires_in

Separate from the question posed here, we are see= ing customer demand for one-time semantics, but agree with Justin that this= would best belong in a dedicated extension parameter and not the default

paul

On 1/16/12 10:29 PM, Richer, Justin P. wrote: 
I think #3.=0A=
=0A=
#1 will be a common instance, and #2 (or its variant, a limited number of u=
ses) is a different expiration pattern than time that would want to have it=
s own expiration parameter name. I haven't seen enough concrete use of this=
 pattern to warrant its own extension though. =0A=
=0A=
Which is why I vote #3 - it's a configuration issue. Perhaps we should rath=
er say that the AS "SHOULD document the token behavior in the absence =
of this parameter, which may include the token not expiring until explicitl=
y revoked, expiring after a set number of uses, or other expiration behavio=
r." That's a lot of words here though.=0A=
=0A=
 -- Justin=0A=
=0A=
On Jan 16, 2012, at 1:53 PM, Eran Hammer wrote:=0A=
=0A=

A question came up about the access token expiration when expires_in i=
s not included in the response. This should probably be made clearer in the=
 spec. The three options are:=0A=
=0A=
1. Does not expire (but can be revoked)=0A=
2. Single use token=0A=
3. Defaults to whatever the authorization server decides and until revoked=
=0A=
=0A=
#3 is the assumed answer given the WG history. I'll note that in the spec, =
but wanted to make sure this is the explicit WG consensus.=0A=
=0A=
EHL=0A=
=0A=
=0A=
_______________________________________________=0A=
OAuth mailing list=0A=
OAuth@ietf.org=0A=
https://www.iet=
f.org/mailman/listinfo/oauth=0A=

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

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


--_000_B33BFB58CCC8BE4998958016839DE27E09EBE7IMCMBX01MITREORG_-- From torsten@lodderstedt.net Tue Jan 17 09:27:15 2012 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 F3ABD11E8075; Tue, 17 Jan 2012 09:27:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[AWL=0.075, 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 5vvgjObX7Ans; Tue, 17 Jan 2012 09:27:14 -0800 (PST) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.38]) by ietfa.amsl.com (Postfix) with ESMTP id 232A511E8072; Tue, 17 Jan 2012 09:27:13 -0800 (PST) Received: from [80.187.97.109] (helo=[10.198.254.251]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.68) (envelope-from ) id 1RnCoR-0001LU-Mg; Tue, 17 Jan 2012 18:27:12 +0100 References: <90C41DD21FB7C64BB94121FBBC2E723453A754C549@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4F157659.7050701@gmail.com> <1451834425-1326818330-cardhu_decombobulator_blackberry.rim.net-253428785-@b4.c11.bise7.blackberry> <4F15A655.4060404@gmail.com> User-Agent: K-9 Mail for Android In-Reply-To: <4F15A655.4060404@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----J9BMLS7DS5C14GN0QQCJ540HNT0I95" From: Torsten Lodderstedt Date: Tue, 17 Jan 2012 18:26:53 +0100 To: Paul Madsen Message-ID: <2fc6806a-8a15-4b97-87f2-3c0c0cbd3623@email.android.com> X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: OAuth WG , oauth-bounces@ietf.org Subject: Re: [OAUTH-WG] Access Token Response without expires_in 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, 17 Jan 2012 17:27:15 -0000 ------J9BMLS7DS5C14GN0QQCJ540HNT0I95 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Paul, that's not what I meant. The Client should know which tokens should be one time usage based on the API description. The authz server must not return expires_in because this would not make any sense in this case. regards, Torsten Paul Madsen schrieb: Hi Torsten, yes the use case in question is payment-based as well. Your suggestion for the client to infer one-time usage from a missing expires_in contradicts the general consensus of this thread does it not? paul On 1/17/12 11:38 AM, torsten@lodderstedt.net wrote: Hi, isn't one-time semantics typically associated with certain requests on certain resources/resource types. I therefore would assume the client to know which tokens to use one-time only. The authz server should not return an expires_in paramter. We for example use one time access tokens for payment transactions. What would such an extension specify? regards, Torsten. Gesendet mit BlackBerry® Webmail von Telekom Deutschland -----Original Message----- From: Paul Madsen Sender: oauth-bounces@ietf.org Date: Tue, 17 Jan 2012 08:23:37 To: Richer, Justin P. Cc: OAuth WG Subject: Re: [OAUTH-WG] Access Token Response without expires_in _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ------J9BMLS7DS5C14GN0QQCJ540HNT0I95 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Paul,

that's not what I meant. The Client should know which tokens should be one time usage based on the API description. The authz server must not return expires_in because this would not make any sense in this case.

regards,
Torsten




Paul Madsen <paul.madsen@gmail.com> schrieb:
Hi Torsten, yes the use case in question is payment-based as well.

Your suggestion for the client to infer one-time usage from a missing expires_in contradicts the general consensus of this thread does it not?

paul

On 1/17/12 11:38 AM, torsten@lodderstedt.net wrote: 
Hi,

isn't one-time semantics typically associated with certain requests on certain resources/resource types. I therefore would assume the client to know which tokens to use one-time only. The authz server should not return an expires_in paramter. We for example use one time access tokens for payment transactions.  

What would such an extension specify?

regards,
Torsten.
Gesendet mit BlackBerry® Webmail von Telekom Deutschland  

-----Original Message-----
From: Paul Madsen <paul.madsen@gmail.com>
Sender: oauth-bounces@ietf.org
Date: Tue, 17 Jan 2012 08:23:37 
To: Richer, Justin P.<jricher@mitre.org>
Cc: OAuth WG<oauth@ietf.org>
Subject: Re: [OAUTH-WG] Access Token Response without expires_in

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
------J9BMLS7DS5C14GN0QQCJ540HNT0I95-- From paul.madsen@gmail.com Tue Jan 17 09:53:23 2012 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 D2FC621F8582 for ; Tue, 17 Jan 2012 09:53:23 -0800 (PST) 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 flE8CFPtxVfZ for ; Tue, 17 Jan 2012 09:53:23 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id B32DC21F8572 for ; Tue, 17 Jan 2012 09:53:22 -0800 (PST) Received: by bkbzs2 with SMTP id zs2so158627bkb.31 for ; Tue, 17 Jan 2012 09:53:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=N+6aAvTt78BTkqZRdxhnd/ldS606XxxWJ3CPeU0smUo=; b=SxSblWScTgDrA8E1vckXeEd5CuQGm5zwdLBbDZKyTZtS0UKXlsB+2QHkQLETp4+JUR y7L/+WlV2iKRFTEBkhPhja+ylnrcX4RkdyQG/tMm744qJfu6FANW/58q+yBXLFttfKK2 Z52eE/6Wg6ctqQ04JnyEt7vUp3J/wvNFo9pZg= Received: by 10.205.131.2 with SMTP id ho2mr7244313bkc.36.1326822800804; Tue, 17 Jan 2012 09:53:20 -0800 (PST) Received: from pmadsen-mbp.local (CPE0022b0cb82b4-CM0012256eb4b4.cpe.net.cable.rogers.com. [72.136.168.159]) by mx.google.com with ESMTPS id ci12sm48702219bkb.13.2012.01.17.09.53.16 (version=SSLv3 cipher=OTHER); Tue, 17 Jan 2012 09:53:19 -0800 (PST) Message-ID: <4F15B589.1060307@gmail.com> Date: Tue, 17 Jan 2012 12:53:13 -0500 From: Paul Madsen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Torsten Lodderstedt References: <90C41DD21FB7C64BB94121FBBC2E723453A754C549@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4F157659.7050701@gmail.com> <1451834425-1326818330-cardhu_decombobulator_blackberry.rim.net-253428785-@b4.c11.bise7.blackberry> <4F15A655.4060404@gmail.com> <2fc6806a-8a15-4b97-87f2-3c0c0cbd3623@email.android.com> In-Reply-To: <2fc6806a-8a15-4b97-87f2-3c0c0cbd3623@email.android.com> Content-Type: multipart/alternative; boundary="------------070806040106090805010303" Cc: OAuth WG Subject: Re: [OAUTH-WG] Access Token Response without expires_in 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, 17 Jan 2012 17:53:24 -0000 This is a multi-part message in MIME format. --------------070806040106090805010303 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit thanks Torsten, but by the same logic we could say that each RS should document the lifetime of tokens it will accept and so the AS need not send expires_in .... - why rely on implicit understanding for one-time tokens when we dont for those that expire based on time? I have no particular axe-to-grind here - just hoping for a consensus best practice for one-time tokens paul On 1/17/12 12:26 PM, Torsten Lodderstedt wrote: > Hi Paul, > > that's not what I meant. The Client should know which tokens should be > one time usage based on the API description. The authz server must not > return expires_in because this would not make any sense in this case. > > regards, > Torsten > > > > > Paul Madsen schrieb: > > Hi Torsten, yes the use case in question is payment-based as well. > > Your suggestion for the client to infer one-time usage from a > missing expires_in contradicts the general consensus of this > thread does it not? > > paul > > On 1/17/12 11:38 AM, torsten@lodderstedt.net wrote: >> Hi, >> >> isn't one-time semantics typically associated with certain requests on certain resources/resource types. I therefore would assume the client to know which tokens to use one-time only. The authz server should not return an expires_in paramter. We for example use one time access tokens for payment transactions. >> >> What would such an extension specify? >> >> regards, >> Torsten. >> Gesendet mit BlackBerry® Webmail von Telekom Deutschland >> >> -----Original Message----- >> From: Paul Madsen >> Sender:oauth-bounces@ietf.org >> Date: Tue, 17 Jan 2012 08:23:37 >> To: Richer, Justin P. >> Cc: OAuth WG >> Subject: Re: [OAUTH-WG] Access Token Response without expires_in >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> --------------070806040106090805010303 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit thanks Torsten, but by the same logic we could say that each RS should document the lifetime of tokens it will accept and so the AS need not send expires_in .... - why rely on implicit understanding for one-time tokens when we dont for those that expire based on time?

I have no particular axe-to-grind here - just hoping for a consensus best practice for one-time tokens

paul

On 1/17/12 12:26 PM, Torsten Lodderstedt wrote:
Hi Paul,

that's not what I meant. The Client should know which tokens should be one time usage based on the API description. The authz server must not return expires_in because this would not make any sense in this case.

regards,
Torsten




Paul Madsen <paul.madsen@gmail.com> schrieb:
Hi Torsten, yes the use case in question is payment-based as well.

Your suggestion for the client to infer one-time usage from a missing expires_in contradicts the general consensus of this thread does it not?

paul

On 1/17/12 11:38 AM, torsten@lodderstedt.net wrote: 
Hi,

isn't one-time semantics typically associated with certain requests on certain resources/resource types. I therefore would assume the client to know which tokens to use one-time only. The authz server should not return an expires_in paramter. We for example use one time access tokens for payment transactions.  

What would such an extension specify?

regards,
Torsten.
Gesendet mit BlackBerry® Webmail von Telekom Deutschland  

-----Original Message-----
From: Paul Madsen <paul.madsen@gmail.com>
Sender: oauth-bounces@ietf.org
Date: Tue, 17 Jan 2012 08:23:37 
To: Richer, Justin P.<jricher@mitre.org>
Cc: OAuth WG<oauth@ietf.org>
Subject: Re: [OAUTH-WG] Access Token Response without expires_in

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--------------070806040106090805010303-- From paul.madsen@gmail.com Tue Jan 17 09:56:01 2012 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 B2AFE11E8071 for ; Tue, 17 Jan 2012 09:56:01 -0800 (PST) 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=[AWL=-0.000, 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 gwc6p7w721jV for ; Tue, 17 Jan 2012 09:56:01 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB3621F8585 for ; Tue, 17 Jan 2012 09:56:00 -0800 (PST) Received: by bkbzs2 with SMTP id zs2so160932bkb.31 for ; Tue, 17 Jan 2012 09:55:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=fuKifBYdyq0URGSUgkbsMfIYIj667f4Fo9O1QhHtM/8=; b=Fms1jKy4rjDISZfO48bcwYXfxk5oyLxC2DCdOtLty3ArRud7V966uAlzVKcaNJzJdh PkYOIX6ln8nOPPJ+L/thM8LY1DV1GYA28bpQOU0maMkpPR0hB7y8/+xwXLswEWOj7yZU oN671eHJ+rwEK2yYu+DMH6ii69NSJLvfJCK00= Received: by 10.204.133.201 with SMTP id g9mr2980303bkt.137.1326822959630; Tue, 17 Jan 2012 09:55:59 -0800 (PST) Received: from pmadsen-mbp.local (CPE0022b0cb82b4-CM0012256eb4b4.cpe.net.cable.rogers.com. [72.136.168.159]) by mx.google.com with ESMTPS id ga13sm12238562bkc.5.2012.01.17.09.55.56 (version=SSLv3 cipher=OTHER); Tue, 17 Jan 2012 09:55:58 -0800 (PST) Message-ID: <4F15B62A.5070001@gmail.com> Date: Tue, 17 Jan 2012 12:55:54 -0500 From: Paul Madsen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: William Mills References: <90C41DD21FB7C64BB94121FBBC2E723453A754C549@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4F157659.7050701@gmail.com> <1326819620.50670.YahooMailNeo@web31804.mail.mud.yahoo.com> In-Reply-To: <1326819620.50670.YahooMailNeo@web31804.mail.mud.yahoo.com> Content-Type: multipart/alternative; boundary="------------010304000106050200030304" Cc: OAuth WG Subject: Re: [OAUTH-WG] Access Token Response without expires_in 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, 17 Jan 2012 17:56:01 -0000 This is a multi-part message in MIME format. --------------010304000106050200030304 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit scope sometimes feels like SAML authncontext - anything can go in there :-) as I said to Torsten, perhaps an extension is overkill. Just looking for a best practice On 1/17/12 12:00 PM, William Mills wrote: > Does this require an extension? That seems something easy to overload > on scope. > > ------------------------------------------------------------------------ > *From:* Paul Madsen > *To:* "Richer, Justin P." > *Cc:* OAuth WG > *Sent:* Tuesday, January 17, 2012 5:23 AM > *Subject:* Re: [OAUTH-WG] Access Token Response without expires_in > > Separate from the question posed here, we are seeing customer demand > for one-time semantics, but agree with Justin that this would best > belong in a dedicated extension parameter and not the default > > paul > > On 1/16/12 10:29 PM, Richer, Justin P. wrote: >> I think #3. >> >> #1 will be a common instance, and #2 (or its variant, a limited number of uses) is a different expiration pattern than time that would want to have its own expiration parameter name. I haven't seen enough concrete use of this pattern to warrant its own extension though. >> >> Which is why I vote #3 - it's a configuration issue. Perhaps we should rather say that the AS "SHOULD document the token behavior in the absence of this parameter, which may include the token not expiring until explicitly revoked, expiring after a set number of uses, or other expiration behavior." That's a lot of words here though. >> >> -- Justin >> >> On Jan 16, 2012, at 1:53 PM, Eran Hammer wrote: >> >>> A question came up about the access token expiration when expires_in is not included in the response. This should probably be made clearer in the spec. The three options are: >>> >>> 1. Does not expire (but can be revoked) >>> 2. Single use token >>> 3. Defaults to whatever the authorization server decides and until revoked >>> >>> #3 is the assumed answer given the WG history. I'll note that in the spec, but wanted to make sure this is the explicit WG consensus. >>> >>> EHL >>> >>> >>> _______________________________________________ >>> 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 > > --------------010304000106050200030304 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit scope sometimes feels like SAML authncontext - anything can go in there :-)

as I said to Torsten, perhaps an extension is overkill. Just looking for a best practice

On 1/17/12 12:00 PM, William Mills wrote:
Does this require an extension?  That seems something easy to overload on scope.

From: Paul Madsen <paul.madsen@gmail.com>
To: "Richer, Justin P." <jricher@mitre.org>
Cc: OAuth WG <oauth@ietf.org>
Sent: Tuesday, January 17, 2012 5:23 AM
Subject: Re: [OAUTH-WG] Access Token Response without expires_in

Separate from the question posed here, we are seeing customer demand for one-time semantics, but agree with Justin that this would best belong in a dedicated extension parameter and not the default

paul

On 1/16/12 10:29 PM, Richer, Justin P. wrote: 
I think #3.

#1 will be a common instance, and #2 (or its variant, a limited number of uses) is a different expiration pattern than time that would want to have its own expiration parameter name. I haven't seen enough concrete use of this pattern to warrant its own extension though. 

Which is why I vote #3 - it's a configuration issue. Perhaps we should rather say that the AS "SHOULD document the token behavior in the absence of this parameter, which may include the token not expiring until explicitly revoked, expiring after a set number of uses, or other expiration behavior." That's a lot of words here though.

 -- Justin

On Jan 16, 2012, at 1:53 PM, Eran Hammer wrote:


A question came up about the access token expiration when expires_in is not included in the response. This should probably be made clearer in the spec. The three options are:

1. Does not expire (but can be revoked)
2. Single use token
3. Defaults to whatever the authorization server decides and until revoked

#3 is the assumed answer given the WG history. I'll note that in the spec, but wanted to make sure this is the explicit WG consensus.

EHL


_______________________________________________
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


--------------010304000106050200030304-- From jricher@mitre.org Tue Jan 17 10:59:32 2012 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 9D6E511E80AA; Tue, 17 Jan 2012 10:59:32 -0800 (PST) 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 bsfSGdD9w8Lk; Tue, 17 Jan 2012 10:59:31 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 82E8D11E80A6; Tue, 17 Jan 2012 10:59:31 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id F25D721B17B3; Tue, 17 Jan 2012 13:59:30 -0500 (EST) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id DDA4421B17A5; Tue, 17 Jan 2012 13:59:30 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.158]) by IMCCAS01.MITRE.ORG ([129.83.29.78]) with mapi id 14.01.0339.001; Tue, 17 Jan 2012 13:59:30 -0500 From: "Richer, Justin P." To: Torsten Lodderstedt , Paul Madsen Thread-Topic: AW: Re: [OAUTH-WG] Access Token Response without expires_in Thread-Index: AczUf8kvUkdgy1nHSGOm5KixWQExDAAclWSAABTAkIAABtE5gAAAVTyAAAFYhID//8HxSQ== Date: Tue, 17 Jan 2012 18:59:30 +0000 Message-ID: References: <90C41DD21FB7C64BB94121FBBC2E723453A754C549@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4F157659.7050701@gmail.com> <1451834425-1326818330-cardhu_decombobulator_blackberry.rim.net-253428785-@b4.c11.bise7.blackberry> <4F15A655.4060404@gmail.com>, <2fc6806a-8a15-4b97-87f2-3c0c0cbd3623@email.android.com> In-Reply-To: <2fc6806a-8a15-4b97-87f2-3c0c0cbd3623@email.android.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.52] Content-Type: multipart/alternative; boundary="_000_B33BFB58CCC8BE4998958016839DE27E09EC78IMCMBX01MITREORG_" MIME-Version: 1.0 Cc: "oauth-bounces@ietf.org" , OAuth WG Subject: Re: [OAUTH-WG] Access Token Response without expires_in 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, 17 Jan 2012 18:59:32 -0000 --_000_B33BFB58CCC8BE4998958016839DE27E09EC78IMCMBX01MITREORG_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable By the same argument, the client can know how long the tokens are good for = via API description. What we're talking about is a programmatic hint by the= AS to the Client about what the token is good for. One common use is time-= limited, and so provisions for that have been baked in so that everybody do= es it the same way. If there's enough out there to be use-limited or other = bits, we should have a tiny provision to extend this in a similar fashion. -- Justin ________________________________ From: Torsten Lodderstedt [torsten@lodderstedt.net] Sent: Tuesday, January 17, 2012 12:26 PM To: Paul Madsen Cc: oauth-bounces@ietf.org; Richer, Justin P.; OAuth WG Subject: Re: AW: Re: [OAUTH-WG] Access Token Response without expires_in Hi Paul, that's not what I meant. The Client should know which tokens should be one = time usage based on the API description. The authz server must not return e= xpires_in because this would not make any sense in this case. regards, Torsten Paul Madsen schrieb: Hi Torsten, yes the use case in question is payment-based as well. Your suggestion for the client to infer one-time usage from a missing expir= es_in contradicts the general consensus of this thread does it not? paul On 1/17/12 11:38 AM, torsten@lodderstedt.net wrote: Hi, isn't one-time semantics typically associated with certain requests on cert= ain resources/resource types. I therefore would assume the client to know w= hich tokens to use one-time only. The authz server should not return an exp= ires_in paramter. We for example use one time access tokens for payment tra= nsactions. What would such an extension specify? regards, Torsten. Gesendet mit BlackBerry=AE Webmail von Telekom Deutschland -----Original Message----- From: Paul Madsen Sender: oauth-bounces@ietf.org Date: Tue, 17 Jan 2012 08:23:37 To: Richer, Justin P. Cc: OAuth WG Subject: Re: [OAUTH-WG] Access Token Response without expires_in _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_B33BFB58CCC8BE4998958016839DE27E09EC78IMCMBX01MITREORG_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
By the same argument, the client can know how long the tokens are go= od for via API description. What we're talking about is a programmatic hint= by the AS to the Client about what the token is good for. One common use is time-limited, and so provisions f= or that have been baked in so that everybody does it the same way. If there= 's enough out there to be use-limited or other bits, we should have a tiny = provision to extend this in a similar fashion.

 -- Justin

From: Torsten Lodderstedt [torsten@lodder= stedt.net]
Sent: Tuesday, January 17, 2012 12:26 PM
To: Paul Madsen
Cc: oauth-bounces@ietf.org; Richer, Justin P.; OAuth WG
Subject: Re: AW: Re: [OAUTH-WG] Access Token Response without expire= s_in

Hi Paul,

that's not what I meant. The Client should know which tokens should be one = time usage based on the API description. The authz server must not return e= xpires_in because this would not make any sense in this case.

regards,
Torsten




Paul Madsen <paul.madsen@gmail.com> schrieb:
Hi Torsten, yes the use case in question is payment-ba= sed as well.

Your suggestion for the client to infer one-time usage from a missing expir= es_in contradicts the general consensus of this thread does it not?

paul

On 1/17/12 11:38 AM, torsten@lodderstedt.net wrote: 
Hi,=0A=
=0A=
isn't one-time semantics typically associated with certain requests on cert=
ain resources/resource types. I therefore would assume the client to know w=
hich tokens to use one-time only. The authz server should not return an exp=
ires_in paramter. We for example use one time access tokens for payment tra=
nsactions.  =0A=
=0A=
What would such an extension specify?=0A=
=0A=
regards,=0A=
Torsten.=0A=
Gesendet mit BlackBerry=AE Webmail von Telekom Deutschland  =0A=
=0A=
-----Original Message-----=0A=
From: Paul Madsen <paul.madsen@gmail.com>=0A=
Sender: oauth-bounces@ietf.org=0A=
Date: Tue, 17 Jan 2012 08:23:37 =0A=
To: Richer, Justin P.<jricher@mitre.org>=0A=
Cc: OAuth WG<oauth@ietf.org>=0A=
Subject: Re: [OAUTH-WG] Access Token Response without expires_in=0A=
=0A=
_______________________________________________=0A=
OAuth mailing list=0A=
OAuth@ietf.org=0A=
https://www.ietf.org/mailman/listinfo/oauth<=
/a>=0A=
=0A=
--_000_B33BFB58CCC8BE4998958016839DE27E09EC78IMCMBX01MITREORG_-- From jricher@mitre.org Tue Jan 17 11:01:04 2012 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 9180811E80B0 for ; Tue, 17 Jan 2012 11:01:04 -0800 (PST) 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 XPU6-Q4ICz+m for ; Tue, 17 Jan 2012 11:01:03 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8525A11E80A6 for ; Tue, 17 Jan 2012 11:01:03 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 91D1421B17A5; Tue, 17 Jan 2012 14:01:00 -0500 (EST) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 19CE521B17B9; Tue, 17 Jan 2012 14:01:00 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.158]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.01.0339.001; Tue, 17 Jan 2012 14:00:59 -0500 From: "Richer, Justin P." To: Paul Madsen , William Mills Thread-Topic: [OAUTH-WG] Access Token Response without expires_in Thread-Index: AczUf8kvUkdgy1nHSGOm5KixWQExDAAclWSAABTAkIAAB5GZAAAB8M4A//++MJ8= Date: Tue, 17 Jan 2012 19:00:59 +0000 Message-ID: References: <90C41DD21FB7C64BB94121FBBC2E723453A754C549@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4F157659.7050701@gmail.com> <1326819620.50670.YahooMailNeo@web31804.mail.mud.yahoo.com>, <4F15B62A.5070001@gmail.com> In-Reply-To: <4F15B62A.5070001@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.52] Content-Type: multipart/alternative; boundary="_000_B33BFB58CCC8BE4998958016839DE27E09EC9CIMCMBX01MITREORG_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Access Token Response without expires_in 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, 17 Jan 2012 19:01:04 -0000 --_000_B33BFB58CCC8BE4998958016839DE27E09EC9CIMCMBX01MITREORG_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Scope is a lot closer to authzcontext in concept than authncontext, since O= Auth is out of the authn game. -- Justin ________________________________ From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] on behalf of Paul Mad= sen [paul.madsen@gmail.com] Sent: Tuesday, January 17, 2012 12:55 PM To: William Mills Cc: OAuth WG Subject: Re: [OAUTH-WG] Access Token Response without expires_in scope sometimes feels like SAML authncontext - anything can go in there :-) as I said to Torsten, perhaps an extension is overkill. Just looking for a = best practice On 1/17/12 12:00 PM, William Mills wrote: Does this require an extension? That seems something easy to overload on s= cope. ________________________________ From: Paul Madsen To: "Richer, Justin P." Cc: OAuth WG Sent: Tuesday, January 17, 2012 5:23 AM Subject: Re: [OAUTH-WG] Access Token Response without expires_in Separate from the question posed here, we are seeing customer demand for on= e-time semantics, but agree with Justin that this would best belong in a de= dicated extension parameter and not the default paul On 1/16/12 10:29 PM, Richer, Justin P. wrote: I think #3. #1 will be a common instance, and #2 (or its variant, a limited number of u= ses) is a different expiration pattern than time that would want to have it= s own expiration parameter name. I haven't seen enough concrete use of this= pattern to warrant its own extension though. Which is why I vote #3 - it's a configuration issue. Perhaps we should rath= er say that the AS "SHOULD document the token behavior in the absence of th= is parameter, which may include the token not expiring until explicitly rev= oked, expiring after a set number of uses, or other expiration behavior." T= hat's a lot of words here though. -- Justin On Jan 16, 2012, at 1:53 PM, Eran Hammer wrote: A question came up about the access token expiration when expires_in is not= included in the response. This should probably be made clearer in the spec= . The three options are: 1. Does not expire (but can be revoked) 2. Single use token 3. Defaults to whatever the authorization server decides and until revoked #3 is the assumed answer given the WG history. I'll note that in the spec, = but wanted to make sure this is the explicit WG consensus. EHL _______________________________________________ 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_B33BFB58CCC8BE4998958016839DE27E09EC9CIMCMBX01MITREORG_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Scope is a lot closer to authzcontext in concept than authncontext, = since OAuth is out of the authn game.

 -- Justin

From: oauth-bounces@ietf.org [oauth-bounc= es@ietf.org] on behalf of Paul Madsen [paul.madsen@gmail.com]
Sent: Tuesday, January 17, 2012 12:55 PM
To: William Mills
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Access Token Response without expires_in

scope sometimes feels like SAML authncontext - an= ything can go in there :-)

as I said to Torsten, perhaps an extension is overkill. Just looking for a = best practice

On 1/17/12 12:00 PM, William Mills wrote:
Does this require an extension?  That seems something easy to ove= rload on scope.

From: Paul Madsen <paul.madsen@gmail.com>
To: "Richer, Justin P= ." <jricher@mitre.org>
Cc: OAuth WG <oauth@ietf.org>
Sent: Tuesday, January 17,= 2012 5:23 AM
Subject: Re: [OAUTH-WG] Ac= cess Token Response without expires_in

Separate from the question posed here, we are see= ing customer demand for one-time semantics, but agree with Justin that this= would best belong in a dedicated extension parameter and not the default

paul

On 1/16/12 10:29 PM, Richer, Justin P. wrote: 
I think #3.=0A=
=0A=
#1 will be a common instance, and #2 (or its variant, a limited number of u=
ses) is a different expiration pattern than time that would want to have it=
s own expiration parameter name. I haven't seen enough concrete use of this=
 pattern to warrant its own extension though. =0A=
=0A=
Which is why I vote #3 - it's a configuration issue. Perhaps we should rath=
er say that the AS "SHOULD document the token behavior in the absence =
of this parameter, which may include the token not expiring until explicitl=
y revoked, expiring after a set number of uses, or other expiration behavio=
r." That's a lot of words here though.=0A=
=0A=
 -- Justin=0A=
=0A=
On Jan 16, 2012, at 1:53 PM, Eran Hammer wrote:=0A=
=0A=

A question came up about the access token expiration when expires_in i=
s not included in the response. This should probably be made clearer in the=
 spec. The three options are:=0A=
=0A=
1. Does not expire (but can be revoked)=0A=
2. Single use token=0A=
3. Defaults to whatever the authorization server decides and until revoked=
=0A=
=0A=
#3 is the assumed answer given the WG history. I'll note that in the spec, =
but wanted to make sure this is the explicit WG consensus.=0A=
=0A=
EHL=0A=
=0A=
=0A=
_______________________________________________=0A=
OAuth mailing list=0A=
OAuth@ietf.org=0A=
https://www.iet=
f.org/mailman/listinfo/oauth=0A=

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

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


--_000_B33BFB58CCC8BE4998958016839DE27E09EC9CIMCMBX01MITREORG_-- From wmills@yahoo-inc.com Tue Jan 17 12:58:37 2012 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 261B721F8681 for ; Tue, 17 Jan 2012 12:58:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.314 X-Spam-Level: X-Spam-Status: No, score=-17.314 tagged_above=-999 required=5 tests=[AWL=0.284, 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 RZsa86-8HcMt for ; Tue, 17 Jan 2012 12:58:36 -0800 (PST) Received: from nm30.bullet.mail.sp2.yahoo.com (nm30.bullet.mail.sp2.yahoo.com [98.139.91.100]) by ietfa.amsl.com (Postfix) with SMTP id 55A7021F868A for ; Tue, 17 Jan 2012 12:58:35 -0800 (PST) Received: from [98.139.91.65] by nm30.bullet.mail.sp2.yahoo.com with NNFMP; 17 Jan 2012 20:58:32 -0000 Received: from [98.139.91.7] by tm5.bullet.mail.sp2.yahoo.com with NNFMP; 17 Jan 2012 20:58:32 -0000 Received: from [127.0.0.1] by omp1007.mail.sp2.yahoo.com with NNFMP; 17 Jan 2012 20:58:32 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 566642.64641.bm@omp1007.mail.sp2.yahoo.com Received: (qmail 79848 invoked by uid 60001); 17 Jan 2012 20:58:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1326833912; bh=5oyJxP/L4Y2HZEPhQ/rwYGo5tFfUniL77nqGFhsI0j4=; 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=KihL0BT03F6DZZYbkw8HuREPMScXLnoqQNdd2dHDRMazJJWWi5IRDJyLZOrIo/TXN4Z0gU1HzWhpK36Q4JxjUJLsowwgZ6rOcmQ96FOQ/5SRHS8bVr21iSFL72vrbPKpgiYZXI9qhN1qntZyp6DjRt6XLt8xH8FEuTnH6UCwlnw= 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=hs1skGl3ROC0maF2buelmfvQpIS/T2UzxKGOZHxxrK7gmJpSfr1T2Wp0Kgkiwaeqzb5f6ETm8ZxIA95DRF4b/BKoR2xvQ8e1GxlV3Je/h3j6uBwLPnTB2qFe+zw7SRJJlNkassFE5/rULQmMXMQvD+Z4DGsChtRaIuICzCOcyKo=; X-YMail-OSG: IkosR_YVM1mZczwsiplJ73Ij_gYnr6psXc09uZ5cy7nj84O aOqu.qSMAndwnhULJGxuH9DPk0nqWqWkQBx4Jjh5JdsKtaBrLTVrdBJu51Ai FCbVQlkJ04IteKn_xJ6ZtVeDR_lADZ7utbv.gpl4zEOXV6EcnmaW974S7MRl _sWp56axdo7.R6rvYPqnXCquN0RbooAaAyrsYFtWEOt3ANezNXijztWOs__6 pLJpWL5hfyp2WQ.IDqJTAfp0zJ6oo61kJWyv5b219ccESkQuNeVn_v3winMC LddjZ4kmAxDDKAp6e67eGgAWLsGjBItcu8q1UIJGCyVAGIOG.phz8FMB8zwa uUEOaOZ94IePEOdkadlOhibKu8EQBeDnajlLsAG3dkxHr.g.XQImFaz1wM2e QA.EypZx7b.enkEL39zRMMoSuIw4cjwvYjT.3ekQ- Received: from [209.131.62.113] by web31813.mail.mud.yahoo.com via HTTP; Tue, 17 Jan 2012 12:58:32 PST X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.116.331537 References: <90C41DD21FB7C64BB94121FBBC2E723453A754C549@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4F157659.7050701@gmail.com> <1451834425-1326818330-cardhu_decombobulator_blackberry.rim.net-253428785-@b4.c11.bise7.blackberry> <4F15A655.4060404@gmail.com>, <2fc6806a-8a15-4b97-87f2-3c0c0cbd3623@email.android.com> Message-ID: <1326833912.76041.YahooMailNeo@web31813.mail.mud.yahoo.com> Date: Tue, 17 Jan 2012 12:58:32 -0800 (PST) From: William Mills To: "Richer, Justin P." , Torsten Lodderstedt , Paul Madsen In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="767760015-594162983-1326833912=:76041" Cc: "oauth-bounces@ietf.org" , OAuth WG Subject: Re: [OAUTH-WG] Access Token Response without expires_in 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, 17 Jan 2012 20:58:37 -0000 --767760015-594162983-1326833912=:76041 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =0A=0AOne use tokens can also expire before they are used.=A0 "You have 5 m= inutes to do this once."=0A=0A=0A=0A________________________________=0A =0A= From: Torsten Lodderstedt [torsten@lodderstedt.net]=0ASent: Tuesday, Januar= y 17, 2012 12:26 PM=0ATo: Paul Madsen=0ACc: oauth-bounces@ietf.org; Richer,= Justin P.; OAuth WG=0ASubject: Re: AW: Re: [OAUTH-WG] Access Token Respons= e without expires_in=0A=0A=0AHi Paul,=0A=0Athat's not what I meant. The Cli= ent should know which tokens should be one time usage based on the API desc= ription. The authz server must not return expires_in because this would not= make any sense in this case.=0A=0Aregards,=0ATorsten=0A=0A=0A=0A=0A=0APaul= Madsen schrieb: =0AHi Torsten, yes the use case in= question is payment-based as well. =0A>=0A>Your suggestion for the client = to infer one-time usage from a missing expires_in contradicts the general c= onsensus of this thread does it not?=0A>=0A>paul=0A>=0A>On 1/17/12 11:38 AM= , torsten@lodderstedt.net wrote: =0A>Hi, isn't one-time semantics typically= associated with certain requests on certain resources/resource types. I th= erefore would assume the client to know which tokens to use one-time only. = The authz server should not return an expires_in paramter. We for example u= se one time access tokens for payment transactions. What would such an ex= tension specify? regards,=0ATorsten.=0AGesendet mit BlackBerry=AE Webmail v= on Telekom Deutschland -----Original Message-----=0AFrom: Paul Madsen Sender: oauth-bounces@ietf.org Date: Tue, 17 Jan 2012 = 08:23:37 =0ATo: Richer, Justin P. Cc: OAuth WG Subject: Re: [OAUTH-WG] Access Token Response without expires_in ___= ____________________________________________=0AOAuth mailing list OAuth@iet= f.org https://www.ietf.org/mailman/listinfo/oauth =0A______________________= _________________________=0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps://w= ww.ietf.org/mailman/listinfo/oauth --767760015-594162983-1326833912=:76041 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

=0A
One use= tokens can also expire before they are used.  "You have 5 minutes to = do this once."

=0A
=0A
From: Torsten Lodderstedt [torsten@lodderstedt.net]=0ASent: Tuesday, January 17, 2012 12:26 PM
=0ATo: Paul = Madsen
=0ACc: oauth-bounces@ietf.org; Richer, Justin P.; OAuth WG=
=0ASubject: Re: AW: Re: [OAUTH-WG] Access Token Response without= expires_in
=0A
=0A
=0A
=0A
Hi Paul,
=0A=
=0Athat's not what I meant. The Client should know which tokens should = be one time usage based on the API description. The authz server must not r= eturn expires_in because this would not make any sense in this case.
=0A=
=0Aregards,
=0ATorsten
=0A
=0A
=0A

=0A
=0APaul Madsen <paul.madsen@gmail.com> schr= ieb:=0A
= =0AHi Torsten, yes the use case in question is payment= -based as well.=0A
=0A
=0AYour suggestion for the client to infer one= -time usage from a missing expires_in contradicts the general consensus of = this thread does it not?
=0A
=0Apaul
=0A
=0AOn 1/17/12 1= 1:38 AM, =0Atorsten@lodderstedt.net wrote:=0A=0A
Hi,=0A=0Aisn't one-time semantics typically asso=
ciated with certain requests on certain resources/resource types. I therefo=
re would assume the client to know which tokens to use one-time only. The a=
uthz server should not return an expires_in paramter. We for example use on=
e time access tokens for payment transactions.  =0A=0AWhat would such an ex=
tension specify?=0A=0Aregards,=0ATorsten.=0AGesendet mit BlackBerry=AE Webm=
ail von Telekom Deutschland  =0A=0A-----Original Message-----=0AFrom: Paul =
Madsen <paul.madsen@gmail.com>=0ASender: oauth-bounces@ietf.org=0ADate: Tue, 17 Jan 2012 08:23:37 =0ATo: Ri=
cher, Justin P.<jricher@mitre.org>=0ACc: OAuth WG<oauth@ietf=
.org>=0ASubject: Re: [OAUTH-WG] Access Token Response without expire=
s_in=0A=0A_______________________________________________=0AOAuth mailing l=
ist=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/oauth=0A=0A
= =0A
=0A=0A
=0A
=0A
=0A
=0A=0A=0A

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


--767760015-594162983-1326833912=:76041-- From torsten@lodderstedt.net Tue Jan 17 22:48:49 2012 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 EB26421F8743; Tue, 17 Jan 2012 22:48:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 Jhy7mE5rdxh9; Tue, 17 Jan 2012 22:48:49 -0800 (PST) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.29.7]) by ietfa.amsl.com (Postfix) with ESMTP id D736121F8741; Tue, 17 Jan 2012 22:48:48 -0800 (PST) Received: from [79.253.33.127] (helo=[192.168.71.31]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.68) (envelope-from ) id 1RnPK9-0007m6-Mb; Wed, 18 Jan 2012 07:48:45 +0100 References: <90C41DD21FB7C64BB94121FBBC2E723453A754C549@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4F157659.7050701@gmail.com> <1451834425-1326818330-cardhu_decombobulator_blackberry.rim.net-253428785-@b4.c11.bise7.blackberry> <4F15A655.4060404@gmail.com>, <2fc6806a-8a15-4b97-87f2-3c0c0cbd3623@email.android.com> <1326833912.76041.YahooMailNeo@web31813.mail.mud.yahoo.com> User-Agent: K-9 Mail for Android In-Reply-To: <1326833912.76041.YahooMailNeo@web31813.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----81UE611OHB02WT6BYGCLNA1LEMS9JM" From: Torsten Lodderstedt Date: Wed, 18 Jan 2012 07:48:28 +0100 To: William Mills , "Richer, Justin P." , Paul Madsen Message-ID: X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: "oauth-bounces@ietf.org" , OAuth WG Subject: Re: [OAUTH-WG] Access Token Response without expires_in 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, 18 Jan 2012 06:48:50 -0000 ------81UE611OHB02WT6BYGCLNA1LEMS9JM Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit good point William Mills schrieb: One use tokens can also expire before they are used. "You have 5 minutes to do this once." _____________________________________________ From: Torsten Lodderstedt [torsten@lodderstedt.net] Sent: Tuesday, January 17, 2012 12:26 PM To: Paul Madsen Cc: oauth-bounces@ietf.org; Richer, Justin P.; OAuth WG Subject: Re: AW: Re: [OAUTH-WG] Access Token Response without expires_in Hi Paul, that's not what I meant. The Client should know which tokens should be one time usage based on the API description. The authz server must not return expires_in because this would not make any sense in this case. regards, Torsten Paul Madsen schrieb: Hi Torsten, yes the use case in question is payment-based as well. Your suggestion for the client to infer one-time usage from a missing expires_in contradicts the general consensus of this thread does it not? paul On 1/17/12 11:38 AM, torsten@lodderstedt.net wrote: Hi, isn't one-time semantics typically associated with certain requests on certain resources/resource types. I therefore would assume the client to know which tokens to use one-time only. The authz server should not return an expires_in paramter. We for example use one time access tokens for payment transactions. What would such an extension specify? regards, Torsten. Gesendet mit BlackBerry® Webmail von Telekom Deutschland -----Original Message----- From: Paul Madsen Sender: oauth-bounces@ietf.org Date: Tue, 17 Jan 2012 08:23:37 To: Richer, Justin P. Cc: OAuth WG Subject: Re: [OAUTH-WG] Access Token Response without expires_in _______________________________________________ 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 ------81UE611OHB02WT6BYGCLNA1LEMS9JM Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit good point



William Mills <wmills@yahoo-inc.com> schrieb:

One use tokens can also expire before they are used.  "You have 5 minutes to do this once."

From: Torsten Lodderstedt [torsten@lodderstedt.net]
Sent: Tuesday, January 17, 2012 12:26 PM
To: Paul Madsen
Cc: oauth-bounces@ietf.org; Richer, Justin P.; OAuth WG
Subject: Re: AW: Re: [OAUTH-WG] Access Token Response without expires_in

Hi Paul,

that's not what I meant. The Client should know which tokens should be one time usage based on the API description. The authz server must not return expires_in because this would not make any sense in this case.

regards,
Torsten




Paul Madsen <paul.madsen@gmail.com> schrieb:
Hi Torsten, yes the use case in question is payment-based as well.

Your suggestion for the client to infer one-time usage from a missing expires_in contradicts the general consensus of this thread does it not?

paul

On 1/17/12 11:38 AM, torsten@lodderstedt.net wrote: 
Hi,

isn't one-time semantics typically associated with certain requests on certain resources/resource types. I therefore would assume the client to know which tokens to use one-time only. The authz server should not return an expires_in paramter. We for example use one time access tokens for payment transactions.  

What would such an extension specify?

regards,
Torsten.
Gesendet mit BlackBerry® Webmail von Telekom Deutschland  

-----Original Message-----
From: Paul Madsen <paul.madsen@gmail.com>
Sender: oauth-bounces@ietf.org
Date: Tue, 17 Jan 2012 08:23:37 
To: Richer, Justin P.<jricher@mitre.org>
Cc: OAuth WG<oauth@ietf.org>
Subject: Re: [OAUTH-WG] Access Token Response without expires_in

_______________________________________________
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


------81UE611OHB02WT6BYGCLNA1LEMS9JM-- From paul.madsen@gmail.com Wed Jan 18 05:57:08 2012 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 A9A9A21F869E for ; Wed, 18 Jan 2012 05:57:08 -0800 (PST) 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=[AWL=-0.000, 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 Zr+Ipw-x3G-w for ; Wed, 18 Jan 2012 05:57:08 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id D63A221F8694 for ; Wed, 18 Jan 2012 05:57:07 -0800 (PST) Received: by vbbfr13 with SMTP id fr13so522663vbb.31 for ; Wed, 18 Jan 2012 05:57:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=6J/Eahbiz6JFnvWbjABIUzQLu7LGMG0jweZB1g2rPs4=; b=lmoJ4R8bpKSUJA68+oQTdg1qxfpO/IH269qMtUKcPkM0zOspuEL1X66u12sOY06RLR 0ak5z0fiomK48x2oVSkl6jlto/ztDMo2g3RTVF3nsToaWkYUq7C7ULfB5xFfvzTcQKat QGCxdZF3qvq2z8uh/+SvbfbvOwEy7E4cyQvLw= Received: by 10.52.74.163 with SMTP id u3mr10496507vdv.91.1326895026067; Wed, 18 Jan 2012 05:57:06 -0800 (PST) Received: from pmadsen-mbp.local (CPE0022b0cb82b4-CM0012256eb4b4.cpe.net.cable.rogers.com. [72.136.168.159]) by mx.google.com with ESMTPS id iw8sm11876529vdb.7.2012.01.18.05.57.00 (version=SSLv3 cipher=OTHER); Wed, 18 Jan 2012 05:57:01 -0800 (PST) Message-ID: <4F16CFAB.5010506@gmail.com> Date: Wed, 18 Jan 2012 08:56:59 -0500 From: Paul Madsen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: William Mills References: <90C41DD21FB7C64BB94121FBBC2E723453A754C549@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4F157659.7050701@gmail.com> <1451834425-1326818330-cardhu_decombobulator_blackberry.rim.net-253428785-@b4.c11.bise7.blackberry> <4F15A655.4060404@gmail.com>, <2fc6806a-8a15-4b97-87f2-3c0c0cbd3623@email.android.com> <1326833912.76041.YahooMailNeo@web31813.mail.mud.yahoo.com> In-Reply-To: <1326833912.76041.YahooMailNeo@web31813.mail.mud.yahoo.com> Content-Type: multipart/alternative; boundary="------------070400010507070202070705" Cc: OAuth WG Subject: Re: [OAUTH-WG] Access Token Response without expires_in 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, 18 Jan 2012 13:57:08 -0000 This is a multi-part message in MIME format. --------------070400010507070202070705 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit which argues for expressing both explicitly On 1/17/12 3:58 PM, William Mills wrote: > > One use tokens can also expire before they are used. "You have 5 > minutes to do this once." > > ------------------------------------------------------------------------ > *From:* Torsten Lodderstedt [torsten@lodderstedt.net] > *Sent:* Tuesday, January 17, 2012 12:26 PM > *To:* Paul Madsen > *Cc:* oauth-bounces@ietf.org; Richer, Justin P.; OAuth WG > *Subject:* Re: AW: Re: [OAUTH-WG] Access Token Response without expires_in > > Hi Paul, > > that's not what I meant. The Client should know which tokens should be > one time usage based on the API description. The authz server must not > return expires_in because this would not make any sense in this case. > > regards, > Torsten > > > > > Paul Madsen schrieb: > > Hi Torsten, yes the use case in question is payment-based as well. > > Your suggestion for the client to infer one-time usage from a > missing expires_in contradicts the general consensus of this > thread does it not? > > paul > > On 1/17/12 11:38 AM, torsten@lodderstedt.net > wrote: >> Hi, >> >> isn't one-time semantics typically associated with certain requests on certain resources/resource types. I therefore would assume the client to know which tokens to use one-time only. The authz server should not return an expires_in paramter. We for example use one time access tokens for payment transactions. >> >> What would such an extension specify? >> >> regards, >> Torsten. >> Gesendet mit BlackBerry® Webmail von Telekom Deutschland >> >> -----Original Message----- >> From: Paul Madsen >> Sender:oauth-bounces@ietf.org >> Date: Tue, 17 Jan 2012 08:23:37 >> To: Richer, Justin P. >> Cc: OAuth WG >> Subject: Re: [OAUTH-WG] Access Token Response without expires_in >> >> _______________________________________________ >> 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 > > --------------070400010507070202070705 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit which argues for expressing both explicitly

On 1/17/12 3:58 PM, William Mills wrote:

One use tokens can also expire before they are used.  "You have 5 minutes to do this once."

From: Torsten Lodderstedt [torsten@lodderstedt.net]
Sent: Tuesday, January 17, 2012 12:26 PM
To: Paul Madsen
Cc: oauth-bounces@ietf.org; Richer, Justin P.; OAuth WG
Subject: Re: AW: Re: [OAUTH-WG] Access Token Response without expires_in

Hi Paul,

that's not what I meant. The Client should know which tokens should be one time usage based on the API description. The authz server must not return expires_in because this would not make any sense in this case.

regards,
Torsten




Paul Madsen <paul.madsen@gmail.com> schrieb:
Hi Torsten, yes the use case in question is payment-based as well.

Your suggestion for the client to infer one-time usage from a missing expires_in contradicts the general consensus of this thread does it not?

paul

On 1/17/12 11:38 AM, torsten@lodderstedt.net wrote: 
Hi,

isn't one-time semantics typically associated with certain requests on certain resources/resource types. I therefore would assume the client to know which tokens to use one-time only. The authz server should not return an expires_in paramter. We for example use one time access tokens for payment transactions.  

What would such an extension specify?

regards,
Torsten.
Gesendet mit BlackBerry® Webmail von Telekom Deutschland  

-----Original Message-----
From: Paul Madsen <paul.madsen@gmail.com>
Sender: oauth-bounces@ietf.org
Date: Tue, 17 Jan 2012 08:23:37 
To: Richer, Justin P.<jricher@mitre.org>
Cc: OAuth WG<oauth@ietf.org>
Subject: Re: [OAUTH-WG] Access Token Response without expires_in

_______________________________________________
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


--------------070400010507070202070705-- From Hannes.Tschofenig@gmx.net Thu Jan 19 07:16:07 2012 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 6670C21F85D6 for ; Thu, 19 Jan 2012 07:16:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.007 X-Spam-Level: X-Spam-Status: No, score=-102.007 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_00=-2.599, 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 ZWRBG4k+HhfS for ; Thu, 19 Jan 2012 07:16:06 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 6469F21F85C9 for ; Thu, 19 Jan 2012 07:16:06 -0800 (PST) Received: (qmail invoked by alias); 19 Jan 2012 15:16:04 -0000 Received: from unknown (EHLO [10.255.135.235]) [192.100.123.77] by mail.gmx.net (mp030) with SMTP; 19 Jan 2012 16:16:04 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/8L39kI+b8l+qn33QPJFBFL3EcGPA/FMm/kT/Pm6 y89NjBBjOYTYF6 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1084) From: Hannes Tschofenig Date: Thu, 19 Jan 2012 17:15:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1E04B787-1CC4-4752-BD34-DBBC7E321450@gmx.net> References: <9E2944CA-16CF-4985-9DA6-B7A1A03EFF10@gmx.net> To: "oauth@ietf.org WG" X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] Fwd: Smart Object Security Workshop Announcement 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, 19 Jan 2012 15:16:07 -0000 Hi all,=20 I know that a few of you have integrated OAuth into small devices, like = picture frames. It would be great if you could share your experience about the utilized = security mechanisms with us. =20 Ciao Hannes Begin forwarded message: > From: Hannes Tschofenig > Date: January 19, 2012 12:21:57 PM GMT+02:00 > To: IETF-Discussion list > Cc: Hannes Tschofenig > Subject: Smart Object Security Workshop Announcement >=20 > Hi all, >=20 > we would like to make you aware of a workshop on Smart Object Security = on the 23rd March 2012 in Paris (attached to the IETF meeting). >=20 > We are seeking input from participants to share their thoughts about = the ability to utilize existing and widely deployed security mechanisms = for smart objects. >=20 > In particular, we are interested to hear about: > =95 What techniques for issuing credentials have been deployed? > =95 What extensions are useful to make existing security = protocols more suitable for smart objects? > =95 What type of credentials are frequently used? > =95 What experience has been gained when implementing and = deploying application layer, transport layer, network layer, and link = layer security mechanisms (or a mixture of all of them)? > =95 How can =93clever=94 implementations make security protocols = a better fit for constrained devices? > =95 Are there lessons we can learn from existing deployments? >=20 > More workshop details can be found on the webpage of our host: > http://www.lix.polytechnique.fr/hipercom/SmartObjectSecurity/ >=20 > If you plan to participate at the workshop please drop us a message = (with a short description of what you are planning to contribute) and we = can give you an early notice regarding your participation.=20 >=20 > Greetings > The Workshop Organizers >=20 From asanso@adobe.com Thu Jan 19 09:06:10 2012 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 631B821F86C6 for ; Thu, 19 Jan 2012 09:06:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 qmNPPXx70xzW for ; Thu, 19 Jan 2012 09:06:09 -0800 (PST) Received: from exprod6og117.obsmtp.com (exprod6og117.obsmtp.com [64.18.1.39]) by ietfa.amsl.com (Postfix) with ESMTP id 48C4921F86C1 for ; Thu, 19 Jan 2012 09:06:08 -0800 (PST) Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob117.postini.com ([64.18.5.12]) with SMTP ID DSNKTxhNc7hHEsA8Jk2rSLhIvs/+Cszqkxy/@postini.com; Thu, 19 Jan 2012 09:06:09 PST Received: from inner-relay-1.corp.adobe.com (inner-relay-1.adobe.com [153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id q0JH5r2U011664; Thu, 19 Jan 2012 09:05:54 -0800 (PST) Received: from nacas01.corp.adobe.com (nacas01.corp.adobe.com [10.8.189.99]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id q0JH5rMM004553; Thu, 19 Jan 2012 09:05:53 -0800 (PST) Received: from eurcas01.eur.adobe.com (10.128.4.27) by nacas01.corp.adobe.com (10.8.189.99) with Microsoft SMTP Server (TLS) id 8.3.192.1; Thu, 19 Jan 2012 09:05:53 -0800 Received: from eurmbx01.eur.adobe.com ([10.128.4.32]) by eurcas01.eur.adobe.com ([10.128.4.27]) with mapi; Thu, 19 Jan 2012 17:05:52 +0000 From: Antonio Sanso To: Eran Hammer Date: Thu, 19 Jan 2012 17:05:51 +0000 Thread-Topic: Error code for access token request Thread-Index: AczWzJk/mzsZWxKHS+ierrXjVwqRaA== Message-ID: <966C829C-AD86-428C-984A-C5A806ECB399@adobe.com> References: <4A1DD0C1-77F2-4824-973A-25F225D94F93@adobe.com> <90C41DD21FB7C64BB94121FBBC2E723453A72D0CF5@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453A72D0CF5@P3PW5EX1MB01.EX1.SECURESERVER.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_966C829CAD86428C984AC5A806ECB399adobecom_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Error code for access token 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, 19 Jan 2012 17:06:10 -0000 --_000_966C829CAD86428C984AC5A806ECB399adobecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Eran, thanks a lot for your response. As long as I understood from [1] though the error parameter is mandatory error REQUIRED. A single error code from the following: Which one is appropriate in case of server error? I cannot see any that wou= ld suite... Thanks in advance Antonio [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-22#section-5.2 On Jan 9, 2012, at 5:11 PM, Eran Hammer wrote: Just return HTTP 5xx. We needed the special error code because of the redir= ection flow. EHL From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Antonio Sanso Sent: Friday, December 30, 2011 10:22 AM To: OAuth WG Subject: [OAUTH-WG] Error code for access token request Hi *, Error response for Authorization Request defines some kind of server error = code response: server_error The authorization server encountered an unexpected condition which prevented it from fulfilling the request. as in [0]. I was wondering if would be possible/useful having same for error code for = access token request [1] WDYT? Regards Antonio [0] http://tools.ietf.org/html/draft-ietf-oauth-v2-22#section-4.1.2.1 [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-22#section-5.2 --_000_966C829CAD86428C984AC5A806ECB399adobecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Eran,

thanks a lot for your response.
As l= ong as I understood from [1] though the error parameter is mandatory
<= div>


<= div>
On Jan 9, 2012, at 5:11 PM, Eran Hammer wrote:

Just return HTTP 5xx. We needed the special error code because of th= e redirection flow.
 
EHL
 
=
From= : o= auth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] = ;On Behalf Of <= /b>Antonio Sanso
Sent: = ;Friday, December 30, 2011 10:22 AM
To: OAuth WG
Subject: [OAUTH-WG] Error code for access token r= equest
 
Hi *,
 
Error response for A= uthorization Request defines some kind of server error code response:<= /o:p>
 
<=
span style=3D"font-size: 12pt; ">server_error
     =
          The authorization se=
rver encountered an unexpected
       &nb=
sp;       condition which prevented it from f=
ulfilling the request.
 
as in [0=
]. 
I was wondering if wou=
ld be possible/useful having same for error code for access token request [=
1] 
WDYT?
 
Regards
 
Antonio
 =

 
<= pre style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; m= argin-left: 0in; font-size: 10pt; font-family: 'Courier New'; page-break-be= fore: always; ">[0] http://tools.ietf.org/html/draft-ietf-oa= uth-v2-22#section-4.1.2.1

= --_000_966C829CAD86428C984AC5A806ECB399adobecom_-- From jricher@mitre.org Thu Jan 19 09:50:49 2012 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 84C7521F86C6 for ; Thu, 19 Jan 2012 09:50:49 -0800 (PST) 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 RDRvkGfJrEYl for ; Thu, 19 Jan 2012 09:50:48 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7CFA621F854C for ; Thu, 19 Jan 2012 09:50:48 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D74FA21B053B for ; Thu, 19 Jan 2012 12:50:47 -0500 (EST) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id B61CA21B1534 for ; Thu, 19 Jan 2012 12:50:47 -0500 (EST) Received: from [129.83.50.12] (129.83.31.51) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.1.339.1; Thu, 19 Jan 2012 12:50:47 -0500 Message-ID: <4F1857BE.4090803@mitre.org> Date: Thu, 19 Jan 2012 12:49:50 -0500 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: References: <90C41DD21FB7C64BB94121FBBC2E723453A754C549@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4F157659.7050701@gmail.com> <1451834425-1326818330-cardhu_decombobulator_blackberry.rim.net-253428785-@b4.c11.bise7.blackberry> <4F15A655.4060404@gmail.com>, <2fc6806a-8a15-4b97-87f2-3c0c0cbd3623@email.android.com> <1326833912.76041.YahooMailNeo@web31813.mail.mud.yahoo.com> <4F16CFAB.5010506@gmail.com> In-Reply-To: <4F16CFAB.5010506@gmail.com> Content-Type: multipart/alternative; boundary="------------080501090004090607000206" X-Originating-IP: [129.83.31.51] Subject: Re: [OAUTH-WG] Access Token Response without expires_in 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, 19 Jan 2012 17:50:49 -0000 --------------080501090004090607000206 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit Precisely, and without a strong consensus of use in practice today, getting the semantics right around a new parameter (even if optional) doesn't make sense this late in the game. The information in the token response is easily extensible by other documents, and it should go there if people really want it to go there. -- Justin On 01/18/2012 08:56 AM, Paul Madsen wrote: > which argues for expressing both explicitly > > On 1/17/12 3:58 PM, William Mills wrote: >> >> One use tokens can also expire before they are used. "You have 5 >> minutes to do this once." >> >> ------------------------------------------------------------------------ >> *From:* Torsten Lodderstedt [torsten@lodderstedt.net] >> *Sent:* Tuesday, January 17, 2012 12:26 PM >> *To:* Paul Madsen >> *Cc:* oauth-bounces@ietf.org; Richer, Justin P.; OAuth WG >> *Subject:* Re: AW: Re: [OAUTH-WG] Access Token Response without >> expires_in >> >> Hi Paul, >> >> that's not what I meant. The Client should know which tokens should >> be one time usage based on the API description. The authz server must >> not return expires_in because this would not make any sense in this case. >> >> regards, >> Torsten >> >> >> >> >> Paul Madsen schrieb: >> >> Hi Torsten, yes the use case in question is payment-based as well. >> >> Your suggestion for the client to infer one-time usage from a >> missing expires_in contradicts the general consensus of this >> thread does it not? >> >> paul >> >> On 1/17/12 11:38 AM, torsten@lodderstedt.net >> wrote: >>> Hi, >>> >>> isn't one-time semantics typically associated with certain requests on certain resources/resource types. I therefore would assume the client to know which tokens to use one-time only. The authz server should not return an expires_in paramter. We for example use one time access tokens for payment transactions. >>> >>> What would such an extension specify? >>> >>> regards, >>> Torsten. >>> Gesendet mit BlackBerry® Webmail von Telekom Deutschland >>> >>> -----Original Message----- >>> From: Paul Madsen >>> Sender:oauth-bounces@ietf.org >>> Date: Tue, 17 Jan 2012 08:23:37 >>> To: Richer, Justin P. >>> Cc: OAuth WG >>> Subject: Re: [OAUTH-WG] Access Token Response without expires_in >>> >>> _______________________________________________ >>> 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 --------------080501090004090607000206 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Precisely, and without a strong consensus of use in practice today, getting the semantics right around a new parameter (even if optional) doesn't make sense this late in the game. The information in the token response is easily extensible by other documents, and it should go there if people really want it to go there.

 -- Justin

On 01/18/2012 08:56 AM, Paul Madsen wrote:
which argues for expressing both explicitly

On 1/17/12 3:58 PM, William Mills wrote:

One use tokens can also expire before they are used.  "You have 5 minutes to do this once."

From: Torsten Lodderstedt [torsten@lodderstedt.net]
Sent: Tuesday, January 17, 2012 12:26 PM
To: Paul Madsen
Cc: oauth-bounces@ietf.org; Richer, Justin P.; OAuth WG
Subject: Re: AW: Re: [OAUTH-WG] Access Token Response without expires_in

Hi Paul,

that's not what I meant. The Client should know which tokens should be one time usage based on the API description. The authz server must not return expires_in because this would not make any sense in this case.

regards,
Torsten




Paul Madsen <paul.madsen@gmail.com> schrieb:
Hi Torsten, yes the use case in question is payment-based as well.

Your suggestion for the client to infer one-time usage from a missing expires_in contradicts the general consensus of this thread does it not?

paul

On 1/17/12 11:38 AM, torsten@lodderstedt.net wrote: 
Hi,

isn't one-time semantics typically associated with certain requests on certain resources/resource types. I therefore would assume the client to know which tokens to use one-time only. The authz server should not return an expires_in paramter. We for example use one time access tokens for payment transactions.  

What would such an extension specify?

regards,
Torsten.
Gesendet mit BlackBerry® Webmail von Telekom Deutschland  

-----Original Message-----
From: Paul Madsen <paul.madsen@gmail.com>
Sender: oauth-bounces@ietf.org
Date: Tue, 17 Jan 2012 08:23:37 
To: Richer, Justin P.<jricher@mitre.org>
Cc: OAuth WG<oauth@ietf.org>
Subject: Re: [OAUTH-WG] Access Token Response without expires_in

_______________________________________________
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

--------------080501090004090607000206-- From eran@hueniverse.com Thu Jan 19 14:59:46 2012 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 685EA21F85DF for ; Thu, 19 Jan 2012 14:59:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[AWL=-1.159, BAYES_00=-2.599, FRT_ADOBE2=2.455, 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 iJT8EHLtLs7m for ; Thu, 19 Jan 2012 14:59:45 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 925B321F85D0 for ; Thu, 19 Jan 2012 14:59:45 -0800 (PST) Received: (qmail 26321 invoked from network); 19 Jan 2012 22:59:42 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.46) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 19 Jan 2012 22:59:41 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT004.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Thu, 19 Jan 2012 15:59:20 -0700 From: Eran Hammer To: Antonio Sanso Date: Thu, 19 Jan 2012 15:59:11 -0700 Thread-Topic: Error code for access token request Thread-Index: AczWzJk/mzsZWxKHS+ierrXjVwqRaAAMUo5w Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453AAB963B1@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4A1DD0C1-77F2-4824-973A-25F225D94F93@adobe.com> <90C41DD21FB7C64BB94121FBBC2E723453A72D0CF5@P3PW5EX1MB01.EX1.SECURESERVER.NET> <966C829C-AD86-428C-984A-C5A806ECB399@adobe.com> In-Reply-To: <966C829C-AD86-428C-984A-C5A806ECB399@adobe.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_90C41DD21FB7C64BB94121FBBC2E723453AAB963B1P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Error code for access token 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, 19 Jan 2012 22:59:46 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723453AAB963B1P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In the case of section 5, because this is a direct interaction with the cli= ent, the server should issue a 5xx response instead. EHL From: Antonio Sanso [mailto:asanso@adobe.com] Sent: Thursday, January 19, 2012 9:06 AM To: Eran Hammer Cc: OAuth WG Subject: Re: Error code for access token request Hi Eran, thanks a lot for your response. As long as I understood from [1] though the error parameter is mandatory error REQUIRED. A single error code from the following: Which one is appropriate in case of server error? I cannot see any that wou= ld suite... Thanks in advance Antonio [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-22#section-5.2 On Jan 9, 2012, at 5:11 PM, Eran Hammer wrote: Just return HTTP 5xx. We needed the special error code because of the redir= ection flow. EHL From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Anton= io Sanso Sent: Friday, December 30, 2011 10:22 AM To: OAuth WG Subject: [OAUTH-WG] Error code for access token request Hi *, Error response for Authorization Request defines some kind of server error = code response: server_error The authorization server encountered an unexpected condition which prevented it from fulfilling the request. as in [0]. I was wondering if would be possible/useful having same for error code for = access token request [1] WDYT? Regards Antonio [0] http://tools.ietf.org/html/draft-ietf-oauth-v2-22#section-4.1.2.1 [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-22#section-5.2 --_000_90C41DD21FB7C64BB94121FBBC2E723453AAB963B1P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In the ca= se of section 5, because this is a direct interaction with the client, the = server should issue a 5xx response instead.

 

EHL

 

 

From: Antonio Sanso [mailto:asanso@adobe.com]=
Sent: Thursday, January 19, 2012 9:06 AM
To: Eran Ham= mer
Cc: OAuth WG
Subject: Re: Error code for access tok= en request

 = ;

Hi Eran,

 

thanks a lot for= your response.

As long as I = understood from [1] though the error parameter is mandatory

<= /div>

 

error
         REQUIR=
ED.  A single error code from the following:

Which one is appropriate in case of server error? I cannot= see any that would suite...

=  

Thanks in advance=

 

<= p class=3DMsoNormal>Antonio

 

[1] http://t= ools.ietf.org/html/draft-ietf-oauth-v2-22#section-5.2

 

On Jan 9, 2012, at 5:11 PM, Eran Hammer wrote:<= /p>



Just return HTTP 5xx. We needed the special error code= because of the redirection flow.

 

EHL

 

From: <= /span>oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Antonio Sanso
Sent: Friday, December 30, 2011 10:22 AM
To: OAuth WG
Subject: [OAUTH-WG] Error code fo= r access token request

 

Hi *,

 

=

Error response for Authorization Reque= st defines some kind of server error code response:

 

serve= r_error
       &nbs=
p;       The authorization server encountered=
 an unexpected
      &nb=
sp;        condition which prevented it =
from fulfilling the request.
 
as in [0].=

 
=
I was wondering if would be possible/useful having same for error code for =
access token request [1]
 
WDYT?
 
Regards
 
Antonio
<= /div>
 
 

 

<= /body>= --_000_90C41DD21FB7C64BB94121FBBC2E723453AAB963B1P3PW5EX1MB01E_-- From eran@hueniverse.com Fri Jan 20 11:48:52 2012 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 9D93421F85C2 for ; Fri, 20 Jan 2012 11:48:52 -0800 (PST) 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=-0.178, BAYES_00=-2.599, J_CHICKENPOX_36=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 7-bGBs6Jb8KQ for ; Fri, 20 Jan 2012 11:48:52 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id D91B021F859E for ; Fri, 20 Jan 2012 11:48:51 -0800 (PST) Received: (qmail 4934 invoked from network); 20 Jan 2012 19:48:41 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 20 Jan 2012 19:48:41 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Fri, 20 Jan 2012 12:48:34 -0700 From: Eran Hammer To: Roger Crew , "oauth@ietf.org" Date: Fri, 20 Jan 2012 12:48:21 -0700 Thread-Topic: [OAUTH-WG] error codes in 4.1.2.1 and 4.2.2.1 and extension response types (8.4) Thread-Index: AcyigZl8UoAtC4IwQj6dNGyUoskplQ1KOl7w Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453AAB964C0@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <20160.24172.942808.563672@hagen.valhalla> In-Reply-To: <20160.24172.942808.563672@hagen.valhalla> 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] error codes in 4.1.2.1 and 4.2.2.1 and extension response types (8.4) 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, 20 Jan 2012 19:48:52 -0000 Thanks. > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Roger Crew > Sent: Sunday, November 13, 2011 4:19 PM > (1) 4.1.2.1, and 4.2.2.1 both say that in the case that client_id is > provided and invalid/unknown, the auth server MUST NOT > automatically redirect. >=20 > However, if the client_id is MISSING, that clause of > 4.1.2.1/4.2.2.1 does not apply, and thence this becomes a > malformed request (i.e., a required parameter is missing) > which then results in an error=3D'invalid_request' redirection. >=20 > Which looks like a mistake to me, because in that situation > what reason do we have to be trusting redirect_uri? In practice, a missing client identifier should also trigger an invalid red= irect URI as the server is unable to validate it. But I agree this doesn't = read correctly. Changed the text in both places to read: If the request fails due to a missing, invalid, or mismatchin= g redirection URI, or if the client identifier is missing or invalid, the authorizatio= n server SHOULD inform the resource owner of the error, and MUST NOT automatically r= edirect the user-agent to the invalid redirection URI. This minor tweak does not change the intended behavior described in -22. > (2) If the response_type is provided but unknown, is that an > 'invalid_request' (since this is clearly an "unsupported > parameter value") or is it an 'unsupported_response_type'? >=20 > Seems to me it should be the latter. If so, then... >=20 > Given that for ALL currently defined parameters to authorization > endpoint requests, there are already provisions for what happens > if the value is provided but invalid/unsupported/etc, i.e., >=20 > bad client_id =3D> do not redirect > bad redirect_uri =3D> do not redirect > bad response_type =3D> redirect error=3D'unsupported_response_type= ' > bad scope =3D> redirect error=3D'invalid_scope' > bad state =3D> undetectable from the server side >=20 > should the description for 'invalid_request' even be referring to > "unsupported values" at all? >=20 > A couple of alternatives (again these are for 4.1.2.1/4.2.2.1): >=20 > invalid_request > a required *extension* parameter is missing > or has an unsupported value, or the request is > otherwise malformed. >=20 > invalid_request > the request is malformed in some manner not covered by any > of the other error codes defined for this response type >=20 > Either of these would make clear that 'unsupported_response_type' > is indeed the error code for the case of a > provided-but-unrecognized response_type. >=20 > Section 5.2 has the same problem w.r.t. 'unsupported_grant_type' Changed the definition of invalid_request to: The request is missing a required parameter, includes= an invalid parameter value, or is otherwise malformed. I rather not introduce new logic such as define invalid_request as a catch = all. > (3) If 'server_error' and 'temporarily_unavailable' are intended to > correspond to HTTP status codes 500 and 503, it might be good to > say so explicitly, e.g., >=20 > The authorization server SHOULD, where possible, use these > redirection error responses in preference to sending the > corresponding status=3D(500|503) HTTP response in situations where > the latter would otherwise be appropriate. >=20 > Admittedly, there's no way an implementation is going to catch all > of these, but I'm assuming the intent is to catch as many as > possible? The two error codes are meant to correspond to the HTTP 5xx codes mentioned= but adding a direct reference would be confusing and import error handling= behavior from HTTP which we did not want to do (e.g. we do not specify the= recommended client reaction to any of the other error codes). No change. > (4) The lists of error codes in 4.1.2.1 and 4.2.2.1 are essentially > identical. I believe these can be merged without any loss of > clarity. >=20 > (... As a matter of general principle, I'm not a huge fan of > having to chase down swaths of cut&pasted text and then having to > use 'diff' to figure out whether/how they are different. Better > to combine the common stuff in a single place, use a cross > reference and highlight the differences. And I absolutely do not > mind following cross-references...) >=20 > In this case, the ONLY place where there's ANY variance at all is > in the descriptions of 'unauthorized_client' and > 'unsupported_response_type'. >=20 > I figure either of the following works: >=20 > unauthorized_client > The client is not authorized to use any of the supported > authorization grant types implied by the requested > response_type. >=20 > unauthorized_client > The client is not authorized to use this response_type. >=20 > the latter having the advantage that we don't then get bogged > down in the question of how response_types and grant_types relate > to each other (see (5) below). >=20 > And similarly for 'unsupported_response_type', viz >=20 > unsupported_response_type > The authorization server does not support any of the > authorization grant types implied by the requested response > type. >=20 > unsupported_response_type > The authorization server does not support this response > type. >=20 > at which point you can replace 4.2.2.1 with a single sentence > referring to 4.1.2.1. We had versions of this consolidation in past editions and the WG preferenc= e has been to reduce references as much as possible. No change. > (5) I am assuming that each authorization endpoint response_type is > NOT necessarily unique to a particular authorization grant type. > It would be helpful to state this explicitly (probably in 8.4) so > that implementers can plan accordingly. >=20 > And if this IS intended otherwise (i.e., that every response > type MUST imply a particular grant type, as is the case for the > current spec so long as no new response types are ever defined), > then that really should be stated somewhere in 8.4. >=20 > The reason I assume not is that this seems a straightforward (to > me, at least) use of response_type=3D"token code", i.e., to allow > the server to respond EITHER as per 4.1.2 or 4.2.2 as it sees fit > (but evidently WG members are not agreeing on whether this > response_type is needed, hence its absence from the current spec > other than as a remark in 8.4). I am not sure what you mean by this but the intention is that the meaning a= nd handling of combinations is out of scope. For example, 'token code' can = mean both or one of the two, and this is left to the spec defining such com= bination. The only requirement is that once 'token code' is registered, 'co= de token' cannot, and both mean the same (whatever that is). EHL From eran@hueniverse.com Fri Jan 20 12:18:23 2012 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 A87D721F869A for ; Fri, 20 Jan 2012 12:18:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130, 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 zpYn7lQgHJl0 for ; Fri, 20 Jan 2012 12:18:23 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 22F6421F8624 for ; Fri, 20 Jan 2012 12:18:23 -0800 (PST) Received: (qmail 27790 invoked from network); 20 Jan 2012 20:18:22 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 20 Jan 2012 20:18:22 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Fri, 20 Jan 2012 13:18:17 -0700 From: Eran Hammer To: Barry Leiba , oauth WG Date: Fri, 20 Jan 2012 13:18:07 -0700 Thread-Topic: [OAUTH-WG] TLS version requirements in OAuth 2.0 base Thread-Index: Acy9tqAcl+ReDOhSTvOl9f85z8s9vQZ+cmfA Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453AAB964D3@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] TLS version requirements in OAuth 2.0 base 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, 20 Jan 2012 20:18:23 -0000 Added to section 1: TLS Version Whenever TLS is required by this specification, the appropriate v= ersion (or versions) of TLS will vary over time, based on the widespread deployment and k= nown security vulnerabilities. At the time of this writing, TLS version 1.2 is the most recent version, but has a very limited deployment bas= e and might not be readily available for implementation. TLS version 1.0 is the most widely deployed version, and will provide the broadest inter= operability. Implementations MAY also support additional transport-layer mecha= nisms that meet their security requirements. And referenced this section when TLS requirements were previously defined. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Barry Leiba > Sent: Sunday, December 18, 2011 10:56 AM > To: oauth WG > Subject: Re: [OAUTH-WG] TLS version requirements in OAuth 2.0 base >=20 > To close out this issue: > There's disagreement about whether this proposed text is "necessary", but > no one thinks it's *bad*, and I see consensus to use it. Eran, please ma= ke > the following change in two places in the base document: >=20 > > OLD > > The authorization server MUST support TLS 1.0 ([RFC2246]), SHOULD > > support TLS 1.2 ([RFC5246]) and its future replacements, and MAY > > support additional transport-layer mechanisms meeting its security > > requirements. >=20 > > NEW > > The authorization server MUST implement TLS. =A0Which version(s) ought > > to be implemented will vary over time, and depend on the widespread > > deployment and known security vulnerabilities at the time of > > implementation. =A0At the time of this writing, TLS version > > 1.2 [RFC5246] is the most recent version, but has very limited actual > > deployment, and might not be readily available in implementation > > toolkits. =A0TLS version 1.0 [RFC2246] is the most widely deployed > > version, and will give the broadest interoperability. > > > > Servers MAY also implement additional transport-layer mechanisms that > > meet their security requirements. >=20 > Barry, as chair > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Fri Jan 20 12:35:00 2012 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 9D11721F869E for ; Fri, 20 Jan 2012 12:35:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.124, 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 pFy6bzEXfPUr for ; Fri, 20 Jan 2012 12:34:59 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 3A8B421F85F3 for ; Fri, 20 Jan 2012 12:34:59 -0800 (PST) Received: (qmail 9048 invoked from network); 20 Jan 2012 20:33:40 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 20 Jan 2012 20:33:39 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Fri, 20 Jan 2012 13:33:08 -0700 From: Eran Hammer To: William Mills , "oauth@ietf.org" Date: Fri, 20 Jan 2012 13:32:58 -0700 Thread-Topic: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification Thread-Index: AczQNrs9YUEdM24kQR+6Iywcjm5WbwHe+x9A Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453AAB964E7@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <6.2.5.6.2.20120109070921.0aec8d00@resistor.net> <6.2.5.6.2.20120109153323.0ab3bf80@resistor.net> <1326156786.88572.YahooMailNeo@web31812.mail.mud.yahoo.com> <1326160314.71861.YahooMailNeo@web31806.mail.mud.yahoo.com> <1326162276.40306.YahooMailNeo@web31811.mail.mud.yahoo.com> <1326215997.44445.YahooMailNeo@web31816.mail.mud.yahoo.com> <6.2.5.6.2.20120110104038.099f1ba8@resistor.net> <90C41DD21FB7C64BB94121FBBC2E723453A72D0F24@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1326240141.98332.YahooMailNeo@web31808.mail.mud.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E723453A72D0F60@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1326268674.20557.YahooMailNeo@web31807.mail.mud.yahoo.com> In-Reply-To: <1326268674.20557.YahooMailNeo@web31807.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_90C41DD21FB7C64BB94121FBBC2E723453AAB964E7P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification 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, 20 Jan 2012 20:35:00 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723453AAB964E7P3PW5EX1MB01E_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TmV3IHRleHQgYWRkZWQgdG8gQWNjZXNzIFRva2VuIFNjb3BlIHNlY3Rpb246DQoNCiAgICAgICAg ICBJZiB0aGUgY2xpZW50IG9taXRzIHRoZSBzY29wZSBwYXJhbWV0ZXIgd2hlbiByZXF1ZXN0aW5n IGF1dGhvcml6YXRpb24sIHRoZSBhdXRob3JpemF0aW9uDQogICAgICAgICAgc2VydmVyIE1VU1Qg cHJvY2VzcyB0aGUgcmVxdWVzdCB1c2luZyBhIHByZS1kZWZpbmVkIGRlZmF1bHQgdmFsdWUsIG9y IGZhaWwgdGhlIHJlcXVlc3QNCiAgICAgICAgICBpbmRpY2F0aW5nIGFuIGludmFsaWQgc2NvcGUu IFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBTSE9VTEQgZG9jdW1lbnQgaXRzIHNjb3BlDQogICAg ICAgICAgcmVxdWlyZW1lbnRzIGFuZCBkZWZhdWx0IHZhbHVlIChpZiBkZWZpbmVkKS4NCg0KDQpF SEwNCg0KRnJvbTogV2lsbGlhbSBNaWxscyBbbWFpbHRvOndtaWxsc0B5YWhvby1pbmMuY29tXQ0K U2VudDogVHVlc2RheSwgSmFudWFyeSAxMCwgMjAxMiAxMTo1OCBQTQ0KVG86IEVyYW4gSGFtbWVy OyBvYXV0aEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gU2Vla2luZyBDbGFyaWZp Y2F0aW9uOiBQb3RlbnRpYWwgQW1iaWd1aXR5IGluIFNwZWNpZmljYXRpb24NCg0KIk51bGwgc3Ry aW5nIiwgImVtcHR5IHN0cmluZyIsIG9yICJzZXJ2ZXIgZGVmaW5lZCBkZWZhdWx0IHZhbHVlIiBh bGwgd29yay4gIERlZmF1bHQgc2NvcGUgZG9lc24ndCBkbyBpdCBmb3IgbWUuDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBFcmFuIEhhbW1lciA8ZXJhbkBodWVuaXZl cnNlLmNvbTxtYWlsdG86ZXJhbkBodWVuaXZlcnNlLmNvbT4+DQpUbzogV2lsbGlhbSBNaWxscyA8 d21pbGxzQHlhaG9vLWluYy5jb208bWFpbHRvOndtaWxsc0B5YWhvby1pbmMuY29tPj47ICJvYXV0 aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+IiA8b2F1dGhAaWV0Zi5vcmc8bWFpbHRv Om9hdXRoQGlldGYub3JnPj4NClNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMTAsIDIwMTIgNToyNCBQ TQ0KU3ViamVjdDogUkU6IFtPQVVUSC1XR10gU2Vla2luZyBDbGFyaWZpY2F0aW9uOiBQb3RlbnRp YWwgQW1iaWd1aXR5IGluIFNwZWNpZmljYXRpb24NCg0KSSBkb27igJl0IGxpa2Ug4oCYZW1wdHkg c2NvcGXigJkgYXMgaXQgaXMgdW5kZWZpbmVkLiBJIHByZWZlciDigJhkZWZhdWx0IHNjb3Bl4oCZ Lg0KDQpFSEwNCg0KRnJvbTogV2lsbGlhbSBNaWxscyBbbWFpbHRvOndtaWxsc0B5YWhvby1pbmMu Y29tXTxtYWlsdG86W21haWx0bzp3bWlsbHNAeWFob28taW5jLmNvbV0+DQpTZW50OiBUdWVzZGF5 LCBKYW51YXJ5IDEwLCAyMDEyIDQ6MDIgUE0NClRvOiBFcmFuIEhhbW1lcjsgb2F1dGhAaWV0Zi5v cmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gU2Vla2lu ZyBDbGFyaWZpY2F0aW9uOiBQb3RlbnRpYWwgQW1iaWd1aXR5IGluIFNwZWNpZmljYXRpb24NCg0K T24geW91ciAjMSwgSSBkb24ndCBhZ3JlZSB0aGF0IGFuIGVtcHR5IHNjb3BlIGlzIHVzZWxlc3Mu ICBUaGVyZSBhcmUgY29tcGFyYWJsZSBpbXBsZW1lbnRhdGlvbnMgdGhhdCB1c2UgYW4gZW1wdHkg c2NvcGUgdG8gYmUgYSB3aWxkY2FyZCBzY29wZS4gIEknZCBzYXksDQoNCiJUaGUgY2xpZW50IGNh biBNQVkgaW5jbHVkZSBvciBvbWl0IHRoZSBzY29wZSBwYXJhbWV0ZXIuIElmIG9taXR0ZWQsIHRo ZSBzZXJ2ZXIgbXVzdCBwcm9jZXNzIHRoZSByZXF1ZXN0IHVzaW5nIGFuIGVtcHR5IHNjb3BlIGFz IHRoZSBkZWZhdWx0LiAgVGhlIHNlcnZlciB0aGVuIHByb2Nlc3NlcyB0aGUgcmVxdWVzdCBlaXRo ZXIgaXNzdWluZyBhIGdyYW50IHdpdGggaXQncyBkZWZhdWx0IHNjb3BlIGFzIGRlZmluZWQgYnkg dGhlIHNlcnZlciBvciBmYWlsaW5nIHRoZSByZXF1ZXN0IGluZGljYXRpbmcgYW4gaW52YWxpZCBz Y29wZSByZXF1ZXN0ZWQuIg0KDQpUaGF0IGxhbmd1YWdlIGlzbid0IHF1aXRlIHJpZ2h0LCBidXQg SSB0aGluayBpdCdzIGNsZWFyLg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K RnJvbTogRXJhbiBIYW1tZXIgPGVyYW5AaHVlbml2ZXJzZS5jb208bWFpbHRvOmVyYW5AaHVlbml2 ZXJzZS5jb20+Pg0KVG86ICJvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+IiA8 b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4NClNlbnQ6IFR1ZXNkYXksIEph bnVhcnkgMTAsIDIwMTIgMToxNSBQTQ0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gU2Vla2luZyBD bGFyaWZpY2F0aW9uOiBQb3RlbnRpYWwgQW1iaWd1aXR5IGluIFNwZWNpZmljYXRpb24NCg0KSSBk b24ndCB0aGluayB0aGUgaXNzdWUgaGVyZSBpcyBhYm91dCB0aGUgc2NvcGUgdmFsdWUsIGJ1dCB3 aG8gZG9lcyB0aGUgT1BUSU9OQUwgZGVzaWduYXRpb24gYXBwbGllcyB0by4gSU9XLCBpcyBpdCBv cHRpb25hbCBmb3IgdGhlIHNlcnZlciB0byBzdXBwb3J0L3JlcXVpcmUgaXQsIG9yIGlzIGl0IG9w dGlvbmFsIGZvciB0aGUgY2xpZW50IHRvIGluY2x1ZGUgb3Igb21pdCBpdC4NCg0KVGhlIGludGVu dGlvbiB3YXMgdG8gbWFrZSBpdCBvcHRpb25hbCBmb3IgdGhlIGF1dGhvcml6YXRpb24gc2VydmVy IHRvIG1ha2UgYWxsIGRlY2lzaW9ucyBhYm91dCB0aGUgcGFyYW1ldGVyLCBpbmNsdWRpbmcgbWFr aW5nIGl0IHJlcXVpcmVkLiBCdXQgdGhlIHRleHQgaXMgY29uZnVzaW5nIHNpbmNlIHRoZSB0ZXh0 IGlzIGFpbWVkIGRpcmVjdGx5IGF0IHRoZSBjbGllbnQgd2hlbiBtYWtpbmcgdGhlIHJlcXVlc3Qu DQoNCldlIG5lZWQgdG8gY2xhcmlmeSB0aGlzIGFuZCB0aGUgb3B0aW9ucyBhcmU6DQoNCjEuIFRo ZSBjbGllbnQgY2FuIGRlY2lkZSBpZiB0aGV5IHdhbnQgdG8gaW5jbHVkZSBvciBvbWl0IHRoZSBz Y29wZSBwYXJhbWV0ZXIuIElmIG9taXR0ZWQsIHRoZSBzZXJ2ZXIgbXVzdCBwcm9jZXNzIHRoZSBy ZXF1ZXN0IHVzaW5nIHNvbWUgZG9jdW1lbnRlZCBkZWZhdWx0IHNjb3BlLiBUaGlzIGRlZmF1bHQg c2NvcGUgY2FuIGJlIGFuIGVtcHR5IHNjb3BlIHJlbmRlcmluZyB0aGUgdG9rZW4gdXNlbGVzcyBm b3IgYW55dGhpbmcgb3RoZXIgdGhhbiB2ZXJpZnlpbmcgdXNlciBhdXRoZW50aWNhdGlvbi4NCg0K Mi4gVGhlIHNlcnZlciBjYW4gZGVjbGFyZSBzY29wZSB0byBiZSBhIHJlcXVpcmVkIHBhcmFtZXRl ciBpbiB3aGljaCBjYXNlIHRoZSBjbGllbnQgbXVzdCBpbmNsdWRlIGl0IG9yIHRoZSByZXF1ZXN0 IHdpbGwgZmFpbC4gSW4gdGhpcyBjYXNlLCB3ZSBzaG91bGQgbWFrZSB0aGUgdGV4dCBjbGVhcmVy IHRoYXQgY2xpZW50cyB0byBmaW5kIG91dCBpZiB0aGUgcGFydGljdWxhciBzZXJ2ZXIgcmVxdWly ZXMgaXQuDQoNCiMxIGlzIGJldHRlciBmb3IgaW50ZXJvcGVyYWJpbGl0eSwgIzIgaXMgbW9yZSBp biB0aGUgc3Bpcml0IG9mIHRoZSBwYXJhbWV0ZXIgZGlzY3Vzc2lvbnMgc28gZmFyLg0KDQpFSEwN Cg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBvYXV0aC1ib3VuY2VzQGll dGYub3JnPG1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOm9hdXRoLWJvdW5j ZXNAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYNCj4g T2YgUGhpbCBIdW50DQo+IFNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMTAsIDIwMTIgMTE6MzMgQU0N Cj4gVG86IFNNDQo+IENjOiBvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+DQo+ IFN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFNlZWtpbmcgQ2xhcmlmaWNhdGlvbjogUG90ZW50aWFs IEFtYmlndWl0eSBpbg0KPiBTcGVjaWZpY2F0aW9uDQo+DQo+IFRoZSB1bmRlcmx5aW5nIGlzc3Vl IGlzIHRoYXQgdGhlcmUgd2FzIGEgZGVjaXNpb24gbm90IHRvIGluIGFueSB3YXkNCj4gc3RhbmRh cmRpemUgdmFsdWVzIGZvciBzY29wZS4NCj4NCj4gSSBhZ3JlZWQgdGhpcyB3YXMgcmVhc29uYWJs ZSBzaW5jZSB0aGUgdW5kZXJseWluZyByZXNvdXJjZSBBUElzIGFyZSBsaWtlbHkgdG8NCj4gYmUg dmVyeSBzcGVjaWZpYyByZXF1aXJpbmcgc29tZSBkZWdyZWUgb2YgcHJpb3Iga25vd2xlZGdlIGJ5 IHRoZSBjbGllbnQgYXBwDQo+IGRldmVsb3Blci4gVGh1cyB0aGUgcmVzb3VyY2Ugc2VydmVyIE9B dXRoIGluZnJhc3RydWN0dXJlIGlzIGZyZWUgdG8gZGVjaWRlDQo+IHdoYXQgYXJlIGFuZCBhcmUg bm90IGFjY2VwdGFibGUgdmFsdWVzIGluY2x1ZGluZyBtaXNzaW5nIG9yIG51bGwgdmFsdWVzIGZv cg0KPiBzY29wZS4NCj4NCj4gSSB0aGluayB0aGUgc3BlY2lmaWNhdGlvbiBpcyBhY2NlcHRhYmxl IGFzIGl0IGlzLg0KPg0KPiBJIG5vdGUgdGhhdCBvdGhlciBzcGVjaWZpY2F0aW9ucyB0aGF0IGxh eWVyIG9uIHRvcCBvZiBPQXV0aDIgc3VjaCBhcyBPcGVuSUQNCj4gQ29ubmVjdCBtYXkgY2hvb3Nl IHRvIHN0cmljdGx5IGRlZmluZSBhY2NlcHRhYmxlIHZhbHVlcyBmb3Igc2NvcGUuIFRoaXMgdHlw ZQ0KPiBvZiBsYXllcmluZyB3b3JrcyB3ZWxsIGluIG15IG9waW5pb24uDQo+DQo+IFBoaWwNCj4N Cj4gQGluZGVwZW5kZW50aWQNCj4gd3d3LmluZGVwZW5kZW50aWQuY29tPGh0dHA6Ly93d3cuaW5k ZXBlbmRlbnRpZC5jb20+DQo+IHBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRA b3JhY2xlLmNvbT4NCj4NCj4NCj4NCj4NCj4NCj4gT24gMjAxMi0wMS0xMCwgYXQgMTA6NTYgQU0s IFNNIHdyb3RlOg0KPg0KPiA+IEF0IDA5OjE5IDEwLTAxLTIwMTIsIFdpbGxpYW0gTWlsbHMgd3Jv dGU6DQo+ID4+IFRoYXQgZG9lcyBjbGVhciBpdCB1cCEgIElmIHRoZSBpbXBsZW1lbnRhdGlvbiBy ZXR1cm5zIGEgcHJvcGVyIGVycm9yIHdoZW4NCj4gdGhlIHNjb3BlIGlzIG9taXR0ZWQgdGhlbiBp dCB3aWxsIGJlIGluIGNvbmZvcm1hbmNlLiAgU2VuZGluZyBhbiBlcnJvciByZXN1bHQNCj4gZm9y IHRoZSBlbXB0eSBzY29wZSBpcyB2YWxpZC4NCj4gPg0KPiA+IFllcy4NCj4gPg0KPiA+IEl0IGlz IG5vdCBwb3NzaWJsZSB0byBnZXQgYSBjbGVhciB2aWV3IG9mIHRoZSBzcGVjcyBpZiB0aGUgZGlz Y3Vzc2lvbiBhYm91dA0KPiAiYW1iaWd1aXR5IiByZWxpZXMgb24gdGhlIG1lYW5pbmcgb2YgdGhl IHdvcmQgIk9QVElPTkFMIiBvbmx5LiAgSWYgdGhlcmUgaXMgYQ0KPiBwcm9ibGVtLCB0aGVuIGNs YXJpZnlpbmcgdGV4dCBjb3VsZCBiZSB1c2VkIHRvIGZpeCBpdCBpbnN0ZWFkIG9mIGNoYW5naW5n IHRoZQ0KPiByZXF1aXJlbWVudHMuDQo+ID4NCj4gPiBSZWdhcmRzLA0KPiA+IC1zbQ0KPiA+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gT0F1dGgg bWFpbGluZyBsaXN0DQo+ID4gT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0K PiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCj4NCj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gT0F1dGggbWFp bGluZyBsaXN0DQo+IE9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1 dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQo= --_000_90C41DD21FB7C64BB94121FBBC2E723453AAB964E7P3PW5EX1MB01E_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PCEtLVtpZiAhbXNvXT48c3R5 bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7YmVoYXZpb3I6dXJs KCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KLnNo YXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwhW2VuZGlmXS0tPjxz dHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIg MTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7 DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxp bmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQg Q2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpwLnlpdjE3MjI2 ODk5NTBtc29hY2V0YXRlLCBsaS55aXYxNzIyNjg5OTUwbXNvYWNldGF0ZSwgZGl2LnlpdjE3MjI2 ODk5NTBtc29hY2V0YXRlDQoJe21zby1zdHlsZS1uYW1lOnlpdjE3MjI2ODk5NTBtc29hY2V0YXRl Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4w cHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpwLnlpdjE3MjI2 ODk5NTBtc29ub3JtYWwsIGxpLnlpdjE3MjI2ODk5NTBtc29ub3JtYWwsIGRpdi55aXYxNzIyNjg5 OTUwbXNvbm9ybWFsDQoJe21zby1zdHlsZS1uYW1lOnlpdjE3MjI2ODk5NTBtc29ub3JtYWw7DQoJ bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsN Cglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnAueWl2MTcyMjY4OTk1 MG1zb2NocGRlZmF1bHQsIGxpLnlpdjE3MjI2ODk5NTBtc29jaHBkZWZhdWx0LCBkaXYueWl2MTcy MjY4OTk1MG1zb2NocGRlZmF1bHQNCgl7bXNvLXN0eWxlLW5hbWU6eWl2MTcyMjY4OTk1MG1zb2No cGRlZmF1bHQ7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsN Cgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1z aXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNw YW4ueWl2MTcyMjY4OTk1MG1zb2h5cGVybGluaw0KCXttc28tc3R5bGUtbmFtZTp5aXYxNzIyNjg5 OTUwbXNvaHlwZXJsaW5rO30NCnNwYW4ueWl2MTcyMjY4OTk1MG1zb2h5cGVybGlua2ZvbGxvd2Vk DQoJe21zby1zdHlsZS1uYW1lOnlpdjE3MjI2ODk5NTBtc29oeXBlcmxpbmtmb2xsb3dlZDt9DQpz cGFuLnlpdjE3MjI2ODk5NTBlbWFpbHN0eWxlMTcNCgl7bXNvLXN0eWxlLW5hbWU6eWl2MTcyMjY4 OTk1MGVtYWlsc3R5bGUxNzt9DQpzcGFuLnlpdjE3MjI2ODk5NTBiYWxsb29udGV4dGNoYXINCgl7 bXNvLXN0eWxlLW5hbWU6eWl2MTcyMjY4OTk1MGJhbGxvb250ZXh0Y2hhcjt9DQpwLnlpdjE3MjI2 ODk5NTBtc29ub3JtYWwxLCBsaS55aXYxNzIyNjg5OTUwbXNvbm9ybWFsMSwgZGl2LnlpdjE3MjI2 ODk5NTBtc29ub3JtYWwxDQoJe21zby1zdHlsZS1uYW1lOnlpdjE3MjI2ODk5NTBtc29ub3JtYWwx Ow0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4w cHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLnlpdjE3 MjI2ODk5NTBtc29oeXBlcmxpbmsxDQoJe21zby1zdHlsZS1uYW1lOnlpdjE3MjI2ODk5NTBtc29o eXBlcmxpbmsxOw0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLnlpdjE3MjI2ODk5NTBtc29oeXBlcmxpbmtmb2xsb3dlZDENCgl7bXNvLXN0eWxlLW5hbWU6 eWl2MTcyMjY4OTk1MG1zb2h5cGVybGlua2ZvbGxvd2VkMTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLnlpdjE3MjI2ODk5NTBtc29hY2V0YXRlMSwgbGku eWl2MTcyMjY4OTk1MG1zb2FjZXRhdGUxLCBkaXYueWl2MTcyMjY4OTk1MG1zb2FjZXRhdGUxDQoJ e21zby1zdHlsZS1uYW1lOnlpdjE3MjI2ODk5NTBtc29hY2V0YXRlMTsNCgltYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6 IkFyaWFsIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi55aXYxNzIyNjg5OTUwZW1haWxzdHlsZTE3MQ0K CXttc28tc3R5bGUtbmFtZTp5aXYxNzIyNjg5OTUwZW1haWxzdHlsZTE3MTsNCglmb250LWZhbWls eToiQXJpYWwiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4ueWl2MTcyMjY4 OTk1MGJhbGxvb250ZXh0Y2hhcjENCgl7bXNvLXN0eWxlLW5hbWU6eWl2MTcyMjY4OTk1MGJhbGxv b250ZXh0Y2hhcjE7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7fQ0KcC55aXYx NzIyNjg5OTUwbXNvY2hwZGVmYXVsdDEsIGxpLnlpdjE3MjI2ODk5NTBtc29jaHBkZWZhdWx0MSwg ZGl2LnlpdjE3MjI2ODk5NTBtc29jaHBkZWZhdWx0MQ0KCXttc28tc3R5bGUtbmFtZTp5aXYxNzIy Njg5OTUwbXNvY2hwZGVmYXVsdDE7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2lu LXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDow aW47DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwi c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTMxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3 RDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0 IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v biBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGlu IDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPjwvaGVhZD48Ym9keSBsYW5nPUVOLVVTIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+PGRp diBjbGFzcz1Xb3JkU2VjdGlvbjE+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFG NDk3RCc+TmV3IHRleHQgYWRkZWQgdG8gQWNjZXNzIFRva2VuIFNjb3BlIHNlY3Rpb246PG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J3Rl eHQtYXV0b3NwYWNlOm5vbmUnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS41cHQ7Zm9udC1mYW1p bHk6Q29uc29sYXMnPsKgwqDCoMKgwqDCoMKgwqDCoCBJZiB0aGUgY2xpZW50IG9taXRzIHRoZSBz Y29wZSBwYXJhbWV0ZXIgd2hlbiByZXF1ZXN0aW5nIGF1dGhvcml6YXRpb24sIHRoZSBhdXRob3Jp emF0aW9uPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0ndGV4 dC1hdXRvc3BhY2U6bm9uZSc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWls eTpDb25zb2xhcyc+wqDCoMKgwqDCoMKgwqDCoMKgIHNlcnZlciBNVVNUIHByb2Nlc3MgdGhlIHJl cXVlc3QgdXNpbmcgYSBwcmUtZGVmaW5lZCBkZWZhdWx0IHZhbHVlLCBvciBmYWlsIHRoZSByZXF1 ZXN0PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0ndGV4dC1h dXRvc3BhY2U6bm9uZSc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseTpD b25zb2xhcyc+wqDCoMKgwqDCoMKgwqDCoMKgIGluZGljYXRpbmcgYW4gaW52YWxpZCBzY29wZS4g VGhlIGF1dGhvcml6YXRpb24gc2VydmVyIFNIT1VMRCBkb2N1bWVudCBpdHMgc2NvcGU8bzpwPjwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSd0ZXh0LWF1dG9zcGFjZTpu b25lJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzJz7C oMKgwqDCoMKgwqDCoMKgwqAgcmVxdWlyZW1lbnRzIGFuZCBkZWZhdWx0IHZhbHVlIChpZiBkZWZp bmVkKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSd0ZXh0 LWF1dG9zcGFjZTpub25lJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5 OkNvbnNvbGFzJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkVITDxvOnA+PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Jz48ZGl2PjxkaXYgc3R5bGU9 J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBpbiAwaW4gMGluJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNh bnMtc2VyaWYiJz4gV2lsbGlhbSBNaWxscyBbbWFpbHRvOndtaWxsc0B5YWhvby1pbmMuY29tXSA8 YnI+PGI+U2VudDo8L2I+IFR1ZXNkYXksIEphbnVhcnkgMTAsIDIwMTIgMTE6NTggUE08YnI+PGI+ VG86PC9iPiBFcmFuIEhhbW1lcjsgb2F1dGhAaWV0Zi5vcmc8YnI+PGI+U3ViamVjdDo8L2I+IFJl OiBbT0FVVEgtV0ddIFNlZWtpbmcgQ2xhcmlmaWNhdGlvbjogUG90ZW50aWFsIEFtYmlndWl0eSBp biBTcGVjaWZpY2F0aW9uPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNz PU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjE0LjBw dDtmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOmJsYWNrJz4mcXVvdDtOdWxsIHN0cmlu ZyZxdW90OywgJnF1b3Q7ZW1wdHkgc3RyaW5nJnF1b3Q7LCBvciAmcXVvdDtzZXJ2ZXIgZGVmaW5l ZCBkZWZhdWx0IHZhbHVlJnF1b3Q7IGFsbCB3b3JrLiZuYnNwOyBEZWZhdWx0IHNjb3BlIGRvZXNu J3QgZG8gaXQgZm9yIG1lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxNC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjpibGFjayc+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PGRpdj48ZGl2PjxkaXYgY2xhc3M9TXNvTm9y bWFsIGFsaWduPWNlbnRlciBzdHlsZT0ndGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0 ZSc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fu cy1zZXJpZiI7Y29sb3I6YmxhY2snPjxociBzaXplPTEgd2lkdGg9IjEwMCUiIGFsaWduPWNlbnRl cj48L3NwYW4+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRl Jz48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJz YW5zLXNlcmlmIjtjb2xvcjpibGFjayc+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNr Jz4gRXJhbiBIYW1tZXIgJmx0OzxhIGhyZWY9Im1haWx0bzplcmFuQGh1ZW5pdmVyc2UuY29tIj5l cmFuQGh1ZW5pdmVyc2UuY29tPC9hPiZndDs8YnI+PGI+VG86PC9iPiBXaWxsaWFtIE1pbGxzICZs dDs8YSBocmVmPSJtYWlsdG86d21pbGxzQHlhaG9vLWluYy5jb20iPndtaWxsc0B5YWhvby1pbmMu Y29tPC9hPiZndDs7ICZxdW90OzxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+b2F1dGhA aWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9h dXRoQGlldGYub3JnPC9hPiZndDsgPGJyPjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBKYW51YXJ5IDEw LCAyMDEyIDU6MjQgUE08YnI+PGI+U3ViamVjdDo8L2I+IFJFOiBbT0FVVEgtV0ddIFNlZWtpbmcg Q2xhcmlmaWNhdGlvbjogUG90ZW50aWFsIEFtYmlndWl0eSBpbiBTcGVjaWZpY2F0aW9uPC9zcGFu PjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2Pjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2Nv bG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdiBpZD15aXYxNzIyNjg5 OTUwPjxkaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3 aGl0ZSc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SSBkb27igJl0IGxpa2Ug4oCYZW1wdHkgc2NvcGXi gJkgYXMgaXQgaXMgdW5kZWZpbmVkLiBJIHByZWZlciDigJhkZWZhdWx0IHNjb3Bl4oCZLjwvc3Bh bj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29s b3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48 L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNr Z3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi QXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5FSEw8L3NwYW4+PHNwYW4gc3R5bGU9 J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiZu YnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48L2Rpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEu NXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQnPjxkaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAw aW4nPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48Yj48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNl cmlmIjtjb2xvcjpibGFjayc+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz4gV2ls bGlhbSBNaWxscyA8YSBocmVmPSJtYWlsdG86W21haWx0bzp3bWlsbHNAeWFob28taW5jLmNvbV0i PlttYWlsdG86d21pbGxzQHlhaG9vLWluYy5jb21dPC9hPiA8YnI+PGI+U2VudDo8L2I+IFR1ZXNk YXksIEphbnVhcnkgMTAsIDIwMTIgNDowMiBQTTxicj48Yj5Ubzo8L2I+IEVyYW4gSGFtbWVyOyA8 YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYub3JnPC9hPjxicj48Yj5T dWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gU2Vla2luZyBDbGFyaWZpY2F0aW9uOiBQb3RlbnRp YWwgQW1iaWd1aXR5IGluIFNwZWNpZmljYXRpb248L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJs YWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjpi bGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PGRpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxNC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjpibGFjayc+T24g eW91ciAjMSwgSSBkb24ndCBhZ3JlZSB0aGF0IGFuIGVtcHR5IHNjb3BlIGlzIHVzZWxlc3MuJm5i c3A7IFRoZXJlIGFyZSBjb21wYXJhYmxlIGltcGxlbWVudGF0aW9ucyB0aGF0IHVzZSBhbiBlbXB0 eSBzY29wZSB0byBiZSBhIHdpbGRjYXJkIHNjb3BlLiZuYnNwOyBJJ2Qgc2F5LCA8L3NwYW4+PHNw YW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+ PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxNC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xv cjpibGFjayc+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286 cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTQuMHB0O2ZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6YmxhY2snPiZxdW90O1RoZSBjbGllbnQgY2FuIE1B WSBpbmNsdWRlIG9yIG9taXQgdGhlIHNjb3BlIHBhcmFtZXRlci4gSWYgb21pdHRlZCwgdGhlIHNl cnZlciBtdXN0IHByb2Nlc3MgdGhlIHJlcXVlc3QgdXNpbmcgYW4gZW1wdHkgc2NvcGUgYXMgdGhl IGRlZmF1bHQuJm5ic3A7IFRoZSBzZXJ2ZXIgdGhlbiBwcm9jZXNzZXMgdGhlIHJlcXVlc3QgZWl0 aGVyIGlzc3VpbmcgYSBncmFudCB3aXRoIGl0J3MgZGVmYXVsdCBzY29wZSBhcyBkZWZpbmVkIGJ5 IHRoZSBzZXJ2ZXIgb3IgZmFpbGluZyB0aGUgcmVxdWVzdCBpbmRpY2F0aW5nIGFuIGludmFsaWQg c2NvcGUgcmVxdWVzdGVkLiZxdW90Ozwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjE0LjBw dDtmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOmJsYWNrJz4mbmJzcDs8L3NwYW4+PHNw YW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+ PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxNC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xv cjpibGFjayc+VGhhdCBsYW5ndWFnZSBpc24ndCBxdWl0ZSByaWdodCwgYnV0IEkgdGhpbmsgaXQn cyBjbGVhci48L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFj a2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxNC4wcHQ7Zm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Ijtjb2xvcjpibGFjayc+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xv cjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48ZGl2 PjxkaXYgY2xhc3M9TXNvTm9ybWFsIGFsaWduPWNlbnRlciBzdHlsZT0ndGV4dC1hbGlnbjpjZW50 ZXI7YmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPjxociBzaXplPTEgd2lkdGg9 IjEwMCUiIGFsaWduPWNlbnRlcj48L3NwYW4+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwi c2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPiBFcmFuIEhhbW1lciAmbHQ7PGEgaHJlZj0ibWFpbHRv OmVyYW5AaHVlbml2ZXJzZS5jb20iIHRhcmdldD0iX2JsYW5rIj5lcmFuQGh1ZW5pdmVyc2UuY29t PC9hPiZndDs8YnI+PGI+VG86PC9iPiAmcXVvdDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aEBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9 Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoQGlldGYub3JnPC9h PiZndDsgPGJyPjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBKYW51YXJ5IDEwLCAyMDEyIDE6MTUgUE08 YnI+PGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIFNlZWtpbmcgQ2xhcmlmaWNhdGlvbjog UG90ZW50aWFsIEFtYmlndWl0eSBpbiBTcGVjaWZpY2F0aW9uPC9zcGFuPjxzcGFuIHN0eWxlPSdj b2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxkaXYgc3R5bGU9 J21hcmdpbi1ib3R0b206MTIuMHB0Jz48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1i b3R0b206MTIuMHB0O2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ PGJyPkkgZG9uJ3QgdGhpbmsgdGhlIGlzc3VlIGhlcmUgaXMgYWJvdXQgdGhlIHNjb3BlIHZhbHVl LCBidXQgd2hvIGRvZXMgdGhlIE9QVElPTkFMIGRlc2lnbmF0aW9uIGFwcGxpZXMgdG8uIElPVywg aXMgaXQgb3B0aW9uYWwgZm9yIHRoZSBzZXJ2ZXIgdG8gc3VwcG9ydC9yZXF1aXJlIGl0LCBvciBp cyBpdCBvcHRpb25hbCBmb3IgdGhlIGNsaWVudCB0byBpbmNsdWRlIG9yIG9taXQgaXQuPGJyPjxi cj5UaGUgaW50ZW50aW9uIHdhcyB0byBtYWtlIGl0IG9wdGlvbmFsIGZvciB0aGUgYXV0aG9yaXph dGlvbiBzZXJ2ZXIgdG8gbWFrZSBhbGwgZGVjaXNpb25zIGFib3V0IHRoZSBwYXJhbWV0ZXIsIGlu Y2x1ZGluZyBtYWtpbmcgaXQgcmVxdWlyZWQuIEJ1dCB0aGUgdGV4dCBpcyBjb25mdXNpbmcgc2lu Y2UgdGhlIHRleHQgaXMgYWltZWQgZGlyZWN0bHkgYXQgdGhlIGNsaWVudCB3aGVuIG1ha2luZyB0 aGUgcmVxdWVzdC48YnI+PGJyPldlIG5lZWQgdG8gY2xhcmlmeSB0aGlzIGFuZCB0aGUgb3B0aW9u cyBhcmU6PGJyPjxicj4xLiBUaGUgY2xpZW50IGNhbiBkZWNpZGUgaWYgdGhleSB3YW50IHRvIGlu Y2x1ZGUgb3Igb21pdCB0aGUgc2NvcGUgcGFyYW1ldGVyLiBJZiBvbWl0dGVkLCB0aGUgc2VydmVy IG11c3QgcHJvY2VzcyB0aGUgcmVxdWVzdCB1c2luZyBzb21lIGRvY3VtZW50ZWQgZGVmYXVsdCBz Y29wZS4gVGhpcyBkZWZhdWx0IHNjb3BlIGNhbiBiZSBhbiBlbXB0eSBzY29wZSByZW5kZXJpbmcg dGhlIHRva2VuIHVzZWxlc3MgZm9yIGFueXRoaW5nIG90aGVyIHRoYW4gdmVyaWZ5aW5nIHVzZXIg YXV0aGVudGljYXRpb24uPGJyPjxicj4yLiBUaGUgc2VydmVyIGNhbiBkZWNsYXJlIHNjb3BlIHRv IGJlIGEgcmVxdWlyZWQgcGFyYW1ldGVyIGluIHdoaWNoIGNhc2UgdGhlIGNsaWVudCBtdXN0IGlu Y2x1ZGUgaXQgb3IgdGhlIHJlcXVlc3Qgd2lsbCBmYWlsLiBJbiB0aGlzIGNhc2UsIHdlIHNob3Vs ZCBtYWtlIHRoZSB0ZXh0IGNsZWFyZXIgdGhhdCBjbGllbnRzIHRvIGZpbmQgb3V0IGlmIHRoZSBw YXJ0aWN1bGFyIHNlcnZlciByZXF1aXJlcyBpdC48YnI+PGJyPiMxIGlzIGJldHRlciBmb3IgaW50 ZXJvcGVyYWJpbGl0eSwgIzIgaXMgbW9yZSBpbiB0aGUgc3Bpcml0IG9mIHRoZSBwYXJhbWV0ZXIg ZGlzY3Vzc2lvbnMgc28gZmFyLjxicj48YnI+RUhMPGJyPjxicj4mZ3Q7IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tPGJyPiZndDsgRnJvbTogPGEgaHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aC1ib3VuY2VzQGlldGYub3JnPC9hPiBbbWFp bHRvOjxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZjxicj4mZ3Q7IE9mIFBoaWwg SHVudDxicj4mZ3Q7IFNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMTAsIDIwMTIgMTE6MzMgQU08YnI+ Jmd0OyBUbzogU008YnI+Jmd0OyBDYzogPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+b2F1dGhAaWV0Zi5vcmc8L2E+PGJyPiZndDsgU3ViamVjdDogUmU6IFtP QVVUSC1XR10gU2Vla2luZyBDbGFyaWZpY2F0aW9uOiBQb3RlbnRpYWwgQW1iaWd1aXR5IGluPGJy PiZndDsgU3BlY2lmaWNhdGlvbjxicj4mZ3Q7IDxicj4mZ3Q7IFRoZSB1bmRlcmx5aW5nIGlzc3Vl IGlzIHRoYXQgdGhlcmUgd2FzIGEgZGVjaXNpb24gbm90IHRvIGluIGFueSB3YXk8YnI+Jmd0OyBz dGFuZGFyZGl6ZSB2YWx1ZXMgZm9yIHNjb3BlLjxicj4mZ3Q7IDxicj4mZ3Q7IEkgYWdyZWVkIHRo aXMgd2FzIHJlYXNvbmFibGUgc2luY2UgdGhlIHVuZGVybHlpbmcgcmVzb3VyY2UgQVBJcyBhcmUg bGlrZWx5IHRvPGJyPiZndDsgYmUgdmVyeSBzcGVjaWZpYyByZXF1aXJpbmcgc29tZSBkZWdyZWUg b2YgcHJpb3Iga25vd2xlZGdlIGJ5IHRoZSBjbGllbnQgYXBwPGJyPiZndDsgZGV2ZWxvcGVyLiBU aHVzIHRoZSByZXNvdXJjZSBzZXJ2ZXIgT0F1dGggaW5mcmFzdHJ1Y3R1cmUgaXMgZnJlZSB0byBk ZWNpZGU8YnI+Jmd0OyB3aGF0IGFyZSBhbmQgYXJlIG5vdCBhY2NlcHRhYmxlIHZhbHVlcyBpbmNs dWRpbmcgbWlzc2luZyBvciBudWxsIHZhbHVlcyBmb3I8YnI+Jmd0OyBzY29wZS48YnI+Jmd0OyA8 YnI+Jmd0OyBJIHRoaW5rIHRoZSBzcGVjaWZpY2F0aW9uIGlzIGFjY2VwdGFibGUgYXMgaXQgaXMu PGJyPiZndDsgPGJyPiZndDsgSSBub3RlIHRoYXQgb3RoZXIgc3BlY2lmaWNhdGlvbnMgdGhhdCBs YXllciBvbiB0b3Agb2YgT0F1dGgyIHN1Y2ggYXMgT3BlbklEPGJyPiZndDsgQ29ubmVjdCBtYXkg Y2hvb3NlIHRvIHN0cmljdGx5IGRlZmluZSBhY2NlcHRhYmxlIHZhbHVlcyBmb3Igc2NvcGUuIFRo aXMgdHlwZTxicj4mZ3Q7IG9mIGxheWVyaW5nIHdvcmtzIHdlbGwgaW4gbXkgb3Bpbmlvbi48YnI+ Jmd0OyA8YnI+Jmd0OyBQaGlsPGJyPiZndDsgPGJyPiZndDsgQGluZGVwZW5kZW50aWQ8YnI+Jmd0 OyA8YSBocmVmPSJodHRwOi8vd3d3LmluZGVwZW5kZW50aWQuY29tIiB0YXJnZXQ9Il9ibGFuayI+ d3d3LmluZGVwZW5kZW50aWQuY29tPC9hPjxicj4mZ3Q7IDxhIGhyZWY9Im1haWx0bzpwaGlsLmh1 bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPjxi cj4mZ3Q7IDxicj4mZ3Q7IDxicj4mZ3Q7IDxicj4mZ3Q7IDxicj4mZ3Q7IDxicj4mZ3Q7IE9uIDIw MTItMDEtMTAsIGF0IDEwOjU2IEFNLCBTTSB3cm90ZTo8YnI+Jmd0OyA8YnI+Jmd0OyAmZ3Q7IEF0 IDA5OjE5IDEwLTAxLTIwMTIsIFdpbGxpYW0gTWlsbHMgd3JvdGU6PGJyPiZndDsgJmd0OyZndDsg VGhhdCBkb2VzIGNsZWFyIGl0IHVwISZuYnNwOyBJZiB0aGUgaW1wbGVtZW50YXRpb24gcmV0dXJu cyBhIHByb3BlciBlcnJvciB3aGVuPGJyPiZndDsgdGhlIHNjb3BlIGlzIG9taXR0ZWQgdGhlbiBp dCB3aWxsIGJlIGluIGNvbmZvcm1hbmNlLiZuYnNwOyBTZW5kaW5nIGFuIGVycm9yIHJlc3VsdDxi cj4mZ3Q7IGZvciB0aGUgZW1wdHkgc2NvcGUgaXMgdmFsaWQuPGJyPiZndDsgJmd0Ozxicj4mZ3Q7 ICZndDsgWWVzLjxicj4mZ3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7IEl0IGlzIG5vdCBwb3NzaWJsZSB0 byBnZXQgYSBjbGVhciB2aWV3IG9mIHRoZSBzcGVjcyBpZiB0aGUgZGlzY3Vzc2lvbiBhYm91dDxi cj4mZ3Q7ICZxdW90O2FtYmlndWl0eSZxdW90OyByZWxpZXMgb24gdGhlIG1lYW5pbmcgb2YgdGhl IHdvcmQgJnF1b3Q7T1BUSU9OQUwmcXVvdDsgb25seS4mbmJzcDsgSWYgdGhlcmUgaXMgYTxicj4m Z3Q7IHByb2JsZW0sIHRoZW4gY2xhcmlmeWluZyB0ZXh0IGNvdWxkIGJlIHVzZWQgdG8gZml4IGl0 IGluc3RlYWQgb2YgY2hhbmdpbmcgdGhlPGJyPiZndDsgcmVxdWlyZW1lbnRzLjxicj4mZ3Q7ICZn dDs8YnI+Jmd0OyAmZ3Q7IFJlZ2FyZHMsPGJyPiZndDsgJmd0OyAtc208YnI+Jmd0OyAmZ3Q7IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPiZndDsgJmd0 OyBPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+Jmd0OyAmZ3Q7IDxhIGhyZWY9Im1haWx0bzpPQXV0aEBp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4mZ3Q7ICZndDsg PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8 L2E+PGJyPiZndDsgPGJyPiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+Jmd0OyBPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+Jmd0OyA8YSBocmVmPSJt YWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48 YnI+Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h dXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9vYXV0aDwvYT48YnI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+T0F1dGggbWFpbGluZyBsaXN0PGJyPjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj48YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9k aXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdDtiYWNrZ3Jv dW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2JvZHk+PC9odG1sPg== --_000_90C41DD21FB7C64BB94121FBBC2E723453AAB964E7P3PW5EX1MB01E_-- From barryleiba@gmail.com Fri Jan 20 12:44:21 2012 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 7873B21F86FA for ; Fri, 20 Jan 2012 12:44:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.855 X-Spam-Level: X-Spam-Status: No, score=-102.855 tagged_above=-999 required=5 tests=[AWL=0.122, 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 j-GzTMqIvOPw for ; Fri, 20 Jan 2012 12:44:20 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8D91D21F86F9 for ; Fri, 20 Jan 2012 12:44:20 -0800 (PST) Received: by obbwc12 with SMTP id wc12so1415851obb.31 for ; Fri, 20 Jan 2012 12:44:20 -0800 (PST) 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=9JcP84/5OL9cQIWLjrvy23WD1GOcW1sDfNQdjIhgOjU=; b=P4ft7jI3c11YHXmGlgidc6ue3bvpYcXyW4CQ5+gAL0bNNlxAwgZ9b3AJWN4ZuJbfLj rrAQ0Nx7i0k6XKe66eopgS+1Tk2DFbDDv8BrURPFcZxcnR09SnCNGsUC7epc58QeddW8 fS+Mecs/CwXlqz9VpDWzO7Rc8c3zFHsMbptaQ= MIME-Version: 1.0 Received: by 10.182.41.5 with SMTP id b5mr25062050obl.79.1327092250412; Fri, 20 Jan 2012 12:44:10 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.60.55.137 with HTTP; Fri, 20 Jan 2012 12:44:10 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453AAB964D3@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723453AAB964D3@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Fri, 20 Jan 2012 15:44:10 -0500 X-Google-Sender-Auth: RTY5lLvwg_VmIUps9yXSTr1L9Js Message-ID: From: Barry Leiba To: Eran Hammer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: oauth WG Subject: Re: [OAUTH-WG] TLS version requirements in OAuth 2.0 base 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, 20 Jan 2012 20:44:21 -0000 > Added to section 1: > > =A0 TLS Version > > =A0 =A0 =A0 =A0 =A0Whenever TLS is required by this specification, the ap= propriate version (or versions) of > =A0 =A0 =A0 =A0 =A0TLS will vary over time, based on the widespread deplo= yment and known security > =A0 =A0 =A0 =A0 =A0vulnerabilities. At the time of this writing, TLS vers= ion 1.2 > =A0 =A0 =A0 =A0 =A0is the most recent version, but has a very limited dep= loyment base and might not be > =A0 =A0 =A0 =A0 =A0readily available for implementation. TLS version 1.0 = is the > =A0 =A0 =A0 =A0 =A0most widely deployed version, and will provide the bro= adest interoperability. > > =A0 =A0 =A0 =A0 =A0Implementations MAY also support additional transport-= layer mechanisms that meet their > =A0 =A0 =A0 =A0 =A0security requirements. > > And referenced this section when TLS requirements were previously defined= . That seems like a very sensible way to organize it; thanks. Barry From igor.faynberg@alcatel-lucent.com Fri Jan 20 14:58:33 2012 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 8299921F8653 for ; Fri, 20 Jan 2012 14:58:33 -0800 (PST) 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 q+y3VyFn3IEm for ; Fri, 20 Jan 2012 14:58:32 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 3986321F864D for ; Fri, 20 Jan 2012 14:58:26 -0800 (PST) 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 q0KMwP29003252 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 20 Jan 2012 16:58:25 -0600 (CST) 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 q0KMwODw001134 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 20 Jan 2012 16:58:25 -0600 Received: from [135.244.1.84] (faynberg.lra.lucent.com [135.244.1.84]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q0KMwNEH020650; Fri, 20 Jan 2012 16:58:24 -0600 (CST) Message-ID: <4F19F18F.6030906@alcatel-lucent.com> Date: Fri, 20 Jan 2012 17:58:23 -0500 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: <1326156786.88572.YahooMailNeo@web31812.mail.mud.yahoo.com> <1326160314.71861.YahooMailNeo@web31806.mail.mud.yahoo.com> <1326162276.40306.YahooMailNeo@web31811.mail.mud.yahoo.com> <1326215997.44445.YahooMailNeo@web31816.mail.mud.yahoo.com> <6.2.5.6.2.20120110104038.099f1ba8@resistor.net> <90C41DD21FB7C64BB94121FBBC2E723453A72D0F24@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1326240141.98332.YahooMailNeo@web31808.mail.mud.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E723453A72D0F60@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1326268674.20557.YahooMailNeo@web31807.mail.mud.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E723453AAB964E7@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453AAB964E7@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: multipart/alternative; boundary="------------080408010004030600070100" X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification 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: Fri, 20 Jan 2012 22:58:33 -0000 This is a multi-part message in MIME format. --------------080408010004030600070100 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit (Strictly editorial.) Just to make the first sentence easiery to parse, I suggest to clarify the scope (no pan intended) of "MUST." I read it the server MUST either process the request OR fail it. If so, maybe just inserting the word either would do the job. I would also change punctuation to delineate the "using" and "indicating" clauses. Probably putting both clauses in parentheses will make it easier than adding an extra comma. Another thing that I found stands in the way of is whether it is really "invalid scope [value]." Maybe it is better to indicate that no scope value has been supplied? As a developer I see the benefit of requiring a default value, incidentally, but since there is an option, I think it might be better to describe the error in a straight-forward way. The suggested text: If the client omits the scope parameter when requesting authorization, the authorization server MUST either process the request (using a pre-defined default scope value) or fail the request (indicating that the scope value is missing). The authorization server SHOULD document its scope requirements and default value (if defined). Igor On 1/20/2012 3:32 PM, Eran Hammer wrote: > > New text added to Access Token Scope section: > > If the client omits the scope parameter when requesting > authorization, the authorization > > server MUST process the request using a pre-defined default > value, or fail the request > > indicating an invalid scope. The authorization server SHOULD > document its scope > > requirements and default value (if defined). > > EHL > > *From:*William Mills [mailto:wmills@yahoo-inc.com] > *Sent:* Tuesday, January 10, 2012 11:58 PM > *To:* Eran Hammer; oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity > in Specification > > "Null string", "empty string", or "server defined default value" all > work. Default scope doesn't do it for me. > > ------------------------------------------------------------------------ > > *From:*Eran Hammer > > *To:* William Mills >; "oauth@ietf.org > " > > *Sent:* Tuesday, January 10, 2012 5:24 PM > *Subject:* RE: [OAUTH-WG] Seeking Clarification: Potential Ambiguity > in Specification > > I don’t like ‘empty scope’ as it is undefined. I prefer ‘default scope’. > > EHL > > *From:*William Mills [mailto:wmills@yahoo-inc.com] > > *Sent:* Tuesday, January 10, 2012 4:02 PM > *To:* Eran Hammer; oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity > in Specification > > On your #1, I don't agree that an empty scope is useless. There are > comparable implementations that use an empty scope to be a wildcard > scope. I'd say, > > "The client can MAY include or omit the scope parameter. If omitted, > the server must process the request using an empty scope as the > default. The server then processes the request either issuing a grant > with it's default scope as defined by the server or failing the > request indicating an invalid scope requested." > > That language isn't quite right, but I think it's clear. > > ------------------------------------------------------------------------ > > *From:*Eran Hammer > > *To:* "oauth@ietf.org " > > *Sent:* Tuesday, January 10, 2012 1:15 PM > *Subject:* Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity > in Specification > > > I don't think the issue here is about the scope value, but who does > the OPTIONAL designation applies to. IOW, is it optional for the > server to support/require it, or is it optional for the client to > include or omit it. > > The intention was to make it optional for the authorization server to > make all decisions about the parameter, including making it required. > But the text is confusing since the text is aimed directly at the > client when making the request. > > We need to clarify this and the options are: > > 1. The client can decide if they want to include or omit the scope > parameter. If omitted, the server must process the request using some > documented default scope. This default scope can be an empty scope > rendering the token useless for anything other than verifying user > authentication. > > 2. The server can declare scope to be a required parameter in which > case the client must include it or the request will fail. In this > case, we should make the text clearer that clients to find out if the > particular server requires it. > > #1 is better for interoperability, #2 is more in the spirit of the > parameter discussions so far. > > EHL > > > -----Original Message----- > > From: oauth-bounces@ietf.org > [mailto:oauth-bounces@ietf.org ] On Behalf > > Of Phil Hunt > > Sent: Tuesday, January 10, 2012 11:33 AM > > To: SM > > Cc: oauth@ietf.org > > Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in > > Specification > > > > The underlying issue is that there was a decision not to in any way > > standardize values for scope. > > > > I agreed this was reasonable since the underlying resource APIs are > likely to > > be very specific requiring some degree of prior knowledge by the > client app > > developer. Thus the resource server OAuth infrastructure is free to > decide > > what are and are not acceptable values including missing or null > values for > > scope. > > > > I think the specification is acceptable as it is. > > > > I note that other specifications that layer on top of OAuth2 such as > OpenID > > Connect may choose to strictly define acceptable values for scope. > This type > > of layering works well in my opinion. > > > > Phil > > > > @independentid > > www.independentid.com > > phil.hunt@oracle.com > > > > > > > > > > > > On 2012-01-10, at 10:56 AM, SM wrote: > > > > > At 09:19 10-01-2012, William Mills wrote: > > >> That does clear it up! If the implementation returns a proper > error when > > the scope is omitted then it will be in conformance. Sending an > error result > > for the empty scope is valid. > > > > > > Yes. > > > > > > It is not possible to get a clear view of the specs if the > discussion about > > "ambiguity" relies on the meaning of the word "OPTIONAL" only. If > there is a > > problem, then clarifying text could be used to fix it instead of > changing the > > requirements. > > > > > > Regards, > > > -sm > > > _______________________________________________ > > > 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 --------------080408010004030600070100 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit (Strictly editorial.)

Just to make the first sentence easiery to parse, I suggest to clarify the scope (no pan intended) of "MUST."  I read it the server MUST either process the request OR fail it.  If so, maybe just inserting the word either would do the job.  I would also change punctuation to delineate the "using" and "indicating" clauses. Probably putting both clauses in parentheses will make it easier than adding an extra comma.  Another thing that I found stands in the way of is whether it is really "invalid scope [value]."  Maybe it is better to indicate that no scope value has been supplied?

As a developer I see the benefit of requiring a default value, incidentally, but since there is an option, I think it might be better to describe the error in a straight-forward way.

The suggested text:

          If the client omits the scope parameter when requesting authorization, the authorization

          server MUST either process the request (using a pre-defined default scope value) or fail the request

          (indicating that the scope value is missing). The authorization server SHOULD document its scope

          requirements and default value (if defined).

 



Igor

On 1/20/2012 3:32 PM, Eran Hammer wrote:

New text added to Access Token Scope section:

 

          If the client omits the scope parameter when requesting authorization, the authorization

          server MUST process the request using a pre-defined default value, or fail the request

          indicating an invalid scope. The authorization server SHOULD document its scope

          requirements and default value (if defined).

 

 

EHL

 

From: William Mills [mailto:wmills@yahoo-inc.com]
Sent: Tuesday, January 10, 2012 11:58 PM
To: Eran Hammer; oauth@ietf.org
Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification

 

"Null string", "empty string", or "server defined default value" all work.  Default scope doesn't do it for me.

 

From: Eran Hammer <eran@hueniverse.com>
To: William Mills <wmills@yahoo-inc.com>; "oauth@ietf.org" <oauth@ietf.org>
Sent: Tuesday, January 10, 2012 5:24 PM
Subject: RE: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification

 

I don’t like ‘empty scope’ as it is undefined. I prefer ‘default scope’.

 

EHL

 

From: William Mills [mailto:wmills@yahoo-inc.com]
Sent: Tuesday, January 10, 2012 4:02 PM
To: Eran Hammer; oauth@ietf.org
Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification

 

On your #1, I don't agree that an empty scope is useless.  There are comparable implementations that use an empty scope to be a wildcard scope.  I'd say,

 

"The client can MAY include or omit the scope parameter. If omitted, the server must process the request using an empty scope as the default.  The server then processes the request either issuing a grant with it's default scope as defined by the server or failing the request indicating an invalid scope requested."

 

That language isn't quite right, but I think it's clear.

 

From: Eran Hammer <eran@hueniverse.com>
To: "oauth@ietf.org" <oauth@ietf.org>
Sent: Tuesday, January 10, 2012 1:15 PM
Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification


I don't think the issue here is about the scope value, but who does the OPTIONAL designation applies to. IOW, is it optional for the server to support/require it, or is it optional for the client to include or omit it.

The intention was to make it optional for the authorization server to make all decisions about the parameter, including making it required. But the text is confusing since the text is aimed directly at the client when making the request.

We need to clarify this and the options are:

1. The client can decide if they want to include or omit the scope parameter. If omitted, the server must process the request using some documented default scope. This default scope can be an empty scope rendering the token useless for anything other than verifying user authentication.

2. The server can declare scope to be a required parameter in which case the client must include it or the request will fail. In this case, we should make the text clearer that clients to find out if the particular server requires it.

#1 is better for interoperability, #2 is more in the spirit of the parameter discussions so far.

EHL

> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Phil Hunt
> Sent: Tuesday, January 10, 2012 11:33 AM
> To: SM
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in
> Specification
>
> The underlying issue is that there was a decision not to in any way
> standardize values for scope.
>
> I agreed this was reasonable since the underlying resource APIs are likely to
> be very specific requiring some degree of prior knowledge by the client app
> developer. Thus the resource server OAuth infrastructure is free to decide
> what are and are not acceptable values including missing or null values for
> scope.
>
> I think the specification is acceptable as it is.
>
> I note that other specifications that layer on top of OAuth2 such as OpenID
> Connect may choose to strictly define acceptable values for scope. This type
> of layering works well in my opinion.
>
> Phil
>
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>
>
>
>
>
> On 2012-01-10, at 10:56 AM, SM wrote:
>
> > At 09:19 10-01-2012, William Mills wrote:
> >> That does clear it up!  If the implementation returns a proper error when
> the scope is omitted then it will be in conformance.  Sending an error result
> for the empty scope is valid.
> >
> > Yes.
> >
> > It is not possible to get a clear view of the specs if the discussion about
> "ambiguity" relies on the meaning of the word "OPTIONAL" only.  If there is a
> problem, then clarifying text could be used to fix it instead of changing the
> requirements.
> >
> > Regards,
> > -sm
> > _______________________________________________
> > 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
--------------080408010004030600070100-- From igor.faynberg@alcatel-lucent.com Fri Jan 20 15:02:35 2012 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 94C3621F869D for ; Fri, 20 Jan 2012 15:02:35 -0800 (PST) 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.000, 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 G68cccs0A7Qn for ; Fri, 20 Jan 2012 15:02:30 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id B28E421F8577 for ; Fri, 20 Jan 2012 15:02:28 -0800 (PST) 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 q0KN2PMA004876 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 20 Jan 2012 17:02:26 -0600 (CST) 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 q0KN2PgF001532 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 20 Jan 2012 17:02:25 -0600 Received: from [135.244.1.84] (faynberg.lra.lucent.com [135.244.1.84]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q0KN2Otd023658; Fri, 20 Jan 2012 17:02:25 -0600 (CST) Message-ID: <4F19F280.2030805@alcatel-lucent.com> Date: Fri, 20 Jan 2012 18:02:24 -0500 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: <90C41DD21FB7C64BB94121FBBC2E723453AAB964D3@P3PW5EX1MB01.EX1.SECURESERVER.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.12 Subject: Re: [OAUTH-WG] TLS version requirements in OAuth 2.0 base 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: Fri, 20 Jan 2012 23:02:35 -0000 Since there is so much agreement and peace in the air, I would through a little editorial query: Would it not be better to say "the appropriate version" instead of this somewaht lawyerish "version (or versions)"? Igor On 1/20/2012 3:44 PM, Barry Leiba wrote: >> Added to section 1: >> >> TLS Version >> >> Whenever TLS is required by this specification, the appropriate version (or versions) of >> TLS will vary over time, based on the widespread deployment and known security >> vulnerabilities. At the time of this writing, TLS version 1.2 >> is the most recent version, but has a very limited deployment base and might not be >> readily available for implementation. TLS version 1.0 is the >> most widely deployed version, and will provide the broadest interoperability. >> >> Implementations MAY also support additional transport-layer mechanisms that meet their >> security requirements. >> >> And referenced this section when TLS requirements were previously defined. > That seems like a very sensible way to organize it; thanks. > > Barry > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Fri Jan 20 15:19:28 2012 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 992D921F85F0 for ; Fri, 20 Jan 2012 15:19:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.119, 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 CH5Eacj7+TBG for ; Fri, 20 Jan 2012 15:19:27 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id C0C2521F85EF for ; Fri, 20 Jan 2012 15:19:27 -0800 (PST) Received: (qmail 10914 invoked from network); 20 Jan 2012 23:19:27 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 20 Jan 2012 23:19:27 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Fri, 20 Jan 2012 16:19:23 -0700 From: Eran Hammer To: OAuth WG Date: Fri, 20 Jan 2012 16:19:12 -0700 Thread-Topic: SHOULD vs MUST for indicating scope on response when different from client request Thread-Index: AczXydXeHyPxe7flRt6JnM0WhQ4x+A== Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453AAB96537@P3PW5EX1MB01.EX1.SECURESERVER.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_90C41DD21FB7C64BB94121FBBC2E723453AAB96537P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: [OAUTH-WG] SHOULD vs MUST for indicating scope on response when different from client 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, 20 Jan 2012 23:19:28 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723453AAB96537P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The current text: If the issued access token scope is different from the one requested by the client, the authorization server SHOULD include the "scope" response parameter to inform the client of the actual scope granted. Stephen asked why not a MUST. I think it should be MUST. Any disagreement? EHL --_000_90C41DD21FB7C64BB94121FBBC2E723453AAB96537P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The current text= :

 

   If the issued access token = scope

   is different from the one requested by the client, the aut= horization

   server SHOULD include the "scope" response = parameter to inform the

   client of the actual scope granted.=

 

Stephen asked why not a MUST. I think it should be MUST. Any disagreem= ent?

 

EHL

 

= --_000_90C41DD21FB7C64BB94121FBBC2E723453AAB96537P3PW5EX1MB01E_-- From torsten@lodderstedt.net Fri Jan 20 15:22:59 2012 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 E393F21F86AF for ; Fri, 20 Jan 2012 15:22:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[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 b3Q2SvTEU5Z0 for ; Fri, 20 Jan 2012 15:22:58 -0800 (PST) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.24]) by ietfa.amsl.com (Postfix) with ESMTP id 1A34A21F861B for ; Fri, 20 Jan 2012 15:22:57 -0800 (PST) Received: from [91.2.70.47] (helo=[192.168.71.31]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.68) (envelope-from ) id 1RoNl4-00081J-8W; Sat, 21 Jan 2012 00:22:55 +0100 References: <90C41DD21FB7C64BB94121FBBC2E723453AAB96537@P3PW5EX1MB01.EX1.SECURESERVER.NET> User-Agent: K-9 Mail for Android In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453AAB96537@P3PW5EX1MB01.EX1.SECURESERVER.NET> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----WJVYPODLC8YR42PF21QQ7W4O7XG4YH" From: Torsten Lodderstedt Date: Sat, 21 Jan 2012 00:20:16 +0100 To: Eran Hammer ,OAuth WG Message-ID: X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Subject: Re: [OAUTH-WG] SHOULD vs MUST for indicating scope on response when different from client 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, 20 Jan 2012 23:22:59 -0000 ------WJVYPODLC8YR42PF21QQ7W4O7XG4YH Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit MUST sounds reasonable Eran Hammer schrieb: The current text: If the issued access token scope is different from the one requested by the client, the authorization server SHOULD include the "scope" response parameter to inform the client of the actual scope granted. Stephen asked why not a MUST. I think it should be MUST. Any disagreement? EHL ------WJVYPODLC8YR42PF21QQ7W4O7XG4YH Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit MUST sounds reasonable



Eran Hammer <eran@hueniverse.com> schrieb:

The current text:

 

   If the issued access token scope

   is different from the one requested by the client, the authorization

   server SHOULD include the "scope" response parameter to inform the

   client of the actual scope granted.

 

Stephen asked why not a MUST. I think it should be MUST. Any disagreement?

 

EHL

 

------WJVYPODLC8YR42PF21QQ7W4O7XG4YH-- From eran@hueniverse.com Fri Jan 20 15:47:01 2012 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 4CC3621F8568 for ; Fri, 20 Jan 2012 15:47:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.484 X-Spam-Level: X-Spam-Status: No, score=-2.484 tagged_above=-999 required=5 tests=[AWL=0.114, 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 9KkS7mCGn9VQ for ; Fri, 20 Jan 2012 15:47:00 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 842A121F855A for ; Fri, 20 Jan 2012 15:47:00 -0800 (PST) Received: (qmail 23547 invoked from network); 20 Jan 2012 23:47:00 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.47) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 20 Jan 2012 23:47:00 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT005.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Fri, 20 Jan 2012 16:46:49 -0700 From: Eran Hammer To: OAuth WG Date: Fri, 20 Jan 2012 16:46:38 -0700 Thread-Topic: Server cret verification in 10.9 Thread-Index: AczXzbKA/SD1BhejQGqf1ifLs7XLXA== Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453AAB9653D@P3PW5EX1MB01.EX1.SECURESERVER.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_90C41DD21FB7C64BB94121FBBC2E723453AAB9653DP3PW5EX1MB01E_" MIME-Version: 1.0 Subject: [OAUTH-WG] Server cret verification in 10.9 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, 20 Jan 2012 23:47:01 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723453AAB9653DP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Stephen asked: > (13) 10.9 says that the client MUST verify the server's cert which is fin= e. > 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 there= by > possibly rule out using DANE with the non PKI options that that WG (may) > produce? Can someone help with this? I don't know enough to address. EHL --_000_90C41DD21FB7C64BB94121FBBC2E723453AAB9653DP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Stephen asked:

 

> (13) 10.9 says that the client MUST verify the server's cert which= is fine.

> However, does that nee= d 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 wi= th the non PKI options that that WG (may)

> produce?

 

=

Can someone help with this? I don’t know enough = to address.

 

EHL

= --_000_90C41DD21FB7C64BB94121FBBC2E723453AAB9653DP3PW5EX1MB01E_-- From eran@hueniverse.com Fri Jan 20 15:47:50 2012 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 BDB4F21F8566 for ; Fri, 20 Jan 2012 15:47:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[AWL=-0.489, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, J_CHICKENPOX_41=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 9c8YIOkCRGJg for ; Fri, 20 Jan 2012 15:47:49 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 7EFF521F8533 for ; Fri, 20 Jan 2012 15:47:49 -0800 (PST) Received: (qmail 24765 invoked from network); 20 Jan 2012 23:47:49 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.47) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 20 Jan 2012 23:47:49 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT005.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Fri, 20 Jan 2012 16:47:49 -0700 From: Eran Hammer To: OAuth WG Date: Fri, 20 Jan 2012 16:47:38 -0700 Thread-Topic: AD Review of -22 (part I) Thread-Index: AczXzc8nJo3JPBK7T6iVe/oWZhvfow== Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453AAB96540@P3PW5EX1MB01.EX1.SECURESERVER.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] AD Review of -22 (part I) 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, 20 Jan 2012 23:47:51 -0000 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Stephen Farrell > Sent: Thursday, October 13, 2011 10:13 AM > List 1 - Fairly sure these need changes: > ---------------------------------------- >=20 > (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 co= der > has to implement.=A0 Saying an AS that issues passwords MUST support "bas= ic > over TLS" and MAY support including credentials in the body would seem > right here. Changed 'MAY allow' to 'MAY support'. Clarified the TLS requirement for sen= ding passwords. > (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 w= hich > cipher suites etc. Doing that once is fine and you could then have a defi= ned > phrase for it, but it needs to be specified for each place where TLS is u= sed. > The text at the end of > p15 is almost exactly what's needed, and would be if you said which ciphe= r > suites are MUSTs. I think you might need to pick cipher suites for each > version if you want some combination of tls1.0 and tls1.2 and need server > auth at least. Replaced ' transport-layer' with TLS with reference to the new section. =20 > (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 a= nd > PROTO write up if you want to stick with the current choices. I personall= y > 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 plai= ntext > 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 t= o go > to the WG.) This has been resolved by the chair and adjusted as such. =20 > (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 o= f > values. When >1 value is provided, it doesn't say what that means, it onl= y > 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. Removed the space-delimited text from the end of the response_type paramete= r definition and added the following immediate after: Extension response types MAY contain a space-delimited (%x20) l= ist of values, where the order of values does not matter (e.g. response type"a b" is the same as "b a"). The meaning of such composite response types is defined by their respective specifications. =20 > (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 ide= ally, > 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. I took that last paragraph out. Client mitigation isn't really practical he= re. > (6) In 7.1 what does it mean to say that the client MUST NOT use the acce= ss > token if it doesn't trust the token type? I don't know what code I'd writ= e > there in a client. Maybe s/trust/support/ or s/trust/understand/ would fi= x > this. Took 'trust' out. > (7) Doesn't 7.1 need to say which token types are MTI so that we get > interop?=A0 I think I'd like to see mac being a MUST and bearer being a M= AY but > regardless of my preference, I don't think you can be silent on this.=A0 = 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.=A0 And as a consequence one or both of the mac/bearer drafts nee= d > to end up as normative I think. No change as resolved by the chair. > (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.) Added to each section: [Access token credentials | Refresh tokens] MUST only be transmit= ted using TLS as described in with server authentication as defined = by . > (9) 10.5 says "effort should be made" to keep codes confidential, but I e= xpect > that'll generate AD comments - that's just a bit too vague - what do you = really > mean there? Took that sentence out. Added no value. > (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 m= ay 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.) Per the requirement in the thread-model document, replaced with the followi= ng: Generated tokens and other credentials not intended for handling = by end-users MUST be constructed from a cryptographically strong random or pseudo-rand= om number sequence () generated by the authorization serv= er. The probability of any two values being identical MUST be less than or equal to 2^(-128)= and SHOULD be less than or equal to 2^(-160). Added a reference to 10.10 from 10.12. > (11) Section 11 says a couple of times that the apps ADs are the appeal c= hain - > shouldn't that be the SEC ADs now? Fixed. =20 > List 2 - Questions: (not sure whether change needed or not) > ---------- >=20 > (1) p12 - 2.1 says that the client developer declares the type of the cli= ent, but > then says that the definition is up to the authorization server really, s= o, in > principle one client might have different types for different authorizati= on > servers. I think you could make this clearer by adding a sentence saying = that > one client could have >1 type according to different authorization server= s or > that the client type could change over time, e.g. as some vulnerability i= n an > OS gets discovered or if a new OS feature is added.=A0 I'm not sure if th= ere'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 invalidati= ng > all outstanding tokens or something? Maybe this sounds like something tha= t > some other document (and RFC or not) can tackle later. Added to section 2.1: A client application consisting of multiple components, each with= its own client type (e.g. a distributed client with both a confidential server-based = component and a public browser-based component), MUST register each component separately= as a different client to ensure proper handling by the authorization server. The author= ization server MAY provider tools to manage such complex clients through a single ad= ministration interface. > (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? Not sure I understand this, but how passwords are handled is outside the sc= ope. Basically, the user-agent is sent to the endpoint and the server shows= some kind of form. How that form is submitted is not part of OAuth is not = part of the form encoding described. The form encoding mentioned is just ab= out inputs send to the server before any login prompt. If this is not clear, please let me know. > (3) Generally, the specification is a bit unclear about what each compone= nt > MUST do, it's hard to figure that out with the style of describing the 21= 19 > rules on a per endpoint basis. Not sure what to suggest that'd not be loa= ds 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. We've got feedback from people who just read the spec without being involve= d here (most of it in the past couple of months) and it did not raise this = issue. =20 > (4) Is it clear that a client always knows when a redirection request wil= l result > in sensitive data being sent, thus triggering the SHOULD for use of TLS i= n > 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. Changed to: The redirection endpoint SHOULD require the use of TLS as des= cribed in when the requested response type is "code" or "token", or when the redirection request will resul= t in the transmission of sensitive credentials over an open network. > (5) 3.1.2.2 says AS'es 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 onl= y > supports 1, and it ought be easy for an AS to support >1 I guess. Because this is not an interop issue. The number of supported redirection U= RIs is a matter of configuration. Until we have an spec for interop on that= side, we don't need to prescribe it. Most 1.0 sites today support only one= . > (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? I assume you are asking why isn't this a MUST NOT? That sentence is a little bit tongue-in-cheek... In 3.1.2.2 we say that unr= egistered endpoints SHOULD NOT be allowed and this one is a way of saying w= hy they are bad in a twisted way. After reading it again, I took that line = out and added this to 3.1.2.2: Lack of a redirection URI registration requirement can enable= an attacker to use the authorization endpoint as open redirector as described in . > (7) Can a client really ensure that other scripts don't go before its own= as > required in 3.1.2.5? Yes, for example, by using multiple endpoints chained in the right order. > (8) What is the impact of the "MUST be taken into consideration" at the e= nd > of 3.2.1? I can't see how to implement that nor is it clear what checks a= n AS > could do at registration time. Dropped that line. 10.1 already covers this. > (9) Does the recent list discussion about scope encoding require any chan= ges > to 3.3? Yep. Been applied. > (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.) No reason. I originally put it in as a SHOULD because scope was more of an = nice idea than an important feature. This should probably be changed to MUS= T. Not going to make this change now, but will if the WG would like to. Wil= l bring up in another thread. > (11) State and scope variables probably should not contain anything sensi= tive > 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 yours= elf.) > An example of what not to include would be a banking client including a > user's bank a/c number as the state variable. Added to 10.8: The "state" and "scope" parameters SHOULD NOT include sensitive client or resource owner information= in plain text as they can be transmitted over insecure channels or stored insecurely. > (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;-) Yeah... This specification sucks when it comes to prescribing interoperable behavio= r. At this point the biggest reason people hate OAuth 1.0 is not the crypto= but that every server implementation is different. Wait until they experie= nce 2.0... But unfortunately this is as far as this WG was able to agree. W= G participants didn't want to come together and agree but to make sure they= will be able to implement their own unique use cases (and screw interop). I think the only hope moving forward is for someone to publish a profile th= at is tight and restrictive and see if it gains traction. Yeah, I'm bitter about the quality of this work after investing 4 years int= o it, but that's life. > (13) 10.9 says that the client MUST verify the server's cert which is fin= e. > 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 there= by > possibly rule out using DANE with the non PKI options that that WG (may) > produce? Don't know anything about this. Will bring up in another thread. =20 (To be continued...) EHL From dick.hardt@gmail.com Fri Jan 20 15:50:53 2012 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 9D13F21F8578 for ; Fri, 20 Jan 2012 15:50:53 -0800 (PST) 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 2flq7pXmykN4 for ; Fri, 20 Jan 2012 15:50:53 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id DFD7121F85FF for ; Fri, 20 Jan 2012 15:50:52 -0800 (PST) Received: by ghbg16 with SMTP id g16so109906ghb.31 for ; Fri, 20 Jan 2012 15:50:52 -0800 (PST) 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 :message-id:references:to:x-mailer; bh=Zm6dxPJOoOe+YiuE6TUGWsItIOnxGW6sHYim+kkKNn0=; b=B/q2xqrNs209apJ7n+JTn/R5GdGt2dxQsPAuVq87EggXy4W+EGM/dk8ayAdQLY7h9J ICbqZ13Fdn71femB9xzgErN+vNx+zhLjiO5D0KaOY8uCj/EmtA4cxx8zdeS+C0HPuZYj Os1rE4nCEKUwPdvlmMOJ9vhGPFqZPRuKF5pQo= Received: by 10.236.179.7 with SMTP id g7mr48513814yhm.74.1327103452499; Fri, 20 Jan 2012 15:50:52 -0800 (PST) Received: from [192.168.0.40] (S0106602ad0767c15.nb.shawcable.net. [70.74.90.92]) by mx.google.com with ESMTPS id n64sm7993416yhk.4.2012.01.20.15.50.50 (version=SSLv3 cipher=OTHER); Fri, 20 Jan 2012 15:50:51 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_45522EB3-AE25-403A-988F-CACE6341566D" From: Dick Hardt In-Reply-To: Date: Fri, 20 Jan 2012 16:50:50 -0700 Message-Id: <35BD8E89-A024-4034-8E89-95F4814F9C6C@gmail.com> References: <90C41DD21FB7C64BB94121FBBC2E723453AAB96537@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Torsten Lodderstedt X-Mailer: Apple Mail (2.1251.1) Cc: OAuth WG Subject: Re: [OAUTH-WG] SHOULD vs MUST for indicating scope on response when different from client 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, 20 Jan 2012 23:50:53 -0000 --Apple-Mail=_45522EB3-AE25-403A-988F-CACE6341566D Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii +! On Jan 20, 2012, at 4:20 PM, Torsten Lodderstedt wrote: > MUST sounds reasonable > > > > Eran Hammer schrieb: > The current text: > > If the issued access token scope > is different from the one requested by the client, the authorization > server SHOULD include the "scope" response parameter to inform the > client of the actual scope granted. > > Stephen asked why not a MUST. I think it should be MUST. Any disagreement? > > EHL > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_45522EB3-AE25-403A-988F-CACE6341566D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii +!

On Jan 20, 2012, at 4:20 PM, = Torsten Lodderstedt wrote:

MUST sounds = reasonable 



Eran Hammer <eran@hueniverse.com> = schrieb:
The current = text:
 
   If the issued access token = scope
   is different from the one requested by the client, = the authorization
   server SHOULD include the "scope" response = parameter to inform the
   client of the actual scope = granted.
 
Stephen asked why not a MUST. I think it should be MUST. = Any disagreement?
 
EHL
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth

= --Apple-Mail=_45522EB3-AE25-403A-988F-CACE6341566D-- From stephen.farrell@cs.tcd.ie Fri Jan 20 16:20:43 2012 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 D0B7A21F86EB for ; Fri, 20 Jan 2012 16:20:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.399 X-Spam-Level: X-Spam-Status: No, score=-101.399 tagged_above=-999 required=5 tests=[AWL=-1.200, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, J_CHICKENPOX_24=0.6, J_CHICKENPOX_41=0.6, J_CHICKENPOX_51=0.6, 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 clt-PTT-2PFI for ; Fri, 20 Jan 2012 16:20:40 -0800 (PST) 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 E9C8C21F8587 for ; Fri, 20 Jan 2012 16:20:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 8AF46171CF1; Sat, 21 Jan 2012 00:20:38 +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=1327105237; bh=hX7uXJtr1D42lg ldGYhqyrpF8NpKhFoihscq5g67Zgc=; b=X7rAgEyCqGpU4DhCYavvIW6pcV7vyg RN0BHL8yYm/9qHtFEE2iRrYWQLRy3H5Nd41BAWEmy8XzCm4v13I4ZrITq5bHa+u1 +ngYyHHHAwMTG/BWMHNXxVJ2q7Sfaz18/qW7SDmF8IeQ7ecdeumv+on3BMc6LzaK jWJp6Lo8qGeVEaZIlN6YiZ8ODuSFOJsGnY2eKCIpRXcGC3JV0lr6/+fMglKIrN3N l3eroQ+g8ikYaQzxLyJYXA0EVGLEM3A9iYs89Rnlx0lAth0oLMqRy+TFxcHQ0owa UpYW80QSyNBHC9rpjViI0QzwNOQiQk6nmBElfpbUuWjawDMLsKGjo7/Q== 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 oYvt5jvAgXWX; Sat, 21 Jan 2012 00:20:37 +0000 (GMT) Received: from [10.87.48.5] (unknown [86.41.8.14]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 6C40C171C1A; Sat, 21 Jan 2012 00:20:35 +0000 (GMT) Message-ID: <4F1A04D2.1080604@cs.tcd.ie> Date: Sat, 21 Jan 2012 00:20:34 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Eran Hammer References: <90C41DD21FB7C64BB94121FBBC2E723453AAB96540@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453AAB96540@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: OAuth WG Subject: Re: [OAUTH-WG] AD Review of -22 (part I) 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, 21 Jan 2012 00:20:43 -0000 FWIW, from my p-o-v everything here is either ok, me being dumb (the password one, I need to check), part of some other thread, or stuff that's ok to resolve if necessary at IETF LC or later. So - I'd say firing away with -23 and getting this out the door (once current threads resolve themselves) is the way to go. Thanks, S. On 01/20/2012 11:47 PM, Eran Hammer wrote: >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Stephen Farrell >> Sent: Thursday, October 13, 2011 10:13 AM > >> 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. > > Changed 'MAY allow' to 'MAY support'. Clarified the TLS requirement for sending passwords. > >> (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 >> cipher suites 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 cipher >> suites are MUSTs. I think you might need to pick cipher suites for each >> version if you want some combination of tls1.0 and tls1.2 and need server >> auth at least. > > Replaced ' transport-layer' with TLS with reference to the new section. > >> (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.) > > This has been resolved by the chair and adjusted as such. > >> (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. > > Removed the space-delimited text from the end of the response_type parameter definition and added the following immediate after: > > Extension response types MAY contain a space-delimited (%x20) list of values, where the > order of values does not matter (e.g. response type"a b" is > the same as "b a"). The meaning of such composite response > types is defined by their respective specifications. > >> (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. > > I took that last paragraph out. Client mitigation isn't really practical here. > >> (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. > > Took 'trust' out. > >> (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. > > No change as resolved by the chair. > >> (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.) > > Added to each section: > > [Access token credentials | Refresh tokens] MUST only be transmitted using TLS as described > in with server authentication as defined by. > >> (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? > > Took that sentence out. Added no value. > >> (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.) > > Per the requirement in the thread-model document, replaced with the following: > > Generated tokens and other credentials not intended for handling by end-users MUST be > constructed from a cryptographically strong random or pseudo-random number sequence > () generated by the authorization server. The probability of any > two values being identical MUST be less than or equal to 2^(-128) and SHOULD be less than > or equal to 2^(-160). > > Added a reference to 10.10 from 10.12. > >> (11) Section 11 says a couple of times that the apps ADs are the appeal chain - >> shouldn't that be the SEC ADs now? > > Fixed. > >> 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. > > Added to section 2.1: > > A client application consisting of multiple components, each with its own client type > (e.g. a distributed client with both a confidential server-based component and a public > browser-based component), MUST register each component separately as a different client > to ensure proper handling by the authorization server. The authorization server MAY > provider tools to manage such complex clients through a single administration interface. > >> (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? > > Not sure I understand this, but how passwords are handled is outside the scope. Basically, the user-agent is sent to the endpoint and the server shows some kind of form. How that form is submitted is not part of OAuth is not part of the form encoding described. The form encoding mentioned is just about inputs send to the server before any login prompt. > > If this is not clear, please let me know. > >> (3) Generally, the specification is a bit unclear about what each component >> MUST do, it's 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. > > We've got feedback from people who just read the spec without being involved here (most of it in the past couple of months) and it did not raise this issue. > >> (4) Is it clear that a client always knows when a redirection request will result >> in sensitive 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. > > Changed to: > > The redirection endpoint SHOULD require the use of TLS as described in > when the requested response type is > "code" or "token", or when the redirection request will result in the transmission of sensitive credentials > over an open network. > >> (5) 3.1.2.2 says AS'es 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. > > Because this is not an interop issue. The number of supported redirection URIs is a matter of configuration. Until we have an spec for interop on that side, we don't need to prescribe it. Most 1.0 sites today support only one. > >> (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? > > I assume you are asking why isn't this a MUST NOT? > > That sentence is a little bit tongue-in-cheek... In 3.1.2.2 we say that unregistered endpoints SHOULD NOT be allowed and this one is a way of saying why they are bad in a twisted way. After reading it again, I took that line out and added this to 3.1.2.2: > > Lack of a redirection URI registration requirement can enable an attacker to use > the authorization endpoint as open redirector as described in > . > >> (7) Can a client really ensure that other scripts don't go before its own as >> required in 3.1.2.5? > > Yes, for example, by using multiple endpoints chained in the right order. > >> (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. > > Dropped that line. 10.1 already covers this. > >> (9) Does the recent list discussion about scope encoding require any changes >> to 3.3? > > Yep. Been applied. > >> (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.) > > No reason. I originally put it in as a SHOULD because scope was more of an nice idea than an important feature. This should probably be changed to MUST. Not going to make this change now, but will if the WG would like to. Will bring up in another thread. > >> (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. > > Added to 10.8: > > The "state" and "scope" parameters > SHOULD NOT include sensitive client or resource owner information in plain text as they > can be transmitted over insecure channels or stored insecurely. > >> (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;-) > > Yeah... > > This specification sucks when it comes to prescribing interoperable behavior. At this point the biggest reason people hate OAuth 1.0 is not the crypto but that every server implementation is different. Wait until they experience 2.0... But unfortunately this is as far as this WG was able to agree. WG participants didn't want to come together and agree but to make sure they will be able to implement their own unique use cases (and screw interop). > > I think the only hope moving forward is for someone to publish a profile that is tight and restrictive and see if it gains traction. > > Yeah, I'm bitter about the quality of this work after investing 4 years into it, but that's life. > >> (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? > > Don't know anything about this. Will bring up in another thread. > > (To be continued...) > > EHL > From igor.faynberg@alcatel-lucent.com Fri Jan 20 16:39:38 2012 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 6BAA411E8073 for ; Fri, 20 Jan 2012 16:39:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.598 X-Spam-Level: X-Spam-Status: No, score=-8.598 tagged_above=-999 required=5 tests=[AWL=2.000, 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 I0zzH1LkKNc8 for ; Fri, 20 Jan 2012 16:39:37 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 522F411E8071 for ; Fri, 20 Jan 2012 16:39:37 -0800 (PST) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q0L0daaG005830 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 20 Jan 2012 18:39:36 -0600 (CST) 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 q0L0dZsQ017453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 20 Jan 2012 18:39:36 -0600 Received: from [135.244.1.84] (faynberg.lra.lucent.com [135.244.1.84]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q0L0dZAt011812; Fri, 20 Jan 2012 18:39:35 -0600 (CST) Message-ID: <4F1A0947.5080107@alcatel-lucent.com> Date: Fri, 20 Jan 2012 19:39:35 -0500 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: <90C41DD21FB7C64BB94121FBBC2E723453AAB96537@P3PW5EX1MB01.EX1.SECURESERVER.NET> <35BD8E89-A024-4034-8E89-95F4814F9C6C@gmail.com> In-Reply-To: <35BD8E89-A024-4034-8E89-95F4814F9C6C@gmail.com> Content-Type: multipart/alternative; boundary="------------060704020706060205020900" X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: Re: [OAUTH-WG] SHOULD vs MUST for indicating scope on response when different from client 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: Sat, 21 Jan 2012 00:39:38 -0000 This is a multi-part message in MIME format. --------------060704020706060205020900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit +1 for MUST. In addition, I suggest slight rewarding: "the authorization server MUST include the value of the scope parameter in the response" in place of " the authorization server SHOULD include the "scope" response parameter " I think there is one parameter, scope, right? Igor On 1/20/2012 6:50 PM, Dick Hardt wrote: > +! > > On Jan 20, 2012, at 4:20 PM, Torsten Lodderstedt wrote: > >> MUST sounds reasonable >> >> >> >> Eran Hammer > schrieb: >> >> The current text: >> If the issued access token scope >> is different from the one requested by the client, the >> authorization >> server SHOULD include the "scope" response parameter to inform the >> client of the actual scope granted. >> Stephen asked why not a MUST. I think it should be MUST. Any >> disagreement? >> EHL >> >> _______________________________________________ >> 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 --------------060704020706060205020900 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit +1 for MUST.

In addition, I suggest slight rewarding: "the authorization server MUST include  the value of  the  scope  parameter in the response" in place of
"
the authorization
   server SHOULD include the "scope" response parameter
"


I think there is one parameter, scope, right?

Igor


On 1/20/2012 6:50 PM, Dick Hardt wrote:
+!

On Jan 20, 2012, at 4:20 PM, Torsten Lodderstedt wrote:

MUST sounds reasonable 



Eran Hammer <eran@hueniverse.com> schrieb:
The current text:
 
   If the issued access token scope
   is different from the one requested by the client, the authorization
   server SHOULD include the "scope" response parameter to inform the
   client of the actual scope granted.
 
Stephen asked why not a MUST. I think it should be MUST. Any disagreement?
 
EHL
 
_______________________________________________
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
--------------060704020706060205020900-- From eran@hueniverse.com Fri Jan 20 17:04:29 2012 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 BE10921F856F for ; Fri, 20 Jan 2012 17:04:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.871 X-Spam-Level: X-Spam-Status: No, score=-1.871 tagged_above=-999 required=5 tests=[AWL=-0.472, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, J_CHICKENPOX_35=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 QGREvWqegynR for ; Fri, 20 Jan 2012 17:04:28 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id A407621F856C for ; Fri, 20 Jan 2012 17:04:28 -0800 (PST) Received: (qmail 13919 invoked from network); 21 Jan 2012 01:04:27 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 21 Jan 2012 01:04:27 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Fri, 20 Jan 2012 18:04:27 -0700 From: Eran Hammer To: OAuth WG Date: Fri, 20 Jan 2012 18:04:17 -0700 Thread-Topic: AD Review of -22 (part II) Thread-Index: AczXzezFz/6KwlD5Sz6HqyDpokz7nA== Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453AAB96544@P3PW5EX1MB01.EX1.SECURESERVER.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] AD Review of -22 (part II) 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, 21 Jan 2012 01:04:29 -0000 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Stephen Farrell > Sent: Thursday, October 13, 2011 10:13 AM > Suggested non-trivial clarifications: > ------------------------------------- >=20 > (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 thin= k that > making it clear that the normal mode for client developers is to work aga= inst > an existing service (AS and resource server) would help to clarify that s= uch > arrangements are ok here. Added new 'Interoperability' section to the introduction: OAuth 2.0 provides a rich authorization framework with well-defin= ed security properties. However, as a rich and highly extensible framework with many opti= onal components, this specification is likely to produce a wide range of non-interopera= ble implementations. In addition, this specification leaves a few required components = partially or fully undefined (e.g. client registration, authorization server capabil= ities, endpoint discovery). This protocol was design with the clear expectation that future w= ork will define prescriptive profiles and extensions necessary to achieve full we= b-scale interoperability. =20 There is no way to sugar coat reality and hopefully by being blunt about it= upfront, we will avoid a prolonged debate about the protocol's failings in= that regard. > (2) p11, in step (F) is there a way to distinguish between an access toke= n 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. That depends on the token specification. Steps C-F are outside the scope of= this document. I'll note that. =20 > (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 protoco= l > here. The entire section 2 is 'Client Registration' which is described as out of = scope for implementation details. =20 > (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 r= efresh > token issuance is covered (I guess it is). Changed to 'when sending requests using password authentication'. > (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. Not enough to be worth the change. > (6) 3.1.2.2 states the rules for when AS'es are to require registration o= f > redirection URIs. I think you need to clarify that some. First, you use t= he term > "redirection_uri" for both a "complete" URI and for a scheme/authority/pa= th > 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.=A0 I do think it could be made clearer by putting the MUST up fr= ont > and separating issues related to complete URI and triples separately from= the > when something MUST be registered. New text: The authorization server MUST require the following clients to register their redirection endpoint: o Public clients. o Confidential clients utilizing the implicit grant type. The authorization server SHOULD require all clients to register their redirection endpoint prior to utilizing the authorization endpoint The authorization server SHOULD require the client to provide the complete redirection URI (the client MAY use the "state" request parameter to achieve per-request customization). If requiring the registration of the complete redirection URI is not possible, the authorization server SHOULD require the registration of the URI scheme, authority, and path (allowing the client to dynamically vary only the query component of the redirection URI when requesting authorization). The authorization server MAY allow the client to register multiple redirection endpoints. Lack of a redirection URI registration requirement can enable an attacker to use the authorization endpoint as open redirector as described in Section 10.15. > (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? The reference is not for the OPTIONAL definition. I changed the coma to a p= eriod. >=A0 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. Organizing the text fo= r 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 minimize the number of pointers in general? We've gone back and forth on this for 22 drafts and this is the best balanc= e between readability and consistency we found. I'm inclined to avoid anoth= er reshuffle. > 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 consistent at the TOC level. Because 4.3 doesn't use the authorization endpoint. > (8) How can the AS protect against brute force attacks in 4.3.2?=A0 I thi= nk 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. Ok. > (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.=A0 Can you not add a hint or reference here? The WG sentiment was that server developers do not require as much hand hol= ding as the client developers. If the authors of the original text want to = propose text, I'm happy to include it. >=20 > Some nits: (Stuff that seemed more serious at first:-) > --------- >=20 > (1) In 2.3.1 I think you're ruling out putting the client_id and client_s= ecret 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. Added: The parameters can only be transmitted in the request body and M= UST NOT be included in the request URI > (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. I think you mean 3.1.2. Added. > (3) In 4.1.2 what does it mean to "attempt" to revoke tokens?=A0 Why can'= t the > AS just revoke them? (Where revoke =3D=3D not accept them when they are > next presented, right?) Can't revoke self-encoded tokens (e.g. stateless on the server). Changed 'a= ttempt' to 'when possible' > (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 eith= er > 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 o= therwise > crap requests to probe for good state values.) s/valid// I think? Yep. =20 > (5) I don't get the benefit of saying the client SHOULD ignore unknown fi= elds > 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 MUS= T > ignore. Changed all 'ignore' to MUST. =20 > (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 oth= er > than the issuer? If not, then is this just saying "don't make a mistake"? No. It's a security concern that developer might decide to be flexible and = provider a refresh token in addition to an access token using this flow. > (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"? Changed 'parameters' to 'value names in the response'. > (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 t= hat > TLS+users actually checking server identity reduces the risk of successfu= l > phishes? I think that's a bit different. (I do like the MUST though.) Dropped 'phishing'. If the authors of the original text would like to expla= in, I'll put it back in. (To be continued...) EHL From stephen.farrell@cs.tcd.ie Fri Jan 20 17:11:41 2012 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 0302121F85AE for ; Fri, 20 Jan 2012 17:11:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.934 X-Spam-Level: X-Spam-Status: No, score=-101.934 tagged_above=-999 required=5 tests=[AWL=-0.535, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, J_CHICKENPOX_35=0.6, 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 LtW8zlc3XbfY for ; Fri, 20 Jan 2012 17:11:39 -0800 (PST) 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 99BA421F859E for ; Fri, 20 Jan 2012 17:11:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id E77CA171CF1; Sat, 21 Jan 2012 01:11:38 +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=1327108298; bh=/Oe/4yNibrkEO7 ITMcld2TkmcnMs140XwXv+pXw7ie4=; b=5Lhncix3qOunyehBm5PmbXdXQK59y7 ocQ3Znoigg5uo6E5GHPOuodSV0RoB9dYzzXSUoFoT/NhSvuErQ0Neo7B/nJXs+2C UuPBtQHbiRt/0YQVqsMXQ2cvQ25ZH7A/l1l4q3UQhGtsUTJAgc6DHuhz8d7Frf7g ZCnwQU2GsypaSW3BF6a95f8REp1xgbMXRlGL0i591rJOhlBlfTWA2P+euQp30L/l c/d+o/rIg8aBy960WfK69e68RHLPlTO75SoC/spMzYV30XZAAFf7ZLXi1JgMrLUL ghsFkOkeh6CjKP9MfFIa/2B5IldOWzti5Qoiavs8a0U14U3JSkCDxv6g== 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 B4OJD-GlPSeM; Sat, 21 Jan 2012 01:11:38 +0000 (GMT) Received: from [10.87.48.5] (unknown [86.41.8.14]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 29D0D171C1A; Sat, 21 Jan 2012 01:11:38 +0000 (GMT) Message-ID: <4F1A10C9.3060800@cs.tcd.ie> Date: Sat, 21 Jan 2012 01:11:37 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Eran Hammer References: <90C41DD21FB7C64BB94121FBBC2E723453AAB96544@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453AAB96544@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: OAuth WG Subject: Re: [OAUTH-WG] AD Review of -22 (part II) 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, 21 Jan 2012 01:11:41 -0000 Same response as for part I from me, S On 01/21/2012 01:04 AM, Eran Hammer wrote: >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Stephen Farrell >> Sent: Thursday, October 13, 2011 10:13 AM > >> 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. > > Added new 'Interoperability' section to the introduction: > > OAuth 2.0 provides a rich authorization framework with well-defined security properties. > However, as a rich and highly extensible framework with many optional components, this > specification is likely to produce a wide range of non-interoperable implementations. > In addition, this specification leaves a few required components partially or fully > undefined (e.g. client registration, authorization server capabilities, endpoint > discovery). > > This protocol was design with the clear expectation that future work will define > prescriptive profiles and extensions necessary to achieve full web-scale > interoperability. > > There is no way to sugar coat reality and hopefully by being blunt about it upfront, we will avoid a prolonged debate about the protocol's failings in that regard. > >> (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. > > That depends on the token specification. Steps C-F are outside the scope of this document. I'll note that. > >> (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. > > The entire section 2 is 'Client Registration' which is described as out of scope for implementation details. > >> (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). > > Changed to 'when sending requests using password authentication'. > >> (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. > > Not enough to be worth the change. > >> (6) 3.1.2.2 states the rules for when AS'es 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. > > New text: > > The authorization server MUST require the following clients to > register their redirection endpoint: > > o Public clients. > o Confidential clients utilizing the implicit grant type. > > The authorization server SHOULD require all clients to register their > redirection endpoint prior to utilizing the authorization endpoint > > The authorization server SHOULD require the client to provide the > complete redirection URI (the client MAY use the "state" request > parameter to achieve per-request customization). If requiring the > registration of the complete redirection URI is not possible, the > authorization server SHOULD require the registration of the URI > scheme, authority, and path (allowing the client to dynamically vary > only the query component of the redirection URI when requesting > authorization). > > The authorization server MAY allow the client to register multiple > redirection endpoints. > > Lack of a redirection URI registration requirement can enable an > attacker to use the authorization endpoint as open redirector as > described in Section 10.15. > >> (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? > > The reference is not for the OPTIONAL definition. I changed the coma to a period. > >> 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. Organizing 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 minimize the number of pointers in general? > > We've gone back and forth on this for 22 drafts and this is the best balance between readability and consistency we found. I'm inclined to avoid another reshuffle. > >> 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 consistent at the TOC level. > > Because 4.3 doesn't use the authorization endpoint. > >> (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. > > Ok. > >> (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? > > The WG sentiment was that server developers do not require as much hand holding as the client developers. If the authors of the original text want to propose text, I'm happy to include it. > >> >> 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. > > Added: > > The parameters can only be transmitted in the request body and MUST NOT be included in the > request URI > >> (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. > > I think you mean 3.1.2. Added. > >> (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?) > > Can't revoke self-encoded tokens (e.g. stateless on the server). Changed 'attempt' to 'when possible' > >> (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? > > Yep. > >> (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. > > Changed all 'ignore' to MUST. > >> (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"? > > No. It's a security concern that developer might decide to be flexible and provider a refresh token in addition to an access token using this flow. > >> (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"? > > Changed 'parameters' to 'value names in the response'. > >> (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.) > > Dropped 'phishing'. If the authors of the original text would like to explain, I'll put it back in. > > (To be continued...) > > EHL > > From ve7jtb@ve7jtb.com Fri Jan 20 17:22:39 2012 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 CAB0B21F85D8 for ; Fri, 20 Jan 2012 17:22:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.9 X-Spam-Level: X-Spam-Status: No, score=-2.9 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 2xYtuFB1iSlM for ; Fri, 20 Jan 2012 17:22:39 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id C23DF21F854B for ; Fri, 20 Jan 2012 17:22:06 -0800 (PST) Received: by ghbg16 with SMTP id g16so130686ghb.31 for ; Fri, 20 Jan 2012 17:22:04 -0800 (PST) Received: by 10.236.139.234 with SMTP id c70mr99027yhj.33.1327108924667; Fri, 20 Jan 2012 17:22:04 -0800 (PST) Received: from [192.168.1.214] ([190.22.42.52]) by mx.google.com with ESMTPS id s7sm13196125anc.4.2012.01.20.17.22.01 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 20 Jan 2012 17:22:03 -0800 (PST) References: <90C41DD21FB7C64BB94121FBBC2E723453AAB96537@P3PW5EX1MB01.EX1.SECURESERVER.NET> <35BD8E89-A024-4034-8E89-95F4814F9C6C@gmail.com> In-Reply-To: <35BD8E89-A024-4034-8E89-95F4814F9C6C@gmail.com> Mime-Version: 1.0 (1.0) Message-Id: X-Mailer: iPhone Mail (9A405) From: John Bradley Date: Fri, 20 Jan 2012 22:22:00 -0300 To: Dick Hardt X-Gm-Message-State: ALoCoQnuyqJL7cHizbGSwEV4n5/5TusJTQiKVo+MJGjvPd0/KGOMtJx02/ykb4RJRCDRhjRFP8r7 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-58EE276B-8E3B-4881-A755-7BE2B6855A90 Cc: OAuth WG Subject: Re: [OAUTH-WG] SHOULD vs MUST for indicating scope on response when different from client 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: Sat, 21 Jan 2012 01:22:39 -0000 --Apple-Mail-58EE276B-8E3B-4881-A755-7BE2B6855A90 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii +1 Sent from my iPhone On 2012-01-20, at 8:50 PM, Dick Hardt wrote: > +! > > On Jan 20, 2012, at 4:20 PM, Torsten Lodderstedt wrote: > >> MUST sounds reasonable >> >> >> >> Eran Hammer schrieb: >> The current text: >> >> If the issued access token scope >> is different from the one requested by the client, the authorization >> server SHOULD include the "scope" response parameter to inform the >> client of the actual scope granted. >> >> Stephen asked why not a MUST. I think it should be MUST. Any disagreement? >> >> EHL >> >> _______________________________________________ >> 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-58EE276B-8E3B-4881-A755-7BE2B6855A90 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
+1

Sent from my iPh= one

On 2012-01-20, at 8:50 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

+!
<= br>
On Jan 20, 2012, at 4:20 PM, Torsten Lodderstedt wrote:
MUST sounds reasonable 


<= br>Eran Hammer <eran@hueniverse.com> schrieb:
The current text:<= /div>
<= o:p> 
   If the issued access= token scope
   is dif= ferent from the one requested by the client, the authorization
   server SHOULD include the "scope"= response parameter to inform the
   client of the actual scope granted.
&nbs= p;
Stephen asked why not a MUST. I think it should be MUST. Any disagre= ement?
 
EHL
 
_______________________________________________
OAuth= mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth

_______________________________= ________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo= /oauth
= --Apple-Mail-58EE276B-8E3B-4881-A755-7BE2B6855A90-- From eran@hueniverse.com Fri Jan 20 18:53:20 2012 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 9B65011E8079 for ; Fri, 20 Jan 2012 18:53:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=0.144, 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 oDh7XJKvIdlG for ; Fri, 20 Jan 2012 18:53:19 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id B9C1611E8074 for ; Fri, 20 Jan 2012 18:53:19 -0800 (PST) Received: (qmail 10300 invoked from network); 21 Jan 2012 02:53:18 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.47) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 21 Jan 2012 02:53:18 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT005.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Fri, 20 Jan 2012 19:53:18 -0700 From: Eran Hammer To: OAuth WG Date: Fri, 20 Jan 2012 19:53:07 -0700 Thread-Topic: AD Review of -22 (part III) Thread-Index: AczX2J0FfS5+S2a1TVm6IGu2lwu30g== Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453AAB96548@P3PW5EX1MB01.EX1.SECURESERVER.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] AD Review of -22 (part III) 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, 21 Jan 2012 02:53:20 -0000 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Stephen Farrell > Sent: Thursday, October 13, 2011 10:13 AM > Original list of nits: > ---------------------- >=20 > - 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 norm= ally > (running on) a web server. Happy to take suggestions, but can't come up with a useful diagram myself. Added to the client definition: The term client does not imply any particular implementation characteristics (e.g. whether the application executes on a s= erver, a desktop, or other devices). > - p4: Maybe s/a string/an octet string/ in the token descriptions, unless= the > access token encoding is constrained to what'd be understood as a string. Just a string. > - p8: Seems odd to speak of "issuing" an implicit grant - wouldn't that m= ake > something explicit? Maybe say "With an implicit grant..." > instead in the 2nd para of 1.3.2? Changed to 'When issuing an access token during the implicit grant flow'. > - p8: I don't get what "its device operating system" means. Do you mean t= he > client is an already-trusted part of the resource owner's device OS? Changed to 'the client is part of the device operating system'. =20 > - p9 - "Issuing a refresh token is optional" - might be better to say tha= t it's the > authorization server's choice and there's no way for the client to signal= a > request for one. Changed to 'Issuing a refresh token is optional at the discretion of the au= thorization server.' > - 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 pr= otocol > options and say that the refresh token is optional in (B) as well. Because this is the refresh token flow. If it is optional, there is no flow= ... > - p12 - the confidential/public terminology isn't great, did the WG consi= der > "authenticating" vs. "non-authenticating"? Trying again to find better te= rms > would maybe be worthwhile. Didn't try this particular alternative, but it doesn't flow off my tongue.= =20 > Also, it may be worth explicitly saying that it > doesn'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 the= n > 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 m= ore > here. This seems to be cross the line as to what the server defines as confidenti= al, but I'm happy to take text proposals. > - p12/13 in the application profile descriptions - is "resource owner's d= evice" > correct? That seems to rule out kiosks, which may be correct, but which i= sn't > obvious. Maybe you mean "device being used by the resource owner" with > no implication as to ownership of the device? Changed to 'the device used by the resource owner' throughout. > - p13 - client application: typos: >=20 > s/such access tokens/such as access tokens/ >=20 > s/which...interact with/with which the application may interact/ Ok. > - p13, "establishing trust with the client or its developer" is badly phr= ased, I > think you mean the AS SHOULD NOT just accept the client type unless it ha= s > some external reason to do so. Trusting the developer might be one such. > Being paid is another, and maybe more likely;-) Changed to: The authorization server SHOULD NOT make assumptions about the cl= ient type, nor accept the type information provided by the client developer without first e= stablishing trust. > - p13, 2.3 has 2119 language both about the things established at registr= ation > 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. Tweaked a bit, but overall it reads fine to me. > - 3.1.2.1 has a SHOULD for TLS which I think generated a lot of mail on t= he list. > I think saying why this is not a MUST would be useful, since it's the kin= d of > thing that might get revised later on if the situation changes. This specification does not mandate the use of TLS because at= the time of this writing, requiring clients to deploy TLS is a si= gnificant hurdle for most client developers. > - Figure 3, (p21) has multiple lines labeled A,B & C - saying why might r= educe > 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 f= igure > 3 they're addressing, e.g. > 4.1.1 maps to (A), right? It's hard to tell. Added clarification about the broken lines. > -p25, 4.1.3, what does "assigned" "authentication requirements" > mean? Suggest deleting the parenthetical clause since "confidential clien= t" > should be sufficiently well-defined to cover that. Ok. > -p28, the description of step (D) isn't clear to me - who does what with = the > URI fragment? Seems pretty clear to me. > -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 abo= ut > that. Same para: s/such client/such clients/ Changed to UA. > -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?=A0 Is there a re-tx thing that the clien= t might > do? Nope. > -p38, is "token_type":"example" a valid value? If not, better to use one = that > is. I refuse to use Bearer as an example and I expect others to take issue with= using MAC :-) > -p40, s/client it was issued/client to which it was issued/?' Ok. > -p40, s/require/REQUIRE/ in the 2nd last bullet on the page Require isn't an uppercase word (REQUIRED is). > -p43, s/native clients may require/native clients require/ I'd say the "m= ay" is > worth deleting both to avoid 2119 language and because we do know that > these require special consideration. Ok. > -p46, s/such malicious clients/such potentially malicious clients/? > Not all unauthenticated clients are bad, though all of them could be bad. Ok. > -p47, s/Access token (as well as.../Access tokens (as well as.../ Ok. > -p50, 10.8 seems to just repeat stuff from earlier in 10.3 & 10.4, is tha= t > deliberate? The requirements are but the context is different. This concludes this review and all other -22 feedback. EHL From internet-drafts@ietf.org Fri Jan 20 19:05:18 2012 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 624F211E8074; Fri, 20 Jan 2012 19:05:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 IZeuVvPXBU6l; Fri, 20 Jan 2012 19:05:17 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E786C21F860B; Fri, 20 Jan 2012 19:05:17 -0800 (PST) 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.64p1 Message-ID: <20120121030517.26403.30113.idtracker@ietfa.amsl.com> Date: Fri, 20 Jan 2012 19:05:17 -0800 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-23.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: Sat, 21 Jan 2012 03:05:18 -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 Author(s) : Eran Hammer David Recordon Dick Hardt Filename : draft-ietf-oauth-v2-23.txt Pages : 65 Date : 2012-01-20 The OAuth 2.0 authorization protocol enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-23.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-23.txt From eran@hueniverse.com Fri Jan 20 19:09:31 2012 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 B878C21F86B0 for ; Fri, 20 Jan 2012 19:09:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.46 X-Spam-Level: X-Spam-Status: No, score=-2.46 tagged_above=-999 required=5 tests=[AWL=0.139, 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 vKPgMLXGQqeR for ; Fri, 20 Jan 2012 19:09:31 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 3704721F86A4 for ; Fri, 20 Jan 2012 19:09:31 -0800 (PST) Received: (qmail 5912 invoked from network); 21 Jan 2012 03:09:30 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 21 Jan 2012 03:09:30 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Fri, 20 Jan 2012 20:09:30 -0700 From: Eran Hammer To: "oauth@ietf.org" Date: Fri, 20 Jan 2012 20:09:19 -0700 Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-23.txt Thread-Index: AczX6Z3g1mkKO27aQAOK50lJ52B7wgAABqNg Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453AAB9654A@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <20120121030517.26403.30113.idtracker@ietfa.amsl.com> In-Reply-To: <20120121030517.26403.30113.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-23.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: Sat, 21 Jan 2012 03:09:31 -0000 This is ready for IETF LC and closes all open issues. There is one pending question (title 'Server cret verification in 10.9') wh= ich is non-blocking and can be resolve after LC. Chairs - per green light from Stephen posted earlier, please push the LC re= quest. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of internet-drafts@ietf.org > Sent: Friday, January 20, 2012 7:05 PM > To: i-d-announce@ietf.org > Cc: oauth@ietf.org > Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-23.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Web Authorization Protocol Working Group= of > the IETF. >=20 > Title : The OAuth 2.0 Authorization Protocol > Author(s) : Eran Hammer > David Recordon > Dick Hardt > Filename : draft-ietf-oauth-v2-23.txt > Pages : 65 > Date : 2012-01-20 >=20 > The OAuth 2.0 authorization protocol enables a third-party > application to obtain limited access to an HTTP service, either on > behalf of a resource owner by orchestrating an approval interaction > between the resource owner and the HTTP service, or by allowing the > third-party application to obtain access on its own behalf. This > specification replaces and obsoletes the OAuth 1.0 protocol described > in RFC 5849. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-23.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-v2-23.txt >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From wmills@yahoo-inc.com Fri Jan 20 21:03:01 2012 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 D9EE621F8499 for ; Fri, 20 Jan 2012 21:03:01 -0800 (PST) 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 pEaZwU2fG7vh for ; Fri, 20 Jan 2012 21:03:00 -0800 (PST) Received: from nm39-vm2.bullet.mail.ne1.yahoo.com (nm39-vm2.bullet.mail.ne1.yahoo.com [98.138.229.162]) by ietfa.amsl.com (Postfix) with SMTP id 1868C21F8498 for ; Fri, 20 Jan 2012 21:02:59 -0800 (PST) Received: from [98.138.90.56] by nm39.bullet.mail.ne1.yahoo.com with NNFMP; 21 Jan 2012 05:02:56 -0000 Received: from [98.138.89.245] by tm9.bullet.mail.ne1.yahoo.com with NNFMP; 21 Jan 2012 05:02:56 -0000 Received: from [127.0.0.1] by omp1059.mail.ne1.yahoo.com with NNFMP; 21 Jan 2012 05:02:56 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 805731.37815.bm@omp1059.mail.ne1.yahoo.com Received: (qmail 16876 invoked by uid 60001); 21 Jan 2012 05:02:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1327122176; bh=kZej4mjyPTW/qbqU4Xo4Px7NOtiP3ZAPQrRQiWBPBLo=; 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=Ic+hi499vnsPgNkAiaZdMD9JuXv/Xt7GA3v9NT2DDvjJ/r2VmvIE2+yAoHHe85bfof4Tuy3Vwf3jdOdJ4VyyrMsj0HGiM904MwwkEieHtkbWdiaWMCyv3cWvc6k809mUSjsXgKBccx4T+2zlNIxSWbEUAF/+iZs3fgt7Lmz1RPQ= 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=r6xLoqTTZebLZq0MxPLrWQ0Ai0XhXuD1iRM/dOfqIf9Bi9N5bUzRixJiJkqqXWv92HWpIo/nTwIDWNFWyIOXqSrgxbXzKNwPCmeDGpzLF0tPRHcOFbK1PemehdbdcnWHJ+ZI0ug/3ftoNrXj4UCeeu2iqdjsVQOYQgHC0KoI8Qw=; X-YMail-OSG: DHUrL_oVM1npNoLg85za8..L1V_uiSU29XssbTnQMoBFVs0 qEKXp2_Ix7gPr_AQdOizUBnqbgi11LNw2ufALgGfSvVpYkm1U8Wr4HHIBvG1 nl0_w7WwPEl3mUd17YE4GlDr9c.RQ0A2BQ1Je6WMW5CzCe5phamJYVpUm_pM OOUHPc0VwMVCd9xAaomzpZe6qMAaV0O.lDOwLJvUlZrXaujndBBdYVej6P.r gLyn41v2jueJCf56FN2A98GS1FzRtXgUgLq6cPW8Fg7lfPo_E9nZoQleekkT gqwuIycgO64gTDv900weLuRvBN.IwWzR2SdyvySmfF8rb8SQaVeozdRuMRdT 6Fra0px4N65Z.3Wmm7MCz2zd6ciJy5c5JO_n1PqUG4QXPNa_t4yQ9n30tTe. bZLCT67HKE02iHItx54in.XGaXrM6eDESTlSpmqaO6zfH4EYzcNf3UpIaJuT P4C4d1rxIbRRYJvNfmFWV9p9J6wpJZ.vMOsP4yhvWzL.x Received: from [99.31.212.42] by web31809.mail.mud.yahoo.com via HTTP; Fri, 20 Jan 2012 21:02:56 PST X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.116.338427 References: <6.2.5.6.2.20120109070921.0aec8d00@resistor.net> <6.2.5.6.2.20120109153323.0ab3bf80@resistor.net> <1326156786.88572.YahooMailNeo@web31812.mail.mud.yahoo.com> <1326160314.71861.YahooMailNeo@web31806.mail.mud.yahoo.com> <1326162276.40306.YahooMailNeo@web31811.mail.mud.yahoo.com> <1326215997.44445.YahooMailNeo@web31816.mail.mud.yahoo.com> <6.2.5.6.2.20120110104038.099f1ba8@resistor.net> <90C41DD21FB7C64BB94121FBBC2E723453A72D0F24@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1326240141.98332.YahooMailNeo@web31808.mail.mud .yahoo.com> <90C41DD21FB7C64BB94121FBBC2E723453A72D0F60@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1326268674.20557.YahooMailNeo@web31807.mail.mud.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E723453AAB964E7@P3PW5EX1MB01.EX1.SECURESERVER.NET> Message-ID: <1327122176.2902.YahooMailNeo@web31809.mail.mud.yahoo.com> Date: Fri, 20 Jan 2012 21:02:56 -0800 (PST) From: William Mills To: Eran Hammer , "oauth@ietf.org" In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453AAB964E7@P3PW5EX1MB01.EX1.SECURESERVER.NET> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1395015409-2109497095-1327122176=:2902" Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification 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, 21 Jan 2012 05:03:02 -0000 ---1395015409-2109497095-1327122176=:2902 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Works for me.=0A=0A=0A=0A________________________________=0A From: Eran Ham= mer =0ATo: William Mills ; "oaut= h@ietf.org" =0ASent: Friday, January 20, 2012 12:32 PM=0AS= ubject: RE: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specif= ication=0A =0A=0ANew text added to Access Token Scope section:=0A=C2=A0=0A= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If the client omits = the scope parameter when requesting authorization, the authorization=0A=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 server MUST process the= request using a pre-defined default value, or fail the request=0A=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 indicating an invalid scope. = The authorization server SHOULD document its scope=0A=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 requirements and default value (if define= d).=0A=C2=A0=0A=C2=A0=0AEHL=0A=C2=A0=0AFrom:William Mills [mailto:wmills@ya= hoo-inc.com] =0ASent: Tuesday, January 10, 2012 11:58 PM=0ATo: Eran Hammer;= oauth@ietf.org=0ASubject: Re: [OAUTH-WG] Seeking Clarification: Potential = Ambiguity in Specification=0A=C2=A0=0A"Null string", "empty string", or "se= rver defined default value" all work.=C2=A0 Default scope doesn't do it for= me.=0A=C2=A0=0A=0A________________________________=0A=0AFrom:Eran Hammer <= eran@hueniverse.com>=0ATo: William Mills ; "oauth@iet= f.org" =0ASent: Tuesday, January 10, 2012 5:24 PM=0ASubjec= t: RE: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specificati= on=0A=C2=A0=0AI don=E2=80=99t like =E2=80=98empty scope=E2=80=99 as it is u= ndefined. I prefer =E2=80=98default scope=E2=80=99.=0A=C2=A0=0AEHL=0A=C2=A0= =0AFrom:William Mills [mailto:wmills@yahoo-inc.com] =0ASent: Tuesday, Janua= ry 10, 2012 4:02 PM=0ATo: Eran Hammer; oauth@ietf.org=0ASubject: Re: [OAUTH= -WG] Seeking Clarification: Potential Ambiguity in Specification=0A=C2=A0= =0AOn your #1, I don't agree that an empty scope is useless.=C2=A0 There ar= e comparable implementations that use an empty scope to be a wildcard scope= .=C2=A0 I'd say, =0A=C2=A0=0A"The client can MAY include or omit the scope = parameter. If omitted, the server must process the request using an empty s= cope as the default.=C2=A0 The server then processes the request either iss= uing a grant with it's default scope as defined by the server or failing th= e request indicating an invalid scope requested."=0A=C2=A0=0AThat language = isn't quite right, but I think it's clear.=0A=C2=A0=0A=0A__________________= ______________=0A=0AFrom:Eran Hammer =0ATo: "oauth@iet= f.org" =0ASent: Tuesday, January 10, 2012 1:15 PM=0ASubjec= t: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specificati= on=0A=0AI don't think the issue here is about the scope value, but who does= the OPTIONAL designation applies to. IOW, is it optional for the server to= support/require it, or is it optional for the client to include or omit it= .=0A=0AThe intention was to make it optional for the authorization server t= o make all decisions about the parameter, including making it required. But= the text is confusing since the text is aimed directly at the client when = making the request.=0A=0AWe need to clarify this and the options are:=0A=0A= 1. The client can decide if they want to include or omit the scope paramete= r. If omitted, the server must process the request using some documented de= fault scope. This default scope can be an empty scope rendering the token u= seless for anything other than verifying user authentication.=0A=0A2. The s= erver can declare scope to be a required parameter in which case the client= must include it or the request will fail. In this case, we should make the= text clearer that clients to find out if the particular server requires it= .=0A=0A#1 is better for interoperability, #2 is more in the spirit of the p= arameter discussions so far.=0A=0AEHL=0A=0A> -----Original Message-----=0A>= From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf=0A>= Of Phil Hunt=0A> Sent: Tuesday, January 10, 2012 11:33 AM=0A> To: SM=0A> C= c: oauth@ietf.org=0A> Subject: Re: [OAUTH-WG] Seeking Clarification: Potent= ial Ambiguity in=0A> Specification=0A> =0A> The underlying issue is that th= ere was a decision not to in any way=0A> standardize values for scope.=0A> = =0A> I agreed this was reasonable since the underlying resource APIs are li= kely to=0A> be very specific requiring some degree of prior knowledge by th= e client app=0A> developer. Thus the resource server OAuth infrastructure i= s free to decide=0A> what are and are not acceptable values including missi= ng or null values for=0A> scope.=0A> =0A> I think the specification is acce= ptable as it is.=0A> =0A> I note that other specifications that layer on to= p of OAuth2 such as OpenID=0A> Connect may choose to strictly define accept= able values for scope. This type=0A> of layering works well in my opinion.= =0A> =0A> Phil=0A> =0A> @independentid=0A> www.independentid.com=0A> phil.h= unt@oracle.com=0A> =0A> =0A> =0A> =0A> =0A> On 2012-01-10, at 10:56 AM, SM = wrote:=0A> =0A> > At 09:19 10-01-2012, William Mills wrote:=0A> >> That doe= s clear it up!=C2=A0 If the implementation returns a proper error when=0A> = the scope is omitted then it will be in conformance.=C2=A0 Sending an error= result=0A> for the empty scope is valid.=0A> >=0A> > Yes.=0A> >=0A> > It i= s not possible to get a clear view of the specs if the discussion about=0A>= "ambiguity" relies on the meaning of the word "OPTIONAL" only.=C2=A0 If th= ere is a=0A> problem, then clarifying text could be used to fix it instead = of changing the=0A> requirements.=0A> >=0A> > Regards,=0A> > -sm=0A> > ____= ___________________________________________=0A> > OAuth mailing list=0A> > = OAuth@ietf.org=0A> > https://www.ietf.org/mailman/listinfo/oauth=0A> =0A> _= ______________________________________________=0A> OAuth mailing list=0A> O= Auth@ietf.org=0A> https://www.ietf.org/mailman/listinfo/oauth=0A___________= ____________________________________=0AOAuth mailing list=0AOAuth@ietf.org= =0Ahttps://www.ietf.org/mailman/listinfo/oauth ---1395015409-2109497095-1327122176=:2902 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Works for me.

<= b>From: Eran Hammer <eran@h= ueniverse.com>
To: = William Mills <wmills@yahoo-inc.com>; "oauth@ietf.org" <oauth@ietf= .org>
Sent: Friday= , January 20, 2012 12:32 PM
Subje= ct: RE: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in= Specification

=0A
New text added to Access Token S= cope section:
&n= bsp;
     &= nbsp;    If the client omits the scope parameter when reques= ting authorization, the authorization
          server MUST proces= s the request using a pre-defined default value, or fail the request=
    &n= bsp;     indicating an invalid scope. The authorization= server SHOULD document its scope
&n= bsp;         requirements and defau= lt value (if defined).
 
 
EHL
 
From: William Mills [mailto:wmills@yahoo-inc.com]
Sent= : Tuesday, January 10, 2012 11:58 PM
To: Eran Hammer; oauth@i= etf.org
Subject: Re: [OAUTH-WG] Seeking Clarification: Potential = Ambiguity in Specification
 
"Null string", "empty string", or "server = defined default value" all work.  Default scope doesn't do it for me.<= /span>
 
From: Eran Hammer <eran@hueniverse.com>
To: William Mills = <wmills@yahoo-inc.com>; "= oauth@ietf.org" <oauth@ietf.org= >
Sent: Tuesday, January 10, 2012 5:24 PM
Subject:<= /b> RE: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specificat= ion
 
I don=E2=80=99t= like =E2=80=98empty scope=E2=80=99 as it is undefined. I prefer =E2=80=98d= efault scope=E2=80=99.
 
EHL
 
From: William Mills [mailto:wm= ills@yahoo-inc.com]
Sent: Tuesday, January 10, 2012 4:02 PM<= br>To: Eran Hammer; oauth@ietf.orgSubject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity= in Specification
 
On y= our #1, I don't agree that an empty scope is useless.  There are compa= rable implementations that use an empty scope to be a wildcard scope. = I'd say,
 
"The client can MAY = include or omit the scope parameter. If omitted, the server must process th= e request using an empty scope as the default.  The server then proces= ses the request either issuing a grant with it's default scope as defined b= y the server or failing the request indicating an invalid scope requested."=
 <= /span>
That language isn't= quite right, but I think it's clear.
 
From:= Eran Hammer <eran@hueniverse.com= >
To: "oauth@ietf.org" <= ;oauth@ietf.org>
Sent: Tuesda= y, January 10, 2012 1:15 PM
Subject: Re: [OAUTH-WG] Seeking Clari= fication: Potential Ambiguity in Specification

I don't think the issue here is about= the scope value, but who does the OPTIONAL designation applies to. IOW, is= it optional for the server to support/require it, or is it optional for the client to include or omit= it.

The intention was to make it optional for the authorization ser= ver to make all decisions about the parameter, including making it required= . But the text is confusing since the text is aimed directly at the client = when making the request.

We need to clarify this and the options are= :

1. The client can decide if they want to include or omit the scope= parameter. If omitted, the server must process the request using some docu= mented default scope. This default scope can be an empty scope rendering th= e token useless for anything other than verifying user authentication.
<= br>2. The server can declare scope to be a required parameter in which case= the client must include it or the request will fail. In this case, we shou= ld make the text clearer that clients to find out if the particular server = requires it.

#1 is better for interoperability, #2 is more in the spirit of the parameter discussions so far.

EHL

> ---= --Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Phil Hunt
&g= t; Sent: Tuesday, January 10, 2012 11:33 AM
> To: SM
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] = Seeking Clarification: Potential Ambiguity in
> Specification
>=
> The underlying issue is that there was a decision not to in any w= ay
> standardize values for scope.
>
> I agreed this was= reasonable since the underlying resource APIs are likely to
> be ver= y specific requiring some degree of prior knowledge by the client app
> develop= er. Thus the resource server OAuth infrastructure is free to decide
>= what are and are not acceptable values including missing or null values fo= r
> scope.
>
> I think the specification is acceptable a= s it is.
>
> I note that other specifications that layer on to= p of OAuth2 such as OpenID
> Connect may choose to strictly define ac= ceptable values for scope. This type
> of layering works well in my o= pinion.
>
> Phil
>
> @independentid
> www.= independentid.com
> phil.= hunt@oracle.com
>
>
>
>
>
> On= 2012-01-10, at 10:56 AM, SM wrote:
>
> > At 09:19 10-01-20= 12, William Mills wrote:
> >> That does clear it up!  If the = implementation returns a proper error when
> the scope is omitted the= n it will be in conformance.  Sending an error result
> for the = empty scope is valid.
> >
> > Yes.
> >
> &= gt; It is not possible to get a clear view of the specs if the discussion a= bout
> "ambiguity" relies on the meaning of the word "OPTIONAL" only.=   If there is a
> problem, then clarifying text could be used to= fix it instead of changing the
> requirements.
> >
> = > Regards,
> > -sm
> > _______________________________= ________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/= mailman/listinfo/oauth
>
> _______________________________= ________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailm= an/listinfo/oauth
_______________________________________________OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
<= /div>
 


---1395015409-2109497095-1327122176=:2902-- From stephen.farrell@cs.tcd.ie Sat Jan 21 02:21:09 2012 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 E1DC621F85D4 for ; Sat, 21 Jan 2012 02:21:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.203 X-Spam-Level: X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[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 TW4jyE1bEz9g for ; Sat, 21 Jan 2012 02:21:05 -0800 (PST) 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 3C58721F85BD for ; Sat, 21 Jan 2012 02:21:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 760A5171C24; Sat, 21 Jan 2012 10:21:02 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h=date :subject:from:x-mailer:message-id:content-type :content-transfer-encoding:mime-version:in-reply-to:references :received:received:x-virus-scanned; s=cs; t=1327141261; bh=iilvb ekD1LlGKHrDFmK+fhqW/2jWE1PvAm1IFvMNXe8=; b=NgNbb8N6nJd5ezFouQny8 J1/1Wd4ihenbNL66ttrO3u68bfi2n5S6MGpjtLYx5i5IKG68O4qPe+/VfJ1gfAuU yEF5AyPvNlZekplGJSIATfLTRtwL3lOaajIIKG2f21m3c/1PXCo/0UKh/2kYqbG7 B9uj2q5EVMxvyxpdcHuKUBwgcsl2ek+scLfOmU+DFuOYEQ/3fci4ZqBbxvMAjwZS zNG32ZJ1XlpXQ5g7uRjBvFaNsPZX0zm4oOaswBK8d6r5+3rxxAD1fKCvpD7GJOi2 UTMcr/r6/kAQ9ToUfgW6xBpWJbpanpLmdtBc9jMbKqrLQORDMdip4dECCZ/5fTr+ Q== 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 beslv9EXGgaD; Sat, 21 Jan 2012 10:21:01 +0000 (GMT) Received: from [10.87.48.5] (unknown [86.46.23.151]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 65618171C23; Sat, 21 Jan 2012 10:21:00 +0000 (GMT) References: <90C41DD21FB7C64BB94121FBBC2E723453AAB96548@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453AAB96548@P3PW5EX1MB01.EX1.SECURESERVER.NET> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (9A405) From: Stephen Farrell Date: Sat, 21 Jan 2012 10:20:58 +0000 To: Eran Hammer Cc: OAuth WG Subject: Re: [OAUTH-WG] AD Review of -22 (part III) 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, 21 Jan 2012 10:21:10 -0000 As before, Thanks S On 21 Jan 2012, at 02:53, Eran Hammer wrote: >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Stephen Farrell >> Sent: Thursday, October 13, 2011 10:13 AM >=20 >> Original list of nits: >> ---------------------- >>=20 >> - 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 norm= ally >> (running on) a web server. >=20 > Happy to take suggestions, but can't come up with a useful diagram myself.= >=20 > Added to the client definition: >=20 > The term client does not imply any particular implementation > characteristics (e.g. whether the application executes on a s= erver, a desktop, or > other devices). >=20 >> - p4: Maybe s/a string/an octet string/ in the token descriptions, unless= the >> access token encoding is constrained to what'd be understood as a string.= >=20 > Just a string. >=20 >> - p8: Seems odd to speak of "issuing" an implicit grant - wouldn't that m= ake >> something explicit? Maybe say "With an implicit grant..." >> instead in the 2nd para of 1.3.2? >=20 > Changed to 'When issuing an access token during the implicit grant flow'. >=20 >> - p8: I don't get what "its device operating system" means. Do you mean t= he >> client is an already-trusted part of the resource owner's device OS? >=20 > Changed to 'the client is part of the device operating system'. >=20 >> - p9 - "Issuing a refresh token is optional" - might be better to say tha= t it's the >> authorization server's choice and there's no way for the client to signal= a >> request for one. >=20 > Changed to 'Issuing a refresh token is optional at the discretion of the a= uthorization server.' >=20 >> - 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 pr= otocol >> options and say that the refresh token is optional in (B) as well. >=20 > Because this is the refresh token flow. If it is optional, there is no flo= w... >=20 >> - p12 - the confidential/public terminology isn't great, did the WG consi= der >> "authenticating" vs. "non-authenticating"? Trying again to find better te= rms >> would maybe be worthwhile. >=20 > Didn't try this particular alternative, but it doesn't flow off my tongue.= =20 >=20 >> Also, it may be worth explicitly saying that it >> doesn'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 the= n >> the client is still public. It nearly says that, but not quite and given t= hat 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 m= ore >> here. >=20 > This seems to be cross the line as to what the server defines as confident= ial, but I'm happy to take text proposals. >=20 >> - p12/13 in the application profile descriptions - is "resource owner's d= evice" >> correct? That seems to rule out kiosks, which may be correct, but which i= sn't >> obvious. Maybe you mean "device being used by the resource owner" with >> no implication as to ownership of the device? >=20 > Changed to 'the device used by the resource owner' throughout. >=20 >> - p13 - client application: typos: >>=20 >> s/such access tokens/such as access tokens/ >>=20 >> s/which...interact with/with which the application may interact/ >=20 > Ok. >=20 >> - p13, "establishing trust with the client or its developer" is badly phr= ased, I >> think you mean the AS SHOULD NOT just accept the client type unless it ha= s >> some external reason to do so. Trusting the developer might be one such. >> Being paid is another, and maybe more likely;-) >=20 > Changed to: >=20 > The authorization server SHOULD NOT make assumptions about the cl= ient type, nor accept the > type information provided by the client developer without first e= stablishing trust. >=20 >> - p13, 2.3 has 2119 language both about the things established at registr= ation >> 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. >=20 > Tweaked a bit, but overall it reads fine to me. >=20 >> - 3.1.2.1 has a SHOULD for TLS which I think generated a lot of mail on t= he list. >> I think saying why this is not a MUST would be useful, since it's the kin= d of >> thing that might get revised later on if the situation changes. >=20 > This specification does not mandate the use of TLS because at= the > time of this writing, requiring clients to deploy TLS is a si= gnificant hurdle for most > client developers. >=20 >> - Figure 3, (p21) has multiple lines labeled A,B & C - saying why might r= educe >> some confusion. Or maybe, say that the labels reflect rough event timing o= r >> something. It'd also be good if subsequent sections said which parts of f= igure >> 3 they're addressing, e.g. >> 4.1.1 maps to (A), right? It's hard to tell. >=20 > Added clarification about the broken lines. >=20 >> -p25, 4.1.3, what does "assigned" "authentication requirements" >> mean? Suggest deleting the parenthetical clause since "confidential clien= t" >> should be sufficiently well-defined to cover that. >=20 > Ok. >=20 >> -p28, the description of step (D) isn't clear to me - who does what with t= he >> URI fragment? >=20 > Seems pretty clear to me. >=20 >> -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 abo= ut >> that. Same para: s/such client/such clients/ >=20 > Changed to UA. >=20 >> -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 m= ight >> do? >=20 > Nope. >=20 >> -p38, is "token_type":"example" a valid value? If not, better to use one t= hat >> is. >=20 > I refuse to use Bearer as an example and I expect others to take issue wit= h using MAC :-) >=20 >> -p40, s/client it was issued/client to which it was issued/?' >=20 > Ok. >=20 >> -p40, s/require/REQUIRE/ in the 2nd last bullet on the page >=20 > Require isn't an uppercase word (REQUIRED is). >=20 >> -p43, s/native clients may require/native clients require/ I'd say the "m= ay" is >> worth deleting both to avoid 2119 language and because we do know that >> these require special consideration. >=20 > Ok. >=20 >> -p46, s/such malicious clients/such potentially malicious clients/? >> Not all unauthenticated clients are bad, though all of them could be bad.= >=20 > Ok. >=20 >> -p47, s/Access token (as well as.../Access tokens (as well as.../ >=20 > Ok. >=20 >> -p50, 10.8 seems to just repeat stuff from earlier in 10.3 & 10.4, is tha= t >> deliberate? >=20 > The requirements are but the context is different. >=20 > This concludes this review and all other -22 feedback. >=20 > EHL > From andreas.solberg@uninett.no Mon Jan 23 01:23:27 2012 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 907D621F85C2 for ; Mon, 23 Jan 2012 01:23:27 -0800 (PST) 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.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 yMU+8ZjmMozB for ; Mon, 23 Jan 2012 01:23:27 -0800 (PST) Received: from epost.uninett.no (epost.uninett.no [IPv6:2001:700:0:526:158:38:180:100]) by ietfa.amsl.com (Postfix) with ESMTP id CCEC521F84CF for ; Mon, 23 Jan 2012 01:23:26 -0800 (PST) Received: from dmanso-11.uninett.no (dmanso-11.uninett.no [158.38.62.67]) by epost.uninett.no (Postfix) with ESMTPS id C76E5336378; Mon, 23 Jan 2012 10:23:24 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/signed; boundary="Apple-Mail=_E8722BD9-2C3A-449A-B69A-86CEFEBD07C7"; protocol="application/pkcs7-signature"; micalg=sha1 From: =?iso-8859-1?Q?Andreas_=C5kre_Solberg?= In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453AAB964E7@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 23 Jan 2012 10:23:24 +0100 Message-Id: <73AB1858-7975-430F-9B70-269310D88302@uninett.no> References: <6.2.5.6.2.20120109070921.0aec8d00@resistor.net> <6.2.5.6.2.20120109153323.0ab3bf80@resistor.net> <1326156786.88572.YahooMailNeo@web31812.mail.mud.yahoo.com> <1326160314.71861.YahooMailNeo@web31806.mail.mud.yahoo.com> <1326162276.40306.YahooMailNeo@web31811.mail.mud.yahoo.com> <1326215997.44445.YahooMailNeo@web31816.mail.mud.yahoo.com> <6.2.5.6.2.20120110104038.099f1ba8@resistor.net> <90C41DD21FB7C64BB94121FBBC2E723453A72D0F24@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1326240141.98332.YahooMailNeo@web31808.mail.mud .yahoo.com> <90C41DD21FB7C64BB94121FBBC2E723453A72D0F60@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1326268674.20557.YahooMailNeo@web31807.mail.mud.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E723453AAB964E7@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer X-Mailer: Apple Mail (2.1251.1) Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification 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, 23 Jan 2012 09:23:27 -0000 --Apple-Mail=_E8722BD9-2C3A-449A-B69A-86CEFEBD07C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Den 20. jan. 2012 kl. 21:32 skrev Eran Hammer: > New text added to Access Token Scope section: > =20 > If the client omits the scope parameter when requesting = authorization, the authorization > server MUST process the request using a pre-defined default = value, or fail the request > indicating an invalid scope. Will this change imply that implementing a more dynamic approach to = issuing scopes, such as in example asking the user which scope should be = issued to the consumer, will be explicitly disallowed, while it was = accepted before this text was added? I think this section of the text does not solve the initial problem that = started this thread, and I think it adds unneccessary restrictions. > The authorization server SHOULD document its scope > requirements and default value (if defined). This makes more sense to me. Andreas= --Apple-Mail=_E8722BD9-2C3A-449A-B69A-86CEFEBD07C7 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOazCCBIow ggNyoAMCAQICECf06hH0eobEbp27bqkXBwcwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0Ux FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0 d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wNTA2MDcwODA5MTBa Fw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNh bHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0 dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0 aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmF pPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJk xIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2q L+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAs vIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMe oYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4HhMIHeMB8GA1UdIwQYMBaAFK29mHo0tCb3 +sQmVO8DveAky1QaMB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMC AQYwDwYDVR0TAQH/BAUwAwEB/zB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kb2Nh LmNvbS9BZGRUcnVzdEV4dGVybmFsQ0FSb290LmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21vZG8u bmV0L0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAZ2IkRbyis pgCi54fBm5AD236hEv0e8+LwAamUVEJrmgnEoG3XkJIEA2Z5Q3H8+G+v23ZF4jcaPd3kWQR4rBz0 g0bzes9bhHIt5UbBuhgRKfPLSXmHPLptBZ2kbWhPrXIUNqi5sf2/z3/wpGqUNVCPz4FtVbHdWTBK 322gnGQfSXzvNrv042n0+DmPWq1LhTq3Du3Tzw1EovsEv+QvcI4l+1pUBrPQxLxtjftzMizpm4Qk LdZ/kXpoAlAfDj9N6cz1u2fo3BwuO/xOzf4CjuOoEwqlJkRl6RDyTVKnrtw+ymsyXEFs/vVdoOr/ 0fqbhlhtPZZH5f4ulQTCAMyOofK7MIIE2jCCA8KgAwIBAgIQXf9Q6v4PU0aIn4BBj+dCyDANBgkq hkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExh a2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8v d3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBFbWFpbDAeFw0wOTA1MTgwMDAwMDBaFw0yODEyMzEyMzU5NTlaMEQxCzAJBgNV BAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExJDAiBgNVBAMTG1RFUkVOQSBlU2NpZW5jZSBQZXJzb25h bCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMS8JX3N71kEq3QnKbZjiu/ENXCh RgivblCbG3F4lwKFwDX/kBgRZvozORSepBL3Pe4FLIHn9y0uNnhDDjm2f3p0w8tVPy+zy8M3auGV AyMbsyKYE4NYMF+sPJFF020LLsvRkWGyynH6wokMewnWkr+jgRcRVSDfN4GfHiYJHdIXGUPLi5kl dEFb5jIq0KdT3NIhjc2Rz3ts9Mn+0OXSBmsaYUIbgJEH3BRJJzsKirLiO2kIhMuBmde6FB/YfpJj vfYtMfqVTs02DZnvEbqtSvuoxHi5fFo+yPUIMsCpBceMGiiPMLoXo/G54genuPtVv59iWtUUDwi0 E5nSEnla8P0CAwEAAaOCAVswggFXMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0G A1UdDgQWBBTIiXOZp11RFlNFVHyjwjl8y9eqgTAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgw BgEB/wIBADAmBgNVHSAEHzAdMA0GCysGAQQBsjEBAgIdMAwGCiqGSIb3TAUCAgUwWAYDVR0fBFEw TzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3QuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0 aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbwYIKwYBBQUHAQEEYzBhMDgGCCsGAQUFBzAChixodHRw Oi8vY3J0LnVzZXJ0cnVzdC5jb20vVVROQUFBQ2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0 cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG9w0BAQUFAAOCAQEACBekHPkVa7AZYW+gSON6 JO9BVZqgUHDYI9VThkpnjujaVhYYLBsYIYm6mCTuVjTjF4YmvSFa1BmTSuphdE22xISNR+7KLmVt NpOYseKSZojiTnt1x15EaSHcEmow/GGA/g/wndLcfq7lwlNNC3CDYVZF+z3fcvYCQnXriIqYV2D1 n6JySbF6PkFnNcNVKw0HNejGK9W6h3mAdOeSNr1GgXouKeJqvuEXEzV8FqQlMy9h7s7JUuBA29O+ OVrPz0wU5X/FQ1eLTblajsIPBk3eyEmdgXO65D+YpZM8WU7bmzXf/k2/VaHpZMNFfKyPfEfROvFO ddmQZ0DosS+eFy9cNTCCBPswggPjoAMCAQICEQCbXV9Tn+I7grzQTh0VEN6kMA0GCSqGSIb3DQEB BQUAMEQxCzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExJDAiBgNVBAMTG1RFUkVOQSBlU2Np ZW5jZSBQZXJzb25hbCBDQTAeFw0xMTA3MDUwMDAwMDBaFw0xMjA4MDMyMzU5NTlaMIGUMRMwEQYK CZImiZPyLGQBGRYDb3JnMRYwFAYKCZImiZPyLGQBGRYGdGVyZW5hMRMwEQYKCZImiZPyLGQBGRYD dGNzMQswCQYDVQQGEwJOTzEQMA4GA1UEChMHVU5JTkVUVDExMC8GA1UEAxQoQW5kcmVhcyBhYWty ZSBTb2xiZXJnIGFuZHJlYXNAdW5pbmV0dC5ubzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAL8ukoshERFAc4JLOA7WhazD4rpQPdboyAtCuynZUBW2s6NYPH6IuU25CcRldKJIzkBa9/A5 +rmD5r2Evsbdnt91VSU8FR9J73BMHPT7HywD4Y3Rv/h/kb6xkLCgoRAoCPlZDepR6TvUWH1PulII IlbtBMarsrfEUFGuntLIJQA5yH7WysiV0wHGygb+P1KiSDJd4/v3OBilAAg7zwRNJJ5ihmcW24Jx ZX3hQU9KV5ZXb2IxohUwTscYEGBPMoOPe62uQlj2MNiTYaXHX3QH4QZzD4v6MU5qxMSFXxdOfb09 lft3GF+c3PpybQ1T3GpKsSbEcA5FVSMb7HnC67V+5p8CAwEAAaOCAZUwggGRMB8GA1UdIwQYMBaA FMiJc5mnXVEWU0VUfKPCOXzL16qBMB0GA1UdDgQWBBQkb3UBIHXOvsZSkUyjDMTSzXPavDAOBgNV HQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIw JgYDVR0gBB8wHTANBgsrBgEEAbIxAQICHTAMBgoqhkiG90wFAgIFMEcGA1UdHwRAMD4wPKA6oDiG Nmh0dHA6Ly9jcmwudGNzLnRlcmVuYS5vcmcvVEVSRU5BZVNjaWVuY2VQZXJzb25hbENBLmNybDB6 BggrBgEFBQcBAQRuMGwwQgYIKwYBBQUHMAKGNmh0dHA6Ly9jcnQudGNzLnRlcmVuYS5vcmcvVEVS RU5BZVNjaWVuY2VQZXJzb25hbENBLmNydDAmBggrBgEFBQcwAYYaaHR0cDovL29jc3AudGNzLnRl cmVuYS5vcmcwJQYDVR0RBB4wHIEaYW5kcmVhcy5zb2xiZXJnQHVuaW5ldHQubm8wDQYJKoZIhvcN AQEFBQADggEBAKLxPqSWPfTshbrMWi2qGgUW9eXsVU5Lq31WSJfqN79TVyi4ipHSPE4uKFZOe7ZK AehMM+XNgk59nxpkcPmvksNsY98dk78NyH4dgybY5NLurWptkFbP9npcvBeneb3MEQXDLXfc0MuX daES6X3bxwhqe1nXKsyTFtIe8FBETf6Y+DSfaYY69rL0Vl6yJiDnz5ZYLoXOAr5xZtTbqx/yP9nC yXc5kSR7R2RJIzQ427/sXX4+BK6/rafXaFpMiPjBdOeHMAnT4HBdCtaEk1gjlsxrf5boVlq3MSww DaDMGyCZhhKUmMJ6Uvh/jUeHkxGiw6KxSmRemNSi5FEKBIJ+cQsxggK3MIICswIBATBZMEQxCzAJ BgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExJDAiBgNVBAMTG1RFUkVOQSBlU2NpZW5jZSBQZXJz b25hbCBDQQIRAJtdX1Of4juCvNBOHRUQ3qQwCQYFKw4DAhoFAKCCATMwGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIwMTIzMDkyMzI1WjAjBgkqhkiG9w0BCQQxFgQU 2k5/Iurw4uTjg+tdjLG/XJvEPeowaAYJKwYBBAGCNxAEMVswWTBEMQswCQYDVQQGEwJOTDEPMA0G A1UEChMGVEVSRU5BMSQwIgYDVQQDExtURVJFTkEgZVNjaWVuY2UgUGVyc29uYWwgQ0ECEQCbXV9T n+I7grzQTh0VEN6kMGoGCyqGSIb3DQEJEAILMVugWTBEMQswCQYDVQQGEwJOTDEPMA0GA1UEChMG VEVSRU5BMSQwIgYDVQQDExtURVJFTkEgZVNjaWVuY2UgUGVyc29uYWwgQ0ECEQCbXV9Tn+I7grzQ Th0VEN6kMA0GCSqGSIb3DQEBAQUABIIBAKN6MZAPJCX9tG9kmyUJ+AtENt6SmwUi6IzJJREgWnhC woGhIw/0LslJj2IlweOsdzS5ThSyl2tswx88Zeuux9m9MzPxFC+pXB6v9AW6z7WcUoDoqTDJEC+B RYgI35jXKfPGbAC0uk1PfoZ7YrMrbGfzpCwLs39FIU5klRS0iyOwTatD4NBWazdJOOQmDvNU0Xls LH6ShMMZLse1o3OVv93FJgxv75N8AJtXfhu1UVEP+GTOgasvfR3g1873m2EmSYspAEwNMnPcqgAC Gl8vgh1pxKeEWlFDBlSiRGkTb4/0i6W9IqV0C1D8CobWZEDahuMt+/gRKUyVA4SdQ4paN3YAAAAA AAA= --Apple-Mail=_E8722BD9-2C3A-449A-B69A-86CEFEBD07C7-- From eran@hueniverse.com Mon Jan 23 07:33:34 2012 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 9E33B21F8687 for ; Mon, 23 Jan 2012 07:33:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.314 X-Spam-Level: X-Spam-Status: No, score=-2.314 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 jDSd7WyvKMrd for ; Mon, 23 Jan 2012 07:33:34 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 35D0B21F8683 for ; Mon, 23 Jan 2012 07:33:34 -0800 (PST) Received: (qmail 32695 invoked from network); 23 Jan 2012 15:33:32 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 23 Jan 2012 15:33:32 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 23 Jan 2012 08:33:26 -0700 From: Eran Hammer To: =?iso-8859-1?Q?Andreas_=C5kre_Solberg?= Date: Mon, 23 Jan 2012 08:33:21 -0700 Thread-Topic: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification Thread-Index: AczZsKooptLIMsS8SH2BhOn7UoD/fAAM4ddg Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453AAB965D2@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <6.2.5.6.2.20120109070921.0aec8d00@resistor.net> <6.2.5.6.2.20120109153323.0ab3bf80@resistor.net> <1326156786.88572.YahooMailNeo@web31812.mail.mud.yahoo.com> <1326160314.71861.YahooMailNeo@web31806.mail.mud.yahoo.com> <1326162276.40306.YahooMailNeo@web31811.mail.mud.yahoo.com> <1326215997.44445.YahooMailNeo@web31816.mail.mud.yahoo.com> <6.2.5.6.2.20120110104038.099f1ba8@resistor.net> <90C41DD21FB7C64BB94121FBBC2E723453A72D0F24@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1326240141.98332.YahooMailNeo@web31808.mail.mud .yahoo.com> <90C41DD21FB7C64BB94121FBBC2E723453A72D0F60@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1326268674.20557.YahooMailNeo@web31807.mail.mud.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E723453AAB964E7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <73AB1858-7975-430F-9B70-269310D88302@uninett.no> In-Reply-To: <73AB1858-7975-430F-9B70-269310D88302@uninett.no> 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@ietf.org" Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification 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, 23 Jan 2012 15:33:34 -0000 It doesn't disallow asking the user. The server is allowed to ignore the sc= ope requested by the client. It can also define 'default scope' to mean 'pr= ompt user' and document that. EHL > -----Original Message----- > From: Andreas =C5kre Solberg [mailto:andreas.solberg@uninett.no] > Sent: Monday, January 23, 2012 1:23 AM > To: Eran Hammer > Cc: William Mills; oauth@ietf.org > Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in > Specification >=20 > Den 20. jan. 2012 kl. 21:32 skrev Eran Hammer: >=20 > > New text added to Access Token Scope section: > > > > If the client omits the scope parameter when requesting > authorization, the authorization > > server MUST process the request using a pre-defined default v= alue, or > fail the request > > indicating an invalid scope. >=20 > Will this change imply that implementing a more dynamic approach to issui= ng > scopes, such as in example asking the user which scope should be issued t= o > the consumer, will be explicitly disallowed, while it was accepted before= this > text was added? >=20 > I think this section of the text does not solve the initial problem that = started > this thread, and I think it adds unneccessary restrictions. >=20 > > The authorization server SHOULD document its scope > > requirements and default value (if defined). >=20 > This makes more sense to me. >=20 > Andreas From iesg-secretary@ietf.org Mon Jan 23 07:44:10 2012 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 32A7421F86BE; Mon, 23 Jan 2012 07:44:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.414 X-Spam-Level: X-Spam-Status: No, score=-102.414 tagged_above=-999 required=5 tests=[AWL=0.185, 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 ggq9nhuc1pxB; Mon, 23 Jan 2012 07:44:09 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7D3721F86B0; Mon, 23 Jan 2012 07:44:09 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120123154409.15089.51253.idtracker@ietfa.amsl.com> Date: Mon, 23 Jan 2012 07:44:09 -0800 Cc: oauth@ietf.org Subject: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol) to Proposed Standard X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 15:44:10 -0000 The IESG has received a request from the Web Authorization Protocol WG (oauth) to consider the following document: - 'The OAuth 2.0 Authorization Protocol' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-02-06. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The OAuth 2.0 authorization protocol enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-oauth-v2/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-oauth-v2/ No IPR declarations have been submitted directly on this I-D. From iesg-secretary@ietf.org Mon Jan 23 07:46:44 2012 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 2E21521F871C; Mon, 23 Jan 2012 07:46:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.476 X-Spam-Level: X-Spam-Status: No, score=-102.476 tagged_above=-999 required=5 tests=[AWL=0.123, 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 2nTRpHF88gEF; Mon, 23 Jan 2012 07:46:43 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD29F21F86B6; Mon, 23 Jan 2012 07:46:43 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120123154643.16223.44509.idtracker@ietfa.amsl.com> Date: Mon, 23 Jan 2012 07:46:43 -0800 Cc: oauth@ietf.org Subject: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 15:46:44 -0000 The IESG has received a request from the Web Authorization Protocol WG (oauth) to consider the following document: - 'The OAuth 2.0 Authorization Protocol: Bearer Tokens' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-02-06. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract 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 the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-oauth-v2-bearer/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-oauth-v2-bearer/ No IPR declarations have been submitted directly on this I-D. From julian.reschke@gmx.de Mon Jan 23 08:04:59 2012 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 A42F521F8734 for ; Mon, 23 Jan 2012 08:04:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.544 X-Spam-Level: X-Spam-Status: No, score=-103.544 tagged_above=-999 required=5 tests=[AWL=-0.945, 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 EtUWb0q8oYXx for ; Mon, 23 Jan 2012 08:04:59 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id E414021F86F8 for ; Mon, 23 Jan 2012 08:04:58 -0800 (PST) Received: (qmail invoked by alias); 23 Jan 2012 15:58:18 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp069) with SMTP; 23 Jan 2012 16:58:18 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+5VW4MwUu5haBx+PEK/sVEJ7CkiOmQQyCqbjcBUC ET4NQJ00tthf0g Message-ID: <4F1D8391.3080009@gmx.de> Date: Mon, 23 Jan 2012 16:58:09 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: ietf@ietf.org References: <20120123154643.16223.44509.idtracker@ietfa.amsl.com> In-Reply-To: <20120123154643.16223.44509.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: The IESG , oauth@ietf.org, IETF-Announce Subject: Re: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard 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, 23 Jan 2012 16:05:00 -0000 On 2012-01-23 16:46, The IESG wrote: > > The IESG has received a request from the Web Authorization Protocol WG > (oauth) to consider the following document: > - 'The OAuth 2.0 Authorization Protocol: Bearer Tokens' > as a Proposed Standard > ... Please see my comments in which I think have not been addressed. Best regards, Julian From jricher@mitre.org Mon Jan 23 08:28:37 2012 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 F17EB21F86EB for ; Mon, 23 Jan 2012 08:28:37 -0800 (PST) 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 H3YO8yKt83j7 for ; Mon, 23 Jan 2012 08:28:37 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id EA3E421F86E8 for ; Mon, 23 Jan 2012 08:28:36 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id BE8CE21B13D8; Mon, 23 Jan 2012 11:28:33 -0500 (EST) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id B00F421B13D2; Mon, 23 Jan 2012 11:28:33 -0500 (EST) Received: from [129.83.50.12] (129.83.31.51) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.1.339.1; Mon, 23 Jan 2012 11:28:33 -0500 Message-ID: <4F1D8A73.2050305@mitre.org> Date: Mon, 23 Jan 2012 11:27:31 -0500 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: Eran Hammer References: <90C41DD21FB7C64BB94121FBBC2E723453AAB96537@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453AAB96537@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: multipart/alternative; boundary="------------000300040602090505010506" X-Originating-IP: [129.83.31.51] Cc: OAuth WG Subject: Re: [OAUTH-WG] SHOULD vs MUST for indicating scope on response when different from client 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: Mon, 23 Jan 2012 16:28:38 -0000 --------------000300040602090505010506 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit +1, sounds reasonable to me and I don't see why not. Also, it fits with current implementations that I'm familiar with. -- Justin On 01/20/2012 06:19 PM, Eran Hammer wrote: > > The current text: > > If the issued access token scope > > is different from the one requested by the client, the authorization > > server SHOULD include the "scope" response parameter to inform the > > client of the actual scope granted. > > Stephen asked why not a MUST. I think it should be MUST. Any disagreement? > > EHL > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------000300040602090505010506 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit +1, sounds reasonable to me and I don't see why not. Also, it fits with current implementations that I'm familiar with.

 -- Justin

On 01/20/2012 06:19 PM, Eran Hammer wrote:

The current text:

 

   If the issued access token scope

   is different from the one requested by the client, the authorization

   server SHOULD include the "scope" response parameter to inform the

   client of the actual scope granted.

 

Stephen asked why not a MUST. I think it should be MUST. Any disagreement?

 

EHL

 



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

--------------000300040602090505010506-- From Michael.Jones@microsoft.com Mon Jan 23 09:12:18 2012 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 935E921F846C for ; Mon, 23 Jan 2012 09:12:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.704 X-Spam-Level: X-Spam-Status: No, score=-3.704 tagged_above=-999 required=5 tests=[AWL=-0.105, 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 hoAKaBR5k1uk for ; Mon, 23 Jan 2012 09:12:12 -0800 (PST) Received: from AM1EHSOBE004.bigfish.com (am1ehsobe004.messaging.microsoft.com [213.199.154.207]) by ietfa.amsl.com (Postfix) with ESMTP id 4101721F843C for ; Mon, 23 Jan 2012 09:12:12 -0800 (PST) Received: from mail101-am1-R.bigfish.com (10.3.201.253) by AM1EHSOBE004.bigfish.com (10.3.204.24) with Microsoft SMTP Server id 14.1.225.23; Mon, 23 Jan 2012 17:12:03 +0000 Received: from mail101-am1 (localhost [127.0.0.1]) by mail101-am1-R.bigfish.com (Postfix) with ESMTP id A898B1C01A7 for ; Mon, 23 Jan 2012 17:12:02 +0000 (UTC) X-SpamScore: -31 X-BigFish: VS-31(zz9371I1b0bM542Mzz1202hzz1033IL8275dhz2fhc1bhc31hc1ah2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail101-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail101-am1 (localhost.localdomain [127.0.0.1]) by mail101-am1 (MessageSwitch) id 1327338720749871_31385; Mon, 23 Jan 2012 17:12:00 +0000 (UTC) Received: from AM1EHSMHS001.bigfish.com (unknown [10.3.201.242]) by mail101-am1.bigfish.com (Postfix) with ESMTP id A7CA4300094 for ; Mon, 23 Jan 2012 17:12:00 +0000 (UTC) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS001.bigfish.com (10.3.207.101) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 23 Jan 2012 17:12:00 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.12]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.02.0247.005; Mon, 23 Jan 2012 09:11:39 -0800 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: OAuth specs in IETF last call Thread-Index: AczZ8guNMkMTRg6xR9CyRRrSj7ESSg== Date: Mon, 23 Jan 2012 17:11:38 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366375EB9@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.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: [OAUTH-WG] OAuth specs in IETF last call 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, 23 Jan 2012 17:12:18 -0000 FYI, the OAuth Core and Bearer specifications have reached IETF last call s= tatus - the last step before becoming RFCs. See the following notes from t= he Internet Engineering Steering Group (IESG). -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of T= he IESG Sent: Monday, January 23, 2012 7:44 AM To: IETF-Announce Cc: oauth@ietf.org Subject: [OAUTH-WG] Last Call: (The OAuth 2.0 = Authorization Protocol) to Proposed Standard The IESG has received a request from the Web Authorization Protocol WG (oauth) to consider the following document: - 'The OAuth 2.0 Authorization Protocol' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final= comments on this action. Please send substantive comments to the ietf@ietf= .org mailing lists by 2012-02-06. Exceptionally, comments may be sent to ie= sg@ietf.org instead. In either case, please retain the beginning of the Sub= ject line to allow automated sorting. Abstract The OAuth 2.0 authorization protocol enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-oauth-v2/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-oauth-v2/ No IPR declarations have been submitted directly on this I-D. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of T= he IESG Sent: Monday, January 23, 2012 7:47 AM To: IETF-Announce Cc: oauth@ietf.org Subject: [OAUTH-WG] Last Call: (The OAu= th 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard The IESG has received a request from the Web Authorization Protocol WG (oauth) to consider the following document: - 'The OAuth 2.0 Authorization Protocol: Bearer Tokens' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final= comments on this action. Please send substantive comments to the ietf@ietf= .org mailing lists by 2012-02-06. Exceptionally, comments may be sent to ie= sg@ietf.org instead. In either case, please retain the beginning of the Sub= ject line to allow automated sorting. Abstract 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 the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-oauth-v2-bearer/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-oauth-v2-bearer/ No IPR declarations have been submitted directly on this I-D. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From Michael.Jones@microsoft.com Mon Jan 23 09:24:39 2012 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 E195621F8661; Mon, 23 Jan 2012 09:24:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.699 X-Spam-Level: X-Spam-Status: No, score=-3.699 tagged_above=-999 required=5 tests=[AWL=-0.100, 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 upHBp3N502iT; Mon, 23 Jan 2012 09:24:39 -0800 (PST) Received: from VA3EHSOBE010.bigfish.com (va3ehsobe010.messaging.microsoft.com [216.32.180.30]) by ietfa.amsl.com (Postfix) with ESMTP id 41B1721F865F; Mon, 23 Jan 2012 09:24:39 -0800 (PST) Received: from mail144-va3-R.bigfish.com (10.7.14.238) by VA3EHSOBE010.bigfish.com (10.7.40.12) with Microsoft SMTP Server id 14.1.225.22; Mon, 23 Jan 2012 17:24:30 +0000 Received: from mail144-va3 (localhost [127.0.0.1]) by mail144-va3-R.bigfish.com (Postfix) with ESMTP id AE9F1120357; Mon, 23 Jan 2012 17:24:32 +0000 (UTC) X-SpamScore: -38 X-BigFish: VS-38(zz9371I936eK542M1432N98dKzz1202hzz1033IL8275dhz2fhc1bhc31hc1ah2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail144-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail144-va3 (localhost.localdomain [127.0.0.1]) by mail144-va3 (MessageSwitch) id 1327339470375874_15246; Mon, 23 Jan 2012 17:24:30 +0000 (UTC) Received: from VA3EHSMHS027.bigfish.com (unknown [10.7.14.243]) by mail144-va3.bigfish.com (Postfix) with ESMTP id 5561520046; Mon, 23 Jan 2012 17:24:30 +0000 (UTC) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS027.bigfish.com (10.7.99.37) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 23 Jan 2012 17:24:27 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.12]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0247.005; Mon, 23 Jan 2012 09:24:25 -0800 From: Mike Jones To: "ietf@ietf.org" Thread-Topic: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard Thread-Index: AQHM2ejbNGzL+7cc6EiU4F3vKE4/fpYaMdvw Date: Mon, 23 Jan 2012 17:24:24 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366375F80@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <20120123154643.16223.44509.idtracker@ietfa.amsl.com> <4F1D8391.3080009@gmx.de> In-Reply-To: <4F1D8391.3080009@gmx.de> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: Julian Reschke , The IESG , "oauth@ietf.org" , IETF-Announce Subject: Re: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard 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, 23 Jan 2012 17:24:40 -0000 As editor of the Oauth Bearer spec, I believe that these comments have been= well understood and considered by the working group. I do understand that= the working group's consensus position is different than Julian's. See th= ese notes documenting that this is the case: https://www.ietf.org/mail-archive/web/oauth/current/msg08113.html https://www.ietf.org/mail-archive/web/oauth/current/msg08116.html https://www.ietf.org/mail-archive/web/oauth/current/msg08121.html Best wishes, -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of J= ulian Reschke Sent: Monday, January 23, 2012 7:58 AM To: ietf@ietf.org Cc: The IESG; oauth@ietf.org; IETF-Announce Subject: Re: [OAUTH-WG] Last Call: (The= OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard On 2012-01-23 16:46, The IESG wrote: > > The IESG has received a request from the Web Authorization Protocol WG > (oauth) to consider the following document: > - 'The OAuth 2.0 Authorization Protocol: Bearer Tokens' > as a Proposed Standard ... Please see my comments in which I think have not been addressed. Best regards, Julian _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From stephen.farrell@cs.tcd.ie Mon Jan 23 09:32:59 2012 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 5B76721F86CF for ; Mon, 23 Jan 2012 09:32:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 sDeSVWPecMdA for ; Mon, 23 Jan 2012 09:32:58 -0800 (PST) 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 5839221F84A2 for ; Mon, 23 Jan 2012 09:32:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 76C71171C08 for ; Mon, 23 Jan 2012 17:32: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=1327339976; bh=BHX2MChT1bUlX7 L/tdPEG3yIJiL6K5Cmf39XFjCZdoU=; b=cHm/+M4Zumw3huTC+olkp9ahFieDgy vqOZEJiWOTjHUceVjao93JzztmIy1rOnNOk9b8bEYzoks9qNcOm2zWiq3FRyf3m8 6hBI5XttABlZviU6BZlPPzk6w6Ql1tmIWLcjjJxiM6O2fkz7IC7cKDReAumtUOvi RYZM9CTTSm1Zi9q0Q1Xps/jHQnwTmW5TJDaj1Mfi6lv0XewctF9v4he0We4BhGp7 srXsbeLtq7pElzBMpdFlpNhApsihRos5vyo2XNnWSRp0Ful6FOb13LCzEQ7ED6pc QmyO1VvR3qsSR8v/U4Yc0hh8LEcgqL3v1PTmKL2OHJ98PtUcMJROhvMw== 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 FvTgWZzZBfCZ for ; Mon, 23 Jan 2012 17:32:56 +0000 (GMT) Received: from [10.1.1.138] (wifi.ist.utl.pt [193.136.128.57]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 14362171C06 for ; Mon, 23 Jan 2012 17:32:56 +0000 (GMT) Message-ID: <4F1D99C7.7050606@cs.tcd.ie> Date: Mon, 23 Jan 2012 17:32:55 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: oauth@ietf.org References: <4E1F6AAD24975D4BA5B168042967394366375EB9@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366375EB9@TK5EX14MBXC284.redmond.corp.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [OAUTH-WG] OAuth specs in IETF last call 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, 23 Jan 2012 17:32:59 -0000 On 01/23/2012 05:11 PM, Mike Jones wrote: > FYI, the OAuth Core and Bearer specifications have reached IETF last call status - the last step before becoming RFCs. See the following notes from the Internet Engineering Steering Group (IESG). Not quite the last step. There may be directorate reviews, then IESG evaluation follows, then the RFC editor queue. But we're getting there:-) S > > -- Mike > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of The IESG > Sent: Monday, January 23, 2012 7:44 AM > To: IETF-Announce > Cc: oauth@ietf.org > Subject: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol) to Proposed Standard > > > The IESG has received a request from the Web Authorization Protocol WG > (oauth) to consider the following document: > - 'The OAuth 2.0 Authorization Protocol' > as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-02-06. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. > > Abstract > > > The OAuth 2.0 authorization protocol enables a third-party > application to obtain limited access to an HTTP service, either on > behalf of a resource owner by orchestrating an approval interaction > between the resource owner and the HTTP service, or by allowing the > third-party application to obtain access on its own behalf. This > specification replaces and obsoletes the OAuth 1.0 protocol described > in RFC 5849. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-oauth-v2/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-oauth-v2/ > > > No IPR declarations have been submitted directly on this I-D. > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of The IESG > Sent: Monday, January 23, 2012 7:47 AM > To: IETF-Announce > Cc: oauth@ietf.org > Subject: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard > > > The IESG has received a request from the Web Authorization Protocol WG > (oauth) to consider the following document: > - 'The OAuth 2.0 Authorization Protocol: Bearer Tokens' > as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-02-06. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. > > Abstract > > > 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 > the associated resources (without demonstrating possession of a > cryptographic key). To prevent misuse, bearer tokens need to be > protected from disclosure in storage and in transport. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-oauth-v2-bearer/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-oauth-v2-bearer/ > > > No IPR declarations have been submitted directly on this I-D. > > > _______________________________________________ > 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 stpeter@stpeter.im Mon Jan 23 09:39:39 2012 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 00FD121F86AB for ; Mon, 23 Jan 2012 09:39:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.655 X-Spam-Level: X-Spam-Status: No, score=-102.655 tagged_above=-999 required=5 tests=[AWL=-0.056, 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 9vIDXKDL4HT3 for ; Mon, 23 Jan 2012 09:39:38 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 2638B21F8664 for ; Mon, 23 Jan 2012 09:39:38 -0800 (PST) Received: from dhcp-64-101-72-243.cisco.com (unknown [64.101.72.243]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 30EAB40058 for ; Mon, 23 Jan 2012 10:49:16 -0700 (MST) Message-ID: <4F1D9B57.1030501@stpeter.im> Date: Mon, 23 Jan 2012 10:39:35 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: oauth@ietf.org References: <4E1F6AAD24975D4BA5B168042967394366375EB9@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366375EB9@TK5EX14MBXC284.redmond.corp.microsoft.com> X-Enigmail-Version: 1.3.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [OAUTH-WG] OAuth specs in IETF last call 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, 23 Jan 2012 17:39:39 -0000 On 1/23/12 10:11 AM, Mike Jones wrote: > FYI, the OAuth Core and Bearer specifications have reached IETF last > call status - the last step before becoming RFCs. See the following > notes from the Internet Engineering Steering Group (IESG). Well, "last step" might be a bit optimistic. :) For those who aren't familiar with the process, the next steps are: 1. IETF Last Call, which lasts two weeks. This is essentially your last opportunity to provide feedback! 2. During IETF Last Call, the documents will be reviewed by several cross-area teams within the IETF, including folks like the "GEN-ART" review team and the AppsDir. We'll expect at least some feedback from those teams. And at this stage anyone in the Internet community can provide feedback, too. 3. After IETF Last Call, this WG's document editors will work to address any feedback we've received. 4. The documents will then be scheduled for disussion during an IESG telechat. Before the telechat, all the members of the Internet Engineering Steering Group will review the specs and also provide feedback. If there are "DISCUSSES" and "COMMENTS" lodged then the document editors will need to address those (often in concert with the WG chairs). If some of those issues are substantive, the editors and chairs might bring those issues back to the WG for more discussion. 5. Assuming the documents are approved by the IESG, they will then be handed off to the RFC Editor team for final copy editing, proofreading, reference checking, etc. As you can see, because there are still many steps left in the process, it might be a few months before these specs are published as RFCs. Just so you know! Peter -- Peter Saint-Andre https://stpeter.im/ From Michael.Jones@microsoft.com Mon Jan 23 09:43:12 2012 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 3C7BC21F8661 for ; Mon, 23 Jan 2012 09:43:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.694 X-Spam-Level: X-Spam-Status: No, score=-3.694 tagged_above=-999 required=5 tests=[AWL=-0.095, 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 MMYwfVrBbQE5 for ; Mon, 23 Jan 2012 09:43:11 -0800 (PST) Received: from AM1EHSOBE005.bigfish.com (am1ehsobe005.messaging.microsoft.com [213.199.154.208]) by ietfa.amsl.com (Postfix) with ESMTP id 1F10F21F862A for ; Mon, 23 Jan 2012 09:43:11 -0800 (PST) Received: from mail117-am1-R.bigfish.com (10.3.201.252) by AM1EHSOBE005.bigfish.com (10.3.204.25) with Microsoft SMTP Server id 14.1.225.23; Mon, 23 Jan 2012 17:43:02 +0000 Received: from mail117-am1 (localhost [127.0.0.1]) by mail117-am1-R.bigfish.com (Postfix) with ESMTP id 783A320017F; Mon, 23 Jan 2012 17:43:02 +0000 (UTC) X-SpamScore: -35 X-BigFish: VS-35(zzbb2dI9371I1b0bM542M98dKzz1202hzz1033IL8275dhz2fhc1bhc31hc1ah2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail117-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC107.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail117-am1 (localhost.localdomain [127.0.0.1]) by mail117-am1 (MessageSwitch) id 1327340580743455_9352; Mon, 23 Jan 2012 17:43:00 +0000 (UTC) Received: from AM1EHSMHS016.bigfish.com (unknown [10.3.201.247]) by mail117-am1.bigfish.com (Postfix) with ESMTP id A7EBB360045; Mon, 23 Jan 2012 17:43:00 +0000 (UTC) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS016.bigfish.com (10.3.207.154) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 23 Jan 2012 17:42:59 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.12]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0247.005; Mon, 23 Jan 2012 09:42:43 -0800 From: Mike Jones To: Peter Saint-Andre , Stephen Farrell , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] OAuth specs in IETF last call Thread-Index: AczZ8guNMkMTRg6xR9CyRRrSj7ESSgARvtOAABC3cjA= Date: Mon, 23 Jan 2012 17:42:42 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366377222@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B168042967394366375EB9@TK5EX14MBXC284.redmond.corp.microsoft.com> <4F1D9B57.1030501@stpeter.im> In-Reply-To: <4F1D9B57.1030501@stpeter.im> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [OAUTH-WG] OAuth specs in IETF last call 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, 23 Jan 2012 17:43:12 -0000 Thanks Stephen and Peter, for the clarifications. For what it's worth, I'd= meant to send my note to a different alias, but now I'm glad to have heard= from both of you on the remaining steps ahead as a result! Best wishes, -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of P= eter Saint-Andre Sent: Monday, January 23, 2012 9:40 AM To: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth specs in IETF last call On 1/23/12 10:11 AM, Mike Jones wrote: > FYI, the OAuth Core and Bearer specifications have reached IETF last=20 > call status - the last step before becoming RFCs. See the following=20 > notes from the Internet Engineering Steering Group (IESG). Well, "last step" might be a bit optimistic. :) For those who aren't familiar with the process, the next steps are: 1. IETF Last Call, which lasts two weeks. This is essentially your last opp= ortunity to provide feedback! 2. During IETF Last Call, the documents will be reviewed by several cross-a= rea teams within the IETF, including folks like the "GEN-ART" review team and the AppsDir. We'll expect at least some feedback from those= teams. And at this stage anyone in the Internet community can provide feed= back, too. 3. After IETF Last Call, this WG's document editors will work to address an= y feedback we've received. 4. The documents will then be scheduled for disussion during an IESG telech= at. Before the telechat, all the members of the Internet Engineering Steeri= ng Group will review the specs and also provide feedback. If there are "DIS= CUSSES" and "COMMENTS" lodged then the document editors will need to addres= s those (often in concert with the WG chairs). If some of those issues are = substantive, the editors and chairs might bring those issues back to the WG= for more discussion. 5. Assuming the documents are approved by the IESG, they will then be hande= d off to the RFC Editor team for final copy editing, proofreading, referenc= e checking, etc. As you can see, because there are still many steps left in the process, it = might be a few months before these specs are published as RFCs. Just so you know! Peter -- Peter Saint-Andre https://stpeter.im/ _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From julian.reschke@gmx.de Mon Jan 23 09:45:56 2012 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 C319321F8664 for ; Mon, 23 Jan 2012 09:45:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.413 X-Spam-Level: X-Spam-Status: No, score=-103.413 tagged_above=-999 required=5 tests=[AWL=-0.814, 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 xnel2uKlzG2e for ; Mon, 23 Jan 2012 09:45:56 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 17E1521F8661 for ; Mon, 23 Jan 2012 09:45:55 -0800 (PST) Received: (qmail invoked by alias); 23 Jan 2012 17:39:15 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp059) with SMTP; 23 Jan 2012 18:39:15 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+vNLNbPiKvpHsb50YBBPBVBDJTqwH2tg4cwQpM4s bFMryQN0c3ZL/7 Message-ID: <4F1D9B40.9070901@gmx.de> Date: Mon, 23 Jan 2012 18:39:12 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Mike Jones References: <20120123154643.16223.44509.idtracker@ietfa.amsl.com> <4F1D8391.3080009@gmx.de> <4E1F6AAD24975D4BA5B168042967394366375F80@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366375F80@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: The IESG , "ietf@ietf.org" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard 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, 23 Jan 2012 17:45:56 -0000 On 2012-01-23 18:24, Mike Jones wrote: > As editor of the Oauth Bearer spec, I believe that these comments have been well understood and considered by the working group. I do understand that the working group's consensus position is different than Julian's. See these notes documenting that this is the case: > > https://www.ietf.org/mail-archive/web/oauth/current/msg08113.html > https://www.ietf.org/mail-archive/web/oauth/current/msg08116.html > https://www.ietf.org/mail-archive/web/oauth/current/msg08121.html > ... We are going in circles; see . I can only recommend that people who want to know what's going on read the complete mail thread. Also I'd like to point out that I *did* recommend to go to IETF LC despite these issues because I believe that more review from outside the WG is needed here. Best regards, Julian From barryleiba.mailing.lists@gmail.com Mon Jan 23 10:31:58 2012 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 2E52321F84C9; Mon, 23 Jan 2012 10:31:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.876 X-Spam-Level: X-Spam-Status: No, score=-102.876 tagged_above=-999 required=5 tests=[AWL=0.101, 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 ROn-nhPcIlJ0; Mon, 23 Jan 2012 10:31:57 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2B36D21F84A1; Mon, 23 Jan 2012 10:31:56 -0800 (PST) Received: by yenm3 with SMTP id m3so1500821yen.31 for ; Mon, 23 Jan 2012 10:31:56 -0800 (PST) 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=rxBfFtbQLKSr67GTCam3tv6BZbEUZOKBn0oEndnGj8w=; b=uA5cPh+FLrbZc8PGMRb81QjP/7oSgw55bBwE66quLaYFdtl91Aaa3A+MkT/o/xpYcn YKeucT3Jks/XDaI0iAQQIARPpnT6B7XFQErrWpvE8b6k0zMYuf1WwgEeY6A7A3cAmehM ZKDMiowPMglkf0KQKoQF2DPEP2G6Nr8jiUO0Y= MIME-Version: 1.0 Received: by 10.236.139.193 with SMTP id c41mr13056450yhj.24.1327343516549; Mon, 23 Jan 2012 10:31:56 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.146.136.20 with HTTP; Mon, 23 Jan 2012 10:31:56 -0800 (PST) In-Reply-To: <20120123154409.15089.51253.idtracker@ietfa.amsl.com> References: <20120123154409.15089.51253.idtracker@ietfa.amsl.com> Date: Mon, 23 Jan 2012 13:31:56 -0500 X-Google-Sender-Auth: 0KHqhPT1FcIgtmj5WU_4h9C_LiM Message-ID: From: Barry Leiba To: ietf@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol) to Proposed Standard 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, 23 Jan 2012 18:31:58 -0000 > The IESG has received a request from the Web Authorization Protocol WG > (oauth) to consider the following document: > - 'The OAuth 2.0 Authorization Protocol' > =A0 as a Proposed Standard There are some downrefs in this document that need to be called out in the Last Call notice, which weren't. * There is a normative reference to RFC 1750, which will be updated to point to RFC 4086 before publication. * There is a normative reference to RFC 2246 (TLS 1.0), which has been obsoleted by RFC 4346 (TLS 1.1). The document uses this reference to note that TLS 1.0 is, at this writing, the most widely deployed version. The working group believes it is necessary to note that, and that the reference be normative. * There is a normative reference to Informational RFC 2818 (HTTP over TLS). * There is a normative reference to Informational RFC 4627 (application/json Media Type). * There is a normative reference to Informational RFC 4949 (Internet Security Glossary). This is an allowed downref. Barry, document shepherd From stpeter@stpeter.im Mon Jan 23 10:35:02 2012 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 214EA21F86DA; Mon, 23 Jan 2012 10:35:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.654 X-Spam-Level: X-Spam-Status: No, score=-102.654 tagged_above=-999 required=5 tests=[AWL=-0.055, 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 fNZv8ZIR5W1g; Mon, 23 Jan 2012 10:35:01 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA8421F8588; Mon, 23 Jan 2012 10:35:01 -0800 (PST) Received: from dhcp-64-101-72-124.cisco.com (unknown [64.101.72.124]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 4629C40058; Mon, 23 Jan 2012 11:44:40 -0700 (MST) Message-ID: <4F1DA853.3020401@stpeter.im> Date: Mon, 23 Jan 2012 11:34:59 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Barry Leiba References: <20120123154409.15089.51253.idtracker@ietfa.amsl.com> In-Reply-To: X-Enigmail-Version: 1.3.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: ietf@ietf.org, oauth@ietf.org Subject: Re: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol) to Proposed Standard 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, 23 Jan 2012 18:35:02 -0000 On 1/23/12 11:31 AM, Barry Leiba wrote: >> The IESG has received a request from the Web Authorization Protocol WG >> (oauth) to consider the following document: >> - 'The OAuth 2.0 Authorization Protocol' >> as a Proposed Standard > > There are some downrefs in this document that need to be called out in > the Last Call notice, which weren't. > > * There is a normative reference to RFC 1750, which will be updated to > point to RFC 4086 before publication. > > * There is a normative reference to RFC 2246 (TLS 1.0), which has been > obsoleted by RFC 4346 (TLS 1.1). The document uses this reference to > note that TLS 1.0 is, at this writing, the most widely deployed > version. The working group believes it is necessary to note that, and > that the reference be normative. > > * There is a normative reference to Informational RFC 2818 (HTTP over TLS). > > * There is a normative reference to Informational RFC 4627 > (application/json Media Type). The last two are already in the downref registry: http://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry Peter -- Peter Saint-Andre https://stpeter.im/ From Michael.Jones@microsoft.com Mon Jan 23 10:45:03 2012 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 4834721F868A; Mon, 23 Jan 2012 10:45:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.19 X-Spam-Level: X-Spam-Status: No, score=-5.19 tagged_above=-999 required=5 tests=[AWL=1.409, 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 sXMskgsKQNjH; Mon, 23 Jan 2012 10:45:02 -0800 (PST) Received: from TX2EHSOBE003.bigfish.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC8821F8681; Mon, 23 Jan 2012 10:45:02 -0800 (PST) Received: from mail80-tx2-R.bigfish.com (10.9.14.240) by TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id 14.1.225.23; Mon, 23 Jan 2012 18:44:53 +0000 Received: from mail80-tx2 (localhost [127.0.0.1]) by mail80-tx2-R.bigfish.com (Postfix) with ESMTP id C9622300288; Mon, 23 Jan 2012 18:44:54 +0000 (UTC) X-SpamScore: -38 X-BigFish: VS-38(zz9371I936eK542M1432N98dKzz1202hzz1033IL8275dhz2fhc1bhc31hc1ah2a8h668h839h944h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail80-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail80-tx2 (localhost.localdomain [127.0.0.1]) by mail80-tx2 (MessageSwitch) id 1327344293172313_27425; Mon, 23 Jan 2012 18:44:53 +0000 (UTC) Received: from TX2EHSMHS034.bigfish.com (unknown [10.9.14.242]) by mail80-tx2.bigfish.com (Postfix) with ESMTP id DD2B9280075; Mon, 23 Jan 2012 18:44:51 +0000 (UTC) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS034.bigfish.com (10.9.99.134) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 23 Jan 2012 18:44:55 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.12]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0247.005; Mon, 23 Jan 2012 10:44:36 -0800 From: Mike Jones To: "ietf@ietf.org" , "iesg@ietf.org" Thread-Topic: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard Thread-Index: AQHM2ejbNGzL+7cc6EiU4F3vKE4/fpYaMdvwgAAYAzA= Date: Mon, 23 Jan 2012 18:44:35 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436637843C@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <20120123154643.16223.44509.idtracker@ietfa.amsl.com> <4F1D8391.3080009@gmx.de> <4E1F6AAD24975D4BA5B168042967394366375F80@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366375F80@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.34] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard 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, 23 Jan 2012 18:45:03 -0000 Resending including iesg@ietf.org, per the advice of Cindy Morgan of the IE= SG Secretariat... -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= ike Jones Sent: Monday, January 23, 2012 9:24 AM To: ietf@ietf.org Cc: Julian Reschke; The IESG; oauth@ietf.org; IETF-Announce Subject: Re: [OAUTH-WG] Last Call: (The= OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard As editor of the Oauth Bearer spec, I believe that these comments have been= well understood and considered by the working group. I do understand that= the working group's consensus position is different than Julian's. See th= ese notes documenting that this is the case: https://www.ietf.org/mail-archive/web/oauth/current/msg08113.html https://www.ietf.org/mail-archive/web/oauth/current/msg08116.html https://www.ietf.org/mail-archive/web/oauth/current/msg08121.html Best wishes, -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of J= ulian Reschke Sent: Monday, January 23, 2012 7:58 AM To: ietf@ietf.org Cc: The IESG; oauth@ietf.org; IETF-Announce Subject: Re: [OAUTH-WG] Last Call: (The= OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard On 2012-01-23 16:46, The IESG wrote: > > The IESG has received a request from the Web Authorization Protocol WG > (oauth) to consider the following document: > - 'The OAuth 2.0 Authorization Protocol: Bearer Tokens' > as a Proposed Standard ... Please see my comments in which I think have not been addressed. 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 bcampbell@pingidentity.com Mon Jan 23 12:23:18 2012 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 7817421F8729 for ; Mon, 23 Jan 2012 12:23:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.143 X-Spam-Level: X-Spam-Status: No, score=-5.143 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 O7mVZcls-b0F for ; Mon, 23 Jan 2012 12:23:17 -0800 (PST) Received: from na3sys009aog111.obsmtp.com (na3sys009aog111.obsmtp.com [74.125.149.205]) by ietfa.amsl.com (Postfix) with ESMTP id EA42421F8721 for ; Mon, 23 Jan 2012 12:23:16 -0800 (PST) Received: from mail-vw0-f45.google.com ([209.85.212.45]) (using TLSv1) by na3sys009aob111.postini.com ([74.125.148.12]) with SMTP ID DSNKTx3BtL9Z0kDJ1+VEGxFshBFCgEqoYs23@postini.com; Mon, 23 Jan 2012 12:23:17 PST Received: by mail-vw0-f45.google.com with SMTP id k17so2454015vbj.32 for ; Mon, 23 Jan 2012 12:23:16 -0800 (PST) Received: by 10.52.174.47 with SMTP id bp15mr1648150vdc.124.1327350195149; Mon, 23 Jan 2012 12:23:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.111.197 with HTTP; Mon, 23 Jan 2012 12:22:44 -0800 (PST) In-Reply-To: References: <918554FB-F7B1-42E7-AA49-E3611F435796@oracle.com> From: Brian Campbell Date: Mon, 23 Jan 2012 13:22:44 -0700 Message-ID: To: Phil Hunt X-Gm-Message-State: ALoCoQnA2aFtUNiOX3R8oheO0df5OqMiJ1EIlxu97mfahdCYumjI2eZ1QHxv2sGYkgP+NZvi3Aqe Content-Type: multipart/alternative; boundary=bcaec51b17bbdfda6d04b737cc3e Cc: "oauth \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] SAML Bearer Spec 09 - Refresh 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: Mon, 23 Jan 2012 20:23:18 -0000 --bcaec51b17bbdfda6d04b737cc3e Content-Type: text/plain; charset=ISO-8859-1 Sorry, I had a section reference and link wrong in the previous message. The question/suggestion about moving some text into the "OAuth 2.0 Assertion Profile" should have referenced section 4.2 and linked to here: http://tools.ietf.org/html/draft-ietf-oauth-assertions-01#section-4.2 That mistake also gives me an excuse to raise this to the WG again. I suggest that whatever text we settle on be moved to general assertion profile. I'm not sure I know what that text should be. On Fri, Dec 16, 2011 at 3:58 PM, Brian Campbell wrote: > Hey Phil, > > Your understanding is pretty much inline with how I understand it. > That text actually originates from earlier versions of the core spec > (I think -09 [1] was the last sighting). And I carried it over when > the grant_type got generalized and the assertion pieces moved into the > SAML/OAuth draft. > > The main idea was that the extension grants (or at least assertions) > relied on some existing trust framework and that issuing a refresh > token would effectually undermine that by giving the client a new way > of getting access outside the established framework of trust. So, for > example, with an RT a fired employee might still be able to access > resources at a SaaS provider. > > That was the thinking anyway but I don't disagree that the wording in > the draft could make that more clear and/or be a less restrictive. > > Regarding the text you've proposed, I'm not sure I know exactly what > "lifetime of the authorization grant" means or how the AS would know. > And I think it might be too ambiguous to have as normative language. > Can you give a workable definition? Or was it intentionally left kind > of vague? > > I'll should also note that that exact same text is in section 3.1 of > the "JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0" [2] > draft. Whatever we decide, I can't think of any reason it would't > apply to both drafts. And that suggests that it should be moved up > into the "OAuth 2.0 Assertion Profile" - perhaps into section 4.1.3 > [3]? > > Thanks, > Brian > > P.S. My apologies for the extremely slow response - this one just > slipped though the cracks for a while - I have no other excuse. > > > [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-09#section-4.1.3 > [2] http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-03#section-3.1 > [3] http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-4.1.3 > > > > On Fri, Nov 4, 2011 at 2:40 PM, Phil Hunt wrote: > > Section 4.5 of the OAuth Core spec provides that extension spec MAY issue > > refresh tokens. Yet, section 3.1 of the OAuth2 SAML Bearer specification > > currently says SHOULD NOT (from draft 09): > > > > Authorization servers SHOULD issue access tokens with a limited lifetime > and > > require clients to refresh them by requesting a new access token using > the > > same assertion, if it is still valid, or with a new assertion. The > > authorization server SHOULD NOT issue a refresh token. > > > > > > There has been some confusion as to why authorization servers SHOULD NOT > > issue refresh tokens. Apparently this wording was put in place because a > > SAML Bearer authorization might have a shorter life than typical refresh > > token lifetime. Hence there was a concern that an authorization server > would > > inadvertently issue a long-lasting refresh token that outlives the > original > > SAML Bearer authorization. In order to make this concern clear I propose > > the following text that makes clear the concern and makes refresh tokens > > more permissive: > > > > Authorization servers SHOULD issue access tokens with a limited lifetime > and > > require clients to refresh them by requesting a new access token using > the > > same assertion, if it is still valid, or with a new assertion. The > > authorization server SHOULD NOT issue a refresh token that has an expiry > > longer than the lifetime of the authorization grant. > > > > I'm not aware of any other concerns regarding refresh tokens being > issued in > > conjunction with SAML Bearer assertions? Are there any concerns that > > suggest we should keep the wording as generally SHOULD NOT? > > > > Phil > > > > @independentid > > www.independentid.com > > phil.hunt@oracle.com > > > > > > > > > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > --bcaec51b17bbdfda6d04b737cc3e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sorry, I had a section reference and link wrong in the previous message. Th= e question/suggestion about moving some text into the "OAuth 2.0 Asser= tion Profile" should have referenced section 4.2 and linked to here: <= a href=3D"http://tools.ietf.org/html/draft-ietf-oauth-assertions-01#section= -4.2">http://tools.ietf.org/html/draft-ietf-oauth-assertions-01#section-4.2=

That mistake also gives me an excuse to raise this to the WG again.=A0 = I suggest that whatever text we settle on be moved to general assertion pro= file. I'm not sure I know what that text should be.

On Fri, Dec 16, 2011 at 3:58 PM, Brian Campbell <bcampbell@pingidentity.com>= wrote:
Hey Phil,

Your understanding is pretty much inline with how I understand it.
That text actually originates from earlier versions of the core spec
(I think -09 [1] was the last sighting). And I carried it over when
the grant_type got generalized and the assertion pieces moved into the
SAML/OAuth draft.

The main idea was that the extension grants (or at least assertions)
relied on some existing trust framework and that issuing a refresh
token would effectually undermine that by giving the client a new way
of getting access outside the established framework of trust. So, for
example, with an RT a fired employee might still be able to access
resources at a SaaS provider.

That was the thinking anyway but I don't disagree that the wording in the draft could make that more clear and/or be a less restrictive.

Regarding the text you've proposed, I'm not sure I know exactly wha= t
"lifetime of the authorization grant" means or how the AS would k= now.
And I think it might be too ambiguous to have as normative language.
Can you give a workable definition? Or was it intentionally left kind
of vague?

I'll should also note that that exact same text is in section 3.1 of the "JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0" [2= ]
draft. =A0Whatever we decide, I can't think of any reason it would'= t
apply to both drafts. And that suggests that it should be moved up
into the "OAuth 2.0 Assertion Profile" - perhaps into section 4.1= .3
[3]?

Thanks,
Brian

P.S. My apologies for the extremely slow response - this one just
slipped though the cracks for a while - I have no other excuse.


[1] http://tools.ietf.org/html/draft-ietf-oauth-v2-09#se= ction-4.1.3
[2] http://tools.ietf.org/html/draft-jones-oauth-= jwt-bearer-03#section-3.1
[3] http://tools.ietf.org/html/draft-ietf-oauth-v2-10#se= ction-4.1.3



On Fri, Nov 4, 2011 at 2:40 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
> Section 4.5 of the OAuth Core spec provides that extension spec MAY is= sue
> refresh tokens. =A0Yet, section 3.1 of the OAuth2 SAML Bearer specific= ation
> currently says SHOULD NOT (from draft 09):
>
> Authorization servers SHOULD issue access tokens with a limited lifeti= me and
> require clients to refresh them by requesting a new access token using= the
> same assertion, if it is still valid, or with a new assertion. The
> authorization server SHOULD NOT issue a refresh token.
>
>
> There has been some confusion as to why authorization servers SHOULD N= OT
> issue refresh tokens.=A0Apparently this wording was put in place becau= se a
> SAML Bearer authorization might have a shorter life than typical refre= sh
> token lifetime. Hence there was a concern that an authorization server= would
> inadvertently issue a long-lasting refresh token that outlives the ori= ginal
> SAML Bearer authorization. =A0In order to make this concern clear I pr= opose
> the following text that makes clear the concern and makes refresh toke= ns
> more permissive:
>
> Authorization servers SHOULD issue access tokens with a limited lifeti= me and
> require clients to refresh them by requesting a new access token using= the
> same assertion, if it is still valid, or with a new assertion. The
> authorization server SHOULD NOT issue a refresh token that has an expi= ry
> longer than the lifetime of the authorization grant.
>
> I'm not aware of any other concerns regarding refresh tokens being= issued in
> conjunction with SAML Bearer assertions? =A0Are there any concerns tha= t
> suggest we should keep the wording as generally SHOULD NOT?
>
> Phil
>
> @independentid
> www.indepen= dentid.com
> phil.hunt@oracle.com
>
>
>
>
>
>
> __________________= _____________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--bcaec51b17bbdfda6d04b737cc3e-- From sm@elandsys.com Mon Jan 23 15:40:57 2012 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 A5A4C21F86B6 for ; Mon, 23 Jan 2012 15:40:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.465 X-Spam-Level: X-Spam-Status: No, score=-101.465 tagged_above=-999 required=5 tests=[AWL=-1.166, BAYES_00=-2.599, MANGLED_LIST=2.3, 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 jCllB9iOVYSN for ; Mon, 23 Jan 2012 15:40:54 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 99D9621F867B for ; Mon, 23 Jan 2012 15:40:54 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.234.130]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q0NNebXa012758 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Jan 2012 15:40:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1327362052; i=@elandsys.com; bh=lCqBVooJ016BSRsUXp/+3S9c+4Ev8cP+WOY0dLE6mdI=; h=Message-Id:Date:To:From:Subject:Cc:Mime-Version:Content-Type; b=TJkGBmiC7w8nXONHfSgMt5c3flAaz/9/101eVTNQND0zlukskXlJhB2kXAexRo0UI OoXjeG4fqmMR/Zm1y/PKNC0OoG791HY+XwNlk8SNhx274ZUNsY0cV+9ZGJmLPl+PkB HyX4lLxoRap4RJfjaERzk81aM7nlv5VeNxlf4tUc= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1327362052; i=@elandsys.com; bh=lCqBVooJ016BSRsUXp/+3S9c+4Ev8cP+WOY0dLE6mdI=; h=Message-Id:Date:To:From:Subject:Cc:Mime-Version:Content-Type; b=xCjhV6+pjGGNfPC8YWJ1Aeaun8dcsF1+i82m900v2G4/4pRG+MStBB9e0riYdN3W+ uBQnS1oMpQ6hloROmB4UHcTANkB8c+C1tA0eiMWm9kh8XuULbgUkvkVTuvVJ/E3i6c cI7Xg95Lttri8HXekEW2Anjf4ysgPkDF87SuWyfw= Message-Id: <6.2.5.6.2.20120123134319.0a76c338@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 23 Jan 2012 13:47:33 -0800 To: draft-ietf-oauth-v2-threatmodel.all@tools.ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Tim Bray , oauth@ietf.org Subject: [OAUTH-WG] [apps-discuss] Apps Area review of draft-ietf-oauth-v2-threatmodel-01 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, 23 Jan 2012 23:40:57 -0000 The following is the AppsDir review performed by Tim Bray. It would be appreciated if a reply is sent to Tim Bray with a copy to the apps-discuss mailing list. I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-oauth-v2-threatmodel-01 Title: OAuth 2.0 Threat Model and Security Considerations Reviewer: Tim Bray Review Date: Jan 23, 2012 Summary: This needs some more editorial work, but is basically sound. It's not clear, though, whether it wants to be an Informational RFC or not; the use of RFC2119 language needs special attention. I think a few of the "minor issues" are worthy of a little bit more work in another draft. Major Issues: The use of 2119 MUST/SHOULD/etc doesn't seem fully thought through. I normally wouldn't expect a "threat model" to include normative text. The basic idea would be to say "Here is an enumeration of the threats, and here are the tools available to OAUTH2 implementors to meet them." I was impressed by the enumeration, which seemed very complete and well thought through. But the usage of 2119, which makes statements normative, seems inconsistent. I can think of 2 ways to address this: 1. Remove all the 2119 words, so this document isn't normative, and publish it as an Informational RFC 2. Go through and clean up the 2119 language so it's used consistently; then this becomes a normative document. This is going to affect the references to this document from other I-Ds in the OAuth suite, which are currently in last call. Here are all the section-numbered notes enumerating my issues around 2119, as I encountered them: Section 2.3, I'm a little confused about the use of RFC2119 MAY in a threat analysis. When you say "The following data elements MAY be stored or accessible...", Is this saying that "The OAuth2 RFC says that the following data elements MAY be..." or is it saying something else. I don't think there's anything seriously wrong here, but a bit more explanation might be in order. I note a comparative absence of 2119-ese in section 5 describing countermeasures, where one would expect to find it. Also in 4.3.1, first bullet point, there's "Authorization servers MUST..." Also in: 4.4.1.1, 4.4.1.6, 4.4.1.12, 4.6.*, 5.1.4.1.5, 5.1.5.11 Related: "SHALL"?! in 4.6.3 Adding to the concern, there is use of lower-case "must"; note 2nd & 3rd bullet points in 4.4.3, which use "MUST" and "must" respectively. Minor Issues: 4.1.2 first attack: It says "An attack may obtain the refresh tokens issued to a web server client." This needs to be clearer... a "Web server client" can be a browser or a native app. Do you mean, "the refresh tokens issued by the web server to multiple clients?" 4.1.2 last attack. In the case where a device is cloned, wouldn't "Utilize device lock to prevent unauthorized device access" still be a countermeasure? In many devices, such cloning would carry along the user's device-lock settings. 4.4.1.4 2nd bullet. The explanation of why this wouldn't work for native clients wasn't comprehensible to me. I'm suspicious of any such claims because I can emulate most things a browser can do in a mobile client. Perhaps this would be obvious to someone who is an OAuth2 implementor. 4.4.1.9 I think where it says "iFrame" it might mean "WebView", i.e. a Web Browser control embedded in the native app. If that's not what it means, I don't understand what it's saying. If this is true, then the second bullet point is probably wrong. 4.6.6 1st bullet. I'm not convinced that the Cache-Control header will *ensure* that a client protects information properly. Should say something like "minimize the risk that authenticated content is not protected" 5.* The enumeration, for some but not all of the countermeasures in this section, of the threats against which this is a countermeasure, reduces readability and, unless it's generated automatically from the underlying source, is redundant information, which is unlikely to be consistent between sections 4 and 5, and adds difficulty to maintenance of this document without adding much value. I'd just wipe all these bullet lists out. If it's generated automatically it's less damaging, but still reduces readability. In the current draft, this is there for some countermeasures but absent for others. Another good reason to just take it out. 5.2.2.5 Device identifiers are very tricky. It's correct that IMEI is not adequate, but there are ways to do it without SMS. For more, see http://android-developers.blogspot.com/2011/03/identifying-app-installations.html 5.3.4 Surely a little more could be said about device lock. On a typical modern phone, "device lock" options include PINs, passwords, "face recognition" and so on. These are *not* equal in their level of security they provide. Nits: Formatting is lousy. There are notations, including ** and _whatever_ that I'm not familiar with in the RFC context. Section 1.0: s/in-built into/built into/ 2.1, last bullet point: "An example could by a..." s/by/be/ 2.2, 1st bullet point s/eaves drop/eavesdrop/ 2.3, 1st para, s/treat/threat/ 2.3.1, last bullet, "per authorization process". Adjectival phrases should be hyphenated: "per-authorization process" 2.3.3, last bullet, ditto 3.1, 1st para, "all kinds of tokens" should be "many kinds of tokens" 3.1, 2nd para, should be ; not , after "within the authorization server" s/protected/protect/ s/different system/different systems/ 3.4 1st para, s/intermediary/intermediate/ list item 1. s/short-living/short-lived/ 3.5 s/malicious client/malicious clients/ 3.7 top of page 12, what is the underscore notation _client_id_ mean? I'm not familiar with this in the RFC context. 1st bullet point: s/token/token's/ 2nd bullet point, multiple issues, 1st sentence should be " the initial authorization and issuance of a token by an end-user to a particular client, and subsequent requests by this client to obtain tokens without user consent (automatic processing of repeated authorization) halfway down page 13, s/insures/ensures/ s/validates the clients/validates the client's/ 4. first sentence, s/this sections/this section/ 4.1.2 first para, the last sentence is confusing. How about: "Before enumerating the threats, here are some generally applicable countermeasures:" 4.2.4 2nd bullet s/could not be/can not be/ 4.3.3 1st bullet, capitalized phrase "Confidentiality of Requests" - I assume that's supposed to be a hyperlink to one of the 5.* sections? 4.4.1.1 last bullet, s/referee/referrer/ - also, should note that the referrer header may contain an Authorization code in a ?a=b style argument 4.4.1.2 first bullet, "can be employed" is inconsistent with style of rest of doc 4.4.1.3 first 2 bullets have un-labeled links. 4.4.1.4 1st bullet s/authentication/authenticate/ 4.4.1.4 2nd bullet s/mean/means/ 4.4.1.7 2nd bullet s/tokens/token's/ 4.4.1.10, 2nd para, s/requisiete/requisite/ s/embbed/embed/ 4.4.1.10, 3rd bullet, s/aibility/ability/ 4.4.1.10, toward bottom of page 30, s/e.t.c./etc./ 4.4.1.12 I think the href to semicomplete.com needs to be turned into an IETF-style reference 4.4.2 " since HTTP user agents do not send fragments server requests." What you mean to say is "Since HTTP user agents do not send the fragment part of URIs to HTTP servers." 4.4.2.2 s/browser/browser's/ 5.1.4.1.3 s/consider to not store/refrain from storing/ 5.* s/may consider to $(verb)/may consider $(verb)ing/ 5.1.6 Needs some sort of sentence structure 5.3.2 Needs some sort of sentence structure; or is this intended just to be a title, with 5.3.3 etc nested under it? From mike@mtcc.com Mon Jan 23 16:18:05 2012 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 ADA7721F8534 for ; Mon, 23 Jan 2012 16:18:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, 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 IPyrxkrLjFZD for ; Mon, 23 Jan 2012 16:18:05 -0800 (PST) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id F1D1621F852A for ; Mon, 23 Jan 2012 16:18:04 -0800 (PST) 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 q0O0HomV019243 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 23 Jan 2012 16:17:50 -0800 Message-ID: <4F1DF8AE.8000009@mtcc.com> Date: Mon, 23 Jan 2012 16:17:50 -0800 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: S Moonesamy References: <6.2.5.6.2.20120123134319.0a76c338@resistor.net> In-Reply-To: <6.2.5.6.2.20120123134319.0a76c338@resistor.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=1992; t=1327364272; x=1328228272; 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]=20[apps-discuss]=20Apps=20Ar ea=20review=20of=20draft-ietf-oauth-v2-threatmodel-01 |Sender:=20 |To:=20S=20Moonesamy=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=Lyckr7VxRv6EeOmyYzQ4zEbdif2x1Sc1F8v4nGs3xxg=; b=q1d19Tf2Vi5QDGdV9AntyiBU5z/ZqXkXDYu95hOHEwKTAMW+djJf/He5PP 2lRH7ltItobzrAhg5JyZW7nkwFsl9Vh4m2Ux6kvBr5MSuASzHBHTPjEQEDSz MQHr0x/l0aJEue1r1ZzrHqFvH/RawnZ55kRU/IWQRfPQPe/1F3c3I=; 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: Tim Bray , draft-ietf-oauth-v2-threatmodel.all@tools.ietf.org, oauth@ietf.org Subject: Re: [OAUTH-WG] [apps-discuss] Apps Area review of draft-ietf-oauth-v2-threatmodel-01 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, 24 Jan 2012 00:18:05 -0000 On 01/23/2012 01:47 PM, S Moonesamy wrote: > > Minor Issues: > > 4.4.1.4 2nd bullet. The explanation of why this wouldn't work for > native clients wasn't comprehensible to me. I'm suspicious of any > such claims because I can emulate most things a browser can do in a > mobile client. Perhaps this would be obvious to someone who is an > OAuth2 implementor. Actually I'd say that it is *not* obvious because I joined the working group mailing list as an oauth deployer who had precisely questions along these lines expecting that I was *wrong* in worrying about this attack. I'd also say in this section and others like it dealing with native apps that saying: " Assumption: It is not the task of the authorization server to protect the end-user's device from malicious software" Is wrong headed. It's not the authorization server's task to protect the end user, but the authorization server *surely* has an interest in protecting *itself* from rogue clients. An attack by a malicious client is an attack against the end user *and* the authorization server. > > 4.4.1.9 I think where it says "iFrame" it might mean "WebView", i.e. a > Web Browser control embedded in the native app. If that's not what it > means, I don't understand what it's saying. If this is true, then the > second bullet point is probably wrong. I agree, and don't think the first bullet makes any sense either: "Native applications SHOULD use external browsers instead of embedding browsers in an iFrame when requesting end-user authorization" Who exactly is the attacker here? If it's the native app itself, then this isn't a countermeasure at all because the rogue client will ignore this SHOULD. If it's not the native app, then what is the an external browser doing that an embedded browser cannot? I don't understand the third bullet in this one either, but if only works in older browsers it's probably not worth mentioning. Mike From stpeter@stpeter.im Mon Jan 23 19:38:28 2012 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 ECBA021F85C9 for ; Mon, 23 Jan 2012 19:38:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.728 X-Spam-Level: X-Spam-Status: No, score=-102.728 tagged_above=-999 required=5 tests=[AWL=-0.129, 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 9yaZu2h5Pywp for ; Mon, 23 Jan 2012 19:38:28 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 527E921F85AA for ; Mon, 23 Jan 2012 19:38:28 -0800 (PST) Received: from squire.local (unknown [216.17.251.49]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A488040058; Mon, 23 Jan 2012 20:41:50 -0700 (MST) Message-ID: <4F1E2639.10902@stpeter.im> Date: Mon, 23 Jan 2012 20:32:09 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Eran Hammer References: <90C41DD21FB7C64BB94121FBBC2E723453AAB9653D@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453AAB9653D@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-Enigmail-Version: 1.3.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: OAuth WG Subject: Re: [OAUTH-WG] Server cret verification in 10.9 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, 24 Jan 2012 03:38:29 -0000 On 1/20/12 4:46 PM, Eran Hammer wrote: > Stephen asked: > >> (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? > > Can someone help with this? I don’t know enough to address. The OAuth core spec currently says: The client MUST validate the authorization server's TLS certificate in accordance with its requirements for server identity authentication. RFC 2818 has guidance about endpoint identity, in Section 3.1: http://tools.ietf.org/html/rfc2818#section-3.1 RFC 6125 attempts to generalize the guidance from RFC 2818 and many similar specs for use by new application protocols. Given that OAuth as defined by the core spec runs over HTTP, I think referencing RFC 2818 would make sense. So something like: The client MUST validate the authorization server's TLS certificate in accordance with the rules for server identity authentication provided in Section 3.1 of [RFC2818]. Peter -- Peter Saint-Andre https://stpeter.im/ From jricher@mitre.org Tue Jan 24 05:58:25 2012 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 6351321F852D for ; Tue, 24 Jan 2012 05:58:25 -0800 (PST) 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.000, 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 2SHpMJDHNRpJ for ; Tue, 24 Jan 2012 05:58:24 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id C9AC621F8523 for ; Tue, 24 Jan 2012 05:58:24 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 6B3A721B0470 for ; Tue, 24 Jan 2012 08:58:24 -0500 (EST) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 5ED9B21B0453 for ; Tue, 24 Jan 2012 08:58:24 -0500 (EST) Received: from [129.83.50.12] (129.83.31.51) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.1.339.1; Tue, 24 Jan 2012 08:58:23 -0500 Message-ID: <4F1EB8C1.1020300@mitre.org> Date: Tue, 24 Jan 2012 08:57:21 -0500 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: References: <6.2.5.6.2.20120123134319.0a76c338@resistor.net> <4F1DF8AE.8000009@mtcc.com> In-Reply-To: <4F1DF8AE.8000009@mtcc.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [129.83.31.51] Subject: Re: [OAUTH-WG] [apps-discuss] Apps Area review of draft-ietf-oauth-v2-threatmodel-01 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, 24 Jan 2012 13:58:25 -0000 Keep in mind that a major purpose of this document is to encourage best practices by well-meaning developers. We want to make it clear for people who want to do the right thing what the right thing to do is. No document in the world will make ill-meaning developers do the right thing. -- Justin On 01/23/2012 07:17 PM, Michael Thomas wrote: > On 01/23/2012 01:47 PM, S Moonesamy wrote: >> >> Minor Issues: >> >> 4.4.1.4 2nd bullet. The explanation of why this wouldn't work for >> native clients wasn't comprehensible to me. I'm suspicious of any >> such claims because I can emulate most things a browser can do in a >> mobile client. Perhaps this would be obvious to someone who is an >> OAuth2 implementor. > > Actually I'd say that it is *not* obvious because I joined the working > group mailing list as an oauth deployer who had precisely questions > along these lines expecting that I was *wrong* in worrying about this > attack. > > I'd also say in this section and others like it dealing with native apps > that saying: > > " Assumption: It is not the task of the authorization server to > protect the end-user's > device from malicious software" > > Is wrong headed. It's not the authorization server's task to protect > the end user, > but the authorization server *surely* has an interest in protecting > *itself* from > rogue clients. An attack by a malicious client is an attack against > the end user > *and* the authorization server. > >> >> 4.4.1.9 I think where it says "iFrame" it might mean "WebView", i.e. a >> Web Browser control embedded in the native app. If that's not what it >> means, I don't understand what it's saying. If this is true, then the >> second bullet point is probably wrong. > > I agree, and don't think the first bullet makes any sense either: > > "Native applications SHOULD use external browsers instead of > embedding browsers in an iFrame when requesting end-user > authorization" > > Who exactly is the attacker here? If it's the native app itself, then > this isn't a countermeasure at all because the rogue client will ignore > this SHOULD. If it's not the native app, then what is the an external > browser doing that an embedded browser cannot? > > I don't understand the third bullet in this one either, but if only works > in older browsers it's probably not worth mentioning. > > > Mike > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From iesg-secretary@ietf.org Tue Jan 24 06:59:09 2012 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 1A1B421F85B6; Tue, 24 Jan 2012 06:59:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gur1XRT6h3lM; Tue, 24 Jan 2012 06:59:08 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A325521F84F7; Tue, 24 Jan 2012 06:59:08 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120124145908.1516.77776.idtracker@ietfa.amsl.com> Date: Tue, 24 Jan 2012 06:59:08 -0800 Cc: oauth@ietf.org Subject: [OAUTH-WG] REVISED Last Call: (The OAuth 2.0 Authorization Protocol) to Proposed Standard X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 14:59:09 -0000 The IESG has received a request from the Web Authorization Protocol WG (oauth) to consider the following document: - 'The OAuth 2.0 Authorization Protocol' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-02-07. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The OAuth 2.0 authorization protocol enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. There are a few downrefs to note: * There is a normative reference to RFC 1750, which will be updated to point to RFC 4086 before publication. * There is a normative reference to RFC 2246 (TLS 1.0), which has been obsoleted by RFC 5246 (TLS 1.2). The document uses this reference to note that TLS 1.0 is, at this writing, the most widely deployed version. The working group believes it is necessary to note that, and that the reference be normative. * There is a normative reference to Informational RFC 2818 (HTTP over TLS). This is an allowed downref. * There is a normative reference to Informational RFC 4627 (application/json Media Type). This is an allowed downref. * There is a normative reference to Informational RFC 4949 (Internet Security Glossary). This is an allowed downref. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-oauth-v2/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-oauth-v2/ No IPR declarations have been submitted directly on this I-D. From iesg-secretary@ietf.org Tue Jan 24 07:00:07 2012 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 7B71821F8605; Tue, 24 Jan 2012 07:00:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 H54BRUUdzcxz; Tue, 24 Jan 2012 07:00:07 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F198121F85FD; Tue, 24 Jan 2012 07:00:06 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120124150006.1521.19292.idtracker@ietfa.amsl.com> Date: Tue, 24 Jan 2012 07:00:06 -0800 Cc: oauth@ietf.org Subject: [OAUTH-WG] REVISED Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 15:00:07 -0000 The IESG has received a request from the Web Authorization Protocol WG (oauth) to consider the following document: - 'The OAuth 2.0 Authorization Protocol: Bearer Tokens' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-02-07. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract 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 the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport. * There is a normative reference to RFC 2246 (TLS 1.0), which has been obsoleted by RFC 5246 (TLS 1.2). The document uses this reference to note that TLS 1.0 is, at this writing, the most widely deployed version. The working group believes it is necessary to note that, and that the reference be normative. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-oauth-v2-bearer/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-oauth-v2-bearer/ No IPR declarations have been submitted directly on this I-D. From stephen.farrell@cs.tcd.ie Tue Jan 24 07:06:41 2012 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 3991921F8646; Tue, 24 Jan 2012 07:06:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.885 X-Spam-Level: X-Spam-Status: No, score=-102.885 tagged_above=-999 required=5 tests=[AWL=-0.286, 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 kms5gnvHffwh; Tue, 24 Jan 2012 07:06:40 -0800 (PST) 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 6E89921F8638; Tue, 24 Jan 2012 07:06:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id D668C171D15; Tue, 24 Jan 2012 15:06:39 +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=1327417599; bh=sA+ugQ1NuCVFPq BNwJSHsTR71jDsoOfbh+MR1EKI2tg=; b=HMX+oR74o/fALoZNS8S4gQQ2kqEBu2 4jCMql3XT4OnQKGfOQC5SMBeelWlv6C3U7M/Zy/pcFtw1mcfOFygynI0zAjDn0VX DM4DHCWsuXmMwnVwLMa+1a9T3zEXLTA3wMz1WnGmfAf9Q/8+C/hJfIq/8qFZukWS LjK18HJIhocCSTYirQj1UW2TXDbz/jzXkzEf3P3j3nFjzBggIzw2rHZTzmy832vC x1nm2PsEqK5LYKpfoa865QF9K63CFSy7gQl4+XWg7S/V0dFMrUQ8Jz7V1N3IxMkF tSsTsocfFH//XfEX3iONRJU2OOR/TU+6lKT/Bg8D78wU38sP3Gdm142Q== 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 2lZhsqgULZr6; Tue, 24 Jan 2012 15:06:39 +0000 (GMT) Received: from [10.1.1.138] (wifi.ist.utl.pt [193.136.128.57]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id A6AA7171C04; Tue, 24 Jan 2012 15:06:38 +0000 (GMT) Message-ID: <4F1EC8FD.2020307@cs.tcd.ie> Date: Tue, 24 Jan 2012 15:06:37 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: ietf@ietf.org References: <20120124150006.1521.19292.idtracker@ietfa.amsl.com> In-Reply-To: <20120124150006.1521.19292.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: The IESG , oauth@ietf.org, IETF-Announce Subject: Re: [OAUTH-WG] REVISED Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard 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, 24 Jan 2012 15:06:41 -0000 Folks, The OAuth bearer and base last calls had to be re-done since I forgot to include some downref information. Other than adding a day to IETF LC, there should be no other difference. Sorry about that. S On 01/24/2012 03:00 PM, The IESG wrote: > > The IESG has received a request from the Web Authorization Protocol WG > (oauth) to consider the following document: > - 'The OAuth 2.0 Authorization Protocol: Bearer Tokens' > as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2012-02-07. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > 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 > the associated resources (without demonstrating possession of a > cryptographic key). To prevent misuse, bearer tokens need to be > protected from disclosure in storage and in transport. > > > * There is a normative reference to RFC 2246 (TLS 1.0), which has been > obsoleted by RFC 5246 (TLS 1.2). The document uses this reference to > note that TLS 1.0 is, at this writing, the most widely deployed > version. The working group believes it is necessary to note that, and > that the reference be normative. > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-oauth-v2-bearer/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-oauth-v2-bearer/ > > > No IPR declarations have been submitted directly on this I-D. > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > From mike@mtcc.com Tue Jan 24 11:06:02 2012 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 2F8C321F8550 for ; Tue, 24 Jan 2012 11:06:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, 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 nVB1--4XTNZe for ; Tue, 24 Jan 2012 11:06:01 -0800 (PST) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 342BA21F855F for ; Tue, 24 Jan 2012 11:06:01 -0800 (PST) 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 q0OJ5vpJ019969 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 24 Jan 2012 11:05:58 -0800 Message-ID: <4F1F0115.4070704@mtcc.com> Date: Tue, 24 Jan 2012 11:05:57 -0800 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: Justin Richer References: <6.2.5.6.2.20120123134319.0a76c338@resistor.net> <4F1DF8AE.8000009@mtcc.com> <4F1EB8C1.1020300@mitre.org> In-Reply-To: <4F1EB8C1.1020300@mitre.org> 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=2978; t=1327431958; x=1328295958; 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]=20[apps-discuss]=20Apps=20Ar ea=20review=20of=20draft-ietf-oauth-v2-threatmodel-01 |Sender:=20 |To:=20Justin=20Richer=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=cvbRGHNWa4QIKEJShvzp5f/4ejraWmDprivx4Pf8m9w=; b=M3w5XLxfSfMJDx6p/Y5TNBQElNSr2XDabAp8lZcWRONV1T0TEbosvZ3/ii eWU9WXA056c9Zgw1dNtSX+fagAFmrINWBjn6R+MJB5K8+YbWMhBAYXFZ1ZnY fIClyrV9ErNAahm2KxXDvy8L4pdE/p+DExWa8gO322YueCP26+tec=; 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] [apps-discuss] Apps Area review of draft-ietf-oauth-v2-threatmodel-01 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, 24 Jan 2012 19:06:02 -0000 On 01/24/2012 05:57 AM, Justin Richer wrote: > Keep in mind that a major purpose of this document is to encourage best practices by well-meaning developers. We want to make it clear for people who want to do the right thing what the right thing to do is. No document in the world will make ill-meaning developers do the right thing. That what BCP's are for. A threat document is supposed to outline threats and what good guys can do to mitigate them. Telling bad guys to be good is completely useless. Mike > > -- Justin > > On 01/23/2012 07:17 PM, Michael Thomas wrote: >> On 01/23/2012 01:47 PM, S Moonesamy wrote: >>> >>> Minor Issues: >>> >>> 4.4.1.4 2nd bullet. The explanation of why this wouldn't work for >>> native clients wasn't comprehensible to me. I'm suspicious of any >>> such claims because I can emulate most things a browser can do in a >>> mobile client. Perhaps this would be obvious to someone who is an >>> OAuth2 implementor. >> >> Actually I'd say that it is *not* obvious because I joined the working >> group mailing list as an oauth deployer who had precisely questions >> along these lines expecting that I was *wrong* in worrying about this >> attack. >> >> I'd also say in this section and others like it dealing with native apps >> that saying: >> >> " Assumption: It is not the task of the authorization server to protect the end-user's >> device from malicious software" >> >> Is wrong headed. It's not the authorization server's task to protect the end user, >> but the authorization server *surely* has an interest in protecting *itself* from >> rogue clients. An attack by a malicious client is an attack against the end user >> *and* the authorization server. >> >>> >>> 4.4.1.9 I think where it says "iFrame" it might mean "WebView", i.e. a >>> Web Browser control embedded in the native app. If that's not what it >>> means, I don't understand what it's saying. If this is true, then the >>> second bullet point is probably wrong. >> >> I agree, and don't think the first bullet makes any sense either: >> >> "Native applications SHOULD use external browsers instead of >> embedding browsers in an iFrame when requesting end-user authorization" >> >> Who exactly is the attacker here? If it's the native app itself, then >> this isn't a countermeasure at all because the rogue client will ignore >> this SHOULD. If it's not the native app, then what is the an external >> browser doing that an embedded browser cannot? >> >> I don't understand the third bullet in this one either, but if only works >> in older browsers it's probably not worth mentioning. >> >> >> 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 torsten@lodderstedt.net Tue Jan 24 11:38:17 2012 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 82A5411E8079 for ; Tue, 24 Jan 2012 11:38:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.099 X-Spam-Level: X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, HELO_EQ_DE=0.35, MANGLED_LIST=2.3] 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 LcaI4eoAoYSW for ; Tue, 24 Jan 2012 11:38:16 -0800 (PST) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.29.23]) by ietfa.amsl.com (Postfix) with ESMTP id 026FB21F8534 for ; Tue, 24 Jan 2012 11:38:15 -0800 (PST) Received: from [79.253.11.185] (helo=[192.168.71.42]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1RpmC2-00076Q-WF; Tue, 24 Jan 2012 20:38:11 +0100 Message-ID: <4F1F08A2.4020707@lodderstedt.net> Date: Tue, 24 Jan 2012 20:38:10 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: S Moonesamy References: <6.2.5.6.2.20120123134319.0a76c338@resistor.net> In-Reply-To: <6.2.5.6.2.20120123134319.0a76c338@resistor.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: Tim Bray , draft-ietf-oauth-v2-threatmodel.all@tools.ietf.org, oauth@ietf.org Subject: Re: [OAUTH-WG] [apps-discuss] Apps Area review of draft-ietf-oauth-v2-threatmodel-01 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, 24 Jan 2012 19:38:17 -0000 Hi, thanks for the thoroughly review. The threat document is intended to become an Informational RFC. So we will follow your advice and remove all normative language. regards, Torsten. Am 23.01.2012 22:47, schrieb S Moonesamy: > The following is the AppsDir review performed by Tim Bray. It would > be appreciated if a reply is sent to Tim Bray with a copy to the > apps-discuss mailing list. > > I have been selected as the Applications Area Directorate reviewer for > this draft (for background on appsdir, please see > http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). > > > Please resolve these comments along with any other Last Call comments > you may receive. Please wait for direction from your document shepherd > or AD before posting a new version of the draft. > > Document: draft-ietf-oauth-v2-threatmodel-01 > Title: OAuth 2.0 Threat Model and Security Considerations > Reviewer: Tim Bray > Review Date: Jan 23, 2012 > > Summary: This needs some more editorial work, but is basically sound. > It's not clear, though, whether it wants to be an Informational RFC or > not; the use of RFC2119 language needs special attention. I think a > few of the "minor issues" are worthy of a little bit more work in > another draft. > > Major Issues: > > The use of 2119 MUST/SHOULD/etc doesn't seem fully thought through. I > normally wouldn't expect a "threat model" to include normative text. > The basic idea would be to say "Here is an enumeration of the threats, > and here are the tools available to OAUTH2 implementors to meet them." > I was impressed by the enumeration, which seemed very complete and > well thought through. But the usage of 2119, which makes statements > normative, seems inconsistent. I can think of 2 ways to address this: > > 1. Remove all the 2119 words, so this document isn't normative, and > publish it as an Informational RFC > 2. Go through and clean up the 2119 language so it's used > consistently; then this becomes a normative document. > > This is going to affect the references to this document from other > I-Ds in the OAuth suite, which are currently in last call. > > Here are all the section-numbered notes enumerating my issues around > 2119, as I encountered them: > > Section 2.3, I'm a little confused about the use of RFC2119 MAY in a > threat analysis. When you say "The following data elements MAY be > stored or accessible...", Is this saying that "The OAuth2 RFC says > that the following data elements MAY be..." or is it saying something > else. I don't think there's anything seriously wrong here, but a bit > more explanation might be in order. I note a comparative absence of > 2119-ese in section 5 describing countermeasures, where one would > expect to find it. > Also in 4.3.1, first bullet point, there's "Authorization servers > MUST..." > Also in: 4.4.1.1, 4.4.1.6, 4.4.1.12, 4.6.*, 5.1.4.1.5, 5.1.5.11 > Related: "SHALL"?! in 4.6.3 > Adding to the concern, there is use of lower-case "must"; note 2nd & > 3rd bullet points in 4.4.3, which use "MUST" and "must" respectively. > > Minor Issues: > > 4.1.2 first attack: It says "An attack may obtain the refresh tokens > issued to a web server client." This needs to be clearer... a "Web > server client" can be a browser or a native app. Do you mean, "the > refresh tokens issued by the web server to multiple clients?" > > 4.1.2 last attack. In the case where a device is cloned, wouldn't > "Utilize device lock to prevent unauthorized device access" still be a > countermeasure? In many devices, such cloning would carry along the > user's device-lock settings. > > 4.4.1.4 2nd bullet. The explanation of why this wouldn't work for > native clients wasn't comprehensible to me. I'm suspicious of any > such claims because I can emulate most things a browser can do in a > mobile client. Perhaps this would be obvious to someone who is an > OAuth2 implementor. > > 4.4.1.9 I think where it says "iFrame" it might mean "WebView", i.e. a > Web Browser control embedded in the native app. If that's not what it > means, I don't understand what it's saying. If this is true, then the > second bullet point is probably wrong. > > 4.6.6 1st bullet. I'm not convinced that the Cache-Control header > will *ensure* that a client protects information properly. Should say > something like "minimize the risk that authenticated content is not > protected" > > 5.* The enumeration, for some but not all of the countermeasures in > this section, of the threats against which this is a countermeasure, > reduces readability and, unless it's generated automatically from the > underlying source, is redundant information, which is unlikely to be > consistent between sections 4 and 5, and adds difficulty to > maintenance of this document without adding much value. I'd just wipe > all these bullet lists out. If it's generated automatically it's less > damaging, but still reduces readability. In the current draft, this > is there for some countermeasures but absent for others. Another good > reason to just take it out. > > 5.2.2.5 Device identifiers are very tricky. It's correct that IMEI is > not adequate, but there are ways to do it without SMS. For more, see > http://android-developers.blogspot.com/2011/03/identifying-app-installations.html > > > 5.3.4 Surely a little more could be said about device lock. On a > typical modern phone, "device lock" options include PINs, passwords, > "face recognition" and so on. These are *not* equal in their level of > security they provide. > > Nits: > > Formatting is lousy. There are notations, including ** and _whatever_ > that I'm not familiar with in the RFC context. > > Section 1.0: s/in-built into/built into/ > 2.1, last bullet point: "An example could by a..." s/by/be/ > 2.2, 1st bullet point s/eaves drop/eavesdrop/ > 2.3, 1st para, s/treat/threat/ > 2.3.1, last bullet, "per authorization process". Adjectival phrases > should be hyphenated: "per-authorization process" > 2.3.3, last bullet, ditto > 3.1, 1st para, "all kinds of tokens" should be "many kinds of tokens" > 3.1, 2nd para, should be ; not , after "within the authorization server" > s/protected/protect/ > s/different system/different systems/ > 3.4 1st para, s/intermediary/intermediate/ > list item 1. s/short-living/short-lived/ > 3.5 s/malicious client/malicious clients/ > 3.7 top of page 12, what is the underscore notation _client_id_ mean? > I'm not familiar with this in the RFC context. > 1st bullet point: s/token/token's/ > 2nd bullet point, multiple issues, 1st sentence should be " the > initial authorization and issuance of a token by an end-user > to a particular client, and subsequent requests by this client to > obtain tokens without user consent (automatic processing of repeated > authorization) > halfway down page 13, s/insures/ensures/ > s/validates the clients/validates the client's/ > 4. first sentence, s/this sections/this section/ > 4.1.2 first para, the last sentence is confusing. How about: "Before > enumerating the threats, here are some generally applicable > countermeasures:" > 4.2.4 2nd bullet s/could not be/can not be/ > 4.3.3 1st bullet, capitalized phrase "Confidentiality of Requests" - I > assume that's supposed to be a hyperlink to one of the 5.* sections? > 4.4.1.1 last bullet, s/referee/referrer/ - also, should note that the > referrer header may contain an Authorization code in a ?a=b style > argument > 4.4.1.2 first bullet, "can be employed" is inconsistent with style of > rest of doc > 4.4.1.3 first 2 bullets have un-labeled links. > 4.4.1.4 1st bullet s/authentication/authenticate/ > 4.4.1.4 2nd bullet s/mean/means/ > 4.4.1.7 2nd bullet s/tokens/token's/ > 4.4.1.10, 2nd para, s/requisiete/requisite/ s/embbed/embed/ > 4.4.1.10, 3rd bullet, s/aibility/ability/ > 4.4.1.10, toward bottom of page 30, s/e.t.c./etc./ > 4.4.1.12 I think the href to semicomplete.com needs to be turned into > an IETF-style reference > 4.4.2 " since HTTP user agents do not send fragments server requests." > What you mean to say is "Since HTTP user agents do not send the > fragment part of URIs to HTTP servers." > 4.4.2.2 s/browser/browser's/ > 5.1.4.1.3 s/consider to not store/refrain from storing/ > 5.* s/may consider to $(verb)/may consider $(verb)ing/ > 5.1.6 Needs some sort of sentence structure > 5.3.2 Needs some sort of sentence structure; or is this intended just > to be a title, with 5.3.3 etc nested under it? > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From ve7jtb@ve7jtb.com Tue Jan 24 12:18:36 2012 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 DD8F221F84C8 for ; Tue, 24 Jan 2012 12:18:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.482 X-Spam-Level: X-Spam-Status: No, score=-3.482 tagged_above=-999 required=5 tests=[AWL=0.117, 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 JQHsowNtLxG9 for ; Tue, 24 Jan 2012 12:18:36 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0BCC121F84C5 for ; Tue, 24 Jan 2012 12:18:35 -0800 (PST) Received: by ggnq4 with SMTP id q4so1811897ggn.31 for ; Tue, 24 Jan 2012 12:18:35 -0800 (PST) Received: by 10.101.132.5 with SMTP id j5mr6258712ann.2.1327436315477; Tue, 24 Jan 2012 12:18:35 -0800 (PST) Received: from [192.168.1.213] ([190.22.35.180]) by mx.google.com with ESMTPS id h36sm15304432yhj.6.2012.01.24.12.18.32 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 24 Jan 2012 12:18:34 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/signed; boundary="Apple-Mail=_B62B4A6F-DD62-45EC-A00A-7588D115FC7A"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <4F1F0115.4070704@mtcc.com> Date: Tue, 24 Jan 2012 17:18:28 -0300 Message-Id: <5714073F-4950-4398-8641-4BA8A491EDA3@ve7jtb.com> References: <6.2.5.6.2.20120123134319.0a76c338@resistor.net> <4F1DF8AE.8000009@mtcc.com> <4F1EB8C1.1020300@mitre.org> <4F1F0115.4070704@mtcc.com> To: Michael Thomas X-Mailer: Apple Mail (2.1251.1) X-Gm-Message-State: ALoCoQnkYkbduFrQt0GjIvSy4NS2o0m9GIObxzfKrVofm2L+ro15uNMyxzqBqmiDtiug8tJd+BNp Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] [apps-discuss] Apps Area review of draft-ietf-oauth-v2-threatmodel-01 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, 24 Jan 2012 20:18:37 -0000 --Apple-Mail=_B62B4A6F-DD62-45EC-A00A-7588D115FC7A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The advice needs to be actionable. A similar issue exists with openID. Good RP don't use the popup login = in a frameless window. We want the user to be able to see where they = are logging in. The idea being that wen a bad RP redirects the user to a phishing site = in a frameless window to collect there credentials they will notice. This may be wishful thinking based on user behaviour, however having = good RP exhibit proper behaviour and train users is better than nothing. In the OAuth case training users to never enter credentials into a = embedded web view needs the good people's help. Perhaps a better explanation of what behaviour we are trying to teach = users is needed. If the counter argument is that a phisher can generate a experience = indistinguishable from a legitimate "Trusted" browser, then the advice = is probably not actionable. The real action is training users to detect phishing. There is no real = technological protection from people installing native clients that are = phishing them. John B. On 2012-01-24, at 4:05 PM, Michael Thomas wrote: > On 01/24/2012 05:57 AM, Justin Richer wrote: >> Keep in mind that a major purpose of this document is to encourage = best practices by well-meaning developers. We want to make it clear for = people who want to do the right thing what the right thing to do is. No = document in the world will make ill-meaning developers do the right = thing. >=20 >=20 > That what BCP's are for. A threat document is supposed to outline = threats > and what good guys can do to mitigate them. Telling bad guys to be = good > is completely useless. >=20 > Mike >=20 >>=20 >> -- Justin >>=20 >> On 01/23/2012 07:17 PM, Michael Thomas wrote: >>> On 01/23/2012 01:47 PM, S Moonesamy wrote: >>>>=20 >>>> Minor Issues: >>>>=20 >>>> 4.4.1.4 2nd bullet. The explanation of why this wouldn't work for >>>> native clients wasn't comprehensible to me. I'm suspicious of any >>>> such claims because I can emulate most things a browser can do in a >>>> mobile client. Perhaps this would be obvious to someone who is an >>>> OAuth2 implementor. >>>=20 >>> Actually I'd say that it is *not* obvious because I joined the = working >>> group mailing list as an oauth deployer who had precisely questions >>> along these lines expecting that I was *wrong* in worrying about = this >>> attack. >>>=20 >>> I'd also say in this section and others like it dealing with native = apps >>> that saying: >>>=20 >>> " Assumption: It is not the task of the authorization server to = protect the end-user's >>> device from malicious software" >>>=20 >>> Is wrong headed. It's not the authorization server's task to protect = the end user, >>> but the authorization server *surely* has an interest in protecting = *itself* from >>> rogue clients. An attack by a malicious client is an attack against = the end user >>> *and* the authorization server. >>>=20 >>>>=20 >>>> 4.4.1.9 I think where it says "iFrame" it might mean "WebView", = i.e. a >>>> Web Browser control embedded in the native app. If that's not what = it >>>> means, I don't understand what it's saying. If this is true, then = the >>>> second bullet point is probably wrong. >>>=20 >>> I agree, and don't think the first bullet makes any sense either: >>>=20 >>> "Native applications SHOULD use external browsers instead of >>> embedding browsers in an iFrame when requesting end-user = authorization" >>>=20 >>> Who exactly is the attacker here? If it's the native app itself, = then >>> this isn't a countermeasure at all because the rogue client will = ignore >>> this SHOULD. If it's not the native app, then what is the an = external >>> browser doing that an embedded browser cannot? >>>=20 >>> I don't understand the third bullet in this one either, but if only = works >>> in older browsers it's probably not worth mentioning. >>>=20 >>>=20 >>> Mike >>> _______________________________________________ >>> 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 --Apple-Mail=_B62B4A6F-DD62-45EC-A00A-7588D115FC7A 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 DgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjAx MjQyMDE4MjhaMCMGCSqGSIb3DQEJBDEWBBSAXeeTDIRzwJqpFLaXqb7cY4Rq7zCBpAYJKwYBBAGC NxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgZDMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzANBgkqhkiG9w0BAQEFAASC AQC97XYVqdCL+4rC7JKEiS4JtTbz0ZE+pQBCnFdaYGAJkZkUKhvLgYVU8K66zGz8vPKsIQfZTPNJ oXL8jbrXfZEIYc0A95QfzebaCWZ7i7CHl94G5b7RwkNEhWcQITx6TDP3Y6KhPLX/2CivRujDYQ3W R9C1xF6Z7866PfxZzdPLPgwcrYm1PwhCjYdiNOPocs7uaG8UFCymhL6Pz1Bbdrr+a/ynGA8PbmhX uChmCC86HmidYIS7A+VdwOaEB36oOgRBkNyFDmUm7oGIDCjjU8FWjUsPUt9WU9Pw3SEd2sEPYYfg Ud87b+nPoiwnNHjHzgZ5ZkEZ843VJFUzGFtE8rYfAAAAAAAA --Apple-Mail=_B62B4A6F-DD62-45EC-A00A-7588D115FC7A-- From ve7jtb@ve7jtb.com Tue Jan 24 14:24:20 2012 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 D9DFB1F0C35 for ; Tue, 24 Jan 2012 14:24:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 Lqi2uW6uEuC0 for ; Tue, 24 Jan 2012 14:24:20 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id EE11821F85C0 for ; Tue, 24 Jan 2012 14:24:19 -0800 (PST) Received: by yhnn12 with SMTP id n12so2267401yhn.31 for ; Tue, 24 Jan 2012 14:24:19 -0800 (PST) Received: by 10.236.93.4 with SMTP id k4mr21038437yhf.114.1327443859517; Tue, 24 Jan 2012 14:24:19 -0800 (PST) Received: from [192.168.1.213] ([190.22.35.180]) by mx.google.com with ESMTPS id q29sm48545473anh.1.2012.01.24.14.24.15 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 24 Jan 2012 14:24:17 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/signed; boundary="Apple-Mail=_01B45CF7-77A5-42F0-93E2-149EFEB8A80A"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <4F1E2639.10902@stpeter.im> Date: Tue, 24 Jan 2012 19:24:12 -0300 Message-Id: <494090F8-EEC5-4156-B372-D06745E01552@ve7jtb.com> References: <90C41DD21FB7C64BB94121FBBC2E723453AAB9653D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4F1E2639.10902@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1251.1) X-Gm-Message-State: ALoCoQlhzTJw65nBrqWr8O7hcW8kJXSZgyqqbOGnakTdMbxF2HuAueE0OAHYNnQlYRRPi6c7YZi0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Server cret verification in 10.9 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, 24 Jan 2012 22:24:21 -0000 --Apple-Mail=_01B45CF7-77A5-42F0-93E2-149EFEB8A80A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 We added the reference to RFC6125 in openID Connect. The Client MUST perform a TLS/SSL server certificate check, per RFC 6125. We wanted to be more general to allow for non http bindings in the = future. If you don't do it in core, every spec that references core will = probably have to add it. John B. On 2012-01-24, at 12:32 AM, Peter Saint-Andre wrote: > On 1/20/12 4:46 PM, Eran Hammer wrote: >> Stephen asked: >>=20 >>> (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=20= >>> you want to be explicit here about the TLS server cert and thereby=20= >>> possibly rule out using DANE with the non PKI options that that WG=20= >>> (may) produce? >>=20 >> Can someone help with this? I don=92t know enough to address. >=20 > The OAuth core spec currently says: >=20 > The client MUST validate the authorization server's > TLS certificate in accordance with its requirements > for server identity authentication. >=20 > RFC 2818 has guidance about endpoint identity, in Section 3.1: >=20 > http://tools.ietf.org/html/rfc2818#section-3.1 >=20 > RFC 6125 attempts to generalize the guidance from RFC 2818 and many > similar specs for use by new application protocols. Given that OAuth = as > defined by the core spec runs over HTTP, I think referencing RFC 2818 > would make sense. So something like: >=20 > The client MUST validate the authorization server's > TLS certificate in accordance with the rules for > server identity authentication provided in Section 3.1 > of [RFC2818]. >=20 > Peter >=20 > --=20 > Peter Saint-Andre > https://stpeter.im/ >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_01B45CF7-77A5-42F0-93E2-149EFEB8A80A 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 DgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjAx MjQyMjI0MTNaMCMGCSqGSIb3DQEJBDEWBBS/y0PO6BczLPrq/GGMGevPjQMUCDCBpAYJKwYBBAGC NxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgZDMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzANBgkqhkiG9w0BAQEFAASC AQBeN23c6x82YlWs39vwFPDxusfhfWvdIcrvzgf5oyA9AJ0dW/OR+gAFV5ikzzqGZKz7WvXbXVhP m8Yap+WEs7+4LF2blhwEE0XRCYslmD5R68pdQY3qrsXak8CD/8jA8MknXEbmHTPV0VZiGiHGxKgJ jg2hJLUwR3tI5u9K6WinsBzj6s5hkgAkHMkmu827ym2RI+gl4zlGfkeMrGCtgRmN9ki9N5Ui6sKX gtHZWCl+wAV4w/u0daiudgJt+i0BKftBlw32Oa3CAbFiNv6EThlxLvdtR58GQf9jZqi0gJ5b55IX 4fe1K4CN0XRgSW9g4MpYOPKm/hsGyGSqRWcwkaKuAAAAAAAA --Apple-Mail=_01B45CF7-77A5-42F0-93E2-149EFEB8A80A-- From mnot@mnot.net Tue Jan 24 15:18:47 2012 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 9431C21F84DA; Tue, 24 Jan 2012 15:18:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-4.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 StlGBR0dQ3Th; Tue, 24 Jan 2012 15:18:46 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id D2BA021F84D7; Tue, 24 Jan 2012 15:18:46 -0800 (PST) Received: from mnot-mini.mnot.net (unknown [118.209.240.235]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 1165F22E25C; Tue, 24 Jan 2012 18:18:39 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1251.1) From: Mark Nottingham Date: Wed, 25 Jan 2012 10:18:36 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <4D97B96E-4186-4B63-A254-013D803FD459@mnot.net> References: <4F1D847A.6060404@gmx.de> To: IETF Discussion X-Mailer: Apple Mail (2.1251.1) Cc: OAuth WG Subject: Re: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard 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, 24 Jan 2012 23:18:47 -0000 My comments were made in: = http://www.ietf.org/mail-archive/web/apps-discuss/current/msg03805.html Most of them (excepting the nits) haven't been addressed in the drafts. Regards, Begin forwarded message: > Subject: [OAUTH-WG] Last Call: = (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed = Standard > Date: Mon, 23 Jan 2012 07:46:43 -0800 > From: The IESG > Reply-To: ietf@ietf.org > To: IETF-Announce > CC: oauth@ietf.org >=20 >=20 > The IESG has received a request from the Web Authorization Protocol WG > (oauth) to consider the following document: > - 'The OAuth 2.0 Authorization Protocol: Bearer Tokens' > as a Proposed Standard >=20 > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2012-02-06. Exceptionally, comments may = be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. >=20 > Abstract >=20 >=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 > the associated resources (without demonstrating possession of a > cryptographic key). To prevent misuse, bearer tokens need to be > protected from disclosure in storage and in transport. >=20 >=20 >=20 >=20 > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-oauth-v2-bearer/ >=20 > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-oauth-v2-bearer/ >=20 >=20 > No IPR declarations have been submitted directly on this I-D. >=20 -- Mark Nottingham http://www.mnot.net/ From julian.reschke@gmx.de Tue Jan 24 15:24:06 2012 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 D7F9111E809F for ; Tue, 24 Jan 2012 15:24:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.468 X-Spam-Level: X-Spam-Status: No, score=-103.468 tagged_above=-999 required=5 tests=[AWL=-0.869, 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 h7lEok1Cl767 for ; Tue, 24 Jan 2012 15:24:06 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id B5CCD11E809A for ; Tue, 24 Jan 2012 15:24:05 -0800 (PST) Received: (qmail invoked by alias); 24 Jan 2012 23:24:04 -0000 Received: from p5DCC2B6A.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.43.106] by mail.gmx.net (mp028) with SMTP; 25 Jan 2012 00:24:04 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+XfokYg2GXmtZex/QIvMdvr6dE14RR6CtUtd/Hzx /ySMTdF+SONJ+n Message-ID: <4F1F3D84.1030300@gmx.de> Date: Wed, 25 Jan 2012 00:23:48 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: ietf@ietf.org References: <20120123154643.16223.44509.idtracker@ietfa.amsl.com> <4F1D8391.3080009@gmx.de> In-Reply-To: <4F1D8391.3080009@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: The IESG , oauth@ietf.org Subject: Re: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard 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, 24 Jan 2012 23:24:07 -0000 On 2012-01-23 16:58, Julian Reschke wrote: > On 2012-01-23 16:46, The IESG wrote: >> >> The IESG has received a request from the Web Authorization Protocol WG >> (oauth) to consider the following document: >> - 'The OAuth 2.0 Authorization Protocol: Bearer Tokens' >> as a Proposed Standard >> ... > > Please see my comments in > > which I think have not been addressed. > ... In an off-list conversation I heard that what I said before may not be as clear as it could be. So... 1) draft-ietf-oauth-v2-bearer-15 defines a new HTTP authentication scheme. 2) In the IANA considerations, it references the registration procedure defined in (now -18, but that doesn't matter here). 3) That document recommends in : o The parsing of challenges and credentials is defined by this specification, and cannot be modified by new authentication schemes. When the auth-param syntax is used, all parameters ought to support both token and quoted-string syntax, and syntactical constraints ought to be defined on the field value after parsing (i.e., quoted-string processing). This is necessary so that recipients can use a generic parser that applies to all authentication schemes. 4) draft-ietf-oauth-v2-bearer-15 ignores this recommendation. It has been mentioned that it might not have ignored it if it had UPPERCASE requirements, but in HTTPbis we try to restrict BCP14 keywords to the actual protocol, not on recommendations on other specs. 5) The registration requirement for a new scheme is "IETF review", which RFC 5226 defines in as: IETF Review - (Formerly called "IETF Consensus" in [IANA-CONSIDERATIONS]) New values are assigned only through RFCs that have been shepherded through the IESG as AD- Sponsored or IETF WG Documents [RFC3932] [RFC3978]. The intention is that the document and proposed assignment will be reviewed by the IESG and appropriate IETF WGs (or experts, if suitable working groups no longer exist) to ensure that the proposed assignment will not negatively impact interoperability or otherwise extend IETF protocols in an inappropriate or damaging manner. In this case the WG exists (it's HTTPbis), and the OAuth got two reviews from HTTPbis pointing out the problem -- from Mark Nottingham, the WG chair, and myself, one of the authors. And yes, I believe the way OAuth defines the syntax *will* impact interoperability. Also, I haven't seen any explanation why OAuth can not follow the recommendation from HTTPbis. Hope this clarifies things, Julian From julian.reschke@gmx.de Tue Jan 24 15:26:05 2012 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 79AF311E809B for ; Tue, 24 Jan 2012 15:26:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.417 X-Spam-Level: X-Spam-Status: No, score=-103.417 tagged_above=-999 required=5 tests=[AWL=-0.818, 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 SWAqxIX20jp0 for ; Tue, 24 Jan 2012 15:26:05 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 9823D11E8086 for ; Tue, 24 Jan 2012 15:26:04 -0800 (PST) Received: (qmail invoked by alias); 24 Jan 2012 23:26:03 -0000 Received: from p5DCC2B6A.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.43.106] by mail.gmx.net (mp021) with SMTP; 25 Jan 2012 00:26:03 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18K1W9LphkKVQQZ+ATDPbXJzzYRebH0AhGVYUN2L3 IHlGRAPHP8r6FS Message-ID: <4F1F3DFA.7050506@gmx.de> Date: Wed, 25 Jan 2012 00:25:46 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Peter Saint-Andre References: <4E1F6AAD24975D4BA5B168042967394366375EB9@TK5EX14MBXC284.redmond.corp.microsoft.com> <4F1D9B57.1030501@stpeter.im> In-Reply-To: <4F1D9B57.1030501@stpeter.im> 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 specs in IETF last call 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, 24 Jan 2012 23:26:05 -0000 On 2012-01-23 18:39, Peter Saint-Andre wrote: > On 1/23/12 10:11 AM, Mike Jones wrote: >> FYI, the OAuth Core and Bearer specifications have reached IETF last >> call status - the last step before becoming RFCs. See the following >> notes from the Internet Engineering Steering Group (IESG). > > Well, "last step" might be a bit optimistic. :) > > For those who aren't familiar with the process, the next steps are: > > 1. IETF Last Call, which lasts two weeks. This is essentially your last > opportunity to provide feedback! > > 2. During IETF Last Call, the documents will be reviewed by several > cross-area teams within the IETF, including folks like the "GEN-ART" > review team and the AppsDir. We'll expect at least some feedback from > those teams. And at this stage anyone in the Internet community can > provide feedback, too. > > 3. After IETF Last Call, this WG's document editors will work to address > any feedback we've received. > > 4. The documents will then be scheduled for disussion during an IESG > telechat. Before the telechat, all the members of the Internet > Engineering Steering Group will review the specs and also provide > feedback. If there are "DISCUSSES" and "COMMENTS" lodged then the > document editors will need to address those (often in concert with the > WG chairs). If some of those issues are substantive, the editors and > chairs might bring those issues back to the WG for more discussion. > > 5. Assuming the documents are approved by the IESG, they will then be > handed off to the RFC Editor team for final copy editing, proofreading, > reference checking, etc. > ... 6. ...and then will have to wait until all normatively referenced drafts are ready, too. Best regards, Julian From Michael.Jones@microsoft.com Tue Jan 24 15:35:16 2012 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 BF4E321F84FC; Tue, 24 Jan 2012 15:35:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.249 X-Spam-Level: X-Spam-Status: No, score=-5.249 tagged_above=-999 required=5 tests=[AWL=1.350, 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 RGwWy2d79-vI; Tue, 24 Jan 2012 15:35:16 -0800 (PST) Received: from TX2EHSOBE002.bigfish.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id D6D6E21F84EA; Tue, 24 Jan 2012 15:35:15 -0800 (PST) Received: from mail193-tx2-R.bigfish.com (10.9.14.242) by TX2EHSOBE002.bigfish.com (10.9.40.22) with Microsoft SMTP Server id 14.1.225.23; Tue, 24 Jan 2012 23:35:15 +0000 Received: from mail193-tx2 (localhost [127.0.0.1]) by mail193-tx2-R.bigfish.com (Postfix) with ESMTP id 6C0B64009C; Tue, 24 Jan 2012 23:35:15 +0000 (UTC) X-SpamScore: -29 X-BigFish: VS-29(zz9371I542M1432N9a6kzz1202hzz8275ch1033IL8275dhz2fhc1bhc31hc1ah2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail193-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC107.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail193-tx2 (localhost.localdomain [127.0.0.1]) by mail193-tx2 (MessageSwitch) id 1327448114278752_29372; Tue, 24 Jan 2012 23:35:14 +0000 (UTC) Received: from TX2EHSMHS039.bigfish.com (unknown [10.9.14.238]) by mail193-tx2.bigfish.com (Postfix) with ESMTP id 345C43E0049; Tue, 24 Jan 2012 23:35:14 +0000 (UTC) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS039.bigfish.com (10.9.99.139) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 24 Jan 2012 23:35:13 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.12]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0247.005; Tue, 24 Jan 2012 15:35:08 -0800 From: Mike Jones To: Mark Nottingham , IETF Discussion Thread-Topic: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard Thread-Index: Acza8M46CiZXQaFIS8+eLGD1eeXM3Q== Date: Tue, 24 Jan 2012 23:35:07 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436637FFB2@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.33] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: OAuth WG Subject: Re: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard 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, 24 Jan 2012 23:35:16 -0000 For those on the ietf@ietf.org list, you can find my responses as editor to= Mark's useful apps area feedback at these locations: http://www.ietf.org/mail-archive/web/oauth/current/msg08040.html http://www.ietf.org/mail-archive/web/oauth/current/msg08075.html As editor, I attempted to apply all of Mark's recommendations, other than t= hose that were contrary to working group consensus positions that had alrea= dy been established via discussions on the working group mailing list. Whe= re his recommendations were not adopted, reasons were given in my responses= on behalf of the working group cited above. Best wishes, -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= ark Nottingham Sent: Tuesday, January 24, 2012 3:19 PM To: IETF Discussion Cc: OAuth WG Subject: Re: [OAUTH-WG] Last Call: (The= OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard My comments were made in: http://www.ietf.org/mail-archive/web/apps-discuss/current/msg03805.html Most of them (excepting the nits) haven't been addressed in the drafts. Regards, Begin forwarded message: > Subject: [OAUTH-WG] Last Call: (The O= Auth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard > Date: Mon, 23 Jan 2012 07:46:43 -0800 > From: The IESG > Reply-To: ietf@ietf.org > To: IETF-Announce > CC: oauth@ietf.org >=20 >=20 > The IESG has received a request from the Web Authorization Protocol WG > (oauth) to consider the following document: > - 'The OAuth 2.0 Authorization Protocol: Bearer Tokens' > as a Proposed Standard >=20 > The IESG plans to make a decision in the next few weeks, and solicits=20 > final comments on this action. Please send substantive comments to the=20 > ietf@ietf.org mailing lists by 2012-02-06. Exceptionally, comments may=20 > be sent to iesg@ietf.org instead. In either case, please retain the=20 > beginning of the Subject line to allow automated sorting. >=20 > Abstract >=20 >=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 > the associated resources (without demonstrating possession of a > cryptographic key). To prevent misuse, bearer tokens need to be > protected from disclosure in storage and in transport. >=20 >=20 >=20 >=20 > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-oauth-v2-bearer/ >=20 > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-oauth-v2-bearer/ >=20 >=20 > No IPR declarations have been submitted directly on this I-D. >=20 -- Mark Nottingham http://www.mnot.net/ _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From Michael.Jones@microsoft.com Tue Jan 24 15:43:51 2012 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 C3A3311E809D; Tue, 24 Jan 2012 15:43:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.803 X-Spam-Level: X-Spam-Status: No, score=-3.803 tagged_above=-999 required=5 tests=[AWL=-0.204, 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 xRn8S77AzaBC; Tue, 24 Jan 2012 15:43:50 -0800 (PST) Received: from AM1EHSOBE002.bigfish.com (am1ehsobe002.messaging.microsoft.com [213.199.154.205]) by ietfa.amsl.com (Postfix) with ESMTP id 3F17E11E809A; Tue, 24 Jan 2012 15:43:50 -0800 (PST) Received: from mail106-am1-R.bigfish.com (10.3.201.253) by AM1EHSOBE002.bigfish.com (10.3.204.22) with Microsoft SMTP Server id 14.1.225.23; Tue, 24 Jan 2012 23:43:49 +0000 Received: from mail106-am1 (localhost [127.0.0.1]) by mail106-am1-R.bigfish.com (Postfix) with ESMTP id 3E03C260170; Tue, 24 Jan 2012 23:43:49 +0000 (UTC) X-SpamScore: -29 X-BigFish: VS-29(zz9371I542M1432N9a6kzz1202hzz8275ch1033IL8275dhz2fhc1bhc31hc1ah2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail106-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC107.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail106-am1 (localhost.localdomain [127.0.0.1]) by mail106-am1 (MessageSwitch) id 132744862714790_3183; Tue, 24 Jan 2012 23:43:47 +0000 (UTC) Received: from AM1EHSMHS005.bigfish.com (unknown [10.3.201.254]) by mail106-am1.bigfish.com (Postfix) with ESMTP id F3533180045; Tue, 24 Jan 2012 23:43:46 +0000 (UTC) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS005.bigfish.com (10.3.207.105) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 24 Jan 2012 23:43:46 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.12]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0247.005; Tue, 24 Jan 2012 15:43:29 -0800 From: Mike Jones To: Mark Nottingham , IETF Discussion Thread-Topic: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard Thread-Index: Acza8M46CiZXQaFIS8+eLGD1eeXM3QAARP1w Date: Tue, 24 Jan 2012 23:43:29 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366380009@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.33] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: OAuth WG Subject: Re: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard 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, 24 Jan 2012 23:43:51 -0000 (Resending now that I'm a member of the ietf@ietf.org list so that my respo= nse will be sent.) -----Original Message----- From: Mike Jones=20 Sent: Tuesday, January 24, 2012 3:35 PM To: 'Mark Nottingham'; IETF Discussion Cc: OAuth WG Subject: RE: [OAUTH-WG] Last Call: (The= OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard For those on the ietf@ietf.org list, you can find my responses as editor to= Mark's useful apps area feedback at these locations: http://www.ietf.org/mail-archive/web/oauth/current/msg08040.html http://www.ietf.org/mail-archive/web/oauth/current/msg08075.html As editor, I attempted to apply all of Mark's recommendations, other than t= hose that were contrary to working group consensus positions that had alrea= dy been established via discussions on the working group mailing list. Whe= re his recommendations were not adopted, reasons were given in my responses= on behalf of the working group cited above. Best wishes, -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= ark Nottingham Sent: Tuesday, January 24, 2012 3:19 PM To: IETF Discussion Cc: OAuth WG Subject: Re: [OAUTH-WG] Last Call: (The= OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard My comments were made in: http://www.ietf.org/mail-archive/web/apps-discuss/current/msg03805.html Most of them (excepting the nits) haven't been addressed in the drafts. Regards, Begin forwarded message: > Subject: [OAUTH-WG] Last Call: (The O= Auth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard > Date: Mon, 23 Jan 2012 07:46:43 -0800 > From: The IESG > Reply-To: ietf@ietf.org > To: IETF-Announce > CC: oauth@ietf.org >=20 >=20 > The IESG has received a request from the Web Authorization Protocol WG > (oauth) to consider the following document: > - 'The OAuth 2.0 Authorization Protocol: Bearer Tokens' > as a Proposed Standard >=20 > The IESG plans to make a decision in the next few weeks, and solicits=20 > final comments on this action. Please send substantive comments to the=20 > ietf@ietf.org mailing lists by 2012-02-06. Exceptionally, comments may=20 > be sent to iesg@ietf.org instead. In either case, please retain the=20 > beginning of the Subject line to allow automated sorting. >=20 > Abstract >=20 >=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 > the associated resources (without demonstrating possession of a > cryptographic key). To prevent misuse, bearer tokens need to be > protected from disclosure in storage and in transport. >=20 >=20 >=20 >=20 > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-oauth-v2-bearer/ >=20 > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-oauth-v2-bearer/ >=20 >=20 > No IPR declarations have been submitted directly on this I-D. >=20 -- Mark Nottingham http://www.mnot.net/ _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From Michael.Jones@microsoft.com Tue Jan 24 15:45:22 2012 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 63A1F11E809D; Tue, 24 Jan 2012 15:45:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.795 X-Spam-Level: X-Spam-Status: No, score=-3.795 tagged_above=-999 required=5 tests=[AWL=-0.196, 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 xIOo9PnfX4E8; Tue, 24 Jan 2012 15:45:21 -0800 (PST) Received: from DB3EHSOBE003.bigfish.com (db3ehsobe003.messaging.microsoft.com [213.199.154.141]) by ietfa.amsl.com (Postfix) with ESMTP id 1D7F311E80C0; Tue, 24 Jan 2012 15:45:21 -0800 (PST) Received: from mail18-db3-R.bigfish.com (10.3.81.242) by DB3EHSOBE003.bigfish.com (10.3.84.23) with Microsoft SMTP Server id 14.1.225.23; Tue, 24 Jan 2012 23:45:18 +0000 Received: from mail18-db3 (localhost [127.0.0.1]) by mail18-db3-R.bigfish.com (Postfix) with ESMTP id D710A4202EE; Tue, 24 Jan 2012 23:45:18 +0000 (UTC) X-SpamScore: -38 X-BigFish: VS-38(zz9371I936eK542M1432N98dKzz1202hzz1033IL8275dhz2fhc1bhc31hc1ah2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail18-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail18-db3 (localhost.localdomain [127.0.0.1]) by mail18-db3 (MessageSwitch) id 1327448716651305_28226; Tue, 24 Jan 2012 23:45:16 +0000 (UTC) Received: from DB3EHSMHS012.bigfish.com (unknown [10.3.81.248]) by mail18-db3.bigfish.com (Postfix) with ESMTP id 900534C004A; Tue, 24 Jan 2012 23:45:16 +0000 (UTC) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS012.bigfish.com (10.3.87.112) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 24 Jan 2012 23:45:15 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.12]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.02.0247.005; Tue, 24 Jan 2012 15:45:13 -0800 From: Mike Jones To: Mike Jones , "ietf@ietf.org" , "iesg@ietf.org" Thread-Topic: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard Thread-Index: AQHM2ejbNGzL+7cc6EiU4F3vKE4/fpYaMdvwgAAYAzCAAeZz0A== Date: Tue, 24 Jan 2012 23:45:12 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366380029@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <20120123154643.16223.44509.idtracker@ietfa.amsl.com> <4F1D8391.3080009@gmx.de> <4E1F6AAD24975D4BA5B168042967394366375F80@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739436637843C@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436637843C@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.33] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard 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, 24 Jan 2012 23:45:22 -0000 (Resending now that I'm a member of the ietf@ietf.org list so that my note = will appear there.) -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= ike Jones Sent: Monday, January 23, 2012 9:24 AM To: ietf@ietf.org Cc: Julian Reschke; The IESG; oauth@ietf.org; IETF-Announce Subject: Re: [OAUTH-WG] Last Call: (The= OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard As editor of the Oauth Bearer spec, I believe that these comments have been= well understood and considered by the working group. I do understand that= the working group's consensus position is different than Julian's. See th= ese notes documenting that this is the case: https://www.ietf.org/mail-archive/web/oauth/current/msg08113.html https://www.ietf.org/mail-archive/web/oauth/current/msg08116.html https://www.ietf.org/mail-archive/web/oauth/current/msg08121.html Best wishes, -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of J= ulian Reschke Sent: Monday, January 23, 2012 7:58 AM To: ietf@ietf.org Cc: The IESG; oauth@ietf.org; IETF-Announce Subject: Re: [OAUTH-WG] Last Call: (The= OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard On 2012-01-23 16:46, The IESG wrote: > > The IESG has received a request from the Web Authorization Protocol WG > (oauth) to consider the following document: > - 'The OAuth 2.0 Authorization Protocol: Bearer Tokens' > as a Proposed Standard ... Please see my comments in which I think have not been addressed. 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 Michael.Jones@microsoft.com Tue Jan 24 16:03:18 2012 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 9D00821F85D7; Tue, 24 Jan 2012 16:03:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.788 X-Spam-Level: X-Spam-Status: No, score=-3.788 tagged_above=-999 required=5 tests=[AWL=-0.189, 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 TQWOi+AmReoS; Tue, 24 Jan 2012 16:03:17 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id C1ED121F8596; Tue, 24 Jan 2012 16:03:17 -0800 (PST) Received: from mail179-ch1-R.bigfish.com (10.43.68.251) by CH1EHSOBE008.bigfish.com (10.43.70.58) with Microsoft SMTP Server id 14.1.225.23; Wed, 25 Jan 2012 00:03:17 +0000 Received: from mail179-ch1 (localhost [127.0.0.1]) by mail179-ch1-R.bigfish.com (Postfix) with ESMTP id 2F4FC260194; Wed, 25 Jan 2012 00:03:17 +0000 (UTC) X-SpamScore: -38 X-BigFish: VS-38(zz9371I936eK542M1432N98dKzz1202hzz1033IL8275dhz2fhc1bhc31hc1ah2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-FB-SS: 13, Received-SPF: pass (mail179-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail179-ch1 (localhost.localdomain [127.0.0.1]) by mail179-ch1 (MessageSwitch) id 13274497977629_28206; Wed, 25 Jan 2012 00:03:17 +0000 (UTC) Received: from CH1EHSMHS007.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.247]) by mail179-ch1.bigfish.com (Postfix) with ESMTP id F16F7180046; Wed, 25 Jan 2012 00:03:16 +0000 (UTC) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS007.bigfish.com (10.43.70.7) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 25 Jan 2012 00:03:16 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.12]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0247.005; Tue, 24 Jan 2012 16:03:15 -0800 From: Mike Jones To: "ietf@ietf.org" Thread-Topic: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard Thread-Index: Acza9LphO1mPc9gpRTC5FQtXgyb9wg== Date: Wed, 25 Jan 2012 00:03:15 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366380094@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.33] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: The IESG , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard 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, 25 Jan 2012 00:03:18 -0000 Per the discussion at http://www.ietf.org/mail-archive/web/oauth/current/ms= g08040.html, the working group's rationale for supporting quoted-string but= not token syntax for these parameters, and for requiring that backslash ('= \') quoting not be used when producing them is as follows: "Once again, the current text reflects a consensus decision of the working = group. It was viewed that requiring support for multiple ways of doing the= same thing unnecessarily complicated implementations without any compensat= ing benefit; better to support one syntax for each semantic operation and r= equire all implementations to use it." Despite Julian's remarks below, the syntax in the Bearer spec *is* compatib= le with standard parameter parsers, and so no interoperability problems are= created by restricting the parameter syntax to a subset of the syntax allo= wed by HTTPbis. No non-standard code is needed to use parameters in the ma= nner described in the Bearer spec. The current text is the result of thorough and informed discussion among th= e working group, and reflects the best consensus available as I understand = it in my role as editor, attempting to accurately represent the working gro= up's decisions and rationale. Best wishes, -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of J= ulian Reschke Sent: Tuesday, January 24, 2012 3:24 PM To: ietf@ietf.org Cc: The IESG; oauth@ietf.org Subject: Re: [OAUTH-WG] Last Call: (The= OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard On 2012-01-23 16:58, Julian Reschke wrote: > On 2012-01-23 16:46, The IESG wrote: >> >> The IESG has received a request from the Web Authorization Protocol=20 >> WG >> (oauth) to consider the following document: >> - 'The OAuth 2.0 Authorization Protocol: Bearer Tokens' >> as a Proposed Standard ... > > Please see my comments in > > which I think have not been addressed. > ... In an off-list conversation I heard that what I said before may not be as c= lear as it could be. So... 1) draft-ietf-oauth-v2-bearer-15 defines a new HTTP authentication scheme. 2) In the IANA considerations, it references the registration procedure def= ined in (now -18, but that doesn't matter here). 3) That document recommends in : o The parsing of challenges and credentials is defined by this specification, and cannot be modified by new authentication schemes. When the auth-param syntax is used, all parameters ought to support both token and quoted-string syntax, and syntactical constraints ought to be defined on the field value after parsing (i.e., quoted-string processing). This is necessary so that recipients can use a generic parser that applies to all authentication schemes. 4) draft-ietf-oauth-v2-bearer-15 ignores this recommendation. It has been m= entioned that it might not have ignored it if it had UPPERCASE requirements= , but in HTTPbis we try to restrict BCP14 keywords to the actual protocol, = not on recommendations on other specs. 5) The registration requirement for a new scheme is "IETF review", which RF= C 5226 defines in as: IETF Review - (Formerly called "IETF Consensus" in [IANA-CONSIDERATIONS]) New values are assigned only through RFCs that have been shepherded through the IESG as AD- Sponsored or IETF WG Documents [RFC3932] [RFC3978]. The intention is that the document and proposed assignment will be reviewed by the IESG and appropriate IETF WGs (or experts, if suitable working groups no longer exist) to ensure that the proposed assignment will not negatively impact interoperability or otherwise extend IETF protocols in an inappropriate or damaging manner. In this case the WG exists (it's HTTPbis), and the OAuth got two reviews fr= om HTTPbis pointing out the problem -- from Mark Nottingham, the WG chair,= and myself, one of the authors. And yes, I believe the way OAuth defines the syntax *will* impact interoper= ability. Also, I haven't seen any explanation why OAuth can not follow the recommend= ation from HTTPbis. Hope this clarifies things, Julian _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From julian.reschke@gmx.de Tue Jan 24 16:19:28 2012 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 14EAE21F861C for ; Tue, 24 Jan 2012 16:19:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.482 X-Spam-Level: X-Spam-Status: No, score=-103.482 tagged_above=-999 required=5 tests=[AWL=-0.883, 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 q75fl9iPmgZS for ; Tue, 24 Jan 2012 16:19:27 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 9311E21F862D for ; Tue, 24 Jan 2012 16:19:26 -0800 (PST) Received: (qmail invoked by alias); 25 Jan 2012 00:19:25 -0000 Received: from p5DCC2B6A.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.43.106] by mail.gmx.net (mp027) with SMTP; 25 Jan 2012 01:19:25 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+8EXdxkGm8eWzdgG72aTFQQKnIszhaoyp6NWIqJE O/qELnxkCapN9G Message-ID: <4F1F4A7B.9090408@gmx.de> Date: Wed, 25 Jan 2012 01:19:07 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Mike Jones References: <4E1F6AAD24975D4BA5B168042967394366380094@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366380094@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" , "ietf@ietf.org" , The IESG Subject: Re: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard 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, 25 Jan 2012 00:19:28 -0000 On 2012-01-25 01:03, Mike Jones wrote: > Per the discussion at http://www.ietf.org/mail-archive/web/oauth/current/msg08040.html, the working group's rationale for supporting quoted-string but not token syntax for these parameters, and for requiring that backslash ('\') quoting not be used when producing them is as follows: > > "Once again, the current text reflects a consensus decision of the working group. It was viewed that requiring support for multiple ways of doing the same thing unnecessarily complicated implementations without any compensating benefit; better to support one syntax for each semantic operation and require all implementations to use it." Mike, you continue to ignore that WWW-Authenticate needs to be processed by generic parsers, as a single instance can contain challenges for different schemes. If you disagree with the text below: o The parsing of challenges and credentials is defined by this specification, and cannot be modified by new authentication schemes. When the auth-param syntax is used, all parameters ought to support both token and quoted-string syntax, and syntactical constraints ought to be defined on the field value after parsing (i.e., quoted-string processing). This is necessary so that recipients can use a generic parser that applies to all authentication schemes. (which is from the text defining the registry you are using), then please come over to the HTTPbis WG and ask for a change. It's work-in-progress. > Despite Julian's remarks below, the syntax in the Bearer spec *is* compatible with standard parameter parsers, and so no interoperability problems are created by restricting the parameter syntax to a subset of the syntax allowed by HTTPbis. No non-standard code is needed to use parameters in the manner described in the Bearer spec. That is not true. Using standard components will cause recipients to accept invalid field instances, which *is* an interoperability problem. This has happened before: RFC 2617 states that the realm parameter needs to be quoted, but we see that all browsers accept the token form as well (). That's not a surprise because it's the natural thing to do with a generic parser. Please don't add to the mess. In particular when there really is no reason to do so. All I heard from you is: "we prefer it that way". I'm sorry, but that's not sufficient. > ... Best regards, Julian From Michael.Jones@microsoft.com Tue Jan 24 16:52:30 2012 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 D2F3121F847B; Tue, 24 Jan 2012 16:52:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.781 X-Spam-Level: X-Spam-Status: No, score=-3.781 tagged_above=-999 required=5 tests=[AWL=-0.182, 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 TVV73AkIrWQ3; Tue, 24 Jan 2012 16:52:30 -0800 (PST) Received: from DB3EHSOBE005.bigfish.com (db3ehsobe005.messaging.microsoft.com [213.199.154.143]) by ietfa.amsl.com (Postfix) with ESMTP id 9794521F8478; Tue, 24 Jan 2012 16:52:29 -0800 (PST) Received: from mail72-db3-R.bigfish.com (10.3.81.242) by DB3EHSOBE005.bigfish.com (10.3.84.25) with Microsoft SMTP Server id 14.1.225.23; Wed, 25 Jan 2012 00:52:28 +0000 Received: from mail72-db3 (localhost [127.0.0.1]) by mail72-db3-R.bigfish.com (Postfix) with ESMTP id 78C4922024D; Wed, 25 Jan 2012 00:52:28 +0000 (UTC) X-SpamScore: -40 X-BigFish: VS-40(zz9371I148cM542M1432N98dKzz1202hzz1033IL8275dhz2fhc1bhc31hc1ah2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail72-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail72-db3 (localhost.localdomain [127.0.0.1]) by mail72-db3 (MessageSwitch) id 1327452746637940_8243; Wed, 25 Jan 2012 00:52:26 +0000 (UTC) Received: from DB3EHSMHS012.bigfish.com (unknown [10.3.81.243]) by mail72-db3.bigfish.com (Postfix) with ESMTP id 8E1DF420048; Wed, 25 Jan 2012 00:52:26 +0000 (UTC) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS012.bigfish.com (10.3.87.112) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 25 Jan 2012 00:52:26 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.12]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0247.005; Tue, 24 Jan 2012 16:52:25 -0800 From: Mike Jones To: "mrex@sap.com" Thread-Topic: [OAUTH-WG] Last Call: (The Thread-Index: AQHM2vhYmAz+4G7gQ0GW7eeS0JEwvZYcPXxg Date: Wed, 25 Jan 2012 00:52:24 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943663801ED@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B168042967394366380094@TK5EX14MBXC284.redmond.corp.microsoft.com> from "Mike Jones" at Jan 25, 12 00:03:15 am <201201250028.q0P0SwiS000165@fs4113.wdf.sap.corp> In-Reply-To: <201201250028.q0P0SwiS000165@fs4113.wdf.sap.corp> 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 X-OriginatorOrg: microsoft.com Cc: "oauth@ietf.org" , "ietf@ietf.org" , "iesg@ietf.org" Subject: Re: [OAUTH-WG] Last Call: (The 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, 25 Jan 2012 00:52:31 -0000 Thanks for asking, Martin. That's effectively what the spec does already. = It restricts the input values of these parameters to be quoted strings con= taining no backslashes. As long as that syntax restriction remains in place, it wouldn't actually m= atter whether the BNF for "scope", "error", "error_description", and "error= _uri" continues to be defined as "quoted-string", is defined as "token / qu= oted-string", per HTTPbis, or defined by referencing the HTTPbis "auth-para= m" definition and containing no parameter-specific BNF declarations. The m= eaning of the spec would remain the same. It's written the way it is, at present, because it would seem to be clearer= to implementers what the restrictions are by using the "quoted-string" BNF= production, rather than by imposing the restriction only in prose. But if= deleting the BNF definitions and leaving the syntax restrictions in the pr= ose would resolve this issue for people, I'm pretty sure the working group = would be fine with that, as it would be a non-normative change. Best wishes, -- Mike -----Original Message----- From: Martin Rex [mailto:mrex@sap.com]=20 Sent: Tuesday, January 24, 2012 4:29 PM To: Mike Jones Cc: ietf@ietf.org; iesg@ietf.org; oauth@ietf.org Subject: Re: [OAUTH-WG] Last Call: (The Mike Jones wrote: >=20 > Per the discussion at > http://www.ietf.org/mail-archive/web/oauth/current/msg08040.html, > the working group's rationale for supporting quoted-string but not=20 > token syntax for these parameters, and for requiring that backslash=20 > ('\') quoting not be used when producing them [...] I'm slightly confused... Instead of inappropriately re-specifying the WWW-Authenticate:, how about r= eferencing the original specification an rules, and then add your desired r= equirements for *creation* of the contents on top of that, so that oauth-be= arer can permit recipients to reject stuff that doesn't fit the additional = "send-requirements" when processing the request. I would assume that pretty much all authentication schemes will effectively= require subsetting of what can be conveyed to what they can parse, and fur= ther subset this to what they can successfully verify, and reject everythin= g else -- without having to rewrite the WWW-Authenticate syntax. -Martin From Michael.Jones@microsoft.com Tue Jan 24 17:03:52 2012 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 077C221F8603; Tue, 24 Jan 2012 17:03:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.775 X-Spam-Level: X-Spam-Status: No, score=-3.775 tagged_above=-999 required=5 tests=[AWL=-0.176, 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 y4pzhbQXw20Y; Tue, 24 Jan 2012 17:03:45 -0800 (PST) Received: from DB3EHSOBE002.bigfish.com (db3ehsobe002.messaging.microsoft.com [213.199.154.140]) by ietfa.amsl.com (Postfix) with ESMTP id 49B5F21F85EF; Tue, 24 Jan 2012 17:03:38 -0800 (PST) Received: from mail64-db3-R.bigfish.com (10.3.81.246) by DB3EHSOBE002.bigfish.com (10.3.84.22) with Microsoft SMTP Server id 14.1.225.23; Wed, 25 Jan 2012 01:03:37 +0000 Received: from mail64-db3 (localhost [127.0.0.1]) by mail64-db3-R.bigfish.com (Postfix) with ESMTP id 19587202D6; Wed, 25 Jan 2012 01:03:37 +0000 (UTC) X-SpamScore: -38 X-BigFish: VS-38(zz9371I936eK542M1432N98dKzz1202hzz1033IL8275dhz2fhc1bhc31hc1ah2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail64-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC105.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail64-db3 (localhost.localdomain [127.0.0.1]) by mail64-db3 (MessageSwitch) id 1327453415813637_4689; Wed, 25 Jan 2012 01:03:35 +0000 (UTC) Received: from DB3EHSMHS019.bigfish.com (unknown [10.3.81.253]) by mail64-db3.bigfish.com (Postfix) with ESMTP id C29874C0046; Wed, 25 Jan 2012 01:03:35 +0000 (UTC) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS019.bigfish.com (10.3.87.119) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 25 Jan 2012 01:03:35 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.12]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.02.0247.005; Tue, 24 Jan 2012 17:03:33 -0800 From: Mike Jones To: Julian Reschke Thread-Topic: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard Thread-Index: Acza9LphO1mPc9gpRTC5FQtXgyb9wgARUdSAABClghA= Date: Wed, 25 Jan 2012 01:03:32 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436638022F@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B168042967394366380094@TK5EX14MBXC284.redmond.corp.microsoft.com> <4F1F4A7B.9090408@gmx.de> In-Reply-To: <4F1F4A7B.9090408@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 X-OriginatorOrg: microsoft.com Cc: "oauth@ietf.org" , "ietf@ietf.org" , The IESG Subject: Re: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard 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, 25 Jan 2012 01:03:52 -0000 Typically "interoperability" is only meaningfully defined over legal inputs= to a protocol. There is no expectation of interoperability when values ou= tside those specified as being legal by a protocol are used. The case you cite below of implementations that "accept invalid field insta= nces" is then, almost by definition, not an interoperability problem, as wh= at you're concerned about is the behavior of implementations when sent ille= gal inputs - not the behavior of implementations when producing and consumi= ng legal protocol values. I believe that that's the key distinction that is causing you to look at th= is issue differently than much of the working group. Cheers, -- Mike -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de]=20 Sent: Tuesday, January 24, 2012 4:19 PM To: Mike Jones Cc: ietf@ietf.org; The IESG; oauth@ietf.org Subject: Re: [OAUTH-WG] Last Call: (The= OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard On 2012-01-25 01:03, Mike Jones wrote: > Per the discussion at http://www.ietf.org/mail-archive/web/oauth/current/= msg08040.html, the working group's rationale for supporting quoted-string b= ut not token syntax for these parameters, and for requiring that backslash = ('\') quoting not be used when producing them is as follows: > > "Once again, the current text reflects a consensus decision of the workin= g group. It was viewed that requiring support for multiple ways of doing t= he same thing unnecessarily complicated implementations without any compens= ating benefit; better to support one syntax for each semantic operation and= require all implementations to use it." Mike, you continue to ignore that WWW-Authenticate needs to be processed by= generic parsers, as a single instance can contain challenges for different= schemes. If you disagree with the text below: o The parsing of challenges and credentials is defined by this specification, and cannot be modified by new authentication schemes. When the auth-param syntax is used, all parameters ought to support both token and quoted-string syntax, and syntactical constraints ought to be defined on the field value after parsing (i.e., quoted-string processing). This is necessary so that recipients can use a generic parser that applies to all authentication schemes. (which is from the text defining the registry you are using), then please c= ome over to the HTTPbis WG and ask for a change. It's work-in-progress. > Despite Julian's remarks below, the syntax in the Bearer spec *is* compat= ible with standard parameter parsers, and so no interoperability problems a= re created by restricting the parameter syntax to a subset of the syntax al= lowed by HTTPbis. No non-standard code is needed to use parameters in the = manner described in the Bearer spec. That is not true. Using standard components will cause recipients to accept= invalid field instances, which *is* an interoperability problem. This has happened before: RFC 2617 states that the realm parameter needs to= be quoted, but we see that all browsers accept the token form as well (). That's not a surpris= e because it's the natural thing to do with a generic parser. Please don't add to the mess. In particular when there really is no reason = to do so. All I heard from you is: "we prefer it that way". I'm sorry, but = that's not sufficient. > ... Best regards, Julian From andredemarre@gmail.com Tue Jan 24 18:10:52 2012 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 DF23B21F84AF for ; Tue, 24 Jan 2012 18:10:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.369 X-Spam-Level: X-Spam-Status: No, score=-2.369 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, 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 BC0rGlU7EyEK for ; Tue, 24 Jan 2012 18:10:52 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 671FF21F84AA for ; Tue, 24 Jan 2012 18:10:52 -0800 (PST) Received: by iagf6 with SMTP id f6so6778100iag.31 for ; Tue, 24 Jan 2012 18:10:52 -0800 (PST) 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=yMcSuNxWjHLk2YDDyZLrQ54YwqSVL6NkxtJDgC9Ujh8=; b=HTQ7YG5LPf4j0zviPOTRiN5le9deYGku4Qb7mxanGP9XJ6IUmSoKIV+e/ua0qzS08e Y6lP+KyhFRQ2QFlKi85OihWYTGwKpq/vnkCFhKA88YBOKO83pyd62+CVCr5tB8EqbUan cTn+Sa1VfY91VgjMjTANyM85ilenn95wen27g= MIME-Version: 1.0 Received: by 10.50.195.129 with SMTP id ie1mr16759607igc.29.1327457452101; Tue, 24 Jan 2012 18:10:52 -0800 (PST) Received: by 10.42.224.67 with HTTP; Tue, 24 Jan 2012 18:10:52 -0800 (PST) Date: Tue, 24 Jan 2012 18:10:52 -0800 Message-ID: From: =?ISO-8859-1?Q?Andr=E9_DeMarre?= To: OAuth WG Content-Type: text/plain; charset=ISO-8859-1 Subject: [OAUTH-WG] Missing characters in draft-ietf-oauth-v2-23 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, 25 Jan 2012 02:10:53 -0000 Revision 23 of draft-ietf-oauth seems to be the victim of some form of sloppy character conversion; perhaps a conversion to ASCII without character transliteration. Some apostrophes have been removed and some names were changed in the acknowledgments. Here are the errors I could find while comparing revs 22 and 23: Section 1 "the end-user's password" became "the end-user s password" Section 12 "Bill de hOra" became "Bill de h ra" "Andre DeMarre" became "Andr DeMarre" "Christian Stuebner" became "Christian St bner" Appendix A "one of OAuth's most" became "one of OAuth s most" Regards, Andre DeMarre From eran@hueniverse.com Tue Jan 24 22:24:04 2012 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 4101C21F8675 for ; Tue, 24 Jan 2012 22:24:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=0.135, 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 aLuChVazB67z for ; Tue, 24 Jan 2012 22:24:03 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 92CAF21F84C5 for ; Tue, 24 Jan 2012 22:24:03 -0800 (PST) Received: (qmail 17705 invoked from network); 25 Jan 2012 06:24:02 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 25 Jan 2012 06:23:57 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Tue, 24 Jan 2012 23:23:57 -0700 From: Eran Hammer To: Julian Reschke , "ietf@ietf.org" Date: Tue, 24 Jan 2012 23:23:51 -0700 Thread-Topic: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard Thread-Index: Acza70cEhZRkpgsWT3eanhkQYYblkgAOmHSA Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453AAB9682E@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <20120123154643.16223.44509.idtracker@ietfa.amsl.com> <4F1D8391.3080009@gmx.de> <4F1F3D84.1030300@gmx.de> In-Reply-To: <4F1F3D84.1030300@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: The IESG , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard 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, 25 Jan 2012 06:24:04 -0000 I fully agree with Julian's perspective. I believe there is sufficient feed= back requiring further review of this issue. If the editor cannot facilitat= e a path forward, I request the chairs to intervene.=20 I will make sure this feedback is fully applied to the MAC token specificat= ion in the next draft. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Julian Reschke > Sent: Tuesday, January 24, 2012 3:24 PM > To: ietf@ietf.org > Cc: The IESG; oauth@ietf.org > Subject: Re: [OAUTH-WG] Last Call: (T= he > OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard >=20 > On 2012-01-23 16:58, Julian Reschke wrote: > > On 2012-01-23 16:46, The IESG wrote: > >> > >> The IESG has received a request from the Web Authorization Protocol > >> WG > >> (oauth) to consider the following document: > >> - 'The OAuth 2.0 Authorization Protocol: Bearer Tokens' > >> as a Proposed Standard ... > > > > Please see my comments in > > > > which I think have not been addressed. > > ... >=20 > In an off-list conversation I heard that what I said before may not be as= clear > as it could be. >=20 > So... >=20 > 1) draft-ietf-oauth-v2-bearer-15 defines a new HTTP authentication scheme= . >=20 > 2) In the IANA considerations, it references the registration procedure > defined in 2.3> > (now -18, but that doesn't matter here). >=20 > 3) That document recommends in > : >=20 > o The parsing of challenges and credentials is defined by this > specification, and cannot be modified by new authentication > schemes. When the auth-param syntax is used, all parameters ought > to support both token and quoted-string syntax, and syntactical > constraints ought to be defined on the field value after parsing > (i.e., quoted-string processing). This is necessary so that > recipients can use a generic parser that applies to all > authentication schemes. >=20 > 4) draft-ietf-oauth-v2-bearer-15 ignores this recommendation. It has been > mentioned that it might not have ignored it if it had UPPERCASE > requirements, but in HTTPbis we try to restrict BCP14 keywords to the act= ual > protocol, not on recommendations on other specs. >=20 > 5) The registration requirement for a new scheme is "IETF review", which = RFC > 5226 defines in as: >=20 > IETF Review - (Formerly called "IETF Consensus" in > [IANA-CONSIDERATIONS]) New values are assigned only through > RFCs that have been shepherded through the IESG as AD- > Sponsored or IETF WG Documents [RFC3932] [RFC3978]. The > intention is that the document and proposed assignment will > be reviewed by the IESG and appropriate IETF WGs (or > experts, if suitable working groups no longer exist) to > ensure that the proposed assignment will not negatively > impact interoperability or otherwise extend IETF protocols > in an inappropriate or damaging manner. >=20 > In this case the WG exists (it's HTTPbis), and the OAuth got two reviews = from > HTTPbis pointing out the problem -- from Mark Nottingham, the WG chair, > and myself, one of the authors. >=20 > And yes, I believe the way OAuth defines the syntax *will* impact > interoperability. >=20 > Also, I haven't seen any explanation why OAuth can not follow the > recommendation from HTTPbis. >=20 > Hope this clarifies things, >=20 > Julian > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From julian.reschke@gmx.de Wed Jan 25 00:37:22 2012 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 1606721F84A6 for ; Wed, 25 Jan 2012 00:37:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.436 X-Spam-Level: X-Spam-Status: No, score=-103.436 tagged_above=-999 required=5 tests=[AWL=-0.837, 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 baA0LvCc1vYu for ; Wed, 25 Jan 2012 00:37:21 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 66AD421F849C for ; Wed, 25 Jan 2012 00:37:21 -0800 (PST) Received: (qmail invoked by alias); 25 Jan 2012 08:37:16 -0000 Received: from p5DCC2B6A.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.43.106] by mail.gmx.net (mp028) with SMTP; 25 Jan 2012 09:37:16 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18yjQMTS20ySdb7+WU0dmS7DOM+2ETFbnxufYgUGt 1zHSufEtVqf1Y5 Message-ID: <4F1FBF3A.4090808@gmx.de> Date: Wed, 25 Jan 2012 09:37:14 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Bjoern Hoehrmann References: <4E1F6AAD24975D4BA5B168042967394366380094@TK5EX14MBXC284.redmond.corp.microsoft.com> from "Mike Jones" at Jan 25, 12 00:03:15 am <201201250028.q0P0SwiS000165@fs4113.wdf.sap.corp> <4E1F6AAD24975D4BA5B1680429673943663801ED@TK5EX14MBXC284.redmond.corp.microsoft.com> <2rkuh71k7eh4h1ciu15p6b2sss77u6qhtp@hive.bjoern.hoehrmann.de> In-Reply-To: <2rkuh71k7eh4h1ciu15p6b2sss77u6qhtp@hive.bjoern.hoehrmann.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org" , "ietf@ietf.org" Subject: Re: [OAUTH-WG] Last Call: (The 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, 25 Jan 2012 08:37:22 -0000 On 2012-01-25 03:14, Bjoern Hoehrmann wrote: > ... +1 > ... > If you want to keep the distinction, you should offer an argument why > this is something individual schemes should regulate (since having the > same rules for all schemes is much simpler). > ... Exactly. I've been asking this many times, but I'm not getting any answers except "we prefer it this way". Best regards, Julian From Michael.Jones@microsoft.com Wed Jan 25 00:37:34 2012 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 41F8721F84A3; Wed, 25 Jan 2012 00:37:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.769 X-Spam-Level: X-Spam-Status: No, score=-3.769 tagged_above=-999 required=5 tests=[AWL=-0.170, 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 h-LXWB8hHbzT; Wed, 25 Jan 2012 00:37:33 -0800 (PST) Received: from DB3EHSOBE002.bigfish.com (db3ehsobe002.messaging.microsoft.com [213.199.154.140]) by ietfa.amsl.com (Postfix) with ESMTP id 09EE521F84B8; Wed, 25 Jan 2012 00:37:30 -0800 (PST) Received: from mail55-db3-R.bigfish.com (10.3.81.250) by DB3EHSOBE002.bigfish.com (10.3.84.22) with Microsoft SMTP Server id 14.1.225.23; Wed, 25 Jan 2012 08:37:29 +0000 Received: from mail55-db3 (localhost [127.0.0.1]) by mail55-db3-R.bigfish.com (Postfix) with ESMTP id D340D4035C; Wed, 25 Jan 2012 08:37:29 +0000 (UTC) X-SpamScore: -38 X-BigFish: VS-38(zz9371I936eK542M1432N98dKzz1202hzz1033IL8275dhz2fhc1bhc31hc1ah2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail55-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC107.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail55-db3 (localhost.localdomain [127.0.0.1]) by mail55-db3 (MessageSwitch) id 1327480647607054_23266; Wed, 25 Jan 2012 08:37:27 +0000 (UTC) Received: from DB3EHSMHS002.bigfish.com (unknown [10.3.81.253]) by mail55-db3.bigfish.com (Postfix) with ESMTP id 8F3D84E0045; Wed, 25 Jan 2012 08:37:27 +0000 (UTC) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS002.bigfish.com (10.3.87.102) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 25 Jan 2012 08:37:25 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.12]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0247.005; Wed, 25 Jan 2012 00:37:23 -0800 From: Mike Jones To: Eran Hammer , Julian Reschke , "ietf@ietf.org" Thread-Topic: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard Thread-Index: AczbPI44ucw8FyvfTTSWdvUFZixqdQ== Date: Wed, 25 Jan 2012 08:37:22 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436638188B@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: The IESG , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard 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, 25 Jan 2012 08:37:34 -0000 Eran, do I then correctly understand that you've changed your mind on the p= osition you took in http://www.ietf.org/mail-archive/web/oauth/current/msg0= 7698.html, which was: "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 ask this, because = if I correctly understand your statement that you agree with Julian, you ar= e now taking the position that you are OK with recipients being required to= perform escape processing for the scope (and other) parameters and with th= em being required to accept them either as tokens or as quoted strings. This raises a question I'd like to ask John Bradley, William Mills, Phil Hu= nt, and Justin Richter: Since all of you replied with a +1 to Eran's origi= nal statement, are you still in agreement with it, or are you now possibly = reconsidering your position, as Eran apparently has. I'm asking, because y= our messages have been part of the basis upon which I've been taking the po= sition as editor that the working group consensus is that no quoting may oc= cur. (The other reason that I believed, as editor, that this was a consens= us position is that this syntax restriction has been present in every Beare= r draft, as it was in OAuth 2.0 draft 10, which was the basis of the first = Bearer draft.) If that's not the actual working group consensus (or it's n= ot anymore), it would be good to know that now. Finally, I'd like to respond publicly to a comment made to me in a private = note sent to me about the current discussions. In it, the sender (an IETF = "old hand") observed that it could appear from the strength of my responses= to Julian's feedback that I might be trying to defend a particular persona= l view of how these issues should be resolved. I responded to him that the= irony here is that I'm not trying to representing a personal position. Ra= ther, I'm truly trying to do what I believe an IETF editor is supposed to d= o, which is to represent the working group's positions. I'm quite open to the working group making it clear that its position has c= hanged with respect to Julian's comments and equally open to the working gr= oup standing behind the text in the current draft. If the chairs would lik= e to help bring this issue to successful closure, I would highly welcome th= eir participation as well. Personally, I'd mostly just like to see the spec finished! -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer Sent: Tuesday, January 24, 2012 10:24 PM To: Julian Reschke; ietf@ietf.org Cc: The IESG; oauth@ietf.org Subject: Re: [OAUTH-WG] Last Call: (The= OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard I fully agree with Julian's perspective. I believe there is sufficient feed= back requiring further review of this issue. If the editor cannot facilitat= e a path forward, I request the chairs to intervene.=20 I will make sure this feedback is fully applied to the MAC token specificat= ion in the next draft. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf=20 > Of Julian Reschke > Sent: Tuesday, January 24, 2012 3:24 PM > To: ietf@ietf.org > Cc: The IESG; oauth@ietf.org > Subject: Re: [OAUTH-WG] Last Call: =20 > (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed=20 > Standard >=20 > On 2012-01-23 16:58, Julian Reschke wrote: > > On 2012-01-23 16:46, The IESG wrote: > >> > >> The IESG has received a request from the Web Authorization Protocol=20 > >> WG > >> (oauth) to consider the following document: > >> - 'The OAuth 2.0 Authorization Protocol: Bearer Tokens' > >> as a Proposed Standard ... > > > > Please see my comments in > > > > which I think have not been addressed. > > ... >=20 > In an off-list conversation I heard that what I said before may not be=20 > as clear as it could be. >=20 > So... >=20 > 1) draft-ietf-oauth-v2-bearer-15 defines a new HTTP authentication scheme= . >=20 > 2) In the IANA considerations, it references the registration=20 > procedure defined in=20 > 2.3> > (now -18, but that doesn't matter here). >=20 > 3) That document recommends in > : >=20 > o The parsing of challenges and credentials is defined by this > specification, and cannot be modified by new authentication > schemes. When the auth-param syntax is used, all parameters ought > to support both token and quoted-string syntax, and syntactical > constraints ought to be defined on the field value after parsing > (i.e., quoted-string processing). This is necessary so that > recipients can use a generic parser that applies to all > authentication schemes. >=20 > 4) draft-ietf-oauth-v2-bearer-15 ignores this recommendation. It has=20 > been mentioned that it might not have ignored it if it had UPPERCASE=20 > requirements, but in HTTPbis we try to restrict BCP14 keywords to the=20 > actual protocol, not on recommendations on other specs. >=20 > 5) The registration requirement for a new scheme is "IETF review",=20 > which RFC > 5226 defines in as: >=20 > IETF Review - (Formerly called "IETF Consensus" in > [IANA-CONSIDERATIONS]) New values are assigned only through > RFCs that have been shepherded through the IESG as AD- > Sponsored or IETF WG Documents [RFC3932] [RFC3978]. The > intention is that the document and proposed assignment will > be reviewed by the IESG and appropriate IETF WGs (or > experts, if suitable working groups no longer exist) to > ensure that the proposed assignment will not negatively > impact interoperability or otherwise extend IETF protocols > in an inappropriate or damaging manner. >=20 > In this case the WG exists (it's HTTPbis), and the OAuth got two=20 > reviews from HTTPbis pointing out the problem -- from Mark=20 > Nottingham, the WG chair, and myself, one of the authors. >=20 > And yes, I believe the way OAuth defines the syntax *will* impact=20 > interoperability. >=20 > Also, I haven't seen any explanation why OAuth can not follow the=20 > recommendation from HTTPbis. >=20 > Hope this clarifies things, >=20 > 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 mrex@sap.com Tue Jan 24 16:29:00 2012 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 D5D9321F8541; Tue, 24 Jan 2012 16:29:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.142 X-Spam-Level: X-Spam-Status: No, score=-10.142 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 B-3N9UoA9xT9; Tue, 24 Jan 2012 16:29:00 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 24CAD21F8540; Tue, 24 Jan 2012 16:28:59 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q0P0Swgv023555 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 25 Jan 2012 01:28:58 +0100 (MET) From: Martin Rex Message-Id: <201201250028.q0P0SwiS000165@fs4113.wdf.sap.corp> To: Michael.Jones@microsoft.com (Mike Jones) Date: Wed, 25 Jan 2012 01:28:58 +0100 (MET) In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366380094@TK5EX14MBXC284.redmond.corp.microsoft.com> from "Mike Jones" at Jan 25, 12 00:03:15 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-Mailman-Approved-At: Wed, 25 Jan 2012 05:27:14 -0800 Cc: oauth@ietf.org, ietf@ietf.org, iesg@ietf.org Subject: Re: [OAUTH-WG] Last Call: (The X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 00:29:01 -0000 Mike Jones wrote: > > Per the discussion at > http://www.ietf.org/mail-archive/web/oauth/current/msg08040.html, > the working group's rationale for supporting quoted-string but > not token syntax for these parameters, and for requiring that > backslash ('\') quoting not be used when producing them [...] I'm slightly confused... Instead of inappropriately re-specifying the WWW-Authenticate:, how about referencing the original specification an rules, and then add your desired requirements for *creation* of the contents on top of that, so that oauth-bearer can permit recipients to reject stuff that doesn't fit the additional "send-requirements" when processing the request. I would assume that pretty much all authentication schemes will effectively require subsetting of what can be conveyed to what they can parse, and further subset this to what they can successfully verify, and reject everything else -- without having to rewrite the WWW-Authenticate syntax. -Martin From derhoermi@gmx.net Tue Jan 24 18:14:12 2012 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 D4C4211E80A2 for ; Tue, 24 Jan 2012 18:14:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[AWL=-2.300, BAYES_00=-2.599, J_CHICKENPOX_73=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 ZZxx3wZwh2OJ for ; Tue, 24 Jan 2012 18:14:12 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 98CBA11E809D for ; Tue, 24 Jan 2012 18:14:11 -0800 (PST) Received: (qmail invoked by alias); 25 Jan 2012 02:14:09 -0000 Received: from dslb-094-222-155-127.pools.arcor-ip.net (EHLO HIVE) [94.222.155.127] by mail.gmx.net (mp070) with SMTP; 25 Jan 2012 03:14:09 +0100 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1/iEsl6xNzirjiOEnuZRUC/6pe5bk7xZFHs3rJfku Gf5xMnIGkgmVu8 From: Bjoern Hoehrmann To: Mike Jones Date: Wed, 25 Jan 2012 03:14:26 +0100 Message-ID: <2rkuh71k7eh4h1ciu15p6b2sss77u6qhtp@hive.bjoern.hoehrmann.de> References: <4E1F6AAD24975D4BA5B168042967394366380094@TK5EX14MBXC284.redmond.corp.microsoft.com> from "Mike Jones" at Jan 25, 12 00:03:15 am <201201250028.q0P0SwiS000165@fs4113.wdf.sap.corp> <4E1F6AAD24975D4BA5B1680429673943663801ED@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943663801ED@TK5EX14MBXC284.redmond.corp.microsoft.com> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Mailman-Approved-At: Wed, 25 Jan 2012 05:27:14 -0800 Cc: "mrex@sap.com" , "oauth@ietf.org" , "ietf@ietf.org" Subject: Re: [OAUTH-WG] Last Call: (The 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, 25 Jan 2012 02:14:13 -0000 * Mike Jones wrote: >Thanks for asking, Martin. That's effectively what the spec does >already. It restricts the input values of these parameters to be quoted >strings containing no backslashes. Most XML parsers do not tell you, and most XML generators do not allow you to control, the difference between and . You could make a specification that says the value of the y attribute on the x element must not be z, but it stops there. The difference be- tween the two XML elements is in the lexical space, not in the value space, the attribute value in both cases is "z", it's just encoded in a different form. Try writing a C function `int example(int i)` that returns `1` when it is called like `example(00)` but returns `0` for `example(0)`. Without some hack you can't do that because the C specification defines that it does not matter whether you write `0` or `00` for an int. Same problem, just as the C specification does not give you an interface to tell the two inputs apart, the HTTP specification does not give you an interface that allows you to tell `x` and `"x"` apart in this particular case. If the draft said "When using WWW-Authenticate: Bearer ... then the header name must be written `wWw-authenTICate`, same problem. HTTP says case does not matter, and if another specification says "Yes, it does" then it is overriding the underlying specification, to some degree anyway. This is not always wrong, you might have coding guidelines for example that tell you to write `example( 0 )` instead of `example(0)` and that may work well with limited scope, but with coding guidelines people are typically aware that they impose limits on formally equivalent things, along with the understanding that if someone ignored the restriction the code would work just as well, but that does not seem to be quite the case here. If I make another scheme, WWW-Authenticate: Example, and say all the parameters must be tokens, not quoted strings, and the tokens must not contain "q" characters, but they are case-insensitive so you can use "Q" to the same effect, would that be just as well? If you want to keep the distinction, you should offer an argument why this is something individual schemes should regulate (since having the same rules for all schemes is much simpler). -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From mrex@sap.com Tue Jan 24 19:48:57 2012 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 2C76C21F8444; Tue, 24 Jan 2012 19:48:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.144 X-Spam-Level: X-Spam-Status: No, score=-10.144 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 WEHkD5qixb4c; Tue, 24 Jan 2012 19:48:56 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 651A021F8319; Tue, 24 Jan 2012 19:48:56 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q0P3mnCp016880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 25 Jan 2012 04:48:54 +0100 (MET) From: Martin Rex Message-Id: <201201250348.q0P3mmLt011370@fs4113.wdf.sap.corp> To: derhoermi@gmx.net (Bjoern Hoehrmann) Date: Wed, 25 Jan 2012 04:48:48 +0100 (MET) In-Reply-To: <2rkuh71k7eh4h1ciu15p6b2sss77u6qhtp@hive.bjoern.hoehrmann.de> from "Bjoern Hoehrmann" at Jan 25, 12 03:14:26 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-Mailman-Approved-At: Wed, 25 Jan 2012 05:27:14 -0800 Cc: mrex@sap.com, oauth@ietf.org, ietf@ietf.org Subject: Re: [OAUTH-WG] Last Call: (The X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 03:48:57 -0000 Bjoern Hoehrmann wrote: > > * Mike Jones wrote: > >Thanks for asking, Martin. That's effectively what the spec does > >already. It restricts the input values of these parameters to be quoted > > the HTTP specification does not give you an interface > that allows you to tell `x` and `"x"` apart in this particular case. If > the draft said "When using WWW-Authenticate: Bearer ... then the header > name must be written `wWw-authenTICate`, same problem. HTTP says case > does not matter, and if another specification says "Yes, it does" then > it is overriding the underlying specification, to some degree anyway. Of course, what oaep-bearer could _not_ "define to not exist" (no matter how much anyone (group) might desire this), is those transformations, and their complexity, that are permitted on HTTP that headerfield, e.g. through "middle-boxes", such as client-side HTTP proxies or server-side reverse-proxies between the original creator and the final consumer, as well as permitted side-effects of other application components sharing the same client (like a browser). -Martin From jricher@mitre.org Wed Jan 25 07:07:31 2012 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 B635221F857F for ; Wed, 25 Jan 2012 07:07:31 -0800 (PST) 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.000, 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 y0c+9CuPDdfN for ; Wed, 25 Jan 2012 07:07:30 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id AAAD721F8531 for ; Wed, 25 Jan 2012 07:07:30 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id EFA8021B09AF for ; Wed, 25 Jan 2012 10:07:27 -0500 (EST) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id B7C6921B182D for ; Wed, 25 Jan 2012 10:07:27 -0500 (EST) Received: from [129.83.50.12] (129.83.31.51) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.1.339.1; Wed, 25 Jan 2012 10:07:27 -0500 Message-ID: <4F201A6F.8010604@mitre.org> Date: Wed, 25 Jan 2012 10:06:23 -0500 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: References: <4E1F6AAD24975D4BA5B16804296739436638188B@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436638188B@TK5EX14MBXC284.redmond.corp.microsoft.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [129.83.31.51] Subject: Re: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard 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, 25 Jan 2012 15:07:31 -0000 My agreement was, and is, to the *production* rules and not the *parsing* rules. So long as the former is a proper subset of the latter, everything is fine. What's happening here is that the spec is being read -- by experts -- as if it were superceding the latter, and that's not a good thing. So as that's the case, I think the solution of using an existing grammar by reference but further restricting input to that in the surrounding text makes sense to me. -- Justin On 01/25/2012 03:37 AM, Mike Jones wrote: > Eran, do I then correctly understand that you've changed your mind on the position you took in http://www.ietf.org/mail-archive/web/oauth/current/msg07698.html, which was: "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 ask this, because if I correctly understand your statement that you agree with Julian, you are now taking the position that you are OK with recipients being required to perform escape processing for the scope (and other) parameters and with them being required to accept them either as tokens or as quoted strings. > > This raises a question I'd like to ask John Bradley, William Mills, Phil Hunt, and Justin Richter: Since all of you replied with a +1 to Eran's original statement, are you still in agreement with it, or are you now possibly reconsidering your position, as Eran apparently has. I'm asking, because your messages have been part of the basis upon which I've been taking the position as editor that the working group consensus is that no quoting may occur. (The other reason that I believed, as editor, that this was a consensus position is that this syntax restriction has been present in every Bearer draft, as it was in OAuth 2.0 draft 10, which was the basis of the first Bearer draft.) If that's not the actual working group consensus (or it's not anymore), it would be good to know that now. > > Finally, I'd like to respond publicly to a comment made to me in a private note sent to me about the current discussions. In it, the sender (an IETF "old hand") observed that it could appear from the strength of my responses to Julian's feedback that I might be trying to defend a particular personal view of how these issues should be resolved. I responded to him that the irony here is that I'm not trying to representing a personal position. Rather, I'm truly trying to do what I believe an IETF editor is supposed to do, which is to represent the working group's positions. > > I'm quite open to the working group making it clear that its position has changed with respect to Julian's comments and equally open to the working group standing behind the text in the current draft. If the chairs would like to help bring this issue to successful closure, I would highly welcome their participation as well. > > Personally, I'd mostly just like to see the spec finished! > > -- Mike > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Eran Hammer > Sent: Tuesday, January 24, 2012 10:24 PM > To: Julian Reschke; ietf@ietf.org > Cc: The IESG; oauth@ietf.org > Subject: Re: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard > > I fully agree with Julian's perspective. I believe there is sufficient feedback requiring further review of this issue. If the editor cannot facilitate a path forward, I request the chairs to intervene. > > I will make sure this feedback is fully applied to the MAC token specification in the next draft. > > EHL > > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Julian Reschke >> Sent: Tuesday, January 24, 2012 3:24 PM >> To: ietf@ietf.org >> Cc: The IESG; oauth@ietf.org >> Subject: Re: [OAUTH-WG] Last Call: >> (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed >> Standard >> >> On 2012-01-23 16:58, Julian Reschke wrote: >>> On 2012-01-23 16:46, The IESG wrote: >>>> The IESG has received a request from the Web Authorization Protocol >>>> WG >>>> (oauth) to consider the following document: >>>> - 'The OAuth 2.0 Authorization Protocol: Bearer Tokens' >>>> as a Proposed Standard ... >>> Please see my comments in >>> >>> which I think have not been addressed. >>> ... >> In an off-list conversation I heard that what I said before may not be >> as clear as it could be. >> >> So... >> >> 1) draft-ietf-oauth-v2-bearer-15 defines a new HTTP authentication scheme. >> >> 2) In the IANA considerations, it references the registration >> procedure defined in >> > 2.3> >> (now -18, but that doesn't matter here). >> >> 3) That document recommends in >> : >> >> o The parsing of challenges and credentials is defined by this >> specification, and cannot be modified by new authentication >> schemes. When the auth-param syntax is used, all parameters ought >> to support both token and quoted-string syntax, and syntactical >> constraints ought to be defined on the field value after parsing >> (i.e., quoted-string processing). This is necessary so that >> recipients can use a generic parser that applies to all >> authentication schemes. >> >> 4) draft-ietf-oauth-v2-bearer-15 ignores this recommendation. It has >> been mentioned that it might not have ignored it if it had UPPERCASE >> requirements, but in HTTPbis we try to restrict BCP14 keywords to the >> actual protocol, not on recommendations on other specs. >> >> 5) The registration requirement for a new scheme is "IETF review", >> which RFC >> 5226 defines in as: >> >> IETF Review - (Formerly called "IETF Consensus" in >> [IANA-CONSIDERATIONS]) New values are assigned only through >> RFCs that have been shepherded through the IESG as AD- >> Sponsored or IETF WG Documents [RFC3932] [RFC3978]. The >> intention is that the document and proposed assignment will >> be reviewed by the IESG and appropriate IETF WGs (or >> experts, if suitable working groups no longer exist) to >> ensure that the proposed assignment will not negatively >> impact interoperability or otherwise extend IETF protocols >> in an inappropriate or damaging manner. >> >> In this case the WG exists (it's HTTPbis), and the OAuth got two >> reviews from HTTPbis pointing out the problem -- from Mark >> Nottingham, the WG chair, and myself, one of the authors. >> >> And yes, I believe the way OAuth defines the syntax *will* impact >> interoperability. >> >> Also, I haven't seen any explanation why OAuth can not follow the >> recommendation from HTTPbis. >> >> Hope this clarifies things, >> >> 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 eran@hueniverse.com Wed Jan 25 07:32:05 2012 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 7FE5521F86A3 for ; Wed, 25 Jan 2012 07:32:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.472 X-Spam-Level: X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[AWL=0.127, 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 gEOQjMTl37sw for ; Wed, 25 Jan 2012 07:32:04 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 8B92921F8690 for ; Wed, 25 Jan 2012 07:32:04 -0800 (PST) Received: (qmail 13847 invoked from network); 25 Jan 2012 15:32:03 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.47) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 25 Jan 2012 15:32:03 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT005.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Wed, 25 Jan 2012 08:31:59 -0700 From: Eran Hammer To: Mike Jones , Julian Reschke , "ietf@ietf.org" Date: Wed, 25 Jan 2012 08:31:52 -0700 Thread-Topic: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard Thread-Index: AczbPI44ucw8FyvfTTSWdvUFZixqdQAOHCww Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453AAB9686E@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E1F6AAD24975D4BA5B16804296739436638188B@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436638188B@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: The IESG , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard 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, 25 Jan 2012 15:32:05 -0000 Didn't change my view. I'm expanding it to say that we should restrict the = encoding but at the same time reuse the exact same syntax as the default he= ader. It's bad for the web if developers write custom parsers just for Bear= er that will break on any other scheme. For example: WWW-Authenticate: Bearer realm=3D"example", OTHER-SCHEME param=3Dsomethi= ng Is a valid header but one that will cause clients written to the Bearer spe= c to fail. EHL > -----Original Message----- > From: Mike Jones [mailto:Michael.Jones@microsoft.com] > Sent: Wednesday, January 25, 2012 12:37 AM > To: Eran Hammer; Julian Reschke; ietf@ietf.org > Cc: The IESG; oauth@ietf.org > Subject: RE: [OAUTH-WG] Last Call: (T= he > OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard >=20 > Eran, do I then correctly understand that you've changed your mind on the > position you took in http://www.ietf.org/mail- > archive/web/oauth/current/msg07698.html, which was: "All I agree with is = to > limit the scope character-set in the v2 spec to the subset of ASCII allow= ed in > HTTP header quoted-string, excluding " and \ so no escaping is needed, > ever."? I ask this, because if I correctly understand your statement tha= t you > agree with Julian, you are now taking the position that you are OK with > recipients being required to perform escape processing for the scope (and > other) parameters and with them being required to accept them either as > tokens or as quoted strings. >=20 > This raises a question I'd like to ask John Bradley, William Mills, Phil = Hunt, and > Justin Richter: Since all of you replied with a +1 to Eran's original st= atement, > are you still in agreement with it, or are you now possibly reconsidering= your > position, as Eran apparently has. I'm asking, because your messages have > been part of the basis upon which I've been taking the position as editor= that > the working group consensus is that no quoting may occur. (The other > reason that I believed, as editor, that this was a consensus position is = that > this syntax restriction has been present in every Bearer draft, as it was= in > OAuth 2.0 draft 10, which was the basis of the first Bearer draft.) If t= hat's not > the actual working group consensus (or it's not anymore), it would be goo= d > to know that now. >=20 > Finally, I'd like to respond publicly to a comment made to me in a privat= e note > sent to me about the current discussions. In it, the sender (an IETF "ol= d > hand") observed that it could appear from the strength of my responses to > Julian's feedback that I might be trying to defend a particular personal = view > of how these issues should be resolved. I responded to him that the iron= y > here is that I'm not trying to representing a personal position. Rather,= I'm > truly trying to do what I believe an IETF editor is supposed to do, which= is to > represent the working group's positions. >=20 > I'm quite open to the working group making it clear that its position has > changed with respect to Julian's comments and equally open to the working > group standing behind the text in the current draft. If the chairs would= like to > help bring this issue to successful closure, I would highly welcome their > participation as well. >=20 > Personally, I'd mostly just like to see the spec finished! >=20 > -- Mike >=20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Eran Hammer > Sent: Tuesday, January 24, 2012 10:24 PM > To: Julian Reschke; ietf@ietf.org > Cc: The IESG; oauth@ietf.org > Subject: Re: [OAUTH-WG] Last Call: (T= he > OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard >=20 > I fully agree with Julian's perspective. I believe there is sufficient fe= edback > requiring further review of this issue. If the editor cannot facilitate a= path > forward, I request the chairs to intervene. >=20 > I will make sure this feedback is fully applied to the MAC token specific= ation > in the next draft. >=20 > EHL >=20 >=20 > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > > Of Julian Reschke > > Sent: Tuesday, January 24, 2012 3:24 PM > > To: ietf@ietf.org > > Cc: The IESG; oauth@ietf.org > > Subject: Re: [OAUTH-WG] Last Call: > > (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed > > Standard > > > > On 2012-01-23 16:58, Julian Reschke wrote: > > > On 2012-01-23 16:46, The IESG wrote: > > >> > > >> The IESG has received a request from the Web Authorization Protocol > > >> WG > > >> (oauth) to consider the following document: > > >> - 'The OAuth 2.0 Authorization Protocol: Bearer Tokens' > > >> as a Proposed Standard ... > > > > > > Please see my comments in > > > archive/web/oauth/current/msg08120.html> > > > which I think have not been addressed. > > > ... > > > > In an off-list conversation I heard that what I said before may not be > > as clear as it could be. > > > > So... > > > > 1) draft-ietf-oauth-v2-bearer-15 defines a new HTTP authentication > scheme. > > > > 2) In the IANA considerations, it references the registration > > procedure defined in > > > 2.3> > > (now -18, but that doesn't matter here). > > > > 3) That document recommends in > > : > > > > o The parsing of challenges and credentials is defined by this > > specification, and cannot be modified by new authentication > > schemes. When the auth-param syntax is used, all parameters oug= ht > > to support both token and quoted-string syntax, and syntactical > > constraints ought to be defined on the field value after parsing > > (i.e., quoted-string processing). This is necessary so that > > recipients can use a generic parser that applies to all > > authentication schemes. > > > > 4) draft-ietf-oauth-v2-bearer-15 ignores this recommendation. It has > > been mentioned that it might not have ignored it if it had UPPERCASE > > requirements, but in HTTPbis we try to restrict BCP14 keywords to the > > actual protocol, not on recommendations on other specs. > > > > 5) The registration requirement for a new scheme is "IETF review", > > which RFC > > 5226 defines in as: > > > > IETF Review - (Formerly called "IETF Consensus" in > > [IANA-CONSIDERATIONS]) New values are assigned only throug= h > > RFCs that have been shepherded through the IESG as AD- > > Sponsored or IETF WG Documents [RFC3932] [RFC3978]. The > > intention is that the document and proposed assignment wil= l > > be reviewed by the IESG and appropriate IETF WGs (or > > experts, if suitable working groups no longer exist) to > > ensure that the proposed assignment will not negatively > > impact interoperability or otherwise extend IETF protocols > > in an inappropriate or damaging manner. > > > > In this case the WG exists (it's HTTPbis), and the OAuth got two > > reviews from HTTPbis pointing out the problem -- from Mark > > Nottingham, the WG chair, and myself, one of the authors. > > > > And yes, I believe the way OAuth defines the syntax *will* impact > > interoperability. > > > > Also, I haven't seen any explanation why OAuth can not follow the > > recommendation from HTTPbis. > > > > Hope this clarifies things, > > > > 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 >=20 From eran@hueniverse.com Wed Jan 25 07:35:45 2012 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 7443D21F8680 for ; Wed, 25 Jan 2012 07:35:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.117, 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 s3J7bb6ncHfW for ; Wed, 25 Jan 2012 07:35:44 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 495C021F85C2 for ; Wed, 25 Jan 2012 07:35:44 -0800 (PST) Received: (qmail 20087 invoked from network); 25 Jan 2012 15:35:44 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.47) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 25 Jan 2012 15:35:44 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT005.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Wed, 25 Jan 2012 08:35:41 -0700 From: Eran Hammer To: "eran@hammer-lahav.net" , Mike Jones , Julian Reschke , "ietf@ietf.org" Date: Wed, 25 Jan 2012 08:35:35 -0700 Thread-Topic: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard Thread-Index: AczbPI44ucw8FyvfTTSWdvUFZixqdQAOHCwwAAB24UA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453AAB9686F@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E1F6AAD24975D4BA5B16804296739436638188B@TK5EX14MBXC284.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723453AAB9686E@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453AAB9686E@P3PW5EX1MB01.EX1.SECURESERVER.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: The IESG , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard 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, 25 Jan 2012 15:35:45 -0000 And by 'restrict the encoding' I meant limit the allowed character-set in t= he value to remove the need for encoding (but encoding which results in a v= alid value - as unnecessary as it may be - is still allowed). EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Eran Hammer > Sent: Wednesday, January 25, 2012 7:32 AM > To: Mike Jones; Julian Reschke; ietf@ietf.org > Cc: The IESG; oauth@ietf.org > Subject: Re: [OAUTH-WG] Last Call: (T= he > OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard >=20 > Didn't change my view. I'm expanding it to say that we should restrict th= e > encoding but at the same time reuse the exact same syntax as the default > header. It's bad for the web if developers write custom parsers just for > Bearer that will break on any other scheme. For example: >=20 > WWW-Authenticate: Bearer realm=3D"example", OTHER-SCHEME > param=3Dsomething >=20 > Is a valid header but one that will cause clients written to the Bearer s= pec to > fail. >=20 > EHL >=20 > > -----Original Message----- > > From: Mike Jones [mailto:Michael.Jones@microsoft.com] > > Sent: Wednesday, January 25, 2012 12:37 AM > > To: Eran Hammer; Julian Reschke; ietf@ietf.org > > Cc: The IESG; oauth@ietf.org > > Subject: RE: [OAUTH-WG] Last Call: > > (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed > > Standard > > > > Eran, do I then correctly understand that you've changed your mind on > > the position you took in http://www.ietf.org/mail- > > archive/web/oauth/current/msg07698.html, which was: "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 ask this, because if I correctly > > understand your statement that you agree with Julian, you are now > > taking the position that you are OK with recipients being required to > > perform escape processing for the scope (and > > other) parameters and with them being required to accept them either > > as tokens or as quoted strings. > > > > This raises a question I'd like to ask John Bradley, William Mills, > > Phil Hunt, and Justin Richter: Since all of you replied with a +1 to > > Eran's original statement, are you still in agreement with it, or are > > you now possibly reconsidering your position, as Eran apparently has. > > I'm asking, because your messages have been part of the basis upon > > which I've been taking the position as editor that the working group > > consensus is that no quoting may occur. (The other reason that I > > believed, as editor, that this was a consensus position is that this > > syntax restriction has been present in every Bearer draft, as it was > > in OAuth 2.0 draft 10, which was the basis of the first Bearer draft.) > > If that's not the actual working group consensus (or it's not anymore),= it > would be good to know that now. > > > > Finally, I'd like to respond publicly to a comment made to me in a > > private note sent to me about the current discussions. In it, the > > sender (an IETF "old > > hand") observed that it could appear from the strength of my responses > > to Julian's feedback that I might be trying to defend a particular > > personal view of how these issues should be resolved. I responded to > > him that the irony here is that I'm not trying to representing a > > personal position. Rather, I'm truly trying to do what I believe an > > IETF editor is supposed to do, which is to represent the working group'= s > positions. > > > > I'm quite open to the working group making it clear that its position > > has changed with respect to Julian's comments and equally open to the > > working group standing behind the text in the current draft. If the > > chairs would like to help bring this issue to successful closure, I > > would highly welcome their participation as well. > > > > Personally, I'd mostly just like to see the spec finished! > > > > -- Mike > > > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > > Of Eran Hammer > > Sent: Tuesday, January 24, 2012 10:24 PM > > To: Julian Reschke; ietf@ietf.org > > Cc: The IESG; oauth@ietf.org > > Subject: Re: [OAUTH-WG] Last Call: > > (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed > > Standard > > > > I fully agree with Julian's perspective. I believe there is sufficient > > feedback requiring further review of this issue. If the editor cannot > > facilitate a path forward, I request the chairs to intervene. > > > > I will make sure this feedback is fully applied to the MAC token > > specification in the next draft. > > > > EHL > > > > > > > -----Original Message----- > > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > > > Behalf Of Julian Reschke > > > Sent: Tuesday, January 24, 2012 3:24 PM > > > To: ietf@ietf.org > > > Cc: The IESG; oauth@ietf.org > > > Subject: Re: [OAUTH-WG] Last Call: > > > > > > (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed > > > Standard > > > > > > On 2012-01-23 16:58, Julian Reschke wrote: > > > > On 2012-01-23 16:46, The IESG wrote: > > > >> > > > >> The IESG has received a request from the Web Authorization > > > >> Protocol WG > > > >> (oauth) to consider the following document: > > > >> - 'The OAuth 2.0 Authorization Protocol: Bearer Tokens' > > > >> as a Proposed Standard ... > > > > > > > > Please see my comments in > > > > > archive/web/oauth/current/msg08120.html> > > > > which I think have not been addressed. > > > > ... > > > > > > In an off-list conversation I heard that what I said before may not > > > be as clear as it could be. > > > > > > So... > > > > > > 1) draft-ietf-oauth-v2-bearer-15 defines a new HTTP authentication > > scheme. > > > > > > 2) In the IANA considerations, it references the registration > > > procedure defined in > > > > > 2.3> > > > (now -18, but that doesn't matter here). > > > > > > 3) That document recommends in > > > : > > > > > > o The parsing of challenges and credentials is defined by this > > > specification, and cannot be modified by new authentication > > > schemes. When the auth-param syntax is used, all parameters o= ught > > > to support both token and quoted-string syntax, and syntactica= l > > > constraints ought to be defined on the field value after parsi= ng > > > (i.e., quoted-string processing). This is necessary so that > > > recipients can use a generic parser that applies to all > > > authentication schemes. > > > > > > 4) draft-ietf-oauth-v2-bearer-15 ignores this recommendation. It has > > > been mentioned that it might not have ignored it if it had UPPERCASE > > > requirements, but in HTTPbis we try to restrict BCP14 keywords to > > > the actual protocol, not on recommendations on other specs. > > > > > > 5) The registration requirement for a new scheme is "IETF review", > > > which RFC > > > 5226 defines in as: > > > > > > IETF Review - (Formerly called "IETF Consensus" in > > > [IANA-CONSIDERATIONS]) New values are assigned only thro= ugh > > > RFCs that have been shepherded through the IESG as AD- > > > Sponsored or IETF WG Documents [RFC3932] [RFC3978]. The > > > intention is that the document and proposed assignment w= ill > > > be reviewed by the IESG and appropriate IETF WGs (or > > > experts, if suitable working groups no longer exist) to > > > ensure that the proposed assignment will not negatively > > > impact interoperability or otherwise extend IETF protoco= ls > > > in an inappropriate or damaging manner. > > > > > > In this case the WG exists (it's HTTPbis), and the OAuth got two > > > reviews from HTTPbis pointing out the problem -- from Mark > > > Nottingham, the WG chair, and myself, one of the authors. > > > > > > And yes, I believe the way OAuth defines the syntax *will* impact > > > interoperability. > > > > > > Also, I haven't seen any explanation why OAuth can not follow the > > > recommendation from HTTPbis. > > > > > > Hope this clarifies things, > > > > > > 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 > > >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From ve7jtb@ve7jtb.com Wed Jan 25 08:33:46 2012 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 7BD0821F85E9; Wed, 25 Jan 2012 08:33:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.511 X-Spam-Level: X-Spam-Status: No, score=-3.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 b6BhniCxinAI; Wed, 25 Jan 2012 08:33:45 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 53C7B21F8574; Wed, 25 Jan 2012 08:33:45 -0800 (PST) Received: by yhnn12 with SMTP id n12so2673510yhn.31 for ; Wed, 25 Jan 2012 08:33:44 -0800 (PST) Received: by 10.236.85.230 with SMTP id u66mr26111255yhe.83.1327509223013; Wed, 25 Jan 2012 08:33:43 -0800 (PST) Received: from [192.168.1.213] ([190.22.13.148]) by mx.google.com with ESMTPS id y58sm1543351yhi.17.2012.01.25.08.33.38 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 Jan 2012 08:33:40 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/signed; boundary="Apple-Mail=_48621B5C-1B04-4989-8790-1373A2A47AC5"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436638188B@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Wed, 25 Jan 2012 13:33:36 -0300 Message-Id: <72C55AEA-2165-4950-8C3D-6F7694FB8F05@ve7jtb.com> References: <4E1F6AAD24975D4BA5B16804296739436638188B@TK5EX14MBXC284.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1251.1) X-Gm-Message-State: ALoCoQm93VfSd+8zfsFCFGexYVa88KIoT6VW6u5deYyZTYQtbSumi1e79KlYRggeTn+o8dOiw4be Cc: Julian Reschke , "oauth@ietf.org" , "ietf@ietf.org" , The IESG Subject: Re: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard 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, 25 Jan 2012 16:33:46 -0000 --Apple-Mail=_48621B5C-1B04-4989-8790-1373A2A47AC5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Eran agreed to move the restriction on production rules into the core = spec. That was what I was agreeing with. I don't quite understand Eran's new position if he has one. I am in favour of restricting the input, however it is possible I am = missing something in this long thread. John B. On 2012-01-25, at 5:37 AM, Mike Jones wrote: > Eran, do I then correctly understand that you've changed your mind on = the position you took in = http://www.ietf.org/mail-archive/web/oauth/current/msg07698.html, which = was: "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 ask this, because = if I correctly understand your statement that you agree with Julian, you = are now taking the position that you are OK with recipients being = required to perform escape processing for the scope (and other) = parameters and with them being required to accept them either as tokens = or as quoted strings. >=20 > This raises a question I'd like to ask John Bradley, William Mills, = Phil Hunt, and Justin Richter: Since all of you replied with a +1 to = Eran's original statement, are you still in agreement with it, or are = you now possibly reconsidering your position, as Eran apparently has. = I'm asking, because your messages have been part of the basis upon which = I've been taking the position as editor that the working group consensus = is that no quoting may occur. (The other reason that I believed, as = editor, that this was a consensus position is that this syntax = restriction has been present in every Bearer draft, as it was in OAuth = 2.0 draft 10, which was the basis of the first Bearer draft.) If that's = not the actual working group consensus (or it's not anymore), it would = be good to know that now. >=20 > Finally, I'd like to respond publicly to a comment made to me in a = private note sent to me about the current discussions. In it, the = sender (an IETF "old hand") observed that it could appear from the = strength of my responses to Julian's feedback that I might be trying to = defend a particular personal view of how these issues should be = resolved. I responded to him that the irony here is that I'm not trying = to representing a personal position. Rather, I'm truly trying to do = what I believe an IETF editor is supposed to do, which is to represent = the working group's positions. >=20 > I'm quite open to the working group making it clear that its position = has changed with respect to Julian's comments and equally open to the = working group standing behind the text in the current draft. If the = chairs would like to help bring this issue to successful closure, I = would highly welcome their participation as well. >=20 > Personally, I'd mostly just like to see the spec finished! >=20 > -- Mike >=20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf = Of Eran Hammer > Sent: Tuesday, January 24, 2012 10:24 PM > To: Julian Reschke; ietf@ietf.org > Cc: The IESG; oauth@ietf.org > Subject: Re: [OAUTH-WG] Last Call: = (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed = Standard >=20 > I fully agree with Julian's perspective. I believe there is sufficient = feedback requiring further review of this issue. If the editor cannot = facilitate a path forward, I request the chairs to intervene.=20 >=20 > I will make sure this feedback is fully applied to the MAC token = specification in the next draft. >=20 > EHL >=20 >=20 >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf=20 >> Of Julian Reschke >> Sent: Tuesday, January 24, 2012 3:24 PM >> To: ietf@ietf.org >> Cc: The IESG; oauth@ietf.org >> Subject: Re: [OAUTH-WG] Last Call: = =20 >> (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed=20 >> Standard >>=20 >> On 2012-01-23 16:58, Julian Reschke wrote: >>> On 2012-01-23 16:46, The IESG wrote: >>>>=20 >>>> The IESG has received a request from the Web Authorization Protocol=20= >>>> WG >>>> (oauth) to consider the following document: >>>> - 'The OAuth 2.0 Authorization Protocol: Bearer Tokens' >>>> as a Proposed Standard ... >>>=20 >>> Please see my comments in >>> >>> which I think have not been addressed. >>> ... >>=20 >> In an off-list conversation I heard that what I said before may not = be=20 >> as clear as it could be. >>=20 >> So... >>=20 >> 1) draft-ietf-oauth-v2-bearer-15 defines a new HTTP authentication = scheme. >>=20 >> 2) In the IANA considerations, it references the registration=20 >> procedure defined in=20 >> > 2.3> >> (now -18, but that doesn't matter here). >>=20 >> 3) That document recommends in >> = : >>=20 >> o The parsing of challenges and credentials is defined by this >> specification, and cannot be modified by new authentication >> schemes. When the auth-param syntax is used, all parameters = ought >> to support both token and quoted-string syntax, and syntactical >> constraints ought to be defined on the field value after = parsing >> (i.e., quoted-string processing). This is necessary so that >> recipients can use a generic parser that applies to all >> authentication schemes. >>=20 >> 4) draft-ietf-oauth-v2-bearer-15 ignores this recommendation. It has=20= >> been mentioned that it might not have ignored it if it had UPPERCASE=20= >> requirements, but in HTTPbis we try to restrict BCP14 keywords to the=20= >> actual protocol, not on recommendations on other specs. >>=20 >> 5) The registration requirement for a new scheme is "IETF review",=20 >> which RFC >> 5226 defines in as: >>=20 >> IETF Review - (Formerly called "IETF Consensus" in >> [IANA-CONSIDERATIONS]) New values are assigned only = through >> RFCs that have been shepherded through the IESG as AD- >> Sponsored or IETF WG Documents [RFC3932] [RFC3978]. The >> intention is that the document and proposed assignment = will >> be reviewed by the IESG and appropriate IETF WGs (or >> experts, if suitable working groups no longer exist) to >> ensure that the proposed assignment will not negatively >> impact interoperability or otherwise extend IETF = protocols >> in an inappropriate or damaging manner. >>=20 >> In this case the WG exists (it's HTTPbis), and the OAuth got two=20 >> reviews from HTTPbis pointing out the problem -- from Mark=20 >> Nottingham, the WG chair, and myself, one of the authors. >>=20 >> And yes, I believe the way OAuth defines the syntax *will* impact=20 >> interoperability. >>=20 >> Also, I haven't seen any explanation why OAuth can not follow the=20 >> recommendation from HTTPbis. >>=20 >> Hope this clarifies things, >>=20 >> 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 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_48621B5C-1B04-4989-8790-1373A2A47AC5 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 DgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjAx MjUxNjMzMzdaMCMGCSqGSIb3DQEJBDEWBBTQQ7HU45TUn2z5d5MT6e2pWcTWrjCBpAYJKwYBBAGC NxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgZDMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzANBgkqhkiG9w0BAQEFAASC AQB0AqHS/EqS9ChRfNvz8Gj162cLWVn2IoL1xKrMENmQs1vmGzeHPNHi1Vxc/jFJmNGDZS7fM+fL OsaWWTHMeoUCp1/ZQM8JngoetBK6L9OWxkQtJOouzfIx+mZ9XJR4QtKMM+yrQ2z/FuveUr5/0Cnw vOksfQwjCFiOOXb6/vfnglCp+/B+51RMVZ8FIiehTlztatddBsO8C+gCIPWdCSp9MsopcyLhbRRR KecxwieJYtD0ptiyFh/0ZsEgTKoC40y+QBNtGnSw6CJFAPqAUYmcZRP9CLGY0rFxIJA3wN/NlZ1e 0F5lchtupjy5/ashjwtQjgyxbok5QTLo8QWG3dCIAAAAAAAA --Apple-Mail=_48621B5C-1B04-4989-8790-1373A2A47AC5-- From wmills@yahoo-inc.com Wed Jan 25 09:49:25 2012 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 CB49721F84A1 for ; Wed, 25 Jan 2012 09:49:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.454 X-Spam-Level: X-Spam-Status: No, score=-17.454 tagged_above=-999 required=5 tests=[AWL=0.144, 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 dOhMfuybsdgC for ; Wed, 25 Jan 2012 09:49:24 -0800 (PST) Received: from nm6.bullet.mail.ac4.yahoo.com (nm6.bullet.mail.ac4.yahoo.com [98.139.52.203]) by ietfa.amsl.com (Postfix) with SMTP id 5244421F8623 for ; Wed, 25 Jan 2012 09:49:24 -0800 (PST) Received: from [98.139.52.190] by nm6.bullet.mail.ac4.yahoo.com with NNFMP; 25 Jan 2012 17:49:21 -0000 Received: from [98.139.52.170] by tm3.bullet.mail.ac4.yahoo.com with NNFMP; 25 Jan 2012 17:49:21 -0000 Received: from [127.0.0.1] by omp1053.mail.ac4.yahoo.com with NNFMP; 25 Jan 2012 17:49:21 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 279485.11275.bm@omp1053.mail.ac4.yahoo.com Received: (qmail 74524 invoked by uid 60001); 25 Jan 2012 17:49:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1327513760; bh=gzWvvwpvBEFGEHDdOLdphMSF+bEnwd5p2fAuLCdUO8k=; 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=VgQ5uOOIz273f6LnhTkcixrznWODoPD3qYjnHAZETUIUTI5nR4Fb2zPCCFpLE+YW7rTRhKtkcSD5a0BmoNzoH7rCjRHrH0VMGJU0UMBPueOI/Qr9vlTS7Tj69+l8Ji1CB3S8LVoag5bocS0aOP7oaCtNht1rdRyfzcpDBGlqHfg= 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=dBNWB4YUSiStwkEDHEP4CTuh4Le84YGPsFdpB0zrK6KbbWVabR71w085oIUenxZ1TDv7/bYcGIQCsjCp1j77z0OVXyWP1npvxz2iugDGjngIFuscyvBE35U4VBaLYekX4G5XiVeRZt/DLr2Q2m80SlAwg64CG+r5Ysz1UzWPHhA=; X-YMail-OSG: R6REnA4VM1mGWbbIDreIWQ2ceqjq48XsgO0KaHvTCTLYakp YvwksBUWVtDEl5s4b.QEwIZ1IQKHA5Zp.azg6H5mWs8qIKbW3WKcSKEoxz_g 01oafz6maog_.1lncOTVETqoXClXHUZ_tadT2D6aurFA5lFLD4_Jg9GAc5Yn aWiQ2qSHERofHV..XZWzeLV8_lVBtAnyLzdxMC1vP1YBtAkoSxFCSb60XrJ7 .1EAO6wBOafMVvJ4oxgRUY98xTJ2yzhQ9lRpNBJaH39ZUgQwM0zMDrzAsC_t 8ZcLFVkoZDv0riGuQiYphuUUlDGQiBt3lAJqEBhtR25z0MhnXA1o05OrK17a .g34l2bF6M.685i5QOoXHvIB6_IJD1mt2dh6YyvWGmjcyt2.Gx3MG9SR1zzb HJsKuttziZKHTmFHTLuAT2qWUJQ-- Received: from [99.31.212.42] by web31806.mail.mud.yahoo.com via HTTP; Wed, 25 Jan 2012 09:49:19 PST X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.116.338427 References: <4E1F6AAD24975D4BA5B16804296739436638188B@TK5EX14MBXC284.redmond.corp.microsoft.com> Message-ID: <1327513759.74454.YahooMailNeo@web31806.mail.mud.yahoo.com> Date: Wed, 25 Jan 2012 09:49:19 -0800 (PST) From: William Mills To: Mike Jones , Eran Hammer , Julian Reschke , "ietf@ietf.org" In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436638188B@TK5EX14MBXC284.redmond.corp.microsoft.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1055047407-1216978258-1327513759=:74454" Cc: The IESG , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard 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, 25 Jan 2012 17:49:25 -0000 ---1055047407-1216978258-1327513759=:74454 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable What I was +1 to there is that it makes sense to limit the character set, a= nd I still think limiting the character set is the right thing to do.=A0 = =0A=0A=0AI have said before in other threads, and still believe, that all o= f the definition for things like scope need to be in the OAuth2 base spec a= nd should be included by reference in all profiles like Bearer and MAC.=A0= =A0 =0A=0A=0AI also find the argument that we need to make sure that this s= tuff is parse-able by generic HTTP header parsers to be a compelling one, b= ecause the more implementers can lean on extant working parsers the more li= kely they are to be successful, i.e. let's make sure that PHP can just pars= e this stuff by default and then we do input validation.=0A=0A-bill=0A=0A= =0A=0A________________________________=0A From: Mike Jones =0ATo: Eran Hammer ; Julian Reschke ; "ietf@ietf.org" =0ACc: The IESG ; "oauth@ietf.org" =0ASent: Wednesday, January 25,= 2012 12:37 AM=0ASubject: Re: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Propo= sed Standard=0A =0AEran, do I then correctly understand that you've changed= your mind on the position you took in http://www.ietf.org/mail-archive/web= /oauth/current/msg07698.html, which was: "All I agree with is to limit the = scope character-set in the v2 spec to the subset of ASCII allowed in HTTP h= eader quoted-string, excluding " and \ so no escaping is needed, ever."?=A0= I ask this, because if I correctly understand your statement that you agre= e with Julian, you are now taking the position that you are OK with recipie= nts being required to perform escape processing for the scope (and other) p= arameters and with them being required to accept them either as tokens or a= s quoted strings.=0A=0AThis raises a question I'd like to ask John Bradley,= William Mills, Phil Hunt, and Justin Richter:=A0 Since all of you replied = with a +1 to Eran's original statement, are you still in agreement with it,= or are you now possibly reconsidering your position, as Eran apparently ha= s.=A0 I'm asking, because your messages have been part of the basis upon wh= ich I've been taking the position as editor that the working group consensu= s is that no quoting may occur.=A0 (The other reason that I believed, as ed= itor, that this was a consensus position is that this syntax restriction ha= s been present in every Bearer draft, as it was in OAuth 2.0 draft 10, whic= h was the basis of the first Bearer draft.)=A0 If that's not the actual wor= king group consensus (or it's not anymore), it would be good to know that n= ow.=0A=0AFinally, I'd like to respond publicly to a comment made to me in a= private note sent to me about the current discussions.=A0 In it, the sende= r (an IETF "old hand") observed that it could appear from the strength of m= y responses to Julian's feedback that I might be trying to defend a particu= lar personal view of how these issues should be resolved.=A0 I responded to= him that the irony here is that I'm not trying to representing a personal = position.=A0 Rather, I'm truly trying to do what I believe an IETF editor i= s supposed to do, which is to represent the working group's positions.=0A= =0AI'm quite open to the working group making it clear that its position ha= s changed with respect to Julian's comments and equally open to the working= group standing behind the text in the current draft.=A0 If the chairs woul= d like to help bring this issue to successful closure, I would highly welco= me their participation as well.=0A=0APersonally, I'd mostly just like to se= e the spec finished!=0A=0A=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 -- Mike= =0A=0A-----Original Message-----=0AFrom: oauth-bounces@ietf.org [mailto:oau= th-bounces@ietf.org] On Behalf Of Eran Hammer=0ASent: Tuesday, January 24, = 2012 10:24 PM=0ATo: Julian Reschke; ietf@ietf.org=0ACc: The IESG; oauth@iet= f.org=0ASubject: Re: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Stand= ard=0A=0AI fully agree with Julian's perspective. I believe there is suffic= ient feedback requiring further review of this issue. If the editor cannot = facilitate a path forward, I request the chairs to intervene. =0A=0AI will = make sure this feedback is fully applied to the MAC token specification in = the next draft.=0A=0AEHL=0A=0A=0A> -----Original Message-----=0A> From: oau= th-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf =0A> Of Julia= n Reschke=0A> Sent: Tuesday, January 24, 2012 3:24 PM=0A> To: ietf@ietf.org= =0A> Cc: The IESG; oauth@ietf.org=0A> Subject: Re: [OAUTH-WG] Last Call: =0A> (The OAuth 2.0 Authorization Protoco= l: Bearer Tokens) to Proposed =0A> Standard=0A> =0A> On 2012-01-23 16:58, J= ulian Reschke wrote:=0A> > On 2012-01-23 16:46, The IESG wrote:=0A> >>=0A> = >> The IESG has received a request from the Web Authorization Protocol =0A>= >> WG=0A> >> (oauth) to consider the following document:=0A> >> - 'The OAu= th 2.0 Authorization Protocol: Bearer Tokens'=0A> >> as a Proposed Standard ...=0A> >=0A> > Please see my comments= in=0A> > =0A> > which I think have not been addressed.=0A> > ...=0A> =0A> In an of= f-list conversation I heard that what I said before may not be =0A> as clea= r as it could be.=0A> =0A> So...=0A> =0A> 1) draft-ietf-oauth-v2-bearer-15 = defines a new HTTP authentication scheme.=0A> =0A> 2) In the IANA considera= tions, it references the registration =0A> procedure defined in =0A> 2.3>=0A> (= now -18, but that doesn't matter here).=0A> =0A> 3) That document recommend= s in=0A> :=0A> =0A>=A0 =A0 o=A0 The parsing of challenges and credentials is = defined by this=0A>=A0 =A0 =A0 =A0 specification, and cannot be modified by= new authentication=0A>=A0 =A0 =A0 =A0 schemes.=A0 When the auth-param synt= ax is used, all parameters ought=0A>=A0 =A0 =A0 =A0 to support both token a= nd quoted-string syntax, and syntactical=0A>=A0 =A0 =A0 =A0 constraints oug= ht to be defined on the field value after parsing=0A>=A0 =A0 =A0 =A0 (i.e.,= quoted-string processing).=A0 This is necessary so that=0A>=A0 =A0 =A0 =A0= recipients can use a generic parser that applies to all=0A>=A0 =A0 =A0 =A0= authentication schemes.=0A> =0A> 4) draft-ietf-oauth-v2-bearer-15 ignores = this recommendation. It has =0A> been mentioned that it might not have igno= red it if it had UPPERCASE =0A> requirements, but in HTTPbis we try to rest= rict BCP14 keywords to the =0A> actual protocol, not on recommendations on = other specs.=0A> =0A> 5) The registration requirement for a new scheme is "= IETF review", =0A> which RFC=0A> 5226 defines in as:=0A> =0A>=A0 =A0 =A0 =A0 IETF Review - (Formerly = called "IETF Consensus" in=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 [IANA-CONSIDERATI= ONS]) New values are assigned only through=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 R= FCs that have been shepherded through the IESG as AD-=0A>=A0 =A0 =A0 =A0 = =A0 =A0 =A0 Sponsored or IETF WG Documents [RFC3932] [RFC3978].=A0 The=0A>= =A0 =A0 =A0 =A0 =A0 =A0 =A0 intention is that the document and proposed ass= ignment will=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 be reviewed by the IESG and app= ropriate IETF WGs (or=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 experts, if suitable w= orking groups no longer exist) to=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 ensure tha= t the proposed assignment will not negatively=0A>=A0 =A0 =A0 =A0 =A0 =A0 = =A0 impact interoperability or otherwise extend IETF protocols=0A>=A0 =A0 = =A0 =A0 =A0 =A0 =A0 in an inappropriate or damaging manner.=0A> =0A> In thi= s case the WG exists (it's HTTPbis), and the OAuth got two =0A> reviews fro= m HTTPbis pointing out the problem=A0 -- from Mark =0A> Nottingham, the WG = chair, and myself, one of the authors.=0A> =0A> And yes, I believe the way = OAuth defines the syntax *will* impact =0A> interoperability.=0A> =0A> Also= , I haven't seen any explanation why OAuth can not follow the =0A> recommen= dation from HTTPbis.=0A> =0A> Hope this clarifies things,=0A> =0A> Julian= =0A> _______________________________________________=0A> OAuth mailing list= =0A> OAuth@ietf.org=0A> https://www.ietf.org/mailman/listinfo/oauth=0A_____= __________________________________________=0AOAuth mailing list=0AOAuth@iet= f.org=0Ahttps://www.ietf.org/mailman/listinfo/oauth=0A=0A=0A_______________= ________________________________=0AOAuth mailing list=0AOAuth@ietf.org=0Aht= tps://www.ietf.org/mailman/listinfo/oauth ---1055047407-1216978258-1327513759=:74454 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
What I was +1 to there is that it makes sense to limit the character set,= and I still think limiting the character set is the right thing to do.&nbs= p;

I have said befo= re in other threads, and still believe, that all of the definition for thin= gs like scope need to be in the OAuth2 base spec and should be included by = reference in all profiles like Bearer and MAC.  

I also find the argument that we ne= ed to make sure that this stuff is parse-able by generic HTTP header parser= s to be a compelling one, because the more implementers can lean on extant = working parsers the more likely they are to be successful, i.e. let's make = sure that PHP can just parse this stuff by default and then we do input validation.

-bill=

From: Mike Jones <Michael.Jones@micr= osoft.com>
To: Eran= Hammer <eran@hueniverse.com>; Julian Reschke <julian.reschke@gmx.= de>; "ietf@ietf.org" <ietf@ietf.org>
Cc: The IESG <iesg@ietf.org>; "oauth@ietf.org= " <oauth@ietf.org>
Sent: Wednesday, January 25, 2012 12:37 AM
Subject: Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-v2-bearer-15.txt> (The OAuth 2.0 Authorization Pro= tocol: Bearer Tokens) to Proposed Standard

=0AEran, = do I then correctly understand that you've changed your mind on the positio= n you took in http://www.ietf.org/mail-archive/web/oauth/current/msg07698.h= tml, which was: "All I agree with is to limit the scope character-set in th= e v2 spec to the subset of ASCII allowed in HTTP header quoted-string, excl= uding " and \ so no escaping is needed, ever."?  I ask this, because i= f I correctly understand your statement that you agree with Julian, you are= now taking the position that you are OK with recipients being required to = perform escape processing for the scope (and other) parameters and with the= m being required to accept them either as tokens or as quoted strings.
<= br>This raises a question I'd like to ask John Bradley, William Mills, Phil= Hunt, and Justin Richter:  Since all of you replied with a +1 to Eran= 's original statement, are you still in agreement with it, or are you now p= ossibly reconsidering your position, as Eran apparently has.  I'm asking, because your messages have been part of the basis u= pon which I've been taking the position as editor that the working group co= nsensus is that no quoting may occur.  (The other reason that I believ= ed, as editor, that this was a consensus position is that this syntax restr= iction has been present in every Bearer draft, as it was in OAuth 2.0 draft= 10, which was the basis of the first Bearer draft.)  If that's not th= e actual working group consensus (or it's not anymore), it would be good to= know that now.

Finally, I'd like to respond publicly to a comment m= ade to me in a private note sent to me about the current discussions. = In it, the sender (an IETF "old hand") observed that it could appear from = the strength of my responses to Julian's feedback that I might be trying to= defend a particular personal view of how these issues should be resolved.&= nbsp; I responded to him that the irony here is that I'm not trying to representing a personal position.  Rather, I'm truly trying to do = what I believe an IETF editor is supposed to do, which is to represent the = working group's positions.

I'm quite open to the working group makin= g it clear that its position has changed with respect to Julian's comments = and equally open to the working group standing behind the text in the curre= nt draft.  If the chairs would like to help bring this issue to succes= sful closure, I would highly welcome their participation as well.

Pe= rsonally, I'd mostly just like to see the spec finished!

  = ;              -- Mike
-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Eran Hammer
Sent: Tuesday, January 24, 2012 10:24 PM
To: Julian Reschke; = ietf@ietf= .org
Cc: The IESG; oauth@ietf.org
Subject: Re: [OAUTH-WG] Last Call:= <draft-ietf-oauth-v2-bearer-15.txt> (The OAuth 2.0 Authorization Pro= tocol: Bearer Tokens) to Proposed Standard

I fully agree with Julian= 's perspective. I believe there is sufficient feedback requiring further re= view of this issue. If the editor cannot facilitate a path forward, I reque= st the chairs to intervene.

I will make sure this feedback is fully= applied to the MAC token specification in the next draft.

EHL

> -----Original Message-----
> From: oauth-bounces@= ietf.org [mailto:oauth-bounces@ietf.org] On Beha= lf
> Of Julian Reschke
> Sent: Tuesday, January 24, 2012 3:24 = PM
> To: ietf@ietf.org
> Cc: The IESG; oauth@ietf.org
> Subject: = Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-v2-bearer-15.txt>
>= ; (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed
>= ; Standard
>
> On 2012-01-23 16:58, Julian Reschke wrote:
&= gt; > On 2012-01-23 16:46, The IESG wrote:
> >>
> >= > The IESG has received a request from the Web Authorization Protocol > >> WG
> >> (oauth) to consider the following docum= ent:
> >> - 'The OAuth 2.0 Authorization Protocol: Bearer Token= s'
> >> <draft-ietf-oauth-v2-bearer-15.txt> as a Proposed Standard ...
> >
> > Please see my comments in
> &= gt; <https://www.ietf.org/mail-archive/web/oauth/cu= rrent/msg08120.html>
> > which I think have not been addres= sed.
> > ...
>
> In an off-list conversation I heard = that what I said before may not be
> as clear as it could be.
>= ;
> So...
>
> 1) draft-ietf-oauth-v2-bearer-15 defines = a new HTTP authentication scheme.
>
> 2) In the IANA considera= tions, it references the registration
> procedure defined in
>= ; <http://tools.ietf.org/html/draft-ietf-httpbis-p7= -auth-17#section-
> 2.3>
> (now -18, but that doesn't ma= tter here).
>
> 3) That document recommends in
> <http://tools.ietf.org/html/draft-ietf-httpbis-p7-au= th-17#section-2.3.1>:
>
>    o  The par= sing of challenges and credentials is defined by this
>    =     specification, and cannot be modified by new authentication>        schemes.  When the auth-param syntax= is used, all parameters ought
>        to suppor= t both token and quoted-string syntax, and syntactical
>   =     constraints ought to be defined on the field value after par= sing
>        (i.e., quoted-string processing).&n= bsp; This is necessary so that
>        recipient= s can use a generic parser that applies to all
>      =   authentication schemes.
>
> 4) draft-ietf-oauth-v2-bearer-15 ignores this recommendation. It has
>= been mentioned that it might not have ignored it if it had UPPERCASE
&= gt; requirements, but in HTTPbis we try to restrict BCP14 keywords to the <= br>> actual protocol, not on recommendations on other specs.
> > 5) The registration requirement for a new scheme is "IETF review", > which RFC
> 5226 defines in <http://tools.ietf.org/html/r= fc5226#section-4.1> as:
>
>        = IETF Review - (Formerly called "IETF Consensus" in
>    &nb= sp;         [IANA-CONSIDERATIONS]) New values are assig= ned only through
>              RF= Cs that have been shepherded through the IESG as AD-
>    &= nbsp;         Sponsored or IETF WG Documents [RFC3932] [RFC3978].  The
>          &= nbsp;   intention is that the document and proposed assignment will>              be reviewed by the IE= SG and appropriate IETF WGs (or
>          &= nbsp;   experts, if suitable working groups no longer exist) to
>= ;              ensure that the proposed = assignment will not negatively
>          &n= bsp;   impact interoperability or otherwise extend IETF protocols
&= gt;              in an inappropriate or = damaging manner.
>
> In this case the WG exists (it's HTTPbis)= , and the OAuth got two
> reviews from HTTPbis pointing out the prob= lem  -- from Mark
> Nottingham, the WG chair, and myself, one o= f the authors.
>
> And yes, I believe the way OAuth defines the syntax *will* impact
> interoperability.
>
&g= t; Also, I haven't seen any explanation why OAuth can not follow the
&g= t; recommendation from HTTPbis.
>
> Hope this clarifies things= ,
>
> Julian
> _________________________________________= ______
> OAuth mailing list
> OAuth@ietf.org
> https://www.ie= tf.org/mailman/listinfo/oauth
______________________________________= _________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailm= an/listinfo/oauth


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


---1055047407-1216978258-1327513759=:74454-- From eran@hueniverse.com Wed Jan 25 10:14:43 2012 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 C960E21F85C4 for ; Wed, 25 Jan 2012 10:14:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.484 X-Spam-Level: X-Spam-Status: No, score=-2.484 tagged_above=-999 required=5 tests=[AWL=0.114, 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 wbZpI-+sXkWJ for ; Wed, 25 Jan 2012 10:14:43 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 352F321F8597 for ; Wed, 25 Jan 2012 10:14:43 -0800 (PST) Received: (qmail 29474 invoked from network); 25 Jan 2012 18:12:55 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 25 Jan 2012 18:12:55 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 25 Jan 2012 11:12:47 -0700 From: Eran Hammer To: "oauth@ietf.org" Date: Wed, 25 Jan 2012 11:12:46 -0700 Thread-Topic: WWW-Authenticate Header (Bearer etc.) Thread-Index: AczbjPC+fOyJLtFtQXmA9XYmFqaU5w== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CB45861EFE53eranhueniversecom_" MIME-Version: 1.0 Subject: [OAUTH-WG] WWW-Authenticate Header (Bearer etc.) 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, 25 Jan 2012 18:14:43 -0000 --_000_CB45861EFE53eranhueniversecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable People seems confused about the issue raised by Julian. It is pretty simple= . The HTTP WWW-Authenticate header definition allows each header parameter to= have a quoted string or token value. Token values are very restrictive and= not suitable for scope (no spaces, etc.). Quoted strings allow a wider set= of characters at the cost of requiring escaping for " and \. The WG decided that in order to avoid escaping, we will restrict scope valu= es to only those characters legal in quotes string without escaping. This c= hange was made in =9623. The issue here is different. The WWW-Authenticate header isn't OAuth-specific and it allows the server t= o declare more than one scheme. For example: WWW-Authenticate: Bearer realm=3D"xyz", Basic realm=3D"123" This is how HTTP works and this WG doesn't get to change it. The problem is= that the bearer token specification is changing the *general* definition o= f the WWW-Authenticate header to only use quoted strings and not tokens. Th= is is wrong. It is true that a *generic* parser will be able to parse a bearer token hea= der without any issues. But a parser written specifically for the bearer to= ken use case will most likely fail when parsing the WWW-Authenticate header= with other schemes. OAuth must not define its own WWW-Authenticate handing logic. It should opt= into the HTTP framework without any modifications. It is perfectly fine to= restrict values and by doing so, we made servers simpler by not having to = ever encode scopes but we cannot try to simplify client code by "profiling"= HTTP. My view has not changed and trying to portray it in this fashion shows igno= rance of the issue. I supported restricting the character set of scopes. I = am against changing the HTTP definition of WWW-Authenticate. EHL --_000_CB45861EFE53eranhueniversecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
People seems confused about the= issue raised by Julian. It is pretty simple.

The = HTTP WWW-Authenticate header definition allows each header parameter to hav= e a quoted string or token value. Token values are very restrictive and not= suitable for scope (no spaces, etc.). Quoted strings allow a wider set of = characters at the cost of requiring escaping for " and \.
The WG decided that in order to avoid escaping, we will restri= ct scope values to only those characters legal in quotes string without esc= aping. This change was made in =9623.

The issue he= re is different.

The WWW-Authenticate header = isn't OAuth-specific and it allows the server to declare more than one sche= me. For example:

WWW-Authenticate: Bearer realm=3D= "xyz", Basic realm=3D"123"

Thi= s is how HTTP works and this WG doesn't get to change it. The problem is th= at the bearer token specification is changing the *general* definition of t= he WWW-Authenticate header to only use quoted strings and not tokens. = This is wrong.

It is true that a *generic* parser = will be able to parse a bearer token header without any issues. But a parse= r written specifically for the bearer token use case will most likely fail = when parsing the WWW-Authenticate header with other schemes.

OAuth must not define its own WWW-Authenticate handing= logic. It should opt into the HTTP framework without any modifications. It= is perfectly fine to restrict values and by doing so, we made servers simp= ler by not having to ever encode scopes but we cannot try to simplify clien= t code by "profiling" HTTP.

My view has = not changed and trying to portray it in this fashion shows ignorance of the= issue. I supported restricting the character set of scopes. I am against c= hanging the HTTP definition of WWW-Authenticate.

<= div>EHL

--_000_CB45861EFE53eranhueniversecom_-- From wmills@yahoo-inc.com Wed Jan 25 11:24:33 2012 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 4FA7D21F860B for ; Wed, 25 Jan 2012 11:24:33 -0800 (PST) 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 pYgOD8UIWocZ for ; Wed, 25 Jan 2012 11:24:32 -0800 (PST) Received: from nm40-vm0.bullet.mail.ne1.yahoo.com (nm40-vm0.bullet.mail.ne1.yahoo.com [98.138.229.176]) by ietfa.amsl.com (Postfix) with SMTP id 46BC521F8605 for ; Wed, 25 Jan 2012 11:24:32 -0800 (PST) Received: from [98.138.90.53] by nm40.bullet.mail.ne1.yahoo.com with NNFMP; 25 Jan 2012 19:24:27 -0000 Received: from [98.138.86.157] by tm6.bullet.mail.ne1.yahoo.com with NNFMP; 25 Jan 2012 19:24:27 -0000 Received: from [127.0.0.1] by omp1015.mail.ne1.yahoo.com with NNFMP; 25 Jan 2012 19:24:27 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 350354.35480.bm@omp1015.mail.ne1.yahoo.com Received: (qmail 17572 invoked by uid 60001); 25 Jan 2012 19:24:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1327519466; bh=Y4MvBIo6vm4Qmm7Oy9M0y6tB1zsE+huNH73A3GAM80I=; 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=phyyi01TG0sug9yUQQQHT+jSa8GuGjytTpv0GgnL5cMBtDt6pvLCyqIeI/RIQcGIZtzNx4/U96jqt0ulH98qces9V3LTPRnG/5CQKU8KOaI2mmzvmnPr1doH2gDUE0pZK94dM8i4gFCoF7HVsXtncU4AMkhRqtX1o0lvhZIBBkI= 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=CMqLcbTCgLfxiaH3ma8/hHa2gnQatwO13/KMpgZryA5MopOc+DbbZMRfoyzUceY9xnqyZJlp4mnlxqHWcxlryo6ykjNMcCvxlQdcJrKNMmouUZj2zQWCgvXQlwtafTW2ZTaGe8lv8x927FJCrZfBMJxTOJvqEy5nlGv+14vM75Y=; X-YMail-OSG: Jb13LHYVM1k5Gj9eyBpcwDzwBenMcqjFbN_tzq6FiLledNg BYhq1jXVmkbEcg9fO7OQGQiJ8Msw_oYlhDiVPxxMqTYgDD46MFkNLN5RjGit th.5GK9PswBVkV73JvxynfVbM2Gyb5YY27LOwXXVHylD3a0O.katLhx4Gz4w LpM.nYjd4OGTyGW6TISGAvp00JYKD4Dl8gia9CM4D8U9A5QmmCCuWL8E4moP n.CcaTnzK3dRu9B.G.N0Ofu7GV.mGzrq8M7AesNdpjwytgeG8dYknRQqQDvu qUi8z5cOuABwHuGhFllIswZuQHQ_kcEDuXK3v4H4MWUQl346mzaRnKaMx6zC zJcw1fnR8N_8KdLunCh4iAVGcDX06gZsLXGofzbd9opuKqpixhhkvGTNA0fM UHkLSVhS1MJSyngq2ssCLlNAbT2QNIG.ExvUJPuB6skbxh2PdMg-- Received: from [209.131.62.115] by web31813.mail.mud.yahoo.com via HTTP; Wed, 25 Jan 2012 11:24:26 PST X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.116.338427 References: Message-ID: <1327519466.90783.YahooMailNeo@web31813.mail.mud.yahoo.com> Date: Wed, 25 Jan 2012 11:24:26 -0800 (PST) From: William Mills To: Eran Hammer , "oauth@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="767760015-650303615-1327519466=:90783" Subject: Re: [OAUTH-WG] WWW-Authenticate Header (Bearer etc.) 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, 25 Jan 2012 19:24:33 -0000 --767760015-650303615-1327519466=:90783 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks, that's a good explanation.=0A=0A=0A=0A_____________________________= ___=0A From: Eran Hammer =0ATo: "oauth@ietf.org" =0ASent: Wednesday, January 25, 2012 10:12 AM=0ASubject: [OAUTH= -WG] WWW-Authenticate Header (Bearer etc.)=0A =0A=0APeople seems confused a= bout the issue raised by Julian. It is pretty simple.=0A=0AThe HTTP WWW-Aut= henticate header definition allows each header parameter to have a quoted s= tring or token value. Token values are very restrictive and not suitable fo= r scope (no spaces, etc.). Quoted strings allow a wider set of characters a= t the cost of requiring escaping for " and \.=0A=0AThe WG decided that in o= rder to avoid escaping, we will restrict scope values to only those charact= ers legal in quotes string without escaping. This change was made in =E2=80= =9323.=0A=0AThe issue here is different.=0A=0AThe=C2=A0WWW-Authenticate hea= der isn't OAuth-specific and it allows the server to declare more than one = scheme. For example:=0A=0AWWW-Authenticate: Bearer realm=3D"xyz", Basic rea= lm=3D"123"=0A=0AThis is how HTTP works and this WG doesn't get to change it= . The problem is that the bearer token specification is changing the *gener= al* definition of the=C2=A0WWW-Authenticate header to only use quoted strin= gs and not tokens. This is wrong.=0A=0AIt is true that a *generic* parser w= ill be able to parse a bearer token header without any issues. But a parser= written specifically for the bearer token use case will most likely fail w= hen parsing the=C2=A0WWW-Authenticate header with other schemes.=0A=0AOAuth= must not define its own=C2=A0WWW-Authenticate handing logic. It should opt= into the HTTP framework without any modifications. It is perfectly fine to= restrict values and by doing so, we made servers simpler by not having to = ever encode scopes but we cannot try to simplify client code by "profiling"= HTTP.=0A=0AMy view has not changed and trying to portray it in this fashio= n shows ignorance of the issue. I supported restricting the character set o= f scopes. I am against changing the HTTP definition of=C2=A0WWW-Authenticat= e.=0A=0AEHL=0A=0A_______________________________________________=0AOAuth ma= iling list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/oauth --767760015-650303615-1327519466=:90783 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Thanks, that's a good explanation.

From: E= ran Hammer <eran@hueniverse.com>
To: "oauth@ietf.org" <oauth@ietf.org>
Sent: Wednesday, January 25, 2012 1= 0:12 AM
Subject: [OAUT= H-WG] WWW-Authenticate Header (Bearer etc.)

=0A
=0A
People seems confused about the issue rai= sed by Julian. It is pretty simple.

The HTTP WWW-A= uthenticate header definition allows each header parameter to have a quoted= string or token value. Token values are very restrictive and not suitable = for scope (no spaces, etc.). Quoted strings allow a wider set of characters= at the cost of requiring escaping for " and \.

Th= e WG decided that in order to avoid escaping, we will restrict scope values= to only those characters legal in quotes string without escaping. This cha= nge was made in =E2=80=9323.

The issue here is dif= ferent.

The WWW-Authenticate header isn't OAu= th-specific and it allows the server to declare more than one scheme. For e= xample:

WWW-Authenticate: Bearer realm=3D"xyz", Ba= sic realm=3D"123"

This is how HTTP works and this = WG doesn't get to change it. The problem is that the bearer token specification is changing the *ge= neral* definition of the WWW-Authenticate header to only use quoted st= rings and not tokens. This is wrong.

It is true th= at a *generic* parser will be able to parse a bearer token header without a= ny issues. But a parser written specifically for the bearer token use case = will most likely fail when parsing the WWW-Authenticate header with ot= her schemes.

OAuth must not define its own WW= W-Authenticate handing logic. It should opt into the HTTP framework without= any modifications. It is perfectly fine to restrict values and by doing so= , we made servers simpler by not having to ever encode scopes but we cannot= try to simplify client code by "profiling" HTTP.

= My view has not changed and trying to portray it in this fashion shows igno= rance of the issue. I supported restricting the character set of scopes. I am against changing the HTTP definition of WWW-Authenticate= .

EHL

=0A

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


<= /div>
--767760015-650303615-1327519466=:90783-- From torsten@lodderstedt.net Wed Jan 25 12:42:06 2012 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 2DCDD21F8548; Wed, 25 Jan 2012 12:42:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.811 X-Spam-Level: X-Spam-Status: No, score=-0.811 tagged_above=-999 required=5 tests=[AWL=-0.862, BAYES_00=-2.599, HELO_EQ_DE=0.35, MANGLED_LIST=2.3] 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 WbcR3LeZJ9xb; Wed, 25 Jan 2012 12:42:05 -0800 (PST) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.14]) by ietfa.amsl.com (Postfix) with ESMTP id 8D8DC21F853D; Wed, 25 Jan 2012 12:42:04 -0800 (PST) Received: from [79.253.19.45] (helo=[192.168.71.42]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1Rq9fM-0001Ls-6D; Wed, 25 Jan 2012 21:42:00 +0100 Message-ID: <4F206917.2080406@lodderstedt.net> Date: Wed, 25 Jan 2012 21:41:59 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: S Moonesamy , Tim Bray References: <6.2.5.6.2.20120123134319.0a76c338@resistor.net> <4F1F08A2.4020707@lodderstedt.net> In-Reply-To: <4F1F08A2.4020707@lodderstedt.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: draft-ietf-oauth-v2-threatmodel.all@tools.ietf.org, apps-discuss@ietf.org, oauth@ietf.org Subject: Re: [OAUTH-WG] [apps-discuss] Apps Area review of draft-ietf-oauth-v2-threatmodel-01 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, 25 Jan 2012 20:42:06 -0000 Hi Tim, thanks again for reviewing the threat model document. We will incorporate your comments into a new revision of our document. This work will take some time. So if anyone else wants to review the document, please wait until we announce availability of the next revision. regards, Torsten. Am 24.01.2012 20:38, schrieb Torsten Lodderstedt: > Hi, > > thanks for the thoroughly review. > > The threat document is intended to become an Informational RFC. So we > will follow your advice and remove all normative language. > > regards, > Torsten. > > Am 23.01.2012 22:47, schrieb S Moonesamy: >> The following is the AppsDir review performed by Tim Bray. It would >> be appreciated if a reply is sent to Tim Bray with a copy to the >> apps-discuss mailing list. >> >> I have been selected as the Applications Area Directorate reviewer for >> this draft (for background on appsdir, please see >> http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). >> >> >> Please resolve these comments along with any other Last Call comments >> you may receive. Please wait for direction from your document shepherd >> or AD before posting a new version of the draft. >> >> Document: draft-ietf-oauth-v2-threatmodel-01 >> Title: OAuth 2.0 Threat Model and Security Considerations >> Reviewer: Tim Bray >> Review Date: Jan 23, 2012 >> >> Summary: This needs some more editorial work, but is basically sound. >> It's not clear, though, whether it wants to be an Informational RFC or >> not; the use of RFC2119 language needs special attention. I think a >> few of the "minor issues" are worthy of a little bit more work in >> another draft. >> >> Major Issues: >> >> The use of 2119 MUST/SHOULD/etc doesn't seem fully thought through. I >> normally wouldn't expect a "threat model" to include normative text. >> The basic idea would be to say "Here is an enumeration of the threats, >> and here are the tools available to OAUTH2 implementors to meet them." >> I was impressed by the enumeration, which seemed very complete and >> well thought through. But the usage of 2119, which makes statements >> normative, seems inconsistent. I can think of 2 ways to address this: >> >> 1. Remove all the 2119 words, so this document isn't normative, and >> publish it as an Informational RFC >> 2. Go through and clean up the 2119 language so it's used >> consistently; then this becomes a normative document. >> >> This is going to affect the references to this document from other >> I-Ds in the OAuth suite, which are currently in last call. >> >> Here are all the section-numbered notes enumerating my issues around >> 2119, as I encountered them: >> >> Section 2.3, I'm a little confused about the use of RFC2119 MAY in a >> threat analysis. When you say "The following data elements MAY be >> stored or accessible...", Is this saying that "The OAuth2 RFC says >> that the following data elements MAY be..." or is it saying something >> else. I don't think there's anything seriously wrong here, but a bit >> more explanation might be in order. I note a comparative absence of >> 2119-ese in section 5 describing countermeasures, where one would >> expect to find it. >> Also in 4.3.1, first bullet point, there's "Authorization servers >> MUST..." >> Also in: 4.4.1.1, 4.4.1.6, 4.4.1.12, 4.6.*, 5.1.4.1.5, 5.1.5.11 >> Related: "SHALL"?! in 4.6.3 >> Adding to the concern, there is use of lower-case "must"; note 2nd & >> 3rd bullet points in 4.4.3, which use "MUST" and "must" respectively. >> >> Minor Issues: >> >> 4.1.2 first attack: It says "An attack may obtain the refresh tokens >> issued to a web server client." This needs to be clearer... a "Web >> server client" can be a browser or a native app. Do you mean, "the >> refresh tokens issued by the web server to multiple clients?" >> >> 4.1.2 last attack. In the case where a device is cloned, wouldn't >> "Utilize device lock to prevent unauthorized device access" still be a >> countermeasure? In many devices, such cloning would carry along the >> user's device-lock settings. >> >> 4.4.1.4 2nd bullet. The explanation of why this wouldn't work for >> native clients wasn't comprehensible to me. I'm suspicious of any >> such claims because I can emulate most things a browser can do in a >> mobile client. Perhaps this would be obvious to someone who is an >> OAuth2 implementor. >> >> 4.4.1.9 I think where it says "iFrame" it might mean "WebView", i.e. a >> Web Browser control embedded in the native app. If that's not what it >> means, I don't understand what it's saying. If this is true, then the >> second bullet point is probably wrong. >> >> 4.6.6 1st bullet. I'm not convinced that the Cache-Control header >> will *ensure* that a client protects information properly. Should say >> something like "minimize the risk that authenticated content is not >> protected" >> >> 5.* The enumeration, for some but not all of the countermeasures in >> this section, of the threats against which this is a countermeasure, >> reduces readability and, unless it's generated automatically from the >> underlying source, is redundant information, which is unlikely to be >> consistent between sections 4 and 5, and adds difficulty to >> maintenance of this document without adding much value. I'd just wipe >> all these bullet lists out. If it's generated automatically it's less >> damaging, but still reduces readability. In the current draft, this >> is there for some countermeasures but absent for others. Another good >> reason to just take it out. >> >> 5.2.2.5 Device identifiers are very tricky. It's correct that IMEI is >> not adequate, but there are ways to do it without SMS. For more, see >> http://android-developers.blogspot.com/2011/03/identifying-app-installations.html >> >> >> 5.3.4 Surely a little more could be said about device lock. On a >> typical modern phone, "device lock" options include PINs, passwords, >> "face recognition" and so on. These are *not* equal in their level of >> security they provide. >> >> Nits: >> >> Formatting is lousy. There are notations, including ** and _whatever_ >> that I'm not familiar with in the RFC context. >> >> Section 1.0: s/in-built into/built into/ >> 2.1, last bullet point: "An example could by a..." s/by/be/ >> 2.2, 1st bullet point s/eaves drop/eavesdrop/ >> 2.3, 1st para, s/treat/threat/ >> 2.3.1, last bullet, "per authorization process". Adjectival phrases >> should be hyphenated: "per-authorization process" >> 2.3.3, last bullet, ditto >> 3.1, 1st para, "all kinds of tokens" should be "many kinds of tokens" >> 3.1, 2nd para, should be ; not , after "within the authorization server" >> s/protected/protect/ >> s/different system/different systems/ >> 3.4 1st para, s/intermediary/intermediate/ >> list item 1. s/short-living/short-lived/ >> 3.5 s/malicious client/malicious clients/ >> 3.7 top of page 12, what is the underscore notation _client_id_ mean? >> I'm not familiar with this in the RFC context. >> 1st bullet point: s/token/token's/ >> 2nd bullet point, multiple issues, 1st sentence should be " the >> initial authorization and issuance of a token by an end-user >> to a particular client, and subsequent requests by this client to >> obtain tokens without user consent (automatic processing of >> repeated >> authorization) >> halfway down page 13, s/insures/ensures/ >> s/validates the clients/validates the client's/ >> 4. first sentence, s/this sections/this section/ >> 4.1.2 first para, the last sentence is confusing. How about: "Before >> enumerating the threats, here are some generally applicable >> countermeasures:" >> 4.2.4 2nd bullet s/could not be/can not be/ >> 4.3.3 1st bullet, capitalized phrase "Confidentiality of Requests" - I >> assume that's supposed to be a hyperlink to one of the 5.* sections? >> 4.4.1.1 last bullet, s/referee/referrer/ - also, should note that the >> referrer header may contain an Authorization code in a ?a=b style >> argument >> 4.4.1.2 first bullet, "can be employed" is inconsistent with style of >> rest of doc >> 4.4.1.3 first 2 bullets have un-labeled links. >> 4.4.1.4 1st bullet s/authentication/authenticate/ >> 4.4.1.4 2nd bullet s/mean/means/ >> 4.4.1.7 2nd bullet s/tokens/token's/ >> 4.4.1.10, 2nd para, s/requisiete/requisite/ s/embbed/embed/ >> 4.4.1.10, 3rd bullet, s/aibility/ability/ >> 4.4.1.10, toward bottom of page 30, s/e.t.c./etc./ >> 4.4.1.12 I think the href to semicomplete.com needs to be turned into >> an IETF-style reference >> 4.4.2 " since HTTP user agents do not send fragments server requests." >> What you mean to say is "Since HTTP user agents do not send the >> fragment part of URIs to HTTP servers." >> 4.4.2.2 s/browser/browser's/ >> 5.1.4.1.3 s/consider to not store/refrain from storing/ >> 5.* s/may consider to $(verb)/may consider $(verb)ing/ >> 5.1.6 Needs some sort of sentence structure >> 5.3.2 Needs some sort of sentence structure; or is this intended just >> to be a title, with 5.3.3 etc nested under it? >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth From stpeter@stpeter.im Wed Jan 25 13:26:12 2012 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 72B8121F856A; Wed, 25 Jan 2012 13:26:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.719 X-Spam-Level: X-Spam-Status: No, score=-102.719 tagged_above=-999 required=5 tests=[AWL=-0.120, 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 pThOpjE565aQ; Wed, 25 Jan 2012 13:26:11 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 9A15B21F8568; Wed, 25 Jan 2012 13:26:11 -0800 (PST) Received: from leavealone.cisco.com (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 872D740058; Wed, 25 Jan 2012 14:35:56 -0700 (MST) Message-ID: <4F207370.2010507@stpeter.im> Date: Wed, 25 Jan 2012 14:26:08 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Mike Jones References: <4E1F6AAD24975D4BA5B16804296739436638188B@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436638188B@TK5EX14MBXC284.redmond.corp.microsoft.com> X-Enigmail-Version: 1.3.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Julian Reschke , "oauth@ietf.org" , "ietf@ietf.org" , The IESG Subject: Re: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard 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, 25 Jan 2012 21:26:12 -0000 (see http://tools.ietf.org/wg/oauth/charters ) On 1/25/12 1:37 AM, Mike Jones wrote: > Eran, do I then correctly understand that you've changed your mind on > the position you took in > http://www.ietf.org/mail-archive/web/oauth/current/msg07698.html, > which was: "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 > ask this, because if I correctly understand your statement that you > agree with Julian, you are now taking the position that you are OK > with recipients being required to perform escape processing for the > scope (and other) parameters and with them being required to accept > them either as tokens or as quoted strings. > > This raises a question I'd like to ask John Bradley, William Mills, > Phil Hunt, and Justin Richter: Since all of you replied with a +1 to > Eran's original statement, are you still in agreement with it, or are > you now possibly reconsidering your position, as Eran apparently has. > I'm asking, because your messages have been part of the basis upon > which I've been taking the position as editor that the working group > consensus is that no quoting may occur. (The other reason that I > believed, as editor, that this was a consensus position is that this > syntax restriction has been present in every Bearer draft, as it was > in OAuth 2.0 draft 10, which was the basis of the first Bearer > draft.) If that's not the actual working group consensus (or it's > not anymore), it would be good to know that now. Yes, input from those (and other) OAuth WG participants would be helpful. > Finally, I'd like to respond publicly to a comment made to me in a > private note sent to me about the current discussions. In it, the > sender (an IETF "old hand") observed that it could appear from the > strength of my responses to Julian's feedback that I might be trying > to defend a particular personal view of how these issues should be > resolved. I responded to him that the irony here is that I'm not > trying to representing a personal position. Rather, I'm truly trying > to do what I believe an IETF editor is supposed to do, which is to > represent the working group's positions. And that's just what a document editor should be doing. > I'm quite open to the working group making it clear that its position > has changed with respect to Julian's comments and equally open to the > working group standing behind the text in the current draft. If the > chairs would like to help bring this issue to successful closure, I > would highly welcome their participation as well. In my role as Tech Advisor, I have reviewed the discussion threads to date. Julian has pointed out text from the specifications being worked on in the HTTPbis WG. I concur with Julian's assessment: it would cause interoperability issues for individual authentication schemes to special-case the rules about parsing of challenges and credentials. However, I think it might be acceptable (as Martin Rex suggested) for such schemes to make recommendations about the actual data that is conveyed, without special-casing the parsing rules as such (if the OAuth WG wishes to go down that path, then further discussion with the HTTPbis WG would probably be helpful so that we get the layering right and set a good example for future schemes). > Personally, I'd mostly just like to see the spec finished! I think we can all agree on that. :) Peter -- Peter Saint-Andre https://stpeter.im/ From jricher@mitre.org Thu Jan 26 06:07:46 2012 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 6DEC921F8667 for ; Thu, 26 Jan 2012 06:07:46 -0800 (PST) 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 Sy2rM8iRiIew for ; Thu, 26 Jan 2012 06:07:45 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 63B5D21F8649 for ; Thu, 26 Jan 2012 06:07:45 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id B5F8421B08C6; Thu, 26 Jan 2012 09:07:44 -0500 (EST) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 8105521B1598; Thu, 26 Jan 2012 09:07:44 -0500 (EST) Received: from [129.83.50.12] (129.83.31.51) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.1.339.1; Thu, 26 Jan 2012 09:07:44 -0500 Message-ID: <4F215DEE.6020608@mitre.org> Date: Thu, 26 Jan 2012 09:06:38 -0500 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: Eran Hammer References: <90C41DD21FB7C64BB94121FBBC2E723453AAB96544@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453AAB96544@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: multipart/alternative; boundary="------------040904020605070505090400" X-Originating-IP: [129.83.31.51] Cc: OAuth WG Subject: Re: [OAUTH-WG] AD Review of -22 (part II) 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, 26 Jan 2012 14:07:46 -0000 --------------040904020605070505090400 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit I realize that -23 is already published with the below text, but since this is a whole new section and nobody else seemed to bring it up, I wanted to make sure it wasn't missed by the WG. >> 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. > Added new 'Interoperability' section to the introduction: > > OAuth 2.0 provides a rich authorization framework with well-defined security properties. > However, as a rich and highly extensible framework with many optional components, this > specification is likely to produce a wide range of non-interoperable implementations. > In addition, this specification leaves a few required components partially or fully > undefined (e.g. client registration, authorization server capabilities, endpoint > discovery). > > This protocol was design with the clear expectation that future work will define > prescriptive profiles and extensions necessary to achieve full web-scale > interoperability. > > There is no way to sugar coat reality and hopefully by being blunt about it upfront, we will avoid a prolonged debate about the protocol's failings in that regard. > I think it's a good idea to call it out, and I don't want to "sugarcoat" it either, but the phrase "this specification is likely to produce a wide range of non-interoperable implementations" is a bit overdramatic in its tone. Instead, I think we should point to other documents that are being developed explicitly along side of this, such as at the beginning of RFC2904 (http://tools.ietf.org/html/rfc2904). I suggest text like the following instead: OAuth 2.0 provides a rich authorization framework with well-defined security properties. However, as a rich and highly extensible framework with many optional components, this specification does not seek to define all components needed for a fully interoperable deployment within this document. Instead, this specification is intended to work with complimentary documents that define token types [MAC] [Bearer], token formats [JWT] [SAML], client registration [Dynamic Reg?], endpoint discovery [XRD] [SWD], and other considerations. This protocol was designed with the clear expectation that future work will define prescriptive profiles and extensions necessary to achieve full web-scale interoperability. -- Justin --------------040904020605070505090400 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit I realize that -23 is already published with the below text, but since this is a whole new section and nobody else seemed to bring it up, I wanted to make sure it wasn't missed by the WG.

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.

Added new 'Interoperability' section to the introduction:

          OAuth 2.0 provides a rich authorization framework with well-defined security properties.
          However, as a rich and highly extensible framework with many optional components, this
          specification is likely to produce a wide range of non-interoperable implementations.
          In addition, this specification leaves a few required components partially or fully
          undefined (e.g. client registration, authorization server capabilities, endpoint
          discovery).

          This protocol was design with the clear expectation that future work will define
          prescriptive profiles and extensions necessary to achieve full web-scale
          interoperability.          

There is no way to sugar coat reality and hopefully by being blunt about it upfront, we will avoid a prolonged debate about the protocol's failings in that regard.
I think it's a good idea to call it out, and I don't want to "sugarcoat" it either, but the phrase "this specification is likely to produce a wide range of non-interoperable implementations" is a bit overdramatic in its tone. Instead, I think we should point to other documents that are being developed explicitly along side of this, such as at the beginning of RFC2904 (http://tools.ietf.org/html/rfc2904). I suggest text like the following instead:

OAuth 2.0 provides a rich authorization framework with well-defined security properties. However, as a rich and highly extensible framework with many optional components, this specification does not seek to define all components needed for a fully interoperable deployment within this document. Instead, this specification is intended to work with complimentary documents that define token types [MAC] [Bearer], token formats [JWT] [SAML], client registration [Dynamic Reg?], endpoint discovery [XRD] [SWD], and other considerations.
This protocol was designed with the clear expectation that future work will define prescriptive profiles and extensions necessary to achieve full web-scale interoperability.


 -- Justin
--------------040904020605070505090400-- From ve7jtb@ve7jtb.com Thu Jan 26 06:11:33 2012 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 5FD9121F8630 for ; Thu, 26 Jan 2012 06:11:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.521 X-Spam-Level: X-Spam-Status: No, score=-3.521 tagged_above=-999 required=5 tests=[AWL=0.077, 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 PDjZ4D1MyrmT for ; Thu, 26 Jan 2012 06:11:32 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 54FDF21F84CE for ; Thu, 26 Jan 2012 06:11:32 -0800 (PST) Received: by yenm3 with SMTP id m3so255156yen.31 for ; Thu, 26 Jan 2012 06:11:31 -0800 (PST) Received: by 10.236.177.6 with SMTP id c6mr3435075yhm.42.1327587091790; Thu, 26 Jan 2012 06:11:31 -0800 (PST) Received: from [192.168.1.210] ([190.22.77.155]) by mx.google.com with ESMTPS id d5sm11057213anm.22.2012.01.26.06.11.25 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 26 Jan 2012 06:11:30 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/signed; boundary="Apple-Mail=_5A7D3E92-07CF-4691-A297-33612F97CA85"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <4F215DEE.6020608@mitre.org> Date: Thu, 26 Jan 2012 11:11:15 -0300 Message-Id: References: <90C41DD21FB7C64BB94121FBBC2E723453AAB96544@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4F215DEE.6020608@mitre.org> To: Justin Richer X-Mailer: Apple Mail (2.1251.1) Cc: OAuth WG Subject: Re: [OAUTH-WG] AD Review of -22 (part II) 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, 26 Jan 2012 14:11:33 -0000 --Apple-Mail=_5A7D3E92-07CF-4691-A297-33612F97CA85 Content-Type: multipart/alternative; boundary="Apple-Mail=_16858E9B-AD28-4973-9BFF-945C0A753E87" --Apple-Mail=_16858E9B-AD28-4973-9BFF-945C0A753E87 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Yes Justin's rewording makes it sound less like non-interoperability is = a desired outcome. On 2012-01-26, at 11:06 AM, Justin Richer wrote: > I realize that -23 is already published with the below text, but since = this is a whole new section and nobody else seemed to bring it up, I = wanted to make sure it wasn't missed by the WG. >=20 >>> Suggested non-trivial clarifications: >>> ------------------------------------- >>>=20 >>> (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. >> Added new 'Interoperability' section to the introduction: >>=20 >> OAuth 2.0 provides a rich authorization framework with = well-defined security properties. >> However, as a rich and highly extensible framework with = many optional components, this >> specification is likely to produce a wide range of = non-interoperable implementations. >> In addition, this specification leaves a few required = components partially or fully >> undefined (e.g. client registration, authorization server = capabilities, endpoint >> discovery). >>=20 >> This protocol was design with the clear expectation that = future work will define >> prescriptive profiles and extensions necessary to achieve = full web-scale >> interoperability. =20 >>=20 >> There is no way to sugar coat reality and hopefully by being blunt = about it upfront, we will avoid a prolonged debate about the protocol's = failings in that regard. >>=20 > I think it's a good idea to call it out, and I don't want to = "sugarcoat" it either, but the phrase "this specification is likely to = produce a wide range of non-interoperable implementations" is a bit = overdramatic in its tone. Instead, I think we should point to other = documents that are being developed explicitly along side of this, such = as at the beginning of RFC2904 (http://tools.ietf.org/html/rfc2904). I = suggest text like the following instead: >=20 > OAuth 2.0 provides a rich authorization framework with well-defined = security properties. However, as a rich and highly extensible framework = with many optional components, this specification does not seek to = define all components needed for a fully interoperable deployment within = this document. Instead, this specification is intended to work with = complimentary documents that define token types [MAC] [Bearer], token = formats [JWT] [SAML], client registration [Dynamic Reg?], endpoint = discovery [XRD] [SWD], and other considerations. > This protocol was designed with the clear expectation that future work = will define prescriptive profiles and extensions necessary to achieve = full web-scale interoperability. >=20 >=20 > -- Justin > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_16858E9B-AD28-4973-9BFF-945C0A753E87 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1 Yes Justin's rewording makes it sound less like non-interoperability is a desired outcome.


On 2012-01-26, at 11:06 AM, Justin Richer wrote:

I realize that -23 is already published with the below text, but since this is a whole new section and nobody else seemed to bring it up, I wanted to make sure it wasn't missed by the WG.

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.

Added new 'Interoperability' section to the introduction:

          OAuth 2.0 provides a rich authorization framework with well-defined security properties.
          However, as a rich and highly extensible framework with many optional components, this
          specification is likely to produce a wide range of non-interoperable implementations.
          In addition, this specification leaves a few required components partially or fully
          undefined (e.g. client registration, authorization server capabilities, endpoint
          discovery).

          This protocol was design with the clear expectation that future work will define
          prescriptive profiles and extensions necessary to achieve full web-scale
          interoperability.          

There is no way to sugar coat reality and hopefully by being blunt about it upfront, we will avoid a prolonged debate about the protocol's failings in that regard.
I think it's a good idea to call it out, and I don't want to "sugarcoat" it either, but the phrase "this specification is likely to produce a wide range of non-interoperable implementations" is a bit overdramatic in its tone. Instead, I think we should point to other documents that are being developed explicitly along side of this, such as at the beginning of RFC2904 (http://tools.ietf.org/html/rfc2904). I suggest text like the following instead:

OAuth 2.0 provides a rich authorization framework with well-defined security properties. However, as a rich and highly extensible framework with many optional components, this specification does not seek to define all components needed for a fully interoperable deployment within this document. Instead, this specification is intended to work with complimentary documents that define token types [MAC] [Bearer], token formats [JWT] [SAML], client registration [Dynamic Reg?], endpoint discovery [XRD] [SWD], and other considerations.
This protocol was designed with the clear expectation that future work will define prescriptive profiles and extensions necessary to achieve full web-scale interoperability.


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

--Apple-Mail=_16858E9B-AD28-4973-9BFF-945C0A753E87-- --Apple-Mail=_5A7D3E92-07CF-4691-A297-33612F97CA85 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 DgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjAx MjYxNDExMTVaMCMGCSqGSIb3DQEJBDEWBBSLsl/z5luCPjY9+kfq4zCGuJKgmzCBpAYJKwYBBAGC NxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgZDMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzANBgkqhkiG9w0BAQEFAASC AQCzHhuKWEcLKjk8VlJubpP019nN1Qh7iCyqhMpgfgQBEgdbMwHI44B8hEK/kUFmBWozj1Z+mjoN fhLoipPGE+epw4Mvi860EuPJcuewTNmjgsuRVBFaaPldptbnbkT5HBg83oOoMz6IoZZWcK5w2+vY BCpCUYJZkZp8FUJOMQmNBgtzY8zE2pcqT/n3kRNn55peXV/SyudMC3yytfUFV7x77rHFTbiS1Aae yeeuSEjT1huZsrqh2DMy7ubwGjNFsT0H684Nfna4NijjWYIqUjUWormGbRstioaGrzgtUqTOKLCJ NGIx9V7RuVXfX1uFGSHNYvy578L7Gry7zp1vr8bAAAAAAAAA --Apple-Mail=_5A7D3E92-07CF-4691-A297-33612F97CA85-- From eran@hueniverse.com Thu Jan 26 09:50:05 2012 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 B0D2421F86C5 for ; Thu, 26 Jan 2012 09:50:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.488 X-Spam-Level: X-Spam-Status: No, score=-2.488 tagged_above=-999 required=5 tests=[AWL=0.111, 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 NqO3AouHWwYk for ; Thu, 26 Jan 2012 09:50:05 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id DFE3B21F86C3 for ; Thu, 26 Jan 2012 09:50:04 -0800 (PST) Received: (qmail 14586 invoked from network); 26 Jan 2012 17:49:56 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.46) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 26 Jan 2012 17:49:55 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT004.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Thu, 26 Jan 2012 10:49:54 -0700 From: Eran Hammer To: Justin Richer Date: Thu, 26 Jan 2012 10:49:44 -0700 Thread-Topic: [OAUTH-WG] AD Review of -22 (part II) Thread-Index: AczcM+Pw8LQB8XjcRf2yEXiu/gaxegAF4yzA Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453AAB969E8@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723453AAB96544@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4F215DEE.6020608@mitre.org> In-Reply-To: <4F215DEE.6020608@mitre.org> 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] AD Review of -22 (part II) 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, 26 Jan 2012 17:50:05 -0000 > -----Original Message----- > From: Justin Richer [mailto:jricher@mitre.org] > Sent: Thursday, January 26, 2012 6:07 AM > To: Eran Hammer > Cc: OAuth WG > Subject: Re: [OAUTH-WG] AD Review of -22 (part II) >=20 > I realize that -23 is already published with the below text, but since th= is is a > whole new section and nobody else seemed to bring it up, I wanted to make > sure it wasn't missed by the WG. > I think it's a good idea to call it out, and I don't want to "sugarcoat" = it either, > but the phrase "this specification is likely to produce a wide range of n= on- > interoperable implementations" is a bit overdramatic in its tone. Instead= , I > think we should point to other documents that are being developed explici= tly > along side of this, such as at the beginning of RFC2904 > (http://tools.ietf.org/html/rfc2904). I suggest text like the following i= nstead: > > OAuth 2.0 provides a rich authorization framework with well-defined secur= ity > properties. However, as a rich and highly extensible framework with many > optional components, this specification does not seek to define all > components needed for a fully interoperable deployment within this > document. Instead, this specification is intended to work with compliment= ary > documents that define token types [MAC] [Bearer], token formats [JWT] > [SAML], client registration [Dynamic Reg?], endpoint discovery [XRD] [SWD= ], > and other considerations. > This protocol was designed with the clear expectation that future work wi= ll > define prescriptive profiles and extensions necessary to achieve full web= - > scale interoperability. This does sugarcoat the fact that 2.0 does not provide *any* guaranteed int= eroperability. The implementations I've seen so far have simply adopted a *= profile* of this document along with bearer tokens. We've already seen feed= back on this list where client developers were surprised and frustrated wit= h such implementations when trying to reuse code across providers and this = is only going to get more noticeable. And then of course we have the insane= complexity of the over-architected solutions, adding layer after layer to = solve problems that are as simple as making a parameter required and well s= pecified. We've also seen questions about providers looking to claim OAuth 2.0 suppor= t while maintaining all their existing architecture and security properties= , seeking to push the boundaries of what is permitted by the specification.= We've gone to a place where *anything* can be made to look like OAuth. We'= ve seen implementations doing nothing but exchanging SAML assertions for JS= ON-formatted assertions (or other SAML assertions), without any actual reso= urce owner participation, calling itself OAuth. And sadly, it can. I'm against adding such a laundry list of references. I am also opposed to = implying that using these extensions will achieve interoperability because = they will not in their current state. The only way to achieve interoperabil= ity at this point is by getting rid of most of the optional components (rem= oved or made required), and tightening the definition of others. Or alterna= tively, come out with a full blown discovery and negotiation protocol - som= ething that would be extremely premature at this point. How can you design = a good discovery/negotiation protocol before you have even a partial pictur= e of what it is you want to discovery/negotiate. Instead, I proposing a small tweak (marked with [[ ]]) to the language: --- 1.7. Interoperability OAuth 2.0 provides a rich authorization framework with well-defined security properties. However, as a rich and highly extensible framework with many optional components, [[ on its own, ]] this specific= ation is likely to produce a wide range of non-interoperable implementations. In addition, this specification leaves a few required components partially or fully undefined (e.g. client registration, authorization server capabilities, endpoint discovery). This protocol was designed with the clear expectation that future work will define prescriptive profiles and extensions necessary to achieve full web-scale interoperability. --- I can appreciate feeling a little sting from such a disclaimer but we all d= eserve it for failing to do our job. We took on a successful, simple, narro= w, and useful protocol and turned it into mush because after more than 2 ye= ars we have failed to find common ground on almost anything that is require= d to achieve interoperability. Instead we now rely on popular providers suc= h as Facebook and Twitter to set the tone for the rest of the industry, fil= ling in the gaps. My personal frustration is from the fact that a significant number of worki= ng group members put the interest of their corporate overlord above what is= good for the web. They have aggressively promoted an agenda based on produ= ct lines already in advance stages of development and refused to compromise= if that meant making changes to their products. We have produced the close= st heir to WS-* I've seen in many years, and that's nothing to be proud of. The result is pretty obvious: claiming OAuth 2.0 support or even compliance= is meaningless. It's the difference between dancing the tango and dancing = to rock music. One gives you a beautifully synced performance while the oth= er put personal expression on a pedestal. Which one do you think is better = for a web protocol? It's time to own the results of our work and to clearly state that this is = the best we were able to produce, and let the industry take over and solve = through running code the problems we were too fragmented to solve here. EHL From phil.hunt@oracle.com Thu Jan 26 10:15:54 2012 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 EAB4021F86EB for ; Thu, 26 Jan 2012 10:15:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.25 X-Spam-Level: X-Spam-Status: No, score=-8.25 tagged_above=-999 required=5 tests=[AWL=2.349, 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 lNzGHeeXv09k for ; Thu, 26 Jan 2012 10:15:53 -0800 (PST) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id C0D7921F86E2 for ; Thu, 26 Jan 2012 10:15:53 -0800 (PST) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q0QIFoKJ024471 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 26 Jan 2012 18:15:51 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q0QIFn5I004389 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Jan 2012 18:15:50 GMT Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q0QIFncA027664; Thu, 26 Jan 2012 12:15:49 -0600 Received: from [192.168.1.8] (/24.87.204.3) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 26 Jan 2012 10:15:49 -0800 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Phil Hunt In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453AAB969E8@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 26 Jan 2012 10:15:51 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <229C3AF7-931C-42F2-B44C-4E8593CE977C@oracle.com> References: <90C41DD21FB7C64BB94121FBBC2E723453AAB96544@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4F215DEE.6020608@mitre.org> <90C41DD21FB7C64BB94121FBBC2E723453AAB969E8@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer X-Mailer: Apple Mail (2.1251.1) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-CT-RefId: str=0001.0A090208.4F219858.003D,ss=1,re=0.000,fgs=0 Cc: OAuth WG Subject: Re: [OAUTH-WG] AD Review of -22 (part II) 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, 26 Jan 2012 18:15:55 -0000 If an app developer writes their own client, than their OAuth code = becomes bound in with the code connecting to the underlying resource API = which may or may not be standardized. Regardless the tight coupling of = OAuth plus an API can only be inter-operable in that specific = combination. This will be mitigated through the eventual emergence of client toolkits = which keep the resource API and the authorization API cleanly separated. = This may lead to further specs and refinements to OAuth2 down the road. = But we don't have enough data for that today. IMHO I think for RESTful services, fuzzy interoperability is the nature = of the technology for now because of its other benefits. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-01-26, at 9:49 AM, Eran Hammer wrote: >=20 >=20 >> -----Original Message----- >> From: Justin Richer [mailto:jricher@mitre.org] >> Sent: Thursday, January 26, 2012 6:07 AM >> To: Eran Hammer >> Cc: OAuth WG >> Subject: Re: [OAUTH-WG] AD Review of -22 (part II) >>=20 >> I realize that -23 is already published with the below text, but = since this is a >> whole new section and nobody else seemed to bring it up, I wanted to = make >> sure it wasn't missed by the WG. >=20 >> I think it's a good idea to call it out, and I don't want to = "sugarcoat" it either, >> but the phrase "this specification is likely to produce a wide range = of non- >> interoperable implementations" is a bit overdramatic in its tone. = Instead, I >> think we should point to other documents that are being developed = explicitly >> along side of this, such as at the beginning of RFC2904 >> (http://tools.ietf.org/html/rfc2904). I suggest text like the = following instead: >>=20 >> OAuth 2.0 provides a rich authorization framework with well-defined = security >> properties. However, as a rich and highly extensible framework with = many >> optional components, this specification does not seek to define all >> components needed for a fully interoperable deployment within this >> document. Instead, this specification is intended to work with = complimentary >> documents that define token types [MAC] [Bearer], token formats [JWT] >> [SAML], client registration [Dynamic Reg?], endpoint discovery [XRD] = [SWD], >> and other considerations. >> This protocol was designed with the clear expectation that future = work will >> define prescriptive profiles and extensions necessary to achieve full = web- >> scale interoperability. >=20 > This does sugarcoat the fact that 2.0 does not provide *any* = guaranteed interoperability. The implementations I've seen so far have = simply adopted a *profile* of this document along with bearer tokens. = We've already seen feedback on this list where client developers were = surprised and frustrated with such implementations when trying to reuse = code across providers and this is only going to get more noticeable. And = then of course we have the insane complexity of the over-architected = solutions, adding layer after layer to solve problems that are as simple = as making a parameter required and well specified. >=20 > We've also seen questions about providers looking to claim OAuth 2.0 = support while maintaining all their existing architecture and security = properties, seeking to push the boundaries of what is permitted by the = specification. We've gone to a place where *anything* can be made to = look like OAuth. We've seen implementations doing nothing but exchanging = SAML assertions for JSON-formatted assertions (or other SAML = assertions), without any actual resource owner participation, calling = itself OAuth. And sadly, it can. >=20 > I'm against adding such a laundry list of references. I am also = opposed to implying that using these extensions will achieve = interoperability because they will not in their current state. The only = way to achieve interoperability at this point is by getting rid of most = of the optional components (removed or made required), and tightening = the definition of others. Or alternatively, come out with a full blown = discovery and negotiation protocol - something that would be extremely = premature at this point. How can you design a good discovery/negotiation = protocol before you have even a partial picture of what it is you want = to discovery/negotiate. >=20 > Instead, I proposing a small tweak (marked with [[ ]]) to the = language: >=20 > --- > 1.7. Interoperability >=20 > OAuth 2.0 provides a rich authorization framework with well-defined > security properties. However, as a rich and highly extensible > framework with many optional components, [[ on its own, ]] this = specification is likely > to produce a wide range of non-interoperable implementations. In > addition, this specification leaves a few required components > partially or fully undefined (e.g. client registration, = authorization > server capabilities, endpoint discovery). >=20 > This protocol was designed with the clear expectation that future = work > will define prescriptive profiles and extensions necessary to = achieve > full web-scale interoperability. > --- >=20 > I can appreciate feeling a little sting from such a disclaimer but we = all deserve it for failing to do our job. We took on a successful, = simple, narrow, and useful protocol and turned it into mush because = after more than 2 years we have failed to find common ground on almost = anything that is required to achieve interoperability. Instead we now = rely on popular providers such as Facebook and Twitter to set the tone = for the rest of the industry, filling in the gaps. >=20 > My personal frustration is from the fact that a significant number of = working group members put the interest of their corporate overlord above = what is good for the web. They have aggressively promoted an agenda = based on product lines already in advance stages of development and = refused to compromise if that meant making changes to their products. We = have produced the closest heir to WS-* I've seen in many years, and = that's nothing to be proud of. >=20 > The result is pretty obvious: claiming OAuth 2.0 support or even = compliance is meaningless. It's the difference between dancing the tango = and dancing to rock music. One gives you a beautifully synced = performance while the other put personal expression on a pedestal. Which = one do you think is better for a web protocol? >=20 > It's time to own the results of our work and to clearly state that = this is the best we were able to produce, and let the industry take over = and solve through running code the problems we were too fragmented to = solve here. >=20 > EHL >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From jricher@mitre.org Thu Jan 26 13:22:16 2012 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 4A45921F85C3 for ; Thu, 26 Jan 2012 13:22:16 -0800 (PST) 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.000, 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 JipcZqcNI+kX for ; Thu, 26 Jan 2012 13:22:15 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2C63921F8486 for ; Thu, 26 Jan 2012 13:22:15 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 12ADD21B194E; Thu, 26 Jan 2012 16:22:14 -0500 (EST) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id EBA4321B18B9; Thu, 26 Jan 2012 16:22:13 -0500 (EST) Received: from [129.83.50.12] (129.83.31.51) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.1.339.1; Thu, 26 Jan 2012 16:22:13 -0500 Message-ID: <4F21C3C4.7060607@mitre.org> Date: Thu, 26 Jan 2012 16:21:08 -0500 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: Eran Hammer References: <90C41DD21FB7C64BB94121FBBC2E723453AAB96544@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4F215DEE.6020608@mitre.org> <90C41DD21FB7C64BB94121FBBC2E723453AAB969E8@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453AAB969E8@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [129.83.31.51] Cc: OAuth WG Subject: Re: [OAUTH-WG] AD Review of -22 (part II) 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, 26 Jan 2012 21:22:16 -0000 I really don't see it this way, as a failure. Instead, I think we've managed to successfully scope the document to address important practices and bits of the protocol that will work in tandem with other documents to solve different use cases. One of the biggest problems that we saw coming in from OAuth1.0 was that it tried to be all things to all people all at once, which also didn't help interoperability. I think that what we have is a more composable UNIXy approach here. Namely, OAuth 2 core/framework/whatever does one thing and does it well: it outlines a standard means and structure for getting a token. Does that help you use the token against a web service, do service discovery, pack information into the token itself? No, but it wasn't meant to. It was meant to leave enough space for other docs to take care of that. But I do not think that it's gone so far as to leave a morass of unusable components, much in the way that WS-* did, and I don't think the comparison is a fair one. I think the separations are clean and the usage profiles are clear. By pointing developers to other specifications, most of which are products of this very working group or members of this working group under other umbrellas, we *can* provide a wider view of the world. At the absolute least, I think it needs to point to the two token type docs, and I'd suggest at least keeping the two token format docs as well. And as was pointed out by Phil Hunt, this notion of loosely coupled specs and components is actually *beneficial* to today's web environment. This is another way that this work differs from WS-*: if you're doing one part of WS-*, you're not going to get away without doing the rest of it too if you want to have a working system. As you point out, and somewhat lament, this is not the case with OAuth 2. You can do some parts, and not others, and utalize just the bits that you need. The fact that I can use the same endpoints and mechanisms for user-delegated auth and machine-directed auth is very powerful, and the fact that I can use the same exact client libraries to fetch and use both random-hex tokens and signed JWTs is equally powerful. The fact that I can reuse 90% of that code and also get signed MAC tokens is likewise powerful. Thus, I stand by my originally-suggested text and respectfully submit it to the editor and working group for consideration of inclusion in this section. -- Justin On 01/26/2012 12:49 PM, Eran Hammer wrote: > >> -----Original Message----- >> From: Justin Richer [mailto:jricher@mitre.org] >> Sent: Thursday, January 26, 2012 6:07 AM >> To: Eran Hammer >> Cc: OAuth WG >> Subject: Re: [OAUTH-WG] AD Review of -22 (part II) >> >> I realize that -23 is already published with the below text, but since this is a >> whole new section and nobody else seemed to bring it up, I wanted to make >> sure it wasn't missed by the WG. >> I think it's a good idea to call it out, and I don't want to "sugarcoat" it either, >> but the phrase "this specification is likely to produce a wide range of non- >> interoperable implementations" is a bit overdramatic in its tone. Instead, I >> think we should point to other documents that are being developed explicitly >> along side of this, such as at the beginning of RFC2904 >> (http://tools.ietf.org/html/rfc2904). I suggest text like the following instead: >> >> OAuth 2.0 provides a rich authorization framework with well-defined security >> properties. However, as a rich and highly extensible framework with many >> optional components, this specification does not seek to define all >> components needed for a fully interoperable deployment within this >> document. Instead, this specification is intended to work with complimentary >> documents that define token types [MAC] [Bearer], token formats [JWT] >> [SAML], client registration [Dynamic Reg?], endpoint discovery [XRD] [SWD], >> and other considerations. >> This protocol was designed with the clear expectation that future work will >> define prescriptive profiles and extensions necessary to achieve full web- >> scale interoperability. > This does sugarcoat the fact that 2.0 does not provide *any* guaranteed interoperability. The implementations I've seen so far have simply adopted a *profile* of this document along with bearer tokens. We've already seen feedback on this list where client developers were surprised and frustrated with such implementations when trying to reuse code across providers and this is only going to get more noticeable. And then of course we have the insane complexity of the over-architected solutions, adding layer after layer to solve problems that are as simple as making a parameter required and well specified. > > We've also seen questions about providers looking to claim OAuth 2.0 support while maintaining all their existing architecture and security properties, seeking to push the boundaries of what is permitted by the specification. We've gone to a place where *anything* can be made to look like OAuth. We've seen implementations doing nothing but exchanging SAML assertions for JSON-formatted assertions (or other SAML assertions), without any actual resource owner participation, calling itself OAuth. And sadly, it can. > > I'm against adding such a laundry list of references. I am also opposed to implying that using these extensions will achieve interoperability because they will not in their current state. The only way to achieve interoperability at this point is by getting rid of most of the optional components (removed or made required), and tightening the definition of others. Or alternatively, come out with a full blown discovery and negotiation protocol - something that would be extremely premature at this point. How can you design a good discovery/negotiation protocol before you have even a partial picture of what it is you want to discovery/negotiate. > > Instead, I proposing a small tweak (marked with [[ ]]) to the language: > > --- > 1.7. Interoperability > > OAuth 2.0 provides a rich authorization framework with well-defined > security properties. However, as a rich and highly extensible > framework with many optional components, [[ on its own, ]] this specification is likely > to produce a wide range of non-interoperable implementations. In > addition, this specification leaves a few required components > partially or fully undefined (e.g. client registration, authorization > server capabilities, endpoint discovery). > > This protocol was designed with the clear expectation that future work > will define prescriptive profiles and extensions necessary to achieve > full web-scale interoperability. > --- > > I can appreciate feeling a little sting from such a disclaimer but we all deserve it for failing to do our job. We took on a successful, simple, narrow, and useful protocol and turned it into mush because after more than 2 years we have failed to find common ground on almost anything that is required to achieve interoperability. Instead we now rely on popular providers such as Facebook and Twitter to set the tone for the rest of the industry, filling in the gaps. > > My personal frustration is from the fact that a significant number of working group members put the interest of their corporate overlord above what is good for the web. They have aggressively promoted an agenda based on product lines already in advance stages of development and refused to compromise if that meant making changes to their products. We have produced the closest heir to WS-* I've seen in many years, and that's nothing to be proud of. > > The result is pretty obvious: claiming OAuth 2.0 support or even compliance is meaningless. It's the difference between dancing the tango and dancing to rock music. One gives you a beautifully synced performance while the other put personal expression on a pedestal. Which one do you think is better for a web protocol? > > It's time to own the results of our work and to clearly state that this is the best we were able to produce, and let the industry take over and solve through running code the problems we were too fragmented to solve here. > > EHL > > > > > > > > > From eran@hueniverse.com Thu Jan 26 14:16:55 2012 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 DBE4221F8663 for ; Thu, 26 Jan 2012 14:16:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108, 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 NmoBdlzq-YPN for ; Thu, 26 Jan 2012 14:16:54 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 69AF921F85E0 for ; Thu, 26 Jan 2012 14:16:54 -0800 (PST) Received: (qmail 28659 invoked from network); 26 Jan 2012 22:13:03 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.46) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 26 Jan 2012 22:13:02 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT004.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Thu, 26 Jan 2012 15:12:47 -0700 From: Eran Hammer To: Justin Richer Date: Thu, 26 Jan 2012 15:12:44 -0700 Thread-Topic: [OAUTH-WG] AD Review of -22 (part II) Thread-Index: Aczcd6LFxrbFUD1SSmmYLTf9LQ8B6g== Message-ID: In-Reply-To: <4F21C3C4.7060607@mitre.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 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] AD Review of -22 (part II) 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, 26 Jan 2012 22:16:56 -0000 The specification already has informative references to the two token types. From purely practical standpoint, I am not adding any more references because that creates more dependencies and longer wait time. There is nothing factually incorrect about the current text. It already makes it clear that additional work is required and expected. It is also a fact that it will produce a wide range an non-interoperable implementations unlike, say, HTTP. We have to make this clear to the reader upfront because every reader outside this WG has exactly the opposite expectation, especially coming from 1.0. I'll make the small tweak proposed below before this goes to the RFC editor, but am not making any other changes to the text unless you can show it is factually incorrect or incomplete. EHL On 1/26/12 1:21 PM, "Justin Richer" wrote: >I really don't see it this way, as a failure. Instead, I think we've >managed to successfully scope the document to address important >practices and bits of the protocol that will work in tandem with other >documents to solve different use cases. One of the biggest problems that >we saw coming in from OAuth1.0 was that it tried to be all things to all >people all at once, which also didn't help interoperability. I think >that what we have is a more composable UNIXy approach here. Namely, >OAuth 2 core/framework/whatever does one thing and does it well: it >outlines a standard means and structure for getting a token. Does that >help you use the token against a web service, do service discovery, pack >information into the token itself? No, but it wasn't meant to. It was >meant to leave enough space for other docs to take care of that. > >But I do not think that it's gone so far as to leave a morass of >unusable components, much in the way that WS-* did, and I don't think >the comparison is a fair one. I think the separations are clean and the >usage profiles are clear. > >By pointing developers to other specifications, most of which are >products of this very working group or members of this working group >under other umbrellas, we *can* provide a wider view of the world. At >the absolute least, I think it needs to point to the two token type >docs, and I'd suggest at least keeping the two token format docs as >well. And as was pointed out by Phil Hunt, this notion of loosely >coupled specs and components is actually *beneficial* to today's web >environment. This is another way that this work differs from WS-*: if >you're doing one part of WS-*, you're not going to get away without >doing the rest of it too if you want to have a working system. As you >point out, and somewhat lament, this is not the case with OAuth 2. You >can do some parts, and not others, and utalize just the bits that you >need. The fact that I can use the same endpoints and mechanisms for >user-delegated auth and machine-directed auth is very powerful, and the >fact that I can use the same exact client libraries to fetch and use >both random-hex tokens and signed JWTs is equally powerful. The fact >that I can reuse 90% of that code and also get signed MAC tokens is >likewise powerful. > >Thus, I stand by my originally-suggested text and respectfully submit it >to the editor and working group for consideration of inclusion in this >section. > > -- Justin > >On 01/26/2012 12:49 PM, Eran Hammer wrote: >> >>> -----Original Message----- >>> From: Justin Richer [mailto:jricher@mitre.org] >>> Sent: Thursday, January 26, 2012 6:07 AM >>> To: Eran Hammer >>> Cc: OAuth WG >>> Subject: Re: [OAUTH-WG] AD Review of -22 (part II) >>> >>> I realize that -23 is already published with the below text, but since >>>this is a >>> whole new section and nobody else seemed to bring it up, I wanted to >>>make >>> sure it wasn't missed by the WG. >>> I think it's a good idea to call it out, and I don't want to >>>"sugarcoat" it either, >>> but the phrase "this specification is likely to produce a wide range >>>of non- >>> interoperable implementations" is a bit overdramatic in its tone. >>>Instead, I >>> think we should point to other documents that are being developed >>>explicitly >>> along side of this, such as at the beginning of RFC2904 >>> (http://tools.ietf.org/html/rfc2904). I suggest text like the >>>following instead: >>> >>> OAuth 2.0 provides a rich authorization framework with well-defined >>>security >>> properties. However, as a rich and highly extensible framework with >>>many >>> optional components, this specification does not seek to define all >>> components needed for a fully interoperable deployment within this >>> document. Instead, this specification is intended to work with >>>complimentary >>> documents that define token types [MAC] [Bearer], token formats [JWT] >>> [SAML], client registration [Dynamic Reg?], endpoint discovery [XRD] >>>[SWD], >>> and other considerations. >>> This protocol was designed with the clear expectation that future work >>>will >>> define prescriptive profiles and extensions necessary to achieve full >>>web- >>> scale interoperability. >> This does sugarcoat the fact that 2.0 does not provide *any* guaranteed >>interoperability. The implementations I've seen so far have simply >>adopted a *profile* of this document along with bearer tokens. We've >>already seen feedback on this list where client developers were >>surprised and frustrated with such implementations when trying to reuse >>code across providers and this is only going to get more noticeable. And >>then of course we have the insane complexity of the over-architected >>solutions, adding layer after layer to solve problems that are as simple >>as making a parameter required and well specified. >> >> We've also seen questions about providers looking to claim OAuth 2.0 >>support while maintaining all their existing architecture and security >>properties, seeking to push the boundaries of what is permitted by the >>specification. We've gone to a place where *anything* can be made to >>look like OAuth. We've seen implementations doing nothing but exchanging >>SAML assertions for JSON-formatted assertions (or other SAML >>assertions), without any actual resource owner participation, calling >>itself OAuth. And sadly, it can. >> >> I'm against adding such a laundry list of references. I am also opposed >>to implying that using these extensions will achieve interoperability >>because they will not in their current state. The only way to achieve >>interoperability at this point is by getting rid of most of the optional >>components (removed or made required), and tightening the definition of >>others. Or alternatively, come out with a full blown discovery and >>negotiation protocol - something that would be extremely premature at >>this point. How can you design a good discovery/negotiation protocol >>before you have even a partial picture of what it is you want to >>discovery/negotiate. >> >> Instead, I proposing a small tweak (marked with [[ ]]) to the language: >> >> --- >> 1.7. Interoperability >> >> OAuth 2.0 provides a rich authorization framework with well-defined >> security properties. However, as a rich and highly extensible >> framework with many optional components, [[ on its own, ]] this >>specification is likely >> to produce a wide range of non-interoperable implementations. In >> addition, this specification leaves a few required components >> partially or fully undefined (e.g. client registration, >>authorization >> server capabilities, endpoint discovery). >> >> This protocol was designed with the clear expectation that future >>work >> will define prescriptive profiles and extensions necessary to >>achieve >> full web-scale interoperability. >> --- >> >> I can appreciate feeling a little sting from such a disclaimer but we >>all deserve it for failing to do our job. We took on a successful, >>simple, narrow, and useful protocol and turned it into mush because >>after more than 2 years we have failed to find common ground on almost >>anything that is required to achieve interoperability. Instead we now >>rely on popular providers such as Facebook and Twitter to set the tone >>for the rest of the industry, filling in the gaps. >> >> My personal frustration is from the fact that a significant number of >>working group members put the interest of their corporate overlord above >>what is good for the web. They have aggressively promoted an agenda >>based on product lines already in advance stages of development and >>refused to compromise if that meant making changes to their products. We >>have produced the closest heir to WS-* I've seen in many years, and >>that's nothing to be proud of. >> >> The result is pretty obvious: claiming OAuth 2.0 support or even >>compliance is meaningless. It's the difference between dancing the tango >>and dancing to rock music. One gives you a beautifully synced >>performance while the other put personal expression on a pedestal. Which >>one do you think is better for a web protocol? >> >> It's time to own the results of our work and to clearly state that this >>is the best we were able to produce, and let the industry take over and >>solve through running code the problems we were too fragmented to solve >>here. >> >> EHL >> >> >> >> >> >> >> >> >> > From security.developer22@gmail.com Sun Jan 29 03:25:14 2012 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 4BDA221F851C for ; Sun, 29 Jan 2012 03:25:14 -0800 (PST) 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 03KTgyd18FaM for ; Sun, 29 Jan 2012 03:25:13 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 83B6C21F850C for ; Sun, 29 Jan 2012 03:25:13 -0800 (PST) Received: by ghbg16 with SMTP id g16so1535752ghb.31 for ; Sun, 29 Jan 2012 03:25:13 -0800 (PST) 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=GNAQYZHgHnTTs8vEx7oSX8A9ICA16BRwY3S+5GQ6mkc=; b=amwwplOUysbpwjG9ttz/qCXtgXND5RVz8FiQ9OI1kdgxI6tCXUudLpUNsFUY7nrOk9 cWMBXRuZ9VKHnLImYPVQwlyiYPBUGpcJvi4/obaI4BmVwCQr79SqwOREADbjmteQ7elc jslPApETUec2u9KVSverfdYHuOjqQUWE3YTQQ= MIME-Version: 1.0 Received: by 10.236.155.226 with SMTP id j62mr20099449yhk.49.1327836313169; Sun, 29 Jan 2012 03:25:13 -0800 (PST) Received: by 10.147.82.4 with HTTP; Sun, 29 Jan 2012 03:25:13 -0800 (PST) Date: Sun, 29 Jan 2012 16:25:13 +0500 Message-ID: From: Security Developer To: OAuth@ietf.org Content-Type: multipart/alternative; boundary=20cf303b3c87c4302b04b7a8fbb8 Subject: [OAUTH-WG] Question related Implicit Grant Type 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, 29 Jan 2012 11:25:14 -0000 --20cf303b3c87c4302b04b7a8fbb8 Content-Type: text/plain; charset=ISO-8859-1 Hi, My question is, why web hosted resource is needed to extract the access token? Thanks for your time. --20cf303b3c87c4302b04b7a8fbb8 Content-Type: text/html; charset=ISO-8859-1 Hi,

My question is, why web hosted resource is needed to extract the access token?

Thanks for your time.
--20cf303b3c87c4302b04b7a8fbb8-- From agksmehx@gmail.com Sun Jan 29 04:19:49 2012 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 1672F21F8540 for ; Sun, 29 Jan 2012 04:19:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.409 X-Spam-Level: X-Spam-Status: No, score=-3.409 tagged_above=-999 required=5 tests=[AWL=0.189, 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 eNcR-r11apaV for ; Sun, 29 Jan 2012 04:19:47 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3765A21F852E for ; Sun, 29 Jan 2012 04:19:47 -0800 (PST) Received: by ggnq4 with SMTP id q4so1659724ggn.31 for ; Sun, 29 Jan 2012 04:19:46 -0800 (PST) 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 :content-type; bh=gaNwb0Z2A0wifBdOKXYgzME4BeDkNLV3w+2J1AQtrGc=; b=LmrNvQibrB4DxisPDkInzGuFOaP3XAoJ3wve8ZKgNqiV/eEDuCFz776VgNHVwOZpZG rDf7y3YjG873E4nY/0YQl3qJgGrs/BnOGFCAV0ui893PX8d9+FDoTZfoFqC1A18D7TpP 2VjAzt+sKdzfBWzrHyfQmDp+3baAj/f87Pg+4= MIME-Version: 1.0 Received: by 10.236.173.37 with SMTP id u25mr20287463yhl.26.1327839586807; Sun, 29 Jan 2012 04:19:46 -0800 (PST) Received: by 10.236.154.73 with HTTP; Sun, 29 Jan 2012 04:19:46 -0800 (PST) In-Reply-To: References: <4F21C3C4.7060607@mitre.org> Date: Sun, 29 Jan 2012 19:19:46 +0700 Message-ID: From: agks mehx To: Eran Hammer , oauth@ietf.org Content-Type: multipart/alternative; boundary=20cf305e2635e3eeef04b7a9bebb Subject: Re: [OAUTH-WG] AD Review of -22 (part II) 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, 29 Jan 2012 12:19:49 -0000 --20cf305e2635e3eeef04b7a9bebb Content-Type: text/plain; charset=ISO-8859-1 I would be unhappy if things were sugarcoated any further. This is definitely a rare specification where OPTIONAL parameters in the API can be REQUIRED by a conforming implmentation (as I discussed in my note on the scope parameter for which the proposed modification does not really change much) I appreciate that there is a cautionary statement that this specification may produce non-interoperable client / server implementations, as I discovered upon writing my first client. The cautionary statement would be invaluable to programmers in the wild who are not used to the unusual semantics of this particular specification. Hence I strongly support (if it counts) keeping the language the way Eran Hammer has suggested. On Fri, Jan 27, 2012 at 5:12 AM, Eran Hammer wrote: > The specification already has informative references to the two token > types. From purely practical standpoint, I am not adding any more > references because that creates more dependencies and longer wait time. > > There is nothing factually incorrect about the current text. It already > makes it clear that additional work is required and expected. It is also a > fact that it will produce a wide range an non-interoperable > implementations unlike, say, HTTP. We have to make this clear to the > reader upfront because every reader outside this WG has exactly the > opposite expectation, especially coming from 1.0. > > I'll make the small tweak proposed below before this goes to the RFC > editor, but am not making any other changes to the text unless you can > show it is factually incorrect or incomplete. > > EHL > > > > On 1/26/12 1:21 PM, "Justin Richer" wrote: > > >I really don't see it this way, as a failure. Instead, I think we've > >managed to successfully scope the document to address important > >practices and bits of the protocol that will work in tandem with other > >documents to solve different use cases. One of the biggest problems that > >we saw coming in from OAuth1.0 was that it tried to be all things to all > >people all at once, which also didn't help interoperability. I think > >that what we have is a more composable UNIXy approach here. Namely, > >OAuth 2 core/framework/whatever does one thing and does it well: it > >outlines a standard means and structure for getting a token. Does that > >help you use the token against a web service, do service discovery, pack > >information into the token itself? No, but it wasn't meant to. It was > >meant to leave enough space for other docs to take care of that. > > > >But I do not think that it's gone so far as to leave a morass of > >unusable components, much in the way that WS-* did, and I don't think > >the comparison is a fair one. I think the separations are clean and the > >usage profiles are clear. > > > >By pointing developers to other specifications, most of which are > >products of this very working group or members of this working group > >under other umbrellas, we *can* provide a wider view of the world. At > >the absolute least, I think it needs to point to the two token type > >docs, and I'd suggest at least keeping the two token format docs as > >well. And as was pointed out by Phil Hunt, this notion of loosely > >coupled specs and components is actually *beneficial* to today's web > >environment. This is another way that this work differs from WS-*: if > >you're doing one part of WS-*, you're not going to get away without > >doing the rest of it too if you want to have a working system. As you > >point out, and somewhat lament, this is not the case with OAuth 2. You > >can do some parts, and not others, and utalize just the bits that you > >need. The fact that I can use the same endpoints and mechanisms for > >user-delegated auth and machine-directed auth is very powerful, and the > >fact that I can use the same exact client libraries to fetch and use > >both random-hex tokens and signed JWTs is equally powerful. The fact > >that I can reuse 90% of that code and also get signed MAC tokens is > >likewise powerful. > > > >Thus, I stand by my originally-suggested text and respectfully submit it > >to the editor and working group for consideration of inclusion in this > >section. > > > > -- Justin > > > >On 01/26/2012 12:49 PM, Eran Hammer wrote: > >> > >>> -----Original Message----- > >>> From: Justin Richer [mailto:jricher@mitre.org] > >>> Sent: Thursday, January 26, 2012 6:07 AM > >>> To: Eran Hammer > >>> Cc: OAuth WG > >>> Subject: Re: [OAUTH-WG] AD Review of -22 (part II) > >>> > >>> I realize that -23 is already published with the below text, but since > >>>this is a > >>> whole new section and nobody else seemed to bring it up, I wanted to > >>>make > >>> sure it wasn't missed by the WG. > >>> I think it's a good idea to call it out, and I don't want to > >>>"sugarcoat" it either, > >>> but the phrase "this specification is likely to produce a wide range > >>>of non- > >>> interoperable implementations" is a bit overdramatic in its tone. > >>>Instead, I > >>> think we should point to other documents that are being developed > >>>explicitly > >>> along side of this, such as at the beginning of RFC2904 > >>> (http://tools.ietf.org/html/rfc2904). I suggest text like the > >>>following instead: > >>> > >>> OAuth 2.0 provides a rich authorization framework with well-defined > >>>security > >>> properties. However, as a rich and highly extensible framework with > >>>many > >>> optional components, this specification does not seek to define all > >>> components needed for a fully interoperable deployment within this > >>> document. Instead, this specification is intended to work with > >>>complimentary > >>> documents that define token types [MAC] [Bearer], token formats [JWT] > >>> [SAML], client registration [Dynamic Reg?], endpoint discovery [XRD] > >>>[SWD], > >>> and other considerations. > >>> This protocol was designed with the clear expectation that future work > >>>will > >>> define prescriptive profiles and extensions necessary to achieve full > >>>web- > >>> scale interoperability. > >> This does sugarcoat the fact that 2.0 does not provide *any* guaranteed > >>interoperability. The implementations I've seen so far have simply > >>adopted a *profile* of this document along with bearer tokens. We've > >>already seen feedback on this list where client developers were > >>surprised and frustrated with such implementations when trying to reuse > >>code across providers and this is only going to get more noticeable. And > >>then of course we have the insane complexity of the over-architected > >>solutions, adding layer after layer to solve problems that are as simple > >>as making a parameter required and well specified. > >> > >> We've also seen questions about providers looking to claim OAuth 2.0 > >>support while maintaining all their existing architecture and security > >>properties, seeking to push the boundaries of what is permitted by the > >>specification. We've gone to a place where *anything* can be made to > >>look like OAuth. We've seen implementations doing nothing but exchanging > >>SAML assertions for JSON-formatted assertions (or other SAML > >>assertions), without any actual resource owner participation, calling > >>itself OAuth. And sadly, it can. > >> > >> I'm against adding such a laundry list of references. I am also opposed > >>to implying that using these extensions will achieve interoperability > >>because they will not in their current state. The only way to achieve > >>interoperability at this point is by getting rid of most of the optional > >>components (removed or made required), and tightening the definition of > >>others. Or alternatively, come out with a full blown discovery and > >>negotiation protocol - something that would be extremely premature at > >>this point. How can you design a good discovery/negotiation protocol > >>before you have even a partial picture of what it is you want to > >>discovery/negotiate. > >> > >> Instead, I proposing a small tweak (marked with [[ ]]) to the language: > >> > >> --- > >> 1.7. Interoperability > >> > >> OAuth 2.0 provides a rich authorization framework with well-defined > >> security properties. However, as a rich and highly extensible > >> framework with many optional components, [[ on its own, ]] this > >>specification is likely > >> to produce a wide range of non-interoperable implementations. In > >> addition, this specification leaves a few required components > >> partially or fully undefined (e.g. client registration, > >>authorization > >> server capabilities, endpoint discovery). > >> > >> This protocol was designed with the clear expectation that future > >>work > >> will define prescriptive profiles and extensions necessary to > >>achieve > >> full web-scale interoperability. > >> --- > >> > >> I can appreciate feeling a little sting from such a disclaimer but we > >>all deserve it for failing to do our job. We took on a successful, > >>simple, narrow, and useful protocol and turned it into mush because > >>after more than 2 years we have failed to find common ground on almost > >>anything that is required to achieve interoperability. Instead we now > >>rely on popular providers such as Facebook and Twitter to set the tone > >>for the rest of the industry, filling in the gaps. > >> > >> My personal frustration is from the fact that a significant number of > >>working group members put the interest of their corporate overlord above > >>what is good for the web. They have aggressively promoted an agenda > >>based on product lines already in advance stages of development and > >>refused to compromise if that meant making changes to their products. We > >>have produced the closest heir to WS-* I've seen in many years, and > >>that's nothing to be proud of. > >> > >> The result is pretty obvious: claiming OAuth 2.0 support or even > >>compliance is meaningless. It's the difference between dancing the tango > >>and dancing to rock music. One gives you a beautifully synced > >>performance while the other put personal expression on a pedestal. Which > >>one do you think is better for a web protocol? > >> > >> It's time to own the results of our work and to clearly state that this > >>is the best we were able to produce, and let the industry take over and > >>solve through running code the problems we were too fragmented to solve > >>here. > >> > >> EHL > >> > >> > >> > >> > >> > >> > >> > >> > >> > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --20cf305e2635e3eeef04b7a9bebb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I would be unhappy if things were sugarcoated any further. =A0This is defin= itely a rare specification where OPTIONAL parameters in the API can be REQU= IRED by a conforming implmentation (as I discussed in my note on the scope = parameter for which the proposed modification does not really change much)<= div>
I appreciate that there is a cautionary statement that this = specification may produce non-interoperable client / server implementations= , as I discovered upon writing my first client.

The cautionary statement would be invaluable to programmers in the wild who= are not used to the unusual semantics of this particular specification.

Hence I strongly support (if it counts) keeping the = language the way Eran Hammer has suggested.

On Fri, Jan 27, 2012 at 5:12 AM, Eran Hammer= <eran@hueniver= se.com> wrote:
The specification already has informative references to the two token
types. From purely practical standpoint, I am not adding any more
references because that creates more dependencies and longer wait time.

There is nothing factually incorrect about the current text. It already
makes it clear that additional work is required and expected. It is also a<= br> fact that it will produce a wide range an non-interoperable
implementations unlike, say, HTTP. We have to make this clear to the
reader upfront because every reader outside this WG has exactly the
opposite expectation, especially coming from 1.0.

I'll make the small tweak proposed below before this goes to the RFC editor, but am not making any other changes to the text unless you can
show it is factually incorrect or incomplete.

EHL



On 1/26/12 1:21 PM, "Justin Richer" <jricher@mitre.org> wrote:

>I really don't see it this way, as a failure. Instead, I think we&#= 39;ve
>managed to successfully scope the document to address important
>practices and bits of the protocol that will work in tandem with other<= br> >documents to solve different use cases. One of the biggest problems tha= t
>we saw coming in from OAuth1.0 was that it tried to be all things to al= l
>people all at once, which also didn't help interoperability. I thin= k
>that what we have is a more composable UNIXy approach here. Namely,
>OAuth 2 core/framework/whatever does one thing and does it well: it
>outlines a standard means and structure for getting a token. Does that<= br> >help you use the token against a web service, do service discovery, pac= k
>information into the token itself? No, but it wasn't meant to. It w= as
>meant to leave enough space for other docs to take care of that.
>
>But I do not think that it's gone so far as to leave a morass of >unusable components, much in the way that WS-* did, and I don't thi= nk
>the comparison is a fair one. I think the separations are clean and the=
>usage profiles are clear.
>
>By pointing developers to other specifications, most of which are
>products of this very working group or members of this working group >under other umbrellas, we *can* provide a wider view of the world. At >the absolute least, I think it needs to point to the two token type
>docs, and I'd suggest at least keeping the two token format docs as=
>well. And as was pointed out by Phil Hunt, this notion of loosely
>coupled specs and components is actually *beneficial* to today's we= b
>environment. This is another way that this work differs from WS-*: if >you're doing one part of WS-*, you're not going to get away wit= hout
>doing the rest of it too if you want to have a working system. As you >point out, and somewhat lament, this is not the case with OAuth 2. You<= br> >can do some parts, and not others, and utalize just the bits that you >need. The fact that I can use the same endpoints and mechanisms for
>user-delegated auth and machine-directed auth is very powerful, and the=
>fact that I can use the same exact client libraries to fetch and use >both random-hex tokens and signed JWTs is equally powerful. The fact >that I can reuse 90% of that code and also get signed MAC tokens is
>likewise powerful.
>
>Thus, I stand by my originally-suggested text and respectfully submit i= t
>to the editor and working group for consideration of inclusion in this<= br> >section.
>
> =A0-- Justin
>
>On 01/26/2012 12:49 PM, Eran Hammer wrote:
>>
>>> -----Original Message-----
>>> From: Justin Richer [mailto:jricher@mitre.org]
>>> Sent: Thursday, January 26, 2012 6:07 AM
>>> To: Eran Hammer
>>> Cc: OAuth WG
>>> Subject: Re: [OAUTH-WG] AD Review of -22 (part II)
>>>
>>> I realize that -23 is already published with the below text, b= ut since
>>>this is a
>>> whole new section and nobody else seemed to bring it up, I wan= ted to
>>>make
>>> sure it wasn't missed by the WG.
>>> I think it's a good idea to call it out, and I don't w= ant to
>>>"sugarcoat" it either,
>>> but the phrase "this specification is likely to produce a= wide range
>>>of non-
>>> interoperable implementations" is a bit overdramatic in i= ts tone.
>>>Instead, I
>>> think we should point to other documents that are being develo= ped
>>>explicitly
>>> along side of this, such as at the beginning of RFC2904
>>> (http://tools.ietf.org/html/rfc2904). I suggest text like the
>>>following instead:
>>>
>>> OAuth 2.0 provides a rich authorization framework with well-de= fined
>>>security
>>> properties. However, as a rich and highly extensible framework= with
>>>many
>>> optional components, this specification does not seek to defin= e all
>>> components needed for a fully interoperable deployment within = this
>>> document. Instead, this specification is intended to work with=
>>>complimentary
>>> documents that define token types [MAC] [Bearer], token format= s [JWT]
>>> [SAML], client registration [Dynamic Reg?], endpoint discovery= [XRD]
>>>[SWD],
>>> and other considerations.
>>> This protocol was designed with the clear expectation that fut= ure work
>>>will
>>> define prescriptive profiles and extensions necessary to achie= ve full
>>>web-
>>> scale interoperability.
>> This does sugarcoat the fact that 2.0 does not provide *any* guara= nteed
>>interoperability. The implementations I've seen so far have sim= ply
>>adopted a *profile* of this document along with bearer tokens. We&#= 39;ve
>>already seen feedback on this list where client developers were
>>surprised and frustrated with such implementations when trying to r= euse
>>code across providers and this is only going to get more noticeable= . And
>>then of course we have the insane complexity of the over-architecte= d
>>solutions, adding layer after layer to solve problems that are as s= imple
>>as making a parameter required and well specified.
>>
>> We've also seen questions about providers looking to claim OAu= th 2.0
>>support while maintaining all their existing architecture and secur= ity
>>properties, seeking to push the boundaries of what is permitted by = the
>>specification. We've gone to a place where *anything* can be ma= de to
>>look like OAuth. We've seen implementations doing nothing but e= xchanging
>>SAML assertions for JSON-formatted assertions (or other SAML
>>assertions), without any actual resource owner participation, calli= ng
>>itself OAuth. And sadly, it can.
>>
>> I'm against adding such a laundry list of references. I am als= o opposed
>>to implying that using these extensions will achieve interoperabili= ty
>>because they will not in their current state. The only way to achie= ve
>>interoperability at this point is by getting rid of most of the opt= ional
>>components (removed or made required), and tightening the definitio= n of
>>others. Or alternatively, come out with a full blown discovery and<= br> >>negotiation protocol - something that would be extremely premature = at
>>this point. How can you design a good discovery/negotiation protoco= l
>>before you have even a partial picture of what it is you want to >>discovery/negotiate.
>>
>> Instead, I proposing a small tweak (marked with [[ ]]) to the lang= uage:
>>
>> ---
>> 1.7. =A0Interoperability
>>
>> =A0 =A0 OAuth 2.0 provides a rich authorization framework with wel= l-defined
>> =A0 =A0 security properties. =A0However, as a rich and highly exte= nsible
>> =A0 =A0 framework with many optional components, [[ on its own, ]]= this
>>specification is likely
>> =A0 =A0 to produce a wide range of non-interoperable implementatio= ns. =A0In
>> =A0 =A0 addition, this specification leaves a few required compone= nts
>> =A0 =A0 partially or fully undefined (e.g. client registration, >>authorization
>> =A0 =A0 server capabilities, endpoint discovery).
>>
>> =A0 =A0 This protocol was designed with the clear expectation that= future
>>work
>> =A0 =A0 will define prescriptive profiles and extensions necessary= to
>>achieve
>> =A0 =A0 full web-scale interoperability.
>> ---
>>
>> I can appreciate feeling a little sting from such a disclaimer but= we
>>all deserve it for failing to do our job. We took on a successful,<= br> >>simple, narrow, and useful protocol and turned it into mush because=
>>after more than 2 years we have failed to find common ground on alm= ost
>>anything that is required to achieve interoperability. Instead we n= ow
>>rely on popular providers such as Facebook and Twitter to set the t= one
>>for the rest of the industry, filling in the gaps.
>>
>> My personal frustration is from the fact that a significant number= of
>>working group members put the interest of their corporate overlord = above
>>what is good for the web. They have aggressively promoted an agenda=
>>based on product lines already in advance stages of development and=
>>refused to compromise if that meant making changes to their product= s. We
>>have produced the closest heir to WS-* I've seen in many years,= and
>>that's nothing to be proud of.
>>
>> The result is pretty obvious: claiming OAuth 2.0 support or even >>compliance is meaningless. It's the difference between dancing = the tango
>>and dancing to rock music. One gives you a beautifully synced
>>performance while the other put personal expression on a pedestal. = Which
>>one do you think is better for a web protocol?
>>
>> It's time to own the results of our work and to clearly state = that this
>>is the best we were able to produce, and let the industry take over= and
>>solve through running code the problems we were too fragmented to s= olve
>>here.
>>
>> EHL
>>
>>
>>
>>
>>
>>
>>
>>
>>
>

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

--20cf305e2635e3eeef04b7a9bebb-- From wmills@yahoo-inc.com Sun Jan 29 20:36:37 2012 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 93EF621F8528 for ; Sun, 29 Jan 2012 20:36:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.18 X-Spam-Level: X-Spam-Status: No, score=-16.18 tagged_above=-999 required=5 tests=[AWL=-1.182, 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 jvBOLmwcoD5R for ; Sun, 29 Jan 2012 20:36:36 -0800 (PST) Received: from nm14-vm0.bullet.mail.ac4.yahoo.com (nm14-vm0.bullet.mail.ac4.yahoo.com [98.139.52.234]) by ietfa.amsl.com (Postfix) with SMTP id B320321F850F for ; Sun, 29 Jan 2012 20:36:36 -0800 (PST) Received: from [98.139.52.196] by nm14.bullet.mail.ac4.yahoo.com with NNFMP; 30 Jan 2012 04:36:32 -0000 Received: from [98.139.52.165] by tm9.bullet.mail.ac4.yahoo.com with NNFMP; 30 Jan 2012 04:36:32 -0000 Received: from [127.0.0.1] by omp1048.mail.ac4.yahoo.com with NNFMP; 30 Jan 2012 04:36:32 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 665859.83395.bm@omp1048.mail.ac4.yahoo.com Received: (qmail 85542 invoked by uid 60001); 30 Jan 2012 04:36:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1327898189; bh=W/s+CjTvxAySxRK0hQqBphqdjLS2XrKR5jisJh73bic=; 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=WDiRwjYgdckWyi/Y41tsmky6qTB/K9IzfJvS6B5mqytBcgwhpfds4oSI6a+oRawAYOL7HfzCK+wIvRb2MmqpBJbxwZjZ7lxQTmygTmWf3Cs9iuCUprosprbm06GByItcTyXGpk+rmvwUPdVyrTa6wFEJaUMkAUcHN9Z0VRbK8jg= 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=m0ArCPupem7taosXvEW50umy9lKPa7vQXikWtpyAHHwGz+TgUPWU1jmqGbJdZUx4FB2z35Fex2r9JcL4TjNZrxf0RoPRRHys92hBiiztHUh2HC5G0mhqClxKWLO+MMqEiqFyhPLgxegrSfUdxk5SFCCBamJKAZqI9wzN8o73sxs=; X-YMail-OSG: E.sseZYVM1kyV7J.I3bxVLLAKcCoIUJI_4tY9i.GzWlQ85a cYQQRPjdDISFfRHTwOFHTnj_FnjklTVXm_SX8xKxcgbqf_8kF7EZswaz.gZT 9Aqw96POJQmbyPKlXeox276OkQduKwHqI5ftlH9TeujKZfp5Fn7H8Ynq9QAW 7hpRApSxpdvb8RuLKqT0pg5xpaOMZo2IqQwY7bebJwE.ysAkiNgOa3y.1Dj7 iLYOS9yVveNZ5eLBQzTkE7SBPuzM9JwpwzjoHFfosJlOSKsgFsiO.DjLi.pt LIOBd865t3dUEOzZ2nKdd12jphdg3W42K0mKusgsJM1sOiDkXtb1nD8Sb40K ZY7lPypYEig0wCKKs6w6YeFU29G5SZ6tFQVX5WqkyfbWw4BVh8R7GQeM2Z5w SDSVhQilr6pLEwpk4dS.8WRGFu_mS Received: from [99.31.212.42] by web31808.mail.mud.yahoo.com via HTTP; Sun, 29 Jan 2012 20:36:29 PST X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.116.338427 References: Message-ID: <1327898189.84945.YahooMailNeo@web31808.mail.mud.yahoo.com> Date: Sun, 29 Jan 2012 20:36:29 -0800 (PST) From: William Mills To: Security Developer , "OAuth@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="258328648-1591626533-1327898189=:84945" Subject: Re: [OAUTH-WG] Question related Implicit Grant Type 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, 30 Jan 2012 04:36:37 -0000 --258328648-1591626533-1327898189=:84945 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable There are a couple of cases where you could have a much simpler API than HT= TP, implicit is one of those.=A0 All in all though it's easier to leave eve= rything under the same rules, instead of having to define a new protocol fo= r thing like implicit.=0A=0AI think that answers your question?=0A=0A-bill= =0A=0A=0A=0A________________________________=0A From: Security Developer =0ATo: OAuth@ietf.org =0ASent: Sunday, Januar= y 29, 2012 3:25 AM=0ASubject: [OAUTH-WG] Question related Implicit Grant Ty= pe=0A =0A=0AHi,=0A=0AMy question is, why web hosted resource is needed to e= xtract the access token?=0A=0AThanks for your time.=0A=0A__________________= _____________________________=0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps= ://www.ietf.org/mailman/listinfo/oauth --258328648-1591626533-1327898189=:84945 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
There are a couple of cases where you could have a much simpler API than = HTTP, implicit is one of those.  All in all though it's easier to leav= e everything under the same rules, instead of having to define a new protoc= ol for thing like implicit.

I think that an= swers your question?

-bill
<= div>
From: Security Developer <security.developer22@gmail.c= om>
To: OAuth@ietf.= org
Sent: Sunday, January 29,= 2012 3:25 AM
Subject:= [OAUTH-WG] Question related Implicit Grant Type

=0A=
Hi,

My question is, why web hosted resourc= e is needed to extract the access token?

Thanks for your time.
= =0A

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

--258328648-1591626533-1327898189=:84945-- From Michael.Jones@microsoft.com Sun Jan 29 21:20:32 2012 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 9123921F855B; Sun, 29 Jan 2012 21:20:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.763 X-Spam-Level: X-Spam-Status: No, score=-3.763 tagged_above=-999 required=5 tests=[AWL=-0.164, 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 uWJFu+xa3LyS; Sun, 29 Jan 2012 21:20:31 -0800 (PST) Received: from DB3EHSOBE006.bigfish.com (db3ehsobe002.messaging.microsoft.com [213.199.154.140]) by ietfa.amsl.com (Postfix) with ESMTP id 3CBAF21F8470; Sun, 29 Jan 2012 21:20:24 -0800 (PST) Received: from mail35-db3-R.bigfish.com (10.3.81.234) by DB3EHSOBE006.bigfish.com (10.3.84.26) with Microsoft SMTP Server id 14.1.225.23; Mon, 30 Jan 2012 05:20:23 +0000 Received: from mail35-db3 (localhost [127.0.0.1]) by mail35-db3-R.bigfish.com (Postfix) with ESMTP id 116573C038A; Mon, 30 Jan 2012 05:20:23 +0000 (UTC) X-SpamScore: -35 X-BigFish: VS-35(zz9371I542Mc1dM111aLzz1202hzz1033IL8275dhz2fhc1bhc31hc1ah2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail35-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail35-db3 (localhost.localdomain [127.0.0.1]) by mail35-db3 (MessageSwitch) id 1327900821603647_29556; Mon, 30 Jan 2012 05:20:21 +0000 (UTC) Received: from DB3EHSMHS006.bigfish.com (unknown [10.3.81.236]) by mail35-db3.bigfish.com (Postfix) with ESMTP id 8EFD1220045; Mon, 30 Jan 2012 05:20:21 +0000 (UTC) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS006.bigfish.com (10.3.87.106) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 30 Jan 2012 05:20:20 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.12]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.02.0247.005; Sun, 29 Jan 2012 21:20:16 -0800 From: Mike Jones To: Alexey Melnikov , "oauth@ietf.org" , General Area Review Team , IETF-Discussion Discussion , "draft-ietf-oauth-v2-bearer.all@tools.ietf.org" Thread-Topic: Gen-ART review of draft-ietf-oauth-v2-bearer-15.txt Thread-Index: AQHM3qRqPCVQxATPKE+KKj7te0rjepYkPTlg Date: Mon, 30 Jan 2012 05:20:15 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436638B7AD@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <4F2575CE.9040001@isode.com> In-Reply-To: <4F2575CE.9040001@isode.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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [OAUTH-WG] Gen-ART review of draft-ietf-oauth-v2-bearer-15.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, 30 Jan 2012 05:20:32 -0000 Thanks for your useful feedback, Alexey. Below, I'll respond to each of yo= ur comments. I've also added the OAuth working group to the thread, so the= y are aware of them as well and can participate in the discussion. About your first issue with the WWW-Authenticate ABNF, I am already working= with Julian, Mark Nottingham, and the chairs to resolve this issue. Expec= t to see a proposal for review by the working group shortly. About your comments on scope: OAuth 2.0 (both the Core and Bearer specs) i= s designed to be deployed in diverse and non-interoperable application cont= exts, meeting a variety of application needs. In those various settings, w= hich are often distinct and potentially non-interoperable, parameters such = as scope, realm, etc. may have very different meanings. This is not a bug;= it is a feature, because it allows the OAuth pattern to meet the needs of = numerous, often distinct, application environments. For that reason, a reg= istry of scope (or realm) parameters would be ill-advised and counterproduc= tive. It's perfectly OK and expected for a scope value such as "email" to = have one meaning in one application context and a different meaning in a di= fferent, but distinct application context. Trying to impose a single meani= ng on particular scope values across distinct application contexts is both = unnecessary and could break many existing deployments. That being said, we= fully expect interoperability profiles to emerge that define interoperable= sets of scope values within particular application contexts. (The OpenID = Connect specifications are one such set of profiles.) But these meanings w= ill always be context-specific - not global in scope. About your first minor issue, I'll reorder the bullets so the statement abo= ut the entity-body being single part is followed by the statement about it = using application/x-www-form-urlencoded, so they will be read together. About your second minor issue on error codes, the error codes registry alre= ady exists, but is in the OAuth Core spec. See http://tools.ietf.org/html/= draft-ietf-oauth-v2-23#section-11.4. About your third minor issue on RFC 6125 versus RFC 2818, you'll find that,= per the history entries, a previous reference to RFC 2818 was changed to R= FC 6125 in draft 14 at the request of Security Area Director Stephen Farrel= l. If you'd like to see this reference reintroduced, I'd request that you = work with Stephen on specific alternative proposed wording that is acceptab= le to both of you. Finally, I'll address both of your nits in the manner you suggested. Thanks again, -- Mike -----Original Message----- From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Ale= xey Melnikov Sent: Sunday, January 29, 2012 8:38 AM To: General Area Review Team; IETF-Discussion Discussion; draft-ietf-oauth-= v2-bearer.all@tools.ietf.org Subject: Gen-ART review of draft-ietf-oauth-v2-bearer-15.txt I am the assigned Gen-ART reviewer for this draft. For background on Gen-AR= T, please see the FAQ at . Please resolve these comments along with any other Last Call comments you m= ay receive. Document: draft-ietf-oauth-v2-bearer-15.txt Reviewer: Alexey Melnikov Review Date: 29 Jan 2012 IETF LC End Date: 7 Feb 2012 IESG Telechat date: (if known) - Summary: Mostly ready, with a couple of things that should be addressed. Major Issues: I have 2 issues in section 3: 3. The WWW-Authenticate Response Header Field If the protected resource request does not include authentication credentials or does not contain an access token that enables access to the protected resource, the resource server MUST include the HTTP "WWW-Authenticate" response header field; it MAY include it in response to other conditions as well. The "WWW-Authenticate" header field uses the framework defined by HTTP/1.1, Part 7 [I-D.ietf-httpbis-p7-auth] as follows: challenge =3D "Bearer" [ 1*SP 1#param ] param =3D realm / scope / error / error-desc / error-uri / auth-param 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 1). I am agreeing with Julian about redefinition of ABNF from HTTPBis docum= ents. I believe there is a proposal to fix that but the new draft hasn't be= en posted yet. 2). My 2nd major issue is about the following paragraph: The "scope" attribute is a space-delimited list of scope values indicating the required scope of the access token for accessing the requested resource. In some cases, the "scope" value will be used when requesting a new access token with sufficient scope of access to utilize the protected resource. The "scope" attribute MUST NOT appear more than once. The "scope" value is intended for programmatic use and is not meant to be displayed to end users. I don't think this provide enough information about what this is, how it is= to be used and which values are allowed. As this is not meant to be displa= yed to end users, then you need to say what values are allowed and which en= tity can allocate them. Is there a registry for these tokens, e.g. an IANA = registry? Minor Issues: 1). 2.2. Form-Encoded Body Parameter When sending the access token in the HTTP request entity-body, the client adds the access token to the request body using the "access_token" parameter. The client MUST NOT use this method unless all of the following conditions are met: o The HTTP request entity-body is single-part. o The entity-body follows the encoding requirements of the "application/x-www-form-urlencoded" content-type as defined by HTML 4.01 [W3C.REC-html401-19991224]. o The HTTP request entity-header includes the "Content-Type" header field set to "application/x-www-form-urlencoded". I would combine the first and the third bullet into a single statement, bec= ause they seem to be a bit confusing while being read separately. (I.e., is it possible to have Content-Type of "application/x-www-form-urlen= coded" with something which is multipart?) 2). Section "3.1. Error Codes" I recommend creating an IANA registry for these or explain why one is not n= eeded. 3). 4.2. Threat Mitigation To protect against token disclosure, confidentiality protection MUST be applied using TLS [RFC5246] with a ciphersuite that provides confidentiality and integrity protection. This requires that the communication interaction between the client and the authorization server, as well as the interaction between the client and the resource server, utilize confidentiality and integrity protection. Since TLS is mandatory to implement and to use with this specification, it is the preferred approach for preventing token disclosure via the communication channel. For those cases where the client is prevented from observing the contents of the token, token encryption MUST be applied in addition to the usage of TLS protection. As a further defense against token disclosure, the client MUST validate the TLS certificate chain when making requests to protected resources. and To deal with token capture and replay, the following recommendations are made: First, the lifetime of the token MUST be limited; one means of achieving this is by putting a validity time field inside the protected part of the token. Note that using short-lived (one hour or less) tokens reduces the impact of them being leaked. Second, confidentiality protection of the exchanges between the client and the authorization server and between the client and the resource server MUST be applied. As a consequence, no eavesdropper along the communication path is able to observe the token exchange. Consequently, such an on-path adversary cannot replay the token. Furthermore, when presenting the token to a resource server, the client MUST verify the identity of that resource server, as per Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS) [RFC6125]. Firstly, I would move the RFC 6125 reference to the first paragraph quoted = above (but see below). Secondly, you should either normatively reference RF= C 2818 (HTTP over TLS) instead of RFC 6125, or you need to provide more inf= ormation about how RFC 6125 is to be used, because it has several options w= hich need to be described (use of SRV-IDs, URI-IDs, DNS-IDs, use of wildcar= ds). I suspect you should just reference RFC 2818. Nits: 2.2. Form-Encoded Body Parameter o The content to be encoded in the entity-body MUST consist entirely of ASCII characters. ASCII needs a reference. ID-nits reports: =3D=3D The document seems to lack the recommended RFC 2119 boilerplate, = even if it appears to use RFC 2119 keywords -- however, there's a paragraph w= ith a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). =3D=3D Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'S= HOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119.=20 Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what = you mean). and: Found 'MUST not' in this paragraph: o Stated that bearer tokens MUST not be stored in cookies that can be sent in the clear in the Threat Mitigation section. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf From internet-drafts@ietf.org Mon Jan 30 11:15:07 2012 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 DBF1121F8559; Mon, 30 Jan 2012 11:15:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 ufdAq-v-U5JC; Mon, 30 Jan 2012 11:15:07 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64BEA21F84FC; Mon, 30 Jan 2012 11:15:07 -0800 (PST) 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.64p1 Message-ID: <20120130191507.18998.18489.idtracker@ietfa.amsl.com> Date: Mon, 30 Jan 2012 11:15:07 -0800 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-16.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, 30 Jan 2012 19:15:08 -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-16.txt Pages : 22 Date : 2012-01-30 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 the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens need 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-16.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-16.txt From Michael.Jones@microsoft.com Mon Jan 30 11:43:14 2012 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 590E921F85D2; Mon, 30 Jan 2012 11:43:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.758 X-Spam-Level: X-Spam-Status: No, score=-3.758 tagged_above=-999 required=5 tests=[AWL=-0.160, 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 BWmf39VQ-fqb; Mon, 30 Jan 2012 11:43:13 -0800 (PST) Received: from DB3EHSOBE001.bigfish.com (db3ehsobe002.messaging.microsoft.com [213.199.154.140]) by ietfa.amsl.com (Postfix) with ESMTP id CD9BA21F850D; Mon, 30 Jan 2012 11:43:12 -0800 (PST) Received: from mail99-db3-R.bigfish.com (10.3.81.230) by DB3EHSOBE001.bigfish.com (10.3.84.21) with Microsoft SMTP Server id 14.1.225.23; Mon, 30 Jan 2012 19:43:11 +0000 Received: from mail99-db3 (localhost [127.0.0.1]) by mail99-db3-R.bigfish.com (Postfix) with ESMTP id 1877E1A02E7; Mon, 30 Jan 2012 19:43:11 +0000 (UTC) X-SpamScore: -19 X-BigFish: VS-19(zzc85fhzz1202hzz1033IL8275eh8275bh8275dha1495iz2fhc1bhc31hc1ahc1bhc31hc1ah2a8h668h839h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail99-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC105.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail99-db3 (localhost.localdomain [127.0.0.1]) by mail99-db3 (MessageSwitch) id 1327952588724882_26700; Mon, 30 Jan 2012 19:43:08 +0000 (UTC) Received: from DB3EHSMHS002.bigfish.com (unknown [10.3.81.231]) by mail99-db3.bigfish.com (Postfix) with ESMTP id A9DB81C0278; Mon, 30 Jan 2012 19:43:08 +0000 (UTC) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS002.bigfish.com (10.3.87.102) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 30 Jan 2012 19:43:07 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.12]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.02.0247.005; Mon, 30 Jan 2012 11:42:34 -0800 From: Mike Jones To: "oauth@ietf.org" , "ietf@ietf.org" , "iesg@ietf.org" Thread-Topic: OAuth 2.0 Bearer Token Specification Draft -16 Thread-Index: Aczfh0f3Dd/+wXTgQaiZVcyGxsaUGw== Date: Mon, 30 Jan 2012 19:42:33 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436638D04A@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.71] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436638D04ATK5EX14MBXC284r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: [OAUTH-WG] OAuth 2.0 Bearer Token Specification Draft -16 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, 30 Jan 2012 19:43:14 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436638D04ATK5EX14MBXC284r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Draft 16 of the OAuth 2.0 Bearer Token Specification has been published. This version contains= a proposed resolution to the auth-param syntax issue that has been reviewe= d by Julian Reschke, Mark Nottingham, and the OAuth WG chairs. It also add= resses the Gen-ART review comments by Alexey Melnikov. It contains the following changes: * Use the HTTPbis auth-param syntax for Bearer challenge attributes. * Dropped the sentence "The realm value is intended for programmatic us= e and is not meant to be displayed to end users". * Reordered form-encoded body parameter description bullets for better = readability. * Added [USASCII] reference. The draft is available at: * http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-16 A HTML-formatted version is available at: * http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-16.html -- Mike --_000_4E1F6AAD24975D4BA5B16804296739436638D04ATK5EX14MBXC284r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Draft 16 of the OAuth 2.0 Bearer Token Specification has been published.  This ver= sion contains a proposed resolution to the auth-param syntax issue that has= been reviewed by Julian Reschke, Mark Nottingham, and the OAuth WG chairs.=   It also addresses the Gen-ART review comments by Alexey Melnikov.

 

It contains the following changes:

  • Use the HTTPbis auth-param syntax for Bearer chall= enge attributes.
  • Dropped the sentence "The realm val= ue is intended for programmatic use and is not meant to be displayed to end= users".
  • Reordered form-encoded body parameter description = bullets for better readability.
  • Added [USASCII] reference.

 

The draft is available at:

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

A HTML-formatted version is available at:=

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

 

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

 

--_000_4E1F6AAD24975D4BA5B16804296739436638D04ATK5EX14MBXC284r_-- From peaceable_whale@hotmail.com Mon Jan 30 12:07:09 2012 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 8E96111E80AE; Mon, 30 Jan 2012 12:07:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.846 X-Spam-Level: X-Spam-Status: No, score=-0.846 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_BASE64_TEXT=1.753] 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 t9pHl9CJCffK; Mon, 30 Jan 2012 12:07:07 -0800 (PST) Received: from col0-omc1-s12.col0.hotmail.com (col0-omc1-s12.col0.hotmail.com [65.55.34.22]) by ietfa.amsl.com (Postfix) with ESMTP id CC99911E8093; Mon, 30 Jan 2012 12:07:07 -0800 (PST) Received: from COL122-DS15 ([65.55.34.7]) by col0-omc1-s12.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 30 Jan 2012 12:07:06 -0800 X-Originating-IP: [14.136.19.151] X-Originating-Email: [peaceable_whale@hotmail.com] Message-ID: From: "Franklin Tse" To: , , References: <4E1F6AAD24975D4BA5B16804296739436638D04A@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436638D04A@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Tue, 31 Jan 2012 04:06:58 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8117.416 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8117.416 X-OriginalArrivalTime: 30 Jan 2012 20:07:06.0999 (UTC) FILETIME=[BDD14070:01CCDF8A] Subject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token Specification Draft -16 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, 30 Jan 2012 20:07:09 -0000 SGVsbG8sDQoNCkp1c3Qgbm90aWNlZCB0aGF0IFJGQzI2MTYgYW5kIFJGQzI2MTcgYXJlIHB1dCB1 bmRlciBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzIGJ1dCBhcmUgb25seSByZWZlcmVuY2VkIGluIERv Y3VtZW50IEhpc3RvcnkuIFdpbGwgdGhleSBiZSByZW1vdmVkIGJlZm9yZSBwdWJsaWNhdGlvbiBh cyBhbiBSRkM/DQoNClJlZ2FyZHMsDQpGcmFua2xpbg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KRnJvbTogIk1pa2UgSm9uZXMiIDxNaWNoYWVs LkpvbmVzQG1pY3Jvc29mdC5jb20+DQpEYXRlOiBUdWVzZGF5LCAzMSBKYW51YXJ5LCAyMDEyIDAz OjQyDQpUbzogPG9hdXRoQGlldGYub3JnPjsgPGlldGZAaWV0Zi5vcmc+OyA8aWVzZ0BpZXRmLm9y Zz4NClN1YmplY3Q6IFtPQVVUSC1XR10gT0F1dGggMi4wIEJlYXJlciBUb2tlbiBTcGVjaWZpY2F0 aW9uIERyYWZ0IC0xNg0KDQo+IERyYWZ0IDE2IG9mIHRoZSBPQXV0aCAyLjAgQmVhcmVyIFRva2Vu IFNwZWNpZmljYXRpb248aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0 aC12Mi1iZWFyZXI+IGhhcyBiZWVuIHB1Ymxpc2hlZC4gIFRoaXMgdmVyc2lvbiBjb250YWlucyBh IHByb3Bvc2VkIHJlc29sdXRpb24gdG8gdGhlIGF1dGgtcGFyYW0gc3ludGF4IGlzc3VlIHRoYXQg aGFzIGJlZW4gcmV2aWV3ZWQgYnkgSnVsaWFuIFJlc2Noa2UsIE1hcmsgTm90dGluZ2hhbSwgYW5k IHRoZSBPQXV0aCBXRyBjaGFpcnMuICBJdCBhbHNvIGFkZHJlc3NlcyB0aGUgR2VuLUFSVCByZXZp ZXcgY29tbWVudHMgYnkgQWxleGV5IE1lbG5pa292Lg0KPiANCj4gSXQgY29udGFpbnMgdGhlIGZv bGxvd2luZyBjaGFuZ2VzOg0KPiANCj4gICogICBVc2UgdGhlIEhUVFBiaXMgYXV0aC1wYXJhbSBz eW50YXggZm9yIEJlYXJlciBjaGFsbGVuZ2UgYXR0cmlidXRlcy4NCj4gICogICBEcm9wcGVkIHRo ZSBzZW50ZW5jZSAiVGhlIHJlYWxtIHZhbHVlIGlzIGludGVuZGVkIGZvciBwcm9ncmFtbWF0aWMg dXNlIGFuZCBpcyBub3QgbWVhbnQgdG8gYmUgZGlzcGxheWVkIHRvIGVuZCB1c2VycyIuDQo+ICAq ICAgUmVvcmRlcmVkIGZvcm0tZW5jb2RlZCBib2R5IHBhcmFtZXRlciBkZXNjcmlwdGlvbiBidWxs ZXRzIGZvciBiZXR0ZXIgcmVhZGFiaWxpdHkuDQo+ICAqICAgQWRkZWQgW1VTQVNDSUldIHJlZmVy ZW5jZS4NCj4gDQo+IFRoZSBkcmFmdCBpcyBhdmFpbGFibGUgYXQ6DQo+IA0KPiAqICAgICAgICAg aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC12Mi1iZWFyZXItMTYN Cj4gQSBIVE1MLWZvcm1hdHRlZCB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCj4gDQo+ICogICAg ICAgICBodHRwOi8vc2VsZi1pc3N1ZWQuaW5mby9kb2NzL2RyYWZ0LWlldGYtb2F1dGgtdjItYmVh cmVyLTE2Lmh0bWwNCj4gDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KPiANCj4NCg0KDQoNCj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gT0F1dGggbWFpbGluZyBsaXN0 DQo+IE9BdXRoQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vb2F1dGgNCj4g From Michael.Jones@microsoft.com Mon Jan 30 15:44:33 2012 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 B3FBC11E80F5; Mon, 30 Jan 2012 15:44:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.753 X-Spam-Level: X-Spam-Status: No, score=-3.753 tagged_above=-999 required=5 tests=[AWL=-0.154, 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 sbCQn-basZ6q; Mon, 30 Jan 2012 15:44:32 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id 35A1B11E80F3; Mon, 30 Jan 2012 15:44:31 -0800 (PST) Received: from mail196-ch1-R.bigfish.com (10.43.68.238) by CH1EHSOBE013.bigfish.com (10.43.70.63) with Microsoft SMTP Server id 14.1.225.23; Mon, 30 Jan 2012 23:44:30 +0000 Received: from mail196-ch1 (localhost [127.0.0.1]) by mail196-ch1-R.bigfish.com (Postfix) with ESMTP id 3A37F1001DE; Mon, 30 Jan 2012 23:44:30 +0000 (UTC) X-SpamScore: -31 X-BigFish: VS-31(zz9371I542M1432Nzz1202hzz1033IL8275eh8275bh8275dha1495iz2fhc1bhc31hc1ah2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail196-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail196-ch1 (localhost.localdomain [127.0.0.1]) by mail196-ch1 (MessageSwitch) id 1327967067958276_25145; Mon, 30 Jan 2012 23:44:27 +0000 (UTC) Received: from CH1EHSMHS006.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.233]) by mail196-ch1.bigfish.com (Postfix) with ESMTP id DC425380048; Mon, 30 Jan 2012 23:44:27 +0000 (UTC) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS006.bigfish.com (10.43.70.6) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 30 Jan 2012 23:44:27 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.12]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.02.0247.005; Mon, 30 Jan 2012 15:44:01 -0800 From: Mike Jones To: Franklin Tse , "oauth@ietf.org" , "ietf@ietf.org" , "iesg@ietf.org" Thread-Topic: [OAUTH-WG] OAuth 2.0 Bearer Token Specification Draft -16 Thread-Index: Aczfh0f3Dd/+wXTgQaiZVcyGxsaUGwARn6gAAAk13wA= Date: Mon, 30 Jan 2012 23:44:00 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436638D3D7@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739436638D04A@TK5EX14MBXC284.redmond.corp.microsoft.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.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token Specification Draft -16 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, 30 Jan 2012 23:44:34 -0000 I suspect that's up to the RFC editor. There are no normative uses of thes= e specifications because Bearer uses the HTTPbis specifications. -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of F= ranklin Tse Sent: Monday, January 30, 2012 12:07 PM To: oauth@ietf.org; ietf@ietf.org; iesg@ietf.org Subject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token Specification Draft -16 Hello, Just noticed that RFC2616 and RFC2617 are put under Informative References = but are only referenced in Document History. Will they be removed before pu= blication as an RFC? Regards, Franklin -------------------------------------------------- From: "Mike Jones" Date: Tuesday, 31 January, 2012 03:42 To: ; ; Subject: [OAUTH-WG] OAuth 2.0 Bearer Token Specification Draft -16 > Draft 16 of the OAuth 2.0 Bearer Token Specification has been published. This version contai= ns a proposed resolution to the auth-param syntax issue that has been revie= wed by Julian Reschke, Mark Nottingham, and the OAuth WG chairs. It also a= ddresses the Gen-ART review comments by Alexey Melnikov. >=20 > It contains the following changes: >=20 > * Use the HTTPbis auth-param syntax for Bearer challenge attributes. > * Dropped the sentence "The realm value is intended for programmatic u= se and is not meant to be displayed to end users". > * Reordered form-encoded body parameter description bullets for better= readability. > * Added [USASCII] reference. >=20 > The draft is available at: >=20 > * http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-16 > A HTML-formatted version is available at: >=20 > * http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-16.html >=20 > -- Mike >=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 alexey.melnikov@isode.com Tue Jan 31 02:33:46 2012 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 C8DBF21F8598; Tue, 31 Jan 2012 02:33:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MacxjZXKurAQ; Tue, 31 Jan 2012 02:33:45 -0800 (PST) Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0566F21F8456; Tue, 31 Jan 2012 02:33:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1328006023; d=isode.com; s=selector; i=@isode.com; bh=wymAVhwEHKfcP6NkNNrsdP98i5LC6+9c9122TL72YGM=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=YMiGNeogKBq/nO7j/gY9Qu22ttPm4GzouC+7uKFW3qgrQNwZLF69l4a//QvZUtcSErWacq iTT+MlssW0DkUCb4seE3T6+1jjEIgu84OWChvd4dtH8wYUfq/k1R3xcsA82axc2FkHoFAD X888fCT/IXJN8YCTsxr976pT2sW35HU=; Received: from [188.29.102.51] (188.29.102.51.threembb.co.uk [188.29.102.51]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 31 Jan 2012 10:33:39 +0000 Message-ID: <4F27C37C.1090008@isode.com> Date: Tue, 31 Jan 2012 10:33:32 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 To: Mike Jones References: <4F2575CE.9040001@isode.com> <4E1F6AAD24975D4BA5B16804296739436638B7AD@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436638B7AD@TK5EX14MBXC284.redmond.corp.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cc: General Area Review Team , "oauth@ietf.org" , "draft-ietf-oauth-v2-bearer.all@tools.ietf.org" , IETF-Discussion Discussion Subject: Re: [OAUTH-WG] Gen-ART review of draft-ietf-oauth-v2-bearer-15.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, 31 Jan 2012 10:33:46 -0000 On 30/01/2012 05:20, Mike Jones wrote: > Thanks for your useful feedback, Alexey. Hi Mike, > Below, I'll respond to each of your comments. I've also added the O= Auth working group to the thread, so they are aware of them as well and c= an participate in the discussion. > > About your first issue with the WWW-Authenticate ABNF, I am already wor= king with Julian, Mark Nottingham, and the chairs to resolve this issue. = Expect to see a proposal for review by the working group shortly. Ok, I will have a look. > About your comments on scope: OAuth 2.0 (both the Core and Bearer spec= s) is designed to be deployed in diverse and non-interoperable applicatio= n contexts, meeting a variety of application needs. In those various set= tings, which are often distinct and potentially non-interoperable, parame= ters such as scope, realm, etc. may have very different meanings. This i= s not a bug; it is a feature, because it allows the OAuth pattern to meet= the needs of numerous, often distinct, application environments. For th= at reason, a registry of scope (or realm) parameters would be ill-advised= and counterproductive. It's perfectly OK and expected for a scope value= such as "email" to have one meaning in one application context and a dif= ferent meaning in a different, but distinct application context. Trying = to impose a single meaning on particular scope values across distinct app= lication contexts is both unnecessary and could break many existing deplo= yments. That being said, we fully expect > interoperability profiles to emerge that define interoperable sets of s= cope values within particular application contexts. (The OpenID Connect = specifications are one such set of profiles.) But these meanings will al= ways be context-specific - not global in scope. The way "scope" is currently defined in the document is completely=20 useless. You don't have a single example in the document. You don't say=20 how the semantics of the value differs from realm. You don't say that=20 its values are deployment specific and can be profiled in future=20 documents. Please say something about these issues in the document (your = explanation above would work.) > About your first minor issue, I'll reorder the bullets so the statement= about the entity-body being single part is followed by the statement abo= ut it using application/x-www-form-urlencoded, so they will be read toget= her. Ok. > About your second minor issue on error codes, the error codes registry = already exists, but is in the OAuth Core spec. Seehttp://tools.ietf.org/= html/draft-ietf-oauth-v2-23#section-11.4. Can you please make this clear in the document (by adding a reference)? > About your third minor issue on RFC 6125 versus RFC 2818, you'll find t= hat, per the history entries, a previous reference to RFC 2818 was change= d to RFC 6125 in draft 14 at the request of Security Area Director Stephe= n Farrell. If you'd like to see this reference reintroduced, I'd request= that you work with Stephen on specific alternative proposed wording that= is acceptable to both of you. Ok, I can work with Stephen and Peter Saint-Andre (RFC 6125 co-author) on= some text. > Finally, I'll address both of your nits in the manner you suggested. These are fixed in -16, thanks. > > Thanks again, > -- Mike > > -----Original Message----- > From:ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of= Alexey Melnikov > Sent: Sunday, January 29, 2012 8:38 AM > To: General Area Review Team; IETF-Discussion Discussion;draft-ietf-oau= th-v2-bearer.all@tools.ietf.org > Subject: Gen-ART review of draft-ietf-oauth-v2-bearer-15.txt > > I am the assigned Gen-ART reviewer for this draft. For background on Ge= n-ART, please see the FAQ at. > > Please resolve these comments along with any other Last Call comments y= ou may receive. > > Document: draft-ietf-oauth-v2-bearer-15.txt > Reviewer: Alexey Melnikov > Review Date: 29 Jan 2012 > IETF LC End Date: 7 Feb 2012 > IESG Telechat date: (if known) - > > Summary: Mostly ready, with a couple of things that should be addressed= =2E > > Major Issues: > > I have 2 issues in section 3: > > 3. The WWW-Authenticate Response Header Field > > If the protected resource request does not include authentication > credentials or does not contain an access token that enables acces= s > to the protected resource, the resource server MUST include the HT= TP > "WWW-Authenticate" response header field; it MAY include it in > response to other conditions as well. The "WWW-Authenticate" head= er > field uses the framework defined by HTTP/1.1, Part 7 > [I-D.ietf-httpbis-p7-auth] as follows: > > challenge =3D "Bearer" [ 1*SP 1#param ] > > param =3D realm / scope / > error / error-desc / error-uri / > auth-param > > 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 > > 1). I am agreeing with Julian about redefinition of ABNF from HTTPBis d= ocuments. I believe there is a proposal to fix that but the new draft has= n't been posted yet. > > 2). My 2nd major issue is about the following paragraph: > > The "scope" attribute is a space-delimited list of scope values > indicating the required scope of the access token for accessing th= e > requested resource. In some cases, the "scope" value will be used= > when requesting a new access token with sufficient scope of access= to > utilize the protected resource. The "scope" attribute MUST NOT > appear more than once. The "scope" value is intended for > programmatic use and is not meant to be displayed to end users. > > I don't think this provide enough information about what this is, how i= t is to be used and which values are allowed. As this is not meant to be = displayed to end users, then you need to say what values are allowed and = which entity can allocate them. Is there a registry for these tokens, e.g= =2E an IANA registry? > > > Minor Issues: > > 1). > 2.2. Form-Encoded Body Parameter > > When sending the access token in the HTTP request entity-body, the= > client adds the access token to the request body using the > "access_token" parameter. The client MUST NOT use this method unl= ess > all of the following conditions are met: > > o The HTTP request entity-body is single-part. > > o The entity-body follows the encoding requirements of the > "application/x-www-form-urlencoded" content-type as defined by > HTML 4.01 [W3C.REC-html401-19991224]. > > o The HTTP request entity-header includes the "Content-Type" head= er > field set to "application/x-www-form-urlencoded". > > I would combine the first and the third bullet into a single statement,= because they seem to be a bit confusing while being read separately. > (I.e., is it possible to have Content-Type of "application/x-www-form-u= rlencoded" with something which is multipart?) > > 2). > Section "3.1. Error Codes" > > I recommend creating an IANA registry for these or explain why one is n= ot needed. > > 3). > 4.2. Threat Mitigation > > To protect against token disclosure, confidentiality protection MU= ST > be applied using TLS [RFC5246] with a ciphersuite that provides > confidentiality and integrity protection. This requires that the > communication interaction between the client and the authorization= > server, as well as the interaction between the client and the > resource server, utilize confidentiality and integrity protection.= > Since TLS is mandatory to implement and to use with this > specification, it is the preferred approach for preventing token > disclosure via the communication channel. For those cases where t= he > client is prevented from observing the contents of the token, toke= n > encryption MUST be applied in addition to the usage of TLS > protection. As a further defense against token disclosure, the > client MUST validate the TLS certificate chain when making request= s > to protected resources. > > and > > To deal with token capture and replay, the following recommendatio= ns > are made: First, the lifetime of the token MUST be limited; one me= ans > of achieving this is by putting a validity time field inside the > protected part of the token. Note that using short-lived (one hou= r > or less) tokens reduces the impact of them being leaked. Second, > confidentiality protection of the exchanges between the client and= > the authorization server and between the client and the resource > server MUST be applied. As a consequence, no eavesdropper along t= he > communication path is able to observe the token exchange. > Consequently, such an on-path adversary cannot replay the token. > Furthermore, when presenting the token to a resource server, the > client MUST verify the identity of that resource server, as per > Representation and Verification of Domain-Based Application Servic= e > Identity within Internet Public Key Infrastructure Using X.509 (PK= IX) > Certificates in the Context of Transport Layer Security (TLS) > [RFC6125]. > > Firstly, I would move the RFC 6125 reference to the first paragraph quo= ted above (but see below). Secondly, you should either normatively refere= nce RFC 2818 (HTTP over TLS) instead of RFC 6125, or you need to provide = more information about how RFC 6125 is to be used, because it has several= options which need to be described (use of SRV-IDs, URI-IDs, DNS-IDs, us= e of wildcards). I suspect you should just reference RFC 2818. > > > Nits: > > 2.2. Form-Encoded Body Parameter > > o The content to be encoded in the entity-body MUST consist entir= ely > of ASCII characters. > > ASCII needs a reference. > > > ID-nits reports: > > =3D=3D The document seems to lack the recommended RFC 2119 boilerpl= ate, even if > it appears to use RFC 2119 keywords -- however, there's a paragr= aph with > a matching beginning. Boilerplate error? > > (The document does seem to have the reference to RFC 2119 which = the > ID-Checklist requires). > =3D=3D Using lowercase 'not' together with uppercase 'MUST', 'SHALL= ', 'SHOULD', > or 'RECOMMENDED' is not an accepted usage according to RFC 2119.= > Please > use uppercase 'NOT' together with RFC 2119 keywords (if that is = what you > mean). > > and: > > Found 'MUST not' in this paragraph: > > o Stated that bearer tokens MUST not be stored in cookies that = can > be sent in the clear in the Threat Mitigation section. > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > >