From jricher@mitre.org Mon Apr 1 10:06:36 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C02B21F8E36 for ; Mon, 1 Apr 2013 10:06:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jg1wFR42dKWj for ; Mon, 1 Apr 2013 10:06:35 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 46FB521F8D0D for ; Mon, 1 Apr 2013 10:06:35 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 9A52E1F0577; Mon, 1 Apr 2013 13:06:34 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id A3936226014E; Mon, 1 Apr 2013 13:06:24 -0400 (EDT) Received: from [10.146.15.29] (129.83.31.58) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.2.342.3; Mon, 1 Apr 2013 13:06:09 -0400 Message-ID: <5159BE2D.3020305@mitre.org> Date: Mon, 1 Apr 2013 13:04:45 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: nov matake References: <20130329203808.13164.56358.idtracker@ietfa.amsl.com> <5155FF43.6070606@mitre.org> <6851D735-F609-4304-AFE6-3BAA35CE9FC4@gmail.com> <328E6FBA-30A1-49EF-A5A7-32EDC04EF48C@gmail.com> In-Reply-To: <328E6FBA-30A1-49EF-A5A7-32EDC04EF48C@gmail.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [129.83.31.58] Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-09.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 17:06:36 -0000 If the access token isn't valid, then the intent is that the server return whatever is a valid response from OAuth, which as I recall is practically any 400 class error. This behavior for DynReg is outlined in section 5.2 of draft -09. In your case, since you're actually failing on the bad token, you're fine with returning a 401. In other words, by my intent of the text and my understanding of your implementation, you're actually compliant. The problem is that the text made you think otherwise. :) Can you suggest how to make this clearer for developers in the text? -- Justin On 03/29/2013 11:57 PM, nov matake wrote: > oops sorry, not draft07, but draft06. > > On 2013/03/30, at 12:55, nov matake wrote: > >> Hi Justin, >> >> I read the latest draft and found endpoints described in the spec returns 403 in "no such clients" case. >> I also read the draft07's editor note below, so I can understand the situation. >> >> [[ Editor's note: If the client doesn't exist, >> then the Refresh Access Token shouldn't be valid, making this kind of >> error a 403 at the auth layer instead. How best to call this >> inconsistency out? ]] >> >> However, in my current implementation, the server returns 401 if an access token is given but there are no valid access token in its DB. >> In my case, validation for the given access token is done in middleware layer, so I don't want to change the error code per endpoint. >> In such case, client registration/read/update/delete endpoints can return 401 error? >> >> Thanks >> >> -- >> nov >> >> On 2013/03/30, at 5:53, Justin Richer wrote: >> >>> New dynamic registration draft is published. Biggest changes here are the internationalization/localization capabilities that are now applicable to human-readable client metadata fields. >>> >>> -- Justin >>> >>> On 03/29/2013 04:38 PM, internet-drafts@ietf.org wrote: >>>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>>> This draft is a work item of the Web Authorization Protocol Working Group of the IETF. >>>> >>>> Title : OAuth 2.0 Dynamic Client Registration Protocol >>>> Author(s) : Justin Richer >>>> John Bradley >>>> Michael B. Jones >>>> Maciej Machulak >>>> Filename : draft-ietf-oauth-dyn-reg-09.txt >>>> Pages : 23 >>>> Date : 2013-03-29 >>>> >>>> Abstract: >>>> This specification defines an endpoint and protocol for dynamic >>>> registration of OAuth 2.0 Clients at an Authorization Server and >>>> methods for the dynamically registered client to manage its >>>> registration. >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg >>>> >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-09 >>>> >>>> A diff from the previous version is available at: >>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dyn-reg-09 >>>> >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> _______________________________________________ >>>> 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 matake@gmail.com Mon Apr 1 10:23:54 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5201521E8053 for ; Mon, 1 Apr 2013 10:23:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DsZaUqaqv7z3 for ; Mon, 1 Apr 2013 10:23:53 -0700 (PDT) Received: from mail-pb0-f47.google.com (mail-pb0-f47.google.com [209.85.160.47]) by ietfa.amsl.com (Postfix) with ESMTP id 67E3911E80D3 for ; Mon, 1 Apr 2013 10:23:53 -0700 (PDT) Received: by mail-pb0-f47.google.com with SMTP id rq13so254691pbb.34 for ; Mon, 01 Apr 2013 10:23:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=WlGP7+63cbL1/eldzxvAO+SA6lvgpkR4bo46SiwXn5A=; b=BAQU1Cg82jT/hutmgqscxY2r+hdnbgWcA4krqQ/HuLzKx83/+sHznv3i1n13cRQAZ8 v9CA3fnrV+gg3E9oWGMoppuQ2S0Ejgrar9jJgV2U6CgrvdBybz3UFwmRtDRHAVUQgHZQ mHFh5bxZjW1cL3RryOxJAVHByqgQLmkbpIkIaCxAXp8UUTKsvW7sQ6FYpQduVqoielHO OStS4+0tssBe7LYISdksdMsYDb5YLnS+Mm8qYtaqETINASnVNpqwt3ojwR1yNW+OlN26 hC8yneSO+n39yiGryApfcdcIOix8G0MN7FIAWwmxHt7T/izA3i0jjx4iFS4jjO+QJPX4 eHqw== X-Received: by 10.68.57.139 with SMTP id i11mr19385973pbq.185.1364837033034; Mon, 01 Apr 2013 10:23:53 -0700 (PDT) Received: from [192.168.1.35] (ac149127.dynamic.ppp.asahi-net.or.jp. [183.77.149.127]) by mx.google.com with ESMTPS id ky10sm16030134pab.23.2013.04.01.10.23.50 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 01 Apr 2013 10:23:51 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: nov matake In-Reply-To: <5159BE2D.3020305@mitre.org> Date: Tue, 2 Apr 2013 02:23:48 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130329203808.13164.56358.idtracker@ietfa.amsl.com> <5155FF43.6070606@mitre.org> <6851D735-F609-4304-AFE6-3BAA35CE9FC4@gmail.com> <328E6FBA-30A1-49EF-A5A7-32EDC04EF48C@gmail.com> <5159BE2D.3020305@mitre.org> To: Justin Richer X-Mailer: Apple Mail (2.1503) Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-09.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 17:23:54 -0000 Thanks for your clarification. After reading the editor's note in draft06, I felt 401 is more natural = than 403. (assuming you don't want to use 404 for security reason) The editor's note is enough detail for the reason of using 401. Using 403, it's like "the token is valid, but the ghost client has no = permission"..? On 2013/04/02, at 2:04, Justin Richer wrote: > If the access token isn't valid, then the intent is that the server = return whatever is a valid response from OAuth, which as I recall is = practically any 400 class error. This behavior for DynReg is outlined in = section 5.2 of draft -09. >=20 > In your case, since you're actually failing on the bad token, you're = fine with returning a 401. In other words, by my intent of the text and = my understanding of your implementation, you're actually compliant. The = problem is that the text made you think otherwise. :) >=20 > Can you suggest how to make this clearer for developers in the text? >=20 > -- Justin >=20 >=20 > On 03/29/2013 11:57 PM, nov matake wrote: >> oops sorry, not draft07, but draft06. >>=20 >> On 2013/03/30, at 12:55, nov matake wrote: >>=20 >>> Hi Justin, >>>=20 >>> I read the latest draft and found endpoints described in the spec = returns 403 in "no such clients" case. >>> I also read the draft07's editor note below, so I can understand the = situation. >>>=20 >>> [[ Editor's note: If the client doesn't exist, >>> then the Refresh Access Token shouldn't be valid, making this kind = of >>> error a 403 at the auth layer instead. How best to call this >>> inconsistency out? ]] >>>=20 >>> However, in my current implementation, the server returns 401 if an = access token is given but there are no valid access token in its DB. >>> In my case, validation for the given access token is done in = middleware layer, so I don't want to change the error code per endpoint. >>> In such case, client registration/read/update/delete endpoints can = return 401 error? >>>=20 >>> Thanks >>>=20 >>> -- >>> nov >>>=20 >>> On 2013/03/30, at 5:53, Justin Richer wrote: >>>=20 >>>> New dynamic registration draft is published. Biggest changes here = are the internationalization/localization capabilities that are now = applicable to human-readable client metadata fields. >>>>=20 >>>> -- Justin >>>>=20 >>>> On 03/29/2013 04:38 PM, internet-drafts@ietf.org wrote: >>>>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>>>> This draft is a work item of the Web Authorization Protocol = Working Group of the IETF. >>>>>=20 >>>>> Title : OAuth 2.0 Dynamic Client Registration Protocol >>>>> Author(s) : Justin Richer >>>>> John Bradley >>>>> Michael B. Jones >>>>> Maciej Machulak >>>>> Filename : draft-ietf-oauth-dyn-reg-09.txt >>>>> Pages : 23 >>>>> Date : 2013-03-29 >>>>>=20 >>>>> Abstract: >>>>> This specification defines an endpoint and protocol for dynamic >>>>> registration of OAuth 2.0 Clients at an Authorization Server and >>>>> methods for the dynamically registered client to manage its >>>>> registration. >>>>>=20 >>>>>=20 >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg >>>>>=20 >>>>> There's also a htmlized version available at: >>>>> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-09 >>>>>=20 >>>>> A diff from the previous version is available at: >>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-09 >>>>>=20 >>>>>=20 >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >=20 From matake@gmail.com Mon Apr 1 10:35:59 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8803711E80AE for ; Mon, 1 Apr 2013 10:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cp0xVBkRrMEH for ; Mon, 1 Apr 2013 10:35:58 -0700 (PDT) Received: from mail-pb0-f45.google.com (mail-pb0-f45.google.com [209.85.160.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2ED0921F8B27 for ; Mon, 1 Apr 2013 10:35:43 -0700 (PDT) Received: by mail-pb0-f45.google.com with SMTP id ro8so1292689pbb.18 for ; Mon, 01 Apr 2013 10:35:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=a6KdQSAp5zdAglGV1X9bApmCMbUndPnFvpy12rdsCDs=; b=deUNKxmga2DFKkqHGNLtzGlnZNuzgyb6DEKZrZ7ipev66MsfCnLkzkjhG3x6Nv0mt6 GdQr1MAbtT9V0hJmUFWyldbsoq2lN+b1zRW7HHHIeN819paeMDmnXPZwRfvhNFgMm5Gh mlTMcWgjBE8nqL+L5ta7fyNBFRmpoP79tz2iKATzTQXVnpM7BKf4mw67TI/9KcAx1lsx KB0sk0fvrjmTdvyqX4kFHR6MA5ynkR0anGQX6Tl4lXfPx9xlWF/VTLZughkrSSq+9YQc ikVBV3TTvpVqB1FtNWsK2M7wBIiBmUX/giCV4noktZUOTr8zc1qCrmsHgtj+keCLIGnu 0brA== X-Received: by 10.66.163.101 with SMTP id yh5mr19830768pab.22.1364837742734; Mon, 01 Apr 2013 10:35:42 -0700 (PDT) Received: from [192.168.1.35] (ac149127.dynamic.ppp.asahi-net.or.jp. [183.77.149.127]) by mx.google.com with ESMTPS id kt5sm14547048pbc.30.2013.04.01.10.35.40 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 01 Apr 2013 10:35:41 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: nov matake In-Reply-To: Date: Tue, 2 Apr 2013 02:35:38 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <90F190E8-2E53-46C3-B5A1-05439ECE69F8@gmail.com> References: <20130329203808.13164.56358.idtracker@ietfa.amsl.com> <5155FF43.6070606@mitre.org> <6851D735-F609-4304-AFE6-3BAA35CE9FC4@gmail.com> <328E6FBA-30A1-49EF-A5A7-32EDC04EF48C@gmail.com> <5159BE2D.3020305@mitre.org> To: Justin Richer X-Mailer: Apple Mail (2.1503) Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-09.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 17:35:59 -0000 [Current] If the client does not exist on this server, the server MUST return an = HTTP 403 Forbidden. [Proposed] If the client does not exist on this server, the server treat the given = token as invalid and MUST return HTTP 401 Unauthorized as described in RFC 6750 Section 3.1. On 2013/04/02, at 2:23, nov matake wrote: > Thanks for your clarification. >=20 > After reading the editor's note in draft06, I felt 401 is more natural = than 403. > (assuming you don't want to use 404 for security reason) >=20 > The editor's note is enough detail for the reason of using 401. >=20 > Using 403, it's like "the token is valid, but the ghost client has no = permission"..? >=20 > On 2013/04/02, at 2:04, Justin Richer wrote: >=20 >> If the access token isn't valid, then the intent is that the server = return whatever is a valid response from OAuth, which as I recall is = practically any 400 class error. This behavior for DynReg is outlined in = section 5.2 of draft -09. >>=20 >> In your case, since you're actually failing on the bad token, you're = fine with returning a 401. In other words, by my intent of the text and = my understanding of your implementation, you're actually compliant. The = problem is that the text made you think otherwise. :) >>=20 >> Can you suggest how to make this clearer for developers in the text? >>=20 >> -- Justin >>=20 >>=20 >> On 03/29/2013 11:57 PM, nov matake wrote: >>> oops sorry, not draft07, but draft06. >>>=20 >>> On 2013/03/30, at 12:55, nov matake wrote: >>>=20 >>>> Hi Justin, >>>>=20 >>>> I read the latest draft and found endpoints described in the spec = returns 403 in "no such clients" case. >>>> I also read the draft07's editor note below, so I can understand = the situation. >>>>=20 >>>> [[ Editor's note: If the client doesn't exist, >>>> then the Refresh Access Token shouldn't be valid, making this kind = of >>>> error a 403 at the auth layer instead. How best to call this >>>> inconsistency out? ]] >>>>=20 >>>> However, in my current implementation, the server returns 401 if an = access token is given but there are no valid access token in its DB. >>>> In my case, validation for the given access token is done in = middleware layer, so I don't want to change the error code per endpoint. >>>> In such case, client registration/read/update/delete endpoints can = return 401 error? >>>>=20 >>>> Thanks >>>>=20 >>>> -- >>>> nov >>>>=20 >>>> On 2013/03/30, at 5:53, Justin Richer wrote: >>>>=20 >>>>> New dynamic registration draft is published. Biggest changes here = are the internationalization/localization capabilities that are now = applicable to human-readable client metadata fields. >>>>>=20 >>>>> -- Justin >>>>>=20 >>>>> On 03/29/2013 04:38 PM, internet-drafts@ietf.org wrote: >>>>>> A New Internet-Draft is available from the on-line = Internet-Drafts directories. >>>>>> This draft is a work item of the Web Authorization Protocol = Working Group of the IETF. >>>>>>=20 >>>>>> Title : OAuth 2.0 Dynamic Client Registration Protocol >>>>>> Author(s) : Justin Richer >>>>>> John Bradley >>>>>> Michael B. Jones >>>>>> Maciej Machulak >>>>>> Filename : draft-ietf-oauth-dyn-reg-09.txt >>>>>> Pages : 23 >>>>>> Date : 2013-03-29 >>>>>>=20 >>>>>> Abstract: >>>>>> This specification defines an endpoint and protocol for dynamic >>>>>> registration of OAuth 2.0 Clients at an Authorization Server and >>>>>> methods for the dynamically registered client to manage its >>>>>> registration. >>>>>>=20 >>>>>>=20 >>>>>> The IETF datatracker status page for this draft is: >>>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg >>>>>>=20 >>>>>> There's also a htmlized version available at: >>>>>> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-09 >>>>>>=20 >>>>>> A diff from the previous version is available at: >>>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-09 >>>>>>=20 >>>>>>=20 >>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 From jricher@mitre.org Mon Apr 1 10:49:34 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C8B521E809D for ; Mon, 1 Apr 2013 10:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AfSCoYuXaho1 for ; Mon, 1 Apr 2013 10:49:33 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC4921E8099 for ; Mon, 1 Apr 2013 10:49:33 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C1F521F058F; Mon, 1 Apr 2013 13:49:32 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id B60211F057F; Mon, 1 Apr 2013 13:49:32 -0400 (EDT) Received: from [10.146.15.29] (129.83.31.58) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.342.3; Mon, 1 Apr 2013 13:49:17 -0400 Message-ID: <5159C849.7020804@mitre.org> Date: Mon, 1 Apr 2013 13:47:53 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: nov matake References: <20130329203808.13164.56358.idtracker@ietfa.amsl.com> <5155FF43.6070606@mitre.org> <6851D735-F609-4304-AFE6-3BAA35CE9FC4@gmail.com> <328E6FBA-30A1-49EF-A5A7-32EDC04EF48C@gmail.com> <5159BE2D.3020305@mitre.org> <90F190E8-2E53-46C3-B5A1-05439ECE69F8@gmail.com> In-Reply-To: <90F190E8-2E53-46C3-B5A1-05439ECE69F8@gmail.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [129.83.31.58] Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-09.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 17:49:34 -0000 I think that text is a viable solution -- we didn't want the "ghost client" situation to be 404 for security reasons (to keep people from poking around the registration endpoint). I don't think it's going to happen in practice, but I think it's important to be clear on what to do in this situation. Created an issue to track it here: https://github.com/jricher/oauth-spec/issues/62 -- Justin On 04/01/2013 01:35 PM, nov matake wrote: > [Current] > If the client does not exist on this server, the server MUST return an HTTP 403 Forbidden. > > [Proposed] > If the client does not exist on this server, the server treat the given token as invalid and > MUST return HTTP 401 Unauthorized as described in RFC 6750 Section 3.1. > > On 2013/04/02, at 2:23, nov matake wrote: > >> Thanks for your clarification. >> >> After reading the editor's note in draft06, I felt 401 is more natural than 403. >> (assuming you don't want to use 404 for security reason) >> >> The editor's note is enough detail for the reason of using 401. >> >> Using 403, it's like "the token is valid, but the ghost client has no permission"..? >> >> On 2013/04/02, at 2:04, Justin Richer wrote: >> >>> If the access token isn't valid, then the intent is that the server return whatever is a valid response from OAuth, which as I recall is practically any 400 class error. This behavior for DynReg is outlined in section 5.2 of draft -09. >>> >>> In your case, since you're actually failing on the bad token, you're fine with returning a 401. In other words, by my intent of the text and my understanding of your implementation, you're actually compliant. The problem is that the text made you think otherwise. :) >>> >>> Can you suggest how to make this clearer for developers in the text? >>> >>> -- Justin >>> >>> >>> On 03/29/2013 11:57 PM, nov matake wrote: >>>> oops sorry, not draft07, but draft06. >>>> >>>> On 2013/03/30, at 12:55, nov matake wrote: >>>> >>>>> Hi Justin, >>>>> >>>>> I read the latest draft and found endpoints described in the spec returns 403 in "no such clients" case. >>>>> I also read the draft07's editor note below, so I can understand the situation. >>>>> >>>>> [[ Editor's note: If the client doesn't exist, >>>>> then the Refresh Access Token shouldn't be valid, making this kind of >>>>> error a 403 at the auth layer instead. How best to call this >>>>> inconsistency out? ]] >>>>> >>>>> However, in my current implementation, the server returns 401 if an access token is given but there are no valid access token in its DB. >>>>> In my case, validation for the given access token is done in middleware layer, so I don't want to change the error code per endpoint. >>>>> In such case, client registration/read/update/delete endpoints can return 401 error? >>>>> >>>>> Thanks >>>>> >>>>> -- >>>>> nov >>>>> >>>>> On 2013/03/30, at 5:53, Justin Richer wrote: >>>>> >>>>>> New dynamic registration draft is published. Biggest changes here are the internationalization/localization capabilities that are now applicable to human-readable client metadata fields. >>>>>> >>>>>> -- Justin >>>>>> >>>>>> On 03/29/2013 04:38 PM, internet-drafts@ietf.org wrote: >>>>>>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>>>>>> This draft is a work item of the Web Authorization Protocol Working Group of the IETF. >>>>>>> >>>>>>> Title : OAuth 2.0 Dynamic Client Registration Protocol >>>>>>> Author(s) : Justin Richer >>>>>>> John Bradley >>>>>>> Michael B. Jones >>>>>>> Maciej Machulak >>>>>>> Filename : draft-ietf-oauth-dyn-reg-09.txt >>>>>>> Pages : 23 >>>>>>> Date : 2013-03-29 >>>>>>> >>>>>>> Abstract: >>>>>>> This specification defines an endpoint and protocol for dynamic >>>>>>> registration of OAuth 2.0 Clients at an Authorization Server and >>>>>>> methods for the dynamically registered client to manage its >>>>>>> registration. >>>>>>> >>>>>>> >>>>>>> The IETF datatracker status page for this draft is: >>>>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg >>>>>>> >>>>>>> There's also a htmlized version available at: >>>>>>> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-09 >>>>>>> >>>>>>> A diff from the previous version is available at: >>>>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dyn-reg-09 >>>>>>> >>>>>>> >>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 sberyozkin@gmail.com Wed Apr 3 01:19:22 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD00B21F8630 for ; Wed, 3 Apr 2013 01:19:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.143 X-Spam-Level: X-Spam-Status: No, score=-0.143 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_PBL=0.905, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tqgh1q+0Vl4F for ; Wed, 3 Apr 2013 01:19:14 -0700 (PDT) Received: from mail-bk0-x22e.google.com (mail-bk0-x22e.google.com [IPv6:2a00:1450:4008:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 5A2E821F8617 for ; Wed, 3 Apr 2013 01:19:13 -0700 (PDT) Received: by mail-bk0-f46.google.com with SMTP id je9so651686bkc.33 for ; Wed, 03 Apr 2013 01:19:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=wf/20jx13Pz59lyz6k4tigKrt0r1PP7PT7yx0mqxhok=; b=Q3Tc6DQqrAT0xTkGsky7Y8dOOGSh4xmJlnDqmLwLLTCNYhrzIbTB1bzqmYNHiiKPdW 00/KFd9kYfe72svthhC8lFBn7aB4tXqqaIHNWgiy0LAgNGg53Ja8wt+oNTtD3u8k8z2+ GBVO89k/Fg85gVhAn1DqCcCGujm8NvhYB3oPnqWPksZL5A0CZKBPcrN3wuzJR+7DZKaK ggKzJoS1NXI0qBIkRMvaU8Dq0x7pht1y3jiy5dAJDBqRxPpIXJ5sVk8Amm2HupXI5eG9 BO++r9/A7M02NbgR45J3uXW5TYk/wrCcUdAu2ScoGKc/YcCKiro8lxcv5W1wlFAz060W VRsg== X-Received: by 10.205.139.71 with SMTP id iv7mr490368bkc.86.1364977152123; Wed, 03 Apr 2013 01:19:12 -0700 (PDT) Received: from [10.39.0.31] ([87.252.227.100]) by mx.google.com with ESMTPS id cr6sm2016444bkb.2.2013.04.03.01.19.09 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Apr 2013 01:19:10 -0700 (PDT) Message-ID: <515BE5D3.70109@gmail.com> Date: Wed, 03 Apr 2013 11:18:27 +0300 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Shane B Weeden References: <51500319.7080907@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth mobile flow X-BeenThere: oauth@ietf.org X-Mailman-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, 03 Apr 2013 08:19:22 -0000 Hi Shane, All, The info below (and the links shared by others) is useful, thanks, I have a single question really which hopefully won't be off-topic, On 25/03/13 14:55, Shane B Weeden wrote: > What I did in my OAuth 2.0 server environment was allow a client to > self-register without a redirect URI. If they do that, then use the azncode > flow, the azncode is displayed on the screen and the resource owner figures > out for themselves how to get it to the client. Quite similar in principal > to oob in OAuth 1.0 as you suggested. And yes - you can even try that > pattern out for yourself on my demo OAuth server. Take a read of > https://www-304.ibm.com/connections/blogs/sweeden/entry/oauth_demonstration_environment > for details on how to get yourself a client_id. I do some custom stuff for > mobileClient - like shrink the authorization code to six lowercase chars > and reduce it's lifetime to 60 seconds so it can be more easily typed into > a phone keyboard, but ultimately that's just config. > > In my demos you saw two options for delivery - type it in, or scan it in > via QR. Obviously there are several security and operational considerations > to think about, but ultimately provided the resource owner does securely > deliver the code to the client it's fundamentally ok. You can get more > elaborate than that for mobile scenarios - for example you can use a web > view of the mobile application itself to interact with the resource owner > then send the azncode back via a push notification service. This has rouge > app / password phishing implications that I don't like and is no better > from a security perspective than doing resource owner password credentials > flow with a public client id, but again it's still a possibility. Why do you refer to the "resource owner password credentials flow" with a public client id ? I see that the resource owner does indeed authenticate and then authorizes a given mobile client application, but effectively it is an authorization code flow 'minus' the redirect from the confidential client (which the mobile app is not in this case), so the RO simply directly invokes on the authorization endpoint, omitting an otherwise required "redirect_uri" - which in itself is not a RO password credentials flow. As a side note I guess I also start appreciating how does a token endpoint can 'authenticate' a public client like 'mobileClient' without it also offering a password/etc, the assumption is that the code obtained earlier must've been provided to the mobile application securely, so effectively it is the (public) client_id + the grant (whatever it is, securely obtained by the client) that the token endpoint works with: I'm not sure yet if it can affect the common processing path in the token endpoint or not, probably not, because the public client must've been marked as such during the registration, so the token endpoint can accept a client_id only (without any credentials like password), as far as the authentication is concerned Thanks, Sergey > > Regards, > Shane. > > > > > > From: Sergey Beryozkin > To: oauth@ietf.org > Date: 25/03/2013 06:01 PM > Subject: Re: [OAUTH-WG] OAuth mobile flow > Sent by: oauth-bounces@ietf.org > > > > Hi Shane > On 25/03/13 00:54, Shane B Weeden wrote: >> There are several options. I've developed a few based on azn code flow > with >> custom "delivery" of the code, and also resource owner password > credentials >> flow with a public client id (although I personally don't like the idea > of >> ever presenting my real credentials to the phone but business owners seem >> to still want to do that). >> >> These might give you an idea: >> > https://www-304.ibm.com/connections/blogs/sweeden/entry/mobile_oauth_application_demonstration > >> > https://www-304.ibm.com/connections/blogs/sweeden/entry/mobile_demonstration_under_the_hood > >> http://www.youtube.com/watch?v=cLLrZMt_hII > > This is interesting, thank you. > I'm just wondering, how does you application decide that the access > token is to be returned effectively out of band (which reminds me of the > 'oob' redirect uri from OAuth 1.0). > > Looks like the client_id being equal to "mobileClient" (in your demo) is > a hint. > > If yes, then would you (and others) see any benefit in actually > attempting to get an 'oob' redirect_uri value standardized ? (sorry if > this was already raised earlier). > > I can see how I can get a generic framework for supporting writing > OAuth2 applications returning the code directly to the browser even > without having 'oob' redirect uri - example, one can configure the > authorization endpoint to recognize that a particular client_id requires > an out of band delivery of the access token, etc. > > FYI, I like the device code flow you linked to though appreciate the > simplicity of returning the token to the browser in demos, etc... > > Cheers, Sergey > >> >> Regards, >> Shane. >> From sweeden@au1.ibm.com Wed Apr 3 02:53:54 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2797621F8615 for ; Wed, 3 Apr 2013 02:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GMdtHWsZMKgy for ; Wed, 3 Apr 2013 02:53:52 -0700 (PDT) Received: from e23smtp03.au.ibm.com (e23smtp03.au.ibm.com [202.81.31.145]) by ietfa.amsl.com (Postfix) with ESMTP id 1E02021F851C for ; Wed, 3 Apr 2013 02:53:51 -0700 (PDT) Received: from /spool/local by e23smtp03.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 3 Apr 2013 19:46:30 +1000 Received: from d23dlp02.au.ibm.com (202.81.31.213) by e23smtp03.au.ibm.com (202.81.31.209) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 3 Apr 2013 19:46:28 +1000 Received: from d23relay05.au.ibm.com (d23relay05.au.ibm.com [9.190.235.152]) by d23dlp02.au.ibm.com (Postfix) with ESMTP id F10152BB0051 for ; Wed, 3 Apr 2013 20:53:36 +1100 (EST) Received: from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.234.97]) by d23relay05.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r339eHhI6685090 for ; Wed, 3 Apr 2013 20:40:18 +1100 Received: from d23av03.au.ibm.com (loopback [127.0.0.1]) by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r339rZ8V011868 for ; Wed, 3 Apr 2013 20:53:35 +1100 Received: from d23ml004.au.ibm.com (d23ml004.au.ibm.com [9.190.250.23]) by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id r339rZUJ011865; Wed, 3 Apr 2013 20:53:35 +1100 In-Reply-To: <515BE5D3.70109@gmail.com> References: <51500319.7080907@gmail.com> <515BE5D3.70109@gmail.com> X-KeepSent: 3F8DBADE:B68E035B-4A257B42:00311608; type=4; name=$KeepSent To: Sergey Beryozkin X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 Message-ID: From: Shane B Weeden Date: Wed, 3 Apr 2013 19:04:48 +1000 X-MIMETrack: Serialize by Router on d23ml004/23/M/IBM(Release 8.5.3FP2HF29 | July 24, 2012) at 03/04/2013 20:58:07 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13040309-6102-0000-0000-00000341B941 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth mobile flow X-BeenThere: oauth@ietf.org X-Mailman-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, 03 Apr 2013 09:53:54 -0000 The latest demo application I have actually has two modes of registration - the one that I show in the video is indeed the authorization code flow with manual delivery of the code however there is another registration panel which allows the resource owner to type in their U/P and then it does indeed use the resource owner password credentials flow with a public client id. The reason I chose that rather than simple client_credentials flow is that only the resource owner password credentials flow (and azn code) issues a refresh token which is central to the pattern. The rest of your discussion about public clients and the token endpoint authentication is accurate - it is essential that the resource owner securely deliver the authorization code to the client - this is really what is identifying that instance of the client. This is written up reasonably well in the threat model doc. Cheers, Shane. From: Sergey Beryozkin To: Shane B Weeden/Australia/IBM@IBMAU Cc: oauth@ietf.org Date: 03/04/2013 06:23 PM Subject: Re: [OAUTH-WG] OAuth mobile flow Hi Shane, All, The info below (and the links shared by others) is useful, thanks, I have a single question really which hopefully won't be off-topic, On 25/03/13 14:55, Shane B Weeden wrote: > What I did in my OAuth 2.0 server environment was allow a client to > self-register without a redirect URI. If they do that, then use the azncode > flow, the azncode is displayed on the screen and the resource owner figures > out for themselves how to get it to the client. Quite similar in principal > to oob in OAuth 1.0 as you suggested. And yes - you can even try that > pattern out for yourself on my demo OAuth server. Take a read of > https://www-304.ibm.com/connections/blogs/sweeden/entry/oauth_demonstration_environment > for details on how to get yourself a client_id. I do some custom stuff for > mobileClient - like shrink the authorization code to six lowercase chars > and reduce it's lifetime to 60 seconds so it can be more easily typed into > a phone keyboard, but ultimately that's just config. > > In my demos you saw two options for delivery - type it in, or scan it in > via QR. Obviously there are several security and operational considerations > to think about, but ultimately provided the resource owner does securely > deliver the code to the client it's fundamentally ok. You can get more > elaborate than that for mobile scenarios - for example you can use a web > view of the mobile application itself to interact with the resource owner > then send the azncode back via a push notification service. This has rouge > app / password phishing implications that I don't like and is no better > from a security perspective than doing resource owner password credentials > flow with a public client id, but again it's still a possibility. Why do you refer to the "resource owner password credentials flow" with a public client id ? I see that the resource owner does indeed authenticate and then authorizes a given mobile client application, but effectively it is an authorization code flow 'minus' the redirect from the confidential client (which the mobile app is not in this case), so the RO simply directly invokes on the authorization endpoint, omitting an otherwise required "redirect_uri" - which in itself is not a RO password credentials flow. As a side note I guess I also start appreciating how does a token endpoint can 'authenticate' a public client like 'mobileClient' without it also offering a password/etc, the assumption is that the code obtained earlier must've been provided to the mobile application securely, so effectively it is the (public) client_id + the grant (whatever it is, securely obtained by the client) that the token endpoint works with: I'm not sure yet if it can affect the common processing path in the token endpoint or not, probably not, because the public client must've been marked as such during the registration, so the token endpoint can accept a client_id only (without any credentials like password), as far as the authentication is concerned Thanks, Sergey > > Regards, > Shane. > > > > > > From: Sergey Beryozkin > To: oauth@ietf.org > Date: 25/03/2013 06:01 PM > Subject: Re: [OAUTH-WG] OAuth mobile flow > Sent by: oauth-bounces@ietf.org > > > > Hi Shane > On 25/03/13 00:54, Shane B Weeden wrote: >> There are several options. I've developed a few based on azn code flow > with >> custom "delivery" of the code, and also resource owner password > credentials >> flow with a public client id (although I personally don't like the idea > of >> ever presenting my real credentials to the phone but business owners seem >> to still want to do that). >> >> These might give you an idea: >> > https://www-304.ibm.com/connections/blogs/sweeden/entry/mobile_oauth_application_demonstration > >> > https://www-304.ibm.com/connections/blogs/sweeden/entry/mobile_demonstration_under_the_hood > >> http://www.youtube.com/watch?v=cLLrZMt_hII > > This is interesting, thank you. > I'm just wondering, how does you application decide that the access > token is to be returned effectively out of band (which reminds me of the > 'oob' redirect uri from OAuth 1.0). > > Looks like the client_id being equal to "mobileClient" (in your demo) is > a hint. > > If yes, then would you (and others) see any benefit in actually > attempting to get an 'oob' redirect_uri value standardized ? (sorry if > this was already raised earlier). > > I can see how I can get a generic framework for supporting writing > OAuth2 applications returning the code directly to the browser even > without having 'oob' redirect uri - example, one can configure the > authorization endpoint to recognize that a particular client_id requires > an out of band delivery of the access token, etc. > > FYI, I like the device code flow you linked to though appreciate the > simplicity of returning the token to the browser in demos, etc... > > Cheers, Sergey > >> >> Regards, >> Shane. >> From internet-drafts@ietf.org Sun Apr 7 05:16:21 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9934421F8E99; Sun, 7 Apr 2013 05:16:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.468 X-Spam-Level: X-Spam-Status: No, score=-102.468 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AQJmrfTKyQig; Sun, 7 Apr 2013 05:16:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 68F6521F8E6C; Sun, 7 Apr 2013 05:16:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p3 Message-ID: <20130407121620.16308.82230.idtracker@ietfa.amsl.com> Date: Sun, 07 Apr 2013 05:16:20 -0700 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-06.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: Sun, 07 Apr 2013 12:16:21 -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 Group = of the IETF. Title : Token Revocation Author(s) : Torsten Lodderstedt Stefanie Dronia Marius Scurtescu Filename : draft-ietf-oauth-revocation-06.txt Pages : 9 Date : 2013-04-07 Abstract: This document proposes an additional endpoint for OAuth authorization servers, which allows clients to notify the authorization server that a previously obtained refresh or access token is no longer needed. This allows the authorization server to cleanup security credentials. A revocation request will invalidate the actual token and, if applicable, other tokens based on the same authorization grant. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-revocation There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-revocation-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-revocation-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From hannes.tschofenig@gmx.net Sun Apr 7 07:45:58 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12EAE21F8DFB for ; Sun, 7 Apr 2013 07:45:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.356 X-Spam-Level: X-Spam-Status: No, score=-103.356 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599, 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 u03uuOfzG7bF for ; Sun, 7 Apr 2013 07:45:57 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 9D93A21F8DD6 for ; Sun, 7 Apr 2013 07:45:56 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.2]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0M2aaZ-1UhCeG2RQT-00sOkd for ; Sun, 07 Apr 2013 16:45:49 +0200 Received: (qmail invoked by alias); 07 Apr 2013 14:45:49 -0000 Received: from a88-115-219-140.elisa-laajakaista.fi (EHLO [192.168.100.101]) [88.115.219.140] by mail.gmx.net (mp002) with SMTP; 07 Apr 2013 16:45:49 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX198woR/4KB8CuQSIYsL9jzos8tfIpOBWlm86QbR9l bWqtY0Cw+a3oVN From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 7 Apr 2013 17:45:45 +0300 Message-Id: <3E010484-F42F-42F7-A36D-F86223047777@gmx.net> To: ext The IESG , Stephen Farrell Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org WG" Subject: [OAUTH-WG] Shepherd Writeup for draft-ietf-oauth-revocation-06 X-BeenThere: oauth@ietf.org X-Mailman-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, 07 Apr 2013 14:45:58 -0000 Dear Stephen, Dear IESG Secretary,=20 here is my shepherd writeup for . Please = proceed with the publication of this document.=20 ------------------------------- (1) What type of RFC is being requested (BCP, Proposed Standard, = Internet Standard, Informational, Experimental, or Historic)? Why is = this the proper type of RFC? Is this type of RFC indicated in the title = page header? The RFC type being requested in Standards Track. The type is appropriate = for this type of OAuth protocol extension.=20 (2) The IESG approval announcement includes a Document Announcement = Write-Up. Please provide such a Document Announcement Write-Up. Recent = examples can be found in the "Action" announcements for approved = documents. The approval announcement contains the following sections: Technical Summary: Relevant content can frequently be found in the abstract and/or = introduction of the document. If not, this may be an indication that = there are deficiencies in the abstract or introduction. The OAuth Token Revocation specification proposes an additional = endpoint for OAuth authorization servers, which allows clients to notify the authorization server that a previously obtained refresh or access token is no longer needed. This allows the authorization server to cleanup security credentials. A revocation request will invalidate the actual token and, if applicable, other tokens based on the same authorization grant. =20 Working Group Summary: The document experienced no particular problems in the working group.=20 Document Quality: The document has been deployed by four companies, namely by Salesforce, = Google, Deutsche Telekom, and MITRE. The working group reviewed and discussed the document extensively.=20 Personnel: Hannes Tschofenig is the document shepherd. The responsible area = director is Stephen Farrell.=20 (3) Briefly describe the review of this document that was performed by = the Document Shepherd. I have reviewed this version of the document and provided feedback to = earlier versions of the draft.=20 The document is ready for publication.=20 (4) Does the document Shepherd have any concerns about the depth or = breadth of the reviews that have been performed? I have no concerns about the level of reviews.=20 (5) Do portions of the document need review from a particular or from = broader perspective, e.g., security, operational complexity, AAA, DNS, = DHCP, XML, or internationalization? If so, describe the review that took = place. No, there is no need for further reviews.=20 (6) Describe any specific concerns or issues that the Document Shepherd = has with this document that the Responsible Area Director and/or the = IESG should be aware of? For example, perhaps he or she is uncomfortable = with certain parts of the document, or has concerns whether there really = is a need for it. In any event, if the WG has discussed those issues and = has indicated that it still wishes to advance the document, detail those = concerns here. I have no concerns regarding the document.=20 (7) Has each author confirmed that any and all appropriate IPR = disclosures required for full conformance with the provisions of BCP 78 = and BCP 79 have already been filed. If not, explain why? Two of the three authors have confirmed that they are not aware of any = IPRs. Marius Scurtescu so far has not responded to my mails.=20 (8) Has an IPR disclosure been filed that references this document? If = so, summarize any WG discussion and conclusion regarding the IPR = disclosures. There are no IPR disclosures available for this document.=20 (9) How solid is the WG consensus behind this document? Does it = represent the strong concurrence of a few individuals, with others being = silent, or does the WG as a whole understand and agree with it? The working group is in support of this document.=20 (10) Has anyone threatened an appeal or otherwise indicated extreme = discontent? If so, please summarise the areas of conflict in separate = email messages to the Responsible Area Director. (It should be in a = separate email because this questionnaire is publicly available.) There has been no extreme discontent.=20 (11) Identify any ID nits the Document Shepherd has found in this = document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts = Checklist). Boilerplate checks are not enough; this check needs to be = thorough. ID nits have been verified. There is one reference ([portable-contacts]) = that is not used in the document that has to be removed with the next = draft update or by the RFC Editor. (12) Describe how the document meets any required formal review = criteria, such as the MIB Doctor, media type, and URI type reviews. The document does not contain content that requires formal reviews.=20 (13) Have all references within this document been identified as either = normative or informative? Yes.=20 (14) Are there normative references to documents that are not ready for = advancement or are otherwise in an unclear state? If such normative = references exist, what is the plan for their completion? All normative references are published RFCs already.=20 (15) Are there downward normative references references (see RFC 3967)? = If so, list these downward references to support the Area Director in = the Last Call procedure. There are no downward references.=20 (16) Will publication of this document change the status of any existing = RFCs? Are those RFCs listed on the title page header, listed in the = abstract, and discussed in the introduction? If the RFCs are not listed = in the Abstract and Introduction, explain why, and point to the part of = the document where the relationship of this document to the other RFCs = is discussed. If this information is not in the document, explain why = the WG considers it unnecessary. This document will not change the status of existing RFCs.=20 (17) Describe the Document Shepherd's review of the IANA considerations = section, especially with regard to its consistency with the body of the = document. Confirm that all protocol extensions that the document makes = are associated with the appropriate reservations in IANA registries. = Confirm that any referenced IANA registries have been clearly = identified. Confirm that newly created IANA registries include a = detailed specification of the initial contents for the registry, that = allocations procedures for future registrations are defined, and a = reasonable name for the new registry has been suggested (see RFC 5226). This document defines a new error code and follows the requirements in = RFC 6749.=20 (18) List any new IANA registries that require Expert Review for future = allocations. Provide any public guidance that the IESG would find useful = in selecting the IANA Experts for these new registries. The shepherd is currently the expert for RFC 6749 IANA registry = allocations.=20 (19) Describe reviews and automated checks performed by the Document = Shepherd to validate sections of the document written in a formal = language, such as XML code, BNF rules, MIB definitions, etc. No text written in a formal language is contained in the document.=20 ------------------------------- Ciao Hannes From stephen.farrell@cs.tcd.ie Sun Apr 7 07:47:59 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB65121F8E5A for ; Sun, 7 Apr 2013 07:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NvS9JxWeX41G for ; Sun, 7 Apr 2013 07:47:59 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id C1C7621F8E63 for ; Sun, 7 Apr 2013 07:47:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 31CDEBE35; Sun, 7 Apr 2013 15:47:37 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dGg7uRFFXpFH; Sun, 7 Apr 2013 15:47:32 +0100 (IST) Received: from [10.87.48.5] (unknown [86.46.27.148]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 14EAFBE5B; Sun, 7 Apr 2013 15:47:32 +0100 (IST) Message-ID: <51618703.1090906@cs.tcd.ie> Date: Sun, 07 Apr 2013 15:47:31 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: Hannes Tschofenig References: <3E010484-F42F-42F7-A36D-F86223047777@gmx.net> In-Reply-To: <3E010484-F42F-42F7-A36D-F86223047777@gmx.net> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Shepherd Writeup for draft-ietf-oauth-revocation-06 X-BeenThere: oauth@ietf.org X-Mailman-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, 07 Apr 2013 14:48:00 -0000 Thanks, If you don't see an AD review by the middle of next week please hassle me, Cheers, S. On 04/07/2013 03:45 PM, Hannes Tschofenig wrote: > Dear Stephen, Dear IESG Secretary, > > here is my shepherd writeup for . Please proceed with the publication of this document. > > ------------------------------- > > (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? > > The RFC type being requested in Standards Track. The type is appropriate for this type of OAuth protocol extension. > > (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: > > Technical Summary: > > Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. > > > The OAuth Token Revocation specification proposes an additional endpoint for OAuth authorization > servers, which allows clients to notify the authorization server that > a previously obtained refresh or access token is no longer needed. > This allows the authorization server to cleanup security credentials. > A revocation request will invalidate the actual token and, if > applicable, other tokens based on the same authorization grant. > > > Working Group Summary: > > The document experienced no particular problems in the working group. > > Document Quality: > > The document has been deployed by four companies, namely by Salesforce, Google, Deutsche Telekom, and MITRE. > The working group reviewed and discussed the document extensively. > > Personnel: > > Hannes Tschofenig is the document shepherd. The responsible area director is Stephen Farrell. > > (3) Briefly describe the review of this document that was performed by the Document Shepherd. > > I have reviewed this version of the document and provided feedback to earlier versions of the draft. > The document is ready for publication. > > (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? > > I have no concerns about the level of reviews. > > (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. > > No, there is no need for further reviews. > > (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. > > I have no concerns regarding the document. > > (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? > > Two of the three authors have confirmed that they are not aware of any IPRs. Marius Scurtescu so far has not responded to my mails. > > (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. > > There are no IPR disclosures available for this document. > > (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? > > The working group is in support of this document. > > (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) > > There has been no extreme discontent. > > (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. > > ID nits have been verified. There is one reference ([portable-contacts]) that is not used in the document that has to be removed with the next draft update or by the RFC Editor. > > (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. > > The document does not contain content that requires formal reviews. > > (13) Have all references within this document been identified as either normative or informative? > > Yes. > > (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? > > All normative references are published RFCs already. > > (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. > > There are no downward references. > > (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. > > This document will not change the status of existing RFCs. > > (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). > > This document defines a new error code and follows the requirements in RFC 6749. > > (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. > > The shepherd is currently the expert for RFC 6749 IANA registry allocations. > > (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. > > No text written in a formal language is contained in the document. > > ------------------------------- > > Ciao > Hannes > > > From stephen.farrell@cs.tcd.ie Tue Apr 9 10:28:23 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FD6321F93B2 for ; Tue, 9 Apr 2013 10:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.382 X-Spam-Level: X-Spam-Status: No, score=-102.382 tagged_above=-999 required=5 tests=[AWL=0.217, 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 uMykjJSd0Stu for ; Tue, 9 Apr 2013 10:28:19 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 2052521F9156 for ; Tue, 9 Apr 2013 10:28:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6C766BE61 for ; Tue, 9 Apr 2013 18:27:54 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IE5Y4y65pcwx for ; Tue, 9 Apr 2013 18:27:54 +0100 (IST) Received: from [IPv6:2001:770:10:203:54d4:67d3:a46c:a5f2] (unknown [IPv6:2001:770:10:203:54d4:67d3:a46c:a5f2]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 35012BE58 for ; Tue, 9 Apr 2013 18:27:54 +0100 (IST) Message-ID: <51644F9A.9040402@cs.tcd.ie> Date: Tue, 09 Apr 2013 18:27:54 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: "oauth@ietf.org" X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [OAUTH-WG] AD review of draft-ietf-oauth-revocation-06 X-BeenThere: oauth@ietf.org X-Mailman-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, 09 Apr 2013 17:28:23 -0000 Hi, I've done my AD review of this draft. I have two quick questions I'd like to get answered before I start IETF LC. Depending on the answers maybe we should re-spin or just fire ahead, let's see... (1) 2.1: "upon the return of the request" isn't right is it? I think you mean the response at least. And what about HTTP error handling? What if I get a 503 error? Is the client supposed to re-send ever? Don't you need to say? (2) 2.2: what's in the response body with a 200 response? If it doesn't matter please say so. I see from the write-up one author hasn't confirmed there are no IPR issues. I've sent a Marius a mail so hopefully we can sort that as we go. I also have the following nits that can be fixed (if need be) whenever the draft is next changed: - intro: "app" isn't really a great term to use, can you replace with something from 6479. - section 2: the "MAY include a query component" is sort of dangling there, maybe it'd be better moved elsewhere? - section 2: "MUST be obtained from a trustworthy source." might generate comment from IESG members who don't like using 2119 terms in ways that don't affect interoperability. (I'm fine with it fwiw, and have nearly cured 'em of that craze;-) Consider s/MUST/need to/ here. - 2.1: ought there be a registry for token_type_hint values? It looks like maybe there ought be. - 2.1: "A client compliant with [RFC6749] must be prepared" was that meant to be a 2119 MUST? - section 6: maybe s/shall/need to/ in the last para Cheers, S. From phil.hunt@oracle.com Wed Apr 10 10:41:05 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A6AC21F8E4E for ; Wed, 10 Apr 2013 10:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5yBkezKHxqSc for ; Wed, 10 Apr 2013 10:41:04 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id C388821F8F4E for ; Wed, 10 Apr 2013 10:41:03 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r3AHf2kA031225 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 10 Apr 2013 17:41:03 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r3AHf1W2015824 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 10 Apr 2013 17:41:02 GMT Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r3AHf1Zf015820 for ; Wed, 10 Apr 2013 17:41:01 GMT Received: from [192.168.1.14] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 10 Apr 2013 10:41:01 -0700 From: Phil Hunt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 10 Apr 2013 10:39:38 -0700 Message-Id: <8214AB9C-F723-4C15-81F6-26A99A8B6C67@oracle.com> To: "oauth@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Subject: [OAUTH-WG] Comments about draft-ietf-oauth-json-web-token-06 - authorization and assertion tokens are different X-BeenThere: oauth@ietf.org X-Mailman-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, 10 Apr 2013 17:41:05 -0000 I keep hearing a lot of questions about the JWT token draft and in = particular what should go in "sub" (Subject) claim. In the context of an = access token, there is confusion about whether it is the resource owner = or the client. Part of the problem is that JWT's can be used in multiple different = ways. Thus content can and should vary: 1. An identity assertions (such as an authentication) 2. As access tokens (such as an authorization) In the OAuth context then, 1 is input to the authorization process and = it seems reasonable to follow typical terminology and profiles found in = classic federation. But under 2, this terminology seems week since it = doesn't express what an access token should necessarily express. An = access token should problem carry the following in order of priority: 1. An integrity check (either in the token itself or a lookup via RS to = AS call) 2. A positive access control decision (authorizing a set of = scopes/roles/rights) the bearer may have 3. Security session information (see openid connect for example) 4. Identity claims (of the resource owner and/or the client app and/or = other intermediary parties) When it comes to access tokens, it seems reasonable that in some cases, = 3 and 4 may not even be present. Particularly if the bearer or = authorizing resource owner needs to be anonymized. What matters is that = the bearer of the token has the right to access a resource. In other = cases, 4 is needed in part to facilitate JIT provisioning. My concern is that the current JWT spec is too biased towards passing = identity assertions and is not neutral enough for authorization = information. I would rather see the JWT spec do both jobs, or be a = foundational spec for 2 or more profiles that do assertions or = authorizations. Phil @independentid www.independentid.com phil.hunt@oracle.com From ecs.accenture@gmail.com Mon Apr 8 04:55:47 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4DFF21F8E59 for ; Mon, 8 Apr 2013 04:55:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lYfe5OMOId8O for ; Mon, 8 Apr 2013 04:55:33 -0700 (PDT) Received: from mail-ve0-f196.google.com (mail-ve0-f196.google.com [209.85.128.196]) by ietfa.amsl.com (Postfix) with ESMTP id 3DB5021F8DA0 for ; Mon, 8 Apr 2013 04:55:32 -0700 (PDT) Received: by mail-ve0-f196.google.com with SMTP id m1so1221939ves.3 for ; Mon, 08 Apr 2013 04:55:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=lNj4lGoHHhaDOZqjmtdkn5mEFctYzeMyyBmO6KA1HeM=; b=xe48JHfhTkv7ChM65SL8hDhdES2YdKeiVyO/zFG4Yqr1b6Vx23jOPqhacWgBEoX3YR WcYZUER7mNjkDRGXBvIrAtNbeWuyB5gIP2fzs0OaEhBhF6OfH+TAdqxej0IbOZhKYyek RqUjo8zriv21XIoC47dDooS9QD47SlJ1538aqura3awawP4gyCQe/XEfgpzB9kEsUe27 TvjmB2YKNjMJh87jomYgLSuGzRC7i3p+TLdiARxloteBgSj0qRDNB9Dv3I7iz2uHUiWe m8E7cukZSN2VeU7qDdzDXIMtqifCox6+cpQVU7J9PjpJ1m1JEH5LdqdfHLFE+nzPTccW 5EXA== MIME-Version: 1.0 X-Received: by 10.220.9.3 with SMTP id j3mr15498155vcj.56.1365422131454; Mon, 08 Apr 2013 04:55:31 -0700 (PDT) Received: by 10.220.66.146 with HTTP; Mon, 8 Apr 2013 04:55:31 -0700 (PDT) In-Reply-To: References: Date: Mon, 8 Apr 2013 17:25:31 +0530 Message-ID: From: ECS ACCENTURE To: oauth@ietfa.amsl.com Content-Type: multipart/alternative; boundary=bcaec54ee0141d596804d9d81dbf X-Mailman-Approved-At: Fri, 12 Apr 2013 07:41:39 -0700 Subject: Re: [OAUTH-WG] For facebook desktop application acces tocken X-BeenThere: oauth@ietf.org X-Mailman-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, 08 Apr 2013 11:57:56 -0000 --bcaec54ee0141d596804d9d81dbf Content-Type: text/plain; charset=ISO-8859-1 > Hi, > > I am following this link : > http://developers.facebook.com/docs/opengraph/howtos/publishing-with-app-token/ > to generate permanent access tocken for my web application. > > HTTP GET request: > https://graph.facebook.com/oauth/access_token? > client_id=YOUR_APP_ID > &client_secret=YOUR_APP_SECRET > &grant_type=client_credentials > > Response: > > { > "error": { > "message": "Invalid callback", > "type":"OAuthException", > "code": 1 > } > } > > For facebook desktop application, how can I get the permanent access > token? > Secondly, how can I know what are the users the application is authorized > by ? > > > could you please provide me any suggestion or links for this issue. > > Regards, > AppFactory. > --bcaec54ee0141d596804d9d81dbf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,
=A0
I am following this link : http://d= evelopers.facebook.com/docs/opengraph/howtos/publishing-with-app-token/= =A0 to generate permanent access tocken for my web application.
=A0
HTTP GET request:
=A0https://graph.facebook.com/oauth/access_token= ?
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 client_id=3DYOUR_APP_ID
=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 &client_secret=3DYOUR_APP_SECRET
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 &grant_type=3Dclient_credentials
=A0
Response:
=A0
{
=A0=A0"error": {
=A0=A0=A0=A0"message":=A0= "Invalid callback",
=A0=A0=A0=A0"type"= :"OAuthException",
=A0=A0=A0=A0"code":= =A01
=A0=A0}
}
=A0
For facebook desktop application, how can I get the permanent=A0 acces= s token?
Secondly, how can I know what are the users the application is authori= zed by ?
=A0
=A0
could you please provide me any suggestion or links for this issue.
=A0
Regards,
AppFactory.

--bcaec54ee0141d596804d9d81dbf-- From ecs.accenture@gmail.com Mon Apr 8 04:39:12 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB7D421F929E for ; Mon, 8 Apr 2013 04:39:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJqa3MZMrbcX for ; Mon, 8 Apr 2013 04:39:12 -0700 (PDT) Received: from mail-vc0-f195.google.com (mail-vc0-f195.google.com [209.85.220.195]) by ietfa.amsl.com (Postfix) with ESMTP id F18D421F9299 for ; Mon, 8 Apr 2013 04:39:11 -0700 (PDT) Received: by mail-vc0-f195.google.com with SMTP id gd11so358348vcb.2 for ; Mon, 08 Apr 2013 04:39:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=JQuetpPk/XYzSEY8p7syg7UyFAzWrZWhFDakRAwJAiY=; b=UlMSAt6Ssm8aFYZtPe5US4GgWF7Ui5TxEQWwQJ4+BNmNYppZ4eMDNMkXSze3oRdOrM WJRYca4V2I2ggce3Y8HBIsH1q1mz86bGFk7mRZ9f3x5YiSBMwY05nvqXL/6XH+RJsEPd kAyA2wlBGYAK5mFo6vgMaFdA3DLSpyGmjJ1hcTKrYa8o+pajlslYWuNopj1Xdzlx3QNr 0Y6cyqab+lTAMYALH2vpS3vp4mqclOrNcyeirOw6qd+Gw08/mRopm+s90W3XdMuKZTkM 2b7px4afwT9ozVTU7ucBRiJeHhQTBEY5FoSHEHN+SMGhlqQoZdNItEUWCDnvMDHJLTwa 2U6Q== MIME-Version: 1.0 X-Received: by 10.52.178.161 with SMTP id cz1mr12926324vdc.7.1365421151414; Mon, 08 Apr 2013 04:39:11 -0700 (PDT) Received: by 10.220.66.146 with HTTP; Mon, 8 Apr 2013 04:39:11 -0700 (PDT) Date: Mon, 8 Apr 2013 17:09:11 +0530 Message-ID: From: ECS ACCENTURE To: oauth@ietf.org Content-Type: multipart/alternative; boundary=bcaec519644bb31cf304d9d7e269 X-Mailman-Approved-At: Fri, 12 Apr 2013 07:41:39 -0700 Subject: [OAUTH-WG] For facebook desktop application acces tocken X-BeenThere: oauth@ietf.org X-Mailman-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, 08 Apr 2013 11:58:34 -0000 --bcaec519644bb31cf304d9d7e269 Content-Type: text/plain; charset=ISO-8859-1 Hi, I am following this link : http://developers.facebook.com/docs/opengraph/howtos/publishing-with-app-token/ to generate permanent access tocken for my web application. HTTP GET request: https://graph.facebook.com/oauth/access_token? client_id=YOUR_APP_ID &client_secret=YOUR_APP_SECRET &grant_type=client_credentials Response: { "error": { "message": "Invalid callback", "type":"OAuthException", "code": 1 } } For facebook desktop application, how can I get the permanent access token? Secondly, how can I know what are the users the application is authorized by ? could you please provide me any suggestion or links for this issue. Regards, AppFactory. --bcaec519644bb31cf304d9d7e269 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,
=A0
I am following this link : http://d= evelopers.facebook.com/docs/opengraph/howtos/publishing-with-app-token/= =A0 to generate permanent access tocken for my web application.
=A0
HTTP GET request:
=A0https://graph.facebook.com/oauth/access_token= ?
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 client_id=3DYOUR_APP_ID
=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 &client_secret=3DYOUR_APP_SECRET
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 &grant_type=3Dclient_credentials
=A0
Response:
=A0
{
=A0=A0"error": {
=A0=A0=A0=A0"message":=A0= "Invalid callback",
=A0=A0= =A0=A0"type":"OAuthException&quo= t;,
=A0=A0=A0=A0"code":=A01
=A0=A0}
}
=A0
For facebook desktop application, how can I get the permanent=A0 acces= s token?
Secondly, how can I know what are the users the application is authori= zed by ?
=A0
=A0
could you please provide me any suggestion or links for this issue.
=A0
Regards,
AppFactory.
--bcaec519644bb31cf304d9d7e269-- From jricher@mitre.org Fri Apr 12 07:51:21 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C21F021F8C08 for ; Fri, 12 Apr 2013 07:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9eA6HAdyQtHj for ; Fri, 12 Apr 2013 07:51:21 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id CEFC321F84DC for ; Fri, 12 Apr 2013 07:51:20 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 4041E1F0600; Fri, 12 Apr 2013 10:51:20 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 2C6E11F0371; Fri, 12 Apr 2013 10:51:20 -0400 (EDT) Received: from [10.146.15.29] (129.83.31.58) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.2.342.3; Fri, 12 Apr 2013 10:51:19 -0400 Message-ID: <51681F62.2060505@mitre.org> Date: Fri, 12 Apr 2013 10:51:14 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: ECS ACCENTURE References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------050206050207090408090901" X-Originating-IP: [129.83.31.58] Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] For facebook desktop application acces tocken X-BeenThere: oauth@ietf.org X-Mailman-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, 12 Apr 2013 14:51:21 -0000 --------------050206050207090408090901 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit This is a question better directed at Facebook's developers community since it's more specific to Facebook's API. I would suggest posting your question to StackOverflow: http://stackoverflow.com/ -- Justin On 04/08/2013 07:39 AM, ECS ACCENTURE wrote: > Hi, > I am following this link : > http://developers.facebook.com/docs/opengraph/howtos/publishing-with-app-token/ > to generate permanent access tocken for my web application. > HTTP GET request: > https://graph.facebook.com/oauth/access_token? > client_id=YOUR_APP_ID > &client_secret=YOUR_APP_SECRET > &grant_type=client_credentials > Response: > { > "error": { > "message": "Invalid callback", > "type":"OAuthException", > "code": 1 > } > } > For facebook desktop application, how can I get the permanent access > token? > Secondly, how can I know what are the users the application is > authorized by ? > could you please provide me any suggestion or links for this issue. > Regards, > AppFactory. > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------050206050207090408090901 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit This is a question better directed at Facebook's developers community since it's more specific to Facebook's API. I would suggest posting your question to StackOverflow:

http://stackoverflow.com/

 -- Justin

On 04/08/2013 07:39 AM, ECS ACCENTURE wrote:
Hi,
 
I am following this link : http://developers.facebook.com/docs/opengraph/howtos/publishing-with-app-token/  to generate permanent access tocken for my web application.
 
HTTP GET request:
 https://graph.facebook.com/oauth/access_token?
            client_id=YOUR_APP_ID
           &client_secret=YOUR_APP_SECRET
           &grant_type=client_credentials
 
Response:
 
{
  "error": {
    "message": "Invalid callback",
    "type":"OAuthException",
    "code": 1
  }
}
 
For facebook desktop application, how can I get the permanent  access token?
Secondly, how can I know what are the users the application is authorized by ?
 
 
could you please provide me any suggestion or links for this issue.
 
Regards,
AppFactory.


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

--------------050206050207090408090901-- From jricher@mitre.org Fri Apr 12 11:25:08 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA7FE21F8BE2 for ; Fri, 12 Apr 2013 11:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zaf5H1f3CkwT for ; Fri, 12 Apr 2013 11:25:01 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6D74F21F87F5 for ; Fri, 12 Apr 2013 11:25:01 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id AF7531F08E9 for ; Fri, 12 Apr 2013 14:25:00 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 862F11F029E for ; Fri, 12 Apr 2013 14:25:00 -0400 (EDT) Received: from [10.146.15.29] (129.83.31.58) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.342.3; Fri, 12 Apr 2013 14:25:00 -0400 Message-ID: <51685177.8060603@mitre.org> Date: Fri, 12 Apr 2013 14:24:55 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: "oauth@ietf.org" Content-Type: multipart/alternative; boundary="------------010008040704010401020101" X-Originating-IP: [129.83.31.58] Subject: [OAUTH-WG] Registration: Scope Values X-BeenThere: oauth@ietf.org X-Mailman-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, 12 Apr 2013 18:25:08 -0000 --------------010008040704010401020101 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Currently, the Dynamic Registration draft defines a "scope" value as part of the client metadata table, with the following definition: scope OPTIONAL. Space separated list of scope values (as described in OAuth 2.0Section 3.3 [RFC6749] ) that the client is declaring that it may use when requesting access tokens. If omitted, an Authorization Server MAY register a Client with a default set of scopes. The idea here is that a client can request a particular set of available scopes from the AS (analogous as to what's available from many/most manual registration pages today), and the AS can communicate back to the client what scopes it's allowed to ask for at authz time. In a strictly-enforced implementation, the client wouldn't be able to ask for any scopes that it wasn't registered for in the first place. However, it's been brought up in some side conversations that the language as found in the DynReg spec might get in the way of people using the "scope" field as an expression language. That is to say, you could have a scope like "send_email_to:myaddress@email.com" where the email address portion is variable, or something like "read:*" which stands in for any scopes starting with "read:" like "read:profile", "read:lists", etc. Precluding this behavior wasn't my intent, and a liberal interpretation of the text as-written would (I believe) lead to this being perfectly OK. Namely: Client requests and is granted a service specific scope value like "send_email_to" in registration. At runtime, the client knows how to turn "send_email_to" into "send_email_to:myaddress@email.com", and the AS knows that a client that's been granted "send_email_to" can ask for "send_email_to:myaddress@email.com". The fact that "send_email_to" expands into an expression language is something specific to the service, and I personally think it's up to the service to document "register for this" and "ask for this at authn time" for clients, since this is all part of the API more than it is part of the underlying OAuth protocol. OAuth merely provides a handy place to communicate these values in an interoperable way, the values themselves aren't intended to be interoperable. But my question to the group is simple: how can we rework the "scope" metadata claim such that it works in both the simple "bag of discreet strings" approach to scope as well as the "list of expressions" approach? Does the language need to change at all? -- Justin --------------010008040704010401020101 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Currently, the Dynamic Registration draft defines a "scope" value as part of the client metadata table, with the following definition:

   scope
      OPTIONAL.  Space separated list of scope values (as described in
      OAuth 2.0 Section 3.3 [RFC6749]) that the client is declaring that
      it may use when requesting access tokens.  If omitted, an
      Authorization Server MAY register a Client with a default set of
      scopes.

The idea here is that a client can request a particular set of available scopes from the AS (analogous as to what's available from many/most manual registration pages today), and the AS can communicate back to the client what scopes it's allowed to ask for at authz time. In a strictly-enforced implementation, the client wouldn't be able to ask for any scopes that it wasn't registered for in the first place.

However, it's been brought up in some side conversations that the language as found in the DynReg spec might get in the way of people using the "scope" field as an expression language. That is to say, you could have a scope like "send_email_to:myaddress@email.com" where the email address portion is variable, or something like "read:*" which stands in for any scopes starting with "read:" like "read:profile", "read:lists", etc. Precluding this behavior wasn't my intent, and a liberal interpretation of the text as-written would (I believe) lead to this being perfectly OK. Namely:

Client requests and is granted a service specific scope value like "send_email_to" in registration. At runtime, the client knows how to turn "send_email_to" into "send_email_to:myaddress@email.com", and the AS knows that a client that's been granted "send_email_to" can ask for "send_email_to:myaddress@email.com". The fact that "send_email_to" expands into an expression language is something specific to the service, and I personally think it's up to the service to document "register for this" and "ask for this at authn time" for clients, since this is all part of the API more than it is part of the underlying OAuth protocol. OAuth merely provides a handy place to communicate these values in an interoperable way, the values themselves aren't intended to be interoperable.


But my question to the group is simple: how can we rework the "scope" metadata claim such that it works in both the simple "bag of discreet strings" approach to scope as well as the "list of expressions" approach? Does the language need to change at all?

 -- Justin
--------------010008040704010401020101-- From twbray@google.com Fri Apr 12 11:31:53 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FA3F21F8E04 for ; Fri, 12 Apr 2013 11:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LSUaU9HkGxbH for ; Fri, 12 Apr 2013 11:31:52 -0700 (PDT) Received: from mail-ia0-x22e.google.com (mail-ia0-x22e.google.com [IPv6:2607:f8b0:4001:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 6A42821F8DFC for ; Fri, 12 Apr 2013 11:31:52 -0700 (PDT) Received: by mail-ia0-f174.google.com with SMTP id r13so2614930iar.19 for ; Fri, 12 Apr 2013 11:31:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=Jr8IJZtaNZfAjkiHfLBKfjgoZF/ZXnXXf9sp5V2l/4E=; b=AwLIc6e4F1fCtWKa1q5rz+8LgggXnt//q17DxAsVGloiWwWzArsJ01wId9GscNfGvw T+plU0lgIoNwUPpnbMUrBpNsJ0FtSpQ8ChAHtL2XO9f+SGMnw2mmV/m+cwBVUUzgGPxw 3NxParC1Z0v45h8qpN0SXRAP6tYSY4ittwOFYrbNyYV96dBW06HJ08VRch/8EsMzUTy5 7WAMysloDo4lyNAKgf3pVHJU08cGfnhcIwHcghrN1EoKdq7yk5kJfoWYNWqNU3OOJib9 x5dbnCVlilSAInmf5UaxDssjj9+hpfNZo9qboIHeCgq8xB2EuivGcZhwkyjlBX6xWupb azTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=Jr8IJZtaNZfAjkiHfLBKfjgoZF/ZXnXXf9sp5V2l/4E=; b=CvMb9iNppnlThG+0/41trhYh3oMWIMamdqIvxBnrAOgexGLfF89RBp7Ux38C203EBI NX3w/rUXnHgWw+EBPEMKbKkJmx3JENAhsDZdfTGCX0FDVrj9nPi+GgQTWQH3It/JEu+i /Z6LjaPGZW+xmxC1N0LekNGMzXvseSGGj6WlTPjSYj3XC1ICEQDhHv0t5Hm+9xoCkO2d TrEKxCh5hMfXtE7dwdAcKkE/Z84bXQOg3nNEFLY/RQdHyWkT2NBgtejslYC/U3swRwQ1 8/GVVjdRu6KZEFbNIPEQ6aohCXjuveH4cI8bVdgBlQgkIufd0eVX2+7Ab4yaihGDZMHa zSbQ== X-Received: by 10.50.112.100 with SMTP id ip4mr2482743igb.87.1365791511822; Fri, 12 Apr 2013 11:31:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.42.232 with HTTP; Fri, 12 Apr 2013 11:31:21 -0700 (PDT) In-Reply-To: <51685177.8060603@mitre.org> References: <51685177.8060603@mitre.org> From: Tim Bray Date: Fri, 12 Apr 2013 11:31:21 -0700 Message-ID: To: Justin Richer Content-Type: multipart/alternative; boundary=047d7b3a9ad2e65a1a04da2e1db7 X-Gm-Message-State: ALoCoQnkWy3EWsnx8RmVWEYOoGCmcaRYIlsR6NEyoQFSKnbEO9uUX5CWLvPju0BeWyD/1X1oEOll+B+hV/YUbiIsR0f2LepfBk6Ug/4PVR3LLFCy/lHzYF5IE8zC5OpUCdB029u7HVKzfJyqPMREJrGQNyJOPJd/ShmJ+y1a+C7XJERt+fEDsEyaqJxCNwBDybTpY4A9K9HY Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Registration: Scope Values X-BeenThere: oauth@ietf.org X-Mailman-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, 12 Apr 2013 18:31:53 -0000 --047d7b3a9ad2e65a1a04da2e1db7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Speaking for myself, I have considerable concern about Turing-complete programming languages starting to emerge inside scope strings, which I think is probably a symptom of bad engineering. I really like the idea of specifying the scopes you=E2=80=99re going to ask for at registration time,= and if that also gets in the way of what I=E2=80=99ll call =E2=80=9Cscope creep=E2= =80=9D (snicker), that feels like a feature not a bug. Anyhow, in practical terms, I can=E2=80=99= t see how you could extend this specify-at-registration-time feature much without stepping on a very slippery complexity slope. -T On Fri, Apr 12, 2013 at 11:24 AM, Justin Richer wrote: > Currently, the Dynamic Registration draft defines a "scope" value as par= t > of the client metadata table, with the following definition: > > scope > OPTIONAL. Space separated list of scope values (as described in > OAuth 2.0 Section 3.3 [RFC6749] ) that the client is declaring that > it may use when requesting access tokens. If omitted, an > Authorization Server MAY register a Client with a default set of > scopes. > > > The idea here is that a client can request a particular set of available > scopes from the AS (analogous as to what's available from many/most manua= l > registration pages today), and the AS can communicate back to the client > what scopes it's allowed to ask for at authz time. In a strictly-enforced > implementation, the client wouldn't be able to ask for any scopes that it > wasn't registered for in the first place. > > However, it's been brought up in some side conversations that the languag= e > as found in the DynReg spec might get in the way of people using the > "scope" field as an expression language. That is to say, you could have a > scope like "send_email_to:myaddress@email.com"where the email address portion is variable, or something like "rea= d:*" > which stands in for any scopes starting with "read:" like "read:profile", > "read:lists", etc. Precluding this behavior wasn't my intent, and a liber= al > interpretation of the text as-written would (I believe) lead to this bein= g > perfectly OK. Namely: > > Client requests and is granted a service specific scope value like > "send_email_to" in registration. At runtime, the client knows how to turn > "send_email_to" into "send_email_to:myaddress@email.com", > and the AS knows that a client that's been granted "send_email_to" can as= k > for "send_email_to:myaddress@email.com". > The fact that "send_email_to" expands into an expression language is > something specific to the service, and I personally think it's up to the > service to document "register for this" and "ask for this at authn time" > for clients, since this is all part of the API more than it is part of th= e > underlying OAuth protocol. OAuth merely provides a handy place to > communicate these values in an interoperable way, the values themselves > aren't intended to be interoperable. > > > But my question to the group is simple: how can we rework the "scope" > metadata claim such that it works in both the simple "bag of discreet > strings" approach to scope as well as the "list of expressions" approach? > Does the language need to change at all? > > -- Justin > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --047d7b3a9ad2e65a1a04da2e1db7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Speaking for myself, I have considerable concern about Tur= ing-complete programming languages starting to emerge inside scope strings,= which I think is probably a symptom of bad engineering. =C2=A0I really lik= e the idea of specifying the scopes you=E2=80=99re going to ask for at regi= stration time, and if that also gets in the way of what I=E2=80=99ll call = =E2=80=9Cscope creep=E2=80=9D (snicker), that feels like a feature not a bu= g. =C2=A0Anyhow, in practical terms, I can=E2=80=99t see how you could exte= nd this specify-at-registration-time feature much without stepping on a ver= y slippery complexity slope.

-T


On Fri, Apr 12, 2013 at 11:24 AM, Justin Richer <jri= cher@mitre.org> wrote:
=20 =20 =20
Currently, the Dynamic Registration draft defines a "scope" v= alue as part of the client metadata table, with the following definition:

   scope
      OPTIONAL.  Space separated list of scope values (as described in
      OAuth 2.0 Section=C2=A03.3 [RFC6749]) that the client is declar=
ing that
      it may use when requesting access tokens.  If omitted, an
      Authorization Server MAY register a Client with a default set of
      scopes.

The idea here is that a client can request a particular set of available scopes from the AS (analogous as to what's available from many/most manual registration pages today), and the AS can communicate back to the client what scopes it's allowed to ask for at authz time. In a strictly-enforced implementation, the client wouldn't be able to ask for any scopes that it wasn't registere= d for in the first place.

However, it's been brought up in some side conversations that the language as found in the DynReg spec might get in the way of people using the "scope" field as an expression language. That is to= say, you could have a scope like "send_email_to:myaddress@email.com" where the email address portion is variable, or something like "read:*" which stands in for any scopes starting with "r= ead:" like "read:profile", "read:lists", etc. Precluding this = behavior wasn't my intent, and a liberal interpretation of the text as-written would (I believe) lead to this being perfectly OK. Namely:

Client requests and is granted a service specific scope value like "send_email_to" in registration. At runtime, the client knows= how to turn "send_email_to" into "send_email_to:myaddress@email.com= ", and the AS knows that a client that's been granted "send_email_to&= quot; can ask for "send_email_to:myaddress@email.com". The fact that "send_email_to" expands into an expression language is someth= ing specific to the service, and I personally think it's up to the service to document "register for this" and "ask for thi= s at authn time" for clients, since this is all part of the API more than it = is part of the underlying OAuth protocol. OAuth merely provides a handy place to communicate these values in an interoperable way, the values themselves aren't intended to be interoperable.


But my question to the group is simple: how can we rework the "scope" metadata claim such that it works in both the simple = "bag of discreet strings" approach to scope as well as the "list of expressions" approach? Does the language need to change at all?

=C2=A0-- Justin

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


--047d7b3a9ad2e65a1a04da2e1db7-- From Michael.Jones@microsoft.com Fri Apr 12 11:46:48 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BEDE21F8E87 for ; Fri, 12 Apr 2013 11:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v98VL4bcMYeF for ; Fri, 12 Apr 2013 11:46:47 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0242.outbound.protection.outlook.com [207.46.163.242]) by ietfa.amsl.com (Postfix) with ESMTP id 4B18621F8E79 for ; Fri, 12 Apr 2013 11:46:47 -0700 (PDT) Received: from BY2FFO11FD011.protection.gbl (10.1.15.201) by BY2FFO11HUB036.protection.gbl (10.1.14.179) with Microsoft SMTP Server (TLS) id 15.0.664.0; Fri, 12 Apr 2013 18:47:18 +0000 Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD011.mail.protection.outlook.com (10.1.14.129) with Microsoft SMTP Server (TLS) id 15.0.664.0 via Frontend Transport; Fri, 12 Apr 2013 18:46:45 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.224]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0318.003; Fri, 12 Apr 2013 18:46:29 +0000 From: Mike Jones To: Tim Bray , Justin Richer Thread-Topic: [OAUTH-WG] Registration: Scope Values Thread-Index: AQHON6sV5AOCpr9wLEyFt+RPKbMBMpjS6IWAgAABiQA= Date: Fri, 12 Apr 2013 18:46:28 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394367619C97@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <51685177.8060603@mitre.org> 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.35] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394367619C97TK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(189002)(47736001)(65816001)(512874001)(20776003)(44976002)(47446002)(76482001)(66066001)(18277545001)(77982001)(54316002)(59766001)(81542001)(74662001)(54356001)(55846006)(4396001)(56816002)(71186001)(50986001)(47976001)(69226001)(51856001)(33656001)(18276755001)(53806001)(49866001)(564824004)(46102001)(81342001)(63696002)(79102001)(74502001)(80022001)(56776001)(16406001)(31966008); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB036; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0814A2C7A3 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Registration: Scope Values X-BeenThere: oauth@ietf.org X-Mailman-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, 12 Apr 2013 18:46:48 -0000 --_000_4E1F6AAD24975D4BA5B168042967394367619C97TK5EX14MBXC283r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGltLCBpZiB5b3UgbG9vayBhdCB0aGUgc2NvcGUgZXhhbXBsZXMgaW4gaHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvcmZjNjc1MCNzZWN0aW9uLTMsIHlvdeKAmWxsIHNlZSB0aGF0IG9uZSBvZiB0 aGVtLCBmcm9tIHRoZSBPcGVuIEF1dGhlbnRpY2F0aW9uIFRlY2hub2xvZ3kgQ29tbWl0dGVlIChP QVRDKSBPbmxpbmUgTXVsdGltZWRpYSBBdXRob3JpemF0aW9uIFByb3RvY29sIFtPTUFQXSwgZG9l cyB1c2Ugbm9uLXN0YXRpYyBzY29wZSB2YWx1ZXMgdG8gY29udmV5IHBhcmFtZXRlcnM6DQpzY29w ZT0idXJuOmV4YW1wbGU6Y2hhbm5lbD1IQk8mdXJuOmV4YW1wbGU6cmF0aW5nPUcsUEctMTMiDQoN CkFsc28sIGlmIHlvdSBsb29rIGF0IHRoZSBPQXV0aCB1c2FnZSBzdXJ2ZXkgcmVzdWx0cyBjb2xs ZWN0ZWQgZHVyaW5nIElFVEYgODYgaW4gaHR0cDovL3NlbGYtaXNzdWVkLmluZm8vbWlzYy9PQXV0 aCUyMEZlYXR1cmUlMjBNYXRyaXglMjAtJTIwQWxsLnhsc3ggKGNlbGwgRzE0NSksIHlvdeKAmWxs IHNlZSB0aGF0IHRoZSBPcGVuRVNQSSDigJxTbWFydCBHcmlk4oCdIHNwZWNzIGFsc28gdXNlIHNj b3BlIHZhbHVlcyB0byBjb252ZXkgc3RydWN0dXJlZCBpbmZvcm1hdGlvbi4NCg0KVGhlIGhvcnNl IGhhcyBsZWZ0IHRoZSBiYXJuIG9uIHJlcXVpcmluZyBzY29wZSB2YWx1ZXMgdG8gYmUgc3RhdGlj IHN0cmluZ3MuICBSRkMgNjc0OSBkaWRu4oCZdCBkbyBpdCBhbmQgbG90cyBvZiBpbXBsZW1lbnRh dGlvbnMgYXJlIGNvbnZleWluZyBzdHJ1Y3R1cmVkIGluZm9ybWF0aW9uIHRoZXJlLiAgQXMgSnVz dGluIGlzIGJyaW5naW5nIHVwLCB0aGUgT0F1dGggUmVnaXN0cmF0aW9uIHNwZWMgc2hvdWxkbuKA mXQgZG8gYW55dGhpbmcgdG8gcHJlY2x1ZGUgdGhpcyB1c2FnZS4NCg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQ2hlZXJzLA0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg LS0gTWlrZQ0KDQpGcm9tOiBvYXV0aC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86b2F1dGgtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFRpbSBCcmF5DQpTZW50OiBGcmlkYXksIEFwcmls IDEyLCAyMDEzIDExOjMxIEFNDQpUbzogSnVzdGluIFJpY2hlcg0KQ2M6IG9hdXRoQGlldGYub3Jn DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBSZWdpc3RyYXRpb246IFNjb3BlIFZhbHVlcw0KDQpT cGVha2luZyBmb3IgbXlzZWxmLCBJIGhhdmUgY29uc2lkZXJhYmxlIGNvbmNlcm4gYWJvdXQgVHVy aW5nLWNvbXBsZXRlIHByb2dyYW1taW5nIGxhbmd1YWdlcyBzdGFydGluZyB0byBlbWVyZ2UgaW5z aWRlIHNjb3BlIHN0cmluZ3MsIHdoaWNoIEkgdGhpbmsgaXMgcHJvYmFibHkgYSBzeW1wdG9tIG9m IGJhZCBlbmdpbmVlcmluZy4gIEkgcmVhbGx5IGxpa2UgdGhlIGlkZWEgb2Ygc3BlY2lmeWluZyB0 aGUgc2NvcGVzIHlvdeKAmXJlIGdvaW5nIHRvIGFzayBmb3IgYXQgcmVnaXN0cmF0aW9uIHRpbWUs IGFuZCBpZiB0aGF0IGFsc28gZ2V0cyBpbiB0aGUgd2F5IG9mIHdoYXQgSeKAmWxsIGNhbGwg4oCc c2NvcGUgY3JlZXDigJ0gKHNuaWNrZXIpLCB0aGF0IGZlZWxzIGxpa2UgYSBmZWF0dXJlIG5vdCBh IGJ1Zy4gIEFueWhvdywgaW4gcHJhY3RpY2FsIHRlcm1zLCBJIGNhbuKAmXQgc2VlIGhvdyB5b3Ug Y291bGQgZXh0ZW5kIHRoaXMgc3BlY2lmeS1hdC1yZWdpc3RyYXRpb24tdGltZSBmZWF0dXJlIG11 Y2ggd2l0aG91dCBzdGVwcGluZyBvbiBhIHZlcnkgc2xpcHBlcnkgY29tcGxleGl0eSBzbG9wZS4N Cg0KLVQNCg0KT24gRnJpLCBBcHIgMTIsIDIwMTMgYXQgMTE6MjQgQU0sIEp1c3RpbiBSaWNoZXIg PGpyaWNoZXJAbWl0cmUub3JnPG1haWx0bzpqcmljaGVyQG1pdHJlLm9yZz4+IHdyb3RlOg0KQ3Vy cmVudGx5LCB0aGUgRHluYW1pYyBSZWdpc3RyYXRpb24gZHJhZnQgZGVmaW5lcyBhICJzY29wZSIg dmFsdWUgYXMgcGFydCBvZiB0aGUgY2xpZW50IG1ldGFkYXRhIHRhYmxlLCB3aXRoIHRoZSBmb2xs b3dpbmcgZGVmaW5pdGlvbjoNCg0KICAgc2NvcGUNCg0KICAgICAgT1BUSU9OQUwuICBTcGFjZSBz ZXBhcmF0ZWQgbGlzdCBvZiBzY29wZSB2YWx1ZXMgKGFzIGRlc2NyaWJlZCBpbg0KDQogICAgICBP QXV0aCAyLjAgU2VjdGlvbiAzLjMgW1JGQzY3NDldPGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L3JmYzY3NDkjc2VjdGlvbi0zLjM+KSB0aGF0IHRoZSBjbGllbnQgaXMgZGVjbGFyaW5nIHRoYXQN Cg0KICAgICAgaXQgbWF5IHVzZSB3aGVuIHJlcXVlc3RpbmcgYWNjZXNzIHRva2Vucy4gIElmIG9t aXR0ZWQsIGFuDQoNCiAgICAgIEF1dGhvcml6YXRpb24gU2VydmVyIE1BWSByZWdpc3RlciBhIENs aWVudCB3aXRoIGEgZGVmYXVsdCBzZXQgb2YNCg0KICAgICAgc2NvcGVzLg0KDQpUaGUgaWRlYSBo ZXJlIGlzIHRoYXQgYSBjbGllbnQgY2FuIHJlcXVlc3QgYSBwYXJ0aWN1bGFyIHNldCBvZiBhdmFp bGFibGUgc2NvcGVzIGZyb20gdGhlIEFTIChhbmFsb2dvdXMgYXMgdG8gd2hhdCdzIGF2YWlsYWJs ZSBmcm9tIG1hbnkvbW9zdCBtYW51YWwgcmVnaXN0cmF0aW9uIHBhZ2VzIHRvZGF5KSwgYW5kIHRo ZSBBUyBjYW4gY29tbXVuaWNhdGUgYmFjayB0byB0aGUgY2xpZW50IHdoYXQgc2NvcGVzIGl0J3Mg YWxsb3dlZCB0byBhc2sgZm9yIGF0IGF1dGh6IHRpbWUuIEluIGEgc3RyaWN0bHktZW5mb3JjZWQg aW1wbGVtZW50YXRpb24sIHRoZSBjbGllbnQgd291bGRuJ3QgYmUgYWJsZSB0byBhc2sgZm9yIGFu eSBzY29wZXMgdGhhdCBpdCB3YXNuJ3QgcmVnaXN0ZXJlZCBmb3IgaW4gdGhlIGZpcnN0IHBsYWNl Lg0KDQpIb3dldmVyLCBpdCdzIGJlZW4gYnJvdWdodCB1cCBpbiBzb21lIHNpZGUgY29udmVyc2F0 aW9ucyB0aGF0IHRoZSBsYW5ndWFnZSBhcyBmb3VuZCBpbiB0aGUgRHluUmVnIHNwZWMgbWlnaHQg Z2V0IGluIHRoZSB3YXkgb2YgcGVvcGxlIHVzaW5nIHRoZSAic2NvcGUiIGZpZWxkIGFzIGFuIGV4 cHJlc3Npb24gbGFuZ3VhZ2UuIFRoYXQgaXMgdG8gc2F5LCB5b3UgY291bGQgaGF2ZSBhIHNjb3Bl IGxpa2UgInNlbmRfZW1haWxfdG86bXlhZGRyZXNzQGVtYWlsLmNvbSI8bWFpbHRvOnNlbmRfZW1h aWxfdG86bXlhZGRyZXNzQGVtYWlsLmNvbT4gd2hlcmUgdGhlIGVtYWlsIGFkZHJlc3MgcG9ydGlv biBpcyB2YXJpYWJsZSwgb3Igc29tZXRoaW5nIGxpa2UgInJlYWQ6KiIgd2hpY2ggc3RhbmRzIGlu IGZvciBhbnkgc2NvcGVzIHN0YXJ0aW5nIHdpdGggInJlYWQ6IiBsaWtlICJyZWFkOnByb2ZpbGUi LCAicmVhZDpsaXN0cyIsIGV0Yy4gUHJlY2x1ZGluZyB0aGlzIGJlaGF2aW9yIHdhc24ndCBteSBp bnRlbnQsIGFuZCBhIGxpYmVyYWwgaW50ZXJwcmV0YXRpb24gb2YgdGhlIHRleHQgYXMtd3JpdHRl biB3b3VsZCAoSSBiZWxpZXZlKSBsZWFkIHRvIHRoaXMgYmVpbmcgcGVyZmVjdGx5IE9LLiBOYW1l bHk6DQoNCkNsaWVudCByZXF1ZXN0cyBhbmQgaXMgZ3JhbnRlZCBhIHNlcnZpY2Ugc3BlY2lmaWMg c2NvcGUgdmFsdWUgbGlrZSAic2VuZF9lbWFpbF90byIgaW4gcmVnaXN0cmF0aW9uLiBBdCBydW50 aW1lLCB0aGUgY2xpZW50IGtub3dzIGhvdyB0byB0dXJuICJzZW5kX2VtYWlsX3RvIiBpbnRvICJz ZW5kX2VtYWlsX3RvOm15YWRkcmVzc0BlbWFpbC5jb20iPG1haWx0bzpzZW5kX2VtYWlsX3RvOm15 YWRkcmVzc0BlbWFpbC5jb20+LCBhbmQgdGhlIEFTIGtub3dzIHRoYXQgYSBjbGllbnQgdGhhdCdz IGJlZW4gZ3JhbnRlZCAic2VuZF9lbWFpbF90byIgY2FuIGFzayBmb3IgInNlbmRfZW1haWxfdG86 bXlhZGRyZXNzQGVtYWlsLmNvbSI8bWFpbHRvOnNlbmRfZW1haWxfdG86bXlhZGRyZXNzQGVtYWls LmNvbT4uIFRoZSBmYWN0IHRoYXQgInNlbmRfZW1haWxfdG8iIGV4cGFuZHMgaW50byBhbiBleHBy ZXNzaW9uIGxhbmd1YWdlIGlzIHNvbWV0aGluZyBzcGVjaWZpYyB0byB0aGUgc2VydmljZSwgYW5k IEkgcGVyc29uYWxseSB0aGluayBpdCdzIHVwIHRvIHRoZSBzZXJ2aWNlIHRvIGRvY3VtZW50ICJy ZWdpc3RlciBmb3IgdGhpcyIgYW5kICJhc2sgZm9yIHRoaXMgYXQgYXV0aG4gdGltZSIgZm9yIGNs aWVudHMsIHNpbmNlIHRoaXMgaXMgYWxsIHBhcnQgb2YgdGhlIEFQSSBtb3JlIHRoYW4gaXQgaXMg cGFydCBvZiB0aGUgdW5kZXJseWluZyBPQXV0aCBwcm90b2NvbC4gT0F1dGggbWVyZWx5IHByb3Zp ZGVzIGEgaGFuZHkgcGxhY2UgdG8gY29tbXVuaWNhdGUgdGhlc2UgdmFsdWVzIGluIGFuIGludGVy b3BlcmFibGUgd2F5LCB0aGUgdmFsdWVzIHRoZW1zZWx2ZXMgYXJlbid0IGludGVuZGVkIHRvIGJl IGludGVyb3BlcmFibGUuDQoNCg0KQnV0IG15IHF1ZXN0aW9uIHRvIHRoZSBncm91cCBpcyBzaW1w bGU6IGhvdyBjYW4gd2UgcmV3b3JrIHRoZSAic2NvcGUiIG1ldGFkYXRhIGNsYWltIHN1Y2ggdGhh dCBpdCB3b3JrcyBpbiBib3RoIHRoZSBzaW1wbGUgImJhZyBvZiBkaXNjcmVldCBzdHJpbmdzIiBh cHByb2FjaCB0byBzY29wZSBhcyB3ZWxsIGFzIHRoZSAibGlzdCBvZiBleHByZXNzaW9ucyIgYXBw cm9hY2g/IERvZXMgdGhlIGxhbmd1YWdlIG5lZWQgdG8gY2hhbmdlIGF0IGFsbD8NCg0KIC0tIEp1 c3Rpbg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K T0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+ DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg== --_000_4E1F6AAD24975D4BA5B168042967394367619C97TK5EX14MBXC283r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBD aGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0 dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7 DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5ob2VuemINCgl7bXNvLXN0eWxlLW5hbWU6 aG9lbnpiO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3 RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGlu IDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpl eHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6 ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0t Pg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUi Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaW0sIGlmIHlvdSBsb29rIGF0 IHRoZSBzY29wZSBleGFtcGxlcyBpbg0KPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvcmZjNjc1MCNzZWN0aW9uLTMiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY3NTAj c2VjdGlvbi0zPC9hPiwgeW914oCZbGwgc2VlIHRoYXQgb25lIG9mIHRoZW0sIGZyb20gdGhlIE9w ZW4gQXV0aGVudGljYXRpb24gVGVjaG5vbG9neSBDb21taXR0ZWUgKE9BVEMpIE9ubGluZSBNdWx0 aW1lZGlhIEF1dGhvcml6YXRpb24gUHJvdG9jb2wgW09NQVBdLCBkb2VzIHVzZSBub24tc3RhdGlj DQogc2NvcGUgdmFsdWVzIHRvIGNvbnZleSBwYXJhbWV0ZXJzOjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBs YW5nPSJFTiI+c2NvcGU9JnF1b3Q7dXJuOmV4YW1wbGU6Y2hhbm5lbD1IQk8mYW1wO3VybjpleGFt cGxlOnJhdGluZz1HLFBHLTEzJnF1b3Q7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFsc28sIGlmIHlvdSBsb29rIGF0IHRoZSBPQXV0 aCB1c2FnZSBzdXJ2ZXkgcmVzdWx0cyBjb2xsZWN0ZWQgZHVyaW5nIElFVEYgODYgaW4NCjxhIGhy ZWY9Imh0dHA6Ly9zZWxmLWlzc3VlZC5pbmZvL21pc2MvT0F1dGglMjBGZWF0dXJlJTIwTWF0cml4 JTIwLSUyMEFsbC54bHN4Ij5odHRwOi8vc2VsZi1pc3N1ZWQuaW5mby9taXNjL09BdXRoJTIwRmVh dHVyZSUyME1hdHJpeCUyMC0lMjBBbGwueGxzeDwvYT4gKGNlbGwgRzE0NSksIHlvdeKAmWxsIHNl ZSB0aGF0IHRoZSBPcGVuRVNQSSDigJxTbWFydCBHcmlk4oCdIHNwZWNzIGFsc28gdXNlIHNjb3Bl IHZhbHVlcyB0byBjb252ZXkgc3RydWN0dXJlZCBpbmZvcm1hdGlvbi48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBo b3JzZSBoYXMgbGVmdCB0aGUgYmFybiBvbiByZXF1aXJpbmcgc2NvcGUgdmFsdWVzIHRvIGJlIHN0 YXRpYyBzdHJpbmdzLiZuYnNwOyBSRkMgNjc0OSBkaWRu4oCZdCBkbyBpdCBhbmQgbG90cyBvZiBp bXBsZW1lbnRhdGlvbnMgYXJlIGNvbnZleWluZyBzdHJ1Y3R1cmVkIGluZm9ybWF0aW9uDQogdGhl cmUuJm5ic3A7IEFzIEp1c3RpbiBpcyBicmluZ2luZyB1cCwgdGhlIE9BdXRoIFJlZ2lzdHJhdGlv biBzcGVjIHNob3VsZG7igJl0IGRvIGFueXRoaW5nIHRvIHByZWNsdWRlIHRoaXMgdXNhZ2UuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgQ2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4gb2F1dGgtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0 Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlRpbSBCcmF5PGJyPg0KPGI+U2VudDo8L2I+IEZy aWRheSwgQXByaWwgMTIsIDIwMTMgMTE6MzEgQU08YnI+DQo8Yj5Ubzo8L2I+IEp1c3RpbiBSaWNo ZXI8YnI+DQo8Yj5DYzo8L2I+IG9hdXRoQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl OiBbT0FVVEgtV0ddIFJlZ2lzdHJhdGlvbjogU2NvcGUgVmFsdWVzPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+U3BlYWtpbmcgZm9yIG15c2VsZiwgSSBoYXZlIGNvbnNpZGVy YWJsZSBjb25jZXJuIGFib3V0IFR1cmluZy1jb21wbGV0ZSBwcm9ncmFtbWluZyBsYW5ndWFnZXMg c3RhcnRpbmcgdG8gZW1lcmdlIGluc2lkZSBzY29wZSBzdHJpbmdzLCB3aGljaCBJIHRoaW5rIGlz IHByb2JhYmx5IGEgc3ltcHRvbSBvZiBiYWQgZW5naW5lZXJpbmcuICZuYnNwO0kgcmVhbGx5IGxp a2UgdGhlIGlkZWEgb2Ygc3BlY2lmeWluZyB0aGUgc2NvcGVzDQogeW914oCZcmUgZ29pbmcgdG8g YXNrIGZvciBhdCByZWdpc3RyYXRpb24gdGltZSwgYW5kIGlmIHRoYXQgYWxzbyBnZXRzIGluIHRo ZSB3YXkgb2Ygd2hhdCBJ4oCZbGwgY2FsbCDigJxzY29wZSBjcmVlcOKAnSAoc25pY2tlciksIHRo YXQgZmVlbHMgbGlrZSBhIGZlYXR1cmUgbm90IGEgYnVnLiAmbmJzcDtBbnlob3csIGluIHByYWN0 aWNhbCB0ZXJtcywgSSBjYW7igJl0IHNlZSBob3cgeW91IGNvdWxkIGV4dGVuZCB0aGlzIHNwZWNp ZnktYXQtcmVnaXN0cmF0aW9uLXRpbWUgZmVhdHVyZQ0KIG11Y2ggd2l0aG91dCBzdGVwcGluZyBv biBhIHZlcnkgc2xpcHBlcnkgY29tcGxleGl0eSBzbG9wZS48bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi1UPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g RnJpLCBBcHIgMTIsIDIwMTMgYXQgMTE6MjQgQU0sIEp1c3RpbiBSaWNoZXIgJmx0OzxhIGhyZWY9 Im1haWx0bzpqcmljaGVyQG1pdHJlLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmpyaWNoZXJAbWl0cmUu b3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5DdXJyZW50bHksIHRoZSBEeW5hbWlj IFJlZ2lzdHJhdGlvbiBkcmFmdCBkZWZpbmVzIGEgJnF1b3Q7c2NvcGUmcXVvdDsgdmFsdWUgYXMg cGFydCBvZiB0aGUgY2xpZW50IG1ldGFkYXRhIHRhYmxlLCB3aXRoIHRoZSBmb2xsb3dpbmcgZGVm aW5pdGlvbjo8bzpwPjwvbzpwPjwvcD4NCjxwcmU+Jm5ic3A7Jm5ic3A7IHNjb3BlPG86cD48L286 cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9QVElPTkFMLiZu YnNwOyBTcGFjZSBzZXBhcmF0ZWQgbGlzdCBvZiBzY29wZSB2YWx1ZXMgKGFzIGRlc2NyaWJlZCBp bjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBP QXV0aCAyLjAgPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjc0OSNzZWN0 aW9uLTMuMyIgdGFyZ2V0PSJfYmxhbmsiPlNlY3Rpb24mbmJzcDszLjMgW1JGQzY3NDldPC9hPikg dGhhdCB0aGUgY2xpZW50IGlzIGRlY2xhcmluZyB0aGF0PG86cD48L286cD48L3ByZT4NCjxwcmU+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGl0IG1heSB1c2Ugd2hlbiByZXF1ZXN0aW5n IGFjY2VzcyB0b2tlbnMuJm5ic3A7IElmIG9taXR0ZWQsIGFuPG86cD48L286cD48L3ByZT4NCjxw cmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEF1dGhvcml6YXRpb24gU2VydmVyIE1B WSByZWdpc3RlciBhIENsaWVudCB3aXRoIGEgZGVmYXVsdCBzZXQgb2Y8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc2NvcGVzLjxvOnA+PC9vOnA+ PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpUaGUgaWRlYSBoZXJlIGlzIHRoYXQg YSBjbGllbnQgY2FuIHJlcXVlc3QgYSBwYXJ0aWN1bGFyIHNldCBvZiBhdmFpbGFibGUgc2NvcGVz IGZyb20gdGhlIEFTIChhbmFsb2dvdXMgYXMgdG8gd2hhdCdzIGF2YWlsYWJsZSBmcm9tIG1hbnkv bW9zdCBtYW51YWwgcmVnaXN0cmF0aW9uIHBhZ2VzIHRvZGF5KSwgYW5kIHRoZSBBUyBjYW4gY29t bXVuaWNhdGUgYmFjayB0byB0aGUgY2xpZW50IHdoYXQgc2NvcGVzIGl0J3MgYWxsb3dlZCB0byBh c2sgZm9yDQogYXQgYXV0aHogdGltZS4gSW4gYSBzdHJpY3RseS1lbmZvcmNlZCBpbXBsZW1lbnRh dGlvbiwgdGhlIGNsaWVudCB3b3VsZG4ndCBiZSBhYmxlIHRvIGFzayBmb3IgYW55IHNjb3BlcyB0 aGF0IGl0IHdhc24ndCByZWdpc3RlcmVkIGZvciBpbiB0aGUgZmlyc3QgcGxhY2UuPGJyPg0KPGJy Pg0KSG93ZXZlciwgaXQncyBiZWVuIGJyb3VnaHQgdXAgaW4gc29tZSBzaWRlIGNvbnZlcnNhdGlv bnMgdGhhdCB0aGUgbGFuZ3VhZ2UgYXMgZm91bmQgaW4gdGhlIER5blJlZyBzcGVjIG1pZ2h0IGdl dCBpbiB0aGUgd2F5IG9mIHBlb3BsZSB1c2luZyB0aGUgJnF1b3Q7c2NvcGUmcXVvdDsgZmllbGQg YXMgYW4gZXhwcmVzc2lvbiBsYW5ndWFnZS4gVGhhdCBpcyB0byBzYXksIHlvdSBjb3VsZCBoYXZl IGEgc2NvcGUgbGlrZQ0KPGEgaHJlZj0ibWFpbHRvOnNlbmRfZW1haWxfdG86bXlhZGRyZXNzQGVt YWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPiZxdW90O3NlbmRfZW1haWxfdG86bXlhZGRyZXNzQGVt YWlsLmNvbSZxdW90OzwvYT4gd2hlcmUgdGhlIGVtYWlsIGFkZHJlc3MgcG9ydGlvbiBpcyB2YXJp YWJsZSwgb3Igc29tZXRoaW5nIGxpa2UgJnF1b3Q7cmVhZDoqJnF1b3Q7IHdoaWNoIHN0YW5kcyBp biBmb3IgYW55IHNjb3BlcyBzdGFydGluZyB3aXRoICZxdW90O3JlYWQ6JnF1b3Q7IGxpa2UgJnF1 b3Q7cmVhZDpwcm9maWxlJnF1b3Q7LCAmcXVvdDtyZWFkOmxpc3RzJnF1b3Q7LA0KIGV0Yy4gUHJl Y2x1ZGluZyB0aGlzIGJlaGF2aW9yIHdhc24ndCBteSBpbnRlbnQsIGFuZCBhIGxpYmVyYWwgaW50 ZXJwcmV0YXRpb24gb2YgdGhlIHRleHQgYXMtd3JpdHRlbiB3b3VsZCAoSSBiZWxpZXZlKSBsZWFk IHRvIHRoaXMgYmVpbmcgcGVyZmVjdGx5IE9LLiBOYW1lbHk6PGJyPg0KPGJyPg0KQ2xpZW50IHJl cXVlc3RzIGFuZCBpcyBncmFudGVkIGEgc2VydmljZSBzcGVjaWZpYyBzY29wZSB2YWx1ZSBsaWtl ICZxdW90O3NlbmRfZW1haWxfdG8mcXVvdDsgaW4gcmVnaXN0cmF0aW9uLiBBdCBydW50aW1lLCB0 aGUgY2xpZW50IGtub3dzIGhvdyB0byB0dXJuICZxdW90O3NlbmRfZW1haWxfdG8mcXVvdDsgaW50 bw0KPGEgaHJlZj0ibWFpbHRvOnNlbmRfZW1haWxfdG86bXlhZGRyZXNzQGVtYWlsLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPiZxdW90O3NlbmRfZW1haWxfdG86bXlhZGRyZXNzQGVtYWlsLmNvbSZxdW90 OzwvYT4sIGFuZCB0aGUgQVMga25vd3MgdGhhdCBhIGNsaWVudCB0aGF0J3MgYmVlbiBncmFudGVk ICZxdW90O3NlbmRfZW1haWxfdG8mcXVvdDsgY2FuIGFzayBmb3INCjxhIGhyZWY9Im1haWx0bzpz ZW5kX2VtYWlsX3RvOm15YWRkcmVzc0BlbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj4mcXVvdDtz ZW5kX2VtYWlsX3RvOm15YWRkcmVzc0BlbWFpbC5jb20mcXVvdDs8L2E+LiBUaGUgZmFjdCB0aGF0 ICZxdW90O3NlbmRfZW1haWxfdG8mcXVvdDsgZXhwYW5kcyBpbnRvIGFuIGV4cHJlc3Npb24gbGFu Z3VhZ2UgaXMgc29tZXRoaW5nIHNwZWNpZmljIHRvIHRoZSBzZXJ2aWNlLCBhbmQgSSBwZXJzb25h bGx5IHRoaW5rIGl0J3MgdXAgdG8gdGhlIHNlcnZpY2UNCiB0byBkb2N1bWVudCAmcXVvdDtyZWdp c3RlciBmb3IgdGhpcyZxdW90OyBhbmQgJnF1b3Q7YXNrIGZvciB0aGlzIGF0IGF1dGhuIHRpbWUm cXVvdDsgZm9yIGNsaWVudHMsIHNpbmNlIHRoaXMgaXMgYWxsIHBhcnQgb2YgdGhlIEFQSSBtb3Jl IHRoYW4gaXQgaXMgcGFydCBvZiB0aGUgdW5kZXJseWluZyBPQXV0aCBwcm90b2NvbC4gT0F1dGgg bWVyZWx5IHByb3ZpZGVzIGEgaGFuZHkgcGxhY2UgdG8gY29tbXVuaWNhdGUgdGhlc2UgdmFsdWVz IGluIGFuIGludGVyb3BlcmFibGUgd2F5LA0KIHRoZSB2YWx1ZXMgdGhlbXNlbHZlcyBhcmVuJ3Qg aW50ZW5kZWQgdG8gYmUgaW50ZXJvcGVyYWJsZS4gPGJyPg0KPGJyPg0KPGJyPg0KQnV0IG15IHF1 ZXN0aW9uIHRvIHRoZSBncm91cCBpcyBzaW1wbGU6IGhvdyBjYW4gd2UgcmV3b3JrIHRoZSAmcXVv dDtzY29wZSZxdW90OyBtZXRhZGF0YSBjbGFpbSBzdWNoIHRoYXQgaXQgd29ya3MgaW4gYm90aCB0 aGUgc2ltcGxlICZxdW90O2JhZyBvZiBkaXNjcmVldCBzdHJpbmdzJnF1b3Q7IGFwcHJvYWNoIHRv IHNjb3BlIGFzIHdlbGwgYXMgdGhlICZxdW90O2xpc3Qgb2YgZXhwcmVzc2lvbnMmcXVvdDsgYXBw cm9hY2g/IERvZXMgdGhlIGxhbmd1YWdlIG5lZWQgdG8gY2hhbmdlIGF0IGFsbD88c3BhbiBzdHls ZT0iY29sb3I6Izg4ODg4OCI+PGJyPg0KPGJyPg0KPHNwYW4gY2xhc3M9ImhvZW56YiI+Jm5ic3A7 LS0gSnVzdGluPC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcg bGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8 L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9v YXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_4E1F6AAD24975D4BA5B168042967394367619C97TK5EX14MBXC283r_-- From donald.coffin@reminetworks.com Fri Apr 12 12:41:07 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4312C21F8EC9 for ; Fri, 12 Apr 2013 12:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jO51dgfXDc-Q for ; Fri, 12 Apr 2013 12:41:06 -0700 (PDT) Received: from oproxy13-pub.unifiedlayer.com (oproxy13-pub.unifiedlayer.com [69.89.16.30]) by ietfa.amsl.com (Postfix) with SMTP id 35D5D21F8E9A for ; Fri, 12 Apr 2013 12:41:06 -0700 (PDT) Received: (qmail 5050 invoked by uid 0); 12 Apr 2013 19:40:41 -0000 Received: from unknown (HELO host125.hostmonster.com) (74.220.207.125) by oproxy13.unifiedlayer.com with SMTP; 12 Apr 2013 19:40:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=reminetworks.com; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=fRBKYHtZkZvW+ImswnZlHYT9WHrC1MKHbLq0t6/wjPg=; b=o+wKyjyXOuTpYzd8RJU4LPJApKuZly6652XDCGLa0l7zb0yzKpb5FLrgonjjGvgcZUb+uyGEHzcFOQIdNfzWSilSsvjqCqgn/13j5DGjRO5mtEN3NZWYMqs7OAujtVoY; Received: from [68.4.207.246] (port=2517 helo=HPPavilionElite) by host125.hostmonster.com with esmtpa (Exim 4.80) (envelope-from ) id 1UQjpx-00007s-AK; Fri, 12 Apr 2013 13:40:41 -0600 From: "Donald F Coffin" To: "'Tim Bray'" , "'Justin Richer'" References: <51685177.8060603@mitre.org> In-Reply-To: Date: Fri, 12 Apr 2013 12:39:05 -0700 Message-ID: <00ce01ce37b5$64829210$2d87b630$@reminetworks.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00CF_01CE377A.B8260400" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKhIF8eX/RIXMm9kgogxQzt5YcUwgJZhmb4lxpdzdA= Content-Language: en-us X-Identified-User: {1395:host125.hostmonster.com:reminetw:reminetworks.com} {sentby:smtp auth 68.4.207.246 authed with donald.coffin@reminetworks.com} Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Registration: Scope Values X-BeenThere: oauth@ietf.org X-Mailman-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, 12 Apr 2013 19:41:07 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00CF_01CE377A.B8260400 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 =20 Best regards, Don Donald F. Coffin Founder/CTO =20 REMI Networks 22751 El Prado Suite 6216 Rancho Santa Margarita, CA 92688-3836 =20 Phone: (949) 636-8571 Email: = donald.coffin@reminetworks.com =20 From: Tim Bray [mailto:twbray@google.com]=20 Sent: Friday, April 12, 2013 11:31 AM To: Justin Richer Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Registration: Scope Values =20 Speaking for myself, I have considerable concern about Turing-complete = programming languages starting to emerge inside scope strings, which I = think is probably a symptom of bad engineering. I really like the idea = of specifying the scopes you=E2=80=99re going to ask for at registration = time, and if that also gets in the way of what I=E2=80=99ll call = =E2=80=9Cscope creep=E2=80=9D (snicker), that feels like a feature not a = bug. Anyhow, in practical terms, I can=E2=80=99t see how you could = extend this specify-at-registration-time feature much without stepping = on a very slippery complexity slope. =20 -T =20 On Fri, Apr 12, 2013 at 11:24 AM, Justin Richer = wrote: Currently, the Dynamic Registration draft defines a "scope" value as = part of the client metadata table, with the following definition: scope OPTIONAL. Space separated list of scope values (as described in OAuth 2.0 Section = 3.3 [RFC6749]) that the client is declaring that it may use when requesting access tokens. If omitted, an Authorization Server MAY register a Client with a default set of scopes. The idea here is that a client can request a particular set of available = scopes from the AS (analogous as to what's available from many/most = manual registration pages today), and the AS can communicate back to the = client what scopes it's allowed to ask for at authz time. In a = strictly-enforced implementation, the client wouldn't be able to ask for = any scopes that it wasn't registered for in the first place. However, it's been brought up in some side conversations that the = language as found in the DynReg spec might get in the way of people = using the "scope" field as an expression language. That is to say, you = could have a scope like = "send_email_to:myaddress@email.com" where the email address portion is = variable, or something like "read:*" which stands in for any scopes = starting with "read:" like "read:profile", "read:lists", etc. Precluding = this behavior wasn't my intent, and a liberal interpretation of the text = as-written would (I believe) lead to this being perfectly OK. Namely: Client requests and is granted a service specific scope value like = "send_email_to" in registration. At runtime, the client knows how to = turn "send_email_to" into = "send_email_to:myaddress@email.com", and the AS knows that a client = that's been granted "send_email_to" can ask for = = "send_email_to:myaddress@email.com". The fact that "send_email_to" = expands into an expression language is something specific to the = service, and I personally think it's up to the service to document = "register for this" and "ask for this at authn time" for clients, since = this is all part of the API more than it is part of the underlying OAuth = protocol. OAuth merely provides a handy place to communicate these = values in an interoperable way, the values themselves aren't intended to = be interoperable.=20 But my question to the group is simple: how can we rework the "scope" = metadata claim such that it works in both the simple "bag of discreet = strings" approach to scope as well as the "list of expressions" = approach? Does the language need to change at all? -- Justin _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =20 ------=_NextPart_000_00CF_01CE377A.B8260400 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

+1

 

Best = regards,

Don

Donald F. = Coffin

Founder/CTO

 

=

REMI = Networks

22751 El Prado Suite = 6216

Rancho Santa Margarita, = CA=C2=A0 92688-3836

 

=

Phone:=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 (949) 636-8571

Email:=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 donald.coffin@reminetworks.com=

 

From:= = Tim Bray [mailto:twbray@google.com]
Sent: Friday, April 12, = 2013 11:31 AM
To: Justin Richer
Cc: = oauth@ietf.org
Subject: Re: [OAUTH-WG] Registration: Scope = Values

 

Speaking for myself, I have considerable concern about = Turing-complete programming languages starting to emerge inside scope = strings, which I think is probably a symptom of bad engineering.  I = really like the idea of specifying the scopes you=E2=80=99re going to = ask for at registration time, and if that also gets in the way of what = I=E2=80=99ll call =E2=80=9Cscope creep=E2=80=9D (snicker), that feels = like a feature not a bug.  Anyhow, in practical terms, I = can=E2=80=99t see how you could extend this specify-at-registration-time = feature much without stepping on a very slippery complexity = slope.

 

-T

 

On Fri, Apr 12, 2013 at 11:24 AM, Justin Richer <jricher@mitre.org> wrote:

Currently, the Dynamic = Registration draft defines a "scope" value as part of the = client metadata table, with the following = definition:

=C2=A0=C2=A0 =
scope
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
OPTIONAL.=C2=A0 Space separated list of scope values (as described =
in
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 OAuth 2.0 Section 3.3 [RFC6749]) that the client is =
declaring that
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 it =
may use when requesting access tokens.=C2=A0 If omitted, =
an
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Authorization =
Server MAY register a Client with a default set =
of
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
scopes.


The idea here is that a = client can request a particular set of available scopes from the AS = (analogous as to what's available from many/most manual registration = pages today), and the AS can communicate back to the client what scopes = it's allowed to ask for at authz time. In a strictly-enforced = implementation, the client wouldn't be able to ask for any scopes that = it wasn't registered for in the first place.

However, it's been = brought up in some side conversations that the language as found in the = DynReg spec might get in the way of people using the "scope" = field as an expression language. That is to say, you could have a scope = like "send_email_to:myaddress@email.com" = where the email address portion is variable, or something like = "read:*" which stands in for any scopes starting with = "read:" like "read:profile", "read:lists", = etc. Precluding this behavior wasn't my intent, and a liberal = interpretation of the text as-written would (I believe) lead to this = being perfectly OK. Namely:

Client requests and is granted a = service specific scope value like "send_email_to" in = registration. At runtime, the client knows how to turn = "send_email_to" into "send_email_to:myaddress@email.com", and = the AS knows that a client that's been granted "send_email_to" = can ask for "send_email_to:myaddress@email.com". The = fact that "send_email_to" expands into an expression language = is something specific to the service, and I personally think it's up to = the service to document "register for this" and "ask for = this at authn time" for clients, since this is all part of the API = more than it is part of the underlying OAuth protocol. OAuth merely = provides a handy place to communicate these values in an interoperable = way, the values themselves aren't intended to be interoperable. =


But my question to the group is simple: how can we rework = the "scope" metadata claim such that it works in both the = simple "bag of discreet strings" approach to scope as well as = the "list of expressions" approach? Does the language need to = change at all?

 -- Justin


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

 

------=_NextPart_000_00CF_01CE377A.B8260400-- From donald.coffin@reminetworks.com Fri Apr 12 12:42:26 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A69D21F8ED5 for ; Fri, 12 Apr 2013 12:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1T-Lq-7MjoGn for ; Fri, 12 Apr 2013 12:42:25 -0700 (PDT) Received: from oproxy5-pub.bluehost.com (oproxy5-pub.bluehost.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id 3611021F8E9A for ; Fri, 12 Apr 2013 12:42:25 -0700 (PDT) Received: (qmail 20301 invoked by uid 0); 12 Apr 2013 19:42:02 -0000 Received: from unknown (HELO host125.hostmonster.com) (74.220.207.125) by cpoproxy2.bluehost.com with SMTP; 12 Apr 2013 19:42:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=reminetworks.com; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=0Hrzmakw8KpBTpr8hMYxuo4AF3VDfiGE39YtZk0467c=; b=xfL6vfKopKo8TU++2444G7qrgW+nJRpfDAFHC5D9kOn2HW2y4EaIdCKinngISNlh0RcGk5k3Jn2IkCWGCqBBoBofjH/BSO3jQi06RC1TD1cDf0RYl4WQ97XB8+LFy4+k; Received: from [68.4.207.246] (port=2521 helo=HPPavilionElite) by host125.hostmonster.com with esmtpa (Exim 4.80) (envelope-from ) id 1UQjrF-0001OV-Kt; Fri, 12 Apr 2013 13:42:01 -0600 From: "Donald F Coffin" To: "'Mike Jones'" , "'Tim Bray'" , "'Justin Richer'" References: <51685177.8060603@mitre.org> <4E1F6AAD24975D4BA5B168042967394367619C97@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394367619C97@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Fri, 12 Apr 2013 12:40:25 -0700 Message-ID: <00d301ce37b5$94657b50$bd3071f0$@reminetworks.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D4_01CE377A.E808ED40" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKhIF8eX/RIXMm9kgogxQzt5YcUwgJZhmb4Ab2hjCiXDHEfcA== Content-Language: en-us X-Identified-User: {1395:host125.hostmonster.com:reminetw:reminetworks.com} {sentby:smtp auth 68.4.207.246 authed with donald.coffin@reminetworks.com} Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Registration: Scope Values X-BeenThere: oauth@ietf.org X-Mailman-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, 12 Apr 2013 19:42:26 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00D4_01CE377A.E808ED40 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 =20 Best regards, Don Donald F. Coffin Founder/CTO =20 REMI Networks 22751 El Prado Suite 6216 Rancho Santa Margarita, CA 92688-3836 =20 Phone: (949) 636-8571 Email: = donald.coffin@reminetworks.com =20 From: Mike Jones [mailto:Michael.Jones@microsoft.com]=20 Sent: Friday, April 12, 2013 11:46 AM To: Tim Bray; Justin Richer Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Registration: Scope Values =20 Tim, if you look at the scope examples in = http://tools.ietf.org/html/rfc6750#section-3, you=E2=80=99ll see that = one of them, from the Open Authentication Technology Committee (OATC) = Online Multimedia Authorization Protocol [OMAP], does use non-static = scope values to convey parameters: scope=3D"urn:example:channel=3DHBO&urn:example:rating=3DG,PG-13" =20 Also, if you look at the OAuth usage survey results collected during = IETF 86 in = http://self-issued.info/misc/OAuth%20Feature%20Matrix%20-%20All.xlsx = (cell G145), you=E2=80=99ll see that the OpenESPI =E2=80=9CSmart = Grid=E2=80=9D specs also use scope values to convey structured = information. =20 The horse has left the barn on requiring scope values to be static = strings. RFC 6749 didn=E2=80=99t do it and lots of implementations are = conveying structured information there. As Justin is bringing up, the = OAuth Registration spec shouldn=E2=80=99t do anything to preclude this = usage. =20 Cheers, -- Mike =20 From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf = Of Tim Bray Sent: Friday, April 12, 2013 11:31 AM To: Justin Richer Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Registration: Scope Values =20 Speaking for myself, I have considerable concern about Turing-complete = programming languages starting to emerge inside scope strings, which I = think is probably a symptom of bad engineering. I really like the idea = of specifying the scopes you=E2=80=99re going to ask for at registration = time, and if that also gets in the way of what I=E2=80=99ll call = =E2=80=9Cscope creep=E2=80=9D (snicker), that feels like a feature not a = bug. Anyhow, in practical terms, I can=E2=80=99t see how you could = extend this specify-at-registration-time feature much without stepping = on a very slippery complexity slope. =20 -T =20 On Fri, Apr 12, 2013 at 11:24 AM, Justin Richer = wrote: Currently, the Dynamic Registration draft defines a "scope" value as = part of the client metadata table, with the following definition: scope OPTIONAL. Space separated list of scope values (as described in OAuth 2.0 Section = 3.3 [RFC6749]) that the client is declaring that it may use when requesting access tokens. If omitted, an Authorization Server MAY register a Client with a default set of scopes. The idea here is that a client can request a particular set of available = scopes from the AS (analogous as to what's available from many/most = manual registration pages today), and the AS can communicate back to the = client what scopes it's allowed to ask for at authz time. In a = strictly-enforced implementation, the client wouldn't be able to ask for = any scopes that it wasn't registered for in the first place. However, it's been brought up in some side conversations that the = language as found in the DynReg spec might get in the way of people = using the "scope" field as an expression language. That is to say, you = could have a scope like = "send_email_to:myaddress@email.com" where the email address portion is = variable, or something like "read:*" which stands in for any scopes = starting with "read:" like "read:profile", "read:lists", etc. Precluding = this behavior wasn't my intent, and a liberal interpretation of the text = as-written would (I believe) lead to this being perfectly OK. Namely: Client requests and is granted a service specific scope value like = "send_email_to" in registration. At runtime, the client knows how to = turn "send_email_to" into = "send_email_to:myaddress@email.com", and the AS knows that a client = that's been granted "send_email_to" can ask for = = "send_email_to:myaddress@email.com". The fact that "send_email_to" = expands into an expression language is something specific to the = service, and I personally think it's up to the service to document = "register for this" and "ask for this at authn time" for clients, since = this is all part of the API more than it is part of the underlying OAuth = protocol. OAuth merely provides a handy place to communicate these = values in an interoperable way, the values themselves aren't intended to = be interoperable.=20 But my question to the group is simple: how can we rework the "scope" = metadata claim such that it works in both the simple "bag of discreet = strings" approach to scope as well as the "list of expressions" = approach? Does the language need to change at all? -- Justin _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =20 ------=_NextPart_000_00D4_01CE377A.E808ED40 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

+1

 

=

Best = regards,

Don

Donald F. = Coffin

Founder/CTO

 

=

REMI = Networks

22751 El Prado Suite = 6216

Rancho Santa Margarita, = CA=C2=A0 92688-3836

 

=

Phone:=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 (949) 636-8571

Email:=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 donald.coffin@reminetworks.com=

 

=

From:= = Mike Jones [mailto:Michael.Jones@microsoft.com]
Sent: Friday, = April 12, 2013 11:46 AM
To: Tim Bray; Justin = Richer
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] = Registration: Scope Values

 

Tim, if you look at the scope examples in http://tools.ietf.o= rg/html/rfc6750#section-3, you=E2=80=99ll see that one of them, from = the Open Authentication Technology Committee (OATC) Online Multimedia = Authorization Protocol [OMAP], does use non-static scope values to = convey parameters:

scope=3D"urn:example:channel=3DHBO&urn:example:rating=3D= G,PG-13"

 

Also, if you look at the OAuth usage survey results collected during = IETF 86 in http://self-issued.info/misc/OAuth%20Feature%20Matrix%20-%20All.xlsx= (cell G145), you=E2=80=99ll see that the OpenESPI =E2=80=9CSmart = Grid=E2=80=9D specs also use scope values to convey structured = information.

 

The horse has left the barn on requiring scope values to be static = strings.  RFC 6749 didn=E2=80=99t do it and lots of implementations = are conveying structured information there.  As Justin is bringing = up, the OAuth Registration spec shouldn=E2=80=99t do anything to = preclude this usage.

 

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

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

 

From:= = oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]= On Behalf Of Tim Bray
Sent: Friday, April 12, 2013 = 11:31 AM
To: Justin Richer
Cc: oauth@ietf.org
Subject: Re: = [OAUTH-WG] Registration: Scope Values

 

Speaking for myself, I have considerable concern about = Turing-complete programming languages starting to emerge inside scope = strings, which I think is probably a symptom of bad engineering.  I = really like the idea of specifying the scopes you=E2=80=99re going to = ask for at registration time, and if that also gets in the way of what = I=E2=80=99ll call =E2=80=9Cscope creep=E2=80=9D (snicker), that feels = like a feature not a bug.  Anyhow, in practical terms, I = can=E2=80=99t see how you could extend this specify-at-registration-time = feature much without stepping on a very slippery complexity = slope.

 

-T

 

On Fri, Apr 12, 2013 at 11:24 AM, Justin Richer <jricher@mitre.org> wrote:

Currently, the Dynamic = Registration draft defines a "scope" value as part of the = client metadata table, with the following = definition:

   =
scope
      =
OPTIONAL.  Space separated list of scope values (as described =
in
      OAuth 2.0 Section 3.3 [RFC6749]) that the client is =
declaring that
      it =
may use when requesting access tokens.  If omitted, =
an
      Authorization =
Server MAY register a Client with a default set =
of
      =
scopes.


The idea here is that a = client can request a particular set of available scopes from the AS = (analogous as to what's available from many/most manual registration = pages today), and the AS can communicate back to the client what scopes = it's allowed to ask for at authz time. In a strictly-enforced = implementation, the client wouldn't be able to ask for any scopes that = it wasn't registered for in the first place.

However, it's been = brought up in some side conversations that the language as found in the = DynReg spec might get in the way of people using the "scope" = field as an expression language. That is to say, you could have a scope = like "send_email_to:myaddress@email.com" = where the email address portion is variable, or something like = "read:*" which stands in for any scopes starting with = "read:" like "read:profile", "read:lists", = etc. Precluding this behavior wasn't my intent, and a liberal = interpretation of the text as-written would (I believe) lead to this = being perfectly OK. Namely:

Client requests and is granted a = service specific scope value like "send_email_to" in = registration. At runtime, the client knows how to turn = "send_email_to" into "send_email_to:myaddress@email.com", and = the AS knows that a client that's been granted "send_email_to" = can ask for "send_email_to:myaddress@email.com". The = fact that "send_email_to" expands into an expression language = is something specific to the service, and I personally think it's up to = the service to document "register for this" and "ask for = this at authn time" for clients, since this is all part of the API = more than it is part of the underlying OAuth protocol. OAuth merely = provides a handy place to communicate these values in an interoperable = way, the values themselves aren't intended to be interoperable. =


But my question to the group is simple: how can we rework = the "scope" metadata claim such that it works in both the = simple "bag of discreet strings" approach to scope as well as = the "list of expressions" approach? Does the language need to = change at all?

 -- Justin


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

 

------=_NextPart_000_00D4_01CE377A.E808ED40-- From jricher@mitre.org Fri Apr 12 12:48:40 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14C5121F8D40 for ; Fri, 12 Apr 2013 12:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yV3bWYNtXvLr for ; Fri, 12 Apr 2013 12:48:37 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 5385421F8C3C for ; Fri, 12 Apr 2013 12:48:37 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E3B0B1F0627; Fri, 12 Apr 2013 15:48:36 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id C9DA61F061E; Fri, 12 Apr 2013 15:48:36 -0400 (EDT) Received: from [10.146.15.29] (129.83.31.58) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.342.3; Fri, 12 Apr 2013 15:48:36 -0400 Message-ID: <5168650F.1070709@mitre.org> Date: Fri, 12 Apr 2013 15:48:31 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: Donald F Coffin References: <51685177.8060603@mitre.org> <00c901ce37b5$443c3dd0$ccb4b970$@reminetworks.com> In-Reply-To: <00c901ce37b5$443c3dd0$ccb4b970$@reminetworks.com> Content-Type: multipart/alternative; boundary="------------050908030801070105030207" X-Originating-IP: [129.83.31.58] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Registration: Scope Values X-BeenThere: oauth@ietf.org X-Mailman-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, 12 Apr 2013 19:48:40 -0000 --------------050908030801070105030207 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit The question refers to the Dynamic Registration draft specifically, since that's what's still editable. RFC6749 treats scopes as bags of strings that are specific to the API that they're protecting, which lets them be either static strings or expressions (or, really, whatever you like them to be). The problem is that the Dynamic Registration draft isn't defining just the conveyance of the scope string during the authorization process, it's got to have language on what a scope is *for* in order for it to make sense in registration. In other words, what does it mean to be "registered" with a scope? What does it mean to ask for a scope at registration time? What does it mean for a server to "grant" a scope at registration time? I had thought that the current language (which is mostly lifted from RFC6749) was sufficient, but there's been question as to its intent, so I want to make sure that it's very clear that Dynamic Registration is as hands-off about scope values as RFC6749 is. -- Justin On 04/12/2013 03:38 PM, Donald F Coffin wrote: > > Justin, > > While I understand the need to clarify the usage of the scope > metadata, I'm not clear on whether your question refers to the Dynamic > Registration draft or to RFC 6749? > > The current language of the Dynamic Registration draft to describe the > scope metadata usage is the same language used to describe the scope > parameter that appears in Section 3.3 of RFC 6749. If the Dynamic > Registration draft uses language different than what is contained in > the scope parameter definition of RFC 6749 additional confusion about > the usage of the scope parameter may arise. Perhaps the best way to > address the issue within the Dynamic Registration draft is to provide > an explanation. The examples you provided in your posting could > easily be included in the Dynamic Registration draft and would achieve > the desired effect of demonstrating how the OAuth 2.0 scope parameter > might be used. > > Best regards, > > Don > > Donald F. Coffin > > Founder/CTO > > REMI Networks > > 22751 El Prado Suite 6216 > > Rancho Santa Margarita, CA 92688-3836 > > Phone: (949) 636-8571 > > Email: donald.coffin@reminetworks.com > > > *From:*Justin Richer [mailto:jricher@mitre.org] > *Sent:* Friday, April 12, 2013 11:25 AM > *To:* oauth@ietf.org > *Subject:* [OAUTH-WG] Registration: Scope Values > > Currently, the Dynamic Registration draft defines a "scope" value as > part of the client metadata table, with the following definition: > > scope > OPTIONAL. Space separated list of scope values (as described in > OAuth 2.0Section 3.3 [RFC6749] ) that the client is declaring that > it may use when requesting access tokens. If omitted, an > Authorization Server MAY register a Client with a default set of > scopes. > > > The idea here is that a client can request a particular set of > available scopes from the AS (analogous as to what's available from > many/most manual registration pages today), and the AS can communicate > back to the client what scopes it's allowed to ask for at authz time. > In a strictly-enforced implementation, the client wouldn't be able to > ask for any scopes that it wasn't registered for in the first place. > > However, it's been brought up in some side conversations that the > language as found in the DynReg spec might get in the way of people > using the "scope" field as an expression language. That is to say, you > could have a scope like "send_email_to:myaddress@email.com" > where the email address > portion is variable, or something like "read:*" which stands in for > any scopes starting with "read:" like "read:profile", "read:lists", > etc. Precluding this behavior wasn't my intent, and a liberal > interpretation of the text as-written would (I believe) lead to this > being perfectly OK. Namely: > > Client requests and is granted a service specific scope value like > "send_email_to" in registration. At runtime, the client knows how to > turn "send_email_to" into "send_email_to:myaddress@email.com" > , and the AS knows that a > client that's been granted "send_email_to" can ask for > "send_email_to:myaddress@email.com" > . The fact that > "send_email_to" expands into an expression language is something > specific to the service, and I personally think it's up to the service > to document "register for this" and "ask for this at authn time" for > clients, since this is all part of the API more than it is part of the > underlying OAuth protocol. OAuth merely provides a handy place to > communicate these values in an interoperable way, the values > themselves aren't intended to be interoperable. > > > But my question to the group is simple: how can we rework the "scope" > metadata claim such that it works in both the simple "bag of discreet > strings" approach to scope as well as the "list of expressions" > approach? Does the language need to change at all? > > -- Justin > --------------050908030801070105030207 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit The question refers to the Dynamic Registration draft specifically, since that's what's still editable. RFC6749 treats scopes as bags of strings that are specific to the API that they're protecting, which lets them be either static strings or expressions (or, really, whatever you like them to be). The problem is that the Dynamic Registration draft isn't defining just the conveyance of the scope string during the authorization process, it's got to have language on what a scope is *for* in order for it to make sense in registration. In other words, what does it mean to be "registered" with a scope? What does it mean to ask for a scope at registration time? What does it mean for a server to "grant" a scope at registration time?

I had thought that the current language (which is mostly lifted from RFC6749) was sufficient, but there's been question as to its intent, so I want to make sure that it's very clear that Dynamic Registration is as hands-off about scope values as RFC6749 is.

 -- Justin

On 04/12/2013 03:38 PM, Donald F Coffin wrote:

Justin,

 

While I understand the need to clarify the usage of the scope metadata, I’m not clear on whether your question refers to the Dynamic Registration draft or to RFC 6749? 

 

The current language of the Dynamic Registration draft to describe the scope metadata usage is the same language used to describe the scope parameter that appears in Section 3.3 of RFC 6749.  If the Dynamic Registration draft uses language different than what is contained in the scope parameter definition of RFC 6749 additional confusion about the usage of the scope parameter may arise.  Perhaps the best way to address the issue within the Dynamic Registration draft is to provide an explanation.  The examples you provided in your posting could easily be included in the Dynamic Registration draft and would achieve the desired effect of demonstrating how the OAuth 2.0 scope parameter might be used.

 

Best regards,

Don

Donald F. Coffin

Founder/CTO

 

REMI Networks

22751 El Prado Suite 6216

Rancho Santa Margarita, CA  92688-3836

 

Phone:      (949) 636-8571

Email:       donald.coffin@reminetworks.com

 

From: Justin Richer [mailto:jricher@mitre.org]
Sent: Friday, April 12, 2013 11:25 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Registration: Scope Values

 

Currently, the Dynamic Registration draft defines a "scope" value as part of the client metadata table, with the following definition:

   scope
      OPTIONAL.  Space separated list of scope values (as described in
      OAuth 2.0 Section 3.3 [RFC6749]) that the client is declaring that
      it may use when requesting access tokens.  If omitted, an
      Authorization Server MAY register a Client with a default set of
      scopes.


The idea here is that a client can request a particular set of available scopes from the AS (analogous as to what's available from many/most manual registration pages today), and the AS can communicate back to the client what scopes it's allowed to ask for at authz time. In a strictly-enforced implementation, the client wouldn't be able to ask for any scopes that it wasn't registered for in the first place.

However, it's been brought up in some side conversations that the language as found in the DynReg spec might get in the way of people using the "scope" field as an expression language. That is to say, you could have a scope like "send_email_to:myaddress@email.com" where the email address portion is variable, or something like "read:*" which stands in for any scopes starting with "read:" like "read:profile", "read:lists", etc. Precluding this behavior wasn't my intent, and a liberal interpretation of the text as-written would (I believe) lead to this being perfectly OK. Namely:

Client requests and is granted a service specific scope value like "send_email_to" in registration. At runtime, the client knows how to turn "send_email_to" into "send_email_to:myaddress@email.com", and the AS knows that a client that's been granted "send_email_to" can ask for "send_email_to:myaddress@email.com". The fact that "send_email_to" expands into an expression language is something specific to the service, and I personally think it's up to the service to document "register for this" and "ask for this at authn time" for clients, since this is all part of the API more than it is part of the underlying OAuth protocol. OAuth merely provides a handy place to communicate these values in an interoperable way, the values themselves aren't intended to be interoperable.


But my question to the group is simple: how can we rework the "scope" metadata claim such that it works in both the simple "bag of discreet strings" approach to scope as well as the "list of expressions" approach? Does the language need to change at all?

 -- Justin


--------------050908030801070105030207-- From donald.coffin@reminetworks.com Fri Apr 12 13:27:02 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11EBE21F8F01 for ; Fri, 12 Apr 2013 13:27:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fk1UoXDkNWX2 for ; Fri, 12 Apr 2013 13:26:58 -0700 (PDT) Received: from oproxy5-pub.bluehost.com (oproxy5-pub.bluehost.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id A759821F8EBE for ; Fri, 12 Apr 2013 13:26:58 -0700 (PDT) Received: (qmail 2252 invoked by uid 0); 12 Apr 2013 20:26:37 -0000 Received: from unknown (HELO host125.hostmonster.com) (74.220.207.125) by cpoproxy2.bluehost.com with SMTP; 12 Apr 2013 20:26:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=reminetworks.com; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=3JKJcx4M13dGNBQITuoQioZLf5sGbe1b/bAARw7bu3o=; b=BcwDeTQbTqqcK1Z1JnWij+wuSIfpWNoiHeE7hIaF0zqh3KI+xgRxif+OEZbIK1TFILpO3B0PKoHj0Bsb864P3UnFinsB8JeyE3JBSLh0FdRY5TECNetzfFZrh19rDb+R; Received: from [68.4.207.246] (port=3304 helo=HPPavilionElite) by host125.hostmonster.com with esmtpa (Exim 4.80) (envelope-from ) id 1UQkYO-0004Pn-WB; Fri, 12 Apr 2013 14:26:37 -0600 From: "Donald F Coffin" To: "'Justin Richer'" References: <51685177.8060603@mitre.org> <00c901ce37b5$443c3dd0$ccb4b970$@reminetworks.com> <5168650F.1070709@mitre.org> In-Reply-To: <5168650F.1070709@mitre.org> Date: Fri, 12 Apr 2013 13:25:00 -0700 Message-ID: <010401ce37bb$cf0582e0$6d1088a0$@reminetworks.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0105_01CE3781.22AB65D0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKhIF8eX/RIXMm9kgogxQzt5YcUwgGN6dx1Asn442uXCnevwA== Content-Language: en-us X-Identified-User: {1395:host125.hostmonster.com:reminetw:reminetworks.com} {sentby:smtp auth 68.4.207.246 authed with donald.coffin@reminetworks.com} Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Registration: Scope Values X-BeenThere: oauth@ietf.org X-Mailman-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, 12 Apr 2013 20:27:02 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0105_01CE3781.22AB65D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Justin, Thanks for the clarification. Best regards, Don Donald F. Coffin Founder/CTO REMI Networks 22751 El Prado Suite 6216 Rancho Santa Margarita, CA 92688-3836 Phone: (949) 636-8571 Email: donald.coffin@reminetworks.com From: Justin Richer [mailto:jricher@mitre.org] Sent: Friday, April 12, 2013 12:49 PM To: Donald F Coffin Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Registration: Scope Values The question refers to the Dynamic Registration draft specifically, since that's what's still editable. RFC6749 treats scopes as bags of strings that are specific to the API that they're protecting, which lets them be either static strings or expressions (or, really, whatever you like them to be). The problem is that the Dynamic Registration draft isn't defining just the conveyance of the scope string during the authorization process, it's got to have language on what a scope is *for* in order for it to make sense in registration. In other words, what does it mean to be "registered" with a scope? What does it mean to ask for a scope at registration time? What does it mean for a server to "grant" a scope at registration time? I had thought that the current language (which is mostly lifted from RFC6749) was sufficient, but there's been question as to its intent, so I want to make sure that it's very clear that Dynamic Registration is as hands-off about scope values as RFC6749 is. -- Justin On 04/12/2013 03:38 PM, Donald F Coffin wrote: Justin, While I understand the need to clarify the usage of the scope metadata, I'm not clear on whether your question refers to the Dynamic Registration draft or to RFC 6749? The current language of the Dynamic Registration draft to describe the scope metadata usage is the same language used to describe the scope parameter that appears in Section 3.3 of RFC 6749. If the Dynamic Registration draft uses language different than what is contained in the scope parameter definition of RFC 6749 additional confusion about the usage of the scope parameter may arise. Perhaps the best way to address the issue within the Dynamic Registration draft is to provide an explanation. The examples you provided in your posting could easily be included in the Dynamic Registration draft and would achieve the desired effect of demonstrating how the OAuth 2.0 scope parameter might be used. Best regards, Don Donald F. Coffin Founder/CTO REMI Networks 22751 El Prado Suite 6216 Rancho Santa Margarita, CA 92688-3836 Phone: (949) 636-8571 Email: donald.coffin@reminetworks.com From: Justin Richer [mailto:jricher@mitre.org] Sent: Friday, April 12, 2013 11:25 AM To: oauth@ietf.org Subject: [OAUTH-WG] Registration: Scope Values Currently, the Dynamic Registration draft defines a "scope" value as part of the client metadata table, with the following definition: scope OPTIONAL. Space separated list of scope values (as described in OAuth 2.0 Section 3.3 [RFC6749]) that the client is declaring that it may use when requesting access tokens. If omitted, an Authorization Server MAY register a Client with a default set of scopes. The idea here is that a client can request a particular set of available scopes from the AS (analogous as to what's available from many/most manual registration pages today), and the AS can communicate back to the client what scopes it's allowed to ask for at authz time. In a strictly-enforced implementation, the client wouldn't be able to ask for any scopes that it wasn't registered for in the first place. However, it's been brought up in some side conversations that the language as found in the DynReg spec might get in the way of people using the "scope" field as an expression language. That is to say, you could have a scope like "send_email_to:myaddress@email.com" where the email address portion is variable, or something like "read:*" which stands in for any scopes starting with "read:" like "read:profile", "read:lists", etc. Precluding this behavior wasn't my intent, and a liberal interpretation of the text as-written would (I believe) lead to this being perfectly OK. Namely: Client requests and is granted a service specific scope value like "send_email_to" in registration. At runtime, the client knows how to turn "send_email_to" into "send_email_to:myaddress@email.com", and the AS knows that a client that's been granted "send_email_to" can ask for "send_email_to:myaddress@email.com". The fact that "send_email_to" expands into an expression language is something specific to the service, and I personally think it's up to the service to document "register for this" and "ask for this at authn time" for clients, since this is all part of the API more than it is part of the underlying OAuth protocol. OAuth merely provides a handy place to communicate these values in an interoperable way, the values themselves aren't intended to be interoperable. But my question to the group is simple: how can we rework the "scope" metadata claim such that it works in both the simple "bag of discreet strings" approach to scope as well as the "list of expressions" approach? Does the language need to change at all? -- Justin ------=_NextPart_000_0105_01CE3781.22AB65D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Justin,

 

Thanks for the = clarification.

 

Best = regards,

Don

Donald F. = Coffin

Founder/CTO=

 =

REMI = Networks

22751 El = Prado Suite 6216

Rancho = Santa Margarita, CA  92688-3836

 =

Phone: = ;     (949) 636-8571

Email: = ;      donald.coffin@reminetworks.com=

 

From: Justin Richer [mailto:jricher@mitre.org]
Sent: Friday, = April 12, 2013 12:49 PM
To: Donald F Coffin
Cc: = oauth@ietf.org
Subject: Re: [OAUTH-WG] Registration: Scope = Values

 

The question refers to the Dynamic = Registration draft specifically, since that's what's still editable. = RFC6749 treats scopes as bags of strings that are specific to the API = that they're protecting, which lets them be either static strings or = expressions (or, really, whatever you like them to be). The problem is = that the Dynamic Registration draft isn't defining just the conveyance = of the scope string during the authorization process, it's got to have = language on what a scope is *for* in order for it to make sense in = registration. In other words, what does it mean to be = "registered" with a scope? What does it mean to ask for a = scope at registration time? What does it mean for a server to = "grant" a scope at registration time?

I had thought = that the current language (which is mostly lifted from RFC6749) was = sufficient, but there's been question as to its intent, so I want to = make sure that it's very clear that Dynamic Registration is as hands-off = about scope values as RFC6749 is.

 -- = Justin

On 04/12/2013 03:38 PM, = Donald F Coffin wrote:

Justin,

 

While I = understand the need to clarify the usage of the scope metadata, = I’m not clear on whether your question refers to the Dynamic = Registration draft or to RFC 6749? 

 

The current = language of the Dynamic Registration draft to describe the scope = metadata usage is the same language used to describe the scope parameter = that appears in Section 3.3 of RFC 6749.  If the Dynamic = Registration draft uses language different than what is contained in the = scope parameter definition of RFC 6749 additional confusion about the = usage of the scope parameter may arise.  Perhaps the best way to = address the issue within the Dynamic Registration draft is to provide an = explanation.  The examples you provided in your posting could = easily be included in the Dynamic Registration draft and would achieve = the desired effect of demonstrating how the OAuth 2.0 scope parameter = might be used.

 

Best = regards,

Don

Donald F. = Coffin

Founder/CTO=

 

REMI = Networks

22751 El = Prado Suite 6216

Rancho = Santa Margarita, CA  92688-3836

 

Phone: = ;     (949) 636-8571

Email: = ;      donald.coffin@reminetworks= .com

 

From: Justin Richer [mailto:jricher@mitre.org] =
Sent: Friday, April 12, 2013 11:25 AM
To: oauth@ietf.org
Subject: = [OAUTH-WG] Registration: Scope = Values

 

Currently, the Dynamic Registration draft = defines a "scope" value as part of the client metadata table, = with the following definition:

   =
scope
      =
OPTIONAL.  Space separated list of scope values (as described =
in
      OAuth 2.0 Section 3.3 =
[RFC6749]) that the client is declaring =
that
      it may use when =
requesting access tokens.  If omitted, =
an
      Authorization =
Server MAY register a Client with a default set =
of
      =
scopes.


The idea here is that a = client can request a particular set of available scopes from the AS = (analogous as to what's available from many/most manual registration = pages today), and the AS can communicate back to the client what scopes = it's allowed to ask for at authz time. In a strictly-enforced = implementation, the client wouldn't be able to ask for any scopes that = it wasn't registered for in the first place.

However, it's been = brought up in some side conversations that the language as found in the = DynReg spec might get in the way of people using the "scope" = field as an expression language. That is to say, you could have a scope = like "send_email_to:mya= ddress@email.com" where the email address portion is variable, = or something like "read:*" which stands in for any scopes = starting with "read:" like "read:profile", = "read:lists", etc. Precluding this behavior wasn't my intent, = and a liberal interpretation of the text as-written would (I believe) = lead to this being perfectly OK. Namely:

Client requests and is = granted a service specific scope value like "send_email_to" in = registration. At runtime, the client knows how to turn = "send_email_to" into "send_email_to:mya= ddress@email.com", and the AS knows that a client that's been = granted "send_email_to" can ask for "send_email_to:mya= ddress@email.com". The fact that "send_email_to" = expands into an expression language is something specific to the = service, and I personally think it's up to the service to document = "register for this" and "ask for this at authn time" = for clients, since this is all part of the API more than it is part of = the underlying OAuth protocol. OAuth merely provides a handy place to = communicate these values in an interoperable way, the values themselves = aren't intended to be interoperable.


But my question to the = group is simple: how can we rework the "scope" metadata claim = such that it works in both the simple "bag of discreet = strings" approach to scope as well as the "list of = expressions" approach? Does the language need to change at = all?

 -- Justin

 

------=_NextPart_000_0105_01CE3781.22AB65D0-- From stephen.farrell@cs.tcd.ie Fri Apr 12 13:54:09 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D576721F8EC1 for ; Fri, 12 Apr 2013 13:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bIq0ZFj1WJyX for ; Fri, 12 Apr 2013 13:54:06 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id D1CFA21F8E99 for ; Fri, 12 Apr 2013 13:54:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E6FF8BE62 for ; Fri, 12 Apr 2013 21:53:43 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pwZCjn57MPBw for ; Fri, 12 Apr 2013 21:53:38 +0100 (IST) Received: from [10.87.48.8] (unknown [86.46.18.6]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id CB79ABE61 for ; Fri, 12 Apr 2013 21:53:37 +0100 (IST) Message-ID: <51687451.3020307@cs.tcd.ie> Date: Fri, 12 Apr 2013 21:53:37 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: "oauth@ietf.org" References: <51644F9A.9040402@cs.tcd.ie> In-Reply-To: <51644F9A.9040402@cs.tcd.ie> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-revocation-06 X-BeenThere: oauth@ietf.org X-Mailman-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, 12 Apr 2013 20:54:09 -0000 Hi, I'm surprised there've been no responses. I thought there was more interest in this one. Ta, S. On 04/09/2013 06:27 PM, Stephen Farrell wrote: > > Hi, > > I've done my AD review of this draft. I have two quick questions > I'd like to get answered before I start IETF LC. Depending on the > answers maybe we should re-spin or just fire ahead, let's see... > > (1) 2.1: "upon the return of the request" isn't right is it? I > think you mean the response at least. And what about HTTP error > handling? What if I get a 503 error? Is the client supposed > to re-send ever? Don't you need to say? > > (2) 2.2: what's in the response body with a 200 response? If it > doesn't matter please say so. > > I see from the write-up one author hasn't confirmed there are > no IPR issues. I've sent a Marius a mail so hopefully we > can sort that as we go. > > I also have the following nits that can be fixed (if need > be) whenever the draft is next changed: > > - intro: "app" isn't really a great term to use, can you replace > with something from 6479. > > - section 2: the "MAY include a query component" is sort of > dangling there, maybe it'd be better moved elsewhere? > > - section 2: "MUST be obtained from a trustworthy source." might > generate comment from IESG members who don't like using 2119 > terms in ways that don't affect interoperability. (I'm fine with > it fwiw, and have nearly cured 'em of that craze;-) Consider > s/MUST/need to/ here. > > - 2.1: ought there be a registry for token_type_hint values? It > looks like maybe there ought be. > > - 2.1: "A client compliant with [RFC6749] must be prepared" was > that meant to be a 2119 MUST? > > - section 6: maybe s/shall/need to/ in the last para > > Cheers, > S. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From jricher@mitre.org Fri Apr 12 14:03:33 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C667221F8DDF for ; Fri, 12 Apr 2013 14:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.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 HPR-lClW6VuQ for ; Fri, 12 Apr 2013 14:03:32 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 5AA2221F8DD1 for ; Fri, 12 Apr 2013 14:03:25 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id DB9261F0ACE; Fri, 12 Apr 2013 17:03:24 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id AC71C1F0AC9; Fri, 12 Apr 2013 17:03:24 -0400 (EDT) Received: from [10.146.15.29] (129.83.31.58) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.342.3; Fri, 12 Apr 2013 17:03:24 -0400 Message-ID: <51687697.3060602@mitre.org> Date: Fri, 12 Apr 2013 17:03:19 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: Stephen Farrell References: <51644F9A.9040402@cs.tcd.ie> <51687451.3020307@cs.tcd.ie> In-Reply-To: <51687451.3020307@cs.tcd.ie> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [129.83.31.58] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-revocation-06 X-BeenThere: oauth@ietf.org X-Mailman-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, 12 Apr 2013 21:03:33 -0000 Hi Stephen, I didn't respond as I didn't have anything to add to your comments, but what little details I have are inline. On 04/12/2013 04:53 PM, Stephen Farrell wrote: > Hi, > > I'm surprised there've been no responses. I thought > there was more interest in this one. > > Ta, > S. > > On 04/09/2013 06:27 PM, Stephen Farrell wrote: >> Hi, >> >> I've done my AD review of this draft. I have two quick questions >> I'd like to get answered before I start IETF LC. Depending on the >> answers maybe we should re-spin or just fire ahead, let's see... >> >> (1) 2.1: "upon the return of the request" isn't right is it? I >> think you mean the response at least. And what about HTTP error >> handling? What if I get a 503 error? Is the client supposed >> to re-send ever? Don't you need to say? Should this read "upon receipt of an HTTP 200 response from the server" instead? If there's a 503, the client can't assume the token is gone, but it also probably shouldn't try spamming the endpoint, either. >> >> (2) 2.2: what's in the response body with a 200 response? If it >> doesn't matter please say so. Doesn't matter. All information is conveyed in the response code. >> >> I see from the write-up one author hasn't confirmed there are >> no IPR issues. I've sent a Marius a mail so hopefully we >> can sort that as we go. >> >> I also have the following nits that can be fixed (if need >> be) whenever the draft is next changed: >> >> - intro: "app" isn't really a great term to use, can you replace >> with something from 6479. "app" was chosen because the application to use here could be either the Client or the Resource Server in RFC6749, so neither is really the right fit. It's whoever's revoking the token. >> >> - section 2: the "MAY include a query component" is sort of >> dangling there, maybe it'd be better moved elsewhere? Don't see where else this could fit. Basically we're saying the endpoint URL can be defined as "/endpoint?type=revoke" just as easily as "/revoke". >> >> - section 2: "MUST be obtained from a trustworthy source." might >> generate comment from IESG members who don't like using 2119 >> terms in ways that don't affect interoperability. (I'm fine with >> it fwiw, and have nearly cured 'em of that craze;-) Consider >> s/MUST/need to/ here. WFM. >> >> - 2.1: ought there be a registry for token_type_hint values? It >> looks like maybe there ought be. I think a registry is overkill for this kind of thing, but I suppose it could be set up. It's meant to be a *hint* to the server as to what kind of token it is. If it does get set up, the Introspection draft will use it (if that ever can get either pulled into the WG or moved through as an individual submission). >> - 2.1: "A client compliant with [RFC6749] must be prepared" was >> that meant to be a 2119 MUST? This is informative, not normative. You could easily replace "must" with "needs to" here and get the same intended meaning, which is that tokens can disappear when you're not looking. >> >> - section 6: maybe s/shall/need to/ in the last para Same as above. >> >> Cheers, >> S. >> >> _______________________________________________ >> 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 stephen.farrell@cs.tcd.ie Fri Apr 12 15:40:06 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1814021F8EF2 for ; Fri, 12 Apr 2013 15:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pGvDsTxA-z1T for ; Fri, 12 Apr 2013 15:40:05 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 22C6F21F85B3 for ; Fri, 12 Apr 2013 15:40:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E802CBE61; Fri, 12 Apr 2013 23:39:42 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSuiZzqhbAlD; Fri, 12 Apr 2013 23:39:41 +0100 (IST) Received: from [10.87.48.4] (unknown [86.45.56.45]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 2F982BE5F; Fri, 12 Apr 2013 23:39:41 +0100 (IST) Message-ID: <51688D2C.4060508@cs.tcd.ie> Date: Fri, 12 Apr 2013 23:39:40 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Justin Richer References: <51644F9A.9040402@cs.tcd.ie> <51687451.3020307@cs.tcd.ie> <51687697.3060602@mitre.org> In-Reply-To: <51687697.3060602@mitre.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-revocation-06 X-BeenThere: oauth@ietf.org X-Mailman-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, 12 Apr 2013 22:40:06 -0000 Hiya, On 04/12/2013 10:03 PM, Justin Richer wrote: > Hi Stephen, > > I didn't respond as I didn't have anything to add to your comments, but > what little details I have are inline. Thanks:-) > On 04/12/2013 04:53 PM, Stephen Farrell wrote: >> Hi, >> >> I'm surprised there've been no responses. I thought >> there was more interest in this one. >> >> Ta, >> S. >> >> On 04/09/2013 06:27 PM, Stephen Farrell wrote: >>> Hi, >>> >>> I've done my AD review of this draft. I have two quick questions >>> I'd like to get answered before I start IETF LC. Depending on the >>> answers maybe we should re-spin or just fire ahead, let's see... >>> >>> (1) 2.1: "upon the return of the request" isn't right is it? I >>> think you mean the response at least. And what about HTTP error >>> handling? What if I get a 503 error? Is the client supposed >>> to re-send ever? Don't you need to say? > Should this read "upon receipt of an HTTP 200 response from the server" > instead? Seems like it needs some fix anyway. I'll mark the draft as revised I-D needed. > If there's a 503, the client can't assume the token is gone, > but it also probably shouldn't try spamming the endpoint, either. So what is a client supposed to do if it gets a 503? >>> (2) 2.2: what's in the response body with a 200 response? If it >>> doesn't matter please say so. > Doesn't matter. All information is conveyed in the response code. That'd be fine. But doesn't it need saying? Like I said the rest are nits. But to be clear: I think we (me and the WG) need to figure out the above before IETF LC starts. Cheers, S. > >>> >>> I see from the write-up one author hasn't confirmed there are >>> no IPR issues. I've sent a Marius a mail so hopefully we >>> can sort that as we go. >>> >>> I also have the following nits that can be fixed (if need >>> be) whenever the draft is next changed: >>> >>> - intro: "app" isn't really a great term to use, can you replace >>> with something from 6479. > "app" was chosen because the application to use here could be either the > Client or the Resource Server in RFC6749, so neither is really the right > fit. It's whoever's revoking the token. > >>> >>> - section 2: the "MAY include a query component" is sort of >>> dangling there, maybe it'd be better moved elsewhere? > Don't see where else this could fit. Basically we're saying the endpoint > URL can be defined as "/endpoint?type=revoke" just as easily as "/revoke". >>> >>> - section 2: "MUST be obtained from a trustworthy source." might >>> generate comment from IESG members who don't like using 2119 >>> terms in ways that don't affect interoperability. (I'm fine with >>> it fwiw, and have nearly cured 'em of that craze;-) Consider >>> s/MUST/need to/ here. > WFM. >>> >>> - 2.1: ought there be a registry for token_type_hint values? It >>> looks like maybe there ought be. > I think a registry is overkill for this kind of thing, but I suppose it > could be set up. It's meant to be a *hint* to the server as to what kind > of token it is. If it does get set up, the Introspection draft will use > it (if that ever can get either pulled into the WG or moved through as > an individual submission). > >>> - 2.1: "A client compliant with [RFC6749] must be prepared" was >>> that meant to be a 2119 MUST? > This is informative, not normative. You could easily replace "must" with > "needs to" here and get the same intended meaning, which is that tokens > can disappear when you're not looking. > >>> >>> - section 6: maybe s/shall/need to/ in the last para > > Same as above. > >>> >>> Cheers, >>> S. >>> >>> _______________________________________________ >>> 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 Sat Apr 13 02:01:51 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A388C21F8546 for ; Sat, 13 Apr 2013 02:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.853 X-Spam-Level: X-Spam-Status: No, score=-0.853 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dfe-9v1Gj1pN for ; Sat, 13 Apr 2013 02:01:51 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.37]) by ietfa.amsl.com (Postfix) with ESMTP id 1557221F8540 for ; Sat, 13 Apr 2013 02:01:50 -0700 (PDT) Received: from [79.253.8.253] (helo=[192.168.71.56]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1UQwLD-0008S3-I0; Sat, 13 Apr 2013 11:01:47 +0200 References: <51644F9A.9040402@cs.tcd.ie> <51687451.3020307@cs.tcd.ie> <51687697.3060602@mitre.org> Mime-Version: 1.0 (1.0) In-Reply-To: <51687697.3060602@mitre.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <23F39A94-54BE-4EA9-9792-66338CBA0A30@lodderstedt.net> X-Mailer: iPad Mail (10B329) From: Torsten Lodderstedt Date: Sat, 13 Apr 2013 11:01:47 +0200 To: "oauth@ietf.org" X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-revocation-06 X-BeenThere: oauth@ietf.org X-Mailman-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, 13 Apr 2013 09:01:51 -0000 Hi all, what do others think regarding a registry for token_type_hint values? regards, Torsten. Am 12.04.2013 um 23:03 schrieb Justin Richer : >>> - 2.1: ought there be a registry for token_type_hint values? It >>> looks like maybe there ought be. > I think a registry is overkill for this kind of thing, but I suppose it co= uld be set up. It's meant to be a *hint* to the server as to what kind of to= ken it is. If it does get set up, the Introspection draft will use it (if th= at ever can get either pulled into the WG or moved through as an individual s= ubmission). From bashkim.marangozi@hotmail.com Sat Apr 13 10:18:48 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7345821F8B27 for ; Sat, 13 Apr 2013 10:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gej3G694b2+2 for ; Sat, 13 Apr 2013 10:18:47 -0700 (PDT) Received: from bay0-omc1-s22.bay0.hotmail.com (bay0-omc1-s22.bay0.hotmail.com [65.54.190.33]) by ietfa.amsl.com (Postfix) with ESMTP id 31D0321F8AC2 for ; Sat, 13 Apr 2013 10:18:47 -0700 (PDT) Received: from BAY172-W20 ([65.54.190.61]) by bay0-omc1-s22.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 13 Apr 2013 10:18:47 -0700 X-EIP: [YSrhIesd6kkb6iY4WrGaXoRQwYznEdBt] X-Originating-Email: [bashkim.marangozi@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_73ae2105-5414-41ac-b6c8-c10b581f5aea_" From: Bashkim Marangozi To: "OAuth@ietf.org" Date: Sat, 13 Apr 2013 19:18:46 +0200 Importance: Normal In-Reply-To: References: MIME-Version: 1.0 X-OriginalArrivalTime: 13 Apr 2013 17:18:47.0322 (UTC) FILETIME=[F54917A0:01CE386A] Subject: Re: [OAUTH-WG] Welcome to the "OAuth" mailing list X-BeenThere: oauth@ietf.org X-Mailman-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, 13 Apr 2013 17:26:55 -0000 --_73ae2105-5414-41ac-b6c8-c10b581f5aea_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Ok my list Bashkimi of Tirana Albania! Thanks! > Subject: Welcome to the "OAuth" mailing list > From: oauth-request@ietf.org > To: bashkim.marangozi@hotmail.com > Date: Sat=2C 13 Apr 2013 10:06:20 -0700 >=20 > Welcome to the OAuth@ietf.org mailing list! Any submission to the IETF > intended by the Contributor for publication as all or part of an IETF > Internet-Draft or RFC and any statement made within the context of an > IETF activity is considered an "IETF Contribution". Such statements > include oral statements in IETF sessions=2C as well as written and > electronic communications made at any time or place=2C which are > addressed to: the IETF plenary session=2C any IETF working group or > portion thereof=2C the IESG=2C or any member thereof on behalf of the > IESG=2C the IAB or any member thereof on behalf of the IAB=2C any IETF > mailing list=2C including the IETF list itself=2C any working group or > design team list=2C or any other list functioning under IETF auspices=2C > the RFC Editor or the Internet-Drafts function All IETF Contributions > are subject to the rules of RFC 3978 (updated by RFC 4748) and RFC > 3979(updated by RFC 4879).=20 >=20 > Statements made outside of an IETF session=2C mailing list or other > function that is clearly not intended to be input to an IETF activity=2C > group or function=2C are not IETF Contributions in the context of this > notice. >=20 > Please consult RFC 3978 (and RFC 4748) for details. >=20 > A participant in any IETF activity is deemed to accept all IETF rules > of process=2C as documented in Best Current Practices RFCs and IESG > Statements. A participant in any IETF activity acknowledges that > written=2C audio and video records of meetings may be made and may be > available to the public. >=20 >=20 > To post to this list=2C send your email to: >=20 > oauth@ietf.org >=20 > General information about the mailing list is at: >=20 > https://www.ietf.org/mailman/listinfo/oauth >=20 > If you ever want to unsubscribe or change your options (eg=2C switch to > or from digest mode=2C change your password=2C etc.)=2C visit your > subscription page at: >=20 > https://www.ietf.org/mailman/options/oauth/bashkim.marangozi%40hotmail.= com >=20 >=20 > You can also make such adjustments via email by sending a message to: >=20 > OAuth-request@ietf.org >=20 > with the word `help' in the subject or body (don't include the > quotes)=2C and you will get back a message with instructions. >=20 > You must know your password to change your options (including changing > the password=2C itself) or to unsubscribe. It is: >=20 > bm.123456789 >=20 > Normally=2C Mailman will remind you of your ietf.org mailing list > passwords once every month=2C although you can disable this if you > prefer. This reminder will also include instructions on how to > unsubscribe or change your account options. There is also a button on > your options page that will email your current password to you. = --_73ae2105-5414-41ac-b6c8-c10b581f5aea_ Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable
Ok my list Bashkimi of Tirana Al= bania!
Thanks!
>=3B Subj= ect: Welcome to the "OAuth" mailing list
>=3B From: oauth-request@ietf= .org
>=3B To: bashkim.marangozi@hotmail.com
>=3B Date: Sat=2C 13 = Apr 2013 10:06:20 -0700
>=3B
>=3B Welcome to the OAuth@ietf.org = mailing list! Any submission to the IETF
>=3B intended by the Contribu= tor for publication as all or part of an IETF
>=3B Internet-Draft or R= FC and any statement made within the context of an
>=3B IETF activity = is considered an "IETF Contribution". Such statements
>=3B include ora= l statements in IETF sessions=2C as well as written and
>=3B electroni= c communications made at any time or place=2C which are
>=3B addressed= to: the IETF plenary session=2C any IETF working group or
>=3B portio= n thereof=2C the IESG=2C or any member thereof on behalf of the
>=3B I= ESG=2C the IAB or any member thereof on behalf of the IAB=2C any IETF
&g= t=3B mailing list=2C including the IETF list itself=2C any working group or=
>=3B design team list=2C or any other list functioning under IETF aus= pices=2C
>=3B the RFC Editor or the Internet-Drafts function All IETF = Contributions
>=3B are subject to the rules of RFC 3978 (updated by RF= C 4748) and RFC
>=3B 3979(updated by RFC 4879).
>=3B
>=3B = Statements made outside of an IETF session=2C mailing list or other
>= =3B function that is clearly not intended to be input to an IETF activity= =2C
>=3B group or function=2C are not IETF Contributions in the contex= t of this
>=3B notice.
>=3B
>=3B Please consult RFC 3978 (a= nd RFC 4748) for details.
>=3B
>=3B A participant in any IETF ac= tivity is deemed to accept all IETF rules
>=3B of process=2C as docume= nted in Best Current Practices RFCs and IESG
>=3B Statements. A partic= ipant in any IETF activity acknowledges that
>=3B written=2C audio and= video records of meetings may be made and may be
>=3B available to th= e public.
>=3B
>=3B
>=3B To post to this list=2C send your= email to:
>=3B
>=3B oauth@ietf.org
>=3B
>=3B Gener= al information about the mailing list is at:
>=3B
>=3B https:/= /www.ietf.org/mailman/listinfo/oauth
>=3B
>=3B If you ever want = to unsubscribe or change your options (eg=2C switch to
>=3B or from di= gest mode=2C change your password=2C etc.)=2C visit your
>=3B subscrip= tion page at:
>=3B
>=3B https://www.ietf.org/mailman/options/o= auth/bashkim.marangozi%40hotmail.com
>=3B
>=3B
>=3B You ca= n also make such adjustments via email by sending a message to:
>=3B <= br>>=3B OAuth-request@ietf.org
>=3B
>=3B with the word `help= ' in the subject or body (don't include the
>=3B quotes)=2C and you wi= ll get back a message with instructions.
>=3B
>=3B You must know= your password to change your options (including changing
>=3B the pas= sword=2C itself) or to unsubscribe. It is:
>=3B
>=3B bm.12345= 6789
>=3B
>=3B Normally=2C Mailman will remind you of your ietf.= org mailing list
>=3B passwords once every month=2C although you can d= isable this if you
>=3B prefer. This reminder will also include instr= uctions on how to
>=3B unsubscribe or change your account options. Th= ere is also a button on
>=3B your options page that will email your cu= rrent password to you.
= --_73ae2105-5414-41ac-b6c8-c10b581f5aea_-- From James.H.Manger@team.telstra.com Sun Apr 14 17:23:30 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B9FE21F8C9B for ; Sun, 14 Apr 2013 17:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cUKj7AJtJu-x for ; Sun, 14 Apr 2013 17:23:29 -0700 (PDT) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id 5AB6721F8B2B for ; Sun, 14 Apr 2013 17:23:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,472,1363093200"; d="scan'208";a="129423729" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipobvi.tcif.telstra.com.au with ESMTP; 15 Apr 2013 10:23:25 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,7045"; a="177652595" Received: from wsmsg3753.srv.dir.telstra.com ([172.49.40.174]) by ipcavi.tcif.telstra.com.au with ESMTP; 15 Apr 2013 10:23:25 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3753.srv.dir.telstra.com ([172.49.40.174]) with mapi; Mon, 15 Apr 2013 10:23:24 +1000 From: "Manger, James H" To: "oauth@ietf.org WG" Date: Mon, 15 Apr 2013 10:23:23 +1000 Thread-Topic: Re: [OAUTH-WG] Registration: Scope Values Thread-Index: Ac45b3BpyTx6EdLMSIaYYpzdUv297w== Message-ID: <255B9BB34FB7D647A506DC292726F6E1150C74DADA@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Registration: Scope Values X-BeenThere: oauth@ietf.org X-Mailman-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, 15 Apr 2013 00:23:30 -0000 UHJlc3VtYWJseSBhdCBhcHAgcmVnaXN0cmF0aW9uIHRpbWUgYW55IHNjb3BlIHNwZWNpZmljYXRp b24gaXMgcmVhbGx5IGEgY29uc3RyYWludCBvbiB0aGUgc2NvcGUgdmFsdWVzIHRoYXQgY2FuIGJl IHJlcXVlc3RlZCBpbiBhbiBhdXRob3JpemF0aW9uIGZsb3cuDQoNClNvIGlkZWFsbHkgcmVnaXN0 cmF0aW9uIHNob3VsZCBhY2NlcHQgcnVsZXMgZm9yIG1hdGNoaW5nIHNjb3BlcywgYXMgb3Bwb3Nl ZCB0byBhY3R1YWwgc2NvcGUgdmFsdWVzLg0KDQpZb3UgY2FuIHRyeSB0byB1c2Ugc2NvcGUgdmFs dWVzIGFzIHRoZWlyIG93biBtYXRjaGluZyBydWxlcy4gVGhhdCBpcyBmaW5lIGZvciBhIHNtYWxs IHNldCBvZiAic3RhdGljIiBzY29wZXMuIEl0IHN0YXJ0cyB0byBmYWlsIHdoZW4gdGhlcmUgYXJl IGEgbGFyZ2UgbnVtYmVyIG9mIHNjb3Blcywgb3Igc2NvcGVzIHRoYXQgY2FuIGluY2x1ZGUgcGFy YW1ldGVycyAocmVzb3VyY2UgcGF0aHM/IGVtYWlsIGFkZHJlc3Nlcz8pLiBZb3UgY2FuIHRyeSB0 byBwYXRjaCB0aG9zZSBmYWlsdXJlcyBieSBhbGxvd2luZyBzZXJ2aWNlcyB0byBkZWZpbmUgc2Vy dmljZS1zcGVjaWZpYyBzcGVjaWFsICJ3aWxkY2FyZCIgc2NvcGUgdmFsdWVzIHRoYXQgY2FuIG9u bHkgYmUgdXNlZCBkdXJpbmcgcmVnaXN0cmF0aW9uIChlZyAicmVhZDoqIikuDQoNCkFsdGVybmF0 aXZlbHksIHJlcGxhY2UgJ3Njb3BlJyBpbiByZWdpc3RyYXRpb24gd2l0aCAnc2NvcGVfcmVnZXgn IHRoYXQgaG9sZHMgYSByZWd1bGFyIGV4cHJlc3Npb24gdGhhdCBhbGwgc2NvcGUgdmFsdWVzIGlu IGFuIGF1dGhvcml6YXRpb24gZmxvdyBtdXN0IG1hdGNoLg0KDQotLQ0KSmFtZXMgTWFuZ2VyDQo= From jricher@mitre.org Mon Apr 15 06:54:49 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82A7E21F93B7 for ; Mon, 15 Apr 2013 06:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QCuMshlNZYQB for ; Mon, 15 Apr 2013 06:54:48 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 93BC921F86C5 for ; Mon, 15 Apr 2013 06:54:48 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 1D6D51F0540; Mon, 15 Apr 2013 09:54:48 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 0D4BD1F0330; Mon, 15 Apr 2013 09:54:48 -0400 (EDT) Received: from [10.146.15.29] (129.83.31.58) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.342.3; Mon, 15 Apr 2013 09:54:47 -0400 Message-ID: <516C069F.9090308@mitre.org> Date: Mon, 15 Apr 2013 09:54:39 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: "Manger, James H" References: <255B9BB34FB7D647A506DC292726F6E1150C74DADA@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1150C74DADA@WSMSG3153V.srv.dir.telstra.com> Content-Type: multipart/alternative; boundary="------------050909090700000206030109" X-Originating-IP: [129.83.31.58] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Registration: Scope Values X-BeenThere: oauth@ietf.org X-Mailman-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, 15 Apr 2013 13:54:49 -0000 --------------050909090700000206030109 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit You are correct that the idea behind the "scope" parameter at registration is a constraint on authorization-time scopes that are made available. It's both a means for the client to request a set of valid scopes and for the server to provision (and echo back to the client) a set of valid scopes. I *really* don't want to try to define a matching language for scope expressions. For that to work, all servers would need to be able to process the regular expressions for all clients, even if the servers themselves only support simple-string scope values. Any regular expression syntax we pick here is guaranteed to be incompatible with something, and I think the complexity doesn't buy much. Also, I think you suddenly have a potential security issue if you have a bad regex in place on either end. As it stands today, the server can interpret the incoming registration scopes and enforce them however it wants to. The real trick comes not from assigning the values to a particular client but to enforcing them, and I think that's always going to be service-specific. We're just not as clear on that as we could be. After looking over everyone's comments so far, I'd like to propose the following text for that section: scope OPTIONAL. Space separated list of scope values (as described in OAuth 2.0Section 3.3 [RFC6749] ) that the client can use when requesting access tokens. As scope values are service-specific, the Authorization Server MAY define its own matching rules when determining if a scope value used during an authorization request is valid according to the scope values assigned during registration. Possible matching rules include wildcard patterns, regular expressions, or exactly matching the string. If omitted, an Authorization Server MAY register a Client with a default set of scopes. Comments? Improvements? -- Justin On 04/14/2013 08:23 PM, Manger, James H wrote: > Presumably at app registration time any scope specification is really a constraint on the scope values that can be requested in an authorization flow. > > So ideally registration should accept rules for matching scopes, as opposed to actual scope values. > > You can try to use scope values as their own matching rules. That is fine for a small set of "static" scopes. It starts to fail when there are a large number of scopes, or scopes that can include parameters (resource paths? email addresses?). You can try to patch those failures by allowing services to define service-specific special "wildcard" scope values that can only be used during registration (eg "read:*"). > > Alternatively, replace 'scope' in registration with 'scope_regex' that holds a regular expression that all scope values in an authorization flow must match. > > -- > James Manger > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------050909090700000206030109 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit You are correct that the idea behind the "scope" parameter at registration is a constraint on authorization-time scopes that are made available. It's both a means for the client to request a set of valid scopes and for the server to provision (and echo back to the client) a set of valid scopes.

I *really* don't want to try to define a matching language for scope expressions. For that to work, all servers would need to be able to process the regular expressions for all clients, even if the servers themselves only support simple-string scope values. Any regular expression syntax we pick here is guaranteed to be incompatible with something, and I think the complexity doesn't buy much. Also, I think you suddenly have a potential security issue if you have a bad regex in place on either end.

As it stands today, the server can interpret the incoming registration scopes and enforce them however it wants to. The real trick comes not from assigning the values to a particular client but to enforcing them, and I think that's always going to be service-specific. We're just not as clear on that as we could be.

After looking over everyone's comments so far, I'd like to propose the following text for that section:


   scope
      OPTIONAL.  Space separated list of scope values (as described in
      OAuth 2.0 Section 3.3 [RFC6749]) that the client can use when 
      requesting access tokens.  As scope values are service-specific, 
      the Authorization Server MAY define its own matching rules when
      determining if a scope value used during an authorization request
      is valid according to the scope values assigned during 
      registration. Possible matching rules include wildcard patterns,
      regular expressions, or exactly matching the string. If omitted, 
      an Authorization Server MAY register a Client with a default 
      set of scopes.

Comments? Improvements?

 -- Justin


On 04/14/2013 08:23 PM, Manger, James H wrote:
Presumably at app registration time any scope specification is really a constraint on the scope values that can be requested in an authorization flow.

So ideally registration should accept rules for matching scopes, as opposed to actual scope values.

You can try to use scope values as their own matching rules. That is fine for a small set of "static" scopes. It starts to fail when there are a large number of scopes, or scopes that can include parameters (resource paths? email addresses?). You can try to patch those failures by allowing services to define service-specific special "wildcard" scope values that can only be used during registration (eg "read:*").

Alternatively, replace 'scope' in registration with 'scope_regex' that holds a regular expression that all scope values in an authorization flow must match.

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

--------------050909090700000206030109-- From twbray@google.com Mon Apr 15 07:14:01 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5114C21F9322 for ; Mon, 15 Apr 2013 07:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6OPvlCTQXLbm for ; Mon, 15 Apr 2013 07:14:00 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 71A5321F9350 for ; Mon, 15 Apr 2013 07:14:00 -0700 (PDT) Received: by mail-ie0-f173.google.com with SMTP id k13so2799015iea.18 for ; Mon, 15 Apr 2013 07:14:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=wFUhpjYHS6SzlEkbOVMUoyttBGRV9Bce0mzzie5/PWw=; b=COPlytnudjqmEtaA0z85qsEvCHnvw5DlIIi3dPUvYMe5dgpsVIzSoP6QAazWWFywqH A55ujFhL6FAVDqmEy3L/Co6i8+YVYDJ+JApvTKK0ExWr1lSIWEHH+p4HArGPg2zt0DES mbHO2+XHxW79YsJ+in7vXcZpxGoozkff21lPJVdAlrEt7AgjQK3tZMQGIUfXyZyo5TMn 0IZY7tBO4Ggm+3C3AvbCbdkAW8BFQU5ml6Y5MUDVXP3NgNRUihIrzAONUkG75qLvFCH9 MGOUcVjwgfgZk4vuspZ4wvep2XiPqp9kh682t6jOiboX+kR+ha5+6awJCg+04yEipBO0 T1mA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=wFUhpjYHS6SzlEkbOVMUoyttBGRV9Bce0mzzie5/PWw=; b=LwvW8PbTfbqF7PdF0LihY9/1vsa0ZVNB7ic0KmjIqZQGiJ4Oy7ZTG2cO6HS1xGY8EL vb5A+H+9q+wh8caTSVonVZpS+pt6jYamXt8NW88uRkkGsUIGR2feIB8W4T8g7BcevpYI mt65EL31N79pssyTeJAg0cIG8wH8zkeSEL6WyUK4W/xWUrxCfJZ66qYTWhRiAWazjrTi i0TIPbzgYQ2B8kS9bQou/uIrnJhMcnZ9c6qdbsoUFNY0vcs5u8r6LPZpOJT+whjqwL4j DVLeBbbPEoDqF9UhOYHWmyXMYo0lXgQ5bV/Uda9okzQhKvPIB9pRNqLvFPswek9kyGB0 VqXA== MIME-Version: 1.0 X-Received: by 10.43.72.133 with SMTP id yo5mr12002863icb.28.1366035239857; Mon, 15 Apr 2013 07:13:59 -0700 (PDT) Received: by 10.64.31.35 with HTTP; Mon, 15 Apr 2013 07:13:59 -0700 (PDT) Received: by 10.64.31.35 with HTTP; Mon, 15 Apr 2013 07:13:59 -0700 (PDT) In-Reply-To: <516C069F.9090308@mitre.org> References: <255B9BB34FB7D647A506DC292726F6E1150C74DADA@WSMSG3153V.srv.dir.telstra.com> <516C069F.9090308@mitre.org> Date: Mon, 15 Apr 2013 07:13:59 -0700 Message-ID: From: Tim Bray To: "Justin P. Richer" Content-Type: multipart/alternative; boundary=001a11c1e89c39139e04da66dd7c X-Gm-Message-State: ALoCoQn100i0orYsysqLDeMDAF1s6H1HfLrBQEwH7sKrg8G7c3NpbWCQmXIHAOfJlbvZz7UpIyz7m1V4gxutRyqjhzHONsAmxvfK3r+XHl+sBFIvk6RxK8VcREl7puXKnERlINKP6qMDyHZI4jpQSNdgbqYOfLsY/B4gLG9XJYZ1FR21mbuZkNv3fH1g6nIk/ViS3qCRPeV6 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Registration: Scope Values X-BeenThere: oauth@ietf.org X-Mailman-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, 15 Apr 2013 14:14:01 -0000 --001a11c1e89c39139e04da66dd7c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This, as written, has zero interoperability. I think this feature can really only be made useful in the case where scopes are fixed strings. -T On Apr 15, 2013 6:54 AM, "Justin Richer" wrote: > You are correct that the idea behind the "scope" parameter at > registration is a constraint on authorization-time scopes that are made > available. It's both a means for the client to request a set of valid > scopes and for the server to provision (and echo back to the client) a se= t > of valid scopes. > > I *really* don't want to try to define a matching language for scope > expressions. For that to work, all servers would need to be able to proce= ss > the regular expressions for all clients, even if the servers themselves > only support simple-string scope values. Any regular expression syntax we > pick here is guaranteed to be incompatible with something, and I think th= e > complexity doesn't buy much. Also, I think you suddenly have a potential > security issue if you have a bad regex in place on either end. > > As it stands today, the server can interpret the incoming registration > scopes and enforce them however it wants to. The real trick comes not fro= m > assigning the values to a particular client but to enforcing them, and I > think that's always going to be service-specific. We're just not as clear > on that as we could be. > > After looking over everyone's comments so far, I'd like to propose the > following text for that section: > > > scope > OPTIONAL. Space separated list of scope values (as described in > OAuth 2.0 Section 3.3 [RFC6749] ) that the client can use when > requesting access tokens. As scope values are service-specific, > the Authorization Server MAY define its own matching rules when > determining if a scope value used during an authorization request > is valid according to the scope values assigned during > registration. Possible matching rules include wildcard patterns, > regular expressions, or exactly matching the string. If omitted, > an Authorization Server MAY register a Client with a default > set of scopes. > > > Comments? Improvements? > > -- Justin > > > On 04/14/2013 08:23 PM, Manger, James H wrote: > > Presumably at app registration time any scope specification is really a c= onstraint on the scope values that can be requested in an authorization flo= w. > > So ideally registration should accept rules for matching scopes, as oppos= ed to actual scope values. > > You can try to use scope values as their own matching rules. That is fine= for a small set of "static" scopes. It starts to fail when there are a lar= ge number of scopes, or scopes that can include parameters (resource paths?= email addresses?). You can try to patch those failures by allowing service= s to define service-specific special "wildcard" scope values that can only = be used during registration (eg "read:*"). > > Alternatively, replace 'scope' in registration with 'scope_regex' that ho= lds a regular expression that all scope values in an authorization flow mus= t match. > > -- > James Manger > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau= th > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --001a11c1e89c39139e04da66dd7c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

This, as written, has zero interoperability.=C2=A0 I think t= his feature can really only be made useful in the case where scopes are fix= ed strings.

-T

On Apr 15, 2013 6:54 AM, "Justin Richer&quo= t; <jricher@mitre.org> wrote= :
=20 =20 =20
You are correct that the idea behind the "scope" parameter at registration is a constraint on authorization-time scopes that are made available. It's both a means for the client to request a set o= f valid scopes and for the server to provision (and echo back to the client) a set of valid scopes.

I *really* don't want to try to define a matching language for scop= e expressions. For that to work, all servers would need to be able to process the regular expressions for all clients, even if the servers themselves only support simple-string scope values. Any regular expression syntax we pick here is guaranteed to be incompatible with something, and I think the complexity doesn't buy much. Also, I think you suddenly have a potential security issue if you have a bad regex in place on either end.

As it stands today, the server can interpret the incoming registration scopes and enforce them however it wants to. The real trick comes not from assigning the values to a particular client but to enforcing them, and I think that's always going to be service-specific. We're just not as clear on that as we could be.
After looking over everyone's comments so far, I'd like to prop= ose the following text for that section:


   scope
      OPTIONAL.  Space separated list of scope values (as described in
      OAuth 2.0 Section=C2=A03.3 [RFC6749]) that the client can use w=
hen=20
      requesting access tokens.  As scope values are service-specific,=20
      the Authorization Server MAY define its own matching rules when
     =C2=A0determining if a scope value used during an authorization reques=
t
      is valid according to the scope values assigned during=20
      registration. Possible matching rules include wildcard patterns,
     =C2=A0regular expressions, or exactly matching the string. If omitted,=
=20
      an Authorization Server MAY register a Client with a default=20
      set of scopes.

Comments? Improvements?

=C2=A0-- Justin


On 04/14/2013 08:23 PM, Manger, James H wrote:
Presumably at app registration time any scope specification is r=
eally a constraint on the scope values that can be requested in an authoriz=
ation flow.

So ideally registration should accept rules for matching scopes, as opposed=
 to actual scope values.

You can try to use scope values as their own matching rules. That is fine f=
or a small set of "static" scopes. It starts to fail when there a=
re a large number of scopes, or scopes that can include parameters (resourc=
e paths? email addresses?). You can try to patch those failures by allowing=
 services to define service-specific special "wildcard" scope val=
ues that can only be used during registration (eg "read:*").

Alternatively, replace 'scope' in registration with 'scope_rege=
x' that holds a regular expression that all scope values in an authoriz=
ation flow must match.

--
James Manger
_______________________________________________
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

--001a11c1e89c39139e04da66dd7c-- From jricher@mitre.org Mon Apr 15 07:16:13 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C2F321F9440 for ; Mon, 15 Apr 2013 07:16:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[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 WlNWQoCKLJpN for ; Mon, 15 Apr 2013 07:16:12 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 4313521F93F3 for ; Mon, 15 Apr 2013 07:16:12 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D65E61F06D0; Mon, 15 Apr 2013 10:16:05 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id C83811F026C; Mon, 15 Apr 2013 10:16:05 -0400 (EDT) Received: from [10.146.15.29] (129.83.31.58) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.342.3; Mon, 15 Apr 2013 10:16:05 -0400 Message-ID: <516C0B9D.6000402@mitre.org> Date: Mon, 15 Apr 2013 10:15:57 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: Tim Bray References: <255B9BB34FB7D647A506DC292726F6E1150C74DADA@WSMSG3153V.srv.dir.telstra.com> <516C069F.9090308@mitre.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050302010001070500000600" X-Originating-IP: [129.83.31.58] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Registration: Scope Values X-BeenThere: oauth@ietf.org X-Mailman-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, 15 Apr 2013 14:16:13 -0000 --------------050302010001070500000600 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit Scopes aren't meant to be interoperable between services since they're necessarily API-specific. The only interoperable bit is that there's *some* place to put the values and that it's expressed as a bag of space-separated strings. How those strings get interpreted and enforced (which is really what's at stake here) is up to the AS and PR (or a higher-level protocol like UMA). -- Justin On 04/15/2013 10:13 AM, Tim Bray wrote: > > This, as written, has zero interoperability. I think this feature can > really only be made useful in the case where scopes are fixed strings. > > -T > > On Apr 15, 2013 6:54 AM, "Justin Richer" > wrote: > > You are correct that the idea behind the "scope" parameter at > registration is a constraint on authorization-time scopes that are > made available. It's both a means for the client to request a set > of valid scopes and for the server to provision (and echo back to > the client) a set of valid scopes. > > I *really* don't want to try to define a matching language for > scope expressions. For that to work, all servers would need to be > able to process the regular expressions for all clients, even if > the servers themselves only support simple-string scope values. > Any regular expression syntax we pick here is guaranteed to be > incompatible with something, and I think the complexity doesn't > buy much. Also, I think you suddenly have a potential security > issue if you have a bad regex in place on either end. > > As it stands today, the server can interpret the incoming > registration scopes and enforce them however it wants to. The real > trick comes not from assigning the values to a particular client > but to enforcing them, and I think that's always going to be > service-specific. We're just not as clear on that as we could be. > > After looking over everyone's comments so far, I'd like to propose > the following text for that section: > > > scope > OPTIONAL. Space separated list of scope values (as described in > OAuth 2.0Section 3.3 [RFC6749] ) that the client can use when > requesting access tokens. As scope values are service-specific, > the Authorization Server MAY define its own matching rules when > determining if a scope value used during an authorization request > is valid according to the scope values assigned during > registration. Possible matching rules include wildcard patterns, > regular expressions, or exactly matching the string. If omitted, > an Authorization Server MAY register a Client with a default > set of scopes. > > > Comments? Improvements? > > -- Justin > > > On 04/14/2013 08:23 PM, Manger, James H wrote: >> Presumably at app registration time any scope specification is really a constraint on the scope values that can be requested in an authorization flow. >> >> So ideally registration should accept rules for matching scopes, as opposed to actual scope values. >> >> You can try to use scope values as their own matching rules. That is fine for a small set of "static" scopes. It starts to fail when there are a large number of scopes, or scopes that can include parameters (resource paths? email addresses?). You can try to patch those failures by allowing services to define service-specific special "wildcard" scope values that can only be used during registration (eg "read:*"). >> >> Alternatively, replace 'scope' in registration with 'scope_regex' that holds a regular expression that all scope values in an authorization flow must match. >> >> -- >> James Manger >> _______________________________________________ >> 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 > --------------050302010001070500000600 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit Scopes aren't meant to be interoperable between services since they're necessarily API-specific. The only interoperable bit is that there's *some* place to put the values and that it's expressed as a bag of space-separated strings. How those strings get interpreted and enforced (which is really what's at stake here) is up to the AS and PR (or a higher-level protocol like UMA).

 -- Justin

On 04/15/2013 10:13 AM, Tim Bray wrote:

This, as written, has zero interoperability.  I think this feature can really only be made useful in the case where scopes are fixed strings.

-T

On Apr 15, 2013 6:54 AM, "Justin Richer" <jricher@mitre.org> wrote:
You are correct that the idea behind the "scope" parameter at registration is a constraint on authorization-time scopes that are made available. It's both a means for the client to request a set of valid scopes and for the server to provision (and echo back to the client) a set of valid scopes.

I *really* don't want to try to define a matching language for scope expressions. For that to work, all servers would need to be able to process the regular expressions for all clients, even if the servers themselves only support simple-string scope values. Any regular expression syntax we pick here is guaranteed to be incompatible with something, and I think the complexity doesn't buy much. Also, I think you suddenly have a potential security issue if you have a bad regex in place on either end.

As it stands today, the server can interpret the incoming registration scopes and enforce them however it wants to. The real trick comes not from assigning the values to a particular client but to enforcing them, and I think that's always going to be service-specific. We're just not as clear on that as we could be.

After looking over everyone's comments so far, I'd like to propose the following text for that section:


   scope
      OPTIONAL.  Space separated list of scope values (as described in
      OAuth 2.0 Section 3.3 [RFC6749]) that the client can use when 
      requesting access tokens.  As scope values are service-specific, 
      the Authorization Server MAY define its own matching rules when
      determining if a scope value used during an authorization request
      is valid according to the scope values assigned during 
      registration. Possible matching rules include wildcard patterns,
      regular expressions, or exactly matching the string. If omitted, 
      an Authorization Server MAY register a Client with a default 
      set of scopes.

Comments? Improvements?

 -- Justin


On 04/14/2013 08:23 PM, Manger, James H wrote:
Presumably at app registration time any scope specification is really a constraint on the scope values that can be requested in an authorization flow.

So ideally registration should accept rules for matching scopes, as opposed to actual scope values.

You can try to use scope values as their own matching rules. That is fine for a small set of "static" scopes. It starts to fail when there are a large number of scopes, or scopes that can include parameters (resource paths? email addresses?). You can try to patch those failures by allowing services to define service-specific special "wildcard" scope values that can only be used during registration (eg "read:*").

Alternatively, replace 'scope' in registration with 'scope_regex' that holds a regular expression that all scope values in an authorization flow must match.

--
James Manger
_______________________________________________
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


--------------050302010001070500000600-- From twbray@google.com Mon Apr 15 07:33:36 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FC5421F935B for ; Mon, 15 Apr 2013 07:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wd+vQsr8NxgU for ; Mon, 15 Apr 2013 07:33:35 -0700 (PDT) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 4965721F9339 for ; Mon, 15 Apr 2013 07:33:35 -0700 (PDT) Received: by mail-ie0-f176.google.com with SMTP id x14so1555042ief.35 for ; Mon, 15 Apr 2013 07:33:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=hfamFgpZbd5SeJ/Jn1utDMKdzXV+X+/NNN+cClYjZts=; b=d/gNs1CVlaR+4OttsvewY4693WbxZR3f7cWaypPgIh3F2WgpakjAX9sq2+moWqGRTu 7Y9qkKTtf/RRjJV+ikX8aiDrqVV6pRiDpxyjvBueW0iK037YKVo7AXzJ76KLdru5RxzT hfQcSMNVw//+1M+3JU1bR72OSs1MTR82jPeKb9HuElN+RUu5a9LBzh24VkGMV742ku1H cu1J9rdbl2LBha8sfQBxGwyya1YndLGVRqX2JalIox8HENBGFMl65g6WtjyOc38Rmk4j i5BHlbneHCQZptJ8nPNuXW2neYwoHqARULrGOU6otd+16XKswWpjSkYv8H+2tTs7vF7E n03Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=hfamFgpZbd5SeJ/Jn1utDMKdzXV+X+/NNN+cClYjZts=; b=Y6T1csWI3FC9f0RyKbtS9QIrW/ewGn8hQLhXJUEi1Rb8kfopyI/CdKy6aVWRayGKye Hcf5P2xYJ8Al2E2mx9YyL0us/M2VV9SAKBNkmWtofNMlUpsTyk5yR4tIgi1zpwJRASiF 85jffY7wXUHTVxZnix0MwJgpWUACCLQswJtPx1b07FTMW5oMF1dg4bAKj/KIcUTaiI5V MHBmYBSiDQNgookHNy5bbU+HQ9FV83dtAETqjqbBQjdDkKmFerBoAl1BiMiRST4PikbV GajKk46yj09G9XzkGrd2MMfwdVv1Wc5wRKzuWfEgiTsKCpuclY16HRI0EXkOBv0DWR+X cC0w== X-Received: by 10.50.195.134 with SMTP id ie6mr5335818igc.6.1366036414600; Mon, 15 Apr 2013 07:33:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.31.35 with HTTP; Mon, 15 Apr 2013 07:33:03 -0700 (PDT) In-Reply-To: <516C0B9D.6000402@mitre.org> References: <255B9BB34FB7D647A506DC292726F6E1150C74DADA@WSMSG3153V.srv.dir.telstra.com> <516C069F.9090308@mitre.org> <516C0B9D.6000402@mitre.org> From: Tim Bray Date: Mon, 15 Apr 2013 07:33:03 -0700 Message-ID: To: Justin Richer Content-Type: multipart/alternative; boundary=14dae9340b453e32a304da672301 X-Gm-Message-State: ALoCoQnL9lvP+aS9kGvKlLHO3dQeMgkSFsSsk21U2MARNRNXVCrNrQPqlxu9cL3T/Micq9k8AtdlH6SyeO79Az+T8s/YYixLnRgNoGTYRwUDVqZzovIsBIo4QPZYC8Gyx7gCghQTzMa6qE59r1E4xTc5qqeLZhqGsN0BUBFN2fCcYR3jy6+RgFWDUh3tmyZUbZ3DBKkd7nw/ Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Registration: Scope Values X-BeenThere: oauth@ietf.org X-Mailman-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, 15 Apr 2013 14:33:36 -0000 --14dae9340b453e32a304da672301 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable No, I mean it=E2=80=99s not interoperable at the software-developer level. = I can=E2=80=99t register scopes at authorization time with any predictable effect that I can write code to support, either client or server side, without out-of-line non-interoperable knowledge about the behavior of the server. I guess I=E2=80=99m just not used to OAuth=E2=80=99s culture of having no e= xpectation that things will be specified tightly enough that I can write code to implement as specified. -T On Mon, Apr 15, 2013 at 7:15 AM, Justin Richer wrote: > Scopes aren't meant to be interoperable between services since they're > necessarily API-specific. The only interoperable bit is that there's *som= e* > place to put the values and that it's expressed as a bag of space-separat= ed > strings. How those strings get interpreted and enforced (which is really > what's at stake here) is up to the AS and PR (or a higher-level protocol > like UMA). > > -- Justin > > > On 04/15/2013 10:13 AM, Tim Bray wrote: > > This, as written, has zero interoperability. I think this feature can > really only be made useful in the case where scopes are fixed strings. > > -T > On Apr 15, 2013 6:54 AM, "Justin Richer" wrote: > >> You are correct that the idea behind the "scope" parameter at >> registration is a constraint on authorization-time scopes that are made >> available. It's both a means for the client to request a set of valid >> scopes and for the server to provision (and echo back to the client) a s= et >> of valid scopes. >> >> I *really* don't want to try to define a matching language for scope >> expressions. For that to work, all servers would need to be able to proc= ess >> the regular expressions for all clients, even if the servers themselves >> only support simple-string scope values. Any regular expression syntax w= e >> pick here is guaranteed to be incompatible with something, and I think t= he >> complexity doesn't buy much. Also, I think you suddenly have a potential >> security issue if you have a bad regex in place on either end. >> >> As it stands today, the server can interpret the incoming registration >> scopes and enforce them however it wants to. The real trick comes not fr= om >> assigning the values to a particular client but to enforcing them, and I >> think that's always going to be service-specific. We're just not as clea= r >> on that as we could be. >> >> After looking over everyone's comments so far, I'd like to propose the >> following text for that section: >> >> >> scope >> OPTIONAL. Space separated list of scope values (as described in >> OAuth 2.0 Section 3.3 [RFC6749] ) that the client can use when >> requesting access tokens. As scope values are service-specific, >> the Authorization Server MAY define its own matching rules when >> determining if a scope value used during an authorization request >> is valid according to the scope values assigned during >> registration. Possible matching rules include wildcard patterns, >> regular expressions, or exactly matching the string. If omitted, >> an Authorization Server MAY register a Client with a default >> set of scopes. >> >> >> Comments? Improvements? >> >> -- Justin >> >> >> On 04/14/2013 08:23 PM, Manger, James H wrote: >> >> Presumably at app registration time any scope specification is really a = constraint on the scope values that can be requested in an authorization fl= ow. >> >> So ideally registration should accept rules for matching scopes, as oppo= sed to actual scope values. >> >> You can try to use scope values as their own matching rules. That is fin= e for a small set of "static" scopes. It starts to fail when there are a la= rge number of scopes, or scopes that can include parameters (resource paths= ? email addresses?). You can try to patch those failures by allowing servic= es to define service-specific special "wildcard" scope values that can only= be used during registration (eg "read:*"). >> >> Alternatively, replace 'scope' in registration with 'scope_regex' that h= olds a regular expression that all scope values in an authorization flow mu= st match. >> >> -- >> James Manger >> _______________________________________________ >> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oa= uth >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > --14dae9340b453e32a304da672301 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
No, I mean it=E2=80=99s not interoperable at the software-= developer level. =C2=A0I can=E2=80=99t register scopes at authorization tim= e with any predictable effect that I can write code to support, either clie= nt or server side, without out-of-line non-interoperable knowledge about th= e behavior of the server. =C2=A0

I guess I=E2=80=99m just not used to OAuth=E2=80=99s c= ulture of having no expectation that things will be specified tightly enoug= h that I can write code to implement as specified. =C2=A0-T


On Mon, Apr 15, 2013 at 7:15 AM, Justin = Richer <jricher@mitre.org> wrote:
=20 =20 =20
Scopes aren't meant to be interoperable between services since they're necessarily API-specific. The only interoperable bit is tha= t there's *some* place to put the values and that it's expressed = as a bag of space-separated strings. How those strings get interpreted and enforced (which is really what's at stake here) is up to the AS and PR (or a higher-level protocol like UMA).

=C2=A0-- Justin


On 04/15/2013 10:13 AM, Tim Bray wrote:
=20

This, as written, has zero interoperability.=C2=A0 I t= hink this feature can really only be made useful in the case where scopes are fixed strings.

-T

On Apr 15, 2013 6:54 AM, "Justin Rich= er" <jricher@= mitre.org> wrote:
You are correct that the idea behind the "scope" parameter at registration= is a constraint on authorization-time scopes that are made available. It's both a means for the client to request a se= t of valid scopes and for the server to provision (and echo back to the client) a set of valid scopes.

I *really* don't want to try to define a matching language for scope expressions. For that to work, all servers would need to be able to process the regular expressions for all clients, even if the servers themselves only support simple-string scope values. Any regular expression syntax we pick here is guaranteed to be incompatible with something, and I think the complexity doesn't buy much. Also, I think you suddenly have a potential security issue if you have a bad regex in place on either end.

As it stands today, the server can interpret the incoming registration scopes and enforce them however it wants to. The real trick comes not from assigning the values to a particular client but to enforcing them, and I think that's always going to be service-specific. We're just not as clea= r on that as we could be.

After looking over everyone's comments so far, I'd like= to propose the following text for that section:


   scope
      OPTIONAL.  Space separated list of scope values (as described in
      OAuth 2.0 Section=C2=A03.3 [RFC6749]) that the client can use w=
hen=20
      requesting access tokens.  As scope values are service-specific,=20
      the Authorization Server MAY define its own matching rules when
     =C2=A0determining if a scope value used during an authorization reques=
t
      is valid according to the scope values assigned during=20
      registration. Possible matching rules include wildcard patterns,
     =C2=A0regular expressions, or exactly matching the string. If omitted,=
=20
      an Authorization Server MAY register a Client with a default=20
      set of scopes.

Comments? Improvements?

=C2=A0-- Justin


On 04/14/2013 08:23 PM, Manger, James H wrote:
Presumably at app registration time any scope specificat=
ion is really a constraint on the scope values that can be requested in an =
authorization flow.

So ideally registration should accept rules for matching scopes, as opposed=
 to actual scope values.

You can try to use scope values as their own matching rules. That is fine f=
or a small set of "static" scopes. It starts to fail when there a=
re a large number of scopes, or scopes that can include parameters (resourc=
e paths? email addresses?). You can try to patch those failures by allowing=
 services to define service-specific special "wildcard" scope val=
ues that can only be used during registration (eg "read:*").

Alternatively, replace 'scope' in registration with 'scope_rege=
x' that holds a regular expression that all scope values in an authoriz=
ation flow must match.

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


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



--14dae9340b453e32a304da672301-- From jricher@mitre.org Mon Apr 15 07:35:23 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B16421F93DD for ; Mon, 15 Apr 2013 07:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8zCJCC6jQuM for ; Mon, 15 Apr 2013 07:35:21 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 166A421F93B4 for ; Mon, 15 Apr 2013 07:35:21 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 953CD1F02E1; Mon, 15 Apr 2013 10:35:20 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 7F9771F029F; Mon, 15 Apr 2013 10:35:20 -0400 (EDT) Received: from [10.146.15.29] (129.83.31.58) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.2.342.3; Mon, 15 Apr 2013 10:35:20 -0400 Message-ID: <516C101F.2090706@mitre.org> Date: Mon, 15 Apr 2013 10:35:11 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: Tim Bray References: <255B9BB34FB7D647A506DC292726F6E1150C74DADA@WSMSG3153V.srv.dir.telstra.com> <516C069F.9090308@mitre.org> <516C0B9D.6000402@mitre.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020003000107040906080706" X-Originating-IP: [129.83.31.58] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Registration: Scope Values X-BeenThere: oauth@ietf.org X-Mailman-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, 15 Apr 2013 14:35:23 -0000 --------------020003000107040906080706 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit What would you suggest for wording here, then? Keeping in mind that we cannot (and don't want to) prohibit expression-based scopes. -- Justin On 04/15/2013 10:33 AM, Tim Bray wrote: > No, I mean it’s not interoperable at the software-developer level. I > can’t register scopes at authorization time with any predictable > effect that I can write code to support, either client or server side, > without out-of-line non-interoperable knowledge about the behavior of > the server. > > I guess I’m just not used to OAuth’s culture of having no expectation > that things will be specified tightly enough that I can write code to > implement as specified. -T > > > On Mon, Apr 15, 2013 at 7:15 AM, Justin Richer > wrote: > > Scopes aren't meant to be interoperable between services since > they're necessarily API-specific. The only interoperable bit is > that there's *some* place to put the values and that it's > expressed as a bag of space-separated strings. How those strings > get interpreted and enforced (which is really what's at stake > here) is up to the AS and PR (or a higher-level protocol like UMA). > > -- Justin > > > On 04/15/2013 10:13 AM, Tim Bray wrote: >> >> This, as written, has zero interoperability. I think this >> feature can really only be made useful in the case where scopes >> are fixed strings. >> >> -T >> >> On Apr 15, 2013 6:54 AM, "Justin Richer" > > wrote: >> >> You are correct that the idea behind the "scope" parameter at >> registration is a constraint on authorization-time scopes >> that are made available. It's both a means for the client to >> request a set of valid scopes and for the server to provision >> (and echo back to the client) a set of valid scopes. >> >> I *really* don't want to try to define a matching language >> for scope expressions. For that to work, all servers would >> need to be able to process the regular expressions for all >> clients, even if the servers themselves only support >> simple-string scope values. Any regular expression syntax we >> pick here is guaranteed to be incompatible with something, >> and I think the complexity doesn't buy much. Also, I think >> you suddenly have a potential security issue if you have a >> bad regex in place on either end. >> >> As it stands today, the server can interpret the incoming >> registration scopes and enforce them however it wants to. The >> real trick comes not from assigning the values to a >> particular client but to enforcing them, and I think that's >> always going to be service-specific. We're just not as clear >> on that as we could be. >> >> After looking over everyone's comments so far, I'd like to >> propose the following text for that section: >> >> >> scope >> OPTIONAL. Space separated list of scope values (as described in >> OAuth 2.0Section 3.3 [RFC6749] ) that the client can use when >> requesting access tokens. As scope values are service-specific, >> the Authorization Server MAY define its own matching rules when >> determining if a scope value used during an authorization request >> is valid according to the scope values assigned during >> registration. Possible matching rules include wildcard patterns, >> regular expressions, or exactly matching the string. If omitted, >> an Authorization Server MAY register a Client with a default >> set of scopes. >> >> >> Comments? Improvements? >> >> -- Justin >> >> >> On 04/14/2013 08:23 PM, Manger, James H wrote: >>> Presumably at app registration time any scope specification is really a constraint on the scope values that can be requested in an authorization flow. >>> >>> So ideally registration should accept rules for matching scopes, as opposed to actual scope values. >>> >>> You can try to use scope values as their own matching rules. That is fine for a small set of "static" scopes. It starts to fail when there are a large number of scopes, or scopes that can include parameters (resource paths? email addresses?). You can try to patch those failures by allowing services to define service-specific special "wildcard" scope values that can only be used during registration (eg "read:*"). >>> >>> Alternatively, replace 'scope' in registration with 'scope_regex' that holds a regular expression that all scope values in an authorization flow must match. >>> >>> -- >>> James Manger >>> _______________________________________________ >>> 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 >> > > --------------020003000107040906080706 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit What would you suggest for wording here, then? Keeping in mind that we cannot (and don't want to) prohibit expression-based scopes.

 -- Justin

On 04/15/2013 10:33 AM, Tim Bray wrote:
No, I mean it’s not interoperable at the software-developer level.  I can’t register scopes at authorization time with any predictable effect that I can write code to support, either client or server side, without out-of-line non-interoperable knowledge about the behavior of the server.  

I guess I’m just not used to OAuth’s culture of having no expectation that things will be specified tightly enough that I can write code to implement as specified.  -T


On Mon, Apr 15, 2013 at 7:15 AM, Justin Richer <jricher@mitre.org> wrote:
Scopes aren't meant to be interoperable between services since they're necessarily API-specific. The only interoperable bit is that there's *some* place to put the values and that it's expressed as a bag of space-separated strings. How those strings get interpreted and enforced (which is really what's at stake here) is up to the AS and PR (or a higher-level protocol like UMA).

 -- Justin


On 04/15/2013 10:13 AM, Tim Bray wrote:

This, as written, has zero interoperability.  I think this feature can really only be made useful in the case where scopes are fixed strings.

-T

On Apr 15, 2013 6:54 AM, "Justin Richer" <jricher@mitre.org> wrote:
You are correct that the idea behind the "scope" parameter at registration is a constraint on authorization-time scopes that are made available. It's both a means for the client to request a set of valid scopes and for the server to provision (and echo back to the client) a set of valid scopes.

I *really* don't want to try to define a matching language for scope expressions. For that to work, all servers would need to be able to process the regular expressions for all clients, even if the servers themselves only support simple-string scope values. Any regular expression syntax we pick here is guaranteed to be incompatible with something, and I think the complexity doesn't buy much. Also, I think you suddenly have a potential security issue if you have a bad regex in place on either end.

As it stands today, the server can interpret the incoming registration scopes and enforce them however it wants to. The real trick comes not from assigning the values to a particular client but to enforcing them, and I think that's always going to be service-specific. We're just not as clear on that as we could be.

After looking over everyone's comments so far, I'd like to propose the following text for that section:


   scope
      OPTIONAL.  Space separated list of scope values (as described in
      OAuth 2.0 Section 3.3 [RFC6749]) that the client can use when 
      requesting access tokens.  As scope values are service-specific, 
      the Authorization Server MAY define its own matching rules when
      determining if a scope value used during an authorization request
      is valid according to the scope values assigned during 
      registration. Possible matching rules include wildcard patterns,
      regular expressions, or exactly matching the string. If omitted, 
      an Authorization Server MAY register a Client with a default 
      set of scopes.

Comments? Improvements?

 -- Justin


On 04/14/2013 08:23 PM, Manger, James H wrote:
Presumably at app registration time any scope specification is really a constraint on the scope values that can be requested in an authorization flow.

So ideally registration should accept rules for matching scopes, as opposed to actual scope values.

You can try to use scope values as their own matching rules. That is fine for a small set of "static" scopes. It starts to fail when there are a large number of scopes, or scopes that can include parameters (resource paths? email addresses?). You can try to patch those failures by allowing services to define service-specific special "wildcard" scope values that can only be used during registration (eg "read:*").

Alternatively, replace 'scope' in registration with 'scope_regex' that holds a regular expression that all scope values in an authorization flow must match.

--
James Manger
_______________________________________________
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




--------------020003000107040906080706-- From jricher@mitre.org Mon Apr 15 08:05:03 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF6521F93D3 for ; Mon, 15 Apr 2013 08:05:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cev6R--z9ocZ for ; Mon, 15 Apr 2013 08:05:02 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id C753021F93CC for ; Mon, 15 Apr 2013 08:05:01 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 593171F03AF; Mon, 15 Apr 2013 11:05:01 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 3E94C1F0322; Mon, 15 Apr 2013 11:05:01 -0400 (EDT) Received: from [10.146.15.29] (129.83.31.58) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.342.3; Mon, 15 Apr 2013 11:05:01 -0400 Message-ID: <516C1714.8070503@mitre.org> Date: Mon, 15 Apr 2013 11:04:52 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: Tim Bray , "oauth@ietf.org" References: <255B9BB34FB7D647A506DC292726F6E1150C74DADA@WSMSG3153V.srv.dir.telstra.com> <516C069F.9090308@mitre.org> <516C0B9D.6000402@mitre.org> <516C101F.2090706@mitre.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050200050208070202010705" X-Originating-IP: [129.83.31.58] Subject: Re: [OAUTH-WG] Registration: Scope Values X-BeenThere: oauth@ietf.org X-Mailman-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, 15 Apr 2013 15:05:03 -0000 --------------050200050208070202010705 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit On 04/15/2013 10:52 AM, Tim Bray wrote: > I’d use the existing wording; it’s perfectly clear. Failing that, if > there’s strong demand for registration of structured scopes, bless the > use of regexes, either PCREs or some careful subset. Thanks for the feedback -- Of these two choices, I'd rather leave it as-is. > > However, I’d subtract the sentence “If omitted, an Authorization > Server MAY register a Client with a default set of scopes.” It adds > no value; if the client doesn’t declare scopes, the client doesn’t > declare scopes, that’s all. -T Remember, all of these fields aren't just for the client *request*, they're also for the server's *response* to either a POST, PUT, or GET request. (I didn't realize it, but perhaps the wording as stated right now doesn't make that clear -- I need to fix that.) The value that it adds is if the client doesn't ask for any particular scopes, the server can still assign it scopes and the client can do something smart with that. Dumb clients are allowed to ignore it if it doesn't mean anything to them. This is how our server implementation actually works right now. If the client doesn't ask for anything specific at registration, the server hands it a bag of "default" scopes. Same thing happens at auth time -- if the client doesn't ask for any particular scopes, the server hands it all of its registered scopes as a default. Granted, on our server, scopes are just simple strings right now, so they get compared at the auth endpoint with an exact string-match metric and set-based logic. -- Justin > > > On Mon, Apr 15, 2013 at 7:35 AM, Justin Richer > wrote: > > What would you suggest for wording here, then? Keeping in mind > that we cannot (and don't want to) prohibit expression-based scopes. > > -- Justin > > > On 04/15/2013 10:33 AM, Tim Bray wrote: >> No, I mean it’s not interoperable at the software-developer >> level. I can’t register scopes at authorization time with any >> predictable effect that I can write code to support, either >> client or server side, without out-of-line non-interoperable >> knowledge about the behavior of the server. >> >> I guess I’m just not used to OAuth’s culture of having no >> expectation that things will be specified tightly enough that I >> can write code to implement as specified. -T >> >> >> On Mon, Apr 15, 2013 at 7:15 AM, Justin Richer > > wrote: >> >> Scopes aren't meant to be interoperable between services >> since they're necessarily API-specific. The only >> interoperable bit is that there's *some* place to put the >> values and that it's expressed as a bag of space-separated >> strings. How those strings get interpreted and enforced >> (which is really what's at stake here) is up to the AS and PR >> (or a higher-level protocol like UMA). >> >> -- Justin >> >> >> On 04/15/2013 10:13 AM, Tim Bray wrote: >>> >>> This, as written, has zero interoperability. I think this >>> feature can really only be made useful in the case where >>> scopes are fixed strings. >>> >>> -T >>> >>> On Apr 15, 2013 6:54 AM, "Justin Richer" >> > wrote: >>> >>> You are correct that the idea behind the "scope" >>> parameter at registration is a constraint on >>> authorization-time scopes that are made available. It's >>> both a means for the client to request a set of valid >>> scopes and for the server to provision (and echo back to >>> the client) a set of valid scopes. >>> >>> I *really* don't want to try to define a matching >>> language for scope expressions. For that to work, all >>> servers would need to be able to process the regular >>> expressions for all clients, even if the servers >>> themselves only support simple-string scope values. Any >>> regular expression syntax we pick here is guaranteed to >>> be incompatible with something, and I think the >>> complexity doesn't buy much. Also, I think you suddenly >>> have a potential security issue if you have a bad regex >>> in place on either end. >>> >>> As it stands today, the server can interpret the >>> incoming registration scopes and enforce them however it >>> wants to. The real trick comes not from assigning the >>> values to a particular client but to enforcing them, and >>> I think that's always going to be service-specific. >>> We're just not as clear on that as we could be. >>> >>> After looking over everyone's comments so far, I'd like >>> to propose the following text for that section: >>> >>> >>> scope >>> OPTIONAL. Space separated list of scope values (as described in >>> OAuth 2.0Section 3.3 [RFC6749] ) that the client can use when >>> requesting access tokens. As scope values are service-specific, >>> the Authorization Server MAY define its own matching rules when >>> determining if a scope value used during an authorization request >>> is valid according to the scope values assigned during >>> registration. Possible matching rules include wildcard patterns, >>> regular expressions, or exactly matching the string. If omitted, >>> an Authorization Server MAY register a Client with a default >>> set of scopes. >>> >>> >>> Comments? Improvements? >>> >>> -- Justin >>> >>> >>> On 04/14/2013 08:23 PM, Manger, James H wrote: >>>> Presumably at app registration time any scope specification is really a constraint on the scope values that can be requested in an authorization flow. >>>> >>>> So ideally registration should accept rules for matching scopes, as opposed to actual scope values. >>>> >>>> You can try to use scope values as their own matching rules. That is fine for a small set of "static" scopes. It starts to fail when there are a large number of scopes, or scopes that can include parameters (resource paths? email addresses?). You can try to patch those failures by allowing services to define service-specific special "wildcard" scope values that can only be used during registration (eg "read:*"). >>>> >>>> Alternatively, replace 'scope' in registration with 'scope_regex' that holds a regular expression that all scope values in an authorization flow must match. >>>> >>>> -- >>>> James Manger >>>> _______________________________________________ >>>> 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 >>> >> >> > > --------------050200050208070202010705 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit On 04/15/2013 10:52 AM, Tim Bray wrote:
I’d use the existing wording; it’s perfectly clear.  Failing that, if there’s strong demand for registration of structured scopes, bless the use of regexes, either PCREs or some careful subset.

Thanks for the feedback -- Of these two choices, I'd rather leave it as-is.


However, I’d subtract the sentence “If omitted, an Authorization Server MAY register a Client with a default set of  scopes.”  It adds no value; if the client doesn’t declare scopes, the client doesn’t declare scopes, that’s all.  -T

Remember, all of these fields aren't just for the client *request*, they're also for the server's *response* to either a POST, PUT, or GET request. (I didn't realize it, but perhaps the wording as stated right now doesn't make that clear -- I need to fix that.) The value that it adds is if the client doesn't ask for any particular scopes, the server can still assign it scopes and the client can do something smart with that. Dumb clients are allowed to ignore it if it doesn't mean anything to them.

This is how our server implementation actually works right now. If the client doesn't ask for anything specific at registration, the server hands it a bag of "default" scopes. Same thing happens at auth time -- if the client doesn't ask for any particular scopes, the server hands it all of its registered scopes as a default. Granted, on our server, scopes are just simple strings right now, so they get compared at the auth endpoint with an exact string-match metric and set-based logic.

 -- Justin



On Mon, Apr 15, 2013 at 7:35 AM, Justin Richer <jricher@mitre.org> wrote:
What would you suggest for wording here, then? Keeping in mind that we cannot (and don't want to) prohibit expression-based scopes.

 -- Justin


On 04/15/2013 10:33 AM, Tim Bray wrote:
No, I mean it’s not interoperable at the software-developer level.  I can’t register scopes at authorization time with any predictable effect that I can write code to support, either client or server side, without out-of-line non-interoperable knowledge about the behavior of the server.  

I guess I’m just not used to OAuth’s culture of having no expectation that things will be specified tightly enough that I can write code to implement as specified.  -T


On Mon, Apr 15, 2013 at 7:15 AM, Justin Richer <jricher@mitre.org> wrote:
Scopes aren't meant to be interoperable between services since they're necessarily API-specific. The only interoperable bit is that there's *some* place to put the values and that it's expressed as a bag of space-separated strings. How those strings get interpreted and enforced (which is really what's at stake here) is up to the AS and PR (or a higher-level protocol like UMA).

 -- Justin


On 04/15/2013 10:13 AM, Tim Bray wrote:

This, as written, has zero interoperability.  I think this feature can really only be made useful in the case where scopes are fixed strings.

-T

On Apr 15, 2013 6:54 AM, "Justin Richer" <jricher@mitre.org> wrote:
You are correct that the idea behind the "scope" parameter at registration is a constraint on authorization-time scopes that are made available. It's both a means for the client to request a set of valid scopes and for the server to provision (and echo back to the client) a set of valid scopes.

I *really* don't want to try to define a matching language for scope expressions. For that to work, all servers would need to be able to process the regular expressions for all clients, even if the servers themselves only support simple-string scope values. Any regular expression syntax we pick here is guaranteed to be incompatible with something, and I think the complexity doesn't buy much. Also, I think you suddenly have a potential security issue if you have a bad regex in place on either end.

As it stands today, the server can interpret the incoming registration scopes and enforce them however it wants to. The real trick comes not from assigning the values to a particular client but to enforcing them, and I think that's always going to be service-specific. We're just not as clear on that as we could be.

After looking over everyone's comments so far, I'd like to propose the following text for that section:


   scope
      OPTIONAL.  Space separated list of scope values (as described in
      OAuth 2.0 Section 3.3 [RFC6749]) that the client can use when 
      requesting access tokens.  As scope values are service-specific, 
      the Authorization Server MAY define its own matching rules when
      determining if a scope value used during an authorization request
      is valid according to the scope values assigned during 
      registration. Possible matching rules include wildcard patterns,
      regular expressions, or exactly matching the string. If omitted, 
      an Authorization Server MAY register a Client with a default 
      set of scopes.

Comments? Improvements?

 -- Justin


On 04/14/2013 08:23 PM, Manger, James H wrote:
Presumably at app registration time any scope specification is really a constraint on the scope values that can be requested in an authorization flow.

So ideally registration should accept rules for matching scopes, as opposed to actual scope values.

You can try to use scope values as their own matching rules. That is fine for a small set of "static" scopes. It starts to fail when there are a large number of scopes, or scopes that can include parameters (resource paths? email addresses?). You can try to patch those failures by allowing services to define service-specific special "wildcard" scope values that can only be used during registration (eg "read:*").

Alternatively, replace 'scope' in registration with 'scope_regex' that holds a regular expression that all scope values in an authorization flow must match.

--
James Manger
_______________________________________________
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






--------------050200050208070202010705-- From Michael.Jones@microsoft.com Mon Apr 15 09:44:44 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A26021F92C1 for ; Mon, 15 Apr 2013 09:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 YmdjU0ciftRp for ; Mon, 15 Apr 2013 09:44:42 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0240.outbound.protection.outlook.com [207.46.163.240]) by ietfa.amsl.com (Postfix) with ESMTP id 914E821F8585 for ; Mon, 15 Apr 2013 09:44:42 -0700 (PDT) Received: from BN1AFFO11FD013.protection.gbl (10.58.52.202) by BN1BFFO11HUB024.protection.gbl (10.58.53.134) with Microsoft SMTP Server (TLS) id 15.0.664.0; Mon, 15 Apr 2013 16:44:40 +0000 Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.37) by BN1AFFO11FD013.mail.protection.outlook.com (10.58.52.73) with Microsoft SMTP Server (TLS) id 15.0.675.0 via Frontend Transport; Mon, 15 Apr 2013 16:44:40 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.224]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0318.003; Mon, 15 Apr 2013 16:44:16 +0000 From: Mike Jones To: Justin Richer , Tim Bray , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Registration: Scope Values Thread-Index: AQHOOeqUFpSaFgMeSEqfp5thtJ9Xm5jXeeUg Date: Mon, 15 Apr 2013 16:44:15 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394367641A87@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <255B9BB34FB7D647A506DC292726F6E1150C74DADA@WSMSG3153V.srv.dir.telstra.com> <516C069F.9090308@mitre.org> <516C0B9D.6000402@mitre.org> <516C101F.2090706@mitre.org> <516C1714.8070503@mitre.org> In-Reply-To: <516C1714.8070503@mitre.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394367641A87TK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(189002)(74662001)(80022001)(69226001)(33656001)(31966008)(18277545001)(47976001)(74502001)(50986001)(4396001)(81542001)(20776003)(564824004)(55846006)(47446002)(66066001)(54356001)(18276755001)(63696002)(512874001)(51856001)(47736001)(56776001)(81342001)(16406001)(53806001)(56816002)(59766001)(76482001)(54316002)(79102001)(46102001)(77982001)(49866001)(71186001)(65816001); DIR:OUT; SFP:; SCL:1; SRVR:BN1BFFO11HUB024; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0817737FD1 Subject: Re: [OAUTH-WG] Registration: Scope Values X-BeenThere: oauth@ietf.org X-Mailman-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, 15 Apr 2013 16:44:44 -0000 --_000_4E1F6AAD24975D4BA5B168042967394367641A87TK5EX14MBXC283r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayB0aGF0IHRoZSBleGlzdGluZyB3b3JkaW5nIGlzIHN1cGVyaW9yIHRvIHRoZSBwcm9w b3NlZCBjaGFuZ2VkIHdvcmRpbmcuICBUaGUgZXhpc3Rpbmcgd29yZGluZyBpczoNCg0KICAgc2Nv cGUNCiAgICAgIE9QVElPTkFMLiAgU3BhY2Ugc2VwYXJhdGVkIGxpc3Qgb2Ygc2NvcGUgdmFsdWVz IChhcyBkZXNjcmliZWQgaW4NCiAgICAgIE9BdXRoIDIuMCBTZWN0aW9uIDMuMyBbUkZDNjc0OV08 aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjc0OSNzZWN0aW9uLTMuMz4pIHRoYXQgdGhl IGNsaWVudCBpcyBkZWNsYXJpbmcgdGhhdA0KICAgICAgaXQgbWF5IHVzZSB3aGVuIHJlcXVlc3Rp bmcgYWNjZXNzIHRva2Vucy4gIElmIG9taXR0ZWQsIGFuDQogICAgICBBdXRob3JpemF0aW9uIFNl cnZlciBNQVkgcmVnaXN0ZXIgYSBDbGllbnQgd2l0aCBhIGRlZmF1bHQgc2V0IG9mDQogICAgICBz Y29wZXMuDQoNCkZvciBpbnN0YW5jZSwgdGhlIGN1cnJlbnQg4oCcY2xpZW50IGlzIGRlY2xhcmlu Z+KAnSB3b3JkaW5nIHdpbGwgYWx3YXlzIGJlIGNvcnJlY3QsIHdoZXJlYXMgYXMgdGhlIGNoYW5n ZSB0byDigJxjbGllbnQgY2FuIHVzZeKAnSB3b3JkaW5nIGltcGxpZXMgYSByZXN0cmljdGlvbiBv biBjbGllbnQgYmVoYXZpb3IgdGhhdCBpcyBub3QgYWx3YXlzIGFwcGxpY2FibGUuICBUaGUg4oCc Y2xpZW50IGlzIGRlY2xhcmluZ+KAnSB3b3JkaW5nIHdhcyBzcGVjaWZpYyBhbmQgcHVycG9zZWZ1 bGx5IGNob3NlbiwgYW5kIEkgdGhpbmsgc2hvdWxkIGJlIHJldGFpbmVkLiAgSW4gcGFydGljdWxh ciwgd2UgY2Fu4oCZdCBkbyBhbnl0aGluZyB0aGF0IGltcGxpZXMgdGhhdCBvbmx5IHRoZSByZWdp c3RlcmVkIHNjb3BlcyB2YWx1ZXMgY2FuIGJlIHVzZWQuICBBdCB0aGUgT0F1dGggc3BlYyBsZXZl bCwgdGhpcyBpcyBhIGhpbnQgYXMgdG8gcG9zc2libGUgZnV0dXJlIGNsaWVudCBiZWhhdmlvciDi gJMgbm90IGEgcmVzdHJpY3Rpb24gb24gZnV0dXJlIGNsaWVudCBiZWhhdmlvci4NCg0KQWxzbywg Zm9yIHRoZSByZWFzb25zIHRoYXQgVGltIHN0YXRlZCwgSeKAmW0gc3Ryb25nbHkgYWdhaW5zdCBh bnkg4oCcbWF0Y2hpbmfigJ0gb3Ig4oCccmVnZXjigJ0gbGFuZ3VhZ2UgaW4gdGhlIHNwZWMgcGVy dGFpbmluZyB0byBzY29wZXMg4oCTIGFzIGl04oCZcyBub3QgYWN0aW9uYWJsZS4NCg0KU28gSeKA mWQgcHJvcG9zZSB0aGF0IHdlIGxlYXZlIHRoZSBleGlzdGluZyBzY29wZSB3b3JkaW5nIGluIHBs YWNlLiAgQWx0ZXJuYXRpdmVseSwgSeKAmWQgYWxzbyBiZSBmaW5lIHdpdGggZGVsZXRpbmcgdGhp cyBmZWF0dXJlIGVudGlyZWx5LCBhcyBJIGRvbuKAmXQgdGhpbmsgaXTigJlzIHVzZWZ1bCBpbiB0 aGUgZ2VuZXJhbCBjYXNlLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IG9hdXRoLWJvdW5jZXNAaWV0 Zi5vcmcgW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSnVzdGlu IFJpY2hlcg0KU2VudDogTW9uZGF5LCBBcHJpbCAxNSwgMjAxMyA4OjA1IEFNDQpUbzogVGltIEJy YXk7IG9hdXRoQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBSZWdpc3RyYXRpb246 IFNjb3BlIFZhbHVlcw0KDQpPbiAwNC8xNS8yMDEzIDEwOjUyIEFNLCBUaW0gQnJheSB3cm90ZToN Cg0KSeKAmWQgdXNlIHRoZSBleGlzdGluZyB3b3JkaW5nOyBpdOKAmXMgcGVyZmVjdGx5IGNsZWFy LiAgRmFpbGluZyB0aGF0LCBpZiB0aGVyZeKAmXMgc3Ryb25nIGRlbWFuZCBmb3IgcmVnaXN0cmF0 aW9uIG9mIHN0cnVjdHVyZWQgc2NvcGVzLCBibGVzcyB0aGUgdXNlIG9mIHJlZ2V4ZXMsIGVpdGhl ciBQQ1JFcyBvciBzb21lIGNhcmVmdWwgc3Vic2V0Lg0KDQpUaGFua3MgZm9yIHRoZSBmZWVkYmFj ayAtLSBPZiB0aGVzZSB0d28gY2hvaWNlcywgSSdkIHJhdGhlciBsZWF2ZSBpdCBhcy1pcy4NCg0K DQoNCkhvd2V2ZXIsIEnigJlkIHN1YnRyYWN0IHRoZSBzZW50ZW5jZSDigJxJZiBvbWl0dGVkLCBh biBBdXRob3JpemF0aW9uIFNlcnZlciBNQVkgcmVnaXN0ZXIgYSBDbGllbnQgd2l0aCBhIGRlZmF1 bHQgc2V0IG9mICBzY29wZXMu4oCdICBJdCBhZGRzIG5vIHZhbHVlOyBpZiB0aGUgY2xpZW50IGRv ZXNu4oCZdCBkZWNsYXJlIHNjb3BlcywgdGhlIGNsaWVudCBkb2VzbuKAmXQgZGVjbGFyZSBzY29w ZXMsIHRoYXTigJlzIGFsbC4gIC1UDQoNClJlbWVtYmVyLCBhbGwgb2YgdGhlc2UgZmllbGRzIGFy ZW4ndCBqdXN0IGZvciB0aGUgY2xpZW50ICpyZXF1ZXN0KiwgdGhleSdyZSBhbHNvIGZvciB0aGUg c2VydmVyJ3MgKnJlc3BvbnNlKiB0byBlaXRoZXIgYSBQT1NULCBQVVQsIG9yIEdFVCByZXF1ZXN0 LiAoSSBkaWRuJ3QgcmVhbGl6ZSBpdCwgYnV0IHBlcmhhcHMgdGhlIHdvcmRpbmcgYXMgc3RhdGVk IHJpZ2h0IG5vdyBkb2Vzbid0IG1ha2UgdGhhdCBjbGVhciAtLSBJIG5lZWQgdG8gZml4IHRoYXQu KSBUaGUgdmFsdWUgdGhhdCBpdCBhZGRzIGlzIGlmIHRoZSBjbGllbnQgZG9lc24ndCBhc2sgZm9y IGFueSBwYXJ0aWN1bGFyIHNjb3BlcywgdGhlIHNlcnZlciBjYW4gc3RpbGwgYXNzaWduIGl0IHNj b3BlcyBhbmQgdGhlIGNsaWVudCBjYW4gZG8gc29tZXRoaW5nIHNtYXJ0IHdpdGggdGhhdC4gRHVt YiBjbGllbnRzIGFyZSBhbGxvd2VkIHRvIGlnbm9yZSBpdCBpZiBpdCBkb2Vzbid0IG1lYW4gYW55 dGhpbmcgdG8gdGhlbS4NCg0KVGhpcyBpcyBob3cgb3VyIHNlcnZlciBpbXBsZW1lbnRhdGlvbiBh Y3R1YWxseSB3b3JrcyByaWdodCBub3cuIElmIHRoZSBjbGllbnQgZG9lc24ndCBhc2sgZm9yIGFu eXRoaW5nIHNwZWNpZmljIGF0IHJlZ2lzdHJhdGlvbiwgdGhlIHNlcnZlciBoYW5kcyBpdCBhIGJh ZyBvZiAiZGVmYXVsdCIgc2NvcGVzLiBTYW1lIHRoaW5nIGhhcHBlbnMgYXQgYXV0aCB0aW1lIC0t IGlmIHRoZSBjbGllbnQgZG9lc24ndCBhc2sgZm9yIGFueSBwYXJ0aWN1bGFyIHNjb3BlcywgdGhl IHNlcnZlciBoYW5kcyBpdCBhbGwgb2YgaXRzIHJlZ2lzdGVyZWQgc2NvcGVzIGFzIGEgZGVmYXVs dC4gR3JhbnRlZCwgb24gb3VyIHNlcnZlciwgc2NvcGVzIGFyZSBqdXN0IHNpbXBsZSBzdHJpbmdz IHJpZ2h0IG5vdywgc28gdGhleSBnZXQgY29tcGFyZWQgYXQgdGhlIGF1dGggZW5kcG9pbnQgd2l0 aCBhbiBleGFjdCBzdHJpbmctbWF0Y2ggbWV0cmljIGFuZCBzZXQtYmFzZWQgbG9naWMuDQoNCiAt LSBKdXN0aW4NCg0KDQoNCk9uIE1vbiwgQXByIDE1LCAyMDEzIGF0IDc6MzUgQU0sIEp1c3RpbiBS aWNoZXIgPGpyaWNoZXJAbWl0cmUub3JnPG1haWx0bzpqcmljaGVyQG1pdHJlLm9yZz4+IHdyb3Rl Og0KV2hhdCB3b3VsZCB5b3Ugc3VnZ2VzdCBmb3Igd29yZGluZyBoZXJlLCB0aGVuPyBLZWVwaW5n IGluIG1pbmQgdGhhdCB3ZSBjYW5ub3QgKGFuZCBkb24ndCB3YW50IHRvKSBwcm9oaWJpdCBleHBy ZXNzaW9uLWJhc2VkIHNjb3Blcy4NCg0KIC0tIEp1c3Rpbg0KDQpPbiAwNC8xNS8yMDEzIDEwOjMz IEFNLCBUaW0gQnJheSB3cm90ZToNCk5vLCBJIG1lYW4gaXTigJlzIG5vdCBpbnRlcm9wZXJhYmxl IGF0IHRoZSBzb2Z0d2FyZS1kZXZlbG9wZXIgbGV2ZWwuICBJIGNhbuKAmXQgcmVnaXN0ZXIgc2Nv cGVzIGF0IGF1dGhvcml6YXRpb24gdGltZSB3aXRoIGFueSBwcmVkaWN0YWJsZSBlZmZlY3QgdGhh dCBJIGNhbiB3cml0ZSBjb2RlIHRvIHN1cHBvcnQsIGVpdGhlciBjbGllbnQgb3Igc2VydmVyIHNp ZGUsIHdpdGhvdXQgb3V0LW9mLWxpbmUgbm9uLWludGVyb3BlcmFibGUga25vd2xlZGdlIGFib3V0 IHRoZSBiZWhhdmlvciBvZiB0aGUgc2VydmVyLg0KDQpJIGd1ZXNzIEnigJltIGp1c3Qgbm90IHVz ZWQgdG8gT0F1dGjigJlzIGN1bHR1cmUgb2YgaGF2aW5nIG5vIGV4cGVjdGF0aW9uIHRoYXQgdGhp bmdzIHdpbGwgYmUgc3BlY2lmaWVkIHRpZ2h0bHkgZW5vdWdoIHRoYXQgSSBjYW4gd3JpdGUgY29k ZSB0byBpbXBsZW1lbnQgYXMgc3BlY2lmaWVkLiAgLVQNCg0KT24gTW9uLCBBcHIgMTUsIDIwMTMg YXQgNzoxNSBBTSwgSnVzdGluIFJpY2hlciA8anJpY2hlckBtaXRyZS5vcmc8bWFpbHRvOmpyaWNo ZXJAbWl0cmUub3JnPj4gd3JvdGU6DQpTY29wZXMgYXJlbid0IG1lYW50IHRvIGJlIGludGVyb3Bl cmFibGUgYmV0d2VlbiBzZXJ2aWNlcyBzaW5jZSB0aGV5J3JlIG5lY2Vzc2FyaWx5IEFQSS1zcGVj aWZpYy4gVGhlIG9ubHkgaW50ZXJvcGVyYWJsZSBiaXQgaXMgdGhhdCB0aGVyZSdzICpzb21lKiBw bGFjZSB0byBwdXQgdGhlIHZhbHVlcyBhbmQgdGhhdCBpdCdzIGV4cHJlc3NlZCBhcyBhIGJhZyBv ZiBzcGFjZS1zZXBhcmF0ZWQgc3RyaW5ncy4gSG93IHRob3NlIHN0cmluZ3MgZ2V0IGludGVycHJl dGVkIGFuZCBlbmZvcmNlZCAod2hpY2ggaXMgcmVhbGx5IHdoYXQncyBhdCBzdGFrZSBoZXJlKSBp cyB1cCB0byB0aGUgQVMgYW5kIFBSIChvciBhIGhpZ2hlci1sZXZlbCBwcm90b2NvbCBsaWtlIFVN QSkuDQoNCiAtLSBKdXN0aW4NCg0KT24gMDQvMTUvMjAxMyAxMDoxMyBBTSwgVGltIEJyYXkgd3Jv dGU6DQoNClRoaXMsIGFzIHdyaXR0ZW4sIGhhcyB6ZXJvIGludGVyb3BlcmFiaWxpdHkuICBJIHRo aW5rIHRoaXMgZmVhdHVyZSBjYW4gcmVhbGx5IG9ubHkgYmUgbWFkZSB1c2VmdWwgaW4gdGhlIGNh c2Ugd2hlcmUgc2NvcGVzIGFyZSBmaXhlZCBzdHJpbmdzLg0KDQotVA0KT24gQXByIDE1LCAyMDEz IDY6NTQgQU0sICJKdXN0aW4gUmljaGVyIiA8anJpY2hlckBtaXRyZS5vcmc8bWFpbHRvOmpyaWNo ZXJAbWl0cmUub3JnPj4gd3JvdGU6DQpZb3UgYXJlIGNvcnJlY3QgdGhhdCB0aGUgaWRlYSBiZWhp bmQgdGhlICJzY29wZSIgcGFyYW1ldGVyIGF0IHJlZ2lzdHJhdGlvbiBpcyBhIGNvbnN0cmFpbnQg b24gYXV0aG9yaXphdGlvbi10aW1lIHNjb3BlcyB0aGF0IGFyZSBtYWRlIGF2YWlsYWJsZS4gSXQn cyBib3RoIGEgbWVhbnMgZm9yIHRoZSBjbGllbnQgdG8gcmVxdWVzdCBhIHNldCBvZiB2YWxpZCBz Y29wZXMgYW5kIGZvciB0aGUgc2VydmVyIHRvIHByb3Zpc2lvbiAoYW5kIGVjaG8gYmFjayB0byB0 aGUgY2xpZW50KSBhIHNldCBvZiB2YWxpZCBzY29wZXMuDQoNCkkgKnJlYWxseSogZG9uJ3Qgd2Fu dCB0byB0cnkgdG8gZGVmaW5lIGEgbWF0Y2hpbmcgbGFuZ3VhZ2UgZm9yIHNjb3BlIGV4cHJlc3Np b25zLiBGb3IgdGhhdCB0byB3b3JrLCBhbGwgc2VydmVycyB3b3VsZCBuZWVkIHRvIGJlIGFibGUg dG8gcHJvY2VzcyB0aGUgcmVndWxhciBleHByZXNzaW9ucyBmb3IgYWxsIGNsaWVudHMsIGV2ZW4g aWYgdGhlIHNlcnZlcnMgdGhlbXNlbHZlcyBvbmx5IHN1cHBvcnQgc2ltcGxlLXN0cmluZyBzY29w ZSB2YWx1ZXMuIEFueSByZWd1bGFyIGV4cHJlc3Npb24gc3ludGF4IHdlIHBpY2sgaGVyZSBpcyBn dWFyYW50ZWVkIHRvIGJlIGluY29tcGF0aWJsZSB3aXRoIHNvbWV0aGluZywgYW5kIEkgdGhpbmsg dGhlIGNvbXBsZXhpdHkgZG9lc24ndCBidXkgbXVjaC4gQWxzbywgSSB0aGluayB5b3Ugc3VkZGVu bHkgaGF2ZSBhIHBvdGVudGlhbCBzZWN1cml0eSBpc3N1ZSBpZiB5b3UgaGF2ZSBhIGJhZCByZWdl eCBpbiBwbGFjZSBvbiBlaXRoZXIgZW5kLg0KDQpBcyBpdCBzdGFuZHMgdG9kYXksIHRoZSBzZXJ2 ZXIgY2FuIGludGVycHJldCB0aGUgaW5jb21pbmcgcmVnaXN0cmF0aW9uIHNjb3BlcyBhbmQgZW5m b3JjZSB0aGVtIGhvd2V2ZXIgaXQgd2FudHMgdG8uIFRoZSByZWFsIHRyaWNrIGNvbWVzIG5vdCBm cm9tIGFzc2lnbmluZyB0aGUgdmFsdWVzIHRvIGEgcGFydGljdWxhciBjbGllbnQgYnV0IHRvIGVu Zm9yY2luZyB0aGVtLCBhbmQgSSB0aGluayB0aGF0J3MgYWx3YXlzIGdvaW5nIHRvIGJlIHNlcnZp Y2Utc3BlY2lmaWMuIFdlJ3JlIGp1c3Qgbm90IGFzIGNsZWFyIG9uIHRoYXQgYXMgd2UgY291bGQg YmUuDQoNCkFmdGVyIGxvb2tpbmcgb3ZlciBldmVyeW9uZSdzIGNvbW1lbnRzIHNvIGZhciwgSSdk IGxpa2UgdG8gcHJvcG9zZSB0aGUgZm9sbG93aW5nIHRleHQgZm9yIHRoYXQgc2VjdGlvbjoNCg0K DQogICBzY29wZQ0KDQogICAgICBPUFRJT05BTC4gIFNwYWNlIHNlcGFyYXRlZCBsaXN0IG9mIHNj b3BlIHZhbHVlcyAoYXMgZGVzY3JpYmVkIGluDQoNCiAgICAgIE9BdXRoIDIuMCBTZWN0aW9uIDMu MyBbUkZDNjc0OV08aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjc0OSNzZWN0aW9uLTMu Mz4pIHRoYXQgdGhlIGNsaWVudCBjYW4gdXNlIHdoZW4NCg0KICAgICAgcmVxdWVzdGluZyBhY2Nl c3MgdG9rZW5zLiAgQXMgc2NvcGUgdmFsdWVzIGFyZSBzZXJ2aWNlLXNwZWNpZmljLA0KDQogICAg ICB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgTUFZIGRlZmluZSBpdHMgb3duIG1hdGNoaW5nIHJ1 bGVzIHdoZW4NCg0KICAgICAgZGV0ZXJtaW5pbmcgaWYgYSBzY29wZSB2YWx1ZSB1c2VkIGR1cmlu ZyBhbiBhdXRob3JpemF0aW9uIHJlcXVlc3QNCg0KICAgICAgaXMgdmFsaWQgYWNjb3JkaW5nIHRv IHRoZSBzY29wZSB2YWx1ZXMgYXNzaWduZWQgZHVyaW5nDQoNCiAgICAgIHJlZ2lzdHJhdGlvbi4g UG9zc2libGUgbWF0Y2hpbmcgcnVsZXMgaW5jbHVkZSB3aWxkY2FyZCBwYXR0ZXJucywNCg0KICAg ICAgcmVndWxhciBleHByZXNzaW9ucywgb3IgZXhhY3RseSBtYXRjaGluZyB0aGUgc3RyaW5nLiBJ ZiBvbWl0dGVkLA0KDQogICAgICBhbiBBdXRob3JpemF0aW9uIFNlcnZlciBNQVkgcmVnaXN0ZXIg YSBDbGllbnQgd2l0aCBhIGRlZmF1bHQNCg0KICAgICAgc2V0IG9mIHNjb3Blcy4NCg0KQ29tbWVu dHM/IEltcHJvdmVtZW50cz8NCg0KIC0tIEp1c3Rpbg0KDQpPbiAwNC8xNC8yMDEzIDA4OjIzIFBN LCBNYW5nZXIsIEphbWVzIEggd3JvdGU6DQoNClByZXN1bWFibHkgYXQgYXBwIHJlZ2lzdHJhdGlv biB0aW1lIGFueSBzY29wZSBzcGVjaWZpY2F0aW9uIGlzIHJlYWxseSBhIGNvbnN0cmFpbnQgb24g dGhlIHNjb3BlIHZhbHVlcyB0aGF0IGNhbiBiZSByZXF1ZXN0ZWQgaW4gYW4gYXV0aG9yaXphdGlv biBmbG93Lg0KDQoNCg0KU28gaWRlYWxseSByZWdpc3RyYXRpb24gc2hvdWxkIGFjY2VwdCBydWxl cyBmb3IgbWF0Y2hpbmcgc2NvcGVzLCBhcyBvcHBvc2VkIHRvIGFjdHVhbCBzY29wZSB2YWx1ZXMu DQoNCg0KDQpZb3UgY2FuIHRyeSB0byB1c2Ugc2NvcGUgdmFsdWVzIGFzIHRoZWlyIG93biBtYXRj aGluZyBydWxlcy4gVGhhdCBpcyBmaW5lIGZvciBhIHNtYWxsIHNldCBvZiAic3RhdGljIiBzY29w ZXMuIEl0IHN0YXJ0cyB0byBmYWlsIHdoZW4gdGhlcmUgYXJlIGEgbGFyZ2UgbnVtYmVyIG9mIHNj b3Blcywgb3Igc2NvcGVzIHRoYXQgY2FuIGluY2x1ZGUgcGFyYW1ldGVycyAocmVzb3VyY2UgcGF0 aHM/IGVtYWlsIGFkZHJlc3Nlcz8pLiBZb3UgY2FuIHRyeSB0byBwYXRjaCB0aG9zZSBmYWlsdXJl cyBieSBhbGxvd2luZyBzZXJ2aWNlcyB0byBkZWZpbmUgc2VydmljZS1zcGVjaWZpYyBzcGVjaWFs ICJ3aWxkY2FyZCIgc2NvcGUgdmFsdWVzIHRoYXQgY2FuIG9ubHkgYmUgdXNlZCBkdXJpbmcgcmVn aXN0cmF0aW9uIChlZyAicmVhZDoqIikuDQoNCg0KDQpBbHRlcm5hdGl2ZWx5LCByZXBsYWNlICdz Y29wZScgaW4gcmVnaXN0cmF0aW9uIHdpdGggJ3Njb3BlX3JlZ2V4JyB0aGF0IGhvbGRzIGEgcmVn dWxhciBleHByZXNzaW9uIHRoYXQgYWxsIHNjb3BlIHZhbHVlcyBpbiBhbiBhdXRob3JpemF0aW9u IGZsb3cgbXVzdCBtYXRjaC4NCg0KDQoNCi0tDQoNCkphbWVzIE1hbmdlcg0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpPQXV0aCBtYWlsaW5nIGxp c3QNCg0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KDQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhA aWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9vYXV0aA0KDQoNCg0KDQoNCg== --_000_4E1F6AAD24975D4BA5B168042967394367641A87TK5EX14MBXC283r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1h cmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFy Z2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uaG9lbnpiDQoJ e21zby1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21z by1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWls eToiQ29uc29sYXMiLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjEN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9 InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgdGhpbmsgdGhh dCB0aGUgZXhpc3Rpbmcgd29yZGluZyBpcyBzdXBlcmlvciB0byB0aGUgcHJvcG9zZWQgY2hhbmdl ZCB3b3JkaW5nLiZuYnNwOyBUaGUgZXhpc3Rpbmcgd29yZGluZyBpczo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4i IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjp3aW5kb3d0 ZXh0Ij4mbmJzcDsmbmJzcDsgc2NvcGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJF TiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOndpbmRv d3RleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBPUFRJT05BTC4mbmJzcDsgU3Bh Y2Ugc2VwYXJhdGVkIGxpc3Qgb2Ygc2NvcGUgdmFsdWVzIChhcyBkZXNjcmliZWQgaW48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1i ZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBPQXV0aCAyLjANCjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3Jm YzY3NDkjc2VjdGlvbi0zLjMiPlNlY3Rpb24mbmJzcDszLjMgW1JGQzY3NDldPC9hPikgdGhhdCB0 aGUgY2xpZW50IGlzIGRlY2xhcmluZyB0aGF0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFu Zz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjp3 aW5kb3d0ZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaXQgbWF5IHVzZSB3aGVu IHJlcXVlc3RpbmcgYWNjZXNzIHRva2Vucy4mbmJzcDsgSWYgb21pdHRlZCwgYW48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZv cmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBBdXRob3JpemF0aW9uIFNlcnZlciBNQVkgcmVnaXN0ZXIgYSBDbGllbnQgd2l0aCBhIGRl ZmF1bHQgc2V0IG9mPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc2NvcGVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZv cmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Rm9y IGluc3RhbmNlLCB0aGUgY3VycmVudCDigJxjbGllbnQgaXMgZGVjbGFyaW5n4oCdIHdvcmRpbmcg d2lsbCBhbHdheXMgYmUgY29ycmVjdCwgd2hlcmVhcyBhcyB0aGUgY2hhbmdlIHRvIOKAnGNsaWVu dCBjYW4gdXNl4oCdIHdvcmRpbmcNCiBpbXBsaWVzIGEgcmVzdHJpY3Rpb24gb24gY2xpZW50IGJl aGF2aW9yIHRoYXQgaXMgbm90IGFsd2F5cyBhcHBsaWNhYmxlLiZuYnNwOyBUaGUg4oCcY2xpZW50 IGlzIGRlY2xhcmluZ+KAnSB3b3JkaW5nIHdhcyBzcGVjaWZpYyBhbmQgcHVycG9zZWZ1bGx5IGNo b3NlbiwgYW5kIEkgdGhpbmsgc2hvdWxkIGJlIHJldGFpbmVkLiZuYnNwOyBJbiBwYXJ0aWN1bGFy LCB3ZSBjYW7igJl0IGRvIGFueXRoaW5nIHRoYXQgaW1wbGllcyB0aGF0IG9ubHkgdGhlIHJlZ2lz dGVyZWQgc2NvcGVzDQogdmFsdWVzIGNhbiBiZSB1c2VkLiZuYnNwOyBBdCB0aGUgT0F1dGggc3Bl YyBsZXZlbCwgdGhpcyBpcyBhIGhpbnQgYXMgdG8gcG9zc2libGUgZnV0dXJlIGNsaWVudCBiZWhh dmlvciDigJMgbm90IGEgcmVzdHJpY3Rpb24gb24gZnV0dXJlIGNsaWVudCBiZWhhdmlvci48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVh ay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkFsc28sIGZvciB0aGUgcmVhc29ucyB0aGF0IFRpbSBzdGF0ZWQsIEni gJltIHN0cm9uZ2x5IGFnYWluc3QgYW55IOKAnG1hdGNoaW5n4oCdIG9yIOKAnHJlZ2V44oCdIGxh bmd1YWdlIGluIHRoZSBzcGVjIHBlcnRhaW5pbmcgdG8gc2NvcGVzDQog4oCTIGFzIGl04oCZcyBu b3QgYWN0aW9uYWJsZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNvIEnigJlkIHByb3Bvc2UgdGhhdCB3 ZSBsZWF2ZSB0aGUgZXhpc3Rpbmcgc2NvcGUgd29yZGluZyBpbiBwbGFjZS4mbmJzcDsgQWx0ZXJu YXRpdmVseSwgSeKAmWQgYWxzbyBiZSBmaW5lIHdpdGggZGVsZXRpbmcgdGhpcyBmZWF0dXJlDQog ZW50aXJlbHksIGFzIEkgZG9u4oCZdCB0aGluayBpdOKAmXMgdXNlZnVsIGluIHRoZSBnZW5lcmFs IGNhc2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiBvYXV0aC1ib3VuY2VzQGlldGYub3Jn IFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+SnVz dGluIFJpY2hlcjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEFwcmlsIDE1LCAyMDEzIDg6MDUg QU08YnI+DQo8Yj5Ubzo8L2I+IFRpbSBCcmF5OyBvYXV0aEBpZXRmLm9yZzxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBSZTogW09BVVRILVdHXSBSZWdpc3RyYXRpb246IFNjb3BlIFZhbHVlczxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDA0LzE1LzIwMTMgMTA6 NTIgQU0sIFRpbSBCcmF5IHdyb3RlOjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPknigJlkIHVzZSB0aGUgZXhpc3Rpbmcgd29yZGluZzsgaXTi gJlzIHBlcmZlY3RseSBjbGVhci4gJm5ic3A7RmFpbGluZyB0aGF0LCBpZiB0aGVyZeKAmXMgc3Ry b25nIGRlbWFuZCBmb3IgcmVnaXN0cmF0aW9uIG9mIHN0cnVjdHVyZWQgc2NvcGVzLCBibGVzcyB0 aGUgdXNlIG9mIHJlZ2V4ZXMsIGVpdGhlciBQQ1JFcyBvciBzb21lIGNhcmVmdWwgc3Vic2V0Ljxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpUaGFua3Mg Zm9yIHRoZSBmZWVkYmFjayAtLSBPZiB0aGVzZSB0d28gY2hvaWNlcywgSSdkIHJhdGhlciBsZWF2 ZSBpdCBhcy1pcy4gPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SG93ZXZlciwgSeKAmWQgc3VidHJhY3QgdGhlIHNl bnRlbmNlIOKAnElmIG9taXR0ZWQsIGFuIEF1dGhvcml6YXRpb24gU2VydmVyIE1BWSByZWdpc3Rl ciBhIENsaWVudCB3aXRoIGEgZGVmYXVsdCBzZXQgb2YgJm5ic3A7c2NvcGVzLuKAnSAmbmJzcDtJ dCBhZGRzIG5vIHZhbHVlOyBpZiB0aGUgY2xpZW50IGRvZXNu4oCZdCBkZWNsYXJlIHNjb3Blcywg dGhlIGNsaWVudCBkb2VzbuKAmXQgZGVjbGFyZSBzY29wZXMsIHRoYXTigJlzIGFsbC4gJm5ic3A7 LVQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 YnI+DQpSZW1lbWJlciwgYWxsIG9mIHRoZXNlIGZpZWxkcyBhcmVuJ3QganVzdCBmb3IgdGhlIGNs aWVudCAqcmVxdWVzdCosIHRoZXkncmUgYWxzbyBmb3IgdGhlIHNlcnZlcidzICpyZXNwb25zZSog dG8gZWl0aGVyIGEgUE9TVCwgUFVULCBvciBHRVQgcmVxdWVzdC4gKEkgZGlkbid0IHJlYWxpemUg aXQsIGJ1dCBwZXJoYXBzIHRoZSB3b3JkaW5nIGFzIHN0YXRlZCByaWdodCBub3cgZG9lc24ndCBt YWtlIHRoYXQgY2xlYXIgLS0gSSBuZWVkIHRvIGZpeCB0aGF0LikNCiBUaGUgdmFsdWUgdGhhdCBp dCBhZGRzIGlzIGlmIHRoZSBjbGllbnQgZG9lc24ndCBhc2sgZm9yIGFueSBwYXJ0aWN1bGFyIHNj b3BlcywgdGhlIHNlcnZlciBjYW4gc3RpbGwgYXNzaWduIGl0IHNjb3BlcyBhbmQgdGhlIGNsaWVu dCBjYW4gZG8gc29tZXRoaW5nIHNtYXJ0IHdpdGggdGhhdC4gRHVtYiBjbGllbnRzIGFyZSBhbGxv d2VkIHRvIGlnbm9yZSBpdCBpZiBpdCBkb2Vzbid0IG1lYW4gYW55dGhpbmcgdG8gdGhlbS4NCjxi cj4NCjxicj4NClRoaXMgaXMgaG93IG91ciBzZXJ2ZXIgaW1wbGVtZW50YXRpb24gYWN0dWFsbHkg d29ya3MgcmlnaHQgbm93LiBJZiB0aGUgY2xpZW50IGRvZXNuJ3QgYXNrIGZvciBhbnl0aGluZyBz cGVjaWZpYyBhdCByZWdpc3RyYXRpb24sIHRoZSBzZXJ2ZXIgaGFuZHMgaXQgYSBiYWcgb2YgJnF1 b3Q7ZGVmYXVsdCZxdW90OyBzY29wZXMuIFNhbWUgdGhpbmcgaGFwcGVucyBhdCBhdXRoIHRpbWUg LS0gaWYgdGhlIGNsaWVudCBkb2Vzbid0IGFzayBmb3IgYW55IHBhcnRpY3VsYXIgc2NvcGVzLA0K IHRoZSBzZXJ2ZXIgaGFuZHMgaXQgYWxsIG9mIGl0cyByZWdpc3RlcmVkIHNjb3BlcyBhcyBhIGRl ZmF1bHQuIEdyYW50ZWQsIG9uIG91ciBzZXJ2ZXIsIHNjb3BlcyBhcmUganVzdCBzaW1wbGUgc3Ry aW5ncyByaWdodCBub3csIHNvIHRoZXkgZ2V0IGNvbXBhcmVkIGF0IHRoZSBhdXRoIGVuZHBvaW50 IHdpdGggYW4gZXhhY3Qgc3RyaW5nLW1hdGNoIG1ldHJpYyBhbmQgc2V0LWJhc2VkIGxvZ2ljLg0K PGJyPg0KPGJyPg0KJm5ic3A7LS0gSnVzdGluPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5P biBNb24sIEFwciAxNSwgMjAxMyBhdCA3OjM1IEFNLCBKdXN0aW4gUmljaGVyICZsdDs8YSBocmVm PSJtYWlsdG86anJpY2hlckBtaXRyZS5vcmciIHRhcmdldD0iX2JsYW5rIj5qcmljaGVyQG1pdHJl Lm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPldoYXQgd291bGQgeW91IHN1Z2dlc3QgZm9yIHdvcmRpbmcgaGVyZSwgdGhlbj8gS2Vl cGluZyBpbiBtaW5kIHRoYXQgd2UgY2Fubm90IChhbmQgZG9uJ3Qgd2FudCB0bykgcHJvaGliaXQg ZXhwcmVzc2lvbi1iYXNlZCBzY29wZXMuDQo8YnI+DQo8c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4 OCI+PGJyPg0KPHNwYW4gY2xhc3M9ImhvZW56YiI+Jm5ic3A7LS0gSnVzdGluPC9zcGFuPjwvc3Bh bj4gPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMDQvMTUvMjAxMyAxMDozMyBBTSwgVGltIEJyYXkgd3Jv dGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pk5vLCBJIG1lYW4gaXTigJlzIG5vdCBpbnRlcm9wZXJhYmxlIGF0IHRoZSBzb2Z0d2FyZS1kZXZl bG9wZXIgbGV2ZWwuICZuYnNwO0kgY2Fu4oCZdCByZWdpc3RlciBzY29wZXMgYXQgYXV0aG9yaXph dGlvbiB0aW1lIHdpdGggYW55IHByZWRpY3RhYmxlIGVmZmVjdCB0aGF0IEkgY2FuIHdyaXRlIGNv ZGUgdG8gc3VwcG9ydCwgZWl0aGVyIGNsaWVudCBvciBzZXJ2ZXIgc2lkZSwgd2l0aG91dCBvdXQt b2YtbGluZSBub24taW50ZXJvcGVyYWJsZQ0KIGtub3dsZWRnZSBhYm91dCB0aGUgYmVoYXZpb3Ig b2YgdGhlIHNlcnZlci4gJm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SSBndWVzcyBJ4oCZbSBqdXN0IG5vdCB1c2VkIHRvIE9BdXRo4oCZcyBjdWx0 dXJlIG9mIGhhdmluZyBubyBleHBlY3RhdGlvbiB0aGF0IHRoaW5ncyB3aWxsIGJlIHNwZWNpZmll ZCB0aWdodGx5IGVub3VnaCB0aGF0IEkgY2FuIHdyaXRlIGNvZGUgdG8gaW1wbGVtZW50IGFzIHNw ZWNpZmllZC4gJm5ic3A7LVQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIEFwciAx NSwgMjAxMyBhdCA3OjE1IEFNLCBKdXN0aW4gUmljaGVyICZsdDs8YSBocmVmPSJtYWlsdG86anJp Y2hlckBtaXRyZS5vcmciIHRhcmdldD0iX2JsYW5rIj5qcmljaGVyQG1pdHJlLm9yZzwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNjb3Bl cyBhcmVuJ3QgbWVhbnQgdG8gYmUgaW50ZXJvcGVyYWJsZSBiZXR3ZWVuIHNlcnZpY2VzIHNpbmNl IHRoZXkncmUgbmVjZXNzYXJpbHkgQVBJLXNwZWNpZmljLiBUaGUgb25seSBpbnRlcm9wZXJhYmxl IGJpdCBpcyB0aGF0IHRoZXJlJ3MgKnNvbWUqIHBsYWNlIHRvIHB1dCB0aGUgdmFsdWVzIGFuZCB0 aGF0IGl0J3MgZXhwcmVzc2VkIGFzIGEgYmFnIG9mIHNwYWNlLXNlcGFyYXRlZCBzdHJpbmdzLiBI b3cNCiB0aG9zZSBzdHJpbmdzIGdldCBpbnRlcnByZXRlZCBhbmQgZW5mb3JjZWQgKHdoaWNoIGlz IHJlYWxseSB3aGF0J3MgYXQgc3Rha2UgaGVyZSkgaXMgdXAgdG8gdGhlIEFTIGFuZCBQUiAob3Ig YSBoaWdoZXItbGV2ZWwgcHJvdG9jb2wgbGlrZSBVTUEpLjxzcGFuIHN0eWxlPSJjb2xvcjojODg4 ODg4Ij48YnI+DQo8YnI+DQombmJzcDstLSBKdXN0aW48L3NwYW4+IDxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox Mi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pk9uIDA0LzE1LzIwMTMgMTA6MTMgQU0sIFRpbSBCcmF5IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxwPlRoaXMsIGFzIHdyaXR0ZW4sIGhhcyB6ZXJvIGludGVyb3BlcmFiaWxpdHku Jm5ic3A7IEkgdGhpbmsgdGhpcyBmZWF0dXJlIGNhbiByZWFsbHkgb25seSBiZSBtYWRlIHVzZWZ1 bCBpbiB0aGUgY2FzZSB3aGVyZSBzY29wZXMgYXJlIGZpeGVkIHN0cmluZ3MuPG86cD48L286cD48 L3A+DQo8cD4tVDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9u IEFwciAxNSwgMjAxMyA2OjU0IEFNLCAmcXVvdDtKdXN0aW4gUmljaGVyJnF1b3Q7ICZsdDs8YSBo cmVmPSJtYWlsdG86anJpY2hlckBtaXRyZS5vcmciIHRhcmdldD0iX2JsYW5rIj5qcmljaGVyQG1p dHJlLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+WW91IGFyZSBjb3JyZWN0IHRo YXQgdGhlIGlkZWEgYmVoaW5kIHRoZSAmcXVvdDtzY29wZSZxdW90OyBwYXJhbWV0ZXIgYXQgcmVn aXN0cmF0aW9uIGlzIGEgY29uc3RyYWludCBvbiBhdXRob3JpemF0aW9uLXRpbWUgc2NvcGVzIHRo YXQgYXJlIG1hZGUgYXZhaWxhYmxlLiBJdCdzIGJvdGggYSBtZWFucyBmb3IgdGhlIGNsaWVudCB0 byByZXF1ZXN0IGEgc2V0IG9mIHZhbGlkIHNjb3Blcw0KIGFuZCBmb3IgdGhlIHNlcnZlciB0byBw cm92aXNpb24gKGFuZCBlY2hvIGJhY2sgdG8gdGhlIGNsaWVudCkgYSBzZXQgb2YgdmFsaWQgc2Nv cGVzLjxicj4NCjxicj4NCkkgKnJlYWxseSogZG9uJ3Qgd2FudCB0byB0cnkgdG8gZGVmaW5lIGEg bWF0Y2hpbmcgbGFuZ3VhZ2UgZm9yIHNjb3BlIGV4cHJlc3Npb25zLiBGb3IgdGhhdCB0byB3b3Jr LCBhbGwgc2VydmVycyB3b3VsZCBuZWVkIHRvIGJlIGFibGUgdG8gcHJvY2VzcyB0aGUgcmVndWxh ciBleHByZXNzaW9ucyBmb3IgYWxsIGNsaWVudHMsIGV2ZW4gaWYgdGhlIHNlcnZlcnMgdGhlbXNl bHZlcyBvbmx5IHN1cHBvcnQgc2ltcGxlLXN0cmluZyBzY29wZSB2YWx1ZXMuDQogQW55IHJlZ3Vs YXIgZXhwcmVzc2lvbiBzeW50YXggd2UgcGljayBoZXJlIGlzIGd1YXJhbnRlZWQgdG8gYmUgaW5j b21wYXRpYmxlIHdpdGggc29tZXRoaW5nLCBhbmQgSSB0aGluayB0aGUgY29tcGxleGl0eSBkb2Vz bid0IGJ1eSBtdWNoLiBBbHNvLCBJIHRoaW5rIHlvdSBzdWRkZW5seSBoYXZlIGEgcG90ZW50aWFs IHNlY3VyaXR5IGlzc3VlIGlmIHlvdSBoYXZlIGEgYmFkIHJlZ2V4IGluIHBsYWNlIG9uIGVpdGhl ciBlbmQuDQo8YnI+DQo8YnI+DQpBcyBpdCBzdGFuZHMgdG9kYXksIHRoZSBzZXJ2ZXIgY2FuIGlu dGVycHJldCB0aGUgaW5jb21pbmcgcmVnaXN0cmF0aW9uIHNjb3BlcyBhbmQgZW5mb3JjZSB0aGVt IGhvd2V2ZXIgaXQgd2FudHMgdG8uIFRoZSByZWFsIHRyaWNrIGNvbWVzIG5vdCBmcm9tIGFzc2ln bmluZyB0aGUgdmFsdWVzIHRvIGEgcGFydGljdWxhciBjbGllbnQgYnV0IHRvIGVuZm9yY2luZyB0 aGVtLCBhbmQgSSB0aGluayB0aGF0J3MgYWx3YXlzIGdvaW5nIHRvIGJlIHNlcnZpY2Utc3BlY2lm aWMuDQogV2UncmUganVzdCBub3QgYXMgY2xlYXIgb24gdGhhdCBhcyB3ZSBjb3VsZCBiZS48YnI+ DQo8YnI+DQpBZnRlciBsb29raW5nIG92ZXIgZXZlcnlvbmUncyBjb21tZW50cyBzbyBmYXIsIEkn ZCBsaWtlIHRvIHByb3Bvc2UgdGhlIGZvbGxvd2luZyB0ZXh0IGZvciB0aGF0IHNlY3Rpb246PGJy Pg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8cHJlPiZuYnNwOyZuYnNwOyBzY29wZTxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBPUFRJT05BTC4m bmJzcDsgU3BhY2Ugc2VwYXJhdGVkIGxpc3Qgb2Ygc2NvcGUgdmFsdWVzIChhcyBkZXNjcmliZWQg aW48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg T0F1dGggMi4wIDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY3NDkjc2Vj dGlvbi0zLjMiIHRhcmdldD0iX2JsYW5rIj5TZWN0aW9uJm5ic3A7My4zIFtSRkM2NzQ5XTwvYT4p IHRoYXQgdGhlIGNsaWVudCBjYW4gdXNlIHdoZW4gPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7cmVxdWVzdGluZyBhY2Nlc3MgdG9rZW5z LiZuYnNwOyBBcyBzY29wZSB2YWx1ZXMgYXJlIHNlcnZpY2Utc3BlY2lmaWMsIDxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3RoZSBBdXRo b3JpemF0aW9uIFNlcnZlciBNQVkgZGVmaW5lIGl0cyBvd24gbWF0Y2hpbmcgcnVsZXMgd2hlbjxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDtkZXRl cm1pbmluZyBpZiBhIHNjb3BlIHZhbHVlIHVzZWQgZHVyaW5nIGFuIGF1dGhvcml6YXRpb24gcmVx dWVzdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBpcyB2YWxpZCBhY2NvcmRpbmcgdG8gdGhlIHNjb3BlIHZhbHVlcyBhc3NpZ25lZCBkdXJpbmcg PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7cmVnaXN0cmF0aW9uLiBQb3NzaWJsZSBtYXRjaGluZyBydWxlcyBpbmNsdWRlIHdpbGRjYXJk IHBhdHRlcm5zLDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmbmJzcDtyZWd1bGFyIGV4cHJlc3Npb25zLCBvciBleGFjdGx5IG1hdGNoaW5nIHRoZSBzdHJp bmcuIElmIG9taXR0ZWQsIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwO2FuIEF1dGhvcml6YXRpb24gU2VydmVyIE1BWSByZWdpc3RlciBh IENsaWVudCB3aXRoIGEgZGVmYXVsdCA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtzZXQgb2Ygc2NvcGVzLjxvOnA+PC9vOnA+PC9wcmU+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4N CkNvbW1lbnRzPyBJbXByb3ZlbWVudHM/PGJyPg0KPGJyPg0KJm5ic3A7LS0gSnVzdGluPGJyPg0K PGJyPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMDQv MTQvMjAxMyAwODoyMyBQTSwgTWFuZ2VyLCBKYW1lcyBIIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxwcmU+UHJlc3VtYWJseSBhdCBhcHAgcmVnaXN0cmF0aW9uIHRpbWUgYW55IHNj b3BlIHNwZWNpZmljYXRpb24gaXMgcmVhbGx5IGEgY29uc3RyYWludCBvbiB0aGUgc2NvcGUgdmFs dWVzIHRoYXQgY2FuIGJlIHJlcXVlc3RlZCBpbiBhbiBhdXRob3JpemF0aW9uIGZsb3cuPG86cD48 L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+U28gaWRlYWxs eSByZWdpc3RyYXRpb24gc2hvdWxkIGFjY2VwdCBydWxlcyBmb3IgbWF0Y2hpbmcgc2NvcGVzLCBh cyBvcHBvc2VkIHRvIGFjdHVhbCBzY29wZSB2YWx1ZXMuPG86cD48L286cD48L3ByZT4NCjxwcmU+ PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+WW91IGNhbiB0cnkgdG8gdXNlIHNjb3BlIHZh bHVlcyBhcyB0aGVpciBvd24gbWF0Y2hpbmcgcnVsZXMuIFRoYXQgaXMgZmluZSBmb3IgYSBzbWFs bCBzZXQgb2YgJnF1b3Q7c3RhdGljJnF1b3Q7IHNjb3Blcy4gSXQgc3RhcnRzIHRvIGZhaWwgd2hl biB0aGVyZSBhcmUgYSBsYXJnZSBudW1iZXIgb2Ygc2NvcGVzLCBvciBzY29wZXMgdGhhdCBjYW4g aW5jbHVkZSBwYXJhbWV0ZXJzIChyZXNvdXJjZSBwYXRocz8gZW1haWwgYWRkcmVzc2VzPykuIFlv dSBjYW4gdHJ5IHRvIHBhdGNoIHRob3NlIGZhaWx1cmVzIGJ5IGFsbG93aW5nIHNlcnZpY2VzIHRv IGRlZmluZSBzZXJ2aWNlLXNwZWNpZmljIHNwZWNpYWwgJnF1b3Q7d2lsZGNhcmQmcXVvdDsgc2Nv cGUgdmFsdWVzIHRoYXQgY2FuIG9ubHkgYmUgdXNlZCBkdXJpbmcgcmVnaXN0cmF0aW9uIChlZyAm cXVvdDtyZWFkOiomcXVvdDspLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9v OnA+PC9wcmU+DQo8cHJlPkFsdGVybmF0aXZlbHksIHJlcGxhY2UgJ3Njb3BlJyBpbiByZWdpc3Ry YXRpb24gd2l0aCAnc2NvcGVfcmVnZXgnIHRoYXQgaG9sZHMgYSByZWd1bGFyIGV4cHJlc3Npb24g dGhhdCBhbGwgc2NvcGUgdmFsdWVzIGluIGFuIGF1dGhvcml6YXRpb24gZmxvdyBtdXN0IG1hdGNo LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPi0t PG86cD48L286cD48L3ByZT4NCjxwcmU+SmFtZXMgTWFuZ2VyPG86cD48L286cD48L3ByZT4NCjxw cmU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwv bzpwPjwvcHJlPg0KPHByZT5PQXV0aCBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT48YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBp ZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcHJlPg0K PC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_4E1F6AAD24975D4BA5B168042967394367641A87TK5EX14MBXC283r_-- From twbray@google.com Mon Apr 15 09:55:10 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 531FD21F9607 for ; Mon, 15 Apr 2013 09:55:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nmMbuSYP2ifg for ; Mon, 15 Apr 2013 09:55:09 -0700 (PDT) Received: from mail-ia0-x232.google.com (mail-ia0-x232.google.com [IPv6:2607:f8b0:4001:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id DB9B321F93E5 for ; Mon, 15 Apr 2013 09:55:08 -0700 (PDT) Received: by mail-ia0-f178.google.com with SMTP id w21so2810459iac.9 for ; Mon, 15 Apr 2013 09:55:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=lzqp5TV98E/ak1nhSGr3gzarBq828IK/eEaCJxQdoNs=; b=jURjWfDeKhDTZrGf4z7c9qrKO04rRmd0CRUTlytQJVoWzGJD9Kofa6r3aX37AQYYxK 0JTos+eTYiV9LL1m2PIv0M5sVl3QPH/iA7ZIZfmwUx5k3bFKgPaF2a2Iy1T62rA9k4dL HqDlqzgfPPlwCYrF7SGL5YR4ywnyeQn7YsrudxYLGgu9PTRIPbBTqMgk+NAc/MlqIroz YQbSMT6w39Dm1U5tEM/+bZeip+c6weOSlevDHulFgbOKsMo4kUTRkWJ37s96zf0hW4O9 UjgjYXnq+iZziko0Kfbd9DwyloulYyvbIbppW1BtELRTrSpcsh3+WtXCnnhMT1CDJTXh C+kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=lzqp5TV98E/ak1nhSGr3gzarBq828IK/eEaCJxQdoNs=; b=PAlO6KL/+j76H38wLFQ1NK0KAAWIQy4RXeNxqKjXfZim9v5CPZj+24gtWU2mW3ZIn6 VOhhemuZQIFHFtg4SHm2paFJddCDpnhYxF002Y1UthHEmmtJj4bD6JZ5JDWk0cewfxy/ DI5bbLKgU4Fcq6LCtyrsHXxHXoM01TgGvQolYlJ4CXoCJxMkpSml0Jc+luR13J4aINv8 oNfUe2iWdKk6r18ufE8z8vgG/xEANAKh1rYT7Ymbs/5GWCl/LxJlX0CJL235fQNTw/zQ vgr3mmmBA6sK3s1DgYJogrWAsKWKGjtKJdhBn2P9z40d2cWN57J7pN7s4IS8ko/3nc+l 3HJg== X-Received: by 10.50.72.83 with SMTP id b19mr5626657igv.71.1366044908415; Mon, 15 Apr 2013 09:55:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.31.35 with HTTP; Mon, 15 Apr 2013 09:54:38 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B168042967394367641A87@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <255B9BB34FB7D647A506DC292726F6E1150C74DADA@WSMSG3153V.srv.dir.telstra.com> <516C069F.9090308@mitre.org> <516C0B9D.6000402@mitre.org> <516C101F.2090706@mitre.org> <516C1714.8070503@mitre.org> <4E1F6AAD24975D4BA5B168042967394367641A87@TK5EX14MBXC283.redmond.corp.microsoft.com> From: Tim Bray Date: Mon, 15 Apr 2013 09:54:38 -0700 Message-ID: To: Mike Jones Content-Type: multipart/alternative; boundary=047d7bdc19d483887104da691d1d X-Gm-Message-State: ALoCoQm4ltK/vIM2UK1yznVtzr9rds1Mma77PSjD6rgoD8IFmniVMK9EvD6z1fffoYxpIdChMm2mL8S5sXZ44TxgUPH2rkGTHdp/grNN6SJ1p61Gdo7M0F/bIE43dnML2XKXs/SQ4duok+DWCwt/S5lpl7bKL4/zW2lB8tV6+PnpOkogD041yeD42xd2gSXnFxXmLM3PE1+n Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Registration: Scope Values X-BeenThere: oauth@ietf.org X-Mailman-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, 15 Apr 2013 16:55:10 -0000 --047d7bdc19d483887104da691d1d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Apr 15, 2013 at 9:44 AM, Mike Jones wr= ote: > So I=E2=80=99d propose that we leave the existing scope wording in place= . > Alternatively, I=E2=80=99d also be fine with deleting this feature entire= ly, as I > don=E2=80=99t think it=E2=80=99s useful in the general case. > I think we might well have a use for this, so that=E2=80=99s something of a= n existence proof. So I=E2=80=99d prefer if we could leave it in. -T > > ** ** > > -- Mike**** > > ** ** > > *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf > Of *Justin Richer > *Sent:* Monday, April 15, 2013 8:05 AM > *To:* Tim Bray; oauth@ietf.org > > *Subject:* Re: [OAUTH-WG] Registration: Scope Values**** > > ** ** > > On 04/15/2013 10:52 AM, Tim Bray wrote: > > **** > > I=E2=80=99d use the existing wording; it=E2=80=99s perfectly clear. Fail= ing that, if > there=E2=80=99s strong demand for registration of structured scopes, bles= s the use > of regexes, either PCREs or some careful subset.**** > > > Thanks for the feedback -- Of these two choices, I'd rather leave it > as-is. > > > **** > > ** ** > > However, I=E2=80=99d subtract the sentence =E2=80=9CIf omitted, an Author= ization Server > MAY register a Client with a default set of scopes.=E2=80=9D It adds no= value; if > the client doesn=E2=80=99t declare scopes, the client doesn=E2=80=99t dec= lare scopes, > that=E2=80=99s all. -T**** > > > Remember, all of these fields aren't just for the client *request*, > they're also for the server's *response* to either a POST, PUT, or GET > request. (I didn't realize it, but perhaps the wording as stated right no= w > doesn't make that clear -- I need to fix that.) The value that it adds is > if the client doesn't ask for any particular scopes, the server can still > assign it scopes and the client can do something smart with that. Dumb > clients are allowed to ignore it if it doesn't mean anything to them. > > This is how our server implementation actually works right now. If the > client doesn't ask for anything specific at registration, the server hand= s > it a bag of "default" scopes. Same thing happens at auth time -- if the > client doesn't ask for any particular scopes, the server hands it all of > its registered scopes as a default. Granted, on our server, scopes are ju= st > simple strings right now, so they get compared at the auth endpoint with = an > exact string-match metric and set-based logic. > > -- Justin > > > **** > > ** ** > > On Mon, Apr 15, 2013 at 7:35 AM, Justin Richer wrote:= * > *** > > What would you suggest for wording here, then? Keeping in mind that we > cannot (and don't want to) prohibit expression-based scopes. > > -- Justin **** > > ** ** > > On 04/15/2013 10:33 AM, Tim Bray wrote:**** > > No, I mean it=E2=80=99s not interoperable at the software-developer leve= l. I > can=E2=80=99t register scopes at authorization time with any predictable = effect > that I can write code to support, either client or server side, without > out-of-line non-interoperable knowledge about the behavior of the server. > **** > > ** ** > > I guess I=E2=80=99m just not used to OAuth=E2=80=99s culture of having no= expectation that > things will be specified tightly enough that I can write code to implemen= t > as specified. -T**** > > ** ** > > On Mon, Apr 15, 2013 at 7:15 AM, Justin Richer wrote:= * > *** > > Scopes aren't meant to be interoperable between services since they're > necessarily API-specific. The only interoperable bit is that there's *som= e* > place to put the values and that it's expressed as a bag of space-separat= ed > strings. How those strings get interpreted and enforced (which is really > what's at stake here) is up to the AS and PR (or a higher-level protocol > like UMA). > > -- Justin **** > > ** ** > > On 04/15/2013 10:13 AM, Tim Bray wrote:**** > > This, as written, has zero interoperability. I think this feature can > really only be made useful in the case where scopes are fixed strings.***= * > > -T**** > > On Apr 15, 2013 6:54 AM, "Justin Richer" wrote:**** > > You are correct that the idea behind the "scope" parameter at registratio= n > is a constraint on authorization-time scopes that are made available. It'= s > both a means for the client to request a set of valid scopes and for the > server to provision (and echo back to the client) a set of valid scopes. > > I *really* don't want to try to define a matching language for scope > expressions. For that to work, all servers would need to be able to proce= ss > the regular expressions for all clients, even if the servers themselves > only support simple-string scope values. Any regular expression syntax we > pick here is guaranteed to be incompatible with something, and I think th= e > complexity doesn't buy much. Also, I think you suddenly have a potential > security issue if you have a bad regex in place on either end. > > As it stands today, the server can interpret the incoming registration > scopes and enforce them however it wants to. The real trick comes not fro= m > assigning the values to a particular client but to enforcing them, and I > think that's always going to be service-specific. We're just not as clear > on that as we could be. > > After looking over everyone's comments so far, I'd like to propose the > following text for that section: > > **** > > scope**** > > OPTIONAL. Space separated list of scope values (as described in***= * > > OAuth 2.0 Section 3.3 [RFC6749] ) that the client can use when **** > > requesting access tokens. As scope values are service-specific, **= ** > > the Authorization Server MAY define its own matching rules when**** > > determining if a scope value used during an authorization request**= ** > > is valid according to the scope values assigned during **** > > registration. Possible matching rules include wildcard patterns,***= * > > regular expressions, or exactly matching the string. If omitted, **= ** > > an Authorization Server MAY register a Client with a default **** > > set of scopes.**** > > > Comments? Improvements? > > -- Justin > > **** > > On 04/14/2013 08:23 PM, Manger, James H wrote:**** > > Presumably at app registration time any scope specification is really a c= onstraint on the scope values that can be requested in an authorization flo= w.**** > > ** ** > > So ideally registration should accept rules for matching scopes, as oppos= ed to actual scope values.**** > > ** ** > > You can try to use scope values as their own matching rules. That is fine= for a small set of "static" scopes. It starts to fail when there are a lar= ge number of scopes, or scopes that can include parameters (resource paths?= email addresses?). You can try to patch those failures by allowing service= s to define service-specific special "wildcard" scope values that can only = be used during registration (eg "read:*").**** > > ** ** > > Alternatively, replace 'scope' in registration with 'scope_regex' that ho= lds a regular expression that all scope values in an authorization flow mus= t match.**** > > ** ** > > --**** > > James Manger**** > > _______________________________________________**** > > 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**** > > ** ** > > ** ** > > ** ** > > ** ** > > ** ** > --047d7bdc19d483887104da691d1d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Apr 15, 2013 at 9:44 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

So I=E2=80=99d propose that we leave the exi= sting scope wording in place.=C2=A0 Alternatively, I=E2=80=99d also be fine= with deleting this feature entirely, as I don=E2=80=99t think it=E2=80=99s useful in the general case= .


I think we m= ight well have a use for this, so that=E2=80=99s something of an existence = proof. =C2=A0So I=E2=80=99d prefer if we could leave it in. -T

=C2=A0


=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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

=C2=A0

From: oauth-bounces@ietf.org [mailto:oauth-bou= nces@ietf.org] On Behalf Of Justin Richer
Sent: Monday, April 15, 2013 8:05 AM
To: Tim Bray; oauth@ietf.org


Subject: Re: [OAUTH-WG] Registration: Scope Values

=C2=A0

On 04/15/2013 10:52 AM, Tim Bray wrote:

I=E2=80=99d use the existing wording; it=E2=80=99s p= erfectly clear. =C2=A0Failing that, if there=E2=80=99s strong demand for re= gistration of structured scopes, bless the use of regexes, either PCREs or = some careful subset.


Thanks for the feedback -- Of these two choices, I'd rather leave it as= -is.


=C2=A0

However, I=E2=80=99d subtract the sentence =E2=80=9C= If omitted, an Authorization Server MAY register a Client with a default se= t of =C2=A0scopes.=E2=80=9D =C2=A0It adds no value; if the client doesn=E2= =80=99t declare scopes, the client doesn=E2=80=99t declare scopes, that=E2= =80=99s all. =C2=A0-T


Remember, all of these fields aren't just for the client *request*, the= y're also for the server's *response* to either a POST, PUT, or GET= request. (I didn't realize it, but perhaps the wording as stated right= now doesn't make that clear -- I need to fix that.) The value that it adds is if the client doesn't ask for any particular= scopes, the server can still assign it scopes and the client can do someth= ing smart with that. Dumb clients are allowed to ignore it if it doesn'= t mean anything to them.

This is how our server implementation actually works right now. If the clie= nt doesn't ask for anything specific at registration, the server hands = it a bag of "default" scopes. Same thing happens at auth time -- = if the client doesn't ask for any particular scopes, the server hands it all of its registered scopes as a default. Granted, on= our server, scopes are just simple strings right now, so they get compared= at the auth endpoint with an exact string-match metric and set-based logic= .

=C2=A0-- Justin


=C2=A0<= /p>

On Mon, Apr 15, 2013 at 7:35 AM, Justin Richer <<= a href=3D"mailto:jricher@mitre.org" target=3D"_blank" class=3D"cremed">jric= her@mitre.org> wrote:

What would you suggest for wording here, then? Keepi= ng in mind that we cannot (and don't want to) prohibit expression-based= scopes.

=C2=A0-- Justin

=C2=A0<= /p>

On 04/15/2013 10:33 AM, Tim Bray wrote:

No, I mean it=E2=80=99s not interoperable at the sof= tware-developer level. =C2=A0I can=E2=80=99t register scopes at authorizati= on time with any predictable effect that I can write code to support, eithe= r client or server side, without out-of-line non-interoperable knowledge about the behavior of the server. =C2=A0

=C2=A0

I guess I=E2=80=99m just not used to OAuth=E2=80=99s= culture of having no expectation that things will be specified tightly eno= ugh that I can write code to implement as specified. =C2=A0-T=

=C2=A0<= /p>

On Mon, Apr 15, 2013 at 7:15 AM, Justin Richer <<= a href=3D"mailto:jricher@mitre.org" target=3D"_blank" class=3D"cremed">jric= her@mitre.org> wrote:

Scopes aren't meant to be interoperable between = services since they're necessarily API-specific. The only interoperable= bit is that there's *some* place to put the values and that it's e= xpressed as a bag of space-separated strings. How those strings get interpreted and enforced (which is really what's at = stake here) is up to the AS and PR (or a higher-level protocol like UMA).

=C2=A0-- Justin

=C2=A0<= /p>

On 04/15/2013 10:13 AM, Tim Bray wrote:

This, as written, has zero interoperability.=C2=A0 I think this feature = can really only be made useful in the case where scopes are fixed strings.<= u>

-T

On Apr 15, 2013 6:54 AM, "Justin Richer" &= lt;= jricher@mitre.org> wrote:

You are correct that = the idea behind the "scope" parameter at registration is a constr= aint on authorization-time scopes that are made available. It's both a = means for the client to request a set of valid scopes and for the server to provision (and echo back to the client) a set of val= id scopes.

I *really* don't want to try to define a matching language for scope ex= pressions. For that to work, all servers would need to be able to process t= he regular expressions for all clients, even if the servers themselves only= support simple-string scope values. Any regular expression syntax we pick here is guaranteed to be incompatibl= e with something, and I think the complexity doesn't buy much. Also, I = think you suddenly have a potential security issue if you have a bad regex = in place on either end.

As it stands today, the server can interpret the incoming registration scop= es and enforce them however it wants to. The real trick comes not from assi= gning the values to a particular client but to enforcing them, and I think = that's always going to be service-specific. We're just not as clear on that as we could be.

After looking over everyone's comments so far, I'd like to propose = the following text for that section:

=C2=A0=C2=A0 scope
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 OPTIONAL.=C2=A0 Space separated list of=
 scope values (as described in
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 OAuth 2.0 Section=C2=
=A03.3 [RFC6749]) that the client can use when 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0requesting access tokens.=C2=A0 As=
 scope values are service-specific, 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0the Authorization Server MAY defin=
e its own matching rules when
=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0determining if a scope value used durin=
g an authorization request
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 is valid according to the scope values =
assigned during 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0registration. Possible matching ru=
les include wildcard patterns,
=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0regular expressions, or exactly matchin=
g the string. If omitted, 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0an Authorization Server MAY regist=
er a Client with a default 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0set of scopes.


Comments? Improvements?

=C2=A0-- Justin

On 04/14/2013 08:23 PM, Manger, James H wrote:

Presumably at app registration time any scope specification is really =
a constraint on the scope values that can be requested in an authorization =
flow.
=C2=A0
So ideally registration should accept rules for matching scopes, as op=
posed to actual scope values.
=C2=A0
You can try to use scope values as their own matching rules. That is f=
ine for a small set of "static" scopes. It starts to fail when th=
ere are a large number of scopes, or scopes that can include parameters (re=
source paths? email addresses?). You can try to patch those failures by all=
owing services to define service-specific special "wildcard" scop=
e values that can only be used during registration (eg "read:*").=

=C2=A0
Alternatively, replace 'scope' in registration with 'scope=
_regex' that holds a regular expression that all scope values in an aut=
horization flow must match.
=C2=A0
--
James Manger
_______________________________________________
OAuth mailing list
O=
Auth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth=

=C2=A0


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

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0


--047d7bdc19d483887104da691d1d-- From jricher@mitre.org Mon Apr 15 09:57:01 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6582021F9604 for ; Mon, 15 Apr 2013 09:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tOrfobg22nYN for ; Mon, 15 Apr 2013 09:56:59 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7185421F93F6 for ; Mon, 15 Apr 2013 09:56:59 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id DD5041F0517; Mon, 15 Apr 2013 12:56:58 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id CA36B1F04CE; Mon, 15 Apr 2013 12:56:58 -0400 (EDT) Received: from [10.146.15.29] (129.83.31.58) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.342.3; Mon, 15 Apr 2013 12:56:58 -0400 Message-ID: <516C3152.9070603@mitre.org> Date: Mon, 15 Apr 2013 12:56:50 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: Mike Jones References: <255B9BB34FB7D647A506DC292726F6E1150C74DADA@WSMSG3153V.srv.dir.telstra.com> <516C069F.9090308@mitre.org> <516C0B9D.6000402@mitre.org> <516C101F.2090706@mitre.org> <516C1714.8070503@mitre.org> <4E1F6AAD24975D4BA5B168042967394367641A87@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394367641A87@TK5EX14MBXC283.redmond.corp.microsoft.com> Content-Type: multipart/alternative; boundary="------------070004030106070407080109" X-Originating-IP: [129.83.31.58] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Registration: Scope Values X-BeenThere: oauth@ietf.org X-Mailman-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, 15 Apr 2013 16:57:01 -0000 --------------070004030106070407080109 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit I absolutely do not want to delete this feature, as (having implemented it) I think it's very useful. This is a very established pattern in manual registration: I know of many, many OAuth2 servers and clients that are set up where the client must pre-register a set of scopes. I don't like the language of "the client is declaring" because it's too one-sided. The client might not have declared anything, and it might be the server that's declaring something to the client. Deleting the "is declaring" bit removes that unintended restriction of the language while keeping the original meaning intact. I actually thought that I had fixed that before the last draft went in but apparently I missed this one. I will work on clarifying the intent of the whole metadata set in its introductory paragraph(s) so that it's clear that all of these fields are used in both of these situations: 1) The client declaring to the server its desire to use a particular value 2) The server declaring to the client that it has been registered with a particular value This should hopefully clear up the issue in the editor's note that I currently have at the top of that section right now, too. Mike, since you were the one who originally brought up the issue, and you're fine with the existing text, can I take this as closed now? Assuming that you agree with deleting "is declaring" for reasons stated above, I'm fine with leaving everything else as is and staying quiet on what the server has to do with the scopes. -- Justin On 04/15/2013 12:44 PM, Mike Jones wrote: > > I think that the existing wording is superior to the proposed changed > wording. The existing wording is: > > scope > > OPTIONAL. Space separated list of scope values (as described in > > OAuth 2.0 Section 3.3 [RFC6749] > ) that the client is > declaring that > > it may use when requesting access tokens. If omitted, an > > Authorization Server MAY register a Client with a default set of > > scopes. > > For instance, the current “client is declaring” wording will always be > correct, whereas as the change to “client can use” wording implies a > restriction on client behavior that is not always applicable. The > “client is declaring” wording was specific and purposefully chosen, > and I think should be retained. In particular, we can’t do anything > that implies that only the registered scopes values can be used. At > the OAuth spec level, this is a hint as to possible future client > behavior – not a restriction on future client behavior. > > Also, for the reasons that Tim stated, I’m strongly against any > “matching” or “regex” language in the spec pertaining to scopes – as > it’s not actionable. > > So I’d propose that we leave the existing scope wording in place. > Alternatively, I’d also be fine with deleting this feature entirely, > as I don’t think it’s useful in the general case. > > -- Mike > > *From:*oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On > Behalf Of *Justin Richer > *Sent:* Monday, April 15, 2013 8:05 AM > *To:* Tim Bray; oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Registration: Scope Values > > On 04/15/2013 10:52 AM, Tim Bray wrote: > > I’d use the existing wording; it’s perfectly clear. Failing that, if > there’s strong demand for registration of structured scopes, bless the > use of regexes, either PCREs or some careful subset. > > > Thanks for the feedback -- Of these two choices, I'd rather leave it > as-is. > > > However, I’d subtract the sentence “If omitted, an Authorization > Server MAY register a Client with a default set of scopes.” It adds > no value; if the client doesn’t declare scopes, the client doesn’t > declare scopes, that’s all. -T > > > Remember, all of these fields aren't just for the client *request*, > they're also for the server's *response* to either a POST, PUT, or GET > request. (I didn't realize it, but perhaps the wording as stated right > now doesn't make that clear -- I need to fix that.) The value that it > adds is if the client doesn't ask for any particular scopes, the > server can still assign it scopes and the client can do something > smart with that. Dumb clients are allowed to ignore it if it doesn't > mean anything to them. > > This is how our server implementation actually works right now. If the > client doesn't ask for anything specific at registration, the server > hands it a bag of "default" scopes. Same thing happens at auth time -- > if the client doesn't ask for any particular scopes, the server hands > it all of its registered scopes as a default. Granted, on our server, > scopes are just simple strings right now, so they get compared at the > auth endpoint with an exact string-match metric and set-based logic. > > -- Justin > > > On Mon, Apr 15, 2013 at 7:35 AM, Justin Richer > wrote: > > What would you suggest for wording here, then? Keeping in mind that we > cannot (and don't want to) prohibit expression-based scopes. > > -- Justin > > On 04/15/2013 10:33 AM, Tim Bray wrote: > > No, I mean it’s not interoperable at the software-developer level. > I can’t register scopes at authorization time with any > predictable effect that I can write code to support, either client > or server side, without out-of-line non-interoperable knowledge > about the behavior of the server. > > I guess I’m just not used to OAuth’s culture of having no > expectation that things will be specified tightly enough that I > can write code to implement as specified. -T > > On Mon, Apr 15, 2013 at 7:15 AM, Justin Richer > wrote: > > Scopes aren't meant to be interoperable between services since > they're necessarily API-specific. The only interoperable bit is > that there's *some* place to put the values and that it's > expressed as a bag of space-separated strings. How those strings > get interpreted and enforced (which is really what's at stake > here) is up to the AS and PR (or a higher-level protocol like UMA). > > -- Justin > > On 04/15/2013 10:13 AM, Tim Bray wrote: > > This, as written, has zero interoperability. I think this > feature can really only be made useful in the case where > scopes are fixed strings. > > -T > > On Apr 15, 2013 6:54 AM, "Justin Richer" > wrote: > > You are correct that the idea behind the "scope" parameter at > registration is a constraint on authorization-time scopes that > are made available. It's both a means for the client to > request a set of valid scopes and for the server to provision > (and echo back to the client) a set of valid scopes. > > I *really* don't want to try to define a matching language for > scope expressions. For that to work, all servers would need to > be able to process the regular expressions for all clients, > even if the servers themselves only support simple-string > scope values. Any regular expression syntax we pick here is > guaranteed to be incompatible with something, and I think the > complexity doesn't buy much. Also, I think you suddenly have a > potential security issue if you have a bad regex in place on > either end. > > As it stands today, the server can interpret the incoming > registration scopes and enforce them however it wants to. The > real trick comes not from assigning the values to a particular > client but to enforcing them, and I think that's always going > to be service-specific. We're just not as clear on that as we > could be. > > After looking over everyone's comments so far, I'd like to > propose the following text for that section: > > scope > > OPTIONAL. Space separated list of scope values (as described in > > OAuth 2.0Section 3.3 [RFC6749] ) that the client can use when > > requesting access tokens. As scope values are service-specific, > > the Authorization Server MAY define its own matching rules when > > determining if a scope value used during an authorization request > > is valid according to the scope values assigned during > > registration. Possible matching rules include wildcard patterns, > > regular expressions, or exactly matching the string. If omitted, > > an Authorization Server MAY register a Client with a default > > set of scopes. > > > Comments? Improvements? > > -- Justin > > On 04/14/2013 08:23 PM, Manger, James H wrote: > > Presumably at app registration time any scope specification is really a constraint on the scope values that can be requested in an authorization flow. > > > > So ideally registration should accept rules for matching scopes, as opposed to actual scope values. > > > > You can try to use scope values as their own matching rules. That is fine for a small set of "static" scopes. It starts to fail when there are a large number of scopes, or scopes that can include parameters (resource paths? email addresses?). You can try to patch those failures by allowing services to define service-specific special "wildcard" scope values that can only be used during registration (eg "read:*"). > > > > Alternatively, replace 'scope' in registration with 'scope_regex' that holds a regular expression that all scope values in an authorization flow must match. > > > > -- > > James Manger > > _______________________________________________ > > 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 > --------------070004030106070407080109 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit I absolutely do not want to delete this feature, as (having implemented it) I think it's very useful. This is a very established pattern in manual registration: I know of many, many OAuth2 servers and clients that are set up where the client must pre-register a set of scopes.

I don't like the language of "the client is declaring" because it's too one-sided. The client might not have declared anything, and it might be the server that's declaring something to the client. Deleting the "is declaring" bit removes that unintended restriction of the language while keeping the original meaning intact. I actually thought that I had fixed that before the last draft went in but apparently I missed this one.

I will work on clarifying the intent of the whole metadata set in its introductory paragraph(s) so that it's clear that all of these fields are used in both of these situations:

 1) The client declaring to the server its desire to use a particular value
 2) The server declaring to the client that it has been registered with a particular value

This should hopefully clear up the issue in the editor's note that I currently have at the top of that section right now, too.

Mike, since you were the one who originally brought up the issue, and you're fine with the existing text, can I take this as closed now? Assuming that you agree with deleting "is declaring" for reasons stated above, I'm fine with leaving everything else as is and staying quiet on what the server has to do with the scopes.

 -- Justin


On 04/15/2013 12:44 PM, Mike Jones wrote:

I think that the existing wording is superior to the proposed changed wording.  The existing wording is:

 

   scope

      OPTIONAL.  Space separated list of scope values (as described in

      OAuth 2.0 Section 3.3 [RFC6749]) that the client is declaring that

      it may use when requesting access tokens.  If omitted, an

      Authorization Server MAY register a Client with a default set of

      scopes.

 

For instance, the current “client is declaring” wording will always be correct, whereas as the change to “client can use” wording implies a restriction on client behavior that is not always applicable.  The “client is declaring” wording was specific and purposefully chosen, and I think should be retained.  In particular, we can’t do anything that implies that only the registered scopes values can be used.  At the OAuth spec level, this is a hint as to possible future client behavior – not a restriction on future client behavior.

 

Also, for the reasons that Tim stated, I’m strongly against any “matching” or “regex” language in the spec pertaining to scopes – as it’s not actionable.

 

So I’d propose that we leave the existing scope wording in place.  Alternatively, I’d also be fine with deleting this feature entirely, as I don’t think it’s useful in the general case.

 

                                                            -- Mike

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Justin Richer
Sent: Monday, April 15, 2013 8:05 AM
To: Tim Bray; oauth@ietf.org
Subject: Re: [OAUTH-WG] Registration: Scope Values

 

On 04/15/2013 10:52 AM, Tim Bray wrote:

I’d use the existing wording; it’s perfectly clear.  Failing that, if there’s strong demand for registration of structured scopes, bless the use of regexes, either PCREs or some careful subset.


Thanks for the feedback -- Of these two choices, I'd rather leave it as-is.


 

However, I’d subtract the sentence “If omitted, an Authorization Server MAY register a Client with a default set of  scopes.”  It adds no value; if the client doesn’t declare scopes, the client doesn’t declare scopes, that’s all.  -T


Remember, all of these fields aren't just for the client *request*, they're also for the server's *response* to either a POST, PUT, or GET request. (I didn't realize it, but perhaps the wording as stated right now doesn't make that clear -- I need to fix that.) The value that it adds is if the client doesn't ask for any particular scopes, the server can still assign it scopes and the client can do something smart with that. Dumb clients are allowed to ignore it if it doesn't mean anything to them.

This is how our server implementation actually works right now. If the client doesn't ask for anything specific at registration, the server hands it a bag of "default" scopes. Same thing happens at auth time -- if the client doesn't ask for any particular scopes, the server hands it all of its registered scopes as a default. Granted, on our server, scopes are just simple strings right now, so they get compared at the auth endpoint with an exact string-match metric and set-based logic.

 -- Justin


 

On Mon, Apr 15, 2013 at 7:35 AM, Justin Richer <jricher@mitre.org> wrote:

What would you suggest for wording here, then? Keeping in mind that we cannot (and don't want to) prohibit expression-based scopes.

 -- Justin

 

On 04/15/2013 10:33 AM, Tim Bray wrote:

No, I mean it’s not interoperable at the software-developer level.  I can’t register scopes at authorization time with any predictable effect that I can write code to support, either client or server side, without out-of-line non-interoperable knowledge about the behavior of the server.  

 

I guess I’m just not used to OAuth’s culture of having no expectation that things will be specified tightly enough that I can write code to implement as specified.  -T

 

On Mon, Apr 15, 2013 at 7:15 AM, Justin Richer <jricher@mitre.org> wrote:

Scopes aren't meant to be interoperable between services since they're necessarily API-specific. The only interoperable bit is that there's *some* place to put the values and that it's expressed as a bag of space-separated strings. How those strings get interpreted and enforced (which is really what's at stake here) is up to the AS and PR (or a higher-level protocol like UMA).

 -- Justin

 

On 04/15/2013 10:13 AM, Tim Bray wrote:

This, as written, has zero interoperability.  I think this feature can really only be made useful in the case where scopes are fixed strings.

-T

On Apr 15, 2013 6:54 AM, "Justin Richer" <jricher@mitre.org> wrote:

You are correct that the idea behind the "scope" parameter at registration is a constraint on authorization-time scopes that are made available. It's both a means for the client to request a set of valid scopes and for the server to provision (and echo back to the client) a set of valid scopes.

I *really* don't want to try to define a matching language for scope expressions. For that to work, all servers would need to be able to process the regular expressions for all clients, even if the servers themselves only support simple-string scope values. Any regular expression syntax we pick here is guaranteed to be incompatible with something, and I think the complexity doesn't buy much. Also, I think you suddenly have a potential security issue if you have a bad regex in place on either end.

As it stands today, the server can interpret the incoming registration scopes and enforce them however it wants to. The real trick comes not from assigning the values to a particular client but to enforcing them, and I think that's always going to be service-specific. We're just not as clear on that as we could be.

After looking over everyone's comments so far, I'd like to propose the following text for that section:

   scope
      OPTIONAL.  Space separated list of scope values (as described in
      OAuth 2.0 Section 3.3 [RFC6749]) that the client can use when 
      requesting access tokens.  As scope values are service-specific, 
      the Authorization Server MAY define its own matching rules when
      determining if a scope value used during an authorization request
      is valid according to the scope values assigned during 
      registration. Possible matching rules include wildcard patterns,
      regular expressions, or exactly matching the string. If omitted, 
      an Authorization Server MAY register a Client with a default 
      set of scopes.


Comments? Improvements?

 -- Justin

On 04/14/2013 08:23 PM, Manger, James H wrote:

Presumably at app registration time any scope specification is really a constraint on the scope values that can be requested in an authorization flow.
 
So ideally registration should accept rules for matching scopes, as opposed to actual scope values.
 
You can try to use scope values as their own matching rules. That is fine for a small set of "static" scopes. It starts to fail when there are a large number of scopes, or scopes that can include parameters (resource paths? email addresses?). You can try to patch those failures by allowing services to define service-specific special "wildcard" scope values that can only be used during registration (eg "read:*").
 
Alternatively, replace 'scope' in registration with 'scope_regex' that holds a regular expression that all scope values in an authorization flow must match.
 
--
James Manger
_______________________________________________
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

 

 

 

 

 


--------------070004030106070407080109-- From prateek.mishra@oracle.com Mon Apr 15 10:00:36 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9879321F9613 for ; Mon, 15 Apr 2013 10:00:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MaXTcnC9Obnp for ; Mon, 15 Apr 2013 10:00:33 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 625C321F9593 for ; Mon, 15 Apr 2013 10:00:33 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r3FH0WbX028540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 15 Apr 2013 17:00:32 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r3FH0VP4002210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 15 Apr 2013 17:00:32 GMT Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r3FH0Vlq002203 for ; Mon, 15 Apr 2013 17:00:31 GMT Received: from [10.152.55.88] (/10.152.55.88) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 15 Apr 2013 10:00:30 -0700 Message-ID: <516C322D.6050004@oracle.com> Date: Mon, 15 Apr 2013 13:00:29 -0400 From: prateek mishra Organization: Oracle Corporation User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: oauth@ietf.org References: <255B9BB34FB7D647A506DC292726F6E1150C74DADA@WSMSG3153V.srv.dir.telstra.com> <516C069F.9090308@mitre.org> <516C0B9D.6000402@mitre.org> <516C101F.2090706@mitre.org> <516C1714.8070503@mitre.org> <4E1F6AAD24975D4BA5B168042967394367641A87@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394367641A87@TK5EX14MBXC283.redmond.corp.microsoft.com> Content-Type: multipart/alternative; boundary="------------090505000307000903020107" X-Source-IP: acsinet22.oracle.com [141.146.126.238] Subject: Re: [OAUTH-WG] Registration: Scope Values X-BeenThere: oauth@ietf.org X-Mailman-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, 15 Apr 2013 17:00:36 -0000 This is a multi-part message in MIME format. --------------090505000307000903020107 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit +1 > > I think that the existing wording is superior to the proposed changed > wording. The existing wording is: > > scope > > OPTIONAL. Space separated list of scope values (as described in > > OAuth 2.0 Section 3.3 [RFC6749] > ) that the client is > declaring that > > it may use when requesting access tokens. If omitted, an > > Authorization Server MAY register a Client with a default set of > > scopes. > > For instance, the current "client is declaring" wording will always be > correct, whereas as the change to "client can use" wording implies a > restriction on client behavior that is not always applicable. The > "client is declaring" wording was specific and purposefully chosen, > and I think should be retained. In particular, we can't do anything > that implies that only the registered scopes values can be used. At > the OAuth spec level, this is a hint as to possible future client > behavior -- not a restriction on future client behavior. > > Also, for the reasons that Tim stated, I'm strongly against any > "matching" or "regex" language in the spec pertaining to scopes -- as > it's not actionable. > > So I'd propose that we leave the existing scope wording in place. > Alternatively, I'd also be fine with deleting this feature entirely, > as I don't think it's useful in the general case. > > -- Mike > > *From:*oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On > Behalf Of *Justin Richer > *Sent:* Monday, April 15, 2013 8:05 AM > *To:* Tim Bray; oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Registration: Scope Values > > On 04/15/2013 10:52 AM, Tim Bray wrote: > > I'd use the existing wording; it's perfectly clear. Failing that, if > there's strong demand for registration of structured scopes, bless the > use of regexes, either PCREs or some careful subset. > > > Thanks for the feedback -- Of these two choices, I'd rather leave it > as-is. > > > However, I'd subtract the sentence "If omitted, an Authorization > Server MAY register a Client with a default set of scopes." It adds > no value; if the client doesn't declare scopes, the client doesn't > declare scopes, that's all. -T > > > Remember, all of these fields aren't just for the client *request*, > they're also for the server's *response* to either a POST, PUT, or GET > request. (I didn't realize it, but perhaps the wording as stated right > now doesn't make that clear -- I need to fix that.) The value that it > adds is if the client doesn't ask for any particular scopes, the > server can still assign it scopes and the client can do something > smart with that. Dumb clients are allowed to ignore it if it doesn't > mean anything to them. > > This is how our server implementation actually works right now. If the > client doesn't ask for anything specific at registration, the server > hands it a bag of "default" scopes. Same thing happens at auth time -- > if the client doesn't ask for any particular scopes, the server hands > it all of its registered scopes as a default. Granted, on our server, > scopes are just simple strings right now, so they get compared at the > auth endpoint with an exact string-match metric and set-based logic. > > -- Justin > > > On Mon, Apr 15, 2013 at 7:35 AM, Justin Richer > wrote: > > What would you suggest for wording here, then? Keeping in mind that we > cannot (and don't want to) prohibit expression-based scopes. > > -- Justin > > On 04/15/2013 10:33 AM, Tim Bray wrote: > > No, I mean it's not interoperable at the software-developer level. > I can't register scopes at authorization time with any > predictable effect that I can write code to support, either client > or server side, without out-of-line non-interoperable knowledge > about the behavior of the server. > > I guess I'm just not used to OAuth's culture of having no > expectation that things will be specified tightly enough that I > can write code to implement as specified. -T > > On Mon, Apr 15, 2013 at 7:15 AM, Justin Richer > wrote: > > Scopes aren't meant to be interoperable between services since > they're necessarily API-specific. The only interoperable bit is > that there's *some* place to put the values and that it's > expressed as a bag of space-separated strings. How those strings > get interpreted and enforced (which is really what's at stake > here) is up to the AS and PR (or a higher-level protocol like UMA). > > -- Justin > > On 04/15/2013 10:13 AM, Tim Bray wrote: > > This, as written, has zero interoperability. I think this > feature can really only be made useful in the case where > scopes are fixed strings. > > -T > > On Apr 15, 2013 6:54 AM, "Justin Richer" > wrote: > > You are correct that the idea behind the "scope" parameter at > registration is a constraint on authorization-time scopes that > are made available. It's both a means for the client to > request a set of valid scopes and for the server to provision > (and echo back to the client) a set of valid scopes. > > I *really* don't want to try to define a matching language for > scope expressions. For that to work, all servers would need to > be able to process the regular expressions for all clients, > even if the servers themselves only support simple-string > scope values. Any regular expression syntax we pick here is > guaranteed to be incompatible with something, and I think the > complexity doesn't buy much. Also, I think you suddenly have a > potential security issue if you have a bad regex in place on > either end. > > As it stands today, the server can interpret the incoming > registration scopes and enforce them however it wants to. The > real trick comes not from assigning the values to a particular > client but to enforcing them, and I think that's always going > to be service-specific. We're just not as clear on that as we > could be. > > After looking over everyone's comments so far, I'd like to > propose the following text for that section: > > scope > > OPTIONAL. Space separated list of scope values (as described in > > OAuth 2.0Section 3.3 [RFC6749] ) that the client can use when > > requesting access tokens. As scope values are service-specific, > > the Authorization Server MAY define its own matching rules when > > determining if a scope value used during an authorization request > > is valid according to the scope values assigned during > > registration. Possible matching rules include wildcard patterns, > > regular expressions, or exactly matching the string. If omitted, > > an Authorization Server MAY register a Client with a default > > set of scopes. > > > Comments? Improvements? > > -- Justin > > On 04/14/2013 08:23 PM, Manger, James H wrote: > > Presumably at app registration time any scope specification is really a constraint on the scope values that can be requested in an authorization flow. > > > > So ideally registration should accept rules for matching scopes, as opposed to actual scope values. > > > > You can try to use scope values as their own matching rules. That is fine for a small set of "static" scopes. It starts to fail when there are a large number of scopes, or scopes that can include parameters (resource paths? email addresses?). You can try to patch those failures by allowing services to define service-specific special "wildcard" scope values that can only be used during registration (eg "read:*"). > > > > Alternatively, replace 'scope' in registration with 'scope_regex' that holds a regular expression that all scope values in an authorization flow must match. > > > > -- > > James Manger > > _______________________________________________ > > 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 --------------090505000307000903020107 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit +1

I think that the existing wording is superior to the proposed changed wording.  The existing wording is:

 

   scope

      OPTIONAL.  Space separated list of scope values (as described in

      OAuth 2.0 Section 3.3 [RFC6749]) that the client is declaring that

      it may use when requesting access tokens.  If omitted, an

      Authorization Server MAY register a Client with a default set of

      scopes.

 

For instance, the current “client is declaring” wording will always be correct, whereas as the change to “client can use” wording implies a restriction on client behavior that is not always applicable.  The “client is declaring” wording was specific and purposefully chosen, and I think should be retained.  In particular, we can’t do anything that implies that only the registered scopes values can be used.  At the OAuth spec level, this is a hint as to possible future client behavior – not a restriction on future client behavior.

 

Also, for the reasons that Tim stated, I’m strongly against any “matching” or “regex” language in the spec pertaining to scopes – as it’s not actionable.

 

So I’d propose that we leave the existing scope wording in place.  Alternatively, I’d also be fine with deleting this feature entirely, as I don’t think it’s useful in the general case.

 

                                                            -- Mike

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Justin Richer
Sent: Monday, April 15, 2013 8:05 AM
To: Tim Bray; oauth@ietf.org
Subject: Re: [OAUTH-WG] Registration: Scope Values

 

On 04/15/2013 10:52 AM, Tim Bray wrote:

I’d use the existing wording; it’s perfectly clear.  Failing that, if there’s strong demand for registration of structured scopes, bless the use of regexes, either PCREs or some careful subset.


Thanks for the feedback -- Of these two choices, I'd rather leave it as-is.


 

However, I’d subtract the sentence “If omitted, an Authorization Server MAY register a Client with a default set of  scopes.”  It adds no value; if the client doesn’t declare scopes, the client doesn’t declare scopes, that’s all.  -T


Remember, all of these fields aren't just for the client *request*, they're also for the server's *response* to either a POST, PUT, or GET request. (I didn't realize it, but perhaps the wording as stated right now doesn't make that clear -- I need to fix that.) The value that it adds is if the client doesn't ask for any particular scopes, the server can still assign it scopes and the client can do something smart with that. Dumb clients are allowed to ignore it if it doesn't mean anything to them.

This is how our server implementation actually works right now. If the client doesn't ask for anything specific at registration, the server hands it a bag of "default" scopes. Same thing happens at auth time -- if the client doesn't ask for any particular scopes, the server hands it all of its registered scopes as a default. Granted, on our server, scopes are just simple strings right now, so they get compared at the auth endpoint with an exact string-match metric and set-based logic.

 -- Justin


 

On Mon, Apr 15, 2013 at 7:35 AM, Justin Richer <jricher@mitre.org> wrote:

What would you suggest for wording here, then? Keeping in mind that we cannot (and don't want to) prohibit expression-based scopes.

 -- Justin

 

On 04/15/2013 10:33 AM, Tim Bray wrote:

No, I mean it’s not interoperable at the software-developer level.  I can’t register scopes at authorization time with any predictable effect that I can write code to support, either client or server side, without out-of-line non-interoperable knowledge about the behavior of the server.  

 

I guess I’m just not used to OAuth’s culture of having no expectation that things will be specified tightly enough that I can write code to implement as specified.  -T

 

On Mon, Apr 15, 2013 at 7:15 AM, Justin Richer <jricher@mitre.org> wrote:

Scopes aren't meant to be interoperable between services since they're necessarily API-specific. The only interoperable bit is that there's *some* place to put the values and that it's expressed as a bag of space-separated strings. How those strings get interpreted and enforced (which is really what's at stake here) is up to the AS and PR (or a higher-level protocol like UMA).

 -- Justin

 

On 04/15/2013 10:13 AM, Tim Bray wrote:

This, as written, has zero interoperability.  I think this feature can really only be made useful in the case where scopes are fixed strings.

-T

On Apr 15, 2013 6:54 AM, "Justin Richer" <jricher@mitre.org> wrote:

You are correct that the idea behind the "scope" parameter at registration is a constraint on authorization-time scopes that are made available. It's both a means for the client to request a set of valid scopes and for the server to provision (and echo back to the client) a set of valid scopes.

I *really* don't want to try to define a matching language for scope expressions. For that to work, all servers would need to be able to process the regular expressions for all clients, even if the servers themselves only support simple-string scope values. Any regular expression syntax we pick here is guaranteed to be incompatible with something, and I think the complexity doesn't buy much. Also, I think you suddenly have a potential security issue if you have a bad regex in place on either end.

As it stands today, the server can interpret the incoming registration scopes and enforce them however it wants to. The real trick comes not from assigning the values to a particular client but to enforcing them, and I think that's always going to be service-specific. We're just not as clear on that as we could be.

After looking over everyone's comments so far, I'd like to propose the following text for that section:

   scope
      OPTIONAL.  Space separated list of scope values (as described in
      OAuth 2.0 Section 3.3 [RFC6749]) that the client can use when 
      requesting access tokens.  As scope values are service-specific, 
      the Authorization Server MAY define its own matching rules when
      determining if a scope value used during an authorization request
      is valid according to the scope values assigned during 
      registration. Possible matching rules include wildcard patterns,
      regular expressions, or exactly matching the string. If omitted, 
      an Authorization Server MAY register a Client with a default 
      set of scopes.


Comments? Improvements?

 -- Justin

On 04/14/2013 08:23 PM, Manger, James H wrote:

Presumably at app registration time any scope specification is really a constraint on the scope values that can be requested in an authorization flow.
 
So ideally registration should accept rules for matching scopes, as opposed to actual scope values.
 
You can try to use scope values as their own matching rules. That is fine for a small set of "static" scopes. It starts to fail when there are a large number of scopes, or scopes that can include parameters (resource paths? email addresses?). You can try to patch those failures by allowing services to define service-specific special "wildcard" scope values that can only be used during registration (eg "read:*").
 
Alternatively, replace 'scope' in registration with 'scope_regex' that holds a regular expression that all scope values in an authorization flow must match.
 
--
James Manger
_______________________________________________
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

--------------090505000307000903020107-- From Michael.Jones@microsoft.com Mon Apr 15 10:30:20 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C544321F95EF for ; Mon, 15 Apr 2013 10:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 HJnWRje8ESQu for ; Mon, 15 Apr 2013 10:30:19 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0244.outbound.protection.outlook.com [207.46.163.244]) by ietfa.amsl.com (Postfix) with ESMTP id B1A2121F95E9 for ; Mon, 15 Apr 2013 10:30:18 -0700 (PDT) Received: from BN1BFFO11FD014.protection.gbl (10.58.52.202) by BN1AFFO11HUB029.protection.gbl (10.58.52.139) with Microsoft SMTP Server (TLS) id 15.0.664.0; Mon, 15 Apr 2013 17:30:46 +0000 Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.37) by BN1BFFO11FD014.mail.protection.outlook.com (10.58.53.74) with Microsoft SMTP Server (TLS) id 15.0.675.0 via Frontend Transport; Mon, 15 Apr 2013 17:30:16 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.224]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0318.003; Mon, 15 Apr 2013 17:29:55 +0000 From: Mike Jones To: Justin Richer Thread-Topic: [OAUTH-WG] Registration: Scope Values Thread-Index: AQHOOeqUFpSaFgMeSEqfp5thtJ9Xm5jXeeUggAAGtwCAAAX9QA== Date: Mon, 15 Apr 2013 17:29:55 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394367641FAB@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <255B9BB34FB7D647A506DC292726F6E1150C74DADA@WSMSG3153V.srv.dir.telstra.com> <516C069F.9090308@mitre.org> <516C0B9D.6000402@mitre.org> <516C101F.2090706@mitre.org> <516C1714.8070503@mitre.org> <4E1F6AAD24975D4BA5B168042967394367641A87@TK5EX14MBXC283.redmond.corp.microsoft.com> <516C3152.9070603@mitre.org> In-Reply-To: <516C3152.9070603@mitre.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394367641FABTK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(189002)(76482001)(79102001)(49866001)(56816002)(512874001)(65816001)(564824004)(54356001)(18276755001)(4396001)(18277545001)(69226001)(71186001)(55846006)(63696002)(47976001)(66066001)(16406001)(50986001)(51856001)(31966008)(46102001)(54316002)(53806001)(74662001)(80022001)(20776003)(47446002)(77982001)(33656001)(81542001)(59766001)(47736001)(81342001)(56776001)(74502001); DIR:OUT; SFP:; SCL:1; SRVR:BN1AFFO11HUB029; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0817737FD1 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Registration: Scope Values X-BeenThere: oauth@ietf.org X-Mailman-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, 15 Apr 2013 17:30:21 -0000 --_000_4E1F6AAD24975D4BA5B168042967394367641FABTK5EX14MBXC283r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2UgY291bGQgZml4IHRoZSBvbmUtc2lkZWQgbGFuZ3VhZ2UgYnkgY2hhbmdpbmcNCuKAnFNwYWNl IHNlcGFyYXRlZCBsaXN0IG9mIHNjb3BlIHZhbHVlcyAoYXMgZGVzY3JpYmVkIGluIE9BdXRoIDIu MCBTZWN0aW9uIDMuMyBbUkZDNjc0OV08aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjc0 OSNzZWN0aW9uLTMuMz4pIHRoYXQgdGhlIGNsaWVudCBpcyBkZWNsYXJpbmcgdGhhdCBpdCBtYXkg dXNlIHdoZW4gcmVxdWVzdGluZyBhY2Nlc3MgdG9rZW5zLuKAnQ0KdG8NCuKAnFNwYWNlIHNlcGFy YXRlZCBsaXN0IG9mIHNjb3BlIHZhbHVlcyAoYXMgZGVzY3JpYmVkIGluIE9BdXRoIDIuMCBTZWN0 aW9uIDMuMyBbUkZDNjc0OV08aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjc0OSNzZWN0 aW9uLTMuMz4pIHRoYXQgdGhlIGNsaWVudCBpcyBkZWNsYXJpbmcgdG8gdGhlIHNlcnZlciB0aGF0 IGl0IG1heSB1c2Ugd2hlbiByZXF1ZXN0aW5nIGFjY2VzcyB0b2tlbnMgYW5kIHRoYXQgdGhlIHNl cnZlciBpcyBkZWNsYXJpbmcgdG8gdGhlIGNsaWVudCB0aGF0IGl0IGlzIHJlZ2lzdGVyZWQgdG8g dXNlIHdoZW4gcmVxdWVzdGluZyBhY2Nlc3MgdG9rZW5zLuKAnS4NCg0KQWdhaW4sIEkgY2hvc2Ug dGhlIOKAnHJlZ2lzdGVyZWQgdG8gdXNl4oCdIGxhbmd1YWdlIGNhcmVmdWxseSDigJMgYmVjYXVz ZSBpbiB0aGUgZ2VuZXJhbCBjYXNlIGl04oCZcyBub3QgYSByZXN0cmljdGlvbiBvbiB0aGUgdmFs dWVzIHRoYXQgdGhlIGNsaWVudCBjYW4gdXNlIOKAkyBqdXN0IGEgc3RhdGVtZW50IGJ5IHRoZSBz ZXJ2ZXIgdG8gdGhlIGNsaWVudCB0aGF0IGl0IGlzIHJlZ2lzdGVyZWQgdG8gdXNlIHRob3NlIHBh cnRpY3VsYXIgdmFsdWVzLiAgSW4gYm90aCBjYXNlcywgdGhlIHBhcnRpZXMgYXJlIG1ha2luZyBk ZWNsYXJhdGlvbnMgdG8gb25lIGFub3RoZXIuDQoNCklmIHlvdSBhZG9wdCB0aGF0IGxhbmd1YWdl IChvciBrZWVwIHRoZSBvcmlnaW5hbCBsYW5ndWFnZSksIHRoZW4geWVzLCBJ4oCZZCBjb25zaWRl ciB0aGlzIGNsb3NlZC4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBKdXN0aW4gUmljaGVyIFttYWls dG86anJpY2hlckBtaXRyZS5vcmddDQpTZW50OiBNb25kYXksIEFwcmlsIDE1LCAyMDEzIDk6NTcg QU0NClRvOiBNaWtlIEpvbmVzDQpDYzogVGltIEJyYXk7IG9hdXRoQGlldGYub3JnDQpTdWJqZWN0 OiBSZTogW09BVVRILVdHXSBSZWdpc3RyYXRpb246IFNjb3BlIFZhbHVlcw0KDQpJIGFic29sdXRl bHkgZG8gbm90IHdhbnQgdG8gZGVsZXRlIHRoaXMgZmVhdHVyZSwgYXMgKGhhdmluZyBpbXBsZW1l bnRlZCBpdCkgSSB0aGluayBpdCdzIHZlcnkgdXNlZnVsLiBUaGlzIGlzIGEgdmVyeSBlc3RhYmxp c2hlZCBwYXR0ZXJuIGluIG1hbnVhbCByZWdpc3RyYXRpb246IEkga25vdyBvZiBtYW55LCBtYW55 IE9BdXRoMiBzZXJ2ZXJzIGFuZCBjbGllbnRzIHRoYXQgYXJlIHNldCB1cCB3aGVyZSB0aGUgY2xp ZW50IG11c3QgcHJlLXJlZ2lzdGVyIGEgc2V0IG9mIHNjb3Blcy4NCg0KSSBkb24ndCBsaWtlIHRo ZSBsYW5ndWFnZSBvZiAidGhlIGNsaWVudCBpcyBkZWNsYXJpbmciIGJlY2F1c2UgaXQncyB0b28g b25lLXNpZGVkLiBUaGUgY2xpZW50IG1pZ2h0IG5vdCBoYXZlIGRlY2xhcmVkIGFueXRoaW5nLCBh bmQgaXQgbWlnaHQgYmUgdGhlIHNlcnZlciB0aGF0J3MgZGVjbGFyaW5nIHNvbWV0aGluZyB0byB0 aGUgY2xpZW50LiBEZWxldGluZyB0aGUgImlzIGRlY2xhcmluZyIgYml0IHJlbW92ZXMgdGhhdCB1 bmludGVuZGVkIHJlc3RyaWN0aW9uIG9mIHRoZSBsYW5ndWFnZSB3aGlsZSBrZWVwaW5nIHRoZSBv cmlnaW5hbCBtZWFuaW5nIGludGFjdC4gSSBhY3R1YWxseSB0aG91Z2h0IHRoYXQgSSBoYWQgZml4 ZWQgdGhhdCBiZWZvcmUgdGhlIGxhc3QgZHJhZnQgd2VudCBpbiBidXQgYXBwYXJlbnRseSBJIG1p c3NlZCB0aGlzIG9uZS4NCg0KSSB3aWxsIHdvcmsgb24gY2xhcmlmeWluZyB0aGUgaW50ZW50IG9m IHRoZSB3aG9sZSBtZXRhZGF0YSBzZXQgaW4gaXRzIGludHJvZHVjdG9yeSBwYXJhZ3JhcGgocykg c28gdGhhdCBpdCdzIGNsZWFyIHRoYXQgYWxsIG9mIHRoZXNlIGZpZWxkcyBhcmUgdXNlZCBpbiBi b3RoIG9mIHRoZXNlIHNpdHVhdGlvbnM6DQoNCiAxKSBUaGUgY2xpZW50IGRlY2xhcmluZyB0byB0 aGUgc2VydmVyIGl0cyBkZXNpcmUgdG8gdXNlIGEgcGFydGljdWxhciB2YWx1ZQ0KIDIpIFRoZSBz ZXJ2ZXIgZGVjbGFyaW5nIHRvIHRoZSBjbGllbnQgdGhhdCBpdCBoYXMgYmVlbiByZWdpc3RlcmVk IHdpdGggYSBwYXJ0aWN1bGFyIHZhbHVlDQoNClRoaXMgc2hvdWxkIGhvcGVmdWxseSBjbGVhciB1 cCB0aGUgaXNzdWUgaW4gdGhlIGVkaXRvcidzIG5vdGUgdGhhdCBJIGN1cnJlbnRseSBoYXZlIGF0 IHRoZSB0b3Agb2YgdGhhdCBzZWN0aW9uIHJpZ2h0IG5vdywgdG9vLg0KDQpNaWtlLCBzaW5jZSB5 b3Ugd2VyZSB0aGUgb25lIHdobyBvcmlnaW5hbGx5IGJyb3VnaHQgdXAgdGhlIGlzc3VlLCBhbmQg eW91J3JlIGZpbmUgd2l0aCB0aGUgZXhpc3RpbmcgdGV4dCwgY2FuIEkgdGFrZSB0aGlzIGFzIGNs b3NlZCBub3c/IEFzc3VtaW5nIHRoYXQgeW91IGFncmVlIHdpdGggZGVsZXRpbmcgImlzIGRlY2xh cmluZyIgZm9yIHJlYXNvbnMgc3RhdGVkIGFib3ZlLCBJJ20gZmluZSB3aXRoIGxlYXZpbmcgZXZl cnl0aGluZyBlbHNlIGFzIGlzIGFuZCBzdGF5aW5nIHF1aWV0IG9uIHdoYXQgdGhlIHNlcnZlciBo YXMgdG8gZG8gd2l0aCB0aGUgc2NvcGVzLg0KDQogLS0gSnVzdGluDQoNCk9uIDA0LzE1LzIwMTMg MTI6NDQgUE0sIE1pa2UgSm9uZXMgd3JvdGU6DQpJIHRoaW5rIHRoYXQgdGhlIGV4aXN0aW5nIHdv cmRpbmcgaXMgc3VwZXJpb3IgdG8gdGhlIHByb3Bvc2VkIGNoYW5nZWQgd29yZGluZy4gIFRoZSBl eGlzdGluZyB3b3JkaW5nIGlzOg0KDQogICBzY29wZQ0KICAgICAgT1BUSU9OQUwuICBTcGFjZSBz ZXBhcmF0ZWQgbGlzdCBvZiBzY29wZSB2YWx1ZXMgKGFzIGRlc2NyaWJlZCBpbg0KICAgICAgT0F1 dGggMi4wIFNlY3Rpb24gMy4zIFtSRkM2NzQ5XTxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9y ZmM2NzQ5I3NlY3Rpb24tMy4zPikgdGhhdCB0aGUgY2xpZW50IGlzIGRlY2xhcmluZyB0aGF0DQog ICAgICBpdCBtYXkgdXNlIHdoZW4gcmVxdWVzdGluZyBhY2Nlc3MgdG9rZW5zLiAgSWYgb21pdHRl ZCwgYW4NCiAgICAgIEF1dGhvcml6YXRpb24gU2VydmVyIE1BWSByZWdpc3RlciBhIENsaWVudCB3 aXRoIGEgZGVmYXVsdCBzZXQgb2YNCiAgICAgIHNjb3Blcy4NCg0KRm9yIGluc3RhbmNlLCB0aGUg Y3VycmVudCDigJxjbGllbnQgaXMgZGVjbGFyaW5n4oCdIHdvcmRpbmcgd2lsbCBhbHdheXMgYmUg Y29ycmVjdCwgd2hlcmVhcyBhcyB0aGUgY2hhbmdlIHRvIOKAnGNsaWVudCBjYW4gdXNl4oCdIHdv cmRpbmcgaW1wbGllcyBhIHJlc3RyaWN0aW9uIG9uIGNsaWVudCBiZWhhdmlvciB0aGF0IGlzIG5v dCBhbHdheXMgYXBwbGljYWJsZS4gIFRoZSDigJxjbGllbnQgaXMgZGVjbGFyaW5n4oCdIHdvcmRp bmcgd2FzIHNwZWNpZmljIGFuZCBwdXJwb3NlZnVsbHkgY2hvc2VuLCBhbmQgSSB0aGluayBzaG91 bGQgYmUgcmV0YWluZWQuICBJbiBwYXJ0aWN1bGFyLCB3ZSBjYW7igJl0IGRvIGFueXRoaW5nIHRo YXQgaW1wbGllcyB0aGF0IG9ubHkgdGhlIHJlZ2lzdGVyZWQgc2NvcGVzIHZhbHVlcyBjYW4gYmUg dXNlZC4gIEF0IHRoZSBPQXV0aCBzcGVjIGxldmVsLCB0aGlzIGlzIGEgaGludCBhcyB0byBwb3Nz aWJsZSBmdXR1cmUgY2xpZW50IGJlaGF2aW9yIOKAkyBub3QgYSByZXN0cmljdGlvbiBvbiBmdXR1 cmUgY2xpZW50IGJlaGF2aW9yLg0KDQpBbHNvLCBmb3IgdGhlIHJlYXNvbnMgdGhhdCBUaW0gc3Rh dGVkLCBJ4oCZbSBzdHJvbmdseSBhZ2FpbnN0IGFueSDigJxtYXRjaGluZ+KAnSBvciDigJxyZWdl eOKAnSBsYW5ndWFnZSBpbiB0aGUgc3BlYyBwZXJ0YWluaW5nIHRvIHNjb3BlcyDigJMgYXMgaXTi gJlzIG5vdCBhY3Rpb25hYmxlLg0KDQpTbyBJ4oCZZCBwcm9wb3NlIHRoYXQgd2UgbGVhdmUgdGhl IGV4aXN0aW5nIHNjb3BlIHdvcmRpbmcgaW4gcGxhY2UuICBBbHRlcm5hdGl2ZWx5LCBJ4oCZZCBh bHNvIGJlIGZpbmUgd2l0aCBkZWxldGluZyB0aGlzIGZlYXR1cmUgZW50aXJlbHksIGFzIEkgZG9u 4oCZdCB0aGluayBpdOKAmXMgdXNlZnVsIGluIHRoZSBnZW5lcmFsIGNhc2UuDQoNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1p a2UNCg0KRnJvbTogb2F1dGgtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86b2F1dGgtYm91bmNlc0Bp ZXRmLm9yZz4gW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSnVz dGluIFJpY2hlcg0KU2VudDogTW9uZGF5LCBBcHJpbCAxNSwgMjAxMyA4OjA1IEFNDQpUbzogVGlt IEJyYXk7IG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFJl OiBbT0FVVEgtV0ddIFJlZ2lzdHJhdGlvbjogU2NvcGUgVmFsdWVzDQoNCk9uIDA0LzE1LzIwMTMg MTA6NTIgQU0sIFRpbSBCcmF5IHdyb3RlOg0KDQoNCknigJlkIHVzZSB0aGUgZXhpc3Rpbmcgd29y ZGluZzsgaXTigJlzIHBlcmZlY3RseSBjbGVhci4gIEZhaWxpbmcgdGhhdCwgaWYgdGhlcmXigJlz IHN0cm9uZyBkZW1hbmQgZm9yIHJlZ2lzdHJhdGlvbiBvZiBzdHJ1Y3R1cmVkIHNjb3BlcywgYmxl c3MgdGhlIHVzZSBvZiByZWdleGVzLCBlaXRoZXIgUENSRXMgb3Igc29tZSBjYXJlZnVsIHN1YnNl dC4NCg0KVGhhbmtzIGZvciB0aGUgZmVlZGJhY2sgLS0gT2YgdGhlc2UgdHdvIGNob2ljZXMsIEkn ZCByYXRoZXIgbGVhdmUgaXQgYXMtaXMuDQoNCg0KDQoNCkhvd2V2ZXIsIEnigJlkIHN1YnRyYWN0 IHRoZSBzZW50ZW5jZSDigJxJZiBvbWl0dGVkLCBhbiBBdXRob3JpemF0aW9uIFNlcnZlciBNQVkg cmVnaXN0ZXIgYSBDbGllbnQgd2l0aCBhIGRlZmF1bHQgc2V0IG9mICBzY29wZXMu4oCdICBJdCBh ZGRzIG5vIHZhbHVlOyBpZiB0aGUgY2xpZW50IGRvZXNu4oCZdCBkZWNsYXJlIHNjb3BlcywgdGhl IGNsaWVudCBkb2VzbuKAmXQgZGVjbGFyZSBzY29wZXMsIHRoYXTigJlzIGFsbC4gIC1UDQoNClJl bWVtYmVyLCBhbGwgb2YgdGhlc2UgZmllbGRzIGFyZW4ndCBqdXN0IGZvciB0aGUgY2xpZW50ICpy ZXF1ZXN0KiwgdGhleSdyZSBhbHNvIGZvciB0aGUgc2VydmVyJ3MgKnJlc3BvbnNlKiB0byBlaXRo ZXIgYSBQT1NULCBQVVQsIG9yIEdFVCByZXF1ZXN0LiAoSSBkaWRuJ3QgcmVhbGl6ZSBpdCwgYnV0 IHBlcmhhcHMgdGhlIHdvcmRpbmcgYXMgc3RhdGVkIHJpZ2h0IG5vdyBkb2Vzbid0IG1ha2UgdGhh dCBjbGVhciAtLSBJIG5lZWQgdG8gZml4IHRoYXQuKSBUaGUgdmFsdWUgdGhhdCBpdCBhZGRzIGlz IGlmIHRoZSBjbGllbnQgZG9lc24ndCBhc2sgZm9yIGFueSBwYXJ0aWN1bGFyIHNjb3BlcywgdGhl IHNlcnZlciBjYW4gc3RpbGwgYXNzaWduIGl0IHNjb3BlcyBhbmQgdGhlIGNsaWVudCBjYW4gZG8g c29tZXRoaW5nIHNtYXJ0IHdpdGggdGhhdC4gRHVtYiBjbGllbnRzIGFyZSBhbGxvd2VkIHRvIGln bm9yZSBpdCBpZiBpdCBkb2Vzbid0IG1lYW4gYW55dGhpbmcgdG8gdGhlbS4NCg0KVGhpcyBpcyBo b3cgb3VyIHNlcnZlciBpbXBsZW1lbnRhdGlvbiBhY3R1YWxseSB3b3JrcyByaWdodCBub3cuIElm IHRoZSBjbGllbnQgZG9lc24ndCBhc2sgZm9yIGFueXRoaW5nIHNwZWNpZmljIGF0IHJlZ2lzdHJh dGlvbiwgdGhlIHNlcnZlciBoYW5kcyBpdCBhIGJhZyBvZiAiZGVmYXVsdCIgc2NvcGVzLiBTYW1l IHRoaW5nIGhhcHBlbnMgYXQgYXV0aCB0aW1lIC0tIGlmIHRoZSBjbGllbnQgZG9lc24ndCBhc2sg Zm9yIGFueSBwYXJ0aWN1bGFyIHNjb3BlcywgdGhlIHNlcnZlciBoYW5kcyBpdCBhbGwgb2YgaXRz IHJlZ2lzdGVyZWQgc2NvcGVzIGFzIGEgZGVmYXVsdC4gR3JhbnRlZCwgb24gb3VyIHNlcnZlciwg c2NvcGVzIGFyZSBqdXN0IHNpbXBsZSBzdHJpbmdzIHJpZ2h0IG5vdywgc28gdGhleSBnZXQgY29t cGFyZWQgYXQgdGhlIGF1dGggZW5kcG9pbnQgd2l0aCBhbiBleGFjdCBzdHJpbmctbWF0Y2ggbWV0 cmljIGFuZCBzZXQtYmFzZWQgbG9naWMuDQoNCiAtLSBKdXN0aW4NCg0KDQoNCg0KT24gTW9uLCBB cHIgMTUsIDIwMTMgYXQgNzozNSBBTSwgSnVzdGluIFJpY2hlciA8anJpY2hlckBtaXRyZS5vcmc8 bWFpbHRvOmpyaWNoZXJAbWl0cmUub3JnPj4gd3JvdGU6DQpXaGF0IHdvdWxkIHlvdSBzdWdnZXN0 IGZvciB3b3JkaW5nIGhlcmUsIHRoZW4/IEtlZXBpbmcgaW4gbWluZCB0aGF0IHdlIGNhbm5vdCAo YW5kIGRvbid0IHdhbnQgdG8pIHByb2hpYml0IGV4cHJlc3Npb24tYmFzZWQgc2NvcGVzLg0KDQog LS0gSnVzdGluDQoNCk9uIDA0LzE1LzIwMTMgMTA6MzMgQU0sIFRpbSBCcmF5IHdyb3RlOg0KTm8s IEkgbWVhbiBpdOKAmXMgbm90IGludGVyb3BlcmFibGUgYXQgdGhlIHNvZnR3YXJlLWRldmVsb3Bl ciBsZXZlbC4gIEkgY2Fu4oCZdCByZWdpc3RlciBzY29wZXMgYXQgYXV0aG9yaXphdGlvbiB0aW1l IHdpdGggYW55IHByZWRpY3RhYmxlIGVmZmVjdCB0aGF0IEkgY2FuIHdyaXRlIGNvZGUgdG8gc3Vw cG9ydCwgZWl0aGVyIGNsaWVudCBvciBzZXJ2ZXIgc2lkZSwgd2l0aG91dCBvdXQtb2YtbGluZSBu b24taW50ZXJvcGVyYWJsZSBrbm93bGVkZ2UgYWJvdXQgdGhlIGJlaGF2aW9yIG9mIHRoZSBzZXJ2 ZXIuDQoNCkkgZ3Vlc3MgSeKAmW0ganVzdCBub3QgdXNlZCB0byBPQXV0aOKAmXMgY3VsdHVyZSBv ZiBoYXZpbmcgbm8gZXhwZWN0YXRpb24gdGhhdCB0aGluZ3Mgd2lsbCBiZSBzcGVjaWZpZWQgdGln aHRseSBlbm91Z2ggdGhhdCBJIGNhbiB3cml0ZSBjb2RlIHRvIGltcGxlbWVudCBhcyBzcGVjaWZp ZWQuICAtVA0KDQpPbiBNb24sIEFwciAxNSwgMjAxMyBhdCA3OjE1IEFNLCBKdXN0aW4gUmljaGVy IDxqcmljaGVyQG1pdHJlLm9yZzxtYWlsdG86anJpY2hlckBtaXRyZS5vcmc+PiB3cm90ZToNClNj b3BlcyBhcmVuJ3QgbWVhbnQgdG8gYmUgaW50ZXJvcGVyYWJsZSBiZXR3ZWVuIHNlcnZpY2VzIHNp bmNlIHRoZXkncmUgbmVjZXNzYXJpbHkgQVBJLXNwZWNpZmljLiBUaGUgb25seSBpbnRlcm9wZXJh YmxlIGJpdCBpcyB0aGF0IHRoZXJlJ3MgKnNvbWUqIHBsYWNlIHRvIHB1dCB0aGUgdmFsdWVzIGFu ZCB0aGF0IGl0J3MgZXhwcmVzc2VkIGFzIGEgYmFnIG9mIHNwYWNlLXNlcGFyYXRlZCBzdHJpbmdz LiBIb3cgdGhvc2Ugc3RyaW5ncyBnZXQgaW50ZXJwcmV0ZWQgYW5kIGVuZm9yY2VkICh3aGljaCBp cyByZWFsbHkgd2hhdCdzIGF0IHN0YWtlIGhlcmUpIGlzIHVwIHRvIHRoZSBBUyBhbmQgUFIgKG9y IGEgaGlnaGVyLWxldmVsIHByb3RvY29sIGxpa2UgVU1BKS4NCg0KIC0tIEp1c3Rpbg0KDQpPbiAw NC8xNS8yMDEzIDEwOjEzIEFNLCBUaW0gQnJheSB3cm90ZToNCg0KVGhpcywgYXMgd3JpdHRlbiwg aGFzIHplcm8gaW50ZXJvcGVyYWJpbGl0eS4gIEkgdGhpbmsgdGhpcyBmZWF0dXJlIGNhbiByZWFs bHkgb25seSBiZSBtYWRlIHVzZWZ1bCBpbiB0aGUgY2FzZSB3aGVyZSBzY29wZXMgYXJlIGZpeGVk IHN0cmluZ3MuDQoNCi1UDQpPbiBBcHIgMTUsIDIwMTMgNjo1NCBBTSwgIkp1c3RpbiBSaWNoZXIi IDxqcmljaGVyQG1pdHJlLm9yZzxtYWlsdG86anJpY2hlckBtaXRyZS5vcmc+PiB3cm90ZToNCllv dSBhcmUgY29ycmVjdCB0aGF0IHRoZSBpZGVhIGJlaGluZCB0aGUgInNjb3BlIiBwYXJhbWV0ZXIg YXQgcmVnaXN0cmF0aW9uIGlzIGEgY29uc3RyYWludCBvbiBhdXRob3JpemF0aW9uLXRpbWUgc2Nv cGVzIHRoYXQgYXJlIG1hZGUgYXZhaWxhYmxlLiBJdCdzIGJvdGggYSBtZWFucyBmb3IgdGhlIGNs aWVudCB0byByZXF1ZXN0IGEgc2V0IG9mIHZhbGlkIHNjb3BlcyBhbmQgZm9yIHRoZSBzZXJ2ZXIg dG8gcHJvdmlzaW9uIChhbmQgZWNobyBiYWNrIHRvIHRoZSBjbGllbnQpIGEgc2V0IG9mIHZhbGlk IHNjb3Blcy4NCg0KSSAqcmVhbGx5KiBkb24ndCB3YW50IHRvIHRyeSB0byBkZWZpbmUgYSBtYXRj aGluZyBsYW5ndWFnZSBmb3Igc2NvcGUgZXhwcmVzc2lvbnMuIEZvciB0aGF0IHRvIHdvcmssIGFs bCBzZXJ2ZXJzIHdvdWxkIG5lZWQgdG8gYmUgYWJsZSB0byBwcm9jZXNzIHRoZSByZWd1bGFyIGV4 cHJlc3Npb25zIGZvciBhbGwgY2xpZW50cywgZXZlbiBpZiB0aGUgc2VydmVycyB0aGVtc2VsdmVz IG9ubHkgc3VwcG9ydCBzaW1wbGUtc3RyaW5nIHNjb3BlIHZhbHVlcy4gQW55IHJlZ3VsYXIgZXhw cmVzc2lvbiBzeW50YXggd2UgcGljayBoZXJlIGlzIGd1YXJhbnRlZWQgdG8gYmUgaW5jb21wYXRp YmxlIHdpdGggc29tZXRoaW5nLCBhbmQgSSB0aGluayB0aGUgY29tcGxleGl0eSBkb2Vzbid0IGJ1 eSBtdWNoLiBBbHNvLCBJIHRoaW5rIHlvdSBzdWRkZW5seSBoYXZlIGEgcG90ZW50aWFsIHNlY3Vy aXR5IGlzc3VlIGlmIHlvdSBoYXZlIGEgYmFkIHJlZ2V4IGluIHBsYWNlIG9uIGVpdGhlciBlbmQu DQoNCkFzIGl0IHN0YW5kcyB0b2RheSwgdGhlIHNlcnZlciBjYW4gaW50ZXJwcmV0IHRoZSBpbmNv bWluZyByZWdpc3RyYXRpb24gc2NvcGVzIGFuZCBlbmZvcmNlIHRoZW0gaG93ZXZlciBpdCB3YW50 cyB0by4gVGhlIHJlYWwgdHJpY2sgY29tZXMgbm90IGZyb20gYXNzaWduaW5nIHRoZSB2YWx1ZXMg dG8gYSBwYXJ0aWN1bGFyIGNsaWVudCBidXQgdG8gZW5mb3JjaW5nIHRoZW0sIGFuZCBJIHRoaW5r IHRoYXQncyBhbHdheXMgZ29pbmcgdG8gYmUgc2VydmljZS1zcGVjaWZpYy4gV2UncmUganVzdCBu b3QgYXMgY2xlYXIgb24gdGhhdCBhcyB3ZSBjb3VsZCBiZS4NCg0KQWZ0ZXIgbG9va2luZyBvdmVy IGV2ZXJ5b25lJ3MgY29tbWVudHMgc28gZmFyLCBJJ2QgbGlrZSB0byBwcm9wb3NlIHRoZSBmb2xs b3dpbmcgdGV4dCBmb3IgdGhhdCBzZWN0aW9uOg0KDQoNCg0KICAgc2NvcGUNCg0KICAgICAgT1BU SU9OQUwuICBTcGFjZSBzZXBhcmF0ZWQgbGlzdCBvZiBzY29wZSB2YWx1ZXMgKGFzIGRlc2NyaWJl ZCBpbg0KDQogICAgICBPQXV0aCAyLjAgU2VjdGlvbiAzLjMgW1JGQzY3NDldPGh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL3JmYzY3NDkjc2VjdGlvbi0zLjM+KSB0aGF0IHRoZSBjbGllbnQgY2Fu IHVzZSB3aGVuDQoNCiAgICAgIHJlcXVlc3RpbmcgYWNjZXNzIHRva2Vucy4gIEFzIHNjb3BlIHZh bHVlcyBhcmUgc2VydmljZS1zcGVjaWZpYywNCg0KICAgICAgdGhlIEF1dGhvcml6YXRpb24gU2Vy dmVyIE1BWSBkZWZpbmUgaXRzIG93biBtYXRjaGluZyBydWxlcyB3aGVuDQoNCiAgICAgIGRldGVy bWluaW5nIGlmIGEgc2NvcGUgdmFsdWUgdXNlZCBkdXJpbmcgYW4gYXV0aG9yaXphdGlvbiByZXF1 ZXN0DQoNCiAgICAgIGlzIHZhbGlkIGFjY29yZGluZyB0byB0aGUgc2NvcGUgdmFsdWVzIGFzc2ln bmVkIGR1cmluZw0KDQogICAgICByZWdpc3RyYXRpb24uIFBvc3NpYmxlIG1hdGNoaW5nIHJ1bGVz IGluY2x1ZGUgd2lsZGNhcmQgcGF0dGVybnMsDQoNCiAgICAgIHJlZ3VsYXIgZXhwcmVzc2lvbnMs IG9yIGV4YWN0bHkgbWF0Y2hpbmcgdGhlIHN0cmluZy4gSWYgb21pdHRlZCwNCg0KICAgICAgYW4g QXV0aG9yaXphdGlvbiBTZXJ2ZXIgTUFZIHJlZ2lzdGVyIGEgQ2xpZW50IHdpdGggYSBkZWZhdWx0 DQoNCiAgICAgIHNldCBvZiBzY29wZXMuDQoNCkNvbW1lbnRzPyBJbXByb3ZlbWVudHM/DQoNCiAt LSBKdXN0aW4NCg0KDQpPbiAwNC8xNC8yMDEzIDA4OjIzIFBNLCBNYW5nZXIsIEphbWVzIEggd3Jv dGU6DQoNClByZXN1bWFibHkgYXQgYXBwIHJlZ2lzdHJhdGlvbiB0aW1lIGFueSBzY29wZSBzcGVj aWZpY2F0aW9uIGlzIHJlYWxseSBhIGNvbnN0cmFpbnQgb24gdGhlIHNjb3BlIHZhbHVlcyB0aGF0 IGNhbiBiZSByZXF1ZXN0ZWQgaW4gYW4gYXV0aG9yaXphdGlvbiBmbG93Lg0KDQoNCg0KU28gaWRl YWxseSByZWdpc3RyYXRpb24gc2hvdWxkIGFjY2VwdCBydWxlcyBmb3IgbWF0Y2hpbmcgc2NvcGVz LCBhcyBvcHBvc2VkIHRvIGFjdHVhbCBzY29wZSB2YWx1ZXMuDQoNCg0KDQpZb3UgY2FuIHRyeSB0 byB1c2Ugc2NvcGUgdmFsdWVzIGFzIHRoZWlyIG93biBtYXRjaGluZyBydWxlcy4gVGhhdCBpcyBm aW5lIGZvciBhIHNtYWxsIHNldCBvZiAic3RhdGljIiBzY29wZXMuIEl0IHN0YXJ0cyB0byBmYWls IHdoZW4gdGhlcmUgYXJlIGEgbGFyZ2UgbnVtYmVyIG9mIHNjb3Blcywgb3Igc2NvcGVzIHRoYXQg Y2FuIGluY2x1ZGUgcGFyYW1ldGVycyAocmVzb3VyY2UgcGF0aHM/IGVtYWlsIGFkZHJlc3Nlcz8p LiBZb3UgY2FuIHRyeSB0byBwYXRjaCB0aG9zZSBmYWlsdXJlcyBieSBhbGxvd2luZyBzZXJ2aWNl cyB0byBkZWZpbmUgc2VydmljZS1zcGVjaWZpYyBzcGVjaWFsICJ3aWxkY2FyZCIgc2NvcGUgdmFs dWVzIHRoYXQgY2FuIG9ubHkgYmUgdXNlZCBkdXJpbmcgcmVnaXN0cmF0aW9uIChlZyAicmVhZDoq IikuDQoNCg0KDQpBbHRlcm5hdGl2ZWx5LCByZXBsYWNlICdzY29wZScgaW4gcmVnaXN0cmF0aW9u IHdpdGggJ3Njb3BlX3JlZ2V4JyB0aGF0IGhvbGRzIGEgcmVndWxhciBleHByZXNzaW9uIHRoYXQg YWxsIHNjb3BlIHZhbHVlcyBpbiBhbiBhdXRob3JpemF0aW9uIGZsb3cgbXVzdCBtYXRjaC4NCg0K DQoNCi0tDQoNCkphbWVzIE1hbmdlcg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KDQpPQXV0aCBtYWlsaW5nIGxpc3QNCg0KT0F1dGhAaWV0Zi5vcmc8 bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL29hdXRoDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRo QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0K DQoNCg0KDQoNCg0K --_000_4E1F6AAD24975D4BA5B168042967394367641FABTK5EX14MBXC283r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1h cmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFy Z2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30NCnAuTXNvQWNldGF0ZSwg bGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhv bWEiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRD aGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglm b250LWZhbWlseTpDb25zb2xhczsNCgljb2xvcjpibGFjazt9DQpzcGFuLmhvZW56Yg0KCXttc28t c3R5bGUtbmFtZTpob2VuemI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjoj MUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3 RDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0 IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v biBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6Ymxh Y2s7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u dC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47 DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48 IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0 PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5 b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxh bmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6 YWx3YXlzIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+V2UgY291 bGQgZml4IHRoZSBvbmUtc2lkZWQgbGFuZ3VhZ2UgYnkgY2hhbmdpbmc8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjtwYWdl LWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj7igJw8L3NwYW4+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij5TcGFjZSBzZXBhcmF0ZWQgbGlz dCBvZiBzY29wZSB2YWx1ZXMNCiAoYXMgZGVzY3JpYmVkIGluIE9BdXRoIDIuMCA8YSBocmVmPSJo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2NzQ5I3NlY3Rpb24tMy4zIj4NClNlY3Rpb24m bmJzcDszLjMgW1JGQzY3NDldPC9hPikgdGhhdCB0aGUgY2xpZW50IGlzIGRlY2xhcmluZyB0aGF0 IGl0IG1heSB1c2Ugd2hlbiByZXF1ZXN0aW5nIGFjY2VzcyB0b2tlbnMuPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj7igJ08bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlz Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+dG88bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp bjtwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj7igJw8L3NwYW4+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij5TcGFjZSBzZXBhcmF0 ZWQgbGlzdCBvZiBzY29wZSB2YWx1ZXMNCiAoYXMgZGVzY3JpYmVkIGluIE9BdXRoIDIuMCA8YSBo cmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2NzQ5I3NlY3Rpb24tMy4zIj4NClNl Y3Rpb24mbmJzcDszLjMgW1JGQzY3NDldPC9hPikgdGhhdCB0aGUgY2xpZW50IGlzIGRlY2xhcmlu ZyB0byB0aGUgc2VydmVyIHRoYXQgaXQgbWF5IHVzZSB3aGVuIHJlcXVlc3RpbmcgYWNjZXNzIHRv a2VucyBhbmQgdGhhdCB0aGUgc2VydmVyIGlzIGRlY2xhcmluZyB0byB0aGUgY2xpZW50IHRoYXQg aXQgaXMgcmVnaXN0ZXJlZCB0byB1c2Ugd2hlbiByZXF1ZXN0aW5nIGFjY2VzcyB0b2tlbnMuPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj7igJ0uPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWst YmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5BZ2FpbiwgSSBjaG9zZSB0aGUg4oCccmVnaXN0ZXJlZCB0byB1c2XigJ0g bGFuZ3VhZ2UgY2FyZWZ1bGx5IOKAkyBiZWNhdXNlIGluIHRoZSBnZW5lcmFsIGNhc2UgaXTigJlz IG5vdCBhIHJlc3RyaWN0aW9uIG9uIHRoZSB2YWx1ZXMNCiB0aGF0IHRoZSBjbGllbnQgY2FuIHVz ZSDigJMganVzdCBhIHN0YXRlbWVudCBieSB0aGUgc2VydmVyIHRvIHRoZSBjbGllbnQgdGhhdCBp dCBpcyByZWdpc3RlcmVkIHRvIHVzZSB0aG9zZSBwYXJ0aWN1bGFyIHZhbHVlcy4mbmJzcDsgSW4g Ym90aCBjYXNlcywgdGhlIHBhcnRpZXMgYXJlIG1ha2luZyBkZWNsYXJhdGlvbnMgdG8gb25lIGFu b3RoZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JZiB5b3UgYWRvcHQgdGhhdCBsYW5ndWFnZSAob3Ig a2VlcCB0aGUgb3JpZ2luYWwgbGFuZ3VhZ2UpLCB0aGVuIHllcywgSeKAmWQgY29uc2lkZXIgdGhp cyBjbG9zZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiBKdXN0aW4gUmlj aGVyIFttYWlsdG86anJpY2hlckBtaXRyZS5vcmddDQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5 LCBBcHJpbCAxNSwgMjAxMyA5OjU3IEFNPGJyPg0KPGI+VG86PC9iPiBNaWtlIEpvbmVzPGJyPg0K PGI+Q2M6PC9iPiBUaW0gQnJheTsgb2F1dGhAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4g UmU6IFtPQVVUSC1XR10gUmVnaXN0cmF0aW9uOiBTY29wZSBWYWx1ZXM8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPkkgYWJzb2x1dGVseSBkbyBub3Qgd2FudCB0byBkZWxldGUgdGhpcyBmZWF0dXJlLCBhcyAo aGF2aW5nIGltcGxlbWVudGVkIGl0KSBJIHRoaW5rIGl0J3MgdmVyeSB1c2VmdWwuIFRoaXMgaXMg YSB2ZXJ5IGVzdGFibGlzaGVkIHBhdHRlcm4gaW4gbWFudWFsIHJlZ2lzdHJhdGlvbjogSSBrbm93 IG9mIG1hbnksIG1hbnkgT0F1dGgyIHNlcnZlcnMgYW5kIGNsaWVudHMNCiB0aGF0IGFyZSBzZXQg dXAgd2hlcmUgdGhlIGNsaWVudCBtdXN0IHByZS1yZWdpc3RlciBhIHNldCBvZiBzY29wZXMuIDxi cj4NCjxicj4NCkkgZG9uJ3QgbGlrZSB0aGUgbGFuZ3VhZ2Ugb2YgJnF1b3Q7dGhlIGNsaWVudCBp cyBkZWNsYXJpbmcmcXVvdDsgYmVjYXVzZSBpdCdzIHRvbyBvbmUtc2lkZWQuIFRoZSBjbGllbnQg bWlnaHQgbm90IGhhdmUgZGVjbGFyZWQgYW55dGhpbmcsIGFuZCBpdCBtaWdodCBiZSB0aGUgc2Vy dmVyIHRoYXQncyBkZWNsYXJpbmcgc29tZXRoaW5nIHRvIHRoZSBjbGllbnQuIERlbGV0aW5nIHRo ZSAmcXVvdDtpcyBkZWNsYXJpbmcmcXVvdDsgYml0IHJlbW92ZXMgdGhhdCB1bmludGVuZGVkIHJl c3RyaWN0aW9uDQogb2YgdGhlIGxhbmd1YWdlIHdoaWxlIGtlZXBpbmcgdGhlIG9yaWdpbmFsIG1l YW5pbmcgaW50YWN0LiBJIGFjdHVhbGx5IHRob3VnaHQgdGhhdCBJIGhhZCBmaXhlZCB0aGF0IGJl Zm9yZSB0aGUgbGFzdCBkcmFmdCB3ZW50IGluIGJ1dCBhcHBhcmVudGx5IEkgbWlzc2VkIHRoaXMg b25lLjxicj4NCjxicj4NCkkgd2lsbCB3b3JrIG9uIGNsYXJpZnlpbmcgdGhlIGludGVudCBvZiB0 aGUgd2hvbGUgbWV0YWRhdGEgc2V0IGluIGl0cyBpbnRyb2R1Y3RvcnkgcGFyYWdyYXBoKHMpIHNv IHRoYXQgaXQncyBjbGVhciB0aGF0IGFsbCBvZiB0aGVzZSBmaWVsZHMgYXJlIHVzZWQgaW4gYm90 aCBvZiB0aGVzZSBzaXR1YXRpb25zOjxicj4NCjxicj4NCiZuYnNwOzEpIFRoZSBjbGllbnQgZGVj bGFyaW5nIHRvIHRoZSBzZXJ2ZXIgaXRzIGRlc2lyZSB0byB1c2UgYSBwYXJ0aWN1bGFyIHZhbHVl PGJyPg0KJm5ic3A7MikgVGhlIHNlcnZlciBkZWNsYXJpbmcgdG8gdGhlIGNsaWVudCB0aGF0IGl0 IGhhcyBiZWVuIHJlZ2lzdGVyZWQgd2l0aCBhIHBhcnRpY3VsYXIgdmFsdWU8YnI+DQo8YnI+DQpU aGlzIHNob3VsZCBob3BlZnVsbHkgY2xlYXIgdXAgdGhlIGlzc3VlIGluIHRoZSBlZGl0b3IncyBu b3RlIHRoYXQgSSBjdXJyZW50bHkgaGF2ZSBhdCB0aGUgdG9wIG9mIHRoYXQgc2VjdGlvbiByaWdo dCBub3csIHRvby48YnI+DQo8YnI+DQpNaWtlLCBzaW5jZSB5b3Ugd2VyZSB0aGUgb25lIHdobyBv cmlnaW5hbGx5IGJyb3VnaHQgdXAgdGhlIGlzc3VlLCBhbmQgeW91J3JlIGZpbmUgd2l0aCB0aGUg ZXhpc3RpbmcgdGV4dCwgY2FuIEkgdGFrZSB0aGlzIGFzIGNsb3NlZCBub3c/IEFzc3VtaW5nIHRo YXQgeW91IGFncmVlIHdpdGggZGVsZXRpbmcgJnF1b3Q7aXMgZGVjbGFyaW5nJnF1b3Q7IGZvciBy ZWFzb25zIHN0YXRlZCBhYm92ZSwgSSdtIGZpbmUgd2l0aCBsZWF2aW5nIGV2ZXJ5dGhpbmcgZWxz ZSBhcw0KIGlzIGFuZCBzdGF5aW5nIHF1aWV0IG9uIHdoYXQgdGhlIHNlcnZlciBoYXMgdG8gZG8g d2l0aCB0aGUgc2NvcGVzLjxicj4NCjxicj4NCiZuYnNwOy0tIEp1c3Rpbjxicj4NCjxicj4NCjxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDA0LzE1LzIwMTMg MTI6NDQgUE0sIE1pa2UgSm9uZXMgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkkgdGhpbmsgdGhhdCB0aGUgZXhpc3Rpbmcgd29yZGluZyBpcyBzdXBlcmlvciB0byB0aGUg cHJvcG9zZWQgY2hhbmdlZCB3b3JkaW5nLiZuYnNwOyBUaGUgZXhpc3Rpbmcgd29yZGluZyBpczo8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+ PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjp3aW5kb3d0ZXh0Ij4mbmJzcDsmbmJzcDsgc2NvcGU8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlz Ij48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOndpbmRvd3RleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBPUFRJ T05BTC4mbmJzcDsgU3BhY2Ugc2VwYXJhdGVkIGxpc3Qgb2Ygc2NvcGUgdmFsdWVzIChhcyBkZXNj cmliZWQgaW48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBPQXV0aCAyLjANCjxhIGhyZWY9Imh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL3JmYzY3NDkjc2VjdGlvbi0zLjMiPlNlY3Rpb24mbmJzcDszLjMgW1JGQzY3 NDldPC9hPikgdGhhdCB0aGUgY2xpZW50IGlzIGRlY2xhcmluZyB0aGF0PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFs d2F5cyI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg aXQgbWF5IHVzZSB3aGVuIHJlcXVlc3RpbmcgYWNjZXNzIHRva2Vucy4mbmJzcDsgSWYgb21pdHRl ZCwgYW48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i cGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBBdXRob3JpemF0aW9uIFNlcnZlciBNQVkgcmVnaXN0ZXIgYSBD bGllbnQgd2l0aCBhIGRlZmF1bHQgc2V0IG9mPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFu Zz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjp3 aW5kb3d0ZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc2NvcGVzLjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJl Zm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i cGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Rm9yIGluc3RhbmNlLCB0aGUgY3VycmVudCDigJxjbGllbnQgaXMgZGVjbGFy aW5n4oCdIHdvcmRpbmcgd2lsbCBhbHdheXMgYmUgY29ycmVjdCwgd2hlcmVhcyBhcyB0aGUgY2hh bmdlIHRvIOKAnGNsaWVudCBjYW4gdXNl4oCdIHdvcmRpbmcNCiBpbXBsaWVzIGEgcmVzdHJpY3Rp b24gb24gY2xpZW50IGJlaGF2aW9yIHRoYXQgaXMgbm90IGFsd2F5cyBhcHBsaWNhYmxlLiZuYnNw OyBUaGUg4oCcY2xpZW50IGlzIGRlY2xhcmluZ+KAnSB3b3JkaW5nIHdhcyBzcGVjaWZpYyBhbmQg cHVycG9zZWZ1bGx5IGNob3NlbiwgYW5kIEkgdGhpbmsgc2hvdWxkIGJlIHJldGFpbmVkLiZuYnNw OyBJbiBwYXJ0aWN1bGFyLCB3ZSBjYW7igJl0IGRvIGFueXRoaW5nIHRoYXQgaW1wbGllcyB0aGF0 IG9ubHkgdGhlIHJlZ2lzdGVyZWQgc2NvcGVzDQogdmFsdWVzIGNhbiBiZSB1c2VkLiZuYnNwOyBB dCB0aGUgT0F1dGggc3BlYyBsZXZlbCwgdGhpcyBpcyBhIGhpbnQgYXMgdG8gcG9zc2libGUgZnV0 dXJlIGNsaWVudCBiZWhhdmlvciDigJMgbm90IGEgcmVzdHJpY3Rpb24gb24gZnV0dXJlIGNsaWVu dCBiZWhhdmlvci48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFsc28sIGZvciB0aGUgcmVhc29ucyB0aGF0 IFRpbSBzdGF0ZWQsIEnigJltIHN0cm9uZ2x5IGFnYWluc3QgYW55IOKAnG1hdGNoaW5n4oCdIG9y IOKAnHJlZ2V44oCdIGxhbmd1YWdlIGluIHRoZSBzcGVjIHBlcnRhaW5pbmcgdG8gc2NvcGVzDQog 4oCTIGFzIGl04oCZcyBub3QgYWN0aW9uYWJsZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFs d2F5cyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNvIEnigJlk IHByb3Bvc2UgdGhhdCB3ZSBsZWF2ZSB0aGUgZXhpc3Rpbmcgc2NvcGUgd29yZGluZyBpbiBwbGFj ZS4mbmJzcDsgQWx0ZXJuYXRpdmVseSwgSeKAmWQgYWxzbyBiZSBmaW5lIHdpdGggZGVsZXRpbmcg dGhpcyBmZWF0dXJlDQogZW50aXJlbHksIGFzIEkgZG9u4oCZdCB0aGluayBpdOKAmXMgdXNlZnVs IGluIHRoZSBnZW5lcmFsIGNhc2UuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPg0KPGEgaHJl Zj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciPm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8 L2E+IFs8YSBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOm9hdXRo LWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5KdXN0aW4gUmljaGVy PGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgQXByaWwgMTUsIDIwMTMgODowNSBBTTxicj4NCjxi PlRvOjwvYj4gVGltIEJyYXk7IDxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+b2F1dGhA aWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIFJlZ2lzdHJh dGlvbjogU2NvcGUgVmFsdWVzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+T24gMDQvMTUvMjAxMyAxMDo1MiBBTSwgVGltIEJyYXkgd3JvdGU6PGJyPg0KPGJy Pg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SeKA mWQgdXNlIHRoZSBleGlzdGluZyB3b3JkaW5nOyBpdOKAmXMgcGVyZmVjdGx5IGNsZWFyLiAmbmJz cDtGYWlsaW5nIHRoYXQsIGlmIHRoZXJl4oCZcyBzdHJvbmcgZGVtYW5kIGZvciByZWdpc3RyYXRp b24gb2Ygc3RydWN0dXJlZCBzY29wZXMsIGJsZXNzIHRoZSB1c2Ugb2YgcmVnZXhlcywgZWl0aGVy IFBDUkVzIG9yIHNvbWUgY2FyZWZ1bCBzdWJzZXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NClRoYW5rcyBmb3IgdGhlIGZlZWRiYWNrIC0tIE9mIHRo ZXNlIHR3byBjaG9pY2VzLCBJJ2QgcmF0aGVyIGxlYXZlIGl0IGFzLWlzLiA8YnI+DQo8YnI+DQo8 YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5Ib3dldmVyLCBJ4oCZZCBzdWJ0cmFjdCB0aGUgc2VudGVuY2Ug4oCcSWYgb21pdHRl ZCwgYW4gQXV0aG9yaXphdGlvbiBTZXJ2ZXIgTUFZIHJlZ2lzdGVyIGEgQ2xpZW50IHdpdGggYSBk ZWZhdWx0IHNldCBvZiAmbmJzcDtzY29wZXMu4oCdICZuYnNwO0l0IGFkZHMgbm8gdmFsdWU7IGlm IHRoZSBjbGllbnQgZG9lc27igJl0IGRlY2xhcmUgc2NvcGVzLCB0aGUgY2xpZW50IGRvZXNu4oCZ dCBkZWNsYXJlIHNjb3BlcywgdGhhdOKAmXMgYWxsLiAmbmJzcDstVDxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NClJlbWVtYmVyLCBhbGwg b2YgdGhlc2UgZmllbGRzIGFyZW4ndCBqdXN0IGZvciB0aGUgY2xpZW50ICpyZXF1ZXN0KiwgdGhl eSdyZSBhbHNvIGZvciB0aGUgc2VydmVyJ3MgKnJlc3BvbnNlKiB0byBlaXRoZXIgYSBQT1NULCBQ VVQsIG9yIEdFVCByZXF1ZXN0LiAoSSBkaWRuJ3QgcmVhbGl6ZSBpdCwgYnV0IHBlcmhhcHMgdGhl IHdvcmRpbmcgYXMgc3RhdGVkIHJpZ2h0IG5vdyBkb2Vzbid0IG1ha2UgdGhhdCBjbGVhciAtLSBJ IG5lZWQgdG8gZml4IHRoYXQuKQ0KIFRoZSB2YWx1ZSB0aGF0IGl0IGFkZHMgaXMgaWYgdGhlIGNs aWVudCBkb2Vzbid0IGFzayBmb3IgYW55IHBhcnRpY3VsYXIgc2NvcGVzLCB0aGUgc2VydmVyIGNh biBzdGlsbCBhc3NpZ24gaXQgc2NvcGVzIGFuZCB0aGUgY2xpZW50IGNhbiBkbyBzb21ldGhpbmcg c21hcnQgd2l0aCB0aGF0LiBEdW1iIGNsaWVudHMgYXJlIGFsbG93ZWQgdG8gaWdub3JlIGl0IGlm IGl0IGRvZXNuJ3QgbWVhbiBhbnl0aGluZyB0byB0aGVtLg0KPGJyPg0KPGJyPg0KVGhpcyBpcyBo b3cgb3VyIHNlcnZlciBpbXBsZW1lbnRhdGlvbiBhY3R1YWxseSB3b3JrcyByaWdodCBub3cuIElm IHRoZSBjbGllbnQgZG9lc24ndCBhc2sgZm9yIGFueXRoaW5nIHNwZWNpZmljIGF0IHJlZ2lzdHJh dGlvbiwgdGhlIHNlcnZlciBoYW5kcyBpdCBhIGJhZyBvZiAmcXVvdDtkZWZhdWx0JnF1b3Q7IHNj b3Blcy4gU2FtZSB0aGluZyBoYXBwZW5zIGF0IGF1dGggdGltZSAtLSBpZiB0aGUgY2xpZW50IGRv ZXNuJ3QgYXNrIGZvciBhbnkgcGFydGljdWxhciBzY29wZXMsDQogdGhlIHNlcnZlciBoYW5kcyBp dCBhbGwgb2YgaXRzIHJlZ2lzdGVyZWQgc2NvcGVzIGFzIGEgZGVmYXVsdC4gR3JhbnRlZCwgb24g b3VyIHNlcnZlciwgc2NvcGVzIGFyZSBqdXN0IHNpbXBsZSBzdHJpbmdzIHJpZ2h0IG5vdywgc28g dGhleSBnZXQgY29tcGFyZWQgYXQgdGhlIGF1dGggZW5kcG9pbnQgd2l0aCBhbiBleGFjdCBzdHJp bmctbWF0Y2ggbWV0cmljIGFuZCBzZXQtYmFzZWQgbG9naWMuDQo8YnI+DQo8YnI+DQombmJzcDst LSBKdXN0aW48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgQXByIDE1 LCAyMDEzIGF0IDc6MzUgQU0sIEp1c3RpbiBSaWNoZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpqcmlj aGVyQG1pdHJlLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmpyaWNoZXJAbWl0cmUub3JnPC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hhdCB3 b3VsZCB5b3Ugc3VnZ2VzdCBmb3Igd29yZGluZyBoZXJlLCB0aGVuPyBLZWVwaW5nIGluIG1pbmQg dGhhdCB3ZSBjYW5ub3QgKGFuZCBkb24ndCB3YW50IHRvKSBwcm9oaWJpdCBleHByZXNzaW9uLWJh c2VkIHNjb3Blcy4NCjxicj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij48YnI+DQo8c3Bh biBjbGFzcz0iaG9lbnpiIj4mbmJzcDstLSBKdXN0aW48L3NwYW4+PC9zcGFuPiA8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206MTIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5PbiAwNC8xNS8yMDEzIDEwOjMzIEFNLCBUaW0gQnJheSB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Tm8sIEkgbWVhbiBp dOKAmXMgbm90IGludGVyb3BlcmFibGUgYXQgdGhlIHNvZnR3YXJlLWRldmVsb3BlciBsZXZlbC4g Jm5ic3A7SSBjYW7igJl0IHJlZ2lzdGVyIHNjb3BlcyBhdCBhdXRob3JpemF0aW9uIHRpbWUgd2l0 aCBhbnkgcHJlZGljdGFibGUgZWZmZWN0IHRoYXQgSSBjYW4gd3JpdGUgY29kZSB0byBzdXBwb3J0 LCBlaXRoZXIgY2xpZW50IG9yIHNlcnZlciBzaWRlLCB3aXRob3V0IG91dC1vZi1saW5lIG5vbi1p bnRlcm9wZXJhYmxlDQoga25vd2xlZGdlIGFib3V0IHRoZSBiZWhhdmlvciBvZiB0aGUgc2VydmVy LiAmbmJzcDsgPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J IGd1ZXNzIEnigJltIGp1c3Qgbm90IHVzZWQgdG8gT0F1dGjigJlzIGN1bHR1cmUgb2YgaGF2aW5n IG5vIGV4cGVjdGF0aW9uIHRoYXQgdGhpbmdzIHdpbGwgYmUgc3BlY2lmaWVkIHRpZ2h0bHkgZW5v dWdoIHRoYXQgSSBjYW4gd3JpdGUgY29kZSB0byBpbXBsZW1lbnQgYXMgc3BlY2lmaWVkLiAmbmJz cDstVDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgQXByIDE1LCAyMDEzIGF0IDc6 MTUgQU0sIEp1c3RpbiBSaWNoZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpqcmljaGVyQG1pdHJlLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPmpyaWNoZXJAbWl0cmUub3JnPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2NvcGVzIGFyZW4ndCBtZWFu dCB0byBiZSBpbnRlcm9wZXJhYmxlIGJldHdlZW4gc2VydmljZXMgc2luY2UgdGhleSdyZSBuZWNl c3NhcmlseSBBUEktc3BlY2lmaWMuIFRoZSBvbmx5IGludGVyb3BlcmFibGUgYml0IGlzIHRoYXQg dGhlcmUncyAqc29tZSogcGxhY2UgdG8gcHV0IHRoZSB2YWx1ZXMgYW5kIHRoYXQgaXQncyBleHBy ZXNzZWQgYXMgYSBiYWcgb2Ygc3BhY2Utc2VwYXJhdGVkIHN0cmluZ3MuIEhvdw0KIHRob3NlIHN0 cmluZ3MgZ2V0IGludGVycHJldGVkIGFuZCBlbmZvcmNlZCAod2hpY2ggaXMgcmVhbGx5IHdoYXQn cyBhdCBzdGFrZSBoZXJlKSBpcyB1cCB0byB0aGUgQVMgYW5kIFBSIChvciBhIGhpZ2hlci1sZXZl bCBwcm90b2NvbCBsaWtlIFVNQSkuPHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxicj4NCjxi cj4NCiZuYnNwOy0tIEp1c3Rpbjwvc3Bhbj4gPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMDQvMTUvMjAx MyAxMDoxMyBBTSwgVGltIEJyYXkgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHA+ VGhpcywgYXMgd3JpdHRlbiwgaGFzIHplcm8gaW50ZXJvcGVyYWJpbGl0eS4mbmJzcDsgSSB0aGlu ayB0aGlzIGZlYXR1cmUgY2FuIHJlYWxseSBvbmx5IGJlIG1hZGUgdXNlZnVsIGluIHRoZSBjYXNl IHdoZXJlIHNjb3BlcyBhcmUgZml4ZWQgc3RyaW5ncy48bzpwPjwvbzpwPjwvcD4NCjxwPi1UPG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gQXByIDE1LCAyMDEz IDY6NTQgQU0sICZxdW90O0p1c3RpbiBSaWNoZXImcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpq cmljaGVyQG1pdHJlLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmpyaWNoZXJAbWl0cmUub3JnPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5Zb3UgYXJlIGNvcnJlY3QgdGhhdCB0aGUgaWRlYSBi ZWhpbmQgdGhlICZxdW90O3Njb3BlJnF1b3Q7IHBhcmFtZXRlciBhdCByZWdpc3RyYXRpb24gaXMg YSBjb25zdHJhaW50IG9uIGF1dGhvcml6YXRpb24tdGltZSBzY29wZXMgdGhhdCBhcmUgbWFkZSBh dmFpbGFibGUuIEl0J3MgYm90aCBhIG1lYW5zIGZvciB0aGUgY2xpZW50IHRvIHJlcXVlc3QgYSBz ZXQgb2YgdmFsaWQgc2NvcGVzDQogYW5kIGZvciB0aGUgc2VydmVyIHRvIHByb3Zpc2lvbiAoYW5k IGVjaG8gYmFjayB0byB0aGUgY2xpZW50KSBhIHNldCBvZiB2YWxpZCBzY29wZXMuPGJyPg0KPGJy Pg0KSSAqcmVhbGx5KiBkb24ndCB3YW50IHRvIHRyeSB0byBkZWZpbmUgYSBtYXRjaGluZyBsYW5n dWFnZSBmb3Igc2NvcGUgZXhwcmVzc2lvbnMuIEZvciB0aGF0IHRvIHdvcmssIGFsbCBzZXJ2ZXJz IHdvdWxkIG5lZWQgdG8gYmUgYWJsZSB0byBwcm9jZXNzIHRoZSByZWd1bGFyIGV4cHJlc3Npb25z IGZvciBhbGwgY2xpZW50cywgZXZlbiBpZiB0aGUgc2VydmVycyB0aGVtc2VsdmVzIG9ubHkgc3Vw cG9ydCBzaW1wbGUtc3RyaW5nIHNjb3BlIHZhbHVlcy4NCiBBbnkgcmVndWxhciBleHByZXNzaW9u IHN5bnRheCB3ZSBwaWNrIGhlcmUgaXMgZ3VhcmFudGVlZCB0byBiZSBpbmNvbXBhdGlibGUgd2l0 aCBzb21ldGhpbmcsIGFuZCBJIHRoaW5rIHRoZSBjb21wbGV4aXR5IGRvZXNuJ3QgYnV5IG11Y2gu IEFsc28sIEkgdGhpbmsgeW91IHN1ZGRlbmx5IGhhdmUgYSBwb3RlbnRpYWwgc2VjdXJpdHkgaXNz dWUgaWYgeW91IGhhdmUgYSBiYWQgcmVnZXggaW4gcGxhY2Ugb24gZWl0aGVyIGVuZC4NCjxicj4N Cjxicj4NCkFzIGl0IHN0YW5kcyB0b2RheSwgdGhlIHNlcnZlciBjYW4gaW50ZXJwcmV0IHRoZSBp bmNvbWluZyByZWdpc3RyYXRpb24gc2NvcGVzIGFuZCBlbmZvcmNlIHRoZW0gaG93ZXZlciBpdCB3 YW50cyB0by4gVGhlIHJlYWwgdHJpY2sgY29tZXMgbm90IGZyb20gYXNzaWduaW5nIHRoZSB2YWx1 ZXMgdG8gYSBwYXJ0aWN1bGFyIGNsaWVudCBidXQgdG8gZW5mb3JjaW5nIHRoZW0sIGFuZCBJIHRo aW5rIHRoYXQncyBhbHdheXMgZ29pbmcgdG8gYmUgc2VydmljZS1zcGVjaWZpYy4NCiBXZSdyZSBq dXN0IG5vdCBhcyBjbGVhciBvbiB0aGF0IGFzIHdlIGNvdWxkIGJlLjxicj4NCjxicj4NCkFmdGVy IGxvb2tpbmcgb3ZlciBldmVyeW9uZSdzIGNvbW1lbnRzIHNvIGZhciwgSSdkIGxpa2UgdG8gcHJv cG9zZSB0aGUgZm9sbG93aW5nIHRleHQgZm9yIHRoYXQgc2VjdGlvbjo8YnI+DQo8YnI+DQo8YnI+ DQo8bzpwPjwvbzpwPjwvcD4NCjxwcmU+Jm5ic3A7Jm5ic3A7IHNjb3BlPG86cD48L286cD48L3By ZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9QVElPTkFMLiZuYnNwOyBT cGFjZSBzZXBhcmF0ZWQgbGlzdCBvZiBzY29wZSB2YWx1ZXMgKGFzIGRlc2NyaWJlZCBpbjxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBPQXV0aCAy LjAgPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjc0OSNzZWN0aW9uLTMu MyIgdGFyZ2V0PSJfYmxhbmsiPlNlY3Rpb24mbmJzcDszLjMgW1JGQzY3NDldPC9hPikgdGhhdCB0 aGUgY2xpZW50IGNhbiB1c2Ugd2hlbiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtyZXF1ZXN0aW5nIGFjY2VzcyB0b2tlbnMuJm5ic3A7 IEFzIHNjb3BlIHZhbHVlcyBhcmUgc2VydmljZS1zcGVjaWZpYywgPG86cD48L286cD48L3ByZT4N CjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7dGhlIEF1dGhvcml6YXRp b24gU2VydmVyIE1BWSBkZWZpbmUgaXRzIG93biBtYXRjaGluZyBydWxlcyB3aGVuPG86cD48L286 cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwO2RldGVybWluaW5n IGlmIGEgc2NvcGUgdmFsdWUgdXNlZCBkdXJpbmcgYW4gYXV0aG9yaXphdGlvbiByZXF1ZXN0PG86 cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGlzIHZh bGlkIGFjY29yZGluZyB0byB0aGUgc2NvcGUgdmFsdWVzIGFzc2lnbmVkIGR1cmluZyA8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtyZWdp c3RyYXRpb24uIFBvc3NpYmxlIG1hdGNoaW5nIHJ1bGVzIGluY2x1ZGUgd2lsZGNhcmQgcGF0dGVy bnMsPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNw O3JlZ3VsYXIgZXhwcmVzc2lvbnMsIG9yIGV4YWN0bHkgbWF0Y2hpbmcgdGhlIHN0cmluZy4gSWYg b21pdHRlZCwgPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7YW4gQXV0aG9yaXphdGlvbiBTZXJ2ZXIgTUFZIHJlZ2lzdGVyIGEgQ2xpZW50 IHdpdGggYSBkZWZhdWx0IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwO3NldCBvZiBzY29wZXMuPG86cD48L286cD48L3ByZT4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KQ29tbWVu dHM/IEltcHJvdmVtZW50cz88YnI+DQo8YnI+DQombmJzcDstLSBKdXN0aW48YnI+DQo8YnI+DQo8 YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAwNC8x NC8yMDEzIDA4OjIzIFBNLCBNYW5nZXIsIEphbWVzIEggd3JvdGU6PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPHByZT5QcmVzdW1hYmx5IGF0IGFwcCByZWdpc3RyYXRpb24gdGltZSBhbnkgc2Nv cGUgc3BlY2lmaWNhdGlvbiBpcyByZWFsbHkgYSBjb25zdHJhaW50IG9uIHRoZSBzY29wZSB2YWx1 ZXMgdGhhdCBjYW4gYmUgcmVxdWVzdGVkIGluIGFuIGF1dGhvcml6YXRpb24gZmxvdy48bzpwPjwv bzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5TbyBpZGVhbGx5 IHJlZ2lzdHJhdGlvbiBzaG91bGQgYWNjZXB0IHJ1bGVzIGZvciBtYXRjaGluZyBzY29wZXMsIGFz IG9wcG9zZWQgdG8gYWN0dWFsIHNjb3BlIHZhbHVlcy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4m bmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Zb3UgY2FuIHRyeSB0byB1c2Ugc2NvcGUgdmFs dWVzIGFzIHRoZWlyIG93biBtYXRjaGluZyBydWxlcy4gVGhhdCBpcyBmaW5lIGZvciBhIHNtYWxs IHNldCBvZiAmcXVvdDtzdGF0aWMmcXVvdDsgc2NvcGVzLiBJdCBzdGFydHMgdG8gZmFpbCB3aGVu IHRoZXJlIGFyZSBhIGxhcmdlIG51bWJlciBvZiBzY29wZXMsIG9yIHNjb3BlcyB0aGF0IGNhbiBp bmNsdWRlIHBhcmFtZXRlcnMgKHJlc291cmNlIHBhdGhzPyBlbWFpbCBhZGRyZXNzZXM/KS4gWW91 IGNhbiB0cnkgdG8gcGF0Y2ggdGhvc2UgZmFpbHVyZXMgYnkgYWxsb3dpbmcgc2VydmljZXMgdG8g ZGVmaW5lIHNlcnZpY2Utc3BlY2lmaWMgc3BlY2lhbCAmcXVvdDt3aWxkY2FyZCZxdW90OyBzY29w ZSB2YWx1ZXMgdGhhdCBjYW4gb25seSBiZSB1c2VkIGR1cmluZyByZWdpc3RyYXRpb24gKGVnICZx dW90O3JlYWQ6KiZxdW90OykuPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286 cD48L3ByZT4NCjxwcmU+QWx0ZXJuYXRpdmVseSwgcmVwbGFjZSAnc2NvcGUnIGluIHJlZ2lzdHJh dGlvbiB3aXRoICdzY29wZV9yZWdleCcgdGhhdCBob2xkcyBhIHJlZ3VsYXIgZXhwcmVzc2lvbiB0 aGF0IGFsbCBzY29wZSB2YWx1ZXMgaW4gYW4gYXV0aG9yaXphdGlvbiBmbG93IG11c3QgbWF0Y2gu PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+LS08 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5KYW1lcyBNYW5nZXI8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPk9BdXRoIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGll dGYub3JnPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8 L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_4E1F6AAD24975D4BA5B168042967394367641FABTK5EX14MBXC283r_-- From ve7jtb@ve7jtb.com Mon Apr 15 12:24:54 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0967F21F9552 for ; Mon, 15 Apr 2013 12:24:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.769 X-Spam-Level: X-Spam-Status: No, score=-1.769 tagged_above=-999 required=5 tests=[AWL=1.829, 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 Hy4xwONDTPRP for ; Mon, 15 Apr 2013 12:24:33 -0700 (PDT) Received: from mail-gh0-f181.google.com (mail-gh0-f181.google.com [209.85.160.181]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED6621F8F50 for ; Mon, 15 Apr 2013 12:24:32 -0700 (PDT) Received: by mail-gh0-f181.google.com with SMTP id 3so807113ghz.40 for ; Mon, 15 Apr 2013 12:24:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=SbYrx/l+6qjnnvjsqvRvlX6Rv4fINZSPv+Jiexv3qnc=; b=gzHru9OY9fkZ14ozsV2Si6oqos61KinKsRuLX59teGx4kveep7PPj19kpj/4Tx6g7W ZSLGubj+cqRKIF/xWt8zOWcEr4MWC2VqpZHvViEGmWXx9tfna5UjVVkDMfvun2zMGtOa kcE6ldJOZD0bTeCQwkiHpcY7TglOkUluLNVapSqSPblRqim75ZvudpcEA1wQVO3A2aEW XGXm6igem6rab2yQQ4nMrGnKmvlo8sH6+r4ATv13NybHB7nFreKoAzdDkHYs1lBudTtr Ap7Zgw35fjYIGfCBaN1VgEcP3Wb/vOsa6cytcxLbOusBAJm7bYHFLXadkVWXRs0TwHX1 eBiQ== X-Received: by 10.236.197.103 with SMTP id s67mr12395622yhn.201.1366053869461; Mon, 15 Apr 2013 12:24:29 -0700 (PDT) Received: from [192.168.1.39] (190-20-46-232.baf.movistar.cl. [190.20.46.232]) by mx.google.com with ESMTPS id o43sm13271408yhm.11.2013.04.15.12.24.17 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 15 Apr 2013 12:24:28 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_355AB1A4-0D70-408D-93FC-66F78D6C180B"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: John Bradley In-Reply-To: <4E1F6AAD24975D4BA5B168042967394367641FAB@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Mon, 15 Apr 2013 16:24:05 -0300 Message-Id: References: <255B9BB34FB7D647A506DC292726F6E1150C74DADA@WSMSG3153V.srv.dir.telstra.com> <516C069F.9090308@mitre.org> <516C0B9D.6000402@mitre.org> <516C101F.2090706@mitre.org> <516C1714.8070503@mitre.org> <4E1F6AAD24975D4BA5B168042967394367641A87@TK5EX14MBXC283.redmond.corp.microsoft.com> <516C3152.9070603@mitre.org> <4E1F6AAD24975D4BA5B168042967394367641FAB@TK5EX14MBXC283.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQlfxV7wj+UTEa/0jtNs0JIdKS9a8GSbgXLZLsP6Cei0H2W5zWPsO9lvZBDznXjf45uzs/8i Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Registration: Scope Values X-BeenThere: oauth@ietf.org X-Mailman-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, 15 Apr 2013 19:24:54 -0000 --Apple-Mail=_355AB1A4-0D70-408D-93FC-66F78D6C180B Content-Type: multipart/alternative; boundary="Apple-Mail=_A25D2E5E-8DC6-4222-9DA9-0922B02B22F6" --Apple-Mail=_A25D2E5E-8DC6-4222-9DA9-0922B02B22F6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I think the below is a bit clearer than the existing language. I can = live with either. John B. On 2013-04-15, at 2:29 PM, Mike Jones = wrote: > We could fix the one-sided language by changing > =93Space separated list of scope values (as described in OAuth = 2.0Section 3.3 [RFC6749]) that the client is declaring that it may use = when requesting access tokens.=94 > to > =93Space separated list of scope values (as described in OAuth = 2.0Section 3.3 [RFC6749]) that the client is declaring to the server = that it may use when requesting access tokens and that the server is = declaring to the client that it is registered to use when requesting = access tokens.=94. > =20 > Again, I chose the =93registered to use=94 language carefully =96 = because in the general case it=92s not a restriction on the values that = the client can use =96 just a statement by the server to the client that = it is registered to use those particular values. In both cases, the = parties are making declarations to one another. > =20 > If you adopt that language (or keep the original language), then yes, = I=92d consider this closed. > =20 > -- Mike > =20 > From: Justin Richer [mailto:jricher@mitre.org]=20 > Sent: Monday, April 15, 2013 9:57 AM > To: Mike Jones > Cc: Tim Bray; oauth@ietf.org > Subject: Re: [OAUTH-WG] Registration: Scope Values > =20 > I absolutely do not want to delete this feature, as (having = implemented it) I think it's very useful. This is a very established = pattern in manual registration: I know of many, many OAuth2 servers and = clients that are set up where the client must pre-register a set of = scopes.=20 >=20 > I don't like the language of "the client is declaring" because it's = too one-sided. The client might not have declared anything, and it might = be the server that's declaring something to the client. Deleting the "is = declaring" bit removes that unintended restriction of the language while = keeping the original meaning intact. I actually thought that I had fixed = that before the last draft went in but apparently I missed this one. >=20 > I will work on clarifying the intent of the whole metadata set in its = introductory paragraph(s) so that it's clear that all of these fields = are used in both of these situations: >=20 > 1) The client declaring to the server its desire to use a particular = value > 2) The server declaring to the client that it has been registered = with a particular value >=20 > This should hopefully clear up the issue in the editor's note that I = currently have at the top of that section right now, too. >=20 > Mike, since you were the one who originally brought up the issue, and = you're fine with the existing text, can I take this as closed now? = Assuming that you agree with deleting "is declaring" for reasons stated = above, I'm fine with leaving everything else as is and staying quiet on = what the server has to do with the scopes. >=20 > -- Justin >=20 >=20 > On 04/15/2013 12:44 PM, Mike Jones wrote: > I think that the existing wording is superior to the proposed changed = wording. The existing wording is: > =20 > scope > OPTIONAL. Space separated list of scope values (as described in > OAuth 2.0 Section 3.3 [RFC6749]) that the client is declaring = that > it may use when requesting access tokens. If omitted, an > Authorization Server MAY register a Client with a default set of > scopes. > =20 > For instance, the current =93client is declaring=94 wording will = always be correct, whereas as the change to =93client can use=94 wording = implies a restriction on client behavior that is not always applicable. = The =93client is declaring=94 wording was specific and purposefully = chosen, and I think should be retained. In particular, we can=92t do = anything that implies that only the registered scopes values can be = used. At the OAuth spec level, this is a hint as to possible future = client behavior =96 not a restriction on future client behavior. > =20 > Also, for the reasons that Tim stated, I=92m strongly against any = =93matching=94 or =93regex=94 language in the spec pertaining to scopes = =96 as it=92s not actionable. > =20 > So I=92d propose that we leave the existing scope wording in place. = Alternatively, I=92d also be fine with deleting this feature entirely, = as I don=92t think it=92s useful in the general case. > =20 > -- Mike > =20 > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf = Of Justin Richer > Sent: Monday, April 15, 2013 8:05 AM > To: Tim Bray; oauth@ietf.org > Subject: Re: [OAUTH-WG] Registration: Scope Values > =20 > On 04/15/2013 10:52 AM, Tim Bray wrote: >=20 >=20 > I=92d use the existing wording; it=92s perfectly clear. Failing that, = if there=92s strong demand for registration of structured scopes, bless = the use of regexes, either PCREs or some careful subset. >=20 > Thanks for the feedback -- Of these two choices, I'd rather leave it = as-is.=20 >=20 >=20 >=20 > =20 > However, I=92d subtract the sentence =93If omitted, an Authorization = Server MAY register a Client with a default set of scopes.=94 It adds = no value; if the client doesn=92t declare scopes, the client doesn=92t = declare scopes, that=92s all. -T >=20 > Remember, all of these fields aren't just for the client *request*, = they're also for the server's *response* to either a POST, PUT, or GET = request. (I didn't realize it, but perhaps the wording as stated right = now doesn't make that clear -- I need to fix that.) The value that it = adds is if the client doesn't ask for any particular scopes, the server = can still assign it scopes and the client can do something smart with = that. Dumb clients are allowed to ignore it if it doesn't mean anything = to them.=20 >=20 > This is how our server implementation actually works right now. If the = client doesn't ask for anything specific at registration, the server = hands it a bag of "default" scopes. Same thing happens at auth time -- = if the client doesn't ask for any particular scopes, the server hands it = all of its registered scopes as a default. Granted, on our server, = scopes are just simple strings right now, so they get compared at the = auth endpoint with an exact string-match metric and set-based logic.=20 >=20 > -- Justin >=20 >=20 >=20 > =20 >=20 > On Mon, Apr 15, 2013 at 7:35 AM, Justin Richer = wrote: > What would you suggest for wording here, then? Keeping in mind that we = cannot (and don't want to) prohibit expression-based scopes.=20 >=20 > -- Justin > =20 >=20 > On 04/15/2013 10:33 AM, Tim Bray wrote: > No, I mean it=92s not interoperable at the software-developer level. = I can=92t register scopes at authorization time with any predictable = effect that I can write code to support, either client or server side, = without out-of-line non-interoperable knowledge about the behavior of = the server. =20 > =20 > I guess I=92m just not used to OAuth=92s culture of having no = expectation that things will be specified tightly enough that I can = write code to implement as specified. -T > =20 >=20 > On Mon, Apr 15, 2013 at 7:15 AM, Justin Richer = wrote: > Scopes aren't meant to be interoperable between services since they're = necessarily API-specific. The only interoperable bit is that there's = *some* place to put the values and that it's expressed as a bag of = space-separated strings. How those strings get interpreted and enforced = (which is really what's at stake here) is up to the AS and PR (or a = higher-level protocol like UMA). >=20 > -- Justin > =20 >=20 > On 04/15/2013 10:13 AM, Tim Bray wrote: > This, as written, has zero interoperability. I think this feature can = really only be made useful in the case where scopes are fixed strings. >=20 > -T >=20 > On Apr 15, 2013 6:54 AM, "Justin Richer" wrote: > You are correct that the idea behind the "scope" parameter at = registration is a constraint on authorization-time scopes that are made = available. It's both a means for the client to request a set of valid = scopes and for the server to provision (and echo back to the client) a = set of valid scopes. >=20 > I *really* don't want to try to define a matching language for scope = expressions. For that to work, all servers would need to be able to = process the regular expressions for all clients, even if the servers = themselves only support simple-string scope values. Any regular = expression syntax we pick here is guaranteed to be incompatible with = something, and I think the complexity doesn't buy much. Also, I think = you suddenly have a potential security issue if you have a bad regex in = place on either end.=20 >=20 > As it stands today, the server can interpret the incoming registration = scopes and enforce them however it wants to. The real trick comes not = from assigning the values to a particular client but to enforcing them, = and I think that's always going to be service-specific. We're just not = as clear on that as we could be. >=20 > After looking over everyone's comments so far, I'd like to propose the = following text for that section: >=20 >=20 >=20 > scope > OPTIONAL. Space separated list of scope values (as described in > OAuth 2.0 Section 3.3 [RFC6749]) that the client can use when=20 > requesting access tokens. As scope values are service-specific,=20= > the Authorization Server MAY define its own matching rules when > determining if a scope value used during an authorization = request > is valid according to the scope values assigned during=20 > registration. Possible matching rules include wildcard patterns, > regular expressions, or exactly matching the string. If omitted,=20= > an Authorization Server MAY register a Client with a default=20 > set of scopes. >=20 > Comments? Improvements? >=20 > -- Justin >=20 >=20 >=20 > On 04/14/2013 08:23 PM, Manger, James H wrote: > Presumably at app registration time any scope specification is really = a constraint on the scope values that can be requested in an = authorization flow. > =20 > So ideally registration should accept rules for matching scopes, as = opposed to actual scope values. > =20 > You can try to use scope values as their own matching rules. That is = fine for a small set of "static" scopes. It starts to fail when there = are a large number of scopes, or scopes that can include parameters = (resource paths? email addresses?). You can try to patch those failures = by allowing services to define service-specific special "wildcard" scope = values that can only be used during registration (eg "read:*"). > =20 > Alternatively, replace 'scope' in registration with 'scope_regex' that = holds a regular expression that all scope values in an authorization = flow must match. > =20 > -- > James Manger > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > =20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 > =20 > =20 > =20 > =20 > =20 > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_A25D2E5E-8DC6-4222-9DA9-0922B02B22F6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I think the below is a bit = clearer than the existing language.    I can live with = either.

John B.

On = 2013-04-15, at 2:29 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

We could = fix the one-sided language by changing
=93Space separated list of scope values = (as described in OAuth 2.0Section 3.3 [RFC6749]) = that the client is declaring that it may use when requesting access = tokens.=94
Space separated list of scope values (as described = in OAuth 2.0Section 3.3 = [RFC6749]) that the client is declaring to the server that it may = use when requesting access tokens and that the server is declaring to = the client that it is registered to use when requesting access = tokens.=94.
Again, I chose the =93registered to use=94 = language carefully =96 because in the general case it=92s not a = restriction on the values that the client can use =96 just a statement = by the server to the client that it is registered to use those = particular values.  In both cases, the parties are making = declarations to one another.
If you adopt that language (or keep the = original language), then yes, I=92d consider this = closed.
 
From: Justin Richer = [mailto:jricher@mitre.org] 
Sent: Monday, April 15, 2013 9:57 = AM
To: Mike = Jones
Cc: Tim = Bray; oauth@ietf.org
Subject: Re: [OAUTH-WG] = Registration: Scope Values
 

I absolutely do not want to delete this feature, as = (having implemented it) I think it's very useful. This is a very = established pattern in manual registration: I know of many, many OAuth2 = servers and clients that are set up where the client must pre-register a = set of scopes. 

I= don't like the language of "the client is declaring" because it's too = one-sided. The client might not have declared anything, and it might be = the server that's declaring something to the client. Deleting the "is = declaring" bit removes that unintended restriction of the language while = keeping the original meaning intact. I actually thought that I had fixed = that before the last draft went in but apparently I missed this = one.

I will work on clarifying the intent of the whole metadata = set in its introductory paragraph(s) so that it's clear that all of = these fields are used in both of these situations:

 1) The = client declaring to the server its desire to use a particular = value
 2) The server declaring to the client that it has been = registered with a particular value

This should hopefully clear up = the issue in the editor's note that I currently have at the top of that = section right now, too.

Mike, since you were the one who = originally brought up the issue, and you're fine with the existing text, = can I take this as closed now? Assuming that you agree with deleting "is = declaring" for reasons stated above, I'm fine with leaving everything = else as is and staying quiet on what the server has to do with the = scopes.

 -- Justin

On 04/15/2013 12:44 PM, Mike Jones = wrote:
I = think that the existing wording is superior to the proposed changed = wording.  The existing wording is:
   = scope
      = OPTIONAL.  Space separated list of scope values (as described = in
      OAuth = 2.0 Section 3.3 [RFC6749]) = that the client is declaring that
For = instance, the current =93client is declaring=94 wording will always be = correct, whereas as the change to =93client can use=94 wording implies a = restriction on client behavior that is not always applicable.  The = =93client is declaring=94 wording was specific and purposefully chosen, = and I think should be retained.  In particular, we can=92t do = anything that implies that only the registered scopes values can be = used.  At the OAuth spec level, this is a hint as to possible = future client behavior =96 not a restriction on future client = behavior.
Also, for = the reasons that Tim stated, I=92m strongly against any =93matching=94 = or =93regex=94 language in the spec pertaining to scopes =96 as it=92s = not actionable.
So I=92d = propose that we leave the existing scope wording in place.  = Alternatively, I=92d also be fine with deleting this feature entirely, = as I don=92t think it=92s useful in the general = case.
 
 
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Justin = Richer
Sent: Monday, April 15, 2013 8:05 = AM
To: Tim = Bray; oauth@ietf.org
Subject: Re: [OAUTH-WG] = Registration: Scope Values
 
I=92d = use the existing wording; it=92s perfectly clear.  Failing that, if = there=92s strong demand for registration of structured scopes, bless the = use of regexes, either PCREs or some careful = subset.

Thanks for = the feedback -- Of these two choices, I'd rather leave it as-is. 



 

This is how our = server implementation actually works right now. If the client doesn't = ask for anything specific at registration, the server hands it a bag of = "default" scopes. Same thing happens at auth time -- if the client = doesn't ask for any particular scopes, the server hands it all of its = registered scopes as a default. Granted, on our server, scopes are just = simple strings right now, so they get compared at the auth endpoint with = an exact string-match metric and set-based logic. 

 -- = Justin



 

On = Mon, Apr 15, 2013 at 7:35 AM, Justin Richer <jricher@mitre.org> = wrote:
What would you = suggest for wording here, then? Keeping in mind that we cannot (and = don't want to) prohibit expression-based scopes. 

 -- = Justin

 

On = 04/15/2013 10:33 AM, Tim Bray wrote:
No, I mean it=92s not interoperable at the software-developer = level.  I can=92t register scopes at authorization time with any = predictable effect that I can write code to support, either client or = server side, without out-of-line non-interoperable knowledge about the = behavior of the server.  
 
I = guess I=92m just not used to OAuth=92s culture of having no expectation = that things will be specified tightly enough that I can write code to = implement as specified.  -T

 

On Mon, Apr 15, 2013 at 7:15 AM, Justin Richer = <jricher@mitre.org> = wrote:
Scopes aren't = meant to be interoperable between services since they're necessarily = API-specific. The only interoperable bit is that there's *some* place to = put the values and that it's expressed as a bag of space-separated = strings. How those strings get interpreted and enforced (which is really = what's at stake here) is up to the AS and PR (or a higher-level protocol = like UMA).

 -- = Justin

On 04/15/2013 = 10:13 AM, Tim Bray wrote:

This, as written, has zero interoperability.  I think this = feature can really only be made useful in the case where scopes are = fixed strings.

On Apr 15, = 2013 6:54 AM, "Justin Richer" <You are correct that the idea = behind the "scope" parameter at registration is a constraint on = authorization-time scopes that are made available. It's both a means for = the client to request a set of valid scopes and for the server to = provision (and echo back to the client) a set of valid scopes.

I = *really* don't want to try to define a matching language for scope = expressions. For that to work, all servers would need to be able to = process the regular expressions for all clients, even if the servers = themselves only support simple-string scope values. Any regular = expression syntax we pick here is guaranteed to be incompatible with = something, and I think the complexity doesn't buy much. Also, I think = you suddenly have a potential security issue if you have a bad regex in = place on either end. 

As it stands today, = the server can interpret the incoming registration scopes and enforce = them however it wants to. The real trick comes not from assigning the = values to a particular client but to enforcing them, and I think that's = always going to be service-specific. We're just not as clear on that as = we could be.

After looking over everyone's comments so far, I'd = like to propose the following text for that = section:


   =
scope
      =
OPTIONAL.  Space separated list of scope values (as described =
in
      OAuth =
2.0 
Comments? =
Improvements?

 -- Justin


On 04/14/2013 08:23 PM, Manger, James H =
wrote:
Presumably at app registration time =
any scope specification is really a constraint on the scope values that =
can be requested in an authorization flow.
 
So ideally =
registration should accept rules for matching scopes, as opposed to =
actual scope values.
You can try to use scope =
values as their own matching rules. That is fine for a small set of =
"static" scopes. It starts to fail when there are a large number of =
scopes, or scopes that can include parameters (resource paths? email =
addresses?). You can try to patch those failures by allowing services to =
define service-specific special "wildcard" scope values that can only be =
used during registration (eg "read:*").
 
Alternatively, =
replace 'scope' in registration with 'scope_regex' that holds a regular =
expression that all scope values in an authorization flow must =
match.
--
James Manger
OAuth mailing list
OAuth@ietf.org
 

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


= --Apple-Mail=_A25D2E5E-8DC6-4222-9DA9-0922B02B22F6-- --Apple-Mail=_355AB1A4-0D70-408D-93FC-66F78D6C180B Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNDE1MTkyNDA1WjAjBgkqhkiG9w0BCQQxFgQUta2S2noD COWeTB1TkhPbQu2cwb8wgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAaeBYuW/dEaebu7f8F+pELMMz6GPTELHe90eMNH2i C2n98x+dI54E/lM+ZaD1EjqzEFL04ADOJD5cOPK9bSPo/TN8DEgjyud7A0axEugpbsSp/0cM8REG pLyIVcgQZ784R0ozJhknAaqjGYPjkVQkO6QSv+4t3FcMszbTBq/hONHrGXvGCpAnoBJS9FzHRZw5 FApH1FLVS969VIM2rVz0M1yCi7XmQn8mRDbjxxqds0NaktoBGDjgEGJ4UburAhBnI+A+GWZuL3s8 i7MJiq8at2YcmESzPMRsx/zle1KhKoNcH8A8a2KXuCib+8aJGuyJ/QS6I3TuAQeO/TNWCtxzzQAA AAAAAA== --Apple-Mail=_355AB1A4-0D70-408D-93FC-66F78D6C180B-- From jricher@mitre.org Mon Apr 15 12:29:02 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EE6721F944A for ; Mon, 15 Apr 2013 12:29:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DEInyRQVke9q for ; Mon, 15 Apr 2013 12:29:00 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id C5F5221F940C for ; Mon, 15 Apr 2013 12:28:59 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 69A841F07CA; Mon, 15 Apr 2013 15:28:59 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 4F55F1F069A; Mon, 15 Apr 2013 15:28:59 -0400 (EDT) Received: from [10.146.15.29] (129.83.31.58) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.342.3; Mon, 15 Apr 2013 15:28:58 -0400 Message-ID: <516C54F2.8040708@mitre.org> Date: Mon, 15 Apr 2013 15:28:50 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: Mike Jones References: <255B9BB34FB7D647A506DC292726F6E1150C74DADA@WSMSG3153V.srv.dir.telstra.com> <516C069F.9090308@mitre.org> <516C0B9D.6000402@mitre.org> <516C101F.2090706@mitre.org> <516C1714.8070503@mitre.org> <4E1F6AAD24975D4BA5B168042967394367641A87@TK5EX14MBXC283.redmond.corp.microsoft.com> <516C3152.9070603@mitre.org> <4E1F6AAD24975D4BA5B168042967394367641FAB@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394367641FAB@TK5EX14MBXC283.redmond.corp.microsoft.com> Content-Type: multipart/alternative; boundary="------------080503000000080807060703" X-Originating-IP: [129.83.31.58] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Registration: Scope Values X-BeenThere: oauth@ietf.org X-Mailman-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, 15 Apr 2013 19:29:02 -0000 --------------080503000000080807060703 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit I think that because the "declaration" issue affects all parameters in the list, not just scope, we should adopt this in a higher level paragraph and leave it out of the individual parameter descriptions. Thus, something like this inserted as the second paragraph in section 2: The client metadata values serve two parallel purposes in the overall OAuth Dynamic Registration protocol: - the Client requesting its desired values for each parameter to the Authorization Server in a [register] or [update] request, - the Authorization Server informing the Client of the current values of each parameter that the Client has been registered to use through a [client information response]. An Authorization Server MAY override any value that a Client requests during the registration process (including any omitted values) and replace the requested value with a default. The normative indications in the following list apply to the Client's declaration of its desired values. The Authorization Server SHOULD provide documentation for any fields that it requires to be filled in by the client or to have particular values or formats. Extensions and profiles... And then remove the sidedness-language from the scope parameter and any other parameters where it might have crept in inadvertently. -- Justin On 04/15/2013 01:29 PM, Mike Jones wrote: > > We could fix the one-sided language by changing > > “Space separated list of scope values (as described in OAuth 2.0 > Section 3.3 [RFC6749] > ) that the client is > declaring that it may use when requesting access tokens.” > > to > > “Space separated list of scope values (as described in OAuth 2.0 > Section 3.3 [RFC6749] > ) that the client is > declaring to the server that it may use when requesting access tokens > and that the server is declaring to the client that it is registered > to use when requesting access tokens.”. > > Again, I chose the “registered to use” language carefully – because in > the general case it’s not a restriction on the values that the client > can use – just a statement by the server to the client that it is > registered to use those particular values. In both cases, the parties > are making declarations to one another. > > If you adopt that language (or keep the original language), then yes, > I’d consider this closed. > > -- Mike > > *From:*Justin Richer [mailto:jricher@mitre.org] > *Sent:* Monday, April 15, 2013 9:57 AM > *To:* Mike Jones > *Cc:* Tim Bray; oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Registration: Scope Values > > I absolutely do not want to delete this feature, as (having > implemented it) I think it's very useful. This is a very established > pattern in manual registration: I know of many, many OAuth2 servers > and clients that are set up where the client must pre-register a set > of scopes. > > I don't like the language of "the client is declaring" because it's > too one-sided. The client might not have declared anything, and it > might be the server that's declaring something to the client. Deleting > the "is declaring" bit removes that unintended restriction of the > language while keeping the original meaning intact. I actually thought > that I had fixed that before the last draft went in but apparently I > missed this one. > > I will work on clarifying the intent of the whole metadata set in its > introductory paragraph(s) so that it's clear that all of these fields > are used in both of these situations: > > 1) The client declaring to the server its desire to use a particular > value > 2) The server declaring to the client that it has been registered > with a particular value > > This should hopefully clear up the issue in the editor's note that I > currently have at the top of that section right now, too. > > Mike, since you were the one who originally brought up the issue, and > you're fine with the existing text, can I take this as closed now? > Assuming that you agree with deleting "is declaring" for reasons > stated above, I'm fine with leaving everything else as is and staying > quiet on what the server has to do with the scopes. > > -- Justin > > On 04/15/2013 12:44 PM, Mike Jones wrote: > > I think that the existing wording is superior to the proposed > changed wording. The existing wording is: > > scope > > OPTIONAL. Space separated list of scope values (as described in > > OAuth 2.0 Section 3.3 [RFC6749] > ) that the client > is declaring that > > it may use when requesting access tokens. If omitted, an > > Authorization Server MAY register a Client with a default set of > > scopes. > > For instance, the current “client is declaring” wording will > always be correct, whereas as the change to “client can use” > wording implies a restriction on client behavior that is not > always applicable. The “client is declaring” wording was specific > and purposefully chosen, and I think should be retained. In > particular, we can’t do anything that implies that only the > registered scopes values can be used. At the OAuth spec level, > this is a hint as to possible future client behavior – not a > restriction on future client behavior. > > Also, for the reasons that Tim stated, I’m strongly against any > “matching” or “regex” language in the spec pertaining to scopes – > as it’s not actionable. > > So I’d propose that we leave the existing scope wording in place. > Alternatively, I’d also be fine with deleting this feature > entirely, as I don’t think it’s useful in the general case. > > -- Mike > > *From:*oauth-bounces@ietf.org > [mailto:oauth-bounces@ietf.org] *On Behalf Of *Justin Richer > *Sent:* Monday, April 15, 2013 8:05 AM > *To:* Tim Bray; oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Registration: Scope Values > > On 04/15/2013 10:52 AM, Tim Bray wrote: > > > I’d use the existing wording; it’s perfectly clear. Failing that, > if there’s strong demand for registration of structured scopes, > bless the use of regexes, either PCREs or some careful subset. > > > Thanks for the feedback -- Of these two choices, I'd rather leave > it as-is. > > > > However, I’d subtract the sentence “If omitted, an Authorization > Server MAY register a Client with a default set of scopes.” It > adds no value; if the client doesn’t declare scopes, the client > doesn’t declare scopes, that’s all. -T > > > Remember, all of these fields aren't just for the client > *request*, they're also for the server's *response* to either a > POST, PUT, or GET request. (I didn't realize it, but perhaps the > wording as stated right now doesn't make that clear -- I need to > fix that.) The value that it adds is if the client doesn't ask for > any particular scopes, the server can still assign it scopes and > the client can do something smart with that. Dumb clients are > allowed to ignore it if it doesn't mean anything to them. > > This is how our server implementation actually works right now. If > the client doesn't ask for anything specific at registration, the > server hands it a bag of "default" scopes. Same thing happens at > auth time -- if the client doesn't ask for any particular scopes, > the server hands it all of its registered scopes as a default. > Granted, on our server, scopes are just simple strings right now, > so they get compared at the auth endpoint with an exact > string-match metric and set-based logic. > > -- Justin > > > > On Mon, Apr 15, 2013 at 7:35 AM, Justin Richer > wrote: > > What would you suggest for wording here, then? Keeping in mind > that we cannot (and don't want to) prohibit expression-based scopes. > > -- Justin > > On 04/15/2013 10:33 AM, Tim Bray wrote: > > No, I mean it’s not interoperable at the software-developer > level. I can’t register scopes at authorization time with any > predictable effect that I can write code to support, either > client or server side, without out-of-line non-interoperable > knowledge about the behavior of the server. > > I guess I’m just not used to OAuth’s culture of having no > expectation that things will be specified tightly enough that > I can write code to implement as specified. -T > > On Mon, Apr 15, 2013 at 7:15 AM, Justin Richer > > wrote: > > Scopes aren't meant to be interoperable between services since > they're necessarily API-specific. The only interoperable bit > is that there's *some* place to put the values and that it's > expressed as a bag of space-separated strings. How those > strings get interpreted and enforced (which is really what's > at stake here) is up to the AS and PR (or a higher-level > protocol like UMA). > > -- Justin > > On 04/15/2013 10:13 AM, Tim Bray wrote: > > This, as written, has zero interoperability. I think this > feature can really only be made useful in the case where > scopes are fixed strings. > > -T > > On Apr 15, 2013 6:54 AM, "Justin Richer" > > wrote: > > You are correct that the idea behind the "scope" parameter > at registration is a constraint on authorization-time > scopes that are made available. It's both a means for the > client to request a set of valid scopes and for the server > to provision (and echo back to the client) a set of valid > scopes. > > I *really* don't want to try to define a matching language > for scope expressions. For that to work, all servers would > need to be able to process the regular expressions for all > clients, even if the servers themselves only support > simple-string scope values. Any regular expression syntax > we pick here is guaranteed to be incompatible with > something, and I think the complexity doesn't buy much. > Also, I think you suddenly have a potential security issue > if you have a bad regex in place on either end. > > As it stands today, the server can interpret the incoming > registration scopes and enforce them however it wants to. > The real trick comes not from assigning the values to a > particular client but to enforcing them, and I think > that's always going to be service-specific. We're just not > as clear on that as we could be. > > After looking over everyone's comments so far, I'd like to > propose the following text for that section: > > > scope > > OPTIONAL. Space separated list of scope values (as described in > > OAuth 2.0Section 3.3 [RFC6749] ) that the client can use when > > requesting access tokens. As scope values are service-specific, > > the Authorization Server MAY define its own matching rules when > > determining if a scope value used during an authorization request > > is valid according to the scope values assigned during > > registration. Possible matching rules include wildcard patterns, > > regular expressions, or exactly matching the string. If omitted, > > an Authorization Server MAY register a Client with a default > > set of scopes. > > > Comments? Improvements? > > -- Justin > > > On 04/14/2013 08:23 PM, Manger, James H wrote: > > Presumably at app registration time any scope specification is really a constraint on the scope values that can be requested in an authorization flow. > > > > So ideally registration should accept rules for matching scopes, as opposed to actual scope values. > > > > You can try to use scope values as their own matching rules. That is fine for a small set of "static" scopes. It starts to fail when there are a large number of scopes, or scopes that can include parameters (resource paths? email addresses?). You can try to patch those failures by allowing services to define service-specific special "wildcard" scope values that can only be used during registration (eg "read:*"). > > > > Alternatively, replace 'scope' in registration with 'scope_regex' that holds a regular expression that all scope values in an authorization flow must match. > > > > -- > > James Manger > > _______________________________________________ > > 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 > --------------080503000000080807060703 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit I think that because the "declaration" issue affects all parameters in the list, not just scope, we should adopt this in a higher level paragraph and leave it out of the individual parameter descriptions. Thus, something like this inserted as the second paragraph in section 2:

The client metadata values serve two parallel purposes in the overall OAuth Dynamic Registration protocol:

 - the Client requesting its desired values for each parameter to the Authorization Server in a [register] or [update] request,
 - the Authorization Server informing the Client of the current values of each parameter that the Client has been registered to use through a [client information response].

An Authorization Server MAY override any value that a Client requests during the registration process (including any omitted values) and replace the requested value with a default. The normative indications in the following list apply to the Client's declaration of its desired values.

The Authorization Server SHOULD provide documentation for any fields that it requires to be filled in by the client or to have particular values or formats. Extensions and profiles...

And then remove the sidedness-language from the scope parameter and any other parameters where it might have crept in inadvertently.

 -- Justin

On 04/15/2013 01:29 PM, Mike Jones wrote:

We could fix the one-sided language by changing

“Space separated list of scope values (as described in OAuth 2.0 Section 3.3 [RFC6749]) that the client is declaring that it may use when requesting access tokens.”

to

“Space separated list of scope values (as described in OAuth 2.0 Section 3.3 [RFC6749]) that the client is declaring to the server that it may use when requesting access tokens and that the server is declaring to the client that it is registered to use when requesting access tokens.”.

 

Again, I chose the “registered to use” language carefully – because in the general case it’s not a restriction on the values that the client can use – just a statement by the server to the client that it is registered to use those particular values.  In both cases, the parties are making declarations to one another.

 

If you adopt that language (or keep the original language), then yes, I’d consider this closed.

 

                                                            -- Mike

 

From: Justin Richer [mailto:jricher@mitre.org]
Sent: Monday, April 15, 2013 9:57 AM
To: Mike Jones
Cc: Tim Bray; oauth@ietf.org
Subject: Re: [OAUTH-WG] Registration: Scope Values

 

I absolutely do not want to delete this feature, as (having implemented it) I think it's very useful. This is a very established pattern in manual registration: I know of many, many OAuth2 servers and clients that are set up where the client must pre-register a set of scopes.

I don't like the language of "the client is declaring" because it's too one-sided. The client might not have declared anything, and it might be the server that's declaring something to the client. Deleting the "is declaring" bit removes that unintended restriction of the language while keeping the original meaning intact. I actually thought that I had fixed that before the last draft went in but apparently I missed this one.

I will work on clarifying the intent of the whole metadata set in its introductory paragraph(s) so that it's clear that all of these fields are used in both of these situations:

 1) The client declaring to the server its desire to use a particular value
 2) The server declaring to the client that it has been registered with a particular value

This should hopefully clear up the issue in the editor's note that I currently have at the top of that section right now, too.

Mike, since you were the one who originally brought up the issue, and you're fine with the existing text, can I take this as closed now? Assuming that you agree with deleting "is declaring" for reasons stated above, I'm fine with leaving everything else as is and staying quiet on what the server has to do with the scopes.

 -- Justin

On 04/15/2013 12:44 PM, Mike Jones wrote:

I think that the existing wording is superior to the proposed changed wording.  The existing wording is:

 

   scope

      OPTIONAL.  Space separated list of scope values (as described in

      OAuth 2.0 Section 3.3 [RFC6749]) that the client is declaring that

      it may use when requesting access tokens.  If omitted, an

      Authorization Server MAY register a Client with a default set of

      scopes.

 

For instance, the current “client is declaring” wording will always be correct, whereas as the change to “client can use” wording implies a restriction on client behavior that is not always applicable.  The “client is declaring” wording was specific and purposefully chosen, and I think should be retained.  In particular, we can’t do anything that implies that only the registered scopes values can be used.  At the OAuth spec level, this is a hint as to possible future client behavior – not a restriction on future client behavior.

 

Also, for the reasons that Tim stated, I’m strongly against any “matching” or “regex” language in the spec pertaining to scopes – as it’s not actionable.

 

So I’d propose that we leave the existing scope wording in place.  Alternatively, I’d also be fine with deleting this feature entirely, as I don’t think it’s useful in the general case.

 

                                                            -- Mike

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Justin Richer
Sent: Monday, April 15, 2013 8:05 AM
To: Tim Bray; oauth@ietf.org
Subject: Re: [OAUTH-WG] Registration: Scope Values

 

On 04/15/2013 10:52 AM, Tim Bray wrote:


I’d use the existing wording; it’s perfectly clear.  Failing that, if there’s strong demand for registration of structured scopes, bless the use of regexes, either PCREs or some careful subset.


Thanks for the feedback -- Of these two choices, I'd rather leave it as-is.



 

However, I’d subtract the sentence “If omitted, an Authorization Server MAY register a Client with a default set of  scopes.”  It adds no value; if the client doesn’t declare scopes, the client doesn’t declare scopes, that’s all.  -T


Remember, all of these fields aren't just for the client *request*, they're also for the server's *response* to either a POST, PUT, or GET request. (I didn't realize it, but perhaps the wording as stated right now doesn't make that clear -- I need to fix that.) The value that it adds is if the client doesn't ask for any particular scopes, the server can still assign it scopes and the client can do something smart with that. Dumb clients are allowed to ignore it if it doesn't mean anything to them.

This is how our server implementation actually works right now. If the client doesn't ask for anything specific at registration, the server hands it a bag of "default" scopes. Same thing happens at auth time -- if the client doesn't ask for any particular scopes, the server hands it all of its registered scopes as a default. Granted, on our server, scopes are just simple strings right now, so they get compared at the auth endpoint with an exact string-match metric and set-based logic.

 -- Justin



 

On Mon, Apr 15, 2013 at 7:35 AM, Justin Richer <jricher@mitre.org> wrote:

What would you suggest for wording here, then? Keeping in mind that we cannot (and don't want to) prohibit expression-based scopes.

 -- Justin

 

On 04/15/2013 10:33 AM, Tim Bray wrote:

No, I mean it’s not interoperable at the software-developer level.  I can’t register scopes at authorization time with any predictable effect that I can write code to support, either client or server side, without out-of-line non-interoperable knowledge about the behavior of the server.  

 

I guess I’m just not used to OAuth’s culture of having no expectation that things will be specified tightly enough that I can write code to implement as specified.  -T

 

On Mon, Apr 15, 2013 at 7:15 AM, Justin Richer <jricher@mitre.org> wrote:

Scopes aren't meant to be interoperable between services since they're necessarily API-specific. The only interoperable bit is that there's *some* place to put the values and that it's expressed as a bag of space-separated strings. How those strings get interpreted and enforced (which is really what's at stake here) is up to the AS and PR (or a higher-level protocol like UMA).

 -- Justin

 

On 04/15/2013 10:13 AM, Tim Bray wrote:

This, as written, has zero interoperability.  I think this feature can really only be made useful in the case where scopes are fixed strings.

-T

On Apr 15, 2013 6:54 AM, "Justin Richer" <jricher@mitre.org> wrote:

You are correct that the idea behind the "scope" parameter at registration is a constraint on authorization-time scopes that are made available. It's both a means for the client to request a set of valid scopes and for the server to provision (and echo back to the client) a set of valid scopes.

I *really* don't want to try to define a matching language for scope expressions. For that to work, all servers would need to be able to process the regular expressions for all clients, even if the servers themselves only support simple-string scope values. Any regular expression syntax we pick here is guaranteed to be incompatible with something, and I think the complexity doesn't buy much. Also, I think you suddenly have a potential security issue if you have a bad regex in place on either end.

As it stands today, the server can interpret the incoming registration scopes and enforce them however it wants to. The real trick comes not from assigning the values to a particular client but to enforcing them, and I think that's always going to be service-specific. We're just not as clear on that as we could be.

After looking over everyone's comments so far, I'd like to propose the following text for that section:


   scope
      OPTIONAL.  Space separated list of scope values (as described in
      OAuth 2.0 Section 3.3 [RFC6749]) that the client can use when 
      requesting access tokens.  As scope values are service-specific, 
      the Authorization Server MAY define its own matching rules when
      determining if a scope value used during an authorization request
      is valid according to the scope values assigned during 
      registration. Possible matching rules include wildcard patterns,
      regular expressions, or exactly matching the string. If omitted, 
      an Authorization Server MAY register a Client with a default 
      set of scopes.


Comments? Improvements?

 -- Justin


On 04/14/2013 08:23 PM, Manger, James H wrote:

Presumably at app registration time any scope specification is really a constraint on the scope values that can be requested in an authorization flow.
 
So ideally registration should accept rules for matching scopes, as opposed to actual scope values.
 
You can try to use scope values as their own matching rules. That is fine for a small set of "static" scopes. It starts to fail when there are a large number of scopes, or scopes that can include parameters (resource paths? email addresses?). You can try to patch those failures by allowing services to define service-specific special "wildcard" scope values that can only be used during registration (eg "read:*").
 
Alternatively, replace 'scope' in registration with 'scope_regex' that holds a regular expression that all scope values in an authorization flow must match.
 
--
James Manger
_______________________________________________
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

 

 

 

 

 

 


--------------080503000000080807060703-- From internet-drafts@ietf.org Mon Apr 15 13:01:14 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F36B021F93C4; Mon, 15 Apr 2013 13:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.255 X-Spam-Level: X-Spam-Status: No, score=-102.255 tagged_above=-999 required=5 tests=[AWL=0.345, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id btiIKzSxIztn; Mon, 15 Apr 2013 13:01:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DF8BF21F93C6; Mon, 15 Apr 2013 13:01:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p4 Message-ID: <20130415200112.7840.9595.idtracker@ietfa.amsl.com> Date: Mon, 15 Apr 2013 13:01:12 -0700 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-07.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, 15 Apr 2013 20:01:14 -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 Group = of the IETF. Title : Token Revocation Author(s) : Torsten Lodderstedt Stefanie Dronia Marius Scurtescu Filename : draft-ietf-oauth-revocation-07.txt Pages : 10 Date : 2013-04-15 Abstract: This document proposes an additional endpoint for OAuth authorization servers, which allows clients to notify the authorization server that a previously obtained refresh or access token is no longer needed. This allows the authorization server to cleanup security credentials. A revocation request will invalidate the actual token and, if applicable, other tokens based on the same authorization grant. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-revocation There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-revocation-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-revocation-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From torsten@lodderstedt.net Mon Apr 15 13:09:54 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7EBB21F93C6 for ; Mon, 15 Apr 2013 13:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zo7bGbjLmZ6c for ; Mon, 15 Apr 2013 13:09:54 -0700 (PDT) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.94]) by ietfa.amsl.com (Postfix) with ESMTP id ABD4321F9361 for ; Mon, 15 Apr 2013 13:09:53 -0700 (PDT) Received: from [79.253.61.122] (helo=[192.168.71.20]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1URpip-0002Um-Ms; Mon, 15 Apr 2013 22:09:51 +0200 Message-ID: <516C5E8F.1020807@lodderstedt.net> Date: Mon, 15 Apr 2013 22:09:51 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.2; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Stephen Farrell References: <51644F9A.9040402@cs.tcd.ie> In-Reply-To: <51644F9A.9040402@cs.tcd.ie> Content-Type: multipart/alternative; boundary="------------010302010605060704010809" X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-revocation-06 X-BeenThere: oauth@ietf.org X-Mailman-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, 15 Apr 2013 20:09:55 -0000 This is a multi-part message in MIME format. --------------010302010605060704010809 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Stephen, I just posted a new revision of the draft (http://tools.ietf.org/html/draft-ietf-oauth-revocation-07). I tried to address all the issues you raised (see below). Am 09.04.2013 19:27, schrieb Stephen Farrell: > Hi, > > I've done my AD review of this draft. I have two quick questions > I'd like to get answered before I start IETF LC. Depending on the > answers maybe we should re-spin or just fire ahead, let's see... > > (1) 2.1: "upon the return of the request" isn't right is it? I > think you mean the response at least. adjusted wording to "upon receipt of an HTTP 200 response from the server" > And what about HTTP error > handling? What if I get a 503 error? Is the client supposed > to re-send ever? Don't you need to say? Added: If the server responds with HTTP status code 503, the client must assume the token still exists and may retry after a reasonable delay. The server may include a "Retry-After" header in the response to indicate how long the service is expected to be unavailable to the requesting client. > > (2) 2.2: what's in the response body with a 200 response? If it > doesn't matter please say so. Added: The content of the response body does not matter as all information is conveyed in the response code. > > I see from the write-up one author hasn't confirmed there are > no IPR issues. I've sent a Marius a mail so hopefully we > can sort that as we go. > > I also have the following nits that can be fixed (if need > be) whenever the draft is next changed: > > - intro: "app" isn't really a great term to use, can you replace > with something from 6479. Assuming you meant 6749 I changed it to "application" > > - section 2: the "MAY include a query component" is sort of > dangling there, maybe it'd be better moved elsewhere? As Justin pointed out, the place is ok. I tried to improve wording a bit. "The client requests the revocation of a particular token by making an HTTP POST request to the token revocation endpoint URL. This URL MAY include a query component." > > - section 2: "MUST be obtained from a trustworthy source." might > generate comment from IESG members who don't like using 2119 > terms in ways that don't affect interoperability. (I'm fine with > it fwiw, and have nearly cured 'em of that craze;-) Consider > s/MUST/need to/ here. done > > - 2.1: ought there be a registry for token_type_hint values? It > looks like maybe there ought be. Added registry in Section 5.1.2 > > - 2.1: "A client compliant with [RFC6749] must be prepared" was > that meant to be a 2119 MUST? yep, changed it. > > - section 6: maybe s/shall/need to/ in the last para done regards, Torsten. > > Cheers, > S. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------010302010605060704010809 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Stephen,

I just posted a new revision of the draft (http://tools.ietf.org/html/draft-ietf-oauth-revocation-07). I tried to address all the issues you raised (see below).

Am 09.04.2013 19:27, schrieb Stephen Farrell:
Hi,

I've done my AD review of this draft. I have two quick questions
I'd like to get answered before I start IETF LC. Depending on the
answers maybe we should re-spin or just fire ahead, let's see...

(1) 2.1: "upon the return of the request" isn't right is it?  I
think you mean the response at least.

adjusted wording to "upon receipt of an HTTP 200 response from the server"
And what about HTTP error
handling? What if I get a 503 error? Is the client supposed
to re-send ever? Don't you need to say?

Added:
If the server responds with HTTP status code 503, the client must assume the token still exists and may retry after a reasonable delay. The server may include a "Retry-After" header in the response to indicate how long the service is expected to be unavailable to the requesting client.


(2) 2.2: what's in the response body with a 200 response?  If it
doesn't matter please say so.

Added:
The content of the response body does not matter as all information is conveyed in the response code.

I see from the write-up one author hasn't confirmed there are
no IPR issues. I've sent a Marius a mail so hopefully we
can sort that as we go.

I also have the following nits that can be fixed (if need
be) whenever the draft is next changed:

- intro: "app" isn't really a great term to use, can you replace
with something from 6479.

Assuming you meant 6749 I changed it to "application"

- section 2: the "MAY include a query component" is sort of
dangling there, maybe it'd be better moved elsewhere?

As Justin pointed out, the place is ok. I tried to improve wording a bit.

"The client requests the revocation of a particular token by making an HTTP POST request to the token revocation endpoint URL. This URL MAY include a query component." 

- section 2: "MUST be obtained from a trustworthy source." might
generate comment from IESG members who don't like using 2119
terms in ways that don't affect interoperability. (I'm fine with
it fwiw, and have nearly cured 'em of that craze;-) Consider
s/MUST/need to/ here.
done

- 2.1: ought there be a registry for token_type_hint values? It
looks like maybe there ought be.

Added registry in Section 5.1.2

- 2.1: "A client compliant with [RFC6749] must be prepared" was
that meant to be a 2119 MUST?
yep, changed it.

- section 6: maybe s/shall/need to/ in the last para
done

regards,
Torsten.

Cheers,
S.

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

--------------010302010605060704010809-- From stephen.farrell@cs.tcd.ie Mon Apr 15 14:14:08 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27B0E21F9184 for ; Mon, 15 Apr 2013 14:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.601 X-Spam-Level: X-Spam-Status: No, score=-101.601 tagged_above=-999 required=5 tests=[AWL=0.398, BAYES_00=-2.599, J_CHICKENPOX_33=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 D2k60LsHOtAw for ; Mon, 15 Apr 2013 14:14:06 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id BA34721F9380 for ; Mon, 15 Apr 2013 14:13:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 930A4BE63; Mon, 15 Apr 2013 22:13:35 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pl93e4CB0tF0; Mon, 15 Apr 2013 22:13:34 +0100 (IST) Received: from [10.87.48.4] (unknown [86.46.29.146]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D9121BE61; Mon, 15 Apr 2013 22:13:33 +0100 (IST) Message-ID: <516C6D7D.4050805@cs.tcd.ie> Date: Mon, 15 Apr 2013 22:13:33 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Torsten Lodderstedt References: <51644F9A.9040402@cs.tcd.ie> <516C5E8F.1020807@lodderstedt.net> In-Reply-To: <516C5E8F.1020807@lodderstedt.net> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-revocation-06 X-BeenThere: oauth@ietf.org X-Mailman-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, 15 Apr 2013 21:14:08 -0000 Hi Torsten, That's great thanks. We're still after a mail from Marius ack'ing no IPR. Be nice to get that. I'll ask for IETF LC in a day or so in case the WG have anything to say, but a couple of follow-ups below that you can take as LC comments from me. On 04/15/2013 09:09 PM, Torsten Lodderstedt wrote: > Hi Stephen, > > I just posted a new revision of the draft > (http://tools.ietf.org/html/draft-ietf-oauth-revocation-07). I tried to > address all the issues you raised (see below). > > Am 09.04.2013 19:27, schrieb Stephen Farrell: >> Hi, >> >> I've done my AD review of this draft. I have two quick questions >> I'd like to get answered before I start IETF LC. Depending on the >> answers maybe we should re-spin or just fire ahead, let's see... >> >> (1) 2.1: "upon the return of the request" isn't right is it? I >> think you mean the response at least. > > adjusted wording to "upon receipt of an HTTP 200 response from the server" >> And what about HTTP error >> handling? What if I get a 503 error? Is the client supposed >> to re-send ever? Don't you need to say? > > Added: > If the server responds with HTTP status code 503, the client must assume > the token still exists and may retry after a reasonable delay. The > server may include a "Retry-After" header in the response to indicate > how long the service is expected to be unavailable to the requesting > client. I think it'd be worth looking at other HTTP consuming specs and maybe asking some folks about that. I suspect you might need to say 5xx rather than just 503 and "reasonable" is gonna set off transport area alarms bells probably. > >> >> (2) 2.2: what's in the response body with a 200 response? If it >> doesn't matter please say so. > > Added: > The content of the response body does not matter as all information is > conveyed in the response code. >> >> I see from the write-up one author hasn't confirmed there are >> no IPR issues. I've sent a Marius a mail so hopefully we >> can sort that as we go. >> >> I also have the following nits that can be fixed (if need >> be) whenever the draft is next changed: >> >> - intro: "app" isn't really a great term to use, can you replace >> with something from 6479. > > Assuming you meant 6749 I changed it to "application" >> >> - section 2: the "MAY include a query component" is sort of >> dangling there, maybe it'd be better moved elsewhere? > > As Justin pointed out, the place is ok. I tried to improve wording a bit. > > "The client requests the revocation of a particular token by making an > HTTP POST request to the token revocation endpoint URL. This URL MAY > include a query component." >> >> - section 2: "MUST be obtained from a trustworthy source." might >> generate comment from IESG members who don't like using 2119 >> terms in ways that don't affect interoperability. (I'm fine with >> it fwiw, and have nearly cured 'em of that craze;-) Consider >> s/MUST/need to/ here. > done >> >> - 2.1: ought there be a registry for token_type_hint values? It >> looks like maybe there ought be. > > Added registry in Section 5.1.2 I'd encourage WG participants to check that and see what they think. We can fix it (if needed) after IETF LC. Cheers, S. >> >> - 2.1: "A client compliant with [RFC6749] must be prepared" was >> that meant to be a 2119 MUST? > yep, changed it. >> >> - section 6: maybe s/shall/need to/ in the last para > done > > regards, > Torsten. >> >> Cheers, >> S. >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > From iesg-secretary@ietf.org Tue Apr 16 10:21:56 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCC6521F971E; Tue, 16 Apr 2013 10:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.47 X-Spam-Level: X-Spam-Status: No, score=-102.47 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4CbhZCyWslCY; Tue, 16 Apr 2013 10:21:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CE62721F95D7; Tue, 16 Apr 2013 10:21:54 -0700 (PDT) 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: 4.43.p4 Message-ID: <20130416172154.18206.53803.idtracker@ietfa.amsl.com> Date: Tue, 16 Apr 2013 10:21:54 -0700 Cc: oauth@ietf.org Subject: [OAUTH-WG] Last Call: (Token Revocation) 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, 16 Apr 2013 17:21:57 -0000 The IESG has received a request from the Web Authorization Protocol WG (oauth) to consider the following document: - 'Token Revocation' as 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 2013-04-30. 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 document proposes an additional endpoint for OAuth authorization servers, which allows clients to notify the authorization server that a previously obtained refresh or access token is no longer needed. This allows the authorization server to cleanup security credentials. A revocation request will invalidate the actual token and, if applicable, other tokens based on the same authorization grant. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-oauth-revocation/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-oauth-revocation/ballot/ No IPR declarations have been submitted directly on this I-D. The draft has a normative reference to RFC2246 (as well as 5346) as it follows the same approach to TLS as the base oauth spec. (RFC6749, section 1.2). From iesg-secretary@ietf.org Tue Apr 16 10:21:57 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C813021F971E for ; Tue, 16 Apr 2013 10:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.47 X-Spam-Level: X-Spam-Status: No, score=-102.47 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s5Qqg-26jG3D; Tue, 16 Apr 2013 10:21:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ED98721F96C5; Tue, 16 Apr 2013 10:21:54 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IANA X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p4 X-IETF-Draft-string: draft-ietf-oauth-revocation X-IETF-Draft-revision: 07 Message-ID: <20130416172154.18206.67874.idtracker@ietfa.amsl.com> Date: Tue, 16 Apr 2013 10:21:54 -0700 Cc: oauth@ietf.org Subject: [OAUTH-WG] Last Call: (Token Revocation) to Proposed Standard X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: noreply@ietf.org List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 17:21:58 -0000 The IESG has received a request from the Web Authorization Protocol WG (oauth) to consider the following document: - 'Token Revocation' as 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 2013-04-30. 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 document proposes an additional endpoint for OAuth authorization servers, which allows clients to notify the authorization server that a previously obtained refresh or access token is no longer needed. This allows the authorization server to cleanup security credentials. A revocation request will invalidate the actual token and, if applicable, other tokens based on the same authorization grant. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-oauth-revocation/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-oauth-revocation/ballot/ No IPR declarations have been submitted directly on this I-D. The draft has a normative reference to RFC2246 (as well as 5346) as it follows the same approach to TLS as the base oauth spec. (RFC6749, section 1.2). From Michael.Jones@microsoft.com Wed Apr 17 14:40:14 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55B0621E80E0 for ; Wed, 17 Apr 2013 14:40:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.082, 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 uIW840pfW0rh for ; Wed, 17 Apr 2013 14:40:12 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0241.outbound.protection.outlook.com [207.46.163.241]) by ietfa.amsl.com (Postfix) with ESMTP id D66B021E80A9 for ; Wed, 17 Apr 2013 14:40:11 -0700 (PDT) Received: from BL2FFO11FD024.protection.gbl (10.173.161.201) by BL2FFO11HUB013.protection.gbl (10.173.160.105) with Microsoft SMTP Server (TLS) id 15.0.675.0; Wed, 17 Apr 2013 21:40:09 +0000 Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD024.mail.protection.outlook.com (10.173.161.103) with Microsoft SMTP Server (TLS) id 15.0.675.0 via Frontend Transport; Wed, 17 Apr 2013 21:40:09 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.224]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.02.0318.003; Wed, 17 Apr 2013 21:39:42 +0000 From: Mike Jones To: =JeffH , IETF oauth WG Thread-Topic: [OAUTH-WG] regarding nested JWTs and security Thread-Index: AQHN39AM+YNehY3ElEmhqPClRQUvSZjbp5Hw Date: Wed, 17 Apr 2013 21:39:42 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436764BC54@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <50D4EBB7.6070508@KingsMountain.com> In-Reply-To: <50D4EBB7.6070508@KingsMountain.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.75] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436764BC54TK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(43784002)(199002)(189002)(377454001)(51704004)(13464002)(71186001)(5343635001)(80022001)(65816001)(56816002)(66066001)(5343655001)(59766001)(77982001)(564824004)(18276755001)(18277545001)(81542001)(79102001)(51856001)(76482001)(33656001)(81342001)(69226001)(53806001)(44976003)(512954001)(15202345002)(16406001)(54356001)(55846006)(16236675002)(56776001)(74502001)(54316002)(74662001)(49866001)(46102001)(4396001)(63696002)(47976001)(47736001)(20776003)(6806003)(31966008)(50986001)(47446002); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB013; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 081904387B Subject: Re: [OAUTH-WG] regarding nested JWTs and security X-BeenThere: oauth@ietf.org X-Mailman-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, 17 Apr 2013 21:40:14 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436764BC54TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jeff - following up on one aspect of our conversation in Orlando, I'd been = thinking about what additional guidance needed to be added to the JWT spec = about the order of signing and encryption operations. I've come to the con= clusion that this is already handled by the JOSE layer, and so is not a JWT= concern, per se. Nonetheless, I've added the following text to my working= draft of the JWT specification after the current Security Considerations a= bout Nested JWTs: Note that potential concerns about security issues related to the order of = signing and encryption operations are already addressed by the underlying J= WS and JWE specifications; in particular, because JWE only supports the use= of authenticated encryption algorithms, cryptographic concerns about the p= otential need to sign after encryption that apply in many contexts do not a= pply to this specification. Please let me know if you agree with that statement or if you'd like to see= any changes to it or additional statements made. Thanks again for your diligence! -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of = =3DJeffH Sent: Friday, December 21, 2012 3:08 PM To: IETF oauth WG Subject: [OAUTH-WG] regarding nested JWTs and security "nested JWTs" are only nominally defined in draft-ietf-oauth-json-web-token= -05 (and the term is missing from the terminology section). the JWT spec implies that "signing and then encrypting" and "encrypting and= then signing" are equivalent. however they aren't in various ways. Axel already raised this point in.. Re: [jose] encrypting AND signing a token https://www.ietf.org/mail-archive/web/jose/current/msg01269.html ..and cited this paper (worth citing again).. Defective Sign & Encrypt in S/MIME, PKCS#7, MOSS, PEM, PGP, and XML Don Davis http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html http://citeseerx.ist.psu.edu/viewdoc/download?doi=3D10.1.1.28.7379&rep=3Dre= p1&type=3Dpdf One has to carefully compose signing and encryption in order to avoid vario= us vulnerabilities detailed in the latter. I agree with Axel that there should be one carefully designed way to craft = a signed and encrypted JW*. Note that in the JSMS draft (draft-rescorla-jsms-00; an early input into wh= at became the JOSE WG), sign & encrypt composition is declared.. > 4.6. Composition > > This document does not specify a combination signed and encrypted > mode. However, because the contents of a message can be arbitrary, > and encryption and data origin authentication can be provided by > recursively encapsulating multiple JSMS messages. In general, > senders SHOULD sign the message and then encrypt the result (thus > encrypting the signature). This prevents attacks in which the > signature is stripped, leaving just an encrypted message, as well as > providing privacy for the signer. ..tho that's a drafty draft and I didn't review carefully enough to determi= ne whether it addresses the need for sign and encrypt to cross-refer (see S= 4.3 in the paper). HTH, =3DJeffH _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_4E1F6AAD24975D4BA5B16804296739436764BC54TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Jeff - following up on one aspect of our conversa= tion in Orlando, I'd been thinking about what additional guidance needed to= be added to the JWT spec about the order of signing and encryption operati= ons.  I've come to the conclusion that this is already handled by the JOSE layer, and so is not a JWT concer= n, per se.  Nonetheless, I've added the following text to my working d= raft of the JWT specification after the current Security Considerations abo= ut Nested JWTs:

 

Note that potential co= ncerns about security issues related to the order of signing and encryption= operations are already addressed by the underlying JWS and JWE specificati= ons; in particular, because JWE only supports the use of authenticated encryption algorithms, cryptographic con= cerns about the potential need to sign after encryption that apply in many = contexts do not apply to this specification.

 

Please let me know if you agree with that stateme= nt or if you’d like to see any changes to it or additional statements= made.

 

Thanks again for your diligence!

 

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

 

-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of = =3DJeffH
Sent: Friday, December 21, 2012 3:08 PM
To: IETF oauth WG
Subject: [OAUTH-WG] regarding nested JWTs and security

 

"nested JWTs" are only nominally define= d in draft-ietf-oauth-json-web-token-05

(and the term is missing from the terminology sec= tion).

 

the JWT spec implies that "signing and then = encrypting" and "encrypting and then signing" are equivalent= . however they aren't in various ways.

 

Axel already raised this point in..

 

   Re: [jose] encrypting AND signing a = token

  https://www.ietf.org/mail-archive/web/jose/current/msg01= 269.html

 

..and cited this paper (worth citing again)..

 

   Defective Sign & Encrypt in S/MI= ME, PKCS#7, MOSS, PEM, PGP, and XML

   Don Davis

   http://world.std.com/= ~dtd/sign_encrypt/sign_encrypt7.html

http://citeseerx.ist.psu.edu/viewdoc= /download?doi=3D10.1.1.28.7379&rep=3Drep1&type=3Dpdf

 

 

One has to carefully compose signing and encrypti= on in order to avoid various vulnerabilities detailed in the latter.

 

I agree with Axel that there should be one carefu= lly designed way to craft a signed and encrypted JW*.

 

Note that in the JSMS draft (draft-rescorla-jsms-= 00; an early input into what became the JOSE WG), sign & encrypt compos= ition is declared..

 

> 4.6.  Composition

>

>    This document does not spe= cify a combination signed and encrypted

>    mode.  However, becau= se the contents of a message can be arbitrary,

>    and encryption and data or= igin authentication can be provided by

>    recursively encapsulating = multiple JSMS messages.  In general,

>    senders SHOULD sign the me= ssage and then encrypt the result (thus

>    encrypting the signature).=   This prevents attacks in which the

>    signature is stripped, lea= ving just an encrypted message, as well as

>    providing privacy for the = signer.

 

..tho that's a drafty draft and I didn't review c= arefully enough to determine whether it addresses the need for sign and enc= rypt to cross-refer (see S4.3 in the paper).

 

 

HTH,

 

=3DJeffH

 

 

 

_______________________________________________

OAuth mailing list

OAuth@ietf.org=

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

--_000_4E1F6AAD24975D4BA5B16804296739436764BC54TK5EX14MBXC283r_-- From Michael.Jones@microsoft.com Thu Apr 18 08:33:28 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9432721F8DE4 for ; Thu, 18 Apr 2013 08:33:28 -0700 (PDT) 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 nx0uYMfSx1OI for ; Thu, 18 Apr 2013 08:33:26 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0235.outbound.protection.outlook.com [207.46.163.235]) by ietfa.amsl.com (Postfix) with ESMTP id ED1FB21F8D5F for ; Thu, 18 Apr 2013 08:33:25 -0700 (PDT) Received: from BL2FFO11FD027.protection.gbl (10.173.161.202) by BL2FFO11HUB014.protection.gbl (10.173.160.106) with Microsoft SMTP Server (TLS) id 15.0.675.0; Thu, 18 Apr 2013 15:29:02 +0000 Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD027.mail.protection.outlook.com (10.173.161.106) with Microsoft SMTP Server (TLS) id 15.0.675.0 via Frontend Transport; Thu, 18 Apr 2013 15:29:02 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.245]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.02.0318.003; Thu, 18 Apr 2013 15:28:20 +0000 From: Mike Jones To: Justin Richer Thread-Topic: [OAUTH-WG] Registration: Scope Values Thread-Index: AQHOOeqUFpSaFgMeSEqfp5thtJ9Xm5jXeeUggAAGtwCAAAX9QIAAJHsAgARy+OA= Date: Thu, 18 Apr 2013 15:28:19 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436766BCC4@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <255B9BB34FB7D647A506DC292726F6E1150C74DADA@WSMSG3153V.srv.dir.telstra.com> <516C069F.9090308@mitre.org> <516C0B9D.6000402@mitre.org> <516C101F.2090706@mitre.org> <516C1714.8070503@mitre.org> <4E1F6AAD24975D4BA5B168042967394367641A87@TK5EX14MBXC283.redmond.corp.microsoft.com> <516C3152.9070603@mitre.org> <4E1F6AAD24975D4BA5B168042967394367641FAB@TK5EX14MBXC283.redmond.corp.microsoft.com> <516C54F2.8040708@mitre.org> In-Reply-To: <516C54F2.8040708@mitre.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436766BCC4TK5EX14MBXC284r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(512874001)(76482001)(56816002)(47736001)(47446002)(59766001)(69226001)(31966008)(56776001)(77982001)(79102001)(564824004)(71186001)(4396001)(49866001)(6806003)(81342001)(81542001)(54316002)(51856001)(53806001)(54356001)(16406001)(65816001)(55846006)(66066001)(50986001)(20776003)(74662001)(63696002)(47976001)(33656001)(74502001)(44976003)(80022001)(46102001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB014; H:TK5EX14HUBC102.redmond.corp.microsoft.com; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 08200063E9 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Registration: Scope Values X-BeenThere: oauth@ietf.org X-Mailman-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, 18 Apr 2013 15:33:28 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436766BCC4TK5EX14MBXC284r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzLCBKdXN0aW4uICBJIGFncmVlIHdpdGggdGhlIG5lZWQgZm9yIHRoZSBnZW5lcmljIHR3 by1zaWRlZCBsYW5ndWFnZS4gIEnigJlkIHN0aWxsIGtlZXAgdGhpcyBsYW5ndWFnZSBmb3Igc2Nv cGUsIGJlY2F1c2Ugd2Ugd2FudCB0byBjYXB0dXJlIHRoZSDigJxkZWNsYXJpbmfigJ0gYXNwZWN0 IGluIHRoaXMgY2FzZToNCg0K4oCcU3BhY2Ugc2VwYXJhdGVkIGxpc3Qgb2Ygc2NvcGUgdmFsdWVz IChhcyBkZXNjcmliZWQgaW4gT0F1dGggMi4wIFNlY3Rpb24gMy4zIFtSRkM2NzQ5XTxodHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2NzQ5I3NlY3Rpb24tMy4zPikgdGhhdCB0aGUgY2xpZW50 IGlzIGRlY2xhcmluZyB0byB0aGUgc2VydmVyIHRoYXQgaXQgbWF5IHVzZSB3aGVuIHJlcXVlc3Rp bmcgYWNjZXNzIHRva2VucyBhbmQgdGhhdCB0aGUgc2VydmVyIGlzIGRlY2xhcmluZyB0byB0aGUg Y2xpZW50IHRoYXQgaXQgaXMgcmVnaXN0ZXJlZCB0byB1c2Ugd2hlbiByZXF1ZXN0aW5nIGFjY2Vz cyB0b2tlbnMu4oCdLg0KDQpZb3Ugc2hvdWxkIHByb2JhYmx5IGFsc28gcmVpbmZvcmNlIHRoYXQg c2NvcGUgdmFsdWVzIGFyZSBzZXJ2aWNlLXNwZWNpZmljIGFuZCBtYXkgbm90IGNvbnNpc3Qgb25s eSBvZiBhIHN0YXRpYyBzZXQgb2Ygc3RyaW5nIHZhbHVlcywgYW5kIHRoYXQgdGhlcmVmb3JlLCBp biBzb21lIGNhc2VzLCBhbiBleGhhdXN0aXZlIGxpc3Qgb2YgcmVnaXN0ZXJlZCBzY29wZSB2YWx1 ZXMgaXMgbm90IHBvc3NpYmxlLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IEp1c3RpbiBSaWNoZXIg W21haWx0bzpqcmljaGVyQG1pdHJlLm9yZ10NClNlbnQ6IE1vbmRheSwgQXByaWwgMTUsIDIwMTMg MTI6MjkgUE0NClRvOiBNaWtlIEpvbmVzDQpDYzogVGltIEJyYXk7IG9hdXRoQGlldGYub3JnDQpT dWJqZWN0OiBSZTogW09BVVRILVdHXSBSZWdpc3RyYXRpb246IFNjb3BlIFZhbHVlcw0KDQpJIHRo aW5rIHRoYXQgYmVjYXVzZSB0aGUgImRlY2xhcmF0aW9uIiBpc3N1ZSBhZmZlY3RzIGFsbCBwYXJh bWV0ZXJzIGluIHRoZSBsaXN0LCBub3QganVzdCBzY29wZSwgd2Ugc2hvdWxkIGFkb3B0IHRoaXMg aW4gYSBoaWdoZXIgbGV2ZWwgcGFyYWdyYXBoIGFuZCBsZWF2ZSBpdCBvdXQgb2YgdGhlIGluZGl2 aWR1YWwgcGFyYW1ldGVyIGRlc2NyaXB0aW9ucy4gVGh1cywgc29tZXRoaW5nIGxpa2UgdGhpcyBp bnNlcnRlZCBhcyB0aGUgc2Vjb25kIHBhcmFncmFwaCBpbiBzZWN0aW9uIDI6DQpUaGUgY2xpZW50 IG1ldGFkYXRhIHZhbHVlcyBzZXJ2ZSB0d28gcGFyYWxsZWwgcHVycG9zZXMgaW4gdGhlIG92ZXJh bGwgT0F1dGggRHluYW1pYyBSZWdpc3RyYXRpb24gcHJvdG9jb2w6DQoNCiAtIHRoZSBDbGllbnQg cmVxdWVzdGluZyBpdHMgZGVzaXJlZCB2YWx1ZXMgZm9yIGVhY2ggcGFyYW1ldGVyIHRvIHRoZSBB dXRob3JpemF0aW9uIFNlcnZlciBpbiBhIFtyZWdpc3Rlcl0gb3IgW3VwZGF0ZV0gcmVxdWVzdCwN CiAtIHRoZSBBdXRob3JpemF0aW9uIFNlcnZlciBpbmZvcm1pbmcgdGhlIENsaWVudCBvZiB0aGUg Y3VycmVudCB2YWx1ZXMgb2YgZWFjaCBwYXJhbWV0ZXIgdGhhdCB0aGUgQ2xpZW50IGhhcyBiZWVu IHJlZ2lzdGVyZWQgdG8gdXNlIHRocm91Z2ggYSBbY2xpZW50IGluZm9ybWF0aW9uIHJlc3BvbnNl XS4NCg0KQW4gQXV0aG9yaXphdGlvbiBTZXJ2ZXIgTUFZIG92ZXJyaWRlIGFueSB2YWx1ZSB0aGF0 IGEgQ2xpZW50IHJlcXVlc3RzIGR1cmluZyB0aGUgcmVnaXN0cmF0aW9uIHByb2Nlc3MgKGluY2x1 ZGluZyBhbnkgb21pdHRlZCB2YWx1ZXMpIGFuZCByZXBsYWNlIHRoZSByZXF1ZXN0ZWQgdmFsdWUg d2l0aCBhIGRlZmF1bHQuIFRoZSBub3JtYXRpdmUgaW5kaWNhdGlvbnMgaW4gdGhlIGZvbGxvd2lu ZyBsaXN0IGFwcGx5IHRvIHRoZSBDbGllbnQncyBkZWNsYXJhdGlvbiBvZiBpdHMgZGVzaXJlZCB2 YWx1ZXMuDQoNClRoZSBBdXRob3JpemF0aW9uIFNlcnZlciBTSE9VTEQgcHJvdmlkZSBkb2N1bWVu dGF0aW9uIGZvciBhbnkgZmllbGRzIHRoYXQgaXQgcmVxdWlyZXMgdG8gYmUgZmlsbGVkIGluIGJ5 IHRoZSBjbGllbnQgb3IgdG8gaGF2ZSBwYXJ0aWN1bGFyIHZhbHVlcyBvciBmb3JtYXRzLiBFeHRl bnNpb25zIGFuZCBwcm9maWxlcy4uLg0KDQpBbmQgdGhlbiByZW1vdmUgdGhlIHNpZGVkbmVzcy1s YW5ndWFnZSBmcm9tIHRoZSBzY29wZSBwYXJhbWV0ZXIgYW5kIGFueSBvdGhlciBwYXJhbWV0ZXJz IHdoZXJlIGl0IG1pZ2h0IGhhdmUgY3JlcHQgaW4gaW5hZHZlcnRlbnRseS4NCg0KIC0tIEp1c3Rp bg0KT24gMDQvMTUvMjAxMyAwMToyOSBQTSwgTWlrZSBKb25lcyB3cm90ZToNCldlIGNvdWxkIGZp eCB0aGUgb25lLXNpZGVkIGxhbmd1YWdlIGJ5IGNoYW5naW5nDQrigJxTcGFjZSBzZXBhcmF0ZWQg bGlzdCBvZiBzY29wZSB2YWx1ZXMgKGFzIGRlc2NyaWJlZCBpbiBPQXV0aCAyLjAgU2VjdGlvbiAz LjMgW1JGQzY3NDldPGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY3NDkjc2VjdGlvbi0z LjM+KSB0aGF0IHRoZSBjbGllbnQgaXMgZGVjbGFyaW5nIHRoYXQgaXQgbWF5IHVzZSB3aGVuIHJl cXVlc3RpbmcgYWNjZXNzIHRva2Vucy7igJ0NCnRvDQrigJxTcGFjZSBzZXBhcmF0ZWQgbGlzdCBv ZiBzY29wZSB2YWx1ZXMgKGFzIGRlc2NyaWJlZCBpbiBPQXV0aCAyLjAgU2VjdGlvbiAzLjMgW1JG QzY3NDldPGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY3NDkjc2VjdGlvbi0zLjM+KSB0 aGF0IHRoZSBjbGllbnQgaXMgZGVjbGFyaW5nIHRvIHRoZSBzZXJ2ZXIgdGhhdCBpdCBtYXkgdXNl IHdoZW4gcmVxdWVzdGluZyBhY2Nlc3MgdG9rZW5zIGFuZCB0aGF0IHRoZSBzZXJ2ZXIgaXMgZGVj bGFyaW5nIHRvIHRoZSBjbGllbnQgdGhhdCBpdCBpcyByZWdpc3RlcmVkIHRvIHVzZSB3aGVuIHJl cXVlc3RpbmcgYWNjZXNzIHRva2Vucy7igJ0uDQoNCkFnYWluLCBJIGNob3NlIHRoZSDigJxyZWdp c3RlcmVkIHRvIHVzZeKAnSBsYW5ndWFnZSBjYXJlZnVsbHkg4oCTIGJlY2F1c2UgaW4gdGhlIGdl bmVyYWwgY2FzZSBpdOKAmXMgbm90IGEgcmVzdHJpY3Rpb24gb24gdGhlIHZhbHVlcyB0aGF0IHRo ZSBjbGllbnQgY2FuIHVzZSDigJMganVzdCBhIHN0YXRlbWVudCBieSB0aGUgc2VydmVyIHRvIHRo ZSBjbGllbnQgdGhhdCBpdCBpcyByZWdpc3RlcmVkIHRvIHVzZSB0aG9zZSBwYXJ0aWN1bGFyIHZh bHVlcy4gIEluIGJvdGggY2FzZXMsIHRoZSBwYXJ0aWVzIGFyZSBtYWtpbmcgZGVjbGFyYXRpb25z IHRvIG9uZSBhbm90aGVyLg0KDQpJZiB5b3UgYWRvcHQgdGhhdCBsYW5ndWFnZSAob3Iga2VlcCB0 aGUgb3JpZ2luYWwgbGFuZ3VhZ2UpLCB0aGVuIHllcywgSeKAmWQgY29uc2lkZXIgdGhpcyBjbG9z ZWQuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogSnVzdGluIFJpY2hlciBbbWFpbHRvOmpyaWNoZXJA bWl0cmUub3JnXQ0KU2VudDogTW9uZGF5LCBBcHJpbCAxNSwgMjAxMyA5OjU3IEFNDQpUbzogTWlr ZSBKb25lcw0KQ2M6IFRpbSBCcmF5OyBvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5v cmc+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBSZWdpc3RyYXRpb246IFNjb3BlIFZhbHVlcw0K DQpJIGFic29sdXRlbHkgZG8gbm90IHdhbnQgdG8gZGVsZXRlIHRoaXMgZmVhdHVyZSwgYXMgKGhh dmluZyBpbXBsZW1lbnRlZCBpdCkgSSB0aGluayBpdCdzIHZlcnkgdXNlZnVsLiBUaGlzIGlzIGEg dmVyeSBlc3RhYmxpc2hlZCBwYXR0ZXJuIGluIG1hbnVhbCByZWdpc3RyYXRpb246IEkga25vdyBv ZiBtYW55LCBtYW55IE9BdXRoMiBzZXJ2ZXJzIGFuZCBjbGllbnRzIHRoYXQgYXJlIHNldCB1cCB3 aGVyZSB0aGUgY2xpZW50IG11c3QgcHJlLXJlZ2lzdGVyIGEgc2V0IG9mIHNjb3Blcy4NCg0KSSBk b24ndCBsaWtlIHRoZSBsYW5ndWFnZSBvZiAidGhlIGNsaWVudCBpcyBkZWNsYXJpbmciIGJlY2F1 c2UgaXQncyB0b28gb25lLXNpZGVkLiBUaGUgY2xpZW50IG1pZ2h0IG5vdCBoYXZlIGRlY2xhcmVk IGFueXRoaW5nLCBhbmQgaXQgbWlnaHQgYmUgdGhlIHNlcnZlciB0aGF0J3MgZGVjbGFyaW5nIHNv bWV0aGluZyB0byB0aGUgY2xpZW50LiBEZWxldGluZyB0aGUgImlzIGRlY2xhcmluZyIgYml0IHJl bW92ZXMgdGhhdCB1bmludGVuZGVkIHJlc3RyaWN0aW9uIG9mIHRoZSBsYW5ndWFnZSB3aGlsZSBr ZWVwaW5nIHRoZSBvcmlnaW5hbCBtZWFuaW5nIGludGFjdC4gSSBhY3R1YWxseSB0aG91Z2h0IHRo YXQgSSBoYWQgZml4ZWQgdGhhdCBiZWZvcmUgdGhlIGxhc3QgZHJhZnQgd2VudCBpbiBidXQgYXBw YXJlbnRseSBJIG1pc3NlZCB0aGlzIG9uZS4NCg0KSSB3aWxsIHdvcmsgb24gY2xhcmlmeWluZyB0 aGUgaW50ZW50IG9mIHRoZSB3aG9sZSBtZXRhZGF0YSBzZXQgaW4gaXRzIGludHJvZHVjdG9yeSBw YXJhZ3JhcGgocykgc28gdGhhdCBpdCdzIGNsZWFyIHRoYXQgYWxsIG9mIHRoZXNlIGZpZWxkcyBh cmUgdXNlZCBpbiBib3RoIG9mIHRoZXNlIHNpdHVhdGlvbnM6DQoNCiAxKSBUaGUgY2xpZW50IGRl Y2xhcmluZyB0byB0aGUgc2VydmVyIGl0cyBkZXNpcmUgdG8gdXNlIGEgcGFydGljdWxhciB2YWx1 ZQ0KIDIpIFRoZSBzZXJ2ZXIgZGVjbGFyaW5nIHRvIHRoZSBjbGllbnQgdGhhdCBpdCBoYXMgYmVl biByZWdpc3RlcmVkIHdpdGggYSBwYXJ0aWN1bGFyIHZhbHVlDQoNClRoaXMgc2hvdWxkIGhvcGVm dWxseSBjbGVhciB1cCB0aGUgaXNzdWUgaW4gdGhlIGVkaXRvcidzIG5vdGUgdGhhdCBJIGN1cnJl bnRseSBoYXZlIGF0IHRoZSB0b3Agb2YgdGhhdCBzZWN0aW9uIHJpZ2h0IG5vdywgdG9vLg0KDQpN aWtlLCBzaW5jZSB5b3Ugd2VyZSB0aGUgb25lIHdobyBvcmlnaW5hbGx5IGJyb3VnaHQgdXAgdGhl IGlzc3VlLCBhbmQgeW91J3JlIGZpbmUgd2l0aCB0aGUgZXhpc3RpbmcgdGV4dCwgY2FuIEkgdGFr ZSB0aGlzIGFzIGNsb3NlZCBub3c/IEFzc3VtaW5nIHRoYXQgeW91IGFncmVlIHdpdGggZGVsZXRp bmcgImlzIGRlY2xhcmluZyIgZm9yIHJlYXNvbnMgc3RhdGVkIGFib3ZlLCBJJ20gZmluZSB3aXRo IGxlYXZpbmcgZXZlcnl0aGluZyBlbHNlIGFzIGlzIGFuZCBzdGF5aW5nIHF1aWV0IG9uIHdoYXQg dGhlIHNlcnZlciBoYXMgdG8gZG8gd2l0aCB0aGUgc2NvcGVzLg0KDQogLS0gSnVzdGluDQoNCg0K T24gMDQvMTUvMjAxMyAxMjo0NCBQTSwgTWlrZSBKb25lcyB3cm90ZToNCkkgdGhpbmsgdGhhdCB0 aGUgZXhpc3Rpbmcgd29yZGluZyBpcyBzdXBlcmlvciB0byB0aGUgcHJvcG9zZWQgY2hhbmdlZCB3 b3JkaW5nLiAgVGhlIGV4aXN0aW5nIHdvcmRpbmcgaXM6DQoNCiAgIHNjb3BlDQogICAgICBPUFRJ T05BTC4gIFNwYWNlIHNlcGFyYXRlZCBsaXN0IG9mIHNjb3BlIHZhbHVlcyAoYXMgZGVzY3JpYmVk IGluDQogICAgICBPQXV0aCAyLjAgU2VjdGlvbiAzLjMgW1JGQzY3NDldPGh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL3JmYzY3NDkjc2VjdGlvbi0zLjM+KSB0aGF0IHRoZSBjbGllbnQgaXMgZGVj bGFyaW5nIHRoYXQNCiAgICAgIGl0IG1heSB1c2Ugd2hlbiByZXF1ZXN0aW5nIGFjY2VzcyB0b2tl bnMuICBJZiBvbWl0dGVkLCBhbg0KICAgICAgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgTUFZIHJlZ2lz dGVyIGEgQ2xpZW50IHdpdGggYSBkZWZhdWx0IHNldCBvZg0KICAgICAgc2NvcGVzLg0KDQpGb3Ig aW5zdGFuY2UsIHRoZSBjdXJyZW50IOKAnGNsaWVudCBpcyBkZWNsYXJpbmfigJ0gd29yZGluZyB3 aWxsIGFsd2F5cyBiZSBjb3JyZWN0LCB3aGVyZWFzIGFzIHRoZSBjaGFuZ2UgdG8g4oCcY2xpZW50 IGNhbiB1c2XigJ0gd29yZGluZyBpbXBsaWVzIGEgcmVzdHJpY3Rpb24gb24gY2xpZW50IGJlaGF2 aW9yIHRoYXQgaXMgbm90IGFsd2F5cyBhcHBsaWNhYmxlLiAgVGhlIOKAnGNsaWVudCBpcyBkZWNs YXJpbmfigJ0gd29yZGluZyB3YXMgc3BlY2lmaWMgYW5kIHB1cnBvc2VmdWxseSBjaG9zZW4sIGFu ZCBJIHRoaW5rIHNob3VsZCBiZSByZXRhaW5lZC4gIEluIHBhcnRpY3VsYXIsIHdlIGNhbuKAmXQg ZG8gYW55dGhpbmcgdGhhdCBpbXBsaWVzIHRoYXQgb25seSB0aGUgcmVnaXN0ZXJlZCBzY29wZXMg dmFsdWVzIGNhbiBiZSB1c2VkLiAgQXQgdGhlIE9BdXRoIHNwZWMgbGV2ZWwsIHRoaXMgaXMgYSBo aW50IGFzIHRvIHBvc3NpYmxlIGZ1dHVyZSBjbGllbnQgYmVoYXZpb3Ig4oCTIG5vdCBhIHJlc3Ry aWN0aW9uIG9uIGZ1dHVyZSBjbGllbnQgYmVoYXZpb3IuDQoNCkFsc28sIGZvciB0aGUgcmVhc29u cyB0aGF0IFRpbSBzdGF0ZWQsIEnigJltIHN0cm9uZ2x5IGFnYWluc3QgYW55IOKAnG1hdGNoaW5n 4oCdIG9yIOKAnHJlZ2V44oCdIGxhbmd1YWdlIGluIHRoZSBzcGVjIHBlcnRhaW5pbmcgdG8gc2Nv cGVzIOKAkyBhcyBpdOKAmXMgbm90IGFjdGlvbmFibGUuDQoNClNvIEnigJlkIHByb3Bvc2UgdGhh dCB3ZSBsZWF2ZSB0aGUgZXhpc3Rpbmcgc2NvcGUgd29yZGluZyBpbiBwbGFjZS4gIEFsdGVybmF0 aXZlbHksIEnigJlkIGFsc28gYmUgZmluZSB3aXRoIGRlbGV0aW5nIHRoaXMgZmVhdHVyZSBlbnRp cmVseSwgYXMgSSBkb27igJl0IHRoaW5rIGl04oCZcyB1c2VmdWwgaW4gdGhlIGdlbmVyYWwgY2Fz ZS4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBvYXV0aC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpv YXV0aC1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBKdXN0aW4gUmljaGVyDQpTZW50OiBNb25kYXksIEFwcmlsIDE1LCAyMDEzIDg6 MDUgQU0NClRvOiBUaW0gQnJheTsgb2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3Jn Pg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gUmVnaXN0cmF0aW9uOiBTY29wZSBWYWx1ZXMNCg0K T24gMDQvMTUvMjAxMyAxMDo1MiBBTSwgVGltIEJyYXkgd3JvdGU6DQoNCg0KDQpJ4oCZZCB1c2Ug dGhlIGV4aXN0aW5nIHdvcmRpbmc7IGl04oCZcyBwZXJmZWN0bHkgY2xlYXIuICBGYWlsaW5nIHRo YXQsIGlmIHRoZXJl4oCZcyBzdHJvbmcgZGVtYW5kIGZvciByZWdpc3RyYXRpb24gb2Ygc3RydWN0 dXJlZCBzY29wZXMsIGJsZXNzIHRoZSB1c2Ugb2YgcmVnZXhlcywgZWl0aGVyIFBDUkVzIG9yIHNv bWUgY2FyZWZ1bCBzdWJzZXQuDQoNClRoYW5rcyBmb3IgdGhlIGZlZWRiYWNrIC0tIE9mIHRoZXNl IHR3byBjaG9pY2VzLCBJJ2QgcmF0aGVyIGxlYXZlIGl0IGFzLWlzLg0KDQoNCg0KDQoNCkhvd2V2 ZXIsIEnigJlkIHN1YnRyYWN0IHRoZSBzZW50ZW5jZSDigJxJZiBvbWl0dGVkLCBhbiBBdXRob3Jp emF0aW9uIFNlcnZlciBNQVkgcmVnaXN0ZXIgYSBDbGllbnQgd2l0aCBhIGRlZmF1bHQgc2V0IG9m ICBzY29wZXMu4oCdICBJdCBhZGRzIG5vIHZhbHVlOyBpZiB0aGUgY2xpZW50IGRvZXNu4oCZdCBk ZWNsYXJlIHNjb3BlcywgdGhlIGNsaWVudCBkb2VzbuKAmXQgZGVjbGFyZSBzY29wZXMsIHRoYXTi gJlzIGFsbC4gIC1UDQoNClJlbWVtYmVyLCBhbGwgb2YgdGhlc2UgZmllbGRzIGFyZW4ndCBqdXN0 IGZvciB0aGUgY2xpZW50ICpyZXF1ZXN0KiwgdGhleSdyZSBhbHNvIGZvciB0aGUgc2VydmVyJ3Mg KnJlc3BvbnNlKiB0byBlaXRoZXIgYSBQT1NULCBQVVQsIG9yIEdFVCByZXF1ZXN0LiAoSSBkaWRu J3QgcmVhbGl6ZSBpdCwgYnV0IHBlcmhhcHMgdGhlIHdvcmRpbmcgYXMgc3RhdGVkIHJpZ2h0IG5v dyBkb2Vzbid0IG1ha2UgdGhhdCBjbGVhciAtLSBJIG5lZWQgdG8gZml4IHRoYXQuKSBUaGUgdmFs dWUgdGhhdCBpdCBhZGRzIGlzIGlmIHRoZSBjbGllbnQgZG9lc24ndCBhc2sgZm9yIGFueSBwYXJ0 aWN1bGFyIHNjb3BlcywgdGhlIHNlcnZlciBjYW4gc3RpbGwgYXNzaWduIGl0IHNjb3BlcyBhbmQg dGhlIGNsaWVudCBjYW4gZG8gc29tZXRoaW5nIHNtYXJ0IHdpdGggdGhhdC4gRHVtYiBjbGllbnRz IGFyZSBhbGxvd2VkIHRvIGlnbm9yZSBpdCBpZiBpdCBkb2Vzbid0IG1lYW4gYW55dGhpbmcgdG8g dGhlbS4NCg0KVGhpcyBpcyBob3cgb3VyIHNlcnZlciBpbXBsZW1lbnRhdGlvbiBhY3R1YWxseSB3 b3JrcyByaWdodCBub3cuIElmIHRoZSBjbGllbnQgZG9lc24ndCBhc2sgZm9yIGFueXRoaW5nIHNw ZWNpZmljIGF0IHJlZ2lzdHJhdGlvbiwgdGhlIHNlcnZlciBoYW5kcyBpdCBhIGJhZyBvZiAiZGVm YXVsdCIgc2NvcGVzLiBTYW1lIHRoaW5nIGhhcHBlbnMgYXQgYXV0aCB0aW1lIC0tIGlmIHRoZSBj bGllbnQgZG9lc24ndCBhc2sgZm9yIGFueSBwYXJ0aWN1bGFyIHNjb3BlcywgdGhlIHNlcnZlciBo YW5kcyBpdCBhbGwgb2YgaXRzIHJlZ2lzdGVyZWQgc2NvcGVzIGFzIGEgZGVmYXVsdC4gR3JhbnRl ZCwgb24gb3VyIHNlcnZlciwgc2NvcGVzIGFyZSBqdXN0IHNpbXBsZSBzdHJpbmdzIHJpZ2h0IG5v dywgc28gdGhleSBnZXQgY29tcGFyZWQgYXQgdGhlIGF1dGggZW5kcG9pbnQgd2l0aCBhbiBleGFj dCBzdHJpbmctbWF0Y2ggbWV0cmljIGFuZCBzZXQtYmFzZWQgbG9naWMuDQoNCiAtLSBKdXN0aW4N Cg0KDQoNCg0KDQpPbiBNb24sIEFwciAxNSwgMjAxMyBhdCA3OjM1IEFNLCBKdXN0aW4gUmljaGVy IDxqcmljaGVyQG1pdHJlLm9yZzxtYWlsdG86anJpY2hlckBtaXRyZS5vcmc+PiB3cm90ZToNCldo YXQgd291bGQgeW91IHN1Z2dlc3QgZm9yIHdvcmRpbmcgaGVyZSwgdGhlbj8gS2VlcGluZyBpbiBt aW5kIHRoYXQgd2UgY2Fubm90IChhbmQgZG9uJ3Qgd2FudCB0bykgcHJvaGliaXQgZXhwcmVzc2lv bi1iYXNlZCBzY29wZXMuDQoNCiAtLSBKdXN0aW4NCg0KT24gMDQvMTUvMjAxMyAxMDozMyBBTSwg VGltIEJyYXkgd3JvdGU6DQpObywgSSBtZWFuIGl04oCZcyBub3QgaW50ZXJvcGVyYWJsZSBhdCB0 aGUgc29mdHdhcmUtZGV2ZWxvcGVyIGxldmVsLiAgSSBjYW7igJl0IHJlZ2lzdGVyIHNjb3BlcyBh dCBhdXRob3JpemF0aW9uIHRpbWUgd2l0aCBhbnkgcHJlZGljdGFibGUgZWZmZWN0IHRoYXQgSSBj YW4gd3JpdGUgY29kZSB0byBzdXBwb3J0LCBlaXRoZXIgY2xpZW50IG9yIHNlcnZlciBzaWRlLCB3 aXRob3V0IG91dC1vZi1saW5lIG5vbi1pbnRlcm9wZXJhYmxlIGtub3dsZWRnZSBhYm91dCB0aGUg YmVoYXZpb3Igb2YgdGhlIHNlcnZlci4NCg0KSSBndWVzcyBJ4oCZbSBqdXN0IG5vdCB1c2VkIHRv IE9BdXRo4oCZcyBjdWx0dXJlIG9mIGhhdmluZyBubyBleHBlY3RhdGlvbiB0aGF0IHRoaW5ncyB3 aWxsIGJlIHNwZWNpZmllZCB0aWdodGx5IGVub3VnaCB0aGF0IEkgY2FuIHdyaXRlIGNvZGUgdG8g aW1wbGVtZW50IGFzIHNwZWNpZmllZC4gIC1UDQoNCk9uIE1vbiwgQXByIDE1LCAyMDEzIGF0IDc6 MTUgQU0sIEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0cmUub3JnPG1haWx0bzpqcmljaGVyQG1p dHJlLm9yZz4+IHdyb3RlOg0KU2NvcGVzIGFyZW4ndCBtZWFudCB0byBiZSBpbnRlcm9wZXJhYmxl IGJldHdlZW4gc2VydmljZXMgc2luY2UgdGhleSdyZSBuZWNlc3NhcmlseSBBUEktc3BlY2lmaWMu IFRoZSBvbmx5IGludGVyb3BlcmFibGUgYml0IGlzIHRoYXQgdGhlcmUncyAqc29tZSogcGxhY2Ug dG8gcHV0IHRoZSB2YWx1ZXMgYW5kIHRoYXQgaXQncyBleHByZXNzZWQgYXMgYSBiYWcgb2Ygc3Bh Y2Utc2VwYXJhdGVkIHN0cmluZ3MuIEhvdyB0aG9zZSBzdHJpbmdzIGdldCBpbnRlcnByZXRlZCBh bmQgZW5mb3JjZWQgKHdoaWNoIGlzIHJlYWxseSB3aGF0J3MgYXQgc3Rha2UgaGVyZSkgaXMgdXAg dG8gdGhlIEFTIGFuZCBQUiAob3IgYSBoaWdoZXItbGV2ZWwgcHJvdG9jb2wgbGlrZSBVTUEpLg0K DQogLS0gSnVzdGluDQoNCk9uIDA0LzE1LzIwMTMgMTA6MTMgQU0sIFRpbSBCcmF5IHdyb3RlOg0K DQpUaGlzLCBhcyB3cml0dGVuLCBoYXMgemVybyBpbnRlcm9wZXJhYmlsaXR5LiAgSSB0aGluayB0 aGlzIGZlYXR1cmUgY2FuIHJlYWxseSBvbmx5IGJlIG1hZGUgdXNlZnVsIGluIHRoZSBjYXNlIHdo ZXJlIHNjb3BlcyBhcmUgZml4ZWQgc3RyaW5ncy4NCg0KLVQNCk9uIEFwciAxNSwgMjAxMyA2OjU0 IEFNLCAiSnVzdGluIFJpY2hlciIgPGpyaWNoZXJAbWl0cmUub3JnPG1haWx0bzpqcmljaGVyQG1p dHJlLm9yZz4+IHdyb3RlOg0KWW91IGFyZSBjb3JyZWN0IHRoYXQgdGhlIGlkZWEgYmVoaW5kIHRo ZSAic2NvcGUiIHBhcmFtZXRlciBhdCByZWdpc3RyYXRpb24gaXMgYSBjb25zdHJhaW50IG9uIGF1 dGhvcml6YXRpb24tdGltZSBzY29wZXMgdGhhdCBhcmUgbWFkZSBhdmFpbGFibGUuIEl0J3MgYm90 aCBhIG1lYW5zIGZvciB0aGUgY2xpZW50IHRvIHJlcXVlc3QgYSBzZXQgb2YgdmFsaWQgc2NvcGVz IGFuZCBmb3IgdGhlIHNlcnZlciB0byBwcm92aXNpb24gKGFuZCBlY2hvIGJhY2sgdG8gdGhlIGNs aWVudCkgYSBzZXQgb2YgdmFsaWQgc2NvcGVzLg0KDQpJICpyZWFsbHkqIGRvbid0IHdhbnQgdG8g dHJ5IHRvIGRlZmluZSBhIG1hdGNoaW5nIGxhbmd1YWdlIGZvciBzY29wZSBleHByZXNzaW9ucy4g Rm9yIHRoYXQgdG8gd29yaywgYWxsIHNlcnZlcnMgd291bGQgbmVlZCB0byBiZSBhYmxlIHRvIHBy b2Nlc3MgdGhlIHJlZ3VsYXIgZXhwcmVzc2lvbnMgZm9yIGFsbCBjbGllbnRzLCBldmVuIGlmIHRo ZSBzZXJ2ZXJzIHRoZW1zZWx2ZXMgb25seSBzdXBwb3J0IHNpbXBsZS1zdHJpbmcgc2NvcGUgdmFs dWVzLiBBbnkgcmVndWxhciBleHByZXNzaW9uIHN5bnRheCB3ZSBwaWNrIGhlcmUgaXMgZ3VhcmFu dGVlZCB0byBiZSBpbmNvbXBhdGlibGUgd2l0aCBzb21ldGhpbmcsIGFuZCBJIHRoaW5rIHRoZSBj b21wbGV4aXR5IGRvZXNuJ3QgYnV5IG11Y2guIEFsc28sIEkgdGhpbmsgeW91IHN1ZGRlbmx5IGhh dmUgYSBwb3RlbnRpYWwgc2VjdXJpdHkgaXNzdWUgaWYgeW91IGhhdmUgYSBiYWQgcmVnZXggaW4g cGxhY2Ugb24gZWl0aGVyIGVuZC4NCg0KQXMgaXQgc3RhbmRzIHRvZGF5LCB0aGUgc2VydmVyIGNh biBpbnRlcnByZXQgdGhlIGluY29taW5nIHJlZ2lzdHJhdGlvbiBzY29wZXMgYW5kIGVuZm9yY2Ug dGhlbSBob3dldmVyIGl0IHdhbnRzIHRvLiBUaGUgcmVhbCB0cmljayBjb21lcyBub3QgZnJvbSBh c3NpZ25pbmcgdGhlIHZhbHVlcyB0byBhIHBhcnRpY3VsYXIgY2xpZW50IGJ1dCB0byBlbmZvcmNp bmcgdGhlbSwgYW5kIEkgdGhpbmsgdGhhdCdzIGFsd2F5cyBnb2luZyB0byBiZSBzZXJ2aWNlLXNw ZWNpZmljLiBXZSdyZSBqdXN0IG5vdCBhcyBjbGVhciBvbiB0aGF0IGFzIHdlIGNvdWxkIGJlLg0K DQpBZnRlciBsb29raW5nIG92ZXIgZXZlcnlvbmUncyBjb21tZW50cyBzbyBmYXIsIEknZCBsaWtl IHRvIHByb3Bvc2UgdGhlIGZvbGxvd2luZyB0ZXh0IGZvciB0aGF0IHNlY3Rpb246DQoNCg0KDQoN CiAgIHNjb3BlDQoNCiAgICAgIE9QVElPTkFMLiAgU3BhY2Ugc2VwYXJhdGVkIGxpc3Qgb2Ygc2Nv cGUgdmFsdWVzIChhcyBkZXNjcmliZWQgaW4NCg0KICAgICAgT0F1dGggMi4wIFNlY3Rpb24gMy4z IFtSRkM2NzQ5XTxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2NzQ5I3NlY3Rpb24tMy4z PikgdGhhdCB0aGUgY2xpZW50IGNhbiB1c2Ugd2hlbg0KDQogICAgICByZXF1ZXN0aW5nIGFjY2Vz cyB0b2tlbnMuICBBcyBzY29wZSB2YWx1ZXMgYXJlIHNlcnZpY2Utc3BlY2lmaWMsDQoNCiAgICAg IHRoZSBBdXRob3JpemF0aW9uIFNlcnZlciBNQVkgZGVmaW5lIGl0cyBvd24gbWF0Y2hpbmcgcnVs ZXMgd2hlbg0KDQogICAgICBkZXRlcm1pbmluZyBpZiBhIHNjb3BlIHZhbHVlIHVzZWQgZHVyaW5n IGFuIGF1dGhvcml6YXRpb24gcmVxdWVzdA0KDQogICAgICBpcyB2YWxpZCBhY2NvcmRpbmcgdG8g dGhlIHNjb3BlIHZhbHVlcyBhc3NpZ25lZCBkdXJpbmcNCg0KICAgICAgcmVnaXN0cmF0aW9uLiBQ b3NzaWJsZSBtYXRjaGluZyBydWxlcyBpbmNsdWRlIHdpbGRjYXJkIHBhdHRlcm5zLA0KDQogICAg ICByZWd1bGFyIGV4cHJlc3Npb25zLCBvciBleGFjdGx5IG1hdGNoaW5nIHRoZSBzdHJpbmcuIElm IG9taXR0ZWQsDQoNCiAgICAgIGFuIEF1dGhvcml6YXRpb24gU2VydmVyIE1BWSByZWdpc3RlciBh IENsaWVudCB3aXRoIGEgZGVmYXVsdA0KDQogICAgICBzZXQgb2Ygc2NvcGVzLg0KDQpDb21tZW50 cz8gSW1wcm92ZW1lbnRzPw0KDQogLS0gSnVzdGluDQoNCg0KDQpPbiAwNC8xNC8yMDEzIDA4OjIz IFBNLCBNYW5nZXIsIEphbWVzIEggd3JvdGU6DQoNClByZXN1bWFibHkgYXQgYXBwIHJlZ2lzdHJh dGlvbiB0aW1lIGFueSBzY29wZSBzcGVjaWZpY2F0aW9uIGlzIHJlYWxseSBhIGNvbnN0cmFpbnQg b24gdGhlIHNjb3BlIHZhbHVlcyB0aGF0IGNhbiBiZSByZXF1ZXN0ZWQgaW4gYW4gYXV0aG9yaXph dGlvbiBmbG93Lg0KDQoNCg0KU28gaWRlYWxseSByZWdpc3RyYXRpb24gc2hvdWxkIGFjY2VwdCBy dWxlcyBmb3IgbWF0Y2hpbmcgc2NvcGVzLCBhcyBvcHBvc2VkIHRvIGFjdHVhbCBzY29wZSB2YWx1 ZXMuDQoNCg0KDQpZb3UgY2FuIHRyeSB0byB1c2Ugc2NvcGUgdmFsdWVzIGFzIHRoZWlyIG93biBt YXRjaGluZyBydWxlcy4gVGhhdCBpcyBmaW5lIGZvciBhIHNtYWxsIHNldCBvZiAic3RhdGljIiBz Y29wZXMuIEl0IHN0YXJ0cyB0byBmYWlsIHdoZW4gdGhlcmUgYXJlIGEgbGFyZ2UgbnVtYmVyIG9m IHNjb3Blcywgb3Igc2NvcGVzIHRoYXQgY2FuIGluY2x1ZGUgcGFyYW1ldGVycyAocmVzb3VyY2Ug cGF0aHM/IGVtYWlsIGFkZHJlc3Nlcz8pLiBZb3UgY2FuIHRyeSB0byBwYXRjaCB0aG9zZSBmYWls dXJlcyBieSBhbGxvd2luZyBzZXJ2aWNlcyB0byBkZWZpbmUgc2VydmljZS1zcGVjaWZpYyBzcGVj aWFsICJ3aWxkY2FyZCIgc2NvcGUgdmFsdWVzIHRoYXQgY2FuIG9ubHkgYmUgdXNlZCBkdXJpbmcg cmVnaXN0cmF0aW9uIChlZyAicmVhZDoqIikuDQoNCg0KDQpBbHRlcm5hdGl2ZWx5LCByZXBsYWNl ICdzY29wZScgaW4gcmVnaXN0cmF0aW9uIHdpdGggJ3Njb3BlX3JlZ2V4JyB0aGF0IGhvbGRzIGEg cmVndWxhciBleHByZXNzaW9uIHRoYXQgYWxsIHNjb3BlIHZhbHVlcyBpbiBhbiBhdXRob3JpemF0 aW9uIGZsb3cgbXVzdCBtYXRjaC4NCg0KDQoNCi0tDQoNCkphbWVzIE1hbmdlcg0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpPQXV0aCBtYWlsaW5n IGxpc3QNCg0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KDQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1 dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQoNCg0KDQoNCg0KDQo= --_000_4E1F6AAD24975D4BA5B16804296739436766BCC4TK5EX14MBXC284r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IFw7Y29s b3JcOndpbmRvd3RleHQiOw0KCXBhbm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9yOmJs YWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQs IHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDow aW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZv bnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsN Cgljb2xvcjpibGFjazt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7DQoJY29sb3I6YmxhY2s7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYu TXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJh bGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiOw0K CWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5h bWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFz Ow0KCWNvbG9yOmJsYWNrO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1l OiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlm IjsNCgljb2xvcjpibGFjazt9DQpzcGFuLmhvZW56Yg0KCXttc28tc3R5bGUtbmFtZTpob2VuemI7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1h aWxTdHlsZTI0DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyNQ0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu MGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzLCBKdXN0 aW4uJm5ic3A7IEkgYWdyZWUgd2l0aCB0aGUgbmVlZCBmb3IgdGhlIGdlbmVyaWMgdHdvLXNpZGVk IGxhbmd1YWdlLiZuYnNwOyBJ4oCZZCBzdGlsbCBrZWVwIHRoaXMgbGFuZ3VhZ2UgZm9yIHNjb3Bl LCBiZWNhdXNlIHdlIHdhbnQgdG8gY2FwdHVyZSB0aGUg4oCcZGVjbGFyaW5n4oCdDQogYXNwZWN0 IGluIHRoaXMgY2FzZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW47cGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+4oCcPC9zcGFuPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+U3BhY2Ugc2Vw YXJhdGVkIGxpc3Qgb2Ygc2NvcGUgdmFsdWVzDQogKGFzIGRlc2NyaWJlZCBpbiBPQXV0aCAyLjAg PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjc0OSNzZWN0aW9uLTMuMyI+ DQpTZWN0aW9uJm5ic3A7My4zIFtSRkM2NzQ5XTwvYT4pIHRoYXQgdGhlIGNsaWVudCBpcyBkZWNs YXJpbmcgdG8gdGhlIHNlcnZlciB0aGF0IGl0IG1heSB1c2Ugd2hlbiByZXF1ZXN0aW5nIGFjY2Vz cyB0b2tlbnMgYW5kIHRoYXQgdGhlIHNlcnZlciBpcyBkZWNsYXJpbmcgdG8gdGhlIGNsaWVudCB0 aGF0IGl0IGlzIHJlZ2lzdGVyZWQgdG8gdXNlIHdoZW4gcmVxdWVzdGluZyBhY2Nlc3MgdG9rZW5z Ljwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+4oCdLjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+WW91IHNob3VsZCBwcm9iYWJseSBhbHNvIHJlaW5mb3JjZSB0aGF0IHNjb3BlIHZh bHVlcyBhcmUgc2VydmljZS1zcGVjaWZpYyBhbmQgbWF5IG5vdCBjb25zaXN0IG9ubHkgb2YgYSBz dGF0aWMgc2V0IG9mIHN0cmluZyB2YWx1ZXMsIGFuZCB0aGF0IHRoZXJlZm9yZSwgaW4NCiBzb21l IGNhc2VzLCBhbiBleGhhdXN0aXZlIGxpc3Qgb2YgcmVnaXN0ZXJlZCBzY29wZSB2YWx1ZXMgaXMg bm90IHBvc3NpYmxlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4gSnVzdGluIFJpY2hlciBb bWFpbHRvOmpyaWNoZXJAbWl0cmUub3JnXQ0KPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgQXBy aWwgMTUsIDIwMTMgMTI6MjkgUE08YnI+DQo8Yj5Ubzo8L2I+IE1pa2UgSm9uZXM8YnI+DQo8Yj5D Yzo8L2I+IFRpbSBCcmF5OyBvYXV0aEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog W09BVVRILVdHXSBSZWdpc3RyYXRpb246IFNjb3BlIFZhbHVlczxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ SSB0aGluayB0aGF0IGJlY2F1c2UgdGhlICZxdW90O2RlY2xhcmF0aW9uJnF1b3Q7IGlzc3VlIGFm ZmVjdHMgYWxsIHBhcmFtZXRlcnMgaW4gdGhlIGxpc3QsIG5vdCBqdXN0IHNjb3BlLCB3ZSBzaG91 bGQgYWRvcHQgdGhpcyBpbiBhIGhpZ2hlciBsZXZlbCBwYXJhZ3JhcGggYW5kIGxlYXZlIGl0IG91 dCBvZiB0aGUgaW5kaXZpZHVhbCBwYXJhbWV0ZXIgZGVzY3JpcHRpb25zLiBUaHVzLA0KIHNvbWV0 aGluZyBsaWtlIHRoaXMgaW5zZXJ0ZWQgYXMgdGhlIHNlY29uZCBwYXJhZ3JhcGggaW4gc2VjdGlv biAyOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGNsaWVudCBtZXRh ZGF0YSB2YWx1ZXMgc2VydmUgdHdvIHBhcmFsbGVsIHB1cnBvc2VzIGluIHRoZSBvdmVyYWxsIE9B dXRoIER5bmFtaWMgUmVnaXN0cmF0aW9uIHByb3RvY29sOg0KPGJyPg0KPGJyPg0KJm5ic3A7LSB0 aGUgQ2xpZW50IHJlcXVlc3RpbmcgaXRzIGRlc2lyZWQgdmFsdWVzIGZvciBlYWNoIHBhcmFtZXRl ciB0byB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgaW4gYSBbcmVnaXN0ZXJdIG9yIFt1cGRhdGVd IHJlcXVlc3QsPGJyPg0KJm5ic3A7LSB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgaW5mb3JtaW5n IHRoZSBDbGllbnQgb2YgdGhlIGN1cnJlbnQgdmFsdWVzIG9mIGVhY2ggcGFyYW1ldGVyIHRoYXQg dGhlIENsaWVudCBoYXMgYmVlbiByZWdpc3RlcmVkIHRvIHVzZSB0aHJvdWdoIGEgW2NsaWVudCBp bmZvcm1hdGlvbiByZXNwb25zZV0uDQo8YnI+DQo8YnI+DQpBbiBBdXRob3JpemF0aW9uIFNlcnZl ciBNQVkgb3ZlcnJpZGUgYW55IHZhbHVlIHRoYXQgYSBDbGllbnQgcmVxdWVzdHMgZHVyaW5nIHRo ZSByZWdpc3RyYXRpb24gcHJvY2VzcyAoaW5jbHVkaW5nIGFueSBvbWl0dGVkIHZhbHVlcykgYW5k IHJlcGxhY2UgdGhlIHJlcXVlc3RlZCB2YWx1ZSB3aXRoIGEgZGVmYXVsdC4gVGhlIG5vcm1hdGl2 ZSBpbmRpY2F0aW9ucyBpbiB0aGUgZm9sbG93aW5nIGxpc3QgYXBwbHkgdG8gdGhlIENsaWVudCdz IGRlY2xhcmF0aW9uDQogb2YgaXRzIGRlc2lyZWQgdmFsdWVzLiA8YnI+DQo8YnI+DQpUaGUgQXV0 aG9yaXphdGlvbiBTZXJ2ZXIgU0hPVUxEIHByb3ZpZGUgZG9jdW1lbnRhdGlvbiBmb3IgYW55IGZp ZWxkcyB0aGF0IGl0IHJlcXVpcmVzIHRvIGJlIGZpbGxlZCBpbiBieSB0aGUgY2xpZW50IG9yIHRv IGhhdmUgcGFydGljdWxhciB2YWx1ZXMgb3IgZm9ybWF0cy4gRXh0ZW5zaW9ucyBhbmQgcHJvZmls ZXMuLi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjEyLjBwdCI+PGJyPg0KQW5kIHRoZW4gcmVtb3ZlIHRoZSBzaWRlZG5lc3MtbGFuZ3Vh Z2UgZnJvbSB0aGUgc2NvcGUgcGFyYW1ldGVyIGFuZCBhbnkgb3RoZXIgcGFyYW1ldGVycyB3aGVy ZSBpdCBtaWdodCBoYXZlIGNyZXB0IGluIGluYWR2ZXJ0ZW50bHkuDQo8YnI+DQo8YnI+DQombmJz cDstLSBKdXN0aW48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5P biAwNC8xNS8yMDEzIDAxOjI5IFBNLCBNaWtlIEpvbmVzIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTph bHdheXMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5XZSBjb3Vs ZCBmaXggdGhlIG9uZS1zaWRlZCBsYW5ndWFnZSBieSBjaGFuZ2luZzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3BhZ2Ut YnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPuKAnDwvc3Bhbj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPlNwYWNlIHNlcGFyYXRlZCBsaXN0 IG9mIHNjb3BlIHZhbHVlcw0KIChhcyBkZXNjcmliZWQgaW4gT0F1dGggMi4wIDxhIGhyZWY9Imh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY3NDkjc2VjdGlvbi0zLjMiPg0KU2VjdGlvbiZu YnNwOzMuMyBbUkZDNjc0OV08L2E+KSB0aGF0IHRoZSBjbGllbnQgaXMgZGVjbGFyaW5nIHRoYXQg aXQgbWF5IHVzZSB3aGVuIHJlcXVlc3RpbmcgYWNjZXNzIHRva2Vucy48L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPuKAnTwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj50bzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu O3BhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPuKAnDwvc3Bhbj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPlNwYWNlIHNlcGFyYXRl ZCBsaXN0IG9mIHNjb3BlIHZhbHVlcw0KIChhcyBkZXNjcmliZWQgaW4gT0F1dGggMi4wIDxhIGhy ZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY3NDkjc2VjdGlvbi0zLjMiPg0KU2Vj dGlvbiZuYnNwOzMuMyBbUkZDNjc0OV08L2E+KSB0aGF0IHRoZSBjbGllbnQgaXMgZGVjbGFyaW5n IHRvIHRoZSBzZXJ2ZXIgdGhhdCBpdCBtYXkgdXNlIHdoZW4gcmVxdWVzdGluZyBhY2Nlc3MgdG9r ZW5zIGFuZCB0aGF0IHRoZSBzZXJ2ZXIgaXMgZGVjbGFyaW5nIHRvIHRoZSBjbGllbnQgdGhhdCBp dCBpcyByZWdpc3RlcmVkIHRvIHVzZSB3aGVuIHJlcXVlc3RpbmcgYWNjZXNzIHRva2Vucy48L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPuKAnS48L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1i ZWZvcmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkFnYWluLCBJIGNob3NlIHRoZSDigJxyZWdpc3RlcmVkIHRvIHVzZeKAnSBs YW5ndWFnZSBjYXJlZnVsbHkg4oCTIGJlY2F1c2UgaW4gdGhlIGdlbmVyYWwgY2FzZSBpdOKAmXMg bm90IGEgcmVzdHJpY3Rpb24gb24gdGhlIHZhbHVlcw0KIHRoYXQgdGhlIGNsaWVudCBjYW4gdXNl IOKAkyBqdXN0IGEgc3RhdGVtZW50IGJ5IHRoZSBzZXJ2ZXIgdG8gdGhlIGNsaWVudCB0aGF0IGl0 IGlzIHJlZ2lzdGVyZWQgdG8gdXNlIHRob3NlIHBhcnRpY3VsYXIgdmFsdWVzLiZuYnNwOyBJbiBi b3RoIGNhc2VzLCB0aGUgcGFydGllcyBhcmUgbWFraW5nIGRlY2xhcmF0aW9ucyB0byBvbmUgYW5v dGhlci48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i cGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklmIHlvdSBhZG9wdCB0aGF0IGxhbmd1YWdlIChvciBr ZWVwIHRoZSBvcmlnaW5hbCBsYW5ndWFnZSksIHRoZW4geWVzLCBJ4oCZZCBjb25zaWRlciB0aGlz IGNsb3NlZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7 cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+IEp1c3RpbiBSaWNo ZXIgWzxhIGhyZWY9Im1haWx0bzpqcmljaGVyQG1pdHJlLm9yZyI+bWFpbHRvOmpyaWNoZXJAbWl0 cmUub3JnPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEFwcmlsIDE1LCAyMDEzIDk6 NTcgQU08YnI+DQo8Yj5Ubzo8L2I+IE1pa2UgSm9uZXM8YnI+DQo8Yj5DYzo8L2I+IFRpbSBCcmF5 OyA8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYub3JnPC9hPjxicj4N CjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBSZWdpc3RyYXRpb246IFNjb3BlIFZhbHVl czwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjEyLjBwdCI+SSBhYnNvbHV0ZWx5IGRvIG5vdCB3YW50IHRvIGRlbGV0ZSB0 aGlzIGZlYXR1cmUsIGFzIChoYXZpbmcgaW1wbGVtZW50ZWQgaXQpIEkgdGhpbmsgaXQncyB2ZXJ5 IHVzZWZ1bC4gVGhpcyBpcyBhIHZlcnkgZXN0YWJsaXNoZWQgcGF0dGVybiBpbiBtYW51YWwgcmVn aXN0cmF0aW9uOiBJIGtub3cgb2YgbWFueSwgbWFueSBPQXV0aDIgc2VydmVycyBhbmQgY2xpZW50 cw0KIHRoYXQgYXJlIHNldCB1cCB3aGVyZSB0aGUgY2xpZW50IG11c3QgcHJlLXJlZ2lzdGVyIGEg c2V0IG9mIHNjb3Blcy4gPGJyPg0KPGJyPg0KSSBkb24ndCBsaWtlIHRoZSBsYW5ndWFnZSBvZiAm cXVvdDt0aGUgY2xpZW50IGlzIGRlY2xhcmluZyZxdW90OyBiZWNhdXNlIGl0J3MgdG9vIG9uZS1z aWRlZC4gVGhlIGNsaWVudCBtaWdodCBub3QgaGF2ZSBkZWNsYXJlZCBhbnl0aGluZywgYW5kIGl0 IG1pZ2h0IGJlIHRoZSBzZXJ2ZXIgdGhhdCdzIGRlY2xhcmluZyBzb21ldGhpbmcgdG8gdGhlIGNs aWVudC4gRGVsZXRpbmcgdGhlICZxdW90O2lzIGRlY2xhcmluZyZxdW90OyBiaXQgcmVtb3ZlcyB0 aGF0IHVuaW50ZW5kZWQgcmVzdHJpY3Rpb24NCiBvZiB0aGUgbGFuZ3VhZ2Ugd2hpbGUga2VlcGlu ZyB0aGUgb3JpZ2luYWwgbWVhbmluZyBpbnRhY3QuIEkgYWN0dWFsbHkgdGhvdWdodCB0aGF0IEkg aGFkIGZpeGVkIHRoYXQgYmVmb3JlIHRoZSBsYXN0IGRyYWZ0IHdlbnQgaW4gYnV0IGFwcGFyZW50 bHkgSSBtaXNzZWQgdGhpcyBvbmUuPGJyPg0KPGJyPg0KSSB3aWxsIHdvcmsgb24gY2xhcmlmeWlu ZyB0aGUgaW50ZW50IG9mIHRoZSB3aG9sZSBtZXRhZGF0YSBzZXQgaW4gaXRzIGludHJvZHVjdG9y eSBwYXJhZ3JhcGgocykgc28gdGhhdCBpdCdzIGNsZWFyIHRoYXQgYWxsIG9mIHRoZXNlIGZpZWxk cyBhcmUgdXNlZCBpbiBib3RoIG9mIHRoZXNlIHNpdHVhdGlvbnM6PGJyPg0KPGJyPg0KJm5ic3A7 MSkgVGhlIGNsaWVudCBkZWNsYXJpbmcgdG8gdGhlIHNlcnZlciBpdHMgZGVzaXJlIHRvIHVzZSBh IHBhcnRpY3VsYXIgdmFsdWU8YnI+DQombmJzcDsyKSBUaGUgc2VydmVyIGRlY2xhcmluZyB0byB0 aGUgY2xpZW50IHRoYXQgaXQgaGFzIGJlZW4gcmVnaXN0ZXJlZCB3aXRoIGEgcGFydGljdWxhciB2 YWx1ZTxicj4NCjxicj4NClRoaXMgc2hvdWxkIGhvcGVmdWxseSBjbGVhciB1cCB0aGUgaXNzdWUg aW4gdGhlIGVkaXRvcidzIG5vdGUgdGhhdCBJIGN1cnJlbnRseSBoYXZlIGF0IHRoZSB0b3Agb2Yg dGhhdCBzZWN0aW9uIHJpZ2h0IG5vdywgdG9vLjxicj4NCjxicj4NCk1pa2UsIHNpbmNlIHlvdSB3 ZXJlIHRoZSBvbmUgd2hvIG9yaWdpbmFsbHkgYnJvdWdodCB1cCB0aGUgaXNzdWUsIGFuZCB5b3Un cmUgZmluZSB3aXRoIHRoZSBleGlzdGluZyB0ZXh0LCBjYW4gSSB0YWtlIHRoaXMgYXMgY2xvc2Vk IG5vdz8gQXNzdW1pbmcgdGhhdCB5b3UgYWdyZWUgd2l0aCBkZWxldGluZyAmcXVvdDtpcyBkZWNs YXJpbmcmcXVvdDsgZm9yIHJlYXNvbnMgc3RhdGVkIGFib3ZlLCBJJ20gZmluZSB3aXRoIGxlYXZp bmcgZXZlcnl0aGluZyBlbHNlIGFzDQogaXMgYW5kIHN0YXlpbmcgcXVpZXQgb24gd2hhdCB0aGUg c2VydmVyIGhhcyB0byBkbyB3aXRoIHRoZSBzY29wZXMuPGJyPg0KPGJyPg0KJm5ic3A7LS0gSnVz dGluPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+T24gMDQvMTUvMjAxMyAxMjo0NCBQTSwgTWlrZSBKb25lcyB3cm90ZTo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSB0aGluayB0aGF0IHRoZSBleGlzdGluZyB3b3Jk aW5nIGlzIHN1cGVyaW9yIHRvIHRoZSBwcm9wb3NlZCBjaGFuZ2VkIHdvcmRpbmcuJm5ic3A7IFRo ZSBleGlzdGluZyB3b3JkaW5nIGlzOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0icGFn ZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3IDtjb2xvcjp3aW5kb3d0ZXh0JnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7Ij4mbmJzcDsmbmJzcDsgc2NvcGU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJF TiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3IDtjb2xvcjp3aW5kb3d0ZXh0 JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg T1BUSU9OQUwuJm5ic3A7IFNwYWNlIHNlcGFyYXRlZCBsaXN0IG9mIHNjb3BlIHZhbHVlcyAoYXMg ZGVzY3JpYmVkIGluPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyA7Y29sb3I6d2luZG93dGV4dCZxdW90OywmcXVv dDtzZXJpZiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9BdXRoIDIuMA0K PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjc0OSNzZWN0aW9uLTMuMyI+ U2VjdGlvbiZuYnNwOzMuMyBbUkZDNjc0OV08L2E+KSB0aGF0IHRoZSBjbGllbnQgaXMgZGVjbGFy aW5nIHRoYXQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3IDtjb2xvcjp3aW5kb3d0ZXh0JnF1b3Q7LCZxdW90O3Nl cmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaXQgbWF5IHVzZSB3aGVu IHJlcXVlc3RpbmcgYWNjZXNzIHRva2Vucy4mbmJzcDsgSWYgb21pdHRlZCwgYW48L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZv cmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3IDtjb2xvcjp3aW5kb3d0ZXh0JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgTUFZIHJlZ2lzdGVy IGEgQ2xpZW50IHdpdGggYSBkZWZhdWx0IHNldCBvZjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFu IGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgO2NvbG9yOndp bmRvd3RleHQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBzY29wZXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Gb3IgaW5zdGFuY2UsIHRoZSBjdXJy ZW50IOKAnGNsaWVudCBpcyBkZWNsYXJpbmfigJ0gd29yZGluZyB3aWxsIGFsd2F5cyBiZSBjb3Jy ZWN0LCB3aGVyZWFzIGFzIHRoZSBjaGFuZ2UgdG8g4oCcY2xpZW50IGNhbiB1c2XigJ0gd29yZGlu Zw0KIGltcGxpZXMgYSByZXN0cmljdGlvbiBvbiBjbGllbnQgYmVoYXZpb3IgdGhhdCBpcyBub3Qg YWx3YXlzIGFwcGxpY2FibGUuJm5ic3A7IFRoZSDigJxjbGllbnQgaXMgZGVjbGFyaW5n4oCdIHdv cmRpbmcgd2FzIHNwZWNpZmljIGFuZCBwdXJwb3NlZnVsbHkgY2hvc2VuLCBhbmQgSSB0aGluayBz aG91bGQgYmUgcmV0YWluZWQuJm5ic3A7IEluIHBhcnRpY3VsYXIsIHdlIGNhbuKAmXQgZG8gYW55 dGhpbmcgdGhhdCBpbXBsaWVzIHRoYXQgb25seSB0aGUgcmVnaXN0ZXJlZCBzY29wZXMNCiB2YWx1 ZXMgY2FuIGJlIHVzZWQuJm5ic3A7IEF0IHRoZSBPQXV0aCBzcGVjIGxldmVsLCB0aGlzIGlzIGEg aGludCBhcyB0byBwb3NzaWJsZSBmdXR1cmUgY2xpZW50IGJlaGF2aW9yIOKAkyBub3QgYSByZXN0 cmljdGlvbiBvbiBmdXR1cmUgY2xpZW50IGJlaGF2aW9yLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZv cmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QWxz bywgZm9yIHRoZSByZWFzb25zIHRoYXQgVGltIHN0YXRlZCwgSeKAmW0gc3Ryb25nbHkgYWdhaW5z dCBhbnkg4oCcbWF0Y2hpbmfigJ0gb3Ig4oCccmVnZXjigJ0gbGFuZ3VhZ2UgaW4gdGhlIHNwZWMg cGVydGFpbmluZyB0byBzY29wZXMNCiDigJMgYXMgaXTigJlzIG5vdCBhY3Rpb25hYmxlLjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFr LWJlZm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+U28gSeKAmWQgcHJvcG9zZSB0aGF0IHdlIGxlYXZlIHRoZSBleGlzdGlu ZyBzY29wZSB3b3JkaW5nIGluIHBsYWNlLiZuYnNwOyBBbHRlcm5hdGl2ZWx5LCBJ4oCZZCBhbHNv IGJlIGZpbmUgd2l0aCBkZWxldGluZyB0aGlzIGZlYXR1cmUNCiBlbnRpcmVseSwgYXMgSSBkb27i gJl0IHRoaW5rIGl04oCZcyB1c2VmdWwgaW4gdGhlIGdlbmVyYWwgY2FzZS48L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAtLSBNaWtlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3 aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6d2luZG93dGV4dCI+DQo8YSBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyI+ b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT4gWzxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2Vz QGlldGYub3JnIj5tYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhh bGYgT2YgPC9iPkp1c3RpbiBSaWNoZXI8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBBcHJpbCAx NSwgMjAxMyA4OjA1IEFNPGJyPg0KPGI+VG86PC9iPiBUaW0gQnJheTsgPGEgaHJlZj0ibWFpbHRv Om9hdXRoQGlldGYub3JnIj5vYXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4g UmU6IFtPQVVUSC1XR10gUmVnaXN0cmF0aW9uOiBTY29wZSBWYWx1ZXM8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAwNC8xNS8yMDEzIDEwOjUyIEFNLCBU aW0gQnJheSB3cm90ZTo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J4oCZZCB1c2UgdGhlIGV4aXN0aW5nIHdvcmRpbmc7 IGl04oCZcyBwZXJmZWN0bHkgY2xlYXIuICZuYnNwO0ZhaWxpbmcgdGhhdCwgaWYgdGhlcmXigJlz IHN0cm9uZyBkZW1hbmQgZm9yIHJlZ2lzdHJhdGlvbiBvZiBzdHJ1Y3R1cmVkIHNjb3BlcywgYmxl c3MgdGhlIHVzZSBvZiByZWdleGVzLCBlaXRoZXIgUENSRXMgb3Igc29tZSBjYXJlZnVsIHN1YnNl dC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KVGhh bmtzIGZvciB0aGUgZmVlZGJhY2sgLS0gT2YgdGhlc2UgdHdvIGNob2ljZXMsIEknZCByYXRoZXIg bGVhdmUgaXQgYXMtaXMuIDxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhvd2V2ZXIsIEnigJlk IHN1YnRyYWN0IHRoZSBzZW50ZW5jZSDigJxJZiBvbWl0dGVkLCBhbiBBdXRob3JpemF0aW9uIFNl cnZlciBNQVkgcmVnaXN0ZXIgYSBDbGllbnQgd2l0aCBhIGRlZmF1bHQgc2V0IG9mICZuYnNwO3Nj b3Blcy7igJ0gJm5ic3A7SXQgYWRkcyBubyB2YWx1ZTsgaWYgdGhlIGNsaWVudCBkb2VzbuKAmXQg ZGVjbGFyZSBzY29wZXMsIHRoZSBjbGllbnQgZG9lc27igJl0IGRlY2xhcmUgc2NvcGVzLCB0aGF0 4oCZcyBhbGwuICZuYnNwOy1UPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGJyPg0KUmVtZW1iZXIsIGFsbCBvZiB0aGVzZSBmaWVsZHMgYXJlbid0 IGp1c3QgZm9yIHRoZSBjbGllbnQgKnJlcXVlc3QqLCB0aGV5J3JlIGFsc28gZm9yIHRoZSBzZXJ2 ZXIncyAqcmVzcG9uc2UqIHRvIGVpdGhlciBhIFBPU1QsIFBVVCwgb3IgR0VUIHJlcXVlc3QuIChJ IGRpZG4ndCByZWFsaXplIGl0LCBidXQgcGVyaGFwcyB0aGUgd29yZGluZyBhcyBzdGF0ZWQgcmln aHQgbm93IGRvZXNuJ3QgbWFrZSB0aGF0IGNsZWFyIC0tIEkgbmVlZCB0byBmaXggdGhhdC4pDQog VGhlIHZhbHVlIHRoYXQgaXQgYWRkcyBpcyBpZiB0aGUgY2xpZW50IGRvZXNuJ3QgYXNrIGZvciBh bnkgcGFydGljdWxhciBzY29wZXMsIHRoZSBzZXJ2ZXIgY2FuIHN0aWxsIGFzc2lnbiBpdCBzY29w ZXMgYW5kIHRoZSBjbGllbnQgY2FuIGRvIHNvbWV0aGluZyBzbWFydCB3aXRoIHRoYXQuIER1bWIg Y2xpZW50cyBhcmUgYWxsb3dlZCB0byBpZ25vcmUgaXQgaWYgaXQgZG9lc24ndCBtZWFuIGFueXRo aW5nIHRvIHRoZW0uDQo8YnI+DQo8YnI+DQpUaGlzIGlzIGhvdyBvdXIgc2VydmVyIGltcGxlbWVu dGF0aW9uIGFjdHVhbGx5IHdvcmtzIHJpZ2h0IG5vdy4gSWYgdGhlIGNsaWVudCBkb2Vzbid0IGFz ayBmb3IgYW55dGhpbmcgc3BlY2lmaWMgYXQgcmVnaXN0cmF0aW9uLCB0aGUgc2VydmVyIGhhbmRz IGl0IGEgYmFnIG9mICZxdW90O2RlZmF1bHQmcXVvdDsgc2NvcGVzLiBTYW1lIHRoaW5nIGhhcHBl bnMgYXQgYXV0aCB0aW1lIC0tIGlmIHRoZSBjbGllbnQgZG9lc24ndCBhc2sgZm9yIGFueSBwYXJ0 aWN1bGFyIHNjb3BlcywNCiB0aGUgc2VydmVyIGhhbmRzIGl0IGFsbCBvZiBpdHMgcmVnaXN0ZXJl ZCBzY29wZXMgYXMgYSBkZWZhdWx0LiBHcmFudGVkLCBvbiBvdXIgc2VydmVyLCBzY29wZXMgYXJl IGp1c3Qgc2ltcGxlIHN0cmluZ3MgcmlnaHQgbm93LCBzbyB0aGV5IGdldCBjb21wYXJlZCBhdCB0 aGUgYXV0aCBlbmRwb2ludCB3aXRoIGFuIGV4YWN0IHN0cmluZy1tYXRjaCBtZXRyaWMgYW5kIHNl dC1iYXNlZCBsb2dpYy4NCjxicj4NCjxicj4NCiZuYnNwOy0tIEp1c3Rpbjxicj4NCjxicj4NCjxi cj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBBcHIgMTUsIDIwMTMgYXQgNzozNSBB TSwgSnVzdGluIFJpY2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0cmUub3JnIiB0 YXJnZXQ9Il9ibGFuayI+anJpY2hlckBtaXRyZS5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGF0IHdvdWxkIHlvdSBzdWdnZXN0 IGZvciB3b3JkaW5nIGhlcmUsIHRoZW4/IEtlZXBpbmcgaW4gbWluZCB0aGF0IHdlIGNhbm5vdCAo YW5kIGRvbid0IHdhbnQgdG8pIHByb2hpYml0IGV4cHJlc3Npb24tYmFzZWQgc2NvcGVzLg0KPGJy Pg0KPHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxicj4NCjxzcGFuIGNsYXNzPSJob2VuemIi PiZuYnNwOy0tIEp1c3Rpbjwvc3Bhbj48L3NwYW4+IDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDA0LzE1 LzIwMTMgMTA6MzMgQU0sIFRpbSBCcmF5IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ObywgSSBtZWFuIGl04oCZcyBub3QgaW50ZXJv cGVyYWJsZSBhdCB0aGUgc29mdHdhcmUtZGV2ZWxvcGVyIGxldmVsLiAmbmJzcDtJIGNhbuKAmXQg cmVnaXN0ZXIgc2NvcGVzIGF0IGF1dGhvcml6YXRpb24gdGltZSB3aXRoIGFueSBwcmVkaWN0YWJs ZSBlZmZlY3QgdGhhdCBJIGNhbiB3cml0ZSBjb2RlIHRvIHN1cHBvcnQsIGVpdGhlciBjbGllbnQg b3Igc2VydmVyIHNpZGUsIHdpdGhvdXQgb3V0LW9mLWxpbmUgbm9uLWludGVyb3BlcmFibGUNCiBr bm93bGVkZ2UgYWJvdXQgdGhlIGJlaGF2aW9yIG9mIHRoZSBzZXJ2ZXIuICZuYnNwOyA8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZ3Vlc3MgSeKAmW0ganVz dCBub3QgdXNlZCB0byBPQXV0aOKAmXMgY3VsdHVyZSBvZiBoYXZpbmcgbm8gZXhwZWN0YXRpb24g dGhhdCB0aGluZ3Mgd2lsbCBiZSBzcGVjaWZpZWQgdGlnaHRseSBlbm91Z2ggdGhhdCBJIGNhbiB3 cml0ZSBjb2RlIHRvIGltcGxlbWVudCBhcyBzcGVjaWZpZWQuICZuYnNwOy1UPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T24gTW9uLCBBcHIgMTUsIDIwMTMgYXQgNzoxNSBBTSwgSnVzdGluIFJp Y2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0cmUub3JnIiB0YXJnZXQ9Il9ibGFu ayI+anJpY2hlckBtaXRyZS5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TY29wZXMgYXJlbid0IG1lYW50IHRvIGJlIGludGVyb3Bl cmFibGUgYmV0d2VlbiBzZXJ2aWNlcyBzaW5jZSB0aGV5J3JlIG5lY2Vzc2FyaWx5IEFQSS1zcGVj aWZpYy4gVGhlIG9ubHkgaW50ZXJvcGVyYWJsZSBiaXQgaXMgdGhhdCB0aGVyZSdzICpzb21lKiBw bGFjZSB0byBwdXQgdGhlIHZhbHVlcyBhbmQgdGhhdCBpdCdzIGV4cHJlc3NlZCBhcyBhIGJhZyBv ZiBzcGFjZS1zZXBhcmF0ZWQgc3RyaW5ncy4gSG93DQogdGhvc2Ugc3RyaW5ncyBnZXQgaW50ZXJw cmV0ZWQgYW5kIGVuZm9yY2VkICh3aGljaCBpcyByZWFsbHkgd2hhdCdzIGF0IHN0YWtlIGhlcmUp IGlzIHVwIHRvIHRoZSBBUyBhbmQgUFIgKG9yIGEgaGlnaGVyLWxldmVsIHByb3RvY29sIGxpa2Ug VU1BKS48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PGJyPg0KPGJyPg0KJm5ic3A7LS0gSnVz dGluPC9zcGFuPiA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAwNC8xNS8yMDEzIDEwOjEzIEFNLCBUaW0g QnJheSB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cD5UaGlzLCBhcyB3cml0dGVu LCBoYXMgemVybyBpbnRlcm9wZXJhYmlsaXR5LiZuYnNwOyBJIHRoaW5rIHRoaXMgZmVhdHVyZSBj YW4gcmVhbGx5IG9ubHkgYmUgbWFkZSB1c2VmdWwgaW4gdGhlIGNhc2Ugd2hlcmUgc2NvcGVzIGFy ZSBmaXhlZCBzdHJpbmdzLjxvOnA+PC9vOnA+PC9wPg0KPHA+LVQ8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBBcHIgMTUsIDIwMTMgNjo1NCBBTSwgJnF1b3Q7 SnVzdGluIFJpY2hlciZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0cmUub3Jn IiB0YXJnZXQ9Il9ibGFuayI+anJpY2hlckBtaXRyZS5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPllvdSBhcmUgY29ycmVjdCB0aGF0IHRoZSBpZGVhIGJlaGluZCB0aGUgJnF1b3Q7 c2NvcGUmcXVvdDsgcGFyYW1ldGVyIGF0IHJlZ2lzdHJhdGlvbiBpcyBhIGNvbnN0cmFpbnQgb24g YXV0aG9yaXphdGlvbi10aW1lIHNjb3BlcyB0aGF0IGFyZSBtYWRlIGF2YWlsYWJsZS4gSXQncyBi b3RoIGEgbWVhbnMgZm9yIHRoZSBjbGllbnQgdG8gcmVxdWVzdCBhIHNldCBvZiB2YWxpZCBzY29w ZXMNCiBhbmQgZm9yIHRoZSBzZXJ2ZXIgdG8gcHJvdmlzaW9uIChhbmQgZWNobyBiYWNrIHRvIHRo ZSBjbGllbnQpIGEgc2V0IG9mIHZhbGlkIHNjb3Blcy48YnI+DQo8YnI+DQpJICpyZWFsbHkqIGRv bid0IHdhbnQgdG8gdHJ5IHRvIGRlZmluZSBhIG1hdGNoaW5nIGxhbmd1YWdlIGZvciBzY29wZSBl eHByZXNzaW9ucy4gRm9yIHRoYXQgdG8gd29yaywgYWxsIHNlcnZlcnMgd291bGQgbmVlZCB0byBi ZSBhYmxlIHRvIHByb2Nlc3MgdGhlIHJlZ3VsYXIgZXhwcmVzc2lvbnMgZm9yIGFsbCBjbGllbnRz LCBldmVuIGlmIHRoZSBzZXJ2ZXJzIHRoZW1zZWx2ZXMgb25seSBzdXBwb3J0IHNpbXBsZS1zdHJp bmcgc2NvcGUgdmFsdWVzLg0KIEFueSByZWd1bGFyIGV4cHJlc3Npb24gc3ludGF4IHdlIHBpY2sg aGVyZSBpcyBndWFyYW50ZWVkIHRvIGJlIGluY29tcGF0aWJsZSB3aXRoIHNvbWV0aGluZywgYW5k IEkgdGhpbmsgdGhlIGNvbXBsZXhpdHkgZG9lc24ndCBidXkgbXVjaC4gQWxzbywgSSB0aGluayB5 b3Ugc3VkZGVubHkgaGF2ZSBhIHBvdGVudGlhbCBzZWN1cml0eSBpc3N1ZSBpZiB5b3UgaGF2ZSBh IGJhZCByZWdleCBpbiBwbGFjZSBvbiBlaXRoZXIgZW5kLg0KPGJyPg0KPGJyPg0KQXMgaXQgc3Rh bmRzIHRvZGF5LCB0aGUgc2VydmVyIGNhbiBpbnRlcnByZXQgdGhlIGluY29taW5nIHJlZ2lzdHJh dGlvbiBzY29wZXMgYW5kIGVuZm9yY2UgdGhlbSBob3dldmVyIGl0IHdhbnRzIHRvLiBUaGUgcmVh bCB0cmljayBjb21lcyBub3QgZnJvbSBhc3NpZ25pbmcgdGhlIHZhbHVlcyB0byBhIHBhcnRpY3Vs YXIgY2xpZW50IGJ1dCB0byBlbmZvcmNpbmcgdGhlbSwgYW5kIEkgdGhpbmsgdGhhdCdzIGFsd2F5 cyBnb2luZyB0byBiZSBzZXJ2aWNlLXNwZWNpZmljLg0KIFdlJ3JlIGp1c3Qgbm90IGFzIGNsZWFy IG9uIHRoYXQgYXMgd2UgY291bGQgYmUuPGJyPg0KPGJyPg0KQWZ0ZXIgbG9va2luZyBvdmVyIGV2 ZXJ5b25lJ3MgY29tbWVudHMgc28gZmFyLCBJJ2QgbGlrZSB0byBwcm9wb3NlIHRoZSBmb2xsb3dp bmcgdGV4dCBmb3IgdGhhdCBzZWN0aW9uOjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9v OnA+PC9wPg0KPHByZT4mbmJzcDsmbmJzcDsgc2NvcGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgT1BUSU9OQUwuJm5ic3A7IFNwYWNlIHNlcGFy YXRlZCBsaXN0IG9mIHNjb3BlIHZhbHVlcyAoYXMgZGVzY3JpYmVkIGluPG86cD48L286cD48L3By ZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9BdXRoIDIuMCA8YSBocmVm PSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2NzQ5I3NlY3Rpb24tMy4zIiB0YXJnZXQ9 Il9ibGFuayI+U2VjdGlvbiZuYnNwOzMuMyBbUkZDNjc0OV08L2E+KSB0aGF0IHRoZSBjbGllbnQg Y2FuIHVzZSB3aGVuIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwO3JlcXVlc3RpbmcgYWNjZXNzIHRva2Vucy4mbmJzcDsgQXMgc2NvcGUg dmFsdWVzIGFyZSBzZXJ2aWNlLXNwZWNpZmljLCA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIg TUFZIGRlZmluZSBpdHMgb3duIG1hdGNoaW5nIHJ1bGVzIHdoZW48bzpwPjwvbzpwPjwvcHJlPg0K PHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7ZGV0ZXJtaW5pbmcgaWYgYSBzY29w ZSB2YWx1ZSB1c2VkIGR1cmluZyBhbiBhdXRob3JpemF0aW9uIHJlcXVlc3Q8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaXMgdmFsaWQgYWNjb3Jk aW5nIHRvIHRoZSBzY29wZSB2YWx1ZXMgYXNzaWduZWQgZHVyaW5nIDxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3JlZ2lzdHJhdGlvbi4g UG9zc2libGUgbWF0Y2hpbmcgcnVsZXMgaW5jbHVkZSB3aWxkY2FyZCBwYXR0ZXJucyw8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7cmVndWxhciBl eHByZXNzaW9ucywgb3IgZXhhY3RseSBtYXRjaGluZyB0aGUgc3RyaW5nLiBJZiBvbWl0dGVkLCA8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDthbiBBdXRob3JpemF0aW9uIFNlcnZlciBNQVkgcmVnaXN0ZXIgYSBDbGllbnQgd2l0aCBhIGRl ZmF1bHQgPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7c2V0IG9mIHNjb3Blcy48bzpwPjwvbzpwPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpDb21tZW50cz8gSW1wcm92 ZW1lbnRzPzxicj4NCjxicj4NCiZuYnNwOy0tIEp1c3Rpbjxicj4NCjxicj4NCjxicj4NCjxicj4N CjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDA0LzE0LzIw MTMgMDg6MjMgUE0sIE1hbmdlciwgSmFtZXMgSCB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8cHJlPlByZXN1bWFibHkgYXQgYXBwIHJlZ2lzdHJhdGlvbiB0aW1lIGFueSBzY29wZSBz cGVjaWZpY2F0aW9uIGlzIHJlYWxseSBhIGNvbnN0cmFpbnQgb24gdGhlIHNjb3BlIHZhbHVlcyB0 aGF0IGNhbiBiZSByZXF1ZXN0ZWQgaW4gYW4gYXV0aG9yaXphdGlvbiBmbG93LjxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlNvIGlkZWFsbHkgcmVn aXN0cmF0aW9uIHNob3VsZCBhY2NlcHQgcnVsZXMgZm9yIG1hdGNoaW5nIHNjb3BlcywgYXMgb3Bw b3NlZCB0byBhY3R1YWwgc2NvcGUgdmFsdWVzLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNw OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPllvdSBjYW4gdHJ5IHRvIHVzZSBzY29wZSB2YWx1ZXMg YXMgdGhlaXIgb3duIG1hdGNoaW5nIHJ1bGVzLiBUaGF0IGlzIGZpbmUgZm9yIGEgc21hbGwgc2V0 IG9mICZxdW90O3N0YXRpYyZxdW90OyBzY29wZXMuIEl0IHN0YXJ0cyB0byBmYWlsIHdoZW4gdGhl cmUgYXJlIGEgbGFyZ2UgbnVtYmVyIG9mIHNjb3Blcywgb3Igc2NvcGVzIHRoYXQgY2FuIGluY2x1 ZGUgcGFyYW1ldGVycyAocmVzb3VyY2UgcGF0aHM/IGVtYWlsIGFkZHJlc3Nlcz8pLiBZb3UgY2Fu IHRyeSB0byBwYXRjaCB0aG9zZSBmYWlsdXJlcyBieSBhbGxvd2luZyBzZXJ2aWNlcyB0byBkZWZp bmUgc2VydmljZS1zcGVjaWZpYyBzcGVjaWFsICZxdW90O3dpbGRjYXJkJnF1b3Q7IHNjb3BlIHZh bHVlcyB0aGF0IGNhbiBvbmx5IGJlIHVzZWQgZHVyaW5nIHJlZ2lzdHJhdGlvbiAoZWcgJnF1b3Q7 cmVhZDoqJnF1b3Q7KS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT5BbHRlcm5hdGl2ZWx5LCByZXBsYWNlICdzY29wZScgaW4gcmVnaXN0cmF0aW9u IHdpdGggJ3Njb3BlX3JlZ2V4JyB0aGF0IGhvbGRzIGEgcmVndWxhciBleHByZXNzaW9uIHRoYXQg YWxsIHNjb3BlIHZhbHVlcyBpbiBhbiBhdXRob3JpemF0aW9uIGZsb3cgbXVzdCBtYXRjaC48bzpw PjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4tLTxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPkphbWVzIE1hbmdlcjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48 L3ByZT4NCjxwcmU+T0F1dGggbWFpbGluZyBsaXN0PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEg aHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5v cmc8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3ByZT4NCjwvYmxv Y2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxi cj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K T0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv YmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_4E1F6AAD24975D4BA5B16804296739436766BCC4TK5EX14MBXC284r_-- From twbray@google.com Thu Apr 18 08:36:38 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0290E21F8F76 for ; Thu, 18 Apr 2013 08:36:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yc6rF++CFrii for ; Thu, 18 Apr 2013 08:36:36 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id C34BC21F8F6D for ; Thu, 18 Apr 2013 08:36:35 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id aq17so2058522iec.9 for ; Thu, 18 Apr 2013 08:36:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=0MvnHXcw+XQ1Ulyts8sAAm8FRZmJz2xZ8tbxL80/MAI=; b=XOk+FgwWCUQEwiuXO1ktcCvaJVe6BKEkUv7qHC9NiWj43Fh7Z3tAVfZNQqJMIzHlA7 r2XHDaQPfkfdWnJNYfTI7A2UChowcrZ3Ai5d5nnElA6dXKBgbCWoV4rTpgRIfj/ORuvM PqcVaH2xnPOP6V7Wx7b200JDe51QwK5Ce7NRbs4/UpidQjODTNG9qhEt5XQ/CPM4GEa6 Nhhq9HtIb/nS/KHb/Fc4DGiLpAJZz3HnOUg2277miwWInSLNGTwGt9pPrinJSqkB/lnE PDND2TP6V/EAiybKzHo93SqGlz5Xx2534xI911s5qw5qLY6kkynxv6iJeQbQyubxjD9u 5zuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=0MvnHXcw+XQ1Ulyts8sAAm8FRZmJz2xZ8tbxL80/MAI=; b=eUa6GiYMXqXG0PHK/DpMQqJ748sNMLjmJYFzbwQ4uf4WlMZJMIZnAiWwhxc8Gc1blW D0GxOmT0hpfaGRND8ED8m3aVVZJbjZ48389By5oM+rk2OkRwfzMGb4+aJ3GwWYk6TkGD GEEhUoZg+Ng1LGPUKAJk543faTeDIOrk5suiaoKcJ8Hv89HcEfGGmsaRGIpHZUinsC65 54m6G1tgklhp04KFDz7v1yT9yx+9V4sIRmbmK/qP+IOpn//DidX1ikVpXcEQDrF9QQ3U PiokPFKwJowI/HhDyasJGJxfvUsnFsHTlNwRCGkkrgySsmjM/AobF3wIpJ1PCXSNwoqY nlXQ== X-Received: by 10.50.72.83 with SMTP id b19mr130410igv.71.1366299395302; Thu, 18 Apr 2013 08:36:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.31.35 with HTTP; Thu, 18 Apr 2013 08:36:04 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436766BCC4@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <255B9BB34FB7D647A506DC292726F6E1150C74DADA@WSMSG3153V.srv.dir.telstra.com> <516C069F.9090308@mitre.org> <516C0B9D.6000402@mitre.org> <516C101F.2090706@mitre.org> <516C1714.8070503@mitre.org> <4E1F6AAD24975D4BA5B168042967394367641A87@TK5EX14MBXC283.redmond.corp.microsoft.com> <516C3152.9070603@mitre.org> <4E1F6AAD24975D4BA5B168042967394367641FAB@TK5EX14MBXC283.redmond.corp.microsoft.com> <516C54F2.8040708@mitre.org> <4E1F6AAD24975D4BA5B16804296739436766BCC4@TK5EX14MBXC284.redmond.corp.microsoft.com> From: Tim Bray Date: Thu, 18 Apr 2013 08:36:04 -0700 Message-ID: To: Mike Jones Content-Type: multipart/alternative; boundary=047d7bdc19d41d92e404daa45ec8 X-Gm-Message-State: ALoCoQleO9aD4fFN20Bk3egyizImdUy5SwUI57KjdMAp2o0HsfyqWC/KbhWGR68QqZFxLKDOg8cKlY0zyEEFMtSb3UcVXJvuy+MMHhp7gV4LC782pEJNq9lizha+dFxhXMv/XAKFEElzYu//Tzvk9aDyFg+J4P4vpy2Tg82CbsJrasuksghpYJCqNZ7BrtAEqKHiEQtgqT/h Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Registration: Scope Values X-BeenThere: oauth@ietf.org X-Mailman-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, 18 Apr 2013 15:36:38 -0000 --047d7bdc19d41d92e404daa45ec8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On the server-to-client side, what does =E2=80=9Cregistered to use=E2=80=9D= mean? Does it mean that the client should assume that any scopes not on the list WILL not be granted, MAY not be granted.... or what? Is this already covered elsewhere? -T On Thu, Apr 18, 2013 at 8:28 AM, Mike Jones wr= ote: > Thanks, Justin. I agree with the need for the generic two-sided > language. I=E2=80=99d still keep this language for scope, because we wan= t to > capture the =E2=80=9Cdeclaring=E2=80=9D aspect in this case:**** > > ** ** > > =E2=80=9CSpace separated list of scope values (as described in OAuth 2.0 = Section 3.3 > [RFC6749] ) that the > client is declaring to the server that it may use when requesting access > tokens and that the server is declaring to the client that it is register= ed > to use when requesting access tokens.=E2=80=9D.**** > > ** ** > > You should probably also reinforce that scope values are service-specific > and may not consist only of a static set of string values, and that > therefore, in some cases, an exhaustive list of registered scope values i= s > not possible.**** > > ** ** > > -- Mike**** > > ** ** > > *From:* Justin Richer [mailto:jricher@mitre.org] > *Sent:* Monday, April 15, 2013 12:29 PM > > *To:* Mike Jones > *Cc:* Tim Bray; oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Registration: Scope Values**** > > ** ** > > I think that because the "declaration" issue affects all parameters in th= e > list, not just scope, we should adopt this in a higher level paragraph an= d > leave it out of the individual parameter descriptions. Thus, something li= ke > this inserted as the second paragraph in section 2:**** > > The client metadata values serve two parallel purposes in the overall > OAuth Dynamic Registration protocol: > > - the Client requesting its desired values for each parameter to the > Authorization Server in a [register] or [update] request, > - the Authorization Server informing the Client of the current values of > each parameter that the Client has been registered to use through a [clie= nt > information response]. > > An Authorization Server MAY override any value that a Client requests > during the registration process (including any omitted values) and replac= e > the requested value with a default. The normative indications in the > following list apply to the Client's declaration of its desired values. > > The Authorization Server SHOULD provide documentation for any fields that > it requires to be filled in by the client or to have particular values or > formats. Extensions and profiles...**** > > > And then remove the sidedness-language from the scope parameter and any > other parameters where it might have crept in inadvertently. > > -- Justin**** > > On 04/15/2013 01:29 PM, Mike Jones wrote:**** > > We could fix the one-sided language by changing**** > > =E2=80=9CSpace separated list of scope values (as described in OAuth 2.0 = Section 3.3 > [RFC6749] ) that the > client is declaring that it may use when requesting access tokens.=E2=80= =9D**** > > to**** > > =E2=80=9CSpace separated list of scope values (as described in OAuth 2.0 = Section 3.3 > [RFC6749] ) that the > client is declaring to the server that it may use when requesting access > tokens and that the server is declaring to the client that it is register= ed > to use when requesting access tokens.=E2=80=9D.**** > > **** > > Again, I chose the =E2=80=9Cregistered to use=E2=80=9D language carefully= =E2=80=93 because in the > general case it=E2=80=99s not a restriction on the values that the client= can use =E2=80=93 > just a statement by the server to the client that it is registered to use > those particular values. In both cases, the parties are making > declarations to one another.**** > > **** > > If you adopt that language (or keep the original language), then yes, I= =E2=80=99d > consider this closed.**** > > **** > > -- Mike**** > > **** > > *From:* Justin Richer [mailto:jricher@mitre.org ] > *Sent:* Monday, April 15, 2013 9:57 AM > *To:* Mike Jones > *Cc:* Tim Bray; oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Registration: Scope Values**** > > **** > > I absolutely do not want to delete this feature, as (having implemented > it) I think it's very useful. This is a very established pattern in manua= l > registration: I know of many, many OAuth2 servers and clients that are se= t > up where the client must pre-register a set of scopes. > > I don't like the language of "the client is declaring" because it's too > one-sided. The client might not have declared anything, and it might be t= he > server that's declaring something to the client. Deleting the "is > declaring" bit removes that unintended restriction of the language while > keeping the original meaning intact. I actually thought that I had fixed > that before the last draft went in but apparently I missed this one. > > I will work on clarifying the intent of the whole metadata set in its > introductory paragraph(s) so that it's clear that all of these fields are > used in both of these situations: > > 1) The client declaring to the server its desire to use a particular val= ue > 2) The server declaring to the client that it has been registered with a > particular value > > This should hopefully clear up the issue in the editor's note that I > currently have at the top of that section right now, too. > > Mike, since you were the one who originally brought up the issue, and > you're fine with the existing text, can I take this as closed now? Assumi= ng > that you agree with deleting "is declaring" for reasons stated above, I'm > fine with leaving everything else as is and staying quiet on what the > server has to do with the scopes. > > -- Justin > > > **** > > On 04/15/2013 12:44 PM, Mike Jones wrote:**** > > I think that the existing wording is superior to the proposed changed > wording. The existing wording is:**** > > **** > > scope**** > > OPTIONAL. Space separated list of scope values (as described in***= * > > OAuth 2.0 Section 3.3 [RFC6749]) > that the client is declaring that**** > > it may use when requesting access tokens. If omitted, an**** > > Authorization Server MAY register a Client with a default set of***= * > > scopes.**** > > **** > > For instance, the current =E2=80=9Cclient is declaring=E2=80=9D wording w= ill always be > correct, whereas as the change to =E2=80=9Cclient can use=E2=80=9D wordin= g implies a > restriction on client behavior that is not always applicable. The =E2=80= =9Cclient > is declaring=E2=80=9D wording was specific and purposefully chosen, and I= think > should be retained. In particular, we can=E2=80=99t do anything that imp= lies that > only the registered scopes values can be used. At the OAuth spec level, > this is a hint as to possible future client behavior =E2=80=93 not a rest= riction on > future client behavior.**** > > **** > > Also, for the reasons that Tim stated, I=E2=80=99m strongly against any = =E2=80=9Cmatching=E2=80=9D > or =E2=80=9Cregex=E2=80=9D language in the spec pertaining to scopes =E2= =80=93 as it=E2=80=99s not > actionable.**** > > **** > > So I=E2=80=99d propose that we leave the existing scope wording in place. > Alternatively, I=E2=80=99d also be fine with deleting this feature entire= ly, as I > don=E2=80=99t think it=E2=80=99s useful in the general case.**** > > **** > > -- Mike**** > > **** > > *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] > *On Behalf Of *Justin Richer > *Sent:* Monday, April 15, 2013 8:05 AM > *To:* Tim Bray; oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Registration: Scope Values**** > > **** > > On 04/15/2013 10:52 AM, Tim Bray wrote: > > > > **** > > I=E2=80=99d use the existing wording; it=E2=80=99s perfectly clear. Fail= ing that, if > there=E2=80=99s strong demand for registration of structured scopes, bles= s the use > of regexes, either PCREs or some careful subset.**** > > > Thanks for the feedback -- Of these two choices, I'd rather leave it > as-is. > > > > > **** > > **** > > However, I=E2=80=99d subtract the sentence =E2=80=9CIf omitted, an Author= ization Server > MAY register a Client with a default set of scopes.=E2=80=9D It adds no= value; if > the client doesn=E2=80=99t declare scopes, the client doesn=E2=80=99t dec= lare scopes, > that=E2=80=99s all. -T**** > > > Remember, all of these fields aren't just for the client *request*, > they're also for the server's *response* to either a POST, PUT, or GET > request. (I didn't realize it, but perhaps the wording as stated right no= w > doesn't make that clear -- I need to fix that.) The value that it adds is > if the client doesn't ask for any particular scopes, the server can still > assign it scopes and the client can do something smart with that. Dumb > clients are allowed to ignore it if it doesn't mean anything to them. > > This is how our server implementation actually works right now. If the > client doesn't ask for anything specific at registration, the server hand= s > it a bag of "default" scopes. Same thing happens at auth time -- if the > client doesn't ask for any particular scopes, the server hands it all of > its registered scopes as a default. Granted, on our server, scopes are ju= st > simple strings right now, so they get compared at the auth endpoint with = an > exact string-match metric and set-based logic. > > -- Justin > > > > > **** > > **** > > On Mon, Apr 15, 2013 at 7:35 AM, Justin Richer wrote:= * > *** > > What would you suggest for wording here, then? Keeping in mind that we > cannot (and don't want to) prohibit expression-based scopes. > > -- Justin **** > > **** > > On 04/15/2013 10:33 AM, Tim Bray wrote:**** > > No, I mean it=E2=80=99s not interoperable at the software-developer leve= l. I > can=E2=80=99t register scopes at authorization time with any predictable = effect > that I can write code to support, either client or server side, without > out-of-line non-interoperable knowledge about the behavior of the server. > **** > > **** > > I guess I=E2=80=99m just not used to OAuth=E2=80=99s culture of having no= expectation that > things will be specified tightly enough that I can write code to implemen= t > as specified. -T**** > > **** > > On Mon, Apr 15, 2013 at 7:15 AM, Justin Richer wrote:= * > *** > > Scopes aren't meant to be interoperable between services since they're > necessarily API-specific. The only interoperable bit is that there's *som= e* > place to put the values and that it's expressed as a bag of space-separat= ed > strings. How those strings get interpreted and enforced (which is really > what's at stake here) is up to the AS and PR (or a higher-level protocol > like UMA). > > -- Justin **** > > **** > > On 04/15/2013 10:13 AM, Tim Bray wrote:**** > > This, as written, has zero interoperability. I think this feature can > really only be made useful in the case where scopes are fixed strings.***= * > > -T**** > > On Apr 15, 2013 6:54 AM, "Justin Richer" wrote:**** > > You are correct that the idea behind the "scope" parameter at registratio= n > is a constraint on authorization-time scopes that are made available. It'= s > both a means for the client to request a set of valid scopes and for the > server to provision (and echo back to the client) a set of valid scopes. > > I *really* don't want to try to define a matching language for scope > expressions. For that to work, all servers would need to be able to proce= ss > the regular expressions for all clients, even if the servers themselves > only support simple-string scope values. Any regular expression syntax we > pick here is guaranteed to be incompatible with something, and I think th= e > complexity doesn't buy much. Also, I think you suddenly have a potential > security issue if you have a bad regex in place on either end. > > As it stands today, the server can interpret the incoming registration > scopes and enforce them however it wants to. The real trick comes not fro= m > assigning the values to a particular client but to enforcing them, and I > think that's always going to be service-specific. We're just not as clear > on that as we could be. > > After looking over everyone's comments so far, I'd like to propose the > following text for that section: > > > > **** > > scope**** > > OPTIONAL. Space separated list of scope values (as described in***= * > > OAuth 2.0 Section 3.3 [RFC6749] ) that the client can use when **** > > requesting access tokens. As scope values are service-specific, **= ** > > the Authorization Server MAY define its own matching rules when**** > > determining if a scope value used during an authorization request**= ** > > is valid according to the scope values assigned during **** > > registration. Possible matching rules include wildcard patterns,***= * > > regular expressions, or exactly matching the string. If omitted, **= ** > > an Authorization Server MAY register a Client with a default **** > > set of scopes.**** > > > Comments? Improvements? > > -- Justin > > > > **** > > On 04/14/2013 08:23 PM, Manger, James H wrote:**** > > Presumably at app registration time any scope specification is really a c= onstraint on the scope values that can be requested in an authorization flo= w.**** > > **** > > So ideally registration should accept rules for matching scopes, as oppos= ed to actual scope values.**** > > **** > > You can try to use scope values as their own matching rules. That is fine= for a small set of "static" scopes. It starts to fail when there are a lar= ge number of scopes, or scopes that can include parameters (resource paths?= email addresses?). You can try to patch those failures by allowing service= s to define service-specific special "wildcard" scope values that can only = be used during registration (eg "read:*").**** > > **** > > Alternatively, replace 'scope' in registration with 'scope_regex' that ho= lds a regular expression that all scope values in an authorization flow mus= t match.**** > > **** > > --**** > > James Manger**** > > _______________________________________________**** > > 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**** > > **** > > **** > > **** > > **** > > **** > > **** > > ** ** > --047d7bdc19d41d92e404daa45ec8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On the server-to-client side, what does =E2=80=9Cregistere= d to use=E2=80=9D mean? =C2=A0Does it mean that the client should assume th= at any scopes not on the list WILL not be granted, MAY not be granted.... o= r what? =C2=A0Is this already covered elsewhere? -T


On Thu, Apr 1= 8, 2013 at 8:28 AM, Mike Jones <Michael.Jones@microsoft.com&= gt; wrote:

Thanks, Justin.=C2=A0 I a= gree with the need for the generic two-sided language.=C2=A0 I=E2=80=99d st= ill keep this language for scope, because we want to capture the =E2=80=9Cd= eclaring=E2=80=9D aspect in this case:

=C2=A0

Space separated list of scope values (as described in OAuth 2.0 Section=C2=A03.3 [RFC6749]) that the client is declaring to the server = that it may use when requesting access tokens and that the server is declar= ing to the client that it is registered to use when requesting access token= s.=E2=80=9D.

=C2=A0

You should probably= also reinforce that scope values are service-specific and may not consist = only of a static set of string values, and that therefore, in some cases, an exhaustive list of registered scope values is not possible.=

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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

=C2=A0

From: Justin Richer [mailto:jricher@mitre.org]
Sent: Monday, April 15, 2013 12:29 PM


To: Mike Jones
Cc: Tim Bray; oa= uth@ietf.org
Subject: Re: [OAUTH-WG] Registration: Scope Values

=C2=A0

I think that because = the "declaration" issue affects all parameters in the list, not j= ust scope, we should adopt this in a higher level paragraph and leave it ou= t of the individual parameter descriptions. Thus, something like this inserted as the second paragraph in section 2:<= u>

The client metadata values serve two parallel purpos= es in the overall OAuth Dynamic Registration protocol:

=C2=A0- the Client requesting its desired values for each parameter to the = Authorization Server in a [register] or [update] request,
=C2=A0- the Authorization Server informing the Client of the current values= of each parameter that the Client has been registered to use through a [cl= ient information response].

An Authorization Server MAY override any value that a Client requests durin= g the registration process (including any omitted values) and replace the r= equested value with a default. The normative indications in the following l= ist apply to the Client's declaration of its desired values.

The Authorization Server SHOULD provide documentation for any fields that i= t requires to be filled in by the client or to have particular values or fo= rmats. Extensions and profiles...


And then remove the sidedness-language from the scope parameter and any oth= er parameters where it might have crept in inadvertently.

=C2=A0-- Justin

On 04/15/2013 01:29 PM, Mike Jones wrote:<= /u>

We could fix the one-side= d language by changing

Space separated list of scope values (as described in OAuth 2.0 Section=C2=A03.3 [RFC6749]) that the client is declaring that it may us= e when requesting access tokens.=E2=80=9D=

to

Space separated list of scope values (as described in OAuth 2.0 Section=C2=A03.3 [RFC6749]) that the client is declaring to the server = that it may use when requesting access tokens and that the server is declar= ing to the client that it is registered to use when requesting access token= s.=E2=80=9D.

=C2=A0

Again, I chose the =E2=80= =9Cregistered to use=E2=80=9D language carefully =E2=80=93 because in the g= eneral case it=E2=80=99s not a restriction on the values that the client can use =E2=80=93 just a statement by the server to the cl= ient that it is registered to use those particular values.=C2=A0 In both ca= ses, the parties are making declarations to one another.

=C2=A0

If you adopt that languag= e (or keep the original language), then yes, I=E2=80=99d consider this clos= ed.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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

=C2=A0

From: Justin Richer [mailto:jricher@mitre.org]
Sent: Monday, April 15, 2013 9:57 AM
To: Mike Jones
Cc: Tim Bray; oa= uth@ietf.org
Subject: Re: [OAUTH-WG] Registration: Scope Values<= /u>

=C2=A0

I absolutely do not w= ant to delete this feature, as (having implemented it) I think it's ver= y useful. This is a very established pattern in manual registration: I know= of many, many OAuth2 servers and clients that are set up where the client must pre-register a set of scopes.

I don't like the language of "the client is declaring" becaus= e it's too one-sided. The client might not have declared anything, and = it might be the server that's declaring something to the client. Deleti= ng the "is declaring" bit removes that unintended restriction of the language while keeping the original meaning intact. I actually thou= ght that I had fixed that before the last draft went in but apparently I mi= ssed this one.

I will work on clarifying the intent of the whole metadata set in its intro= ductory paragraph(s) so that it's clear that all of these fields are us= ed in both of these situations:

=C2=A01) The client declaring to the server its desire to use a particular = value
=C2=A02) The server declaring to the client that it has been registered wit= h a particular value

This should hopefully clear up the issue in the editor's note that I cu= rrently have at the top of that section right now, too.

Mike, since you were the one who originally brought up the issue, and you&#= 39;re fine with the existing text, can I take this as closed now? Assuming = that you agree with deleting "is declaring" for reasons stated ab= ove, I'm fine with leaving everything else as is and staying quiet on what the server has to do with the scopes.

=C2=A0-- Justin


On 04/15/2013 12:44 PM, Mike Jones wrote:<= /u>

I think that the existing= wording is superior to the proposed changed wording.=C2=A0 The existing wo= rding is:

=C2=A0

=C2=A0=C2=A0 scope

=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 OPTIONAL.=C2=A0 Space separated list of scope values (as described in

=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 OAuth 2.0 Section=C2=A03.3 [RFC6749]) that the client is declaring that<= u>

=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 it may use when requesting access tokens.=C2=A0 If omitted, an

=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Authorization Server MAY register a Client with a default set of=

=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 scopes.

=C2=A0

For instance, the current= =E2=80=9Cclient is declaring=E2=80=9D wording will always be correct, wher= eas as the change to =E2=80=9Cclient can use=E2=80=9D wording implies a restriction on client behavior that is not always applicable.=C2= =A0 The =E2=80=9Cclient is declaring=E2=80=9D wording was specific and purp= osefully chosen, and I think should be retained.=C2=A0 In particular, we ca= n=E2=80=99t do anything that implies that only the registered scopes values can be used.=C2=A0 At the OAuth spec level, this is a hint as to po= ssible future client behavior =E2=80=93 not a restriction on future client = behavior.

=C2=A0

Also, for the reasons tha= t Tim stated, I=E2=80=99m strongly against any =E2=80=9Cmatching=E2=80=9D o= r =E2=80=9Cregex=E2=80=9D language in the spec pertaining to scopes =E2=80=93 as it=E2=80=99s not actionable.

=C2=A0

So I=E2=80=99d propose th= at we leave the existing scope wording in place.=C2=A0 Alternatively, I=E2= =80=99d also be fine with deleting this feature entirely, as I don=E2=80=99t think it=E2=80=99s useful in the general case= .

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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

=C2=A0

From: oauth-bounces@i= etf.org [ma= ilto:oauth-bounces@ietf.org] On Behalf Of Justin Richer
Sent: Monday, April 15, 2013 8:05 AM
To: Tim Bray; oa= uth@ietf.org
Subject: Re: [OAUTH-WG] Registration: Scope Values<= /u>

=C2=A0

On 04/15/2013 10:52 AM, Tim Bray wrote:



I=E2=80=99d use the existing wording; it=E2=80=99s p= erfectly clear. =C2=A0Failing that, if there=E2=80=99s strong demand for re= gistration of structured scopes, bless the use of regexes, either PCREs or = some careful subset.


Thanks for the feedback -- Of these two choices, I'd rather leave it as= -is.




=C2=A0

However, I=E2=80=99d subtract the sentence =E2=80=9C= If omitted, an Authorization Server MAY register a Client with a default se= t of =C2=A0scopes.=E2=80=9D =C2=A0It adds no value; if the client doesn=E2= =80=99t declare scopes, the client doesn=E2=80=99t declare scopes, that=E2= =80=99s all. =C2=A0-T


Remember, all of these fields aren't just for the client *request*, the= y're also for the server's *response* to either a POST, PUT, or GET= request. (I didn't realize it, but perhaps the wording as stated right= now doesn't make that clear -- I need to fix that.) The value that it adds is if the client doesn't ask for any particular= scopes, the server can still assign it scopes and the client can do someth= ing smart with that. Dumb clients are allowed to ignore it if it doesn'= t mean anything to them.

This is how our server implementation actually works right now. If the clie= nt doesn't ask for anything specific at registration, the server hands = it a bag of "default" scopes. Same thing happens at auth time -- = if the client doesn't ask for any particular scopes, the server hands it all of its registered scopes as a default. Granted, on= our server, scopes are just simple strings right now, so they get compared= at the auth endpoint with an exact string-match metric and set-based logic= .

=C2=A0-- Justin




=C2=A0<= /p>

On Mon, Apr 15, 2013 at 7:35 AM, Justin Richer <<= a href=3D"mailto:jricher@mitre.org" target=3D"_blank">jricher@mitre.org= > wrote:

What would you suggest for wording here, then? Keepi= ng in mind that we cannot (and don't want to) prohibit expression-based= scopes.

=C2=A0-- Justin

=C2=A0<= /p>

On 04/15/2013 10:33 AM, Tim Bray wrote:

No, I mean it=E2=80=99s not interoperable at the sof= tware-developer level. =C2=A0I can=E2=80=99t register scopes at authorizati= on time with any predictable effect that I can write code to support, eithe= r client or server side, without out-of-line non-interoperable knowledge about the behavior of the server. =C2=A0

=C2=A0

I guess I=E2=80=99m just not used to OAuth=E2=80=99s= culture of having no expectation that things will be specified tightly eno= ugh that I can write code to implement as specified. =C2=A0-T=

=C2=A0<= /p>

On Mon, Apr 15, 2013 at 7:15 AM, Justin Richer <<= a href=3D"mailto:jricher@mitre.org" target=3D"_blank">jricher@mitre.org= > wrote:

Scopes aren't meant to be interoperable between = services since they're necessarily API-specific. The only interoperable= bit is that there's *some* place to put the values and that it's e= xpressed as a bag of space-separated strings. How those strings get interpreted and enforced (which is really what's at = stake here) is up to the AS and PR (or a higher-level protocol like UMA).

=C2=A0-- Justin

=C2=A0<= /p>

On 04/15/2013 10:13 AM, Tim Bray wrote:

This, as written, has zero interoperability.=C2=A0 I think this feature = can really only be made useful in the case where scopes are fixed strings.<= u>

-T

On Apr 15, 2013 6:54 AM, "Justin Richer" &= lt;jricher@mitre.org= > wrote:

You are correct that = the idea behind the "scope" parameter at registration is a constr= aint on authorization-time scopes that are made available. It's both a = means for the client to request a set of valid scopes and for the server to provision (and echo back to the client) a set of val= id scopes.

I *really* don't want to try to define a matching language for scope ex= pressions. For that to work, all servers would need to be able to process t= he regular expressions for all clients, even if the servers themselves only= support simple-string scope values. Any regular expression syntax we pick here is guaranteed to be incompatibl= e with something, and I think the complexity doesn't buy much. Also, I = think you suddenly have a potential security issue if you have a bad regex = in place on either end.

As it stands today, the server can interpret the incoming registration scop= es and enforce them however it wants to. The real trick comes not from assi= gning the values to a particular client but to enforcing them, and I think = that's always going to be service-specific. We're just not as clear on that as we could be.

After looking over everyone's comments so far, I'd like to propose = the following text for that section:



=C2=A0=C2=A0 scope
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 OPTIONAL.=C2=A0 Space separated list of=
 scope values (as described in
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 OAuth 2.0 Section=C2=A03.3 [RFC6749]<=
/a>) that the client can use when 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0requesting access tokens.=C2=A0 As=
 scope values are service-specific, 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0the Authorization Server MAY defin=
e its own matching rules when
=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0determining if a scope value used durin=
g an authorization request
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 is valid according to the scope values =
assigned during 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0registration. Possible matching ru=
les include wildcard patterns,
=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0regular expressions, or exactly matchin=
g the string. If omitted, 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0an Authorization Server MAY regist=
er a Client with a default 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0set of scopes.


Comments? Improvements?

=C2=A0-- Justin



On 04/14/2013 08:23 PM, Manger, James H wrote:

Presumably at app registration time any scope specification is really =
a constraint on the scope values that can be requested in an authorization =
flow.
=C2=A0
So ideally registration should accept rules for matching scopes, as op=
posed to actual scope values.
=C2=A0
You can try to use scope values as their own matching rules. That is f=
ine for a small set of "static" scopes. It starts to fail when th=
ere are a large number of scopes, or scopes that can include parameters (re=
source paths? email addresses?). You can try to patch those failures by all=
owing services to define service-specific special "wildcard" scop=
e values that can only be used during registration (eg "read:*").=

=C2=A0
Alternatively, replace 'scope' in registration with 'scope=
_regex' that holds a regular expression that all scope values in an aut=
horization flow must match.
=C2=A0
--
James Manger
_______________________________________________
OAuth mailing list
OAuth@ietf.org=

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

=C2=A0


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

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0


--047d7bdc19d41d92e404daa45ec8-- From Michael.Jones@microsoft.com Thu Apr 18 08:59:51 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 450D421F8B5F for ; Thu, 18 Apr 2013 08:59:50 -0700 (PDT) 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 0UL6y-NrmFwy for ; Thu, 18 Apr 2013 08:59:47 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0206.outbound.protection.outlook.com [207.46.163.206]) by ietfa.amsl.com (Postfix) with ESMTP id 6561321F8FFB for ; Thu, 18 Apr 2013 08:59:42 -0700 (PDT) Received: from BL2FFO11FD027.protection.gbl (10.173.161.200) by BL2FFO11HUB029.protection.gbl (10.173.161.53) with Microsoft SMTP Server (TLS) id 15.0.675.0; Thu, 18 Apr 2013 15:56:07 +0000 Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD027.mail.protection.outlook.com (10.173.161.106) with Microsoft SMTP Server (TLS) id 15.0.675.0 via Frontend Transport; Thu, 18 Apr 2013 15:56:07 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.245]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0318.003; Thu, 18 Apr 2013 15:55:05 +0000 From: Mike Jones To: Tim Bray Thread-Topic: [OAUTH-WG] Registration: Scope Values Thread-Index: AQHOOeqUFpSaFgMeSEqfp5thtJ9Xm5jXeeUggAAGtwCAAAX9QIAAJHsAgARy+OCAAAL+AIAABHrw Date: Thu, 18 Apr 2013 15:55:03 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436766C964@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <255B9BB34FB7D647A506DC292726F6E1150C74DADA@WSMSG3153V.srv.dir.telstra.com> <516C069F.9090308@mitre.org> <516C0B9D.6000402@mitre.org> <516C101F.2090706@mitre.org> <516C1714.8070503@mitre.org> <4E1F6AAD24975D4BA5B168042967394367641A87@TK5EX14MBXC283.redmond.corp.microsoft.com> <516C3152.9070603@mitre.org> <4E1F6AAD24975D4BA5B168042967394367641FAB@TK5EX14MBXC283.redmond.corp.microsoft.com> <516C54F2.8040708@mitre.org> <4E1F6AAD24975D4BA5B16804296739436766BCC4@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.35] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436766C964TK5EX14MBXC284r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(56776001)(47736001)(49866001)(76482001)(53806001)(47976001)(50986001)(77982001)(51856001)(31966008)(4396001)(54316002)(6806003)(69226001)(65816001)(56816002)(81542001)(81342001)(79102001)(512874001)(20776003)(54356001)(47446002)(80022001)(16406001)(71186001)(46102001)(55846006)(66066001)(564824004)(44976003)(63696002)(74502001)(33656001)(59766001)(74662001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB029; H:TK5EX14MLTC103.redmond.corp.microsoft.com; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 08200063E9 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Registration: Scope Values X-BeenThere: oauth@ietf.org X-Mailman-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, 18 Apr 2013 15:59:52 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436766C964TK5EX14MBXC284r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBkb27igJl0IHRoaW5rIGl04oCZcyBwb3NzaWJsZSB0byBkZWZpbmUgd2hhdCBpdCBtZWFucyBp biBhbiBpbnRlcm9wZXJhYmxlIHdheSBiZWNhdXNlIE9BdXRoIGRpZG7igJl0IHNwZWNpZnkgc2Nv cGVzIGluIGFuIGludGVyb3BlcmFibGUgd2F5LiAgTm8sIEkgZG9u4oCZdCBsaWtlIHRoYXQgZWl0 aGVyLCBidXQgSSB0aGluayB0aGF04oCZcyB3aGVyZSB0aGluZ3MgYXJlLiAgVGhhdOKAmXMgd2h5 IEkgd2FzIGFkdm9jYXRpbmcgZGVsZXRpbmcgdGhpcyByZWdpc3RyYXRpb24gZmVhdHVyZSBlbnRp cmVseS4NCg0KQnV0IHVuZGVyc3RhbmRpbmcgaXQgbWlnaHQgYmUgdXNlZnVsIGluIHNvbWUgY29u dGV4dHMsIEnigJltIE9LIGtlZXBpbmcgaXQsIHByb3ZpZGVkIHdlIGJlIGNsZWFyIHRoYXQgdGhl IHNlbWFudGljcyBvZiDigJxyZWdpc3RlcmVkIHRvIHVzZeKAnSBhcmUgc2VydmljZS1zcGVjaWZp Yy4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBUaW0gQnJheSBbbWFpbHRvOnR3YnJheUBnb29nbGUu Y29tXQ0KU2VudDogVGh1cnNkYXksIEFwcmlsIDE4LCAyMDEzIDg6MzYgQU0NClRvOiBNaWtlIEpv bmVzDQpDYzogSnVzdGluIFJpY2hlcjsgb2F1dGhAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbT0FV VEgtV0ddIFJlZ2lzdHJhdGlvbjogU2NvcGUgVmFsdWVzDQoNCk9uIHRoZSBzZXJ2ZXItdG8tY2xp ZW50IHNpZGUsIHdoYXQgZG9lcyDigJxyZWdpc3RlcmVkIHRvIHVzZeKAnSBtZWFuPyAgRG9lcyBp dCBtZWFuIHRoYXQgdGhlIGNsaWVudCBzaG91bGQgYXNzdW1lIHRoYXQgYW55IHNjb3BlcyBub3Qg b24gdGhlIGxpc3QgV0lMTCBub3QgYmUgZ3JhbnRlZCwgTUFZIG5vdCBiZSBncmFudGVkLi4uLiBv ciB3aGF0PyAgSXMgdGhpcyBhbHJlYWR5IGNvdmVyZWQgZWxzZXdoZXJlPyAtVA0KDQpPbiBUaHUs IEFwciAxOCwgMjAxMyBhdCA4OjI4IEFNLCBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jv c29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KVGhh bmtzLCBKdXN0aW4uICBJIGFncmVlIHdpdGggdGhlIG5lZWQgZm9yIHRoZSBnZW5lcmljIHR3by1z aWRlZCBsYW5ndWFnZS4gIEnigJlkIHN0aWxsIGtlZXAgdGhpcyBsYW5ndWFnZSBmb3Igc2NvcGUs IGJlY2F1c2Ugd2Ugd2FudCB0byBjYXB0dXJlIHRoZSDigJxkZWNsYXJpbmfigJ0gYXNwZWN0IGlu IHRoaXMgY2FzZToNCg0K4oCcU3BhY2Ugc2VwYXJhdGVkIGxpc3Qgb2Ygc2NvcGUgdmFsdWVzIChh cyBkZXNjcmliZWQgaW4gT0F1dGggMi4wIFNlY3Rpb24gMy4zIFtSRkM2NzQ5XTxodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9yZmM2NzQ5I3NlY3Rpb24tMy4zPikgdGhhdCB0aGUgY2xpZW50IGlz IGRlY2xhcmluZyB0byB0aGUgc2VydmVyIHRoYXQgaXQgbWF5IHVzZSB3aGVuIHJlcXVlc3Rpbmcg YWNjZXNzIHRva2VucyBhbmQgdGhhdCB0aGUgc2VydmVyIGlzIGRlY2xhcmluZyB0byB0aGUgY2xp ZW50IHRoYXQgaXQgaXMgcmVnaXN0ZXJlZCB0byB1c2Ugd2hlbiByZXF1ZXN0aW5nIGFjY2VzcyB0 b2tlbnMu4oCdLg0KDQpZb3Ugc2hvdWxkIHByb2JhYmx5IGFsc28gcmVpbmZvcmNlIHRoYXQgc2Nv cGUgdmFsdWVzIGFyZSBzZXJ2aWNlLXNwZWNpZmljIGFuZCBtYXkgbm90IGNvbnNpc3Qgb25seSBv ZiBhIHN0YXRpYyBzZXQgb2Ygc3RyaW5nIHZhbHVlcywgYW5kIHRoYXQgdGhlcmVmb3JlLCBpbiBz b21lIGNhc2VzLCBhbiBleGhhdXN0aXZlIGxpc3Qgb2YgcmVnaXN0ZXJlZCBzY29wZSB2YWx1ZXMg aXMgbm90IHBvc3NpYmxlLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IEp1c3RpbiBSaWNoZXIgW21h aWx0bzpqcmljaGVyQG1pdHJlLm9yZzxtYWlsdG86anJpY2hlckBtaXRyZS5vcmc+XQ0KU2VudDog TW9uZGF5LCBBcHJpbCAxNSwgMjAxMyAxMjoyOSBQTQ0KDQpUbzogTWlrZSBKb25lcw0KQ2M6IFRp bSBCcmF5OyBvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBS ZTogW09BVVRILVdHXSBSZWdpc3RyYXRpb246IFNjb3BlIFZhbHVlcw0KDQpJIHRoaW5rIHRoYXQg YmVjYXVzZSB0aGUgImRlY2xhcmF0aW9uIiBpc3N1ZSBhZmZlY3RzIGFsbCBwYXJhbWV0ZXJzIGlu IHRoZSBsaXN0LCBub3QganVzdCBzY29wZSwgd2Ugc2hvdWxkIGFkb3B0IHRoaXMgaW4gYSBoaWdo ZXIgbGV2ZWwgcGFyYWdyYXBoIGFuZCBsZWF2ZSBpdCBvdXQgb2YgdGhlIGluZGl2aWR1YWwgcGFy YW1ldGVyIGRlc2NyaXB0aW9ucy4gVGh1cywgc29tZXRoaW5nIGxpa2UgdGhpcyBpbnNlcnRlZCBh cyB0aGUgc2Vjb25kIHBhcmFncmFwaCBpbiBzZWN0aW9uIDI6DQpUaGUgY2xpZW50IG1ldGFkYXRh IHZhbHVlcyBzZXJ2ZSB0d28gcGFyYWxsZWwgcHVycG9zZXMgaW4gdGhlIG92ZXJhbGwgT0F1dGgg RHluYW1pYyBSZWdpc3RyYXRpb24gcHJvdG9jb2w6DQoNCiAtIHRoZSBDbGllbnQgcmVxdWVzdGlu ZyBpdHMgZGVzaXJlZCB2YWx1ZXMgZm9yIGVhY2ggcGFyYW1ldGVyIHRvIHRoZSBBdXRob3JpemF0 aW9uIFNlcnZlciBpbiBhIFtyZWdpc3Rlcl0gb3IgW3VwZGF0ZV0gcmVxdWVzdCwNCiAtIHRoZSBB dXRob3JpemF0aW9uIFNlcnZlciBpbmZvcm1pbmcgdGhlIENsaWVudCBvZiB0aGUgY3VycmVudCB2 YWx1ZXMgb2YgZWFjaCBwYXJhbWV0ZXIgdGhhdCB0aGUgQ2xpZW50IGhhcyBiZWVuIHJlZ2lzdGVy ZWQgdG8gdXNlIHRocm91Z2ggYSBbY2xpZW50IGluZm9ybWF0aW9uIHJlc3BvbnNlXS4NCg0KQW4g QXV0aG9yaXphdGlvbiBTZXJ2ZXIgTUFZIG92ZXJyaWRlIGFueSB2YWx1ZSB0aGF0IGEgQ2xpZW50 IHJlcXVlc3RzIGR1cmluZyB0aGUgcmVnaXN0cmF0aW9uIHByb2Nlc3MgKGluY2x1ZGluZyBhbnkg b21pdHRlZCB2YWx1ZXMpIGFuZCByZXBsYWNlIHRoZSByZXF1ZXN0ZWQgdmFsdWUgd2l0aCBhIGRl ZmF1bHQuIFRoZSBub3JtYXRpdmUgaW5kaWNhdGlvbnMgaW4gdGhlIGZvbGxvd2luZyBsaXN0IGFw cGx5IHRvIHRoZSBDbGllbnQncyBkZWNsYXJhdGlvbiBvZiBpdHMgZGVzaXJlZCB2YWx1ZXMuDQoN ClRoZSBBdXRob3JpemF0aW9uIFNlcnZlciBTSE9VTEQgcHJvdmlkZSBkb2N1bWVudGF0aW9uIGZv ciBhbnkgZmllbGRzIHRoYXQgaXQgcmVxdWlyZXMgdG8gYmUgZmlsbGVkIGluIGJ5IHRoZSBjbGll bnQgb3IgdG8gaGF2ZSBwYXJ0aWN1bGFyIHZhbHVlcyBvciBmb3JtYXRzLiBFeHRlbnNpb25zIGFu ZCBwcm9maWxlcy4uLg0KDQpBbmQgdGhlbiByZW1vdmUgdGhlIHNpZGVkbmVzcy1sYW5ndWFnZSBm cm9tIHRoZSBzY29wZSBwYXJhbWV0ZXIgYW5kIGFueSBvdGhlciBwYXJhbWV0ZXJzIHdoZXJlIGl0 IG1pZ2h0IGhhdmUgY3JlcHQgaW4gaW5hZHZlcnRlbnRseS4NCg0KIC0tIEp1c3Rpbg0KT24gMDQv MTUvMjAxMyAwMToyOSBQTSwgTWlrZSBKb25lcyB3cm90ZToNCldlIGNvdWxkIGZpeCB0aGUgb25l LXNpZGVkIGxhbmd1YWdlIGJ5IGNoYW5naW5nDQrigJxTcGFjZSBzZXBhcmF0ZWQgbGlzdCBvZiBz Y29wZSB2YWx1ZXMgKGFzIGRlc2NyaWJlZCBpbiBPQXV0aCAyLjAgU2VjdGlvbiAzLjMgW1JGQzY3 NDldPGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY3NDkjc2VjdGlvbi0zLjM+KSB0aGF0 IHRoZSBjbGllbnQgaXMgZGVjbGFyaW5nIHRoYXQgaXQgbWF5IHVzZSB3aGVuIHJlcXVlc3Rpbmcg YWNjZXNzIHRva2Vucy7igJ0NCnRvDQrigJxTcGFjZSBzZXBhcmF0ZWQgbGlzdCBvZiBzY29wZSB2 YWx1ZXMgKGFzIGRlc2NyaWJlZCBpbiBPQXV0aCAyLjAgU2VjdGlvbiAzLjMgW1JGQzY3NDldPGh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY3NDkjc2VjdGlvbi0zLjM+KSB0aGF0IHRoZSBj bGllbnQgaXMgZGVjbGFyaW5nIHRvIHRoZSBzZXJ2ZXIgdGhhdCBpdCBtYXkgdXNlIHdoZW4gcmVx dWVzdGluZyBhY2Nlc3MgdG9rZW5zIGFuZCB0aGF0IHRoZSBzZXJ2ZXIgaXMgZGVjbGFyaW5nIHRv IHRoZSBjbGllbnQgdGhhdCBpdCBpcyByZWdpc3RlcmVkIHRvIHVzZSB3aGVuIHJlcXVlc3Rpbmcg YWNjZXNzIHRva2Vucy7igJ0uDQoNCkFnYWluLCBJIGNob3NlIHRoZSDigJxyZWdpc3RlcmVkIHRv IHVzZeKAnSBsYW5ndWFnZSBjYXJlZnVsbHkg4oCTIGJlY2F1c2UgaW4gdGhlIGdlbmVyYWwgY2Fz ZSBpdOKAmXMgbm90IGEgcmVzdHJpY3Rpb24gb24gdGhlIHZhbHVlcyB0aGF0IHRoZSBjbGllbnQg Y2FuIHVzZSDigJMganVzdCBhIHN0YXRlbWVudCBieSB0aGUgc2VydmVyIHRvIHRoZSBjbGllbnQg dGhhdCBpdCBpcyByZWdpc3RlcmVkIHRvIHVzZSB0aG9zZSBwYXJ0aWN1bGFyIHZhbHVlcy4gIElu IGJvdGggY2FzZXMsIHRoZSBwYXJ0aWVzIGFyZSBtYWtpbmcgZGVjbGFyYXRpb25zIHRvIG9uZSBh bm90aGVyLg0KDQpJZiB5b3UgYWRvcHQgdGhhdCBsYW5ndWFnZSAob3Iga2VlcCB0aGUgb3JpZ2lu YWwgbGFuZ3VhZ2UpLCB0aGVuIHllcywgSeKAmWQgY29uc2lkZXIgdGhpcyBjbG9zZWQuDQoNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IC0tIE1pa2UNCg0KRnJvbTogSnVzdGluIFJpY2hlciBbbWFpbHRvOmpyaWNoZXJAbWl0cmUub3Jn XQ0KU2VudDogTW9uZGF5LCBBcHJpbCAxNSwgMjAxMyA5OjU3IEFNDQpUbzogTWlrZSBKb25lcw0K Q2M6IFRpbSBCcmF5OyBvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+DQpTdWJq ZWN0OiBSZTogW09BVVRILVdHXSBSZWdpc3RyYXRpb246IFNjb3BlIFZhbHVlcw0KDQpJIGFic29s dXRlbHkgZG8gbm90IHdhbnQgdG8gZGVsZXRlIHRoaXMgZmVhdHVyZSwgYXMgKGhhdmluZyBpbXBs ZW1lbnRlZCBpdCkgSSB0aGluayBpdCdzIHZlcnkgdXNlZnVsLiBUaGlzIGlzIGEgdmVyeSBlc3Rh Ymxpc2hlZCBwYXR0ZXJuIGluIG1hbnVhbCByZWdpc3RyYXRpb246IEkga25vdyBvZiBtYW55LCBt YW55IE9BdXRoMiBzZXJ2ZXJzIGFuZCBjbGllbnRzIHRoYXQgYXJlIHNldCB1cCB3aGVyZSB0aGUg Y2xpZW50IG11c3QgcHJlLXJlZ2lzdGVyIGEgc2V0IG9mIHNjb3Blcy4NCg0KSSBkb24ndCBsaWtl IHRoZSBsYW5ndWFnZSBvZiAidGhlIGNsaWVudCBpcyBkZWNsYXJpbmciIGJlY2F1c2UgaXQncyB0 b28gb25lLXNpZGVkLiBUaGUgY2xpZW50IG1pZ2h0IG5vdCBoYXZlIGRlY2xhcmVkIGFueXRoaW5n LCBhbmQgaXQgbWlnaHQgYmUgdGhlIHNlcnZlciB0aGF0J3MgZGVjbGFyaW5nIHNvbWV0aGluZyB0 byB0aGUgY2xpZW50LiBEZWxldGluZyB0aGUgImlzIGRlY2xhcmluZyIgYml0IHJlbW92ZXMgdGhh dCB1bmludGVuZGVkIHJlc3RyaWN0aW9uIG9mIHRoZSBsYW5ndWFnZSB3aGlsZSBrZWVwaW5nIHRo ZSBvcmlnaW5hbCBtZWFuaW5nIGludGFjdC4gSSBhY3R1YWxseSB0aG91Z2h0IHRoYXQgSSBoYWQg Zml4ZWQgdGhhdCBiZWZvcmUgdGhlIGxhc3QgZHJhZnQgd2VudCBpbiBidXQgYXBwYXJlbnRseSBJ IG1pc3NlZCB0aGlzIG9uZS4NCg0KSSB3aWxsIHdvcmsgb24gY2xhcmlmeWluZyB0aGUgaW50ZW50 IG9mIHRoZSB3aG9sZSBtZXRhZGF0YSBzZXQgaW4gaXRzIGludHJvZHVjdG9yeSBwYXJhZ3JhcGgo cykgc28gdGhhdCBpdCdzIGNsZWFyIHRoYXQgYWxsIG9mIHRoZXNlIGZpZWxkcyBhcmUgdXNlZCBp biBib3RoIG9mIHRoZXNlIHNpdHVhdGlvbnM6DQoNCiAxKSBUaGUgY2xpZW50IGRlY2xhcmluZyB0 byB0aGUgc2VydmVyIGl0cyBkZXNpcmUgdG8gdXNlIGEgcGFydGljdWxhciB2YWx1ZQ0KIDIpIFRo ZSBzZXJ2ZXIgZGVjbGFyaW5nIHRvIHRoZSBjbGllbnQgdGhhdCBpdCBoYXMgYmVlbiByZWdpc3Rl cmVkIHdpdGggYSBwYXJ0aWN1bGFyIHZhbHVlDQoNClRoaXMgc2hvdWxkIGhvcGVmdWxseSBjbGVh ciB1cCB0aGUgaXNzdWUgaW4gdGhlIGVkaXRvcidzIG5vdGUgdGhhdCBJIGN1cnJlbnRseSBoYXZl IGF0IHRoZSB0b3Agb2YgdGhhdCBzZWN0aW9uIHJpZ2h0IG5vdywgdG9vLg0KDQpNaWtlLCBzaW5j ZSB5b3Ugd2VyZSB0aGUgb25lIHdobyBvcmlnaW5hbGx5IGJyb3VnaHQgdXAgdGhlIGlzc3VlLCBh bmQgeW91J3JlIGZpbmUgd2l0aCB0aGUgZXhpc3RpbmcgdGV4dCwgY2FuIEkgdGFrZSB0aGlzIGFz IGNsb3NlZCBub3c/IEFzc3VtaW5nIHRoYXQgeW91IGFncmVlIHdpdGggZGVsZXRpbmcgImlzIGRl Y2xhcmluZyIgZm9yIHJlYXNvbnMgc3RhdGVkIGFib3ZlLCBJJ20gZmluZSB3aXRoIGxlYXZpbmcg ZXZlcnl0aGluZyBlbHNlIGFzIGlzIGFuZCBzdGF5aW5nIHF1aWV0IG9uIHdoYXQgdGhlIHNlcnZl ciBoYXMgdG8gZG8gd2l0aCB0aGUgc2NvcGVzLg0KDQogLS0gSnVzdGluDQoNCk9uIDA0LzE1LzIw MTMgMTI6NDQgUE0sIE1pa2UgSm9uZXMgd3JvdGU6DQpJIHRoaW5rIHRoYXQgdGhlIGV4aXN0aW5n IHdvcmRpbmcgaXMgc3VwZXJpb3IgdG8gdGhlIHByb3Bvc2VkIGNoYW5nZWQgd29yZGluZy4gIFRo ZSBleGlzdGluZyB3b3JkaW5nIGlzOg0KDQogICBzY29wZQ0KICAgICAgT1BUSU9OQUwuICBTcGFj ZSBzZXBhcmF0ZWQgbGlzdCBvZiBzY29wZSB2YWx1ZXMgKGFzIGRlc2NyaWJlZCBpbg0KICAgICAg T0F1dGggMi4wIFNlY3Rpb24gMy4zIFtSRkM2NzQ5XTxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9yZmM2NzQ5I3NlY3Rpb24tMy4zPikgdGhhdCB0aGUgY2xpZW50IGlzIGRlY2xhcmluZyB0aGF0 DQogICAgICBpdCBtYXkgdXNlIHdoZW4gcmVxdWVzdGluZyBhY2Nlc3MgdG9rZW5zLiAgSWYgb21p dHRlZCwgYW4NCiAgICAgIEF1dGhvcml6YXRpb24gU2VydmVyIE1BWSByZWdpc3RlciBhIENsaWVu dCB3aXRoIGEgZGVmYXVsdCBzZXQgb2YNCiAgICAgIHNjb3Blcy4NCg0KRm9yIGluc3RhbmNlLCB0 aGUgY3VycmVudCDigJxjbGllbnQgaXMgZGVjbGFyaW5n4oCdIHdvcmRpbmcgd2lsbCBhbHdheXMg YmUgY29ycmVjdCwgd2hlcmVhcyBhcyB0aGUgY2hhbmdlIHRvIOKAnGNsaWVudCBjYW4gdXNl4oCd IHdvcmRpbmcgaW1wbGllcyBhIHJlc3RyaWN0aW9uIG9uIGNsaWVudCBiZWhhdmlvciB0aGF0IGlz IG5vdCBhbHdheXMgYXBwbGljYWJsZS4gIFRoZSDigJxjbGllbnQgaXMgZGVjbGFyaW5n4oCdIHdv cmRpbmcgd2FzIHNwZWNpZmljIGFuZCBwdXJwb3NlZnVsbHkgY2hvc2VuLCBhbmQgSSB0aGluayBz aG91bGQgYmUgcmV0YWluZWQuICBJbiBwYXJ0aWN1bGFyLCB3ZSBjYW7igJl0IGRvIGFueXRoaW5n IHRoYXQgaW1wbGllcyB0aGF0IG9ubHkgdGhlIHJlZ2lzdGVyZWQgc2NvcGVzIHZhbHVlcyBjYW4g YmUgdXNlZC4gIEF0IHRoZSBPQXV0aCBzcGVjIGxldmVsLCB0aGlzIGlzIGEgaGludCBhcyB0byBw b3NzaWJsZSBmdXR1cmUgY2xpZW50IGJlaGF2aW9yIOKAkyBub3QgYSByZXN0cmljdGlvbiBvbiBm dXR1cmUgY2xpZW50IGJlaGF2aW9yLg0KDQpBbHNvLCBmb3IgdGhlIHJlYXNvbnMgdGhhdCBUaW0g c3RhdGVkLCBJ4oCZbSBzdHJvbmdseSBhZ2FpbnN0IGFueSDigJxtYXRjaGluZ+KAnSBvciDigJxy ZWdleOKAnSBsYW5ndWFnZSBpbiB0aGUgc3BlYyBwZXJ0YWluaW5nIHRvIHNjb3BlcyDigJMgYXMg aXTigJlzIG5vdCBhY3Rpb25hYmxlLg0KDQpTbyBJ4oCZZCBwcm9wb3NlIHRoYXQgd2UgbGVhdmUg dGhlIGV4aXN0aW5nIHNjb3BlIHdvcmRpbmcgaW4gcGxhY2UuICBBbHRlcm5hdGl2ZWx5LCBJ4oCZ ZCBhbHNvIGJlIGZpbmUgd2l0aCBkZWxldGluZyB0aGlzIGZlYXR1cmUgZW50aXJlbHksIGFzIEkg ZG9u4oCZdCB0aGluayBpdOKAmXMgdXNlZnVsIGluIHRoZSBnZW5lcmFsIGNhc2UuDQoNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0t IE1pa2UNCg0KRnJvbTogb2F1dGgtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86b2F1dGgtYm91bmNl c0BpZXRmLm9yZz4gW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg SnVzdGluIFJpY2hlcg0KU2VudDogTW9uZGF5LCBBcHJpbCAxNSwgMjAxMyA4OjA1IEFNDQpUbzog VGltIEJyYXk7IG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6 IFJlOiBbT0FVVEgtV0ddIFJlZ2lzdHJhdGlvbjogU2NvcGUgVmFsdWVzDQoNCk9uIDA0LzE1LzIw MTMgMTA6NTIgQU0sIFRpbSBCcmF5IHdyb3RlOg0KDQoNCknigJlkIHVzZSB0aGUgZXhpc3Rpbmcg d29yZGluZzsgaXTigJlzIHBlcmZlY3RseSBjbGVhci4gIEZhaWxpbmcgdGhhdCwgaWYgdGhlcmXi gJlzIHN0cm9uZyBkZW1hbmQgZm9yIHJlZ2lzdHJhdGlvbiBvZiBzdHJ1Y3R1cmVkIHNjb3Blcywg Ymxlc3MgdGhlIHVzZSBvZiByZWdleGVzLCBlaXRoZXIgUENSRXMgb3Igc29tZSBjYXJlZnVsIHN1 YnNldC4NCg0KVGhhbmtzIGZvciB0aGUgZmVlZGJhY2sgLS0gT2YgdGhlc2UgdHdvIGNob2ljZXMs IEknZCByYXRoZXIgbGVhdmUgaXQgYXMtaXMuDQoNCg0KDQoNCkhvd2V2ZXIsIEnigJlkIHN1YnRy YWN0IHRoZSBzZW50ZW5jZSDigJxJZiBvbWl0dGVkLCBhbiBBdXRob3JpemF0aW9uIFNlcnZlciBN QVkgcmVnaXN0ZXIgYSBDbGllbnQgd2l0aCBhIGRlZmF1bHQgc2V0IG9mICBzY29wZXMu4oCdICBJ dCBhZGRzIG5vIHZhbHVlOyBpZiB0aGUgY2xpZW50IGRvZXNu4oCZdCBkZWNsYXJlIHNjb3Blcywg dGhlIGNsaWVudCBkb2VzbuKAmXQgZGVjbGFyZSBzY29wZXMsIHRoYXTigJlzIGFsbC4gIC1UDQoN ClJlbWVtYmVyLCBhbGwgb2YgdGhlc2UgZmllbGRzIGFyZW4ndCBqdXN0IGZvciB0aGUgY2xpZW50 ICpyZXF1ZXN0KiwgdGhleSdyZSBhbHNvIGZvciB0aGUgc2VydmVyJ3MgKnJlc3BvbnNlKiB0byBl aXRoZXIgYSBQT1NULCBQVVQsIG9yIEdFVCByZXF1ZXN0LiAoSSBkaWRuJ3QgcmVhbGl6ZSBpdCwg YnV0IHBlcmhhcHMgdGhlIHdvcmRpbmcgYXMgc3RhdGVkIHJpZ2h0IG5vdyBkb2Vzbid0IG1ha2Ug dGhhdCBjbGVhciAtLSBJIG5lZWQgdG8gZml4IHRoYXQuKSBUaGUgdmFsdWUgdGhhdCBpdCBhZGRz IGlzIGlmIHRoZSBjbGllbnQgZG9lc24ndCBhc2sgZm9yIGFueSBwYXJ0aWN1bGFyIHNjb3Blcywg dGhlIHNlcnZlciBjYW4gc3RpbGwgYXNzaWduIGl0IHNjb3BlcyBhbmQgdGhlIGNsaWVudCBjYW4g ZG8gc29tZXRoaW5nIHNtYXJ0IHdpdGggdGhhdC4gRHVtYiBjbGllbnRzIGFyZSBhbGxvd2VkIHRv IGlnbm9yZSBpdCBpZiBpdCBkb2Vzbid0IG1lYW4gYW55dGhpbmcgdG8gdGhlbS4NCg0KVGhpcyBp cyBob3cgb3VyIHNlcnZlciBpbXBsZW1lbnRhdGlvbiBhY3R1YWxseSB3b3JrcyByaWdodCBub3cu IElmIHRoZSBjbGllbnQgZG9lc24ndCBhc2sgZm9yIGFueXRoaW5nIHNwZWNpZmljIGF0IHJlZ2lz dHJhdGlvbiwgdGhlIHNlcnZlciBoYW5kcyBpdCBhIGJhZyBvZiAiZGVmYXVsdCIgc2NvcGVzLiBT YW1lIHRoaW5nIGhhcHBlbnMgYXQgYXV0aCB0aW1lIC0tIGlmIHRoZSBjbGllbnQgZG9lc24ndCBh c2sgZm9yIGFueSBwYXJ0aWN1bGFyIHNjb3BlcywgdGhlIHNlcnZlciBoYW5kcyBpdCBhbGwgb2Yg aXRzIHJlZ2lzdGVyZWQgc2NvcGVzIGFzIGEgZGVmYXVsdC4gR3JhbnRlZCwgb24gb3VyIHNlcnZl ciwgc2NvcGVzIGFyZSBqdXN0IHNpbXBsZSBzdHJpbmdzIHJpZ2h0IG5vdywgc28gdGhleSBnZXQg Y29tcGFyZWQgYXQgdGhlIGF1dGggZW5kcG9pbnQgd2l0aCBhbiBleGFjdCBzdHJpbmctbWF0Y2gg bWV0cmljIGFuZCBzZXQtYmFzZWQgbG9naWMuDQoNCiAtLSBKdXN0aW4NCg0KDQoNCg0KT24gTW9u LCBBcHIgMTUsIDIwMTMgYXQgNzozNSBBTSwgSnVzdGluIFJpY2hlciA8anJpY2hlckBtaXRyZS5v cmc8bWFpbHRvOmpyaWNoZXJAbWl0cmUub3JnPj4gd3JvdGU6DQpXaGF0IHdvdWxkIHlvdSBzdWdn ZXN0IGZvciB3b3JkaW5nIGhlcmUsIHRoZW4/IEtlZXBpbmcgaW4gbWluZCB0aGF0IHdlIGNhbm5v dCAoYW5kIGRvbid0IHdhbnQgdG8pIHByb2hpYml0IGV4cHJlc3Npb24tYmFzZWQgc2NvcGVzLg0K DQogLS0gSnVzdGluDQoNCk9uIDA0LzE1LzIwMTMgMTA6MzMgQU0sIFRpbSBCcmF5IHdyb3RlOg0K Tm8sIEkgbWVhbiBpdOKAmXMgbm90IGludGVyb3BlcmFibGUgYXQgdGhlIHNvZnR3YXJlLWRldmVs b3BlciBsZXZlbC4gIEkgY2Fu4oCZdCByZWdpc3RlciBzY29wZXMgYXQgYXV0aG9yaXphdGlvbiB0 aW1lIHdpdGggYW55IHByZWRpY3RhYmxlIGVmZmVjdCB0aGF0IEkgY2FuIHdyaXRlIGNvZGUgdG8g c3VwcG9ydCwgZWl0aGVyIGNsaWVudCBvciBzZXJ2ZXIgc2lkZSwgd2l0aG91dCBvdXQtb2YtbGlu ZSBub24taW50ZXJvcGVyYWJsZSBrbm93bGVkZ2UgYWJvdXQgdGhlIGJlaGF2aW9yIG9mIHRoZSBz ZXJ2ZXIuDQoNCkkgZ3Vlc3MgSeKAmW0ganVzdCBub3QgdXNlZCB0byBPQXV0aOKAmXMgY3VsdHVy ZSBvZiBoYXZpbmcgbm8gZXhwZWN0YXRpb24gdGhhdCB0aGluZ3Mgd2lsbCBiZSBzcGVjaWZpZWQg dGlnaHRseSBlbm91Z2ggdGhhdCBJIGNhbiB3cml0ZSBjb2RlIHRvIGltcGxlbWVudCBhcyBzcGVj aWZpZWQuICAtVA0KDQpPbiBNb24sIEFwciAxNSwgMjAxMyBhdCA3OjE1IEFNLCBKdXN0aW4gUmlj aGVyIDxqcmljaGVyQG1pdHJlLm9yZzxtYWlsdG86anJpY2hlckBtaXRyZS5vcmc+PiB3cm90ZToN ClNjb3BlcyBhcmVuJ3QgbWVhbnQgdG8gYmUgaW50ZXJvcGVyYWJsZSBiZXR3ZWVuIHNlcnZpY2Vz IHNpbmNlIHRoZXkncmUgbmVjZXNzYXJpbHkgQVBJLXNwZWNpZmljLiBUaGUgb25seSBpbnRlcm9w ZXJhYmxlIGJpdCBpcyB0aGF0IHRoZXJlJ3MgKnNvbWUqIHBsYWNlIHRvIHB1dCB0aGUgdmFsdWVz IGFuZCB0aGF0IGl0J3MgZXhwcmVzc2VkIGFzIGEgYmFnIG9mIHNwYWNlLXNlcGFyYXRlZCBzdHJp bmdzLiBIb3cgdGhvc2Ugc3RyaW5ncyBnZXQgaW50ZXJwcmV0ZWQgYW5kIGVuZm9yY2VkICh3aGlj aCBpcyByZWFsbHkgd2hhdCdzIGF0IHN0YWtlIGhlcmUpIGlzIHVwIHRvIHRoZSBBUyBhbmQgUFIg KG9yIGEgaGlnaGVyLWxldmVsIHByb3RvY29sIGxpa2UgVU1BKS4NCg0KIC0tIEp1c3Rpbg0KDQpP biAwNC8xNS8yMDEzIDEwOjEzIEFNLCBUaW0gQnJheSB3cm90ZToNCg0KVGhpcywgYXMgd3JpdHRl biwgaGFzIHplcm8gaW50ZXJvcGVyYWJpbGl0eS4gIEkgdGhpbmsgdGhpcyBmZWF0dXJlIGNhbiBy ZWFsbHkgb25seSBiZSBtYWRlIHVzZWZ1bCBpbiB0aGUgY2FzZSB3aGVyZSBzY29wZXMgYXJlIGZp eGVkIHN0cmluZ3MuDQoNCi1UDQpPbiBBcHIgMTUsIDIwMTMgNjo1NCBBTSwgIkp1c3RpbiBSaWNo ZXIiIDxqcmljaGVyQG1pdHJlLm9yZzxtYWlsdG86anJpY2hlckBtaXRyZS5vcmc+PiB3cm90ZToN CllvdSBhcmUgY29ycmVjdCB0aGF0IHRoZSBpZGVhIGJlaGluZCB0aGUgInNjb3BlIiBwYXJhbWV0 ZXIgYXQgcmVnaXN0cmF0aW9uIGlzIGEgY29uc3RyYWludCBvbiBhdXRob3JpemF0aW9uLXRpbWUg c2NvcGVzIHRoYXQgYXJlIG1hZGUgYXZhaWxhYmxlLiBJdCdzIGJvdGggYSBtZWFucyBmb3IgdGhl IGNsaWVudCB0byByZXF1ZXN0IGEgc2V0IG9mIHZhbGlkIHNjb3BlcyBhbmQgZm9yIHRoZSBzZXJ2 ZXIgdG8gcHJvdmlzaW9uIChhbmQgZWNobyBiYWNrIHRvIHRoZSBjbGllbnQpIGEgc2V0IG9mIHZh bGlkIHNjb3Blcy4NCg0KSSAqcmVhbGx5KiBkb24ndCB3YW50IHRvIHRyeSB0byBkZWZpbmUgYSBt YXRjaGluZyBsYW5ndWFnZSBmb3Igc2NvcGUgZXhwcmVzc2lvbnMuIEZvciB0aGF0IHRvIHdvcmss IGFsbCBzZXJ2ZXJzIHdvdWxkIG5lZWQgdG8gYmUgYWJsZSB0byBwcm9jZXNzIHRoZSByZWd1bGFy IGV4cHJlc3Npb25zIGZvciBhbGwgY2xpZW50cywgZXZlbiBpZiB0aGUgc2VydmVycyB0aGVtc2Vs dmVzIG9ubHkgc3VwcG9ydCBzaW1wbGUtc3RyaW5nIHNjb3BlIHZhbHVlcy4gQW55IHJlZ3VsYXIg ZXhwcmVzc2lvbiBzeW50YXggd2UgcGljayBoZXJlIGlzIGd1YXJhbnRlZWQgdG8gYmUgaW5jb21w YXRpYmxlIHdpdGggc29tZXRoaW5nLCBhbmQgSSB0aGluayB0aGUgY29tcGxleGl0eSBkb2Vzbid0 IGJ1eSBtdWNoLiBBbHNvLCBJIHRoaW5rIHlvdSBzdWRkZW5seSBoYXZlIGEgcG90ZW50aWFsIHNl Y3VyaXR5IGlzc3VlIGlmIHlvdSBoYXZlIGEgYmFkIHJlZ2V4IGluIHBsYWNlIG9uIGVpdGhlciBl bmQuDQoNCkFzIGl0IHN0YW5kcyB0b2RheSwgdGhlIHNlcnZlciBjYW4gaW50ZXJwcmV0IHRoZSBp bmNvbWluZyByZWdpc3RyYXRpb24gc2NvcGVzIGFuZCBlbmZvcmNlIHRoZW0gaG93ZXZlciBpdCB3 YW50cyB0by4gVGhlIHJlYWwgdHJpY2sgY29tZXMgbm90IGZyb20gYXNzaWduaW5nIHRoZSB2YWx1 ZXMgdG8gYSBwYXJ0aWN1bGFyIGNsaWVudCBidXQgdG8gZW5mb3JjaW5nIHRoZW0sIGFuZCBJIHRo aW5rIHRoYXQncyBhbHdheXMgZ29pbmcgdG8gYmUgc2VydmljZS1zcGVjaWZpYy4gV2UncmUganVz dCBub3QgYXMgY2xlYXIgb24gdGhhdCBhcyB3ZSBjb3VsZCBiZS4NCg0KQWZ0ZXIgbG9va2luZyBv dmVyIGV2ZXJ5b25lJ3MgY29tbWVudHMgc28gZmFyLCBJJ2QgbGlrZSB0byBwcm9wb3NlIHRoZSBm b2xsb3dpbmcgdGV4dCBmb3IgdGhhdCBzZWN0aW9uOg0KDQoNCg0KICAgc2NvcGUNCg0KICAgICAg T1BUSU9OQUwuICBTcGFjZSBzZXBhcmF0ZWQgbGlzdCBvZiBzY29wZSB2YWx1ZXMgKGFzIGRlc2Ny aWJlZCBpbg0KDQogICAgICBPQXV0aCAyLjAgU2VjdGlvbiAzLjMgW1JGQzY3NDldPGh0dHA6Ly90 b29scy5pZXRmLm9yZy9odG1sL3JmYzY3NDkjc2VjdGlvbi0zLjM+KSB0aGF0IHRoZSBjbGllbnQg Y2FuIHVzZSB3aGVuDQoNCiAgICAgIHJlcXVlc3RpbmcgYWNjZXNzIHRva2Vucy4gIEFzIHNjb3Bl IHZhbHVlcyBhcmUgc2VydmljZS1zcGVjaWZpYywNCg0KICAgICAgdGhlIEF1dGhvcml6YXRpb24g U2VydmVyIE1BWSBkZWZpbmUgaXRzIG93biBtYXRjaGluZyBydWxlcyB3aGVuDQoNCiAgICAgIGRl dGVybWluaW5nIGlmIGEgc2NvcGUgdmFsdWUgdXNlZCBkdXJpbmcgYW4gYXV0aG9yaXphdGlvbiBy ZXF1ZXN0DQoNCiAgICAgIGlzIHZhbGlkIGFjY29yZGluZyB0byB0aGUgc2NvcGUgdmFsdWVzIGFz c2lnbmVkIGR1cmluZw0KDQogICAgICByZWdpc3RyYXRpb24uIFBvc3NpYmxlIG1hdGNoaW5nIHJ1 bGVzIGluY2x1ZGUgd2lsZGNhcmQgcGF0dGVybnMsDQoNCiAgICAgIHJlZ3VsYXIgZXhwcmVzc2lv bnMsIG9yIGV4YWN0bHkgbWF0Y2hpbmcgdGhlIHN0cmluZy4gSWYgb21pdHRlZCwNCg0KICAgICAg YW4gQXV0aG9yaXphdGlvbiBTZXJ2ZXIgTUFZIHJlZ2lzdGVyIGEgQ2xpZW50IHdpdGggYSBkZWZh dWx0DQoNCiAgICAgIHNldCBvZiBzY29wZXMuDQoNCkNvbW1lbnRzPyBJbXByb3ZlbWVudHM/DQoN CiAtLSBKdXN0aW4NCg0KDQpPbiAwNC8xNC8yMDEzIDA4OjIzIFBNLCBNYW5nZXIsIEphbWVzIEgg d3JvdGU6DQoNClByZXN1bWFibHkgYXQgYXBwIHJlZ2lzdHJhdGlvbiB0aW1lIGFueSBzY29wZSBz cGVjaWZpY2F0aW9uIGlzIHJlYWxseSBhIGNvbnN0cmFpbnQgb24gdGhlIHNjb3BlIHZhbHVlcyB0 aGF0IGNhbiBiZSByZXF1ZXN0ZWQgaW4gYW4gYXV0aG9yaXphdGlvbiBmbG93Lg0KDQoNCg0KU28g aWRlYWxseSByZWdpc3RyYXRpb24gc2hvdWxkIGFjY2VwdCBydWxlcyBmb3IgbWF0Y2hpbmcgc2Nv cGVzLCBhcyBvcHBvc2VkIHRvIGFjdHVhbCBzY29wZSB2YWx1ZXMuDQoNCg0KDQpZb3UgY2FuIHRy eSB0byB1c2Ugc2NvcGUgdmFsdWVzIGFzIHRoZWlyIG93biBtYXRjaGluZyBydWxlcy4gVGhhdCBp cyBmaW5lIGZvciBhIHNtYWxsIHNldCBvZiAic3RhdGljIiBzY29wZXMuIEl0IHN0YXJ0cyB0byBm YWlsIHdoZW4gdGhlcmUgYXJlIGEgbGFyZ2UgbnVtYmVyIG9mIHNjb3Blcywgb3Igc2NvcGVzIHRo YXQgY2FuIGluY2x1ZGUgcGFyYW1ldGVycyAocmVzb3VyY2UgcGF0aHM/IGVtYWlsIGFkZHJlc3Nl cz8pLiBZb3UgY2FuIHRyeSB0byBwYXRjaCB0aG9zZSBmYWlsdXJlcyBieSBhbGxvd2luZyBzZXJ2 aWNlcyB0byBkZWZpbmUgc2VydmljZS1zcGVjaWZpYyBzcGVjaWFsICJ3aWxkY2FyZCIgc2NvcGUg dmFsdWVzIHRoYXQgY2FuIG9ubHkgYmUgdXNlZCBkdXJpbmcgcmVnaXN0cmF0aW9uIChlZyAicmVh ZDoqIikuDQoNCg0KDQpBbHRlcm5hdGl2ZWx5LCByZXBsYWNlICdzY29wZScgaW4gcmVnaXN0cmF0 aW9uIHdpdGggJ3Njb3BlX3JlZ2V4JyB0aGF0IGhvbGRzIGEgcmVndWxhciBleHByZXNzaW9uIHRo YXQgYWxsIHNjb3BlIHZhbHVlcyBpbiBhbiBhdXRob3JpemF0aW9uIGZsb3cgbXVzdCBtYXRjaC4N Cg0KDQoNCi0tDQoNCkphbWVzIE1hbmdlcg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KDQpPQXV0aCBtYWlsaW5nIGxpc3QNCg0KT0F1dGhAaWV0Zi5v cmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL29hdXRoDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9B dXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0 aA0KDQoNCg0KDQoNCg0KDQoNCg== --_000_4E1F6AAD24975D4BA5B16804296739436766C964TK5EX14MBXC284r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IFw7Y29s b3JcOndpbmRvd3RleHQiOw0KCXBhbm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywg c3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJs aW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpwcmUNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFy IjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29B Y2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNh bnMtc2VyaWYiO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6 IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30N CnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFu LkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0K CW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsN Cglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFy Z2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGRv buKAmXQgdGhpbmsgaXTigJlzIHBvc3NpYmxlIHRvIGRlZmluZSB3aGF0IGl0IG1lYW5zIGluIGFu IGludGVyb3BlcmFibGUgd2F5IGJlY2F1c2UgT0F1dGggZGlkbuKAmXQgc3BlY2lmeSBzY29wZXMg aW4gYW4gaW50ZXJvcGVyYWJsZSB3YXkuJm5ic3A7IE5vLCBJIGRvbuKAmXQgbGlrZSB0aGF0DQog ZWl0aGVyLCBidXQgSSB0aGluayB0aGF04oCZcyB3aGVyZSB0aGluZ3MgYXJlLiZuYnNwOyBUaGF0 4oCZcyB3aHkgSSB3YXMgYWR2b2NhdGluZyBkZWxldGluZyB0aGlzIHJlZ2lzdHJhdGlvbiBmZWF0 dXJlIGVudGlyZWx5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QnV0IHVuZGVyc3RhbmRpbmcgaXQgbWlnaHQgYmUgdXNl ZnVsIGluIHNvbWUgY29udGV4dHMsIEnigJltIE9LIGtlZXBpbmcgaXQsIHByb3ZpZGVkIHdlIGJl IGNsZWFyIHRoYXQgdGhlIHNlbWFudGljcyBvZiDigJxyZWdpc3RlcmVkIHRvIHVzZeKAnSBhcmUg c2VydmljZS1zcGVjaWZpYy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBUaW0gQnJheSBbbWFpbHRvOnR3YnJh eUBnb29nbGUuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBBcHJpbCAxOCwgMjAx MyA4OjM2IEFNPGJyPg0KPGI+VG86PC9iPiBNaWtlIEpvbmVzPGJyPg0KPGI+Q2M6PC9iPiBKdXN0 aW4gUmljaGVyOyBvYXV0aEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRI LVdHXSBSZWdpc3RyYXRpb246IFNjb3BlIFZhbHVlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk9uIHRoZSBzZXJ2ZXItdG8tY2xpZW50IHNpZGUsIHdoYXQgZG9lcyDigJxy ZWdpc3RlcmVkIHRvIHVzZeKAnSBtZWFuPyAmbmJzcDtEb2VzIGl0IG1lYW4gdGhhdCB0aGUgY2xp ZW50IHNob3VsZCBhc3N1bWUgdGhhdCBhbnkgc2NvcGVzIG5vdCBvbiB0aGUgbGlzdCBXSUxMIG5v dCBiZSBncmFudGVkLCBNQVkgbm90IGJlIGdyYW50ZWQuLi4uIG9yIHdoYXQ/ICZuYnNwO0lzIHRo aXMgYWxyZWFkeSBjb3ZlcmVkIGVsc2V3aGVyZT8gLVQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1 LCBBcHIgMTgsIDIwMTMgYXQgODoyOCBBTSwgTWlrZSBKb25lcyAmbHQ7PGEgaHJlZj0ibWFpbHRv Ok1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPk1pY2hhZWwuSm9u ZXNAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5UaGFua3MsIEp1c3Rpbi4mbmJzcDsgSSBhZ3JlZSB3aXRoIHRoZSBuZWVk IGZvciB0aGUgZ2VuZXJpYyB0d28tc2lkZWQgbGFuZ3VhZ2UuJm5ic3A7IEnigJlkIHN0aWxsIGtl ZXAgdGhpcyBsYW5ndWFnZQ0KIGZvciBzY29wZSwgYmVjYXVzZSB3ZSB3YW50IHRvIGNhcHR1cmUg dGhlIOKAnGRlY2xhcmluZ+KAnSBhc3BlY3QgaW4gdGhpcyBjYXNlOjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQo8c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+4oCcPC9zcGFuPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlNwYWNlIHNlcGFyYXRlZCBsaXN0 IG9mIHNjb3BlIHZhbHVlcyAoYXMgZGVzY3JpYmVkIGluIE9BdXRoIDIuMA0KPGEgaHJlZj0iaHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjc0OSNzZWN0aW9uLTMuMyIgdGFyZ2V0PSJfYmxh bmsiPlNlY3Rpb24mbmJzcDszLjMgW1JGQzY3NDldPC9hPikgdGhhdCB0aGUgY2xpZW50IGlzIGRl Y2xhcmluZyB0byB0aGUgc2VydmVyIHRoYXQgaXQgbWF5IHVzZSB3aGVuIHJlcXVlc3RpbmcgYWNj ZXNzIHRva2VucyBhbmQgdGhhdCB0aGUgc2VydmVyIGlzIGRlY2xhcmluZyB0byB0aGUgY2xpZW50 IHRoYXQgaXQgaXMgcmVnaXN0ZXJlZA0KIHRvIHVzZSB3aGVuIHJlcXVlc3RpbmcgYWNjZXNzIHRv a2Vucy48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPuKA nS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPllvdSBzaG91bGQgcHJvYmFibHkgYWxzbyByZWluZm9y Y2UgdGhhdCBzY29wZSB2YWx1ZXMgYXJlIHNlcnZpY2Utc3BlY2lmaWMgYW5kIG1heSBub3QgY29u c2lzdCBvbmx5DQogb2YgYSBzdGF0aWMgc2V0IG9mIHN0cmluZyB2YWx1ZXMsIGFuZCB0aGF0IHRo ZXJlZm9yZSwgaW4gc29tZSBjYXNlcywgYW4gZXhoYXVzdGl2ZSBsaXN0IG9mIHJlZ2lzdGVyZWQg c2NvcGUgdmFsdWVzIGlzIG5vdCBwb3NzaWJsZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg LS0gTWlrZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBKdXN0aW4gUmljaGVyIFttYWlsdG86PGEg aHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0cmUub3JnIiB0YXJnZXQ9Il9ibGFuayI+anJpY2hlckBt aXRyZS5vcmc8L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgQXByaWwgMTUsIDIwMTMg MTI6MjkgUE08L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxicj4NCjxiPlRvOjwvYj4gTWlrZSBKb25lczxicj4NCjxiPkNjOjwvYj4gVGlt IEJyYXk7IDxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9h dXRoQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBSZWdp c3RyYXRpb246IFNjb3BlIFZhbHVlczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPkkgdGhpbmsgdGhhdCBiZWNhdXNlIHRo ZSAmcXVvdDtkZWNsYXJhdGlvbiZxdW90OyBpc3N1ZSBhZmZlY3RzIGFsbCBwYXJhbWV0ZXJzIGlu IHRoZSBsaXN0LCBub3QganVzdCBzY29wZSwgd2Ugc2hvdWxkIGFkb3B0IHRoaXMgaW4gYSBoaWdo ZXIgbGV2ZWwgcGFyYWdyYXBoIGFuZCBsZWF2ZSBpdCBvdXQgb2YgdGhlIGluZGl2aWR1YWwgcGFy YW1ldGVyDQogZGVzY3JpcHRpb25zLiBUaHVzLCBzb21ldGhpbmcgbGlrZSB0aGlzIGluc2VydGVk IGFzIHRoZSBzZWNvbmQgcGFyYWdyYXBoIGluIHNlY3Rpb24gMjo8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlIGNsaWVudCBtZXRhZGF0YSB2YWx1ZXMgc2VydmUgdHdv IHBhcmFsbGVsIHB1cnBvc2VzIGluIHRoZSBvdmVyYWxsIE9BdXRoIER5bmFtaWMgUmVnaXN0cmF0 aW9uIHByb3RvY29sOg0KPGJyPg0KPGJyPg0KJm5ic3A7LSB0aGUgQ2xpZW50IHJlcXVlc3Rpbmcg aXRzIGRlc2lyZWQgdmFsdWVzIGZvciBlYWNoIHBhcmFtZXRlciB0byB0aGUgQXV0aG9yaXphdGlv biBTZXJ2ZXIgaW4gYSBbcmVnaXN0ZXJdIG9yIFt1cGRhdGVdIHJlcXVlc3QsPGJyPg0KJm5ic3A7 LSB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgaW5mb3JtaW5nIHRoZSBDbGllbnQgb2YgdGhlIGN1 cnJlbnQgdmFsdWVzIG9mIGVhY2ggcGFyYW1ldGVyIHRoYXQgdGhlIENsaWVudCBoYXMgYmVlbiBy ZWdpc3RlcmVkIHRvIHVzZSB0aHJvdWdoIGEgW2NsaWVudCBpbmZvcm1hdGlvbiByZXNwb25zZV0u DQo8YnI+DQo8YnI+DQpBbiBBdXRob3JpemF0aW9uIFNlcnZlciBNQVkgb3ZlcnJpZGUgYW55IHZh bHVlIHRoYXQgYSBDbGllbnQgcmVxdWVzdHMgZHVyaW5nIHRoZSByZWdpc3RyYXRpb24gcHJvY2Vz cyAoaW5jbHVkaW5nIGFueSBvbWl0dGVkIHZhbHVlcykgYW5kIHJlcGxhY2UgdGhlIHJlcXVlc3Rl ZCB2YWx1ZSB3aXRoIGEgZGVmYXVsdC4gVGhlIG5vcm1hdGl2ZSBpbmRpY2F0aW9ucyBpbiB0aGUg Zm9sbG93aW5nIGxpc3QgYXBwbHkgdG8gdGhlIENsaWVudCdzIGRlY2xhcmF0aW9uDQogb2YgaXRz IGRlc2lyZWQgdmFsdWVzLiA8YnI+DQo8YnI+DQpUaGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgU0hP VUxEIHByb3ZpZGUgZG9jdW1lbnRhdGlvbiBmb3IgYW55IGZpZWxkcyB0aGF0IGl0IHJlcXVpcmVz IHRvIGJlIGZpbGxlZCBpbiBieSB0aGUgY2xpZW50IG9yIHRvIGhhdmUgcGFydGljdWxhciB2YWx1 ZXMgb3IgZm9ybWF0cy4gRXh0ZW5zaW9ucyBhbmQgcHJvZmlsZXMuLi48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJn aW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KQW5kIHRoZW4gcmVtb3ZlIHRoZSBzaWRlZG5lc3MtbGFu Z3VhZ2UgZnJvbSB0aGUgc2NvcGUgcGFyYW1ldGVyIGFuZCBhbnkgb3RoZXIgcGFyYW1ldGVycyB3 aGVyZSBpdCBtaWdodCBoYXZlIGNyZXB0IGluIGluYWR2ZXJ0ZW50bHkuDQo8YnI+DQo8YnI+DQom bmJzcDstLSBKdXN0aW48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPk9uIDA0LzE1LzIwMTMgMDE6MjkgUE0sIE1pa2UgSm9uZXMgd3JvdGU6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+V2UgY291bGQgZml4IHRoZSBvbmUtc2lkZWQgbGFuZ3Vh Z2UgYnkgY2hhbmdpbmc8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+4oCcPC9zcGFuPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPlNwYWNlIHNlcGFyYXRlZCBsaXN0IG9mIHNjb3BlIHZhbHVl cyAoYXMgZGVzY3JpYmVkIGluIE9BdXRoIDIuMA0KPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYu b3JnL2h0bWwvcmZjNjc0OSNzZWN0aW9uLTMuMyIgdGFyZ2V0PSJfYmxhbmsiPlNlY3Rpb24mbmJz cDszLjMgW1JGQzY3NDldPC9hPikgdGhhdCB0aGUgY2xpZW50IGlzIGRlY2xhcmluZyB0aGF0IGl0 IG1heSB1c2Ugd2hlbiByZXF1ZXN0aW5nIGFjY2VzcyB0b2tlbnMuPC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj7igJ08L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj50bzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzttYXJnaW4tbGVmdDouNWluIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj7igJw8L3NwYW4+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+U3BhY2Ugc2VwYXJhdGVkIGxpc3Qgb2Ygc2NvcGUgdmFsdWVz IChhcyBkZXNjcmliZWQgaW4gT0F1dGggMi4wDQo8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9yZmM2NzQ5I3NlY3Rpb24tMy4zIiB0YXJnZXQ9Il9ibGFuayI+U2VjdGlvbiZuYnNw OzMuMyBbUkZDNjc0OV08L2E+KSB0aGF0IHRoZSBjbGllbnQgaXMgZGVjbGFyaW5nIHRvIHRoZSBz ZXJ2ZXIgdGhhdCBpdCBtYXkgdXNlIHdoZW4gcmVxdWVzdGluZyBhY2Nlc3MgdG9rZW5zIGFuZCB0 aGF0IHRoZSBzZXJ2ZXIgaXMgZGVjbGFyaW5nIHRvIHRoZSBjbGllbnQgdGhhdCBpdCBpcyByZWdp c3RlcmVkDQogdG8gdXNlIHdoZW4gcmVxdWVzdGluZyBhY2Nlc3MgdG9rZW5zLjwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+4oCdLjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PkFnYWluLCBJIGNob3NlIHRoZSDigJxyZWdpc3RlcmVkIHRvIHVzZeKAnSBsYW5ndWFnZSBjYXJl ZnVsbHkg4oCTIGJlY2F1c2UgaW4gdGhlIGdlbmVyYWwgY2FzZSBpdOKAmXMgbm90DQogYSByZXN0 cmljdGlvbiBvbiB0aGUgdmFsdWVzIHRoYXQgdGhlIGNsaWVudCBjYW4gdXNlIOKAkyBqdXN0IGEg c3RhdGVtZW50IGJ5IHRoZSBzZXJ2ZXIgdG8gdGhlIGNsaWVudCB0aGF0IGl0IGlzIHJlZ2lzdGVy ZWQgdG8gdXNlIHRob3NlIHBhcnRpY3VsYXIgdmFsdWVzLiZuYnNwOyBJbiBib3RoIGNhc2VzLCB0 aGUgcGFydGllcyBhcmUgbWFraW5nIGRlY2xhcmF0aW9ucyB0byBvbmUgYW5vdGhlci48L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5JZiB5b3UgYWRvcHQgdGhhdCBsYW5ndWFnZSAob3Iga2VlcCB0aGUgb3JpZ2luYWwg bGFuZ3VhZ2UpLCB0aGVuIHllcywgSeKAmWQgY29uc2lkZXIgdGhpcyBjbG9zZWQuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gSnVzdGlu IFJpY2hlciBbPGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0cmUub3JnIiB0YXJnZXQ9Il9ibGFu ayI+bWFpbHRvOmpyaWNoZXJAbWl0cmUub3JnPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBNb25k YXksIEFwcmlsIDE1LCAyMDEzIDk6NTcgQU08YnI+DQo8Yj5Ubzo8L2I+IE1pa2UgSm9uZXM8YnI+ DQo8Yj5DYzo8L2I+IFRpbSBCcmF5OyA8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5vYXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6 IFtPQVVUSC1XR10gUmVnaXN0cmF0aW9uOiBTY29wZSBWYWx1ZXM8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+SSBhYnNvbHV0ZWx5IGRvIG5vdCB3YW50IHRvIGRl bGV0ZSB0aGlzIGZlYXR1cmUsIGFzIChoYXZpbmcgaW1wbGVtZW50ZWQgaXQpIEkgdGhpbmsgaXQn cyB2ZXJ5IHVzZWZ1bC4gVGhpcyBpcyBhIHZlcnkgZXN0YWJsaXNoZWQgcGF0dGVybiBpbiBtYW51 YWwgcmVnaXN0cmF0aW9uOiBJIGtub3cgb2YgbWFueSwgbWFueSBPQXV0aDINCiBzZXJ2ZXJzIGFu ZCBjbGllbnRzIHRoYXQgYXJlIHNldCB1cCB3aGVyZSB0aGUgY2xpZW50IG11c3QgcHJlLXJlZ2lz dGVyIGEgc2V0IG9mIHNjb3Blcy4NCjxicj4NCjxicj4NCkkgZG9uJ3QgbGlrZSB0aGUgbGFuZ3Vh Z2Ugb2YgJnF1b3Q7dGhlIGNsaWVudCBpcyBkZWNsYXJpbmcmcXVvdDsgYmVjYXVzZSBpdCdzIHRv byBvbmUtc2lkZWQuIFRoZSBjbGllbnQgbWlnaHQgbm90IGhhdmUgZGVjbGFyZWQgYW55dGhpbmcs IGFuZCBpdCBtaWdodCBiZSB0aGUgc2VydmVyIHRoYXQncyBkZWNsYXJpbmcgc29tZXRoaW5nIHRv IHRoZSBjbGllbnQuIERlbGV0aW5nIHRoZSAmcXVvdDtpcyBkZWNsYXJpbmcmcXVvdDsgYml0IHJl bW92ZXMgdGhhdCB1bmludGVuZGVkIHJlc3RyaWN0aW9uDQogb2YgdGhlIGxhbmd1YWdlIHdoaWxl IGtlZXBpbmcgdGhlIG9yaWdpbmFsIG1lYW5pbmcgaW50YWN0LiBJIGFjdHVhbGx5IHRob3VnaHQg dGhhdCBJIGhhZCBmaXhlZCB0aGF0IGJlZm9yZSB0aGUgbGFzdCBkcmFmdCB3ZW50IGluIGJ1dCBh cHBhcmVudGx5IEkgbWlzc2VkIHRoaXMgb25lLjxicj4NCjxicj4NCkkgd2lsbCB3b3JrIG9uIGNs YXJpZnlpbmcgdGhlIGludGVudCBvZiB0aGUgd2hvbGUgbWV0YWRhdGEgc2V0IGluIGl0cyBpbnRy b2R1Y3RvcnkgcGFyYWdyYXBoKHMpIHNvIHRoYXQgaXQncyBjbGVhciB0aGF0IGFsbCBvZiB0aGVz ZSBmaWVsZHMgYXJlIHVzZWQgaW4gYm90aCBvZiB0aGVzZSBzaXR1YXRpb25zOjxicj4NCjxicj4N CiZuYnNwOzEpIFRoZSBjbGllbnQgZGVjbGFyaW5nIHRvIHRoZSBzZXJ2ZXIgaXRzIGRlc2lyZSB0 byB1c2UgYSBwYXJ0aWN1bGFyIHZhbHVlPGJyPg0KJm5ic3A7MikgVGhlIHNlcnZlciBkZWNsYXJp bmcgdG8gdGhlIGNsaWVudCB0aGF0IGl0IGhhcyBiZWVuIHJlZ2lzdGVyZWQgd2l0aCBhIHBhcnRp Y3VsYXIgdmFsdWU8YnI+DQo8YnI+DQpUaGlzIHNob3VsZCBob3BlZnVsbHkgY2xlYXIgdXAgdGhl IGlzc3VlIGluIHRoZSBlZGl0b3IncyBub3RlIHRoYXQgSSBjdXJyZW50bHkgaGF2ZSBhdCB0aGUg dG9wIG9mIHRoYXQgc2VjdGlvbiByaWdodCBub3csIHRvby48YnI+DQo8YnI+DQpNaWtlLCBzaW5j ZSB5b3Ugd2VyZSB0aGUgb25lIHdobyBvcmlnaW5hbGx5IGJyb3VnaHQgdXAgdGhlIGlzc3VlLCBh bmQgeW91J3JlIGZpbmUgd2l0aCB0aGUgZXhpc3RpbmcgdGV4dCwgY2FuIEkgdGFrZSB0aGlzIGFz IGNsb3NlZCBub3c/IEFzc3VtaW5nIHRoYXQgeW91IGFncmVlIHdpdGggZGVsZXRpbmcgJnF1b3Q7 aXMgZGVjbGFyaW5nJnF1b3Q7IGZvciByZWFzb25zIHN0YXRlZCBhYm92ZSwgSSdtIGZpbmUgd2l0 aCBsZWF2aW5nIGV2ZXJ5dGhpbmcgZWxzZSBhcw0KIGlzIGFuZCBzdGF5aW5nIHF1aWV0IG9uIHdo YXQgdGhlIHNlcnZlciBoYXMgdG8gZG8gd2l0aCB0aGUgc2NvcGVzLjxicj4NCjxicj4NCiZuYnNw Oy0tIEp1c3Rpbjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+T24gMDQvMTUvMjAxMyAxMjo0NCBQTSwgTWlrZSBKb25lcyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHRoaW5rIHRoYXQgdGhlIGV4aXN0aW5n IHdvcmRpbmcgaXMgc3VwZXJpb3IgdG8gdGhlIHByb3Bvc2VkIGNoYW5nZWQgd29yZGluZy4mbmJz cDsgVGhlIGV4aXN0aW5nIHdvcmRpbmcNCiBpczo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgO2Nv bG9yOndpbmRvd3RleHQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyBzY29w ZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyA7Y29sb3I6d2luZG93 dGV4dCZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IE9QVElPTkFMLiZuYnNwOyBTcGFjZSBzZXBhcmF0ZWQgbGlzdCBvZiBzY29wZSB2YWx1ZXMg KGFzIGRlc2NyaWJlZCBpbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyA7Y29sb3I6d2luZG93dGV4dCZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9BdXRoIDIuMA0KPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYu b3JnL2h0bWwvcmZjNjc0OSNzZWN0aW9uLTMuMyIgdGFyZ2V0PSJfYmxhbmsiPlNlY3Rpb24mbmJz cDszLjMgW1JGQzY3NDldPC9hPikgdGhhdCB0aGUgY2xpZW50IGlzIGRlY2xhcmluZyB0aGF0PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF TiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3IDtjb2xvcjp3aW5kb3d0ZXh0 JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg aXQgbWF5IHVzZSB3aGVuIHJlcXVlc3RpbmcgYWNjZXNzIHRva2Vucy4mbmJzcDsgSWYgb21pdHRl ZCwgYW48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgO2NvbG9yOndp bmRvd3RleHQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBBdXRob3JpemF0aW9uIFNlcnZlciBNQVkgcmVnaXN0ZXIgYSBDbGllbnQgd2l0aCBh IGRlZmF1bHQgc2V0IG9mPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 IDtjb2xvcjp3aW5kb3d0ZXh0JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgc2NvcGVzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkZvciBpbnN0YW5jZSwgdGhl IGN1cnJlbnQg4oCcY2xpZW50IGlzIGRlY2xhcmluZ+KAnSB3b3JkaW5nIHdpbGwgYWx3YXlzIGJl IGNvcnJlY3QsIHdoZXJlYXMgYXMgdGhlIGNoYW5nZQ0KIHRvIOKAnGNsaWVudCBjYW4gdXNl4oCd IHdvcmRpbmcgaW1wbGllcyBhIHJlc3RyaWN0aW9uIG9uIGNsaWVudCBiZWhhdmlvciB0aGF0IGlz IG5vdCBhbHdheXMgYXBwbGljYWJsZS4mbmJzcDsgVGhlIOKAnGNsaWVudCBpcyBkZWNsYXJpbmfi gJ0gd29yZGluZyB3YXMgc3BlY2lmaWMgYW5kIHB1cnBvc2VmdWxseSBjaG9zZW4sIGFuZCBJIHRo aW5rIHNob3VsZCBiZSByZXRhaW5lZC4mbmJzcDsgSW4gcGFydGljdWxhciwgd2UgY2Fu4oCZdCBk byBhbnl0aGluZyB0aGF0IGltcGxpZXMgdGhhdA0KIG9ubHkgdGhlIHJlZ2lzdGVyZWQgc2NvcGVz IHZhbHVlcyBjYW4gYmUgdXNlZC4mbmJzcDsgQXQgdGhlIE9BdXRoIHNwZWMgbGV2ZWwsIHRoaXMg aXMgYSBoaW50IGFzIHRvIHBvc3NpYmxlIGZ1dHVyZSBjbGllbnQgYmVoYXZpb3Ig4oCTIG5vdCBh IHJlc3RyaWN0aW9uIG9uIGZ1dHVyZSBjbGllbnQgYmVoYXZpb3IuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QWxz bywgZm9yIHRoZSByZWFzb25zIHRoYXQgVGltIHN0YXRlZCwgSeKAmW0gc3Ryb25nbHkgYWdhaW5z dCBhbnkg4oCcbWF0Y2hpbmfigJ0gb3Ig4oCccmVnZXjigJ0gbGFuZ3VhZ2UgaW4NCiB0aGUgc3Bl YyBwZXJ0YWluaW5nIHRvIHNjb3BlcyDigJMgYXMgaXTigJlzIG5vdCBhY3Rpb25hYmxlLjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPlNvIEnigJlkIHByb3Bvc2UgdGhhdCB3ZSBsZWF2ZSB0aGUgZXhpc3Rpbmcgc2Nv cGUgd29yZGluZyBpbiBwbGFjZS4mbmJzcDsgQWx0ZXJuYXRpdmVseSwgSeKAmWQgYWxzbyBiZSBm aW5lDQogd2l0aCBkZWxldGluZyB0aGlzIGZlYXR1cmUgZW50aXJlbHksIGFzIEkgZG9u4oCZdCB0 aGluayBpdOKAmXMgdXNlZnVsIGluIHRoZSBnZW5lcmFsIGNhc2UuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IC0tIE1pa2U8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4NCjxhIGhyZWY9Im1haWx0 bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGgtYm91bmNlc0Bp ZXRmLm9yZzwvYT4gWzxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVo YWxmIE9mIDwvYj5KdXN0aW4gUmljaGVyPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgQXByaWwg MTUsIDIwMTMgODowNSBBTTxicj4NCjxiPlRvOjwvYj4gVGltIEJyYXk7IDxhIGhyZWY9Im1haWx0 bzpvYXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoQGlldGYub3JnPC9hPjxicj4N CjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBSZWdpc3RyYXRpb246IFNjb3BlIFZhbHVl czwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij5PbiAwNC8xNS8y MDEzIDEwOjUyIEFNLCBUaW0gQnJheSB3cm90ZTo8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPknigJlkIHVzZSB0aGUgZXhpc3Rp bmcgd29yZGluZzsgaXTigJlzIHBlcmZlY3RseSBjbGVhci4gJm5ic3A7RmFpbGluZyB0aGF0LCBp ZiB0aGVyZeKAmXMgc3Ryb25nIGRlbWFuZCBmb3IgcmVnaXN0cmF0aW9uIG9mIHN0cnVjdHVyZWQg c2NvcGVzLCBibGVzcyB0aGUgdXNlIG9mIHJlZ2V4ZXMsIGVpdGhlciBQQ1JFcyBvciBzb21lDQog Y2FyZWZ1bCBzdWJzZXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+ PGJyPg0KVGhhbmtzIGZvciB0aGUgZmVlZGJhY2sgLS0gT2YgdGhlc2UgdHdvIGNob2ljZXMsIEkn ZCByYXRoZXIgbGVhdmUgaXQgYXMtaXMuIDxicj4NCjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Ib3dldmVy LCBJ4oCZZCBzdWJ0cmFjdCB0aGUgc2VudGVuY2Ug4oCcSWYgb21pdHRlZCwgYW4gQXV0aG9yaXph dGlvbiBTZXJ2ZXIgTUFZIHJlZ2lzdGVyIGEgQ2xpZW50IHdpdGggYSBkZWZhdWx0IHNldCBvZiAm bmJzcDtzY29wZXMu4oCdICZuYnNwO0l0IGFkZHMgbm8gdmFsdWU7IGlmIHRoZSBjbGllbnQgZG9l c27igJl0IGRlY2xhcmUgc2NvcGVzLA0KIHRoZSBjbGllbnQgZG9lc27igJl0IGRlY2xhcmUgc2Nv cGVzLCB0aGF04oCZcyBhbGwuICZuYnNwOy1UPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21h cmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpSZW1lbWJlciwgYWxsIG9mIHRoZXNlIGZpZWxkcyBh cmVuJ3QganVzdCBmb3IgdGhlIGNsaWVudCAqcmVxdWVzdCosIHRoZXkncmUgYWxzbyBmb3IgdGhl IHNlcnZlcidzICpyZXNwb25zZSogdG8gZWl0aGVyIGEgUE9TVCwgUFVULCBvciBHRVQgcmVxdWVz dC4gKEkgZGlkbid0IHJlYWxpemUgaXQsIGJ1dCBwZXJoYXBzIHRoZSB3b3JkaW5nIGFzIHN0YXRl ZCByaWdodCBub3cgZG9lc24ndCBtYWtlIHRoYXQgY2xlYXIgLS0gSSBuZWVkIHRvIGZpeCB0aGF0 LikNCiBUaGUgdmFsdWUgdGhhdCBpdCBhZGRzIGlzIGlmIHRoZSBjbGllbnQgZG9lc24ndCBhc2sg Zm9yIGFueSBwYXJ0aWN1bGFyIHNjb3BlcywgdGhlIHNlcnZlciBjYW4gc3RpbGwgYXNzaWduIGl0 IHNjb3BlcyBhbmQgdGhlIGNsaWVudCBjYW4gZG8gc29tZXRoaW5nIHNtYXJ0IHdpdGggdGhhdC4g RHVtYiBjbGllbnRzIGFyZSBhbGxvd2VkIHRvIGlnbm9yZSBpdCBpZiBpdCBkb2Vzbid0IG1lYW4g YW55dGhpbmcgdG8gdGhlbS4NCjxicj4NCjxicj4NClRoaXMgaXMgaG93IG91ciBzZXJ2ZXIgaW1w bGVtZW50YXRpb24gYWN0dWFsbHkgd29ya3MgcmlnaHQgbm93LiBJZiB0aGUgY2xpZW50IGRvZXNu J3QgYXNrIGZvciBhbnl0aGluZyBzcGVjaWZpYyBhdCByZWdpc3RyYXRpb24sIHRoZSBzZXJ2ZXIg aGFuZHMgaXQgYSBiYWcgb2YgJnF1b3Q7ZGVmYXVsdCZxdW90OyBzY29wZXMuIFNhbWUgdGhpbmcg aGFwcGVucyBhdCBhdXRoIHRpbWUgLS0gaWYgdGhlIGNsaWVudCBkb2Vzbid0IGFzayBmb3IgYW55 IHBhcnRpY3VsYXIgc2NvcGVzLA0KIHRoZSBzZXJ2ZXIgaGFuZHMgaXQgYWxsIG9mIGl0cyByZWdp c3RlcmVkIHNjb3BlcyBhcyBhIGRlZmF1bHQuIEdyYW50ZWQsIG9uIG91ciBzZXJ2ZXIsIHNjb3Bl cyBhcmUganVzdCBzaW1wbGUgc3RyaW5ncyByaWdodCBub3csIHNvIHRoZXkgZ2V0IGNvbXBhcmVk IGF0IHRoZSBhdXRoIGVuZHBvaW50IHdpdGggYW4gZXhhY3Qgc3RyaW5nLW1hdGNoIG1ldHJpYyBh bmQgc2V0LWJhc2VkIGxvZ2ljLg0KPGJyPg0KPGJyPg0KJm5ic3A7LS0gSnVzdGluPGJyPg0KPGJy Pg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIE1v biwgQXByIDE1LCAyMDEzIGF0IDc6MzUgQU0sIEp1c3RpbiBSaWNoZXIgJmx0OzxhIGhyZWY9Im1h aWx0bzpqcmljaGVyQG1pdHJlLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmpyaWNoZXJAbWl0cmUub3Jn PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5XaGF0IHdvdWxkIHlvdSBzdWdnZXN0IGZvciB3b3JkaW5nIGhlcmUsIHRoZW4/IEtlZXBp bmcgaW4gbWluZCB0aGF0IHdlIGNhbm5vdCAoYW5kIGRvbid0IHdhbnQgdG8pIHByb2hpYml0IGV4 cHJlc3Npb24tYmFzZWQgc2NvcGVzLg0KPGJyPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgi Pjxicj4NCiZuYnNwOy0tIEp1c3Rpbjwvc3Bhbj4gPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt YXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5PbiAwNC8xNS8yMDEzIDEwOjMzIEFNLCBUaW0gQnJheSB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5O bywgSSBtZWFuIGl04oCZcyBub3QgaW50ZXJvcGVyYWJsZSBhdCB0aGUgc29mdHdhcmUtZGV2ZWxv cGVyIGxldmVsLiAmbmJzcDtJIGNhbuKAmXQgcmVnaXN0ZXIgc2NvcGVzIGF0IGF1dGhvcml6YXRp b24gdGltZSB3aXRoIGFueSBwcmVkaWN0YWJsZSBlZmZlY3QgdGhhdCBJIGNhbiB3cml0ZSBjb2Rl IHRvIHN1cHBvcnQsIGVpdGhlcg0KIGNsaWVudCBvciBzZXJ2ZXIgc2lkZSwgd2l0aG91dCBvdXQt b2YtbGluZSBub24taW50ZXJvcGVyYWJsZSBrbm93bGVkZ2UgYWJvdXQgdGhlIGJlaGF2aW9yIG9m IHRoZSBzZXJ2ZXIuICZuYnNwOw0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+SSBndWVzcyBJ4oCZbSBqdXN0IG5vdCB1c2VkIHRvIE9BdXRo4oCZcyBj dWx0dXJlIG9mIGhhdmluZyBubyBleHBlY3RhdGlvbiB0aGF0IHRoaW5ncyB3aWxsIGJlIHNwZWNp ZmllZCB0aWdodGx5IGVub3VnaCB0aGF0IEkgY2FuIHdyaXRlIGNvZGUgdG8gaW1wbGVtZW50IGFz IHNwZWNpZmllZC4gJm5ic3A7LVQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21h cmdpbi1ib3R0b206MTIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPk9uIE1vbiwgQXByIDE1LCAyMDEzIGF0IDc6MTUgQU0sIEp1c3RpbiBS aWNoZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpqcmljaGVyQG1pdHJlLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPmpyaWNoZXJAbWl0cmUub3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5TY29wZXMgYXJlbid0IG1lYW50IHRvIGJlIGludGVy b3BlcmFibGUgYmV0d2VlbiBzZXJ2aWNlcyBzaW5jZSB0aGV5J3JlIG5lY2Vzc2FyaWx5IEFQSS1z cGVjaWZpYy4gVGhlIG9ubHkgaW50ZXJvcGVyYWJsZSBiaXQgaXMgdGhhdCB0aGVyZSdzICpzb21l KiBwbGFjZSB0byBwdXQgdGhlIHZhbHVlcyBhbmQgdGhhdA0KIGl0J3MgZXhwcmVzc2VkIGFzIGEg YmFnIG9mIHNwYWNlLXNlcGFyYXRlZCBzdHJpbmdzLiBIb3cgdGhvc2Ugc3RyaW5ncyBnZXQgaW50 ZXJwcmV0ZWQgYW5kIGVuZm9yY2VkICh3aGljaCBpcyByZWFsbHkgd2hhdCdzIGF0IHN0YWtlIGhl cmUpIGlzIHVwIHRvIHRoZSBBUyBhbmQgUFIgKG9yIGEgaGlnaGVyLWxldmVsIHByb3RvY29sIGxp a2UgVU1BKS48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PGJyPg0KPGJyPg0KJm5ic3A7LS0g SnVzdGluPC9zcGFuPiA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIu MHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i Pk9uIDA0LzE1LzIwMTMgMTA6MTMgQU0sIFRpbSBCcmF5IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxwPlRoaXMsIGFzIHdyaXR0ZW4sIGhhcyB6ZXJvIGludGVyb3BlcmFiaWxpdHku Jm5ic3A7IEkgdGhpbmsgdGhpcyBmZWF0dXJlIGNhbiByZWFsbHkgb25seSBiZSBtYWRlIHVzZWZ1 bCBpbiB0aGUgY2FzZSB3aGVyZSBzY29wZXMgYXJlIGZpeGVkIHN0cmluZ3MuPG86cD48L286cD48 L3A+DQo8cD4tVDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ T24gQXByIDE1LCAyMDEzIDY6NTQgQU0sICZxdW90O0p1c3RpbiBSaWNoZXImcXVvdDsgJmx0Ozxh IGhyZWY9Im1haWx0bzpqcmljaGVyQG1pdHJlLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmpyaWNoZXJA bWl0cmUub3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206 MTIuMHB0Ij5Zb3UgYXJlIGNvcnJlY3QgdGhhdCB0aGUgaWRlYSBiZWhpbmQgdGhlICZxdW90O3Nj b3BlJnF1b3Q7IHBhcmFtZXRlciBhdCByZWdpc3RyYXRpb24gaXMgYSBjb25zdHJhaW50IG9uIGF1 dGhvcml6YXRpb24tdGltZSBzY29wZXMgdGhhdCBhcmUgbWFkZSBhdmFpbGFibGUuIEl0J3MgYm90 aCBhIG1lYW5zIGZvciB0aGUgY2xpZW50IHRvIHJlcXVlc3QNCiBhIHNldCBvZiB2YWxpZCBzY29w ZXMgYW5kIGZvciB0aGUgc2VydmVyIHRvIHByb3Zpc2lvbiAoYW5kIGVjaG8gYmFjayB0byB0aGUg Y2xpZW50KSBhIHNldCBvZiB2YWxpZCBzY29wZXMuPGJyPg0KPGJyPg0KSSAqcmVhbGx5KiBkb24n dCB3YW50IHRvIHRyeSB0byBkZWZpbmUgYSBtYXRjaGluZyBsYW5ndWFnZSBmb3Igc2NvcGUgZXhw cmVzc2lvbnMuIEZvciB0aGF0IHRvIHdvcmssIGFsbCBzZXJ2ZXJzIHdvdWxkIG5lZWQgdG8gYmUg YWJsZSB0byBwcm9jZXNzIHRoZSByZWd1bGFyIGV4cHJlc3Npb25zIGZvciBhbGwgY2xpZW50cywg ZXZlbiBpZiB0aGUgc2VydmVycyB0aGVtc2VsdmVzIG9ubHkgc3VwcG9ydCBzaW1wbGUtc3RyaW5n IHNjb3BlIHZhbHVlcy4NCiBBbnkgcmVndWxhciBleHByZXNzaW9uIHN5bnRheCB3ZSBwaWNrIGhl cmUgaXMgZ3VhcmFudGVlZCB0byBiZSBpbmNvbXBhdGlibGUgd2l0aCBzb21ldGhpbmcsIGFuZCBJ IHRoaW5rIHRoZSBjb21wbGV4aXR5IGRvZXNuJ3QgYnV5IG11Y2guIEFsc28sIEkgdGhpbmsgeW91 IHN1ZGRlbmx5IGhhdmUgYSBwb3RlbnRpYWwgc2VjdXJpdHkgaXNzdWUgaWYgeW91IGhhdmUgYSBi YWQgcmVnZXggaW4gcGxhY2Ugb24gZWl0aGVyIGVuZC4NCjxicj4NCjxicj4NCkFzIGl0IHN0YW5k cyB0b2RheSwgdGhlIHNlcnZlciBjYW4gaW50ZXJwcmV0IHRoZSBpbmNvbWluZyByZWdpc3RyYXRp b24gc2NvcGVzIGFuZCBlbmZvcmNlIHRoZW0gaG93ZXZlciBpdCB3YW50cyB0by4gVGhlIHJlYWwg dHJpY2sgY29tZXMgbm90IGZyb20gYXNzaWduaW5nIHRoZSB2YWx1ZXMgdG8gYSBwYXJ0aWN1bGFy IGNsaWVudCBidXQgdG8gZW5mb3JjaW5nIHRoZW0sIGFuZCBJIHRoaW5rIHRoYXQncyBhbHdheXMg Z29pbmcgdG8gYmUgc2VydmljZS1zcGVjaWZpYy4NCiBXZSdyZSBqdXN0IG5vdCBhcyBjbGVhciBv biB0aGF0IGFzIHdlIGNvdWxkIGJlLjxicj4NCjxicj4NCkFmdGVyIGxvb2tpbmcgb3ZlciBldmVy eW9uZSdzIGNvbW1lbnRzIHNvIGZhciwgSSdkIGxpa2UgdG8gcHJvcG9zZSB0aGUgZm9sbG93aW5n IHRleHQgZm9yIHRoYXQgc2VjdGlvbjo8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4N CjxwcmU+Jm5ic3A7Jm5ic3A7IHNjb3BlPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9QVElPTkFMLiZuYnNwOyBTcGFjZSBzZXBhcmF0ZWQgbGlz dCBvZiBzY29wZSB2YWx1ZXMgKGFzIGRlc2NyaWJlZCBpbjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBPQXV0aCAyLjAgPGEgaHJlZj0iaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjc0OSNzZWN0aW9uLTMuMyIgdGFyZ2V0PSJfYmxhbmsi PlNlY3Rpb24mbmJzcDszLjMgW1JGQzY3NDldPC9hPikgdGhhdCB0aGUgY2xpZW50IGNhbiB1c2Ug d2hlbiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDtyZXF1ZXN0aW5nIGFjY2VzcyB0b2tlbnMuJm5ic3A7IEFzIHNjb3BlIHZhbHVlcyBh cmUgc2VydmljZS1zcGVjaWZpYywgPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7dGhlIEF1dGhvcml6YXRpb24gU2VydmVyIE1BWSBkZWZp bmUgaXRzIG93biBtYXRjaGluZyBydWxlcyB3aGVuPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwO2RldGVybWluaW5nIGlmIGEgc2NvcGUgdmFsdWUg dXNlZCBkdXJpbmcgYW4gYXV0aG9yaXphdGlvbiByZXF1ZXN0PG86cD48L286cD48L3ByZT4NCjxw cmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGlzIHZhbGlkIGFjY29yZGluZyB0byB0 aGUgc2NvcGUgdmFsdWVzIGFzc2lnbmVkIGR1cmluZyA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtyZWdpc3RyYXRpb24uIFBvc3NpYmxl IG1hdGNoaW5nIHJ1bGVzIGluY2x1ZGUgd2lsZGNhcmQgcGF0dGVybnMsPG86cD48L286cD48L3By ZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwO3JlZ3VsYXIgZXhwcmVzc2lv bnMsIG9yIGV4YWN0bHkgbWF0Y2hpbmcgdGhlIHN0cmluZy4gSWYgb21pdHRlZCwgPG86cD48L286 cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7YW4gQXV0 aG9yaXphdGlvbiBTZXJ2ZXIgTUFZIHJlZ2lzdGVyIGEgQ2xpZW50IHdpdGggYSBkZWZhdWx0IDxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw O3NldCBvZiBzY29wZXMuPG86cD48L286cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0K Q29tbWVudHM/IEltcHJvdmVtZW50cz88YnI+DQo8YnI+DQombmJzcDstLSBKdXN0aW48YnI+DQo8 YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i Pk9uIDA0LzE0LzIwMTMgMDg6MjMgUE0sIE1hbmdlciwgSmFtZXMgSCB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8cHJlPlByZXN1bWFibHkgYXQgYXBwIHJlZ2lzdHJhdGlvbiB0aW1l IGFueSBzY29wZSBzcGVjaWZpY2F0aW9uIGlzIHJlYWxseSBhIGNvbnN0cmFpbnQgb24gdGhlIHNj b3BlIHZhbHVlcyB0aGF0IGNhbiBiZSByZXF1ZXN0ZWQgaW4gYW4gYXV0aG9yaXphdGlvbiBmbG93 LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlNv IGlkZWFsbHkgcmVnaXN0cmF0aW9uIHNob3VsZCBhY2NlcHQgcnVsZXMgZm9yIG1hdGNoaW5nIHNj b3BlcywgYXMgb3Bwb3NlZCB0byBhY3R1YWwgc2NvcGUgdmFsdWVzLjxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPllvdSBjYW4gdHJ5IHRvIHVzZSBz Y29wZSB2YWx1ZXMgYXMgdGhlaXIgb3duIG1hdGNoaW5nIHJ1bGVzLiBUaGF0IGlzIGZpbmUgZm9y IGEgc21hbGwgc2V0IG9mICZxdW90O3N0YXRpYyZxdW90OyBzY29wZXMuIEl0IHN0YXJ0cyB0byBm YWlsIHdoZW4gdGhlcmUgYXJlIGEgbGFyZ2UgbnVtYmVyIG9mIHNjb3Blcywgb3Igc2NvcGVzIHRo YXQgY2FuIGluY2x1ZGUgcGFyYW1ldGVycyAocmVzb3VyY2UgcGF0aHM/IGVtYWlsIGFkZHJlc3Nl cz8pLiBZb3UgY2FuIHRyeSB0byBwYXRjaCB0aG9zZSBmYWlsdXJlcyBieSBhbGxvd2luZyBzZXJ2 aWNlcyB0byBkZWZpbmUgc2VydmljZS1zcGVjaWZpYyBzcGVjaWFsICZxdW90O3dpbGRjYXJkJnF1 b3Q7IHNjb3BlIHZhbHVlcyB0aGF0IGNhbiBvbmx5IGJlIHVzZWQgZHVyaW5nIHJlZ2lzdHJhdGlv biAoZWcgJnF1b3Q7cmVhZDoqJnF1b3Q7KS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5BbHRlcm5hdGl2ZWx5LCByZXBsYWNlICdzY29wZScgaW4g cmVnaXN0cmF0aW9uIHdpdGggJ3Njb3BlX3JlZ2V4JyB0aGF0IGhvbGRzIGEgcmVndWxhciBleHBy ZXNzaW9uIHRoYXQgYWxsIHNjb3BlIHZhbHVlcyBpbiBhbiBhdXRob3JpemF0aW9uIGZsb3cgbXVz dCBtYXRjaC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0K PHByZT4tLTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkphbWVzIE1hbmdlcjxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PG86cD48L286cD48L3ByZT4NCjxwcmU+T0F1dGggbWFpbGluZyBsaXN0PG86cD48L286cD48L3By ZT4NCjxwcmU+PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ T0F1dGhAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48 L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8 YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0 aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90 ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Jsb2Nr cXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_4E1F6AAD24975D4BA5B16804296739436766C964TK5EX14MBXC284r_-- From twbray@google.com Thu Apr 18 09:04:46 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80CA521F8F75 for ; Thu, 18 Apr 2013 09:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60ECiibQtcue for ; Thu, 18 Apr 2013 09:04:32 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id B76F921F8FAB for ; Thu, 18 Apr 2013 09:04:21 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id e11so3539984iej.16 for ; Thu, 18 Apr 2013 09:04:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=JozgRbEdvxdzHzVQkbdRDpl4dlsTStxEiTU6cumDqi4=; b=oNJnE9qS4wya1qyi31rAPJOgnvnTYlX08d8KT46lmckbIfCHO8ioeWH2C+dU+MFnm6 SPMcNwT5i1eOFj8rwGBy0OtjoGRUbsgSZejHq3G0I0wWQ6a6b7Il0G4a+zzt3LitJKcN pmEXXLJ9Bkdb0Itx4KZNhUfKTOqiGsRPsBGNRiKYxZnbxSdeWm/U0qciFz1A0D4ZzwZY vdtE+SNu/aNII2TWJovtKzth85O5Q+qnkEKevV9GZVwco8DsFs3liqjiemfpIljGUnTi kc1DcKFvInA3EuFNAuc0L622F7DouxwIvO5uvPOideHenSPeOFNRxS+w0hpkAwmxot+Z NHNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=JozgRbEdvxdzHzVQkbdRDpl4dlsTStxEiTU6cumDqi4=; b=cRlbgZkpbUcFNj5McoN6/DELW0SSHbKU9B1ble1vlesM1nTG0Vfm4VdYnsK7iSjfJc 1o/n5/4A0AbKMKtOHoZyBaT2veqtVKOGliof3sOa47SLF3/BHPEGse34LIRz6rca1lMg OafTR0e/OgQEe3bdLEIgX7fQ0cF2oJk9pVLNKGw6+od6gcXJBEY6eHz14Z1+4WhPtWLB 3Rm5d+YavfJv5vF2eF/v3dJ+zNHlYI6JLJpW+Pydrvo9dcjuw26UEeUsw2xH6Cvi6xgY 3agDgvR9Tyj1ofBPEQ+TCa+oHZtrZl80Ta5y5Et8HopREV8AFLGMjWVbEhdHLpsais1k 3P4w== X-Received: by 10.50.135.105 with SMTP id pr9mr198947igb.6.1366301060880; Thu, 18 Apr 2013 09:04:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.31.35 with HTTP; Thu, 18 Apr 2013 09:03:49 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436766C964@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <255B9BB34FB7D647A506DC292726F6E1150C74DADA@WSMSG3153V.srv.dir.telstra.com> <516C069F.9090308@mitre.org> <516C0B9D.6000402@mitre.org> <516C101F.2090706@mitre.org> <516C1714.8070503@mitre.org> <4E1F6AAD24975D4BA5B168042967394367641A87@TK5EX14MBXC283.redmond.corp.microsoft.com> <516C3152.9070603@mitre.org> <4E1F6AAD24975D4BA5B168042967394367641FAB@TK5EX14MBXC283.redmond.corp.microsoft.com> <516C54F2.8040708@mitre.org> <4E1F6AAD24975D4BA5B16804296739436766BCC4@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739436766C964@TK5EX14MBXC284.redmond.corp.microsoft.com> From: Tim Bray Date: Thu, 18 Apr 2013 09:03:49 -0700 Message-ID: To: Mike Jones Content-Type: multipart/alternative; boundary=e89a8f923b6664387404daa4c1d2 X-Gm-Message-State: ALoCoQkBt1Hym2lT5yqrFcKJrt/SQmylhtGEV76QhzwsOnWy3Vnpov4yMQ2AKi8CM6ekvOJqooRGv7AKZsz6KWy98kDoHe4hHhJbp/gTehVayRmXJmb5Bq3wF7/BoHzDxuPIFe+1Yy6wY1P/pgTXX/iwYS9zZAJTzcbxdhmkKNGDBBdvmC0ux9NPxFYeXCXwcTNlJIAGyMHt Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Registration: Scope Values X-BeenThere: oauth@ietf.org X-Mailman-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, 18 Apr 2013 16:04:46 -0000 --e89a8f923b6664387404daa4c1d2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I=E2=80=99m unconvinced, Mike. Obviously you=E2=80=99re right about the lo= oseness of OAuth2 scope specification, but this is a very specific semantic of what happens when you register, and I don=E2=80=99t think we=E2=80=99re bound by= history here. If we can=E2=80=99t safely say anything about what the list of scopes means= , then I'm with you let's take them out. But the most obvious intended semantic is (from the client) =E2=80=9CI promise to ask only for these=E2=80=9D and = from the server =E2=80=9CThese are the only ones I=E2=80=99ll give you tokens for.=E2=80=9D= Or does someone have use-cases for an alternative semantic? To make this concrete, I propose the following: =E2=80=9CSpace-separated list of scope values (as described in OAuth 2.0 Se= ction 3.3 [RFC6749] ) that the client is declaring to the server that it will restrict itself to when requesting access tokens, and that the server is declaring to the client that it is registered to use when requesting access tokens. Clients SHOULD assume that servers will refuse to grant access tokens for scopes not in the list provided by the server.=E2=80=9D ** On Thu, Apr 18, 2013 at 8:55 AM, Mike Jones wr= ote: > I don=E2=80=99t think it=E2=80=99s possible to define what it means in a= n interoperable > way because OAuth didn=E2=80=99t specify scopes in an interoperable way. = No, I > don=E2=80=99t like that either, but I think that=E2=80=99s where things a= re. That=E2=80=99s why I > was advocating deleting this registration feature entirely.**** > > ** ** > > But understanding it might be useful in some contexts, I=E2=80=99m OK kee= ping it, > provided we be clear that the semantics of =E2=80=9Cregistered to use=E2= =80=9D are > service-specific.**** > > ** ** > > -- Mike**** > > ** ** > > *From:* Tim Bray [mailto:twbray@google.com] > *Sent:* Thursday, April 18, 2013 8:36 AM > *To:* Mike Jones > *Cc:* Justin Richer; oauth@ietf.org > > *Subject:* Re: [OAUTH-WG] Registration: Scope Values**** > > ** ** > > On the server-to-client side, what does =E2=80=9Cregistered to use=E2=80= =9D mean? Does it > mean that the client should assume that any scopes not on the list WILL n= ot > be granted, MAY not be granted.... or what? Is this already covered > elsewhere? -T**** > > ** ** > > On Thu, Apr 18, 2013 at 8:28 AM, Mike Jones > wrote:**** > > Thanks, Justin. I agree with the need for the generic two-sided > language. I=E2=80=99d still keep this language for scope, because we wan= t to > capture the =E2=80=9Cdeclaring=E2=80=9D aspect in this case:**** > > **** > > =E2=80=9CSpace separated list of scope values (as described in OAuth 2.0 = Section 3.3 > [RFC6749] ) that the > client is declaring to the server that it may use when requesting access > tokens and that the server is declaring to the client that it is register= ed > to use when requesting access tokens.=E2=80=9D.**** > > **** > > You should probably also reinforce that scope values are service-specific > and may not consist only of a static set of string values, and that > therefore, in some cases, an exhaustive list of registered scope values i= s > not possible.**** > > **** > > -- Mike**** > > **** > > *From:* Justin Richer [mailto:jricher@mitre.org] > *Sent:* Monday, April 15, 2013 12:29 PM**** > > > *To:* Mike Jones > *Cc:* Tim Bray; oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Registration: Scope Values**** > > **** > > I think that because the "declaration" issue affects all parameters in th= e > list, not just scope, we should adopt this in a higher level paragraph an= d > leave it out of the individual parameter descriptions. Thus, something li= ke > this inserted as the second paragraph in section 2:**** > > The client metadata values serve two parallel purposes in the overall > OAuth Dynamic Registration protocol: > > - the Client requesting its desired values for each parameter to the > Authorization Server in a [register] or [update] request, > - the Authorization Server informing the Client of the current values of > each parameter that the Client has been registered to use through a [clie= nt > information response]. > > An Authorization Server MAY override any value that a Client requests > during the registration process (including any omitted values) and replac= e > the requested value with a default. The normative indications in the > following list apply to the Client's declaration of its desired values. > > The Authorization Server SHOULD provide documentation for any fields that > it requires to be filled in by the client or to have particular values or > formats. Extensions and profiles...**** > > > And then remove the sidedness-language from the scope parameter and any > other parameters where it might have crept in inadvertently. > > -- Justin**** > > On 04/15/2013 01:29 PM, Mike Jones wrote:**** > > We could fix the one-sided language by changing**** > > =E2=80=9CSpace separated list of scope values (as described in OAuth 2.0 = Section 3.3 > [RFC6749] ) that the > client is declaring that it may use when requesting access tokens.=E2=80= =9D**** > > to**** > > =E2=80=9CSpace separated list of scope values (as described in OAuth 2.0 = Section 3.3 > [RFC6749] ) that the > client is declaring to the server that it may use when requesting access > tokens and that the server is declaring to the client that it is register= ed > to use when requesting access tokens.=E2=80=9D.**** > > **** > > Again, I chose the =E2=80=9Cregistered to use=E2=80=9D language carefully= =E2=80=93 because in the > general case it=E2=80=99s not a restriction on the values that the client= can use =E2=80=93 > just a statement by the server to the client that it is registered to use > those particular values. In both cases, the parties are making > declarations to one another.**** > > **** > > If you adopt that language (or keep the original language), then yes, I= =E2=80=99d > consider this closed.**** > > **** > > -- Mike**** > > **** > > *From:* Justin Richer [mailto:jricher@mitre.org ] > *Sent:* Monday, April 15, 2013 9:57 AM > *To:* Mike Jones > *Cc:* Tim Bray; oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Registration: Scope Values**** > > **** > > I absolutely do not want to delete this feature, as (having implemented > it) I think it's very useful. This is a very established pattern in manua= l > registration: I know of many, many OAuth2 servers and clients that are se= t > up where the client must pre-register a set of scopes. > > I don't like the language of "the client is declaring" because it's too > one-sided. The client might not have declared anything, and it might be t= he > server that's declaring something to the client. Deleting the "is > declaring" bit removes that unintended restriction of the language while > keeping the original meaning intact. I actually thought that I had fixed > that before the last draft went in but apparently I missed this one. > > I will work on clarifying the intent of the whole metadata set in its > introductory paragraph(s) so that it's clear that all of these fields are > used in both of these situations: > > 1) The client declaring to the server its desire to use a particular val= ue > 2) The server declaring to the client that it has been registered with a > particular value > > This should hopefully clear up the issue in the editor's note that I > currently have at the top of that section right now, too. > > Mike, since you were the one who originally brought up the issue, and > you're fine with the existing text, can I take this as closed now? Assumi= ng > that you agree with deleting "is declaring" for reasons stated above, I'm > fine with leaving everything else as is and staying quiet on what the > server has to do with the scopes. > > -- Justin > > **** > > On 04/15/2013 12:44 PM, Mike Jones wrote:**** > > I think that the existing wording is superior to the proposed changed > wording. The existing wording is:**** > > **** > > scope**** > > OPTIONAL. Space separated list of scope values (as described in***= * > > OAuth 2.0 Section 3.3 [RFC6749]) > that the client is declaring that**** > > it may use when requesting access tokens. If omitted, an**** > > Authorization Server MAY register a Client with a default set of***= * > > scopes.**** > > **** > > For instance, the current =E2=80=9Cclient is declaring=E2=80=9D wording w= ill always be > correct, whereas as the change to =E2=80=9Cclient can use=E2=80=9D wordin= g implies a > restriction on client behavior that is not always applicable. The =E2=80= =9Cclient > is declaring=E2=80=9D wording was specific and purposefully chosen, and I= think > should be retained. In particular, we can=E2=80=99t do anything that imp= lies that > only the registered scopes values can be used. At the OAuth spec level, > this is a hint as to possible future client behavior =E2=80=93 not a rest= riction on > future client behavior.**** > > **** > > Also, for the reasons that Tim stated, I=E2=80=99m strongly against any = =E2=80=9Cmatching=E2=80=9D > or =E2=80=9Cregex=E2=80=9D language in the spec pertaining to scopes =E2= =80=93 as it=E2=80=99s not > actionable.**** > > **** > > So I=E2=80=99d propose that we leave the existing scope wording in place. > Alternatively, I=E2=80=99d also be fine with deleting this feature entire= ly, as I > don=E2=80=99t think it=E2=80=99s useful in the general case.**** > > **** > > -- Mike**** > > **** > > *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] > *On Behalf Of *Justin Richer > *Sent:* Monday, April 15, 2013 8:05 AM > *To:* Tim Bray; oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Registration: Scope Values**** > > **** > > On 04/15/2013 10:52 AM, Tim Bray wrote: > > > **** > > I=E2=80=99d use the existing wording; it=E2=80=99s perfectly clear. Fail= ing that, if > there=E2=80=99s strong demand for registration of structured scopes, bles= s the use > of regexes, either PCREs or some careful subset.**** > > > Thanks for the feedback -- Of these two choices, I'd rather leave it > as-is. > > > > **** > > **** > > However, I=E2=80=99d subtract the sentence =E2=80=9CIf omitted, an Author= ization Server > MAY register a Client with a default set of scopes.=E2=80=9D It adds no= value; if > the client doesn=E2=80=99t declare scopes, the client doesn=E2=80=99t dec= lare scopes, > that=E2=80=99s all. -T**** > > > Remember, all of these fields aren't just for the client *request*, > they're also for the server's *response* to either a POST, PUT, or GET > request. (I didn't realize it, but perhaps the wording as stated right no= w > doesn't make that clear -- I need to fix that.) The value that it adds is > if the client doesn't ask for any particular scopes, the server can still > assign it scopes and the client can do something smart with that. Dumb > clients are allowed to ignore it if it doesn't mean anything to them. > > This is how our server implementation actually works right now. If the > client doesn't ask for anything specific at registration, the server hand= s > it a bag of "default" scopes. Same thing happens at auth time -- if the > client doesn't ask for any particular scopes, the server hands it all of > its registered scopes as a default. Granted, on our server, scopes are ju= st > simple strings right now, so they get compared at the auth endpoint with = an > exact string-match metric and set-based logic. > > -- Justin > > > > **** > > **** > > On Mon, Apr 15, 2013 at 7:35 AM, Justin Richer wrote:= * > *** > > What would you suggest for wording here, then? Keeping in mind that we > cannot (and don't want to) prohibit expression-based scopes. > > -- Justin **** > > **** > > On 04/15/2013 10:33 AM, Tim Bray wrote:**** > > No, I mean it=E2=80=99s not interoperable at the software-developer leve= l. I > can=E2=80=99t register scopes at authorization time with any predictable = effect > that I can write code to support, either client or server side, without > out-of-line non-interoperable knowledge about the behavior of the server. > **** > > **** > > I guess I=E2=80=99m just not used to OAuth=E2=80=99s culture of having no= expectation that > things will be specified tightly enough that I can write code to implemen= t > as specified. -T**** > > **** > > On Mon, Apr 15, 2013 at 7:15 AM, Justin Richer wrote:= * > *** > > Scopes aren't meant to be interoperable between services since they're > necessarily API-specific. The only interoperable bit is that there's *som= e* > place to put the values and that it's expressed as a bag of space-separat= ed > strings. How those strings get interpreted and enforced (which is really > what's at stake here) is up to the AS and PR (or a higher-level protocol > like UMA). > > -- Justin **** > > **** > > On 04/15/2013 10:13 AM, Tim Bray wrote:**** > > This, as written, has zero interoperability. I think this feature can > really only be made useful in the case where scopes are fixed strings.***= * > > -T**** > > On Apr 15, 2013 6:54 AM, "Justin Richer" wrote:**** > > You are correct that the idea behind the "scope" parameter at registratio= n > is a constraint on authorization-time scopes that are made available. It'= s > both a means for the client to request a set of valid scopes and for the > server to provision (and echo back to the client) a set of valid scopes. > > I *really* don't want to try to define a matching language for scope > expressions. For that to work, all servers would need to be able to proce= ss > the regular expressions for all clients, even if the servers themselves > only support simple-string scope values. Any regular expression syntax we > pick here is guaranteed to be incompatible with something, and I think th= e > complexity doesn't buy much. Also, I think you suddenly have a potential > security issue if you have a bad regex in place on either end. > > As it stands today, the server can interpret the incoming registration > scopes and enforce them however it wants to. The real trick comes not fro= m > assigning the values to a particular client but to enforcing them, and I > think that's always going to be service-specific. We're just not as clear > on that as we could be. > > After looking over everyone's comments so far, I'd like to propose the > following text for that section: > > > **** > > scope**** > > OPTIONAL. Space separated list of scope values (as described in***= * > > OAuth 2.0 Section 3.3 [RFC6749] ) that the client can use when **** > > requesting access tokens. As scope values are service-specific, **= ** > > the Authorization Server MAY define its own matching rules when**** > > determining if a scope value used during an authorization request**= ** > > is valid according to the scope values assigned during **** > > registration. Possible matching rules include wildcard patterns,***= * > > regular expressions, or exactly matching the string. If omitted, **= ** > > an Authorization Server MAY register a Client with a default **** > > set of scopes.**** > > > Comments? Improvements? > > -- Justin > > > **** > > On 04/14/2013 08:23 PM, Manger, James H wrote:**** > > Presumably at app registration time any scope specification is really a c= onstraint on the scope values that can be requested in an authorization flo= w.**** > > **** > > So ideally registration should accept rules for matching scopes, as oppos= ed to actual scope values.**** > > **** > > You can try to use scope values as their own matching rules. That is fine= for a small set of "static" scopes. It starts to fail when there are a lar= ge number of scopes, or scopes that can include parameters (resource paths?= email addresses?). You can try to patch those failures by allowing service= s to define service-specific special "wildcard" scope values that can only = be used during registration (eg "read:*").**** > > **** > > Alternatively, replace 'scope' in registration with 'scope_regex' that ho= lds a regular expression that all scope values in an authorization flow mus= t match.**** > > **** > > --**** > > James Manger**** > > _______________________________________________**** > > 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**** > > **** > > **** > > **** > > **** > > **** > > **** > > **** > > ** ** > --e89a8f923b6664387404daa4c1d2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I=E2=80=99m unconvinced, Mike. =C2=A0Obviously you=E2=80= =99re right about the looseness of OAuth2 scope specification, but this is = a very specific semantic of what happens when you register, and I don=E2=80= =99t think we=E2=80=99re bound by history here. =C2=A0 If we can=E2=80=99t = safely say anything about what the list of scopes means, then I'm with = you let's take them out. =C2=A0But the most obvious intended semantic i= s (from the client) =E2=80=9CI promise to ask only for these=E2=80=9D and f= rom the server =E2=80=9CThese are the only ones I=E2=80=99ll give you token= s for.=E2=80=9D =C2=A0Or does someone have use-cases for an alternative sem= antic?

To make this concrete, I propose the following:
<= div style>

=E2=80=9CSpace-= separated list of scope values (as described in OAuth 2.0=C2=A0Section=C2=A03.3 [RFC6749]) that the client is declaring to the = server that it will restrict itself to when requesting access tokens, and t= hat the server is declaring to the client that it is registered to use when= requesting access tokens. =C2=A0Clients SHOULD assume that servers will ref= use to grant access tokens for scopes not in the list provided by the serve= r.=E2=80=9D




On Thu, Apr 18, 2013= at 8:55 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

I don=E2=80=99t think it= =E2=80=99s possible to define what it means in an interoperable way because= OAuth didn=E2=80=99t specify scopes in an interoperable way.=C2=A0 No, I d= on=E2=80=99t like that either, but I think that=E2=80=99s where things are.=C2=A0 That=E2=80=99s = why I was advocating deleting this registration feature entirely.=

=C2=A0

But understanding it migh= t be useful in some contexts, I=E2=80=99m OK keeping it, provided we be cle= ar that the semantics of =E2=80=9Cregistered to use=E2=80=9D are service-sp= ecific.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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

=C2=A0

From: Tim Bray= [mailto:twbray@goog= le.com]
Sent: Thursday, April 18, 2013 8:36 AM
To: Mike Jones
Cc: Justin Richer; oauth@ietf.org


Subject: Re: [OAUTH-WG] Registration: Scope Values

=C2=A0

On the server-to-client side, what does =E2=80=9Creg= istered to use=E2=80=9D mean? =C2=A0Does it mean that the client should ass= ume that any scopes not on the list WILL not be granted, MAY not be granted= .... or what? =C2=A0Is this already covered elsewhere? -T

=C2=A0<= /p>

On Thu, Apr 18, 2013 at 8:28 AM, Mike Jones <Michael.Jones@= microsoft.com> wrote:

Thanks, Justin.=C2=A0 I a= gree with the need for the generic two-sided language.=C2=A0 I=E2=80=99d st= ill keep this language for scope, because we want to capture the =E2=80=9Cdeclaring=E2=80=9D aspe= ct in this case:

=C2=A0

=E2=80=9CSpace separated list of scope values (as de= scribed in OAuth 2.0 Section=C2=A03.3 [RFC6749]) that the client is declaring to the serve= r that it may use when requesting access tokens and that the server is decl= aring to the client that it is registered to use when requesting access tokens.=E2= =80=9D.

=C2=A0

You should probably also = reinforce that scope values are service-specific and may not consist only of a static set of string values, and that therefore, in some cases, an ex= haustive list of registered scope values is not possible.<= /u>

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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

=C2=A0

From: Justin R= icher [mailto:jriche= r@mitre.org]
Sent: Monday, April 15, 2013 12:29 PM


To: Mike Jones
Cc: Tim Bray; oa= uth@ietf.org
Subject: Re: [OAUTH-WG] Registration: Scope Values

=C2=A0

I think that because = the "declaration" issue affects all parameters in the list, not j= ust scope, we should adopt this in a higher level paragraph and leave it ou= t of the individual parameter descriptions. Thus, something like this inserted as the second paragraph i= n section 2:

The client metadata values serve two parallel purpos= es in the overall OAuth Dynamic Registration protocol:

=C2=A0- the Client requesting its desired values for each parameter to the = Authorization Server in a [register] or [update] request,
=C2=A0- the Authorization Server informing the Client of the current values= of each parameter that the Client has been registered to use through a [cl= ient information response].

An Authorization Server MAY override any value that a Client requests durin= g the registration process (including any omitted values) and replace the r= equested value with a default. The normative indications in the following l= ist apply to the Client's declaration of its desired values.

The Authorization Server SHOULD provide documentation for any fields that i= t requires to be filled in by the client or to have particular values or fo= rmats. Extensions and profiles...


And then remove the sidedness-language from the scope parameter and any oth= er parameters where it might have crept in inadvertently.

=C2=A0-- Justin

On 04/15/2013 01:29 PM, Mike Jones wrote:<= /u>

We could fix the one-side= d language by changing

=E2=80=9CSpace separated list of scope values (as de= scribed in OAuth 2.0 Section=C2=A03.3 [RFC6749]) that the client is declaring that it may = use when requesting access tokens.=E2=80= =9D

to

=E2=80=9CSpace separated list of scope values (as de= scribed in OAuth 2.0 Section=C2=A03.3 [RFC6749]) that the client is declaring to the serve= r that it may use when requesting access tokens and that the server is decl= aring to the client that it is registered to use when requesting access tokens.=E2= =80=9D.

=C2=A0

Again, I chose the =E2=80= =9Cregistered to use=E2=80=9D language carefully =E2=80=93 because in the g= eneral case it=E2=80=99s not a restriction on the values that the client can use =E2=80=93 just a state= ment by the server to the client that it is registered to use those particu= lar values.=C2=A0 In both cases, the parties are making declarations to one= another.

=C2=A0

If you adopt that languag= e (or keep the original language), then yes, I=E2=80=99d consider this clos= ed.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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

=C2=A0

From: Justin R= icher [mailto:jriche= r@mitre.org]
Sent: Monday, April 15, 2013 9:57 AM
To: Mike Jones
Cc: Tim Bray; oa= uth@ietf.org
Subject: Re: [OAUTH-WG] Registration: Scope Values<= /u>

=C2=A0

I absolutely do not w= ant to delete this feature, as (having implemented it) I think it's ver= y useful. This is a very established pattern in manual registration: I know= of many, many OAuth2 servers and clients that are set up where the client must pre-register a s= et of scopes.

I don't like the language of "the client is declaring" becaus= e it's too one-sided. The client might not have declared anything, and = it might be the server that's declaring something to the client. Deleti= ng the "is declaring" bit removes that unintended restriction of the language while keeping the original meaning intact. I actually thou= ght that I had fixed that before the last draft went in but apparently I mi= ssed this one.

I will work on clarifying the intent of the whole metadata set in its intro= ductory paragraph(s) so that it's clear that all of these fields are us= ed in both of these situations:

=C2=A01) The client declaring to the server its desire to use a particular = value
=C2=A02) The server declaring to the client that it has been registered wit= h a particular value

This should hopefully clear up the issue in the editor's note that I cu= rrently have at the top of that section right now, too.

Mike, since you were the one who originally brought up the issue, and you&#= 39;re fine with the existing text, can I take this as closed now? Assuming = that you agree with deleting "is declaring" for reasons stated ab= ove, I'm fine with leaving everything else as is and staying quiet on what the server has to do with the scopes.

=C2=A0-- Justin

On 04/15/2013 12:44 PM, Mike Jones wrote:<= /u>

I think that the existing= wording is superior to the proposed changed wording.=C2=A0 The existing wo= rding is:

=C2=A0

=C2=A0=C2=A0 scope

=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 OPTIONAL.=C2=A0 Space separated list of scope values (as described in

=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 OAuth 2.0 Section=C2=A03.3 [RFC6749]) that the client is declaring that<= u>

=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 it may use when requesting access tokens.=C2=A0 If omitted, an

=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Authorization Server MAY register a Client with a default set of=

=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 scopes.

=C2=A0

For instance, the current= =E2=80=9Cclient is declaring=E2=80=9D wording will always be correct, wher= eas as the change to =E2=80=9Cclient can use=E2=80=9D wording implies a restriction on clien= t behavior that is not always applicable.=C2=A0 The =E2=80=9Cclient is decl= aring=E2=80=9D wording was specific and purposefully chosen, and I think sh= ould be retained.=C2=A0 In particular, we can=E2=80=99t do anything that im= plies that only the registered scopes values can be used.=C2=A0 At the OAuth spec lev= el, this is a hint as to possible future client behavior =E2=80=93 not a re= striction on future client behavior.

=C2=A0

Also, for the reasons tha= t Tim stated, I=E2=80=99m strongly against any =E2=80=9Cmatching=E2=80=9D o= r =E2=80=9Cregex=E2=80=9D language in the spec pertaining to scopes =E2=80=93 as it=E2=80=99s not actionable.

=C2=A0

So I=E2=80=99d propose th= at we leave the existing scope wording in place.=C2=A0 Alternatively, I=E2= =80=99d also be fine with deleting this feature entirely, as I don=E2=80=99t think it=E2=80=99s= useful in the general case.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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

=C2=A0

From: oauth-bounces@i= etf.org [ma= ilto:oauth-bounces@ietf.org] On Behalf Of Justin Richer
Sent: Monday, April 15, 2013 8:05 AM
To: Tim Bray; oa= uth@ietf.org
Subject: Re: [OAUTH-WG] Registration: Scope Values<= /u>

=C2=A0

On 04/15/2013 10:52 A= M, Tim Bray wrote:


I=E2=80=99d use the existing wording; it=E2=80=99s p= erfectly clear. =C2=A0Failing that, if there=E2=80=99s strong demand for re= gistration of structured scopes, bless the use of regexes, either PCREs or = some careful subset.


Thanks for the feedback -- Of these two choices, I'd rather leave it as= -is.



=C2=A0

However, I=E2=80=99d subtract the sentence =E2=80=9C= If omitted, an Authorization Server MAY register a Client with a default se= t of =C2=A0scopes.=E2=80=9D =C2=A0It adds no value; if the client doesn=E2= =80=99t declare scopes, the client doesn=E2=80=99t declare scopes, that=E2=80=99s all. =C2=A0-T=


Remember, all of these fields aren't just for the client *request*, the= y're also for the server's *response* to either a POST, PUT, or GET= request. (I didn't realize it, but perhaps the wording as stated right= now doesn't make that clear -- I need to fix that.) The value that it adds is if the client doesn't ask for any particular= scopes, the server can still assign it scopes and the client can do someth= ing smart with that. Dumb clients are allowed to ignore it if it doesn'= t mean anything to them.

This is how our server implementation actually works right now. If the clie= nt doesn't ask for anything specific at registration, the server hands = it a bag of "default" scopes. Same thing happens at auth time -- = if the client doesn't ask for any particular scopes, the server hands it all of its registered scopes as a default. Granted, on= our server, scopes are just simple strings right now, so they get compared= at the auth endpoint with an exact string-match metric and set-based logic= .

=C2=A0-- Justin



=C2=A0<= /p>

On Mon, Apr 15, 2013 at 7:35 AM, Justin Richer <<= a href=3D"mailto:jricher@mitre.org" target=3D"_blank">jricher@mitre.org= > wrote:

What would you suggest for wording here, then? Keepi= ng in mind that we cannot (and don't want to) prohibit expression-based= scopes.

=C2=A0-- Justin

=C2=A0<= /p>

On 04/15/2013 10:33 AM, Tim Bray wrote:

No, I mean it=E2=80=99s not interoperable at the sof= tware-developer level. =C2=A0I can=E2=80=99t register scopes at authorizati= on time with any predictable effect that I can write code to support, eithe= r client or server side, without out-of-line non-interoperable knowledge abo= ut the behavior of the server. =C2=A0

=C2=A0

I guess I=E2=80=99m just not used to OAuth=E2=80=99s= culture of having no expectation that things will be specified tightly eno= ugh that I can write code to implement as specified. =C2=A0-T=

=C2=A0<= /p>

On Mon, Apr 15, 2013 at 7:15 AM, Justin Richer <<= a href=3D"mailto:jricher@mitre.org" target=3D"_blank">jricher@mitre.org= > wrote:

Scopes aren't meant to be interoperable between = services since they're necessarily API-specific. The only interoperable= bit is that there's *some* place to put the values and that it's expressed as a bag of space-separated strings. How those strings = get interpreted and enforced (which is really what's at stake here) is = up to the AS and PR (or a higher-level protocol like UMA).

=C2=A0-- Justin

=C2=A0<= /p>

On 04/15/2013 10:13 AM, Tim Bray wrote:

This, as written, has zero interoperability.=C2=A0 I think this feature = can really only be made useful in the case where scopes are fixed strings.<= u>

-T

On Apr 15, 2013 6:54 AM, "Justin Richer" &= lt;jricher@mitre.org= > wrote:

You are correct that = the idea behind the "scope" parameter at registration is a constr= aint on authorization-time scopes that are made available. It's both a = means for the client to request a set of valid scopes and for the server to provision (and echo back to th= e client) a set of valid scopes.

I *really* don't want to try to define a matching language for scope ex= pressions. For that to work, all servers would need to be able to process t= he regular expressions for all clients, even if the servers themselves only= support simple-string scope values. Any regular expression syntax we pick here is guaranteed to be incompatibl= e with something, and I think the complexity doesn't buy much. Also, I = think you suddenly have a potential security issue if you have a bad regex = in place on either end.

As it stands today, the server can interpret the incoming registration scop= es and enforce them however it wants to. The real trick comes not from assi= gning the values to a particular client but to enforcing them, and I think = that's always going to be service-specific. We're just not as clear on that as we could be.

After looking over everyone's comments so far, I'd like to propose = the following text for that section:


=C2=A0=C2=A0 scope
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 OPTIONAL.=C2=A0 Space separated list of=
 scope values (as described in
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 OAuth 2.0 Section=C2=A03.3 [RFC6749]<=
/a>) that the client can use when 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0requesting access tokens.=C2=A0 As=
 scope values are service-specific, 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0the Authorization Server MAY defin=
e its own matching rules when
=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0determining if a scope value used durin=
g an authorization request
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 is valid according to the scope values =
assigned during 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0registration. Possible matching ru=
les include wildcard patterns,
=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0regular expressions, or exactly matchin=
g the string. If omitted, 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0an Authorization Server MAY regist=
er a Client with a default 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0set of scopes.


Comments? Improvements?

=C2=A0-- Justin


On 04/14/2013 08:23 PM, Manger, James H wrote:

Presumably at app registration time any scope specification is really =
a constraint on the scope values that can be requested in an authorization =
flow.
=C2=A0
So ideally registration should accept rules for matching scopes, as op=
posed to actual scope values.
=C2=A0
You can try to use scope values as their own matching rules. That is f=
ine for a small set of "static" scopes. It starts to fail when th=
ere are a large number of scopes, or scopes that can include parameters (re=
source paths? email addresses?). You can try to patch those failures by all=
owing services to define service-specific special "wildcard" scop=
e values that can only be used during registration (eg "read:*").=

=C2=A0
Alternatively, replace 'scope' in registration with 'scope=
_regex' that holds a regular expression that all scope values in an aut=
horization flow must match.
=C2=A0
--
James Manger
_______________________________________________
OAuth mailing list
OAuth@ietf.org=

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

=C2=A0


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

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0


--e89a8f923b6664387404daa4c1d2-- From tonynad@microsoft.com Thu Apr 18 09:16:43 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5033121F8E4C for ; Thu, 18 Apr 2013 09:16:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.534 X-Spam-Level: X-Spam-Status: No, score=0.534 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cQkiqc3a1R0T for ; Thu, 18 Apr 2013 09:16:41 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0238.outbound.protection.outlook.com [207.46.163.238]) by ietfa.amsl.com (Postfix) with ESMTP id 2652121F8FD6 for ; Thu, 18 Apr 2013 09:16:41 -0700 (PDT) Received: from BY2FFO11FD013.protection.gbl (10.1.15.200) by BY2FFO11HUB027.protection.gbl (10.1.14.113) with Microsoft SMTP Server (TLS) id 15.0.675.0; Thu, 18 Apr 2013 16:16:40 +0000 Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD013.mail.protection.outlook.com (10.1.14.75) with Microsoft SMTP Server (TLS) id 15.0.675.0 via Frontend Transport; Thu, 18 Apr 2013 16:16:39 +0000 Received: from va3outboundpool.messaging.microsoft.com (157.54.51.112) by mail.microsoft.com (157.54.80.67) with Microsoft SMTP Server (TLS) id 14.2.318.3; Thu, 18 Apr 2013 16:16:36 +0000 Received: from mail74-va3-R.bigfish.com (10.7.14.245) by VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id 14.1.225.23; Thu, 18 Apr 2013 16:13:53 +0000 Received: from mail74-va3 (localhost [127.0.0.1]) by mail74-va3-R.bigfish.com (Postfix) with ESMTP id 513A53C03F4 for ; Thu, 18 Apr 2013 16:13:53 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT005.namprd03.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -24 X-BigFish: PS-24(zzbb2dI98dI9371Ic89bh1418Ic857h4015I199bI1447Idf9Izz1f42h1fc6h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1082kz97hz1033IL17326ah18c673h8275bh8275dh15d4Iz31h2a8h668h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh9a9j1155h) Received-SPF: softfail (mail74-va3: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=tonynad@microsoft.com; helo=BL2PRD0310HT005.namprd03.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BY2PR03MB043; H:BY2PR03MB041.namprd03.prod.outlook.com; LANG:en; Received: from mail74-va3 (localhost.localdomain [127.0.0.1]) by mail74-va3 (MessageSwitch) id 1366301627841050_5222; Thu, 18 Apr 2013 16:13:47 +0000 (UTC) Received: from VA3EHSMHS020.bigfish.com (unknown [10.7.14.247]) by mail74-va3.bigfish.com (Postfix) with ESMTP id BB00318007A; Thu, 18 Apr 2013 16:13:47 +0000 (UTC) Received: from BL2PRD0310HT005.namprd03.prod.outlook.com (157.56.240.21) by VA3EHSMHS020.bigfish.com (10.7.99.30) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 18 Apr 2013 16:13:46 +0000 Received: from BY2PR03MB043.namprd03.prod.outlook.com (10.255.241.147) by BL2PRD0310HT005.namprd03.prod.outlook.com (10.255.97.40) with Microsoft SMTP Server (TLS) id 14.16.299.2; Thu, 18 Apr 2013 16:13:45 +0000 Received: from BY2PR03MB041.namprd03.prod.outlook.com (10.255.241.145) by BY2PR03MB043.namprd03.prod.outlook.com (10.255.241.147) with Microsoft SMTP Server (TLS) id 15.0.670.13; Thu, 18 Apr 2013 16:13:42 +0000 Received: from BY2PR03MB041.namprd03.prod.outlook.com ([169.254.8.206]) by BY2PR03MB041.namprd03.prod.outlook.com ([169.254.8.18]) with mapi id 15.00.0670.000; Thu, 18 Apr 2013 16:13:42 +0000 From: Anthony Nadalin To: Tim Bray , Mike Jones Thread-Topic: [OAUTH-WG] Registration: Scope Values Thread-Index: AQHOOeqUpTbAsDaRHkORyYtY57tExZjXfRiAgAADhACAAAk/gIAAITkAgARzy4CAAAIrAIAABU6AgAACc4CAAAJxoA== Date: Thu, 18 Apr 2013 16:13:42 +0000 Message-ID: References: <255B9BB34FB7D647A506DC292726F6E1150C74DADA@WSMSG3153V.srv.dir.telstra.com> <516C069F.9090308@mitre.org> <516C0B9D.6000402@mitre.org> <516C101F.2090706@mitre.org> <516C1714.8070503@mitre.org> <4E1F6AAD24975D4BA5B168042967394367641A87@TK5EX14MBXC283.redmond.corp.microsoft.com> <516C3152.9070603@mitre.org> <4E1F6AAD24975D4BA5B168042967394367641FAB@TK5EX14MBXC283.redmond.corp.microsoft.com> <516C54F2.8040708@mitre.org> <4E1F6AAD24975D4BA5B16804296739436766BCC4@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739436766C964@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: [212.47.23.197] Content-Type: multipart/alternative; boundary="_000_d857b70d64e349a2ac0ff52a6aaf5a19BY2PR03MB041namprd03pro_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: BY2PR03MB043.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%GOOGLE.COM$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC107.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC107.redmond.corp.microsoft.com X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(71186001)(1511001)(33646001)(20776003)(66066001)(80022001)(47976001)(79102001)(50986001)(512874001)(49866001)(81542001)(16676001)(47446002)(4396001)(53806001)(59766001)(54356001)(51856001)(74502001)(6806003)(76482001)(564824004)(44976003)(47736001)(69226001)(74662001)(56776001)(31966008)(56816002)(81342001)(65816001)(63696002)(77982001)(46102001)(54316002)(42262001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB027; H:TK5EX14HUBC107.redmond.corp.microsoft.com; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 08200063E9 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Registration: Scope Values X-BeenThere: oauth@ietf.org X-Mailman-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, 18 Apr 2013 16:16:43 -0000 --_000_d857b70d64e349a2ac0ff52a6aaf5a19BY2PR03MB041namprd03pro_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SWYgSSBkb27igJl0IHNwZWNpZnkgYSBzY29wZSwgdGhlbiB0aGUgc2VydmVyIGNhbiBhbGxvY2F0 ZSBhIGRlZmF1bHQgKG9yIGRlZmF1bHQgc2V0KSwgdGh1cyB0aGF0IGJyZWFrcyB0aGUgc2VtYW50 aWNzIHlvdSBkZXNjcmliZQ0KDQpGcm9tOiBvYXV0aC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86 b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFRpbSBCcmF5DQpTZW50OiBUaHVy c2RheSwgQXByaWwgMTgsIDIwMTMgOTowNCBBTQ0KVG86IE1pa2UgSm9uZXMNCkNjOiBvYXV0aEBp ZXRmLm9yZw0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gUmVnaXN0cmF0aW9uOiBTY29wZSBWYWx1 ZXMNCg0KSeKAmW0gdW5jb252aW5jZWQsIE1pa2UuICBPYnZpb3VzbHkgeW914oCZcmUgcmlnaHQg YWJvdXQgdGhlIGxvb3NlbmVzcyBvZiBPQXV0aDIgc2NvcGUgc3BlY2lmaWNhdGlvbiwgYnV0IHRo aXMgaXMgYSB2ZXJ5IHNwZWNpZmljIHNlbWFudGljIG9mIHdoYXQgaGFwcGVucyB3aGVuIHlvdSBy ZWdpc3RlciwgYW5kIEkgZG9u4oCZdCB0aGluayB3ZeKAmXJlIGJvdW5kIGJ5IGhpc3RvcnkgaGVy ZS4gICBJZiB3ZSBjYW7igJl0IHNhZmVseSBzYXkgYW55dGhpbmcgYWJvdXQgd2hhdCB0aGUgbGlz dCBvZiBzY29wZXMgbWVhbnMsIHRoZW4gSSdtIHdpdGggeW91IGxldCdzIHRha2UgdGhlbSBvdXQu ICBCdXQgdGhlIG1vc3Qgb2J2aW91cyBpbnRlbmRlZCBzZW1hbnRpYyBpcyAoZnJvbSB0aGUgY2xp ZW50KSDigJxJIHByb21pc2UgdG8gYXNrIG9ubHkgZm9yIHRoZXNl4oCdIGFuZCBmcm9tIHRoZSBz ZXJ2ZXIg4oCcVGhlc2UgYXJlIHRoZSBvbmx5IG9uZXMgSeKAmWxsIGdpdmUgeW91IHRva2VucyBm b3Iu4oCdICBPciBkb2VzIHNvbWVvbmUgaGF2ZSB1c2UtY2FzZXMgZm9yIGFuIGFsdGVybmF0aXZl IHNlbWFudGljPw0KDQpUbyBtYWtlIHRoaXMgY29uY3JldGUsIEkgcHJvcG9zZSB0aGUgZm9sbG93 aW5nOg0K4oCcU3BhY2Utc2VwYXJhdGVkIGxpc3Qgb2Ygc2NvcGUgdmFsdWVzIChhcyBkZXNjcmli ZWQgaW4gT0F1dGggMi4wIFNlY3Rpb24gMy4zIFtSRkM2NzQ5XTxodHRwOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9yZmM2NzQ5I3NlY3Rpb24tMy4zPikgdGhhdCB0aGUgY2xpZW50IGlzIGRlY2xhcmlu ZyB0byB0aGUgc2VydmVyIHRoYXQgaXQgd2lsbCByZXN0cmljdCBpdHNlbGYgdG8gd2hlbiByZXF1 ZXN0aW5nIGFjY2VzcyB0b2tlbnMsIGFuZCB0aGF0IHRoZSBzZXJ2ZXIgaXMgZGVjbGFyaW5nIHRv IHRoZSBjbGllbnQgdGhhdCBpdCBpcyByZWdpc3RlcmVkIHRvIHVzZSB3aGVuIHJlcXVlc3Rpbmcg YWNjZXNzIHRva2Vucy4gIENsaWVudHMgU0hPVUxEIGFzc3VtZSB0aGF0IHNlcnZlcnMgd2lsbCBy ZWZ1c2UgdG8gZ3JhbnQgYWNjZXNzIHRva2VucyBmb3Igc2NvcGVzIG5vdCBpbiB0aGUgbGlzdCBw cm92aWRlZCBieSB0aGUgc2VydmVyLuKAnQ0KDQoNCk9uIFRodSwgQXByIDE4LCAyMDEzIGF0IDg6 NTUgQU0sIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWlj aGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQpJIGRvbuKAmXQgdGhpbmsgaXTigJlz IHBvc3NpYmxlIHRvIGRlZmluZSB3aGF0IGl0IG1lYW5zIGluIGFuIGludGVyb3BlcmFibGUgd2F5 IGJlY2F1c2UgT0F1dGggZGlkbuKAmXQgc3BlY2lmeSBzY29wZXMgaW4gYW4gaW50ZXJvcGVyYWJs ZSB3YXkuICBObywgSSBkb27igJl0IGxpa2UgdGhhdCBlaXRoZXIsIGJ1dCBJIHRoaW5rIHRoYXTi gJlzIHdoZXJlIHRoaW5ncyBhcmUuICBUaGF04oCZcyB3aHkgSSB3YXMgYWR2b2NhdGluZyBkZWxl dGluZyB0aGlzIHJlZ2lzdHJhdGlvbiBmZWF0dXJlIGVudGlyZWx5Lg0KDQpCdXQgdW5kZXJzdGFu ZGluZyBpdCBtaWdodCBiZSB1c2VmdWwgaW4gc29tZSBjb250ZXh0cywgSeKAmW0gT0sga2VlcGlu ZyBpdCwgcHJvdmlkZWQgd2UgYmUgY2xlYXIgdGhhdCB0aGUgc2VtYW50aWNzIG9mIOKAnHJlZ2lz dGVyZWQgdG8gdXNl4oCdIGFyZSBzZXJ2aWNlLXNwZWNpZmljLg0KDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZy b206IFRpbSBCcmF5IFttYWlsdG86dHdicmF5QGdvb2dsZS5jb208bWFpbHRvOnR3YnJheUBnb29n bGUuY29tPl0NClNlbnQ6IFRodXJzZGF5LCBBcHJpbCAxOCwgMjAxMyA4OjM2IEFNDQpUbzogTWlr ZSBKb25lcw0KQ2M6IEp1c3RpbiBSaWNoZXI7IG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBp ZXRmLm9yZz4NCg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gUmVnaXN0cmF0aW9uOiBTY29wZSBW YWx1ZXMNCg0KT24gdGhlIHNlcnZlci10by1jbGllbnQgc2lkZSwgd2hhdCBkb2VzIOKAnHJlZ2lz dGVyZWQgdG8gdXNl4oCdIG1lYW4/ICBEb2VzIGl0IG1lYW4gdGhhdCB0aGUgY2xpZW50IHNob3Vs ZCBhc3N1bWUgdGhhdCBhbnkgc2NvcGVzIG5vdCBvbiB0aGUgbGlzdCBXSUxMIG5vdCBiZSBncmFu dGVkLCBNQVkgbm90IGJlIGdyYW50ZWQuLi4uIG9yIHdoYXQ/ICBJcyB0aGlzIGFscmVhZHkgY292 ZXJlZCBlbHNld2hlcmU/IC1UDQoNCk9uIFRodSwgQXByIDE4LCAyMDEzIGF0IDg6MjggQU0sIE1p a2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5Kb25l c0BtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQpUaGFua3MsIEp1c3Rpbi4gIEkgYWdyZWUgd2l0aCB0 aGUgbmVlZCBmb3IgdGhlIGdlbmVyaWMgdHdvLXNpZGVkIGxhbmd1YWdlLiAgSeKAmWQgc3RpbGwg a2VlcCB0aGlzIGxhbmd1YWdlIGZvciBzY29wZSwgYmVjYXVzZSB3ZSB3YW50IHRvIGNhcHR1cmUg dGhlIOKAnGRlY2xhcmluZ+KAnSBhc3BlY3QgaW4gdGhpcyBjYXNlOg0KDQrigJxTcGFjZSBzZXBh cmF0ZWQgbGlzdCBvZiBzY29wZSB2YWx1ZXMgKGFzIGRlc2NyaWJlZCBpbiBPQXV0aCAyLjAgU2Vj dGlvbiAzLjMgW1JGQzY3NDldPGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY3NDkjc2Vj dGlvbi0zLjM+KSB0aGF0IHRoZSBjbGllbnQgaXMgZGVjbGFyaW5nIHRvIHRoZSBzZXJ2ZXIgdGhh dCBpdCBtYXkgdXNlIHdoZW4gcmVxdWVzdGluZyBhY2Nlc3MgdG9rZW5zIGFuZCB0aGF0IHRoZSBz ZXJ2ZXIgaXMgZGVjbGFyaW5nIHRvIHRoZSBjbGllbnQgdGhhdCBpdCBpcyByZWdpc3RlcmVkIHRv IHVzZSB3aGVuIHJlcXVlc3RpbmcgYWNjZXNzIHRva2Vucy7igJ0uDQoNCllvdSBzaG91bGQgcHJv YmFibHkgYWxzbyByZWluZm9yY2UgdGhhdCBzY29wZSB2YWx1ZXMgYXJlIHNlcnZpY2Utc3BlY2lm aWMgYW5kIG1heSBub3QgY29uc2lzdCBvbmx5IG9mIGEgc3RhdGljIHNldCBvZiBzdHJpbmcgdmFs dWVzLCBhbmQgdGhhdCB0aGVyZWZvcmUsIGluIHNvbWUgY2FzZXMsIGFuIGV4aGF1c3RpdmUgbGlz dCBvZiByZWdpc3RlcmVkIHNjb3BlIHZhbHVlcyBpcyBub3QgcG9zc2libGUuDQoNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1p a2UNCg0KRnJvbTogSnVzdGluIFJpY2hlciBbbWFpbHRvOmpyaWNoZXJAbWl0cmUub3JnPG1haWx0 bzpqcmljaGVyQG1pdHJlLm9yZz5dDQpTZW50OiBNb25kYXksIEFwcmlsIDE1LCAyMDEzIDEyOjI5 IFBNDQoNClRvOiBNaWtlIEpvbmVzDQpDYzogVGltIEJyYXk7IG9hdXRoQGlldGYub3JnPG1haWx0 bzpvYXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFJlZ2lzdHJhdGlvbjog U2NvcGUgVmFsdWVzDQoNCkkgdGhpbmsgdGhhdCBiZWNhdXNlIHRoZSAiZGVjbGFyYXRpb24iIGlz c3VlIGFmZmVjdHMgYWxsIHBhcmFtZXRlcnMgaW4gdGhlIGxpc3QsIG5vdCBqdXN0IHNjb3BlLCB3 ZSBzaG91bGQgYWRvcHQgdGhpcyBpbiBhIGhpZ2hlciBsZXZlbCBwYXJhZ3JhcGggYW5kIGxlYXZl IGl0IG91dCBvZiB0aGUgaW5kaXZpZHVhbCBwYXJhbWV0ZXIgZGVzY3JpcHRpb25zLiBUaHVzLCBz b21ldGhpbmcgbGlrZSB0aGlzIGluc2VydGVkIGFzIHRoZSBzZWNvbmQgcGFyYWdyYXBoIGluIHNl Y3Rpb24gMjoNClRoZSBjbGllbnQgbWV0YWRhdGEgdmFsdWVzIHNlcnZlIHR3byBwYXJhbGxlbCBw dXJwb3NlcyBpbiB0aGUgb3ZlcmFsbCBPQXV0aCBEeW5hbWljIFJlZ2lzdHJhdGlvbiBwcm90b2Nv bDoNCg0KIC0gdGhlIENsaWVudCByZXF1ZXN0aW5nIGl0cyBkZXNpcmVkIHZhbHVlcyBmb3IgZWFj aCBwYXJhbWV0ZXIgdG8gdGhlIEF1dGhvcml6YXRpb24gU2VydmVyIGluIGEgW3JlZ2lzdGVyXSBv ciBbdXBkYXRlXSByZXF1ZXN0LA0KIC0gdGhlIEF1dGhvcml6YXRpb24gU2VydmVyIGluZm9ybWlu ZyB0aGUgQ2xpZW50IG9mIHRoZSBjdXJyZW50IHZhbHVlcyBvZiBlYWNoIHBhcmFtZXRlciB0aGF0 IHRoZSBDbGllbnQgaGFzIGJlZW4gcmVnaXN0ZXJlZCB0byB1c2UgdGhyb3VnaCBhIFtjbGllbnQg aW5mb3JtYXRpb24gcmVzcG9uc2VdLg0KDQpBbiBBdXRob3JpemF0aW9uIFNlcnZlciBNQVkgb3Zl cnJpZGUgYW55IHZhbHVlIHRoYXQgYSBDbGllbnQgcmVxdWVzdHMgZHVyaW5nIHRoZSByZWdpc3Ry YXRpb24gcHJvY2VzcyAoaW5jbHVkaW5nIGFueSBvbWl0dGVkIHZhbHVlcykgYW5kIHJlcGxhY2Ug dGhlIHJlcXVlc3RlZCB2YWx1ZSB3aXRoIGEgZGVmYXVsdC4gVGhlIG5vcm1hdGl2ZSBpbmRpY2F0 aW9ucyBpbiB0aGUgZm9sbG93aW5nIGxpc3QgYXBwbHkgdG8gdGhlIENsaWVudCdzIGRlY2xhcmF0 aW9uIG9mIGl0cyBkZXNpcmVkIHZhbHVlcy4NCg0KVGhlIEF1dGhvcml6YXRpb24gU2VydmVyIFNI T1VMRCBwcm92aWRlIGRvY3VtZW50YXRpb24gZm9yIGFueSBmaWVsZHMgdGhhdCBpdCByZXF1aXJl cyB0byBiZSBmaWxsZWQgaW4gYnkgdGhlIGNsaWVudCBvciB0byBoYXZlIHBhcnRpY3VsYXIgdmFs dWVzIG9yIGZvcm1hdHMuIEV4dGVuc2lvbnMgYW5kIHByb2ZpbGVzLi4uDQoNCkFuZCB0aGVuIHJl bW92ZSB0aGUgc2lkZWRuZXNzLWxhbmd1YWdlIGZyb20gdGhlIHNjb3BlIHBhcmFtZXRlciBhbmQg YW55IG90aGVyIHBhcmFtZXRlcnMgd2hlcmUgaXQgbWlnaHQgaGF2ZSBjcmVwdCBpbiBpbmFkdmVy dGVudGx5Lg0KDQogLS0gSnVzdGluDQpPbiAwNC8xNS8yMDEzIDAxOjI5IFBNLCBNaWtlIEpvbmVz IHdyb3RlOg0KV2UgY291bGQgZml4IHRoZSBvbmUtc2lkZWQgbGFuZ3VhZ2UgYnkgY2hhbmdpbmcN CuKAnFNwYWNlIHNlcGFyYXRlZCBsaXN0IG9mIHNjb3BlIHZhbHVlcyAoYXMgZGVzY3JpYmVkIGlu IE9BdXRoIDIuMCBTZWN0aW9uIDMuMyBbUkZDNjc0OV08aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvcmZjNjc0OSNzZWN0aW9uLTMuMz4pIHRoYXQgdGhlIGNsaWVudCBpcyBkZWNsYXJpbmcgdGhh dCBpdCBtYXkgdXNlIHdoZW4gcmVxdWVzdGluZyBhY2Nlc3MgdG9rZW5zLuKAnQ0KdG8NCuKAnFNw YWNlIHNlcGFyYXRlZCBsaXN0IG9mIHNjb3BlIHZhbHVlcyAoYXMgZGVzY3JpYmVkIGluIE9BdXRo IDIuMCBTZWN0aW9uIDMuMyBbUkZDNjc0OV08aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZj Njc0OSNzZWN0aW9uLTMuMz4pIHRoYXQgdGhlIGNsaWVudCBpcyBkZWNsYXJpbmcgdG8gdGhlIHNl cnZlciB0aGF0IGl0IG1heSB1c2Ugd2hlbiByZXF1ZXN0aW5nIGFjY2VzcyB0b2tlbnMgYW5kIHRo YXQgdGhlIHNlcnZlciBpcyBkZWNsYXJpbmcgdG8gdGhlIGNsaWVudCB0aGF0IGl0IGlzIHJlZ2lz dGVyZWQgdG8gdXNlIHdoZW4gcmVxdWVzdGluZyBhY2Nlc3MgdG9rZW5zLuKAnS4NCg0KQWdhaW4s IEkgY2hvc2UgdGhlIOKAnHJlZ2lzdGVyZWQgdG8gdXNl4oCdIGxhbmd1YWdlIGNhcmVmdWxseSDi gJMgYmVjYXVzZSBpbiB0aGUgZ2VuZXJhbCBjYXNlIGl04oCZcyBub3QgYSByZXN0cmljdGlvbiBv biB0aGUgdmFsdWVzIHRoYXQgdGhlIGNsaWVudCBjYW4gdXNlIOKAkyBqdXN0IGEgc3RhdGVtZW50 IGJ5IHRoZSBzZXJ2ZXIgdG8gdGhlIGNsaWVudCB0aGF0IGl0IGlzIHJlZ2lzdGVyZWQgdG8gdXNl IHRob3NlIHBhcnRpY3VsYXIgdmFsdWVzLiAgSW4gYm90aCBjYXNlcywgdGhlIHBhcnRpZXMgYXJl IG1ha2luZyBkZWNsYXJhdGlvbnMgdG8gb25lIGFub3RoZXIuDQoNCklmIHlvdSBhZG9wdCB0aGF0 IGxhbmd1YWdlIChvciBrZWVwIHRoZSBvcmlnaW5hbCBsYW5ndWFnZSksIHRoZW4geWVzLCBJ4oCZ ZCBjb25zaWRlciB0aGlzIGNsb3NlZC4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBKdXN0aW4gUmlj aGVyIFttYWlsdG86anJpY2hlckBtaXRyZS5vcmddDQpTZW50OiBNb25kYXksIEFwcmlsIDE1LCAy MDEzIDk6NTcgQU0NClRvOiBNaWtlIEpvbmVzDQpDYzogVGltIEJyYXk7IG9hdXRoQGlldGYub3Jn PG1haWx0bzpvYXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFJlZ2lzdHJh dGlvbjogU2NvcGUgVmFsdWVzDQoNCkkgYWJzb2x1dGVseSBkbyBub3Qgd2FudCB0byBkZWxldGUg dGhpcyBmZWF0dXJlLCBhcyAoaGF2aW5nIGltcGxlbWVudGVkIGl0KSBJIHRoaW5rIGl0J3MgdmVy eSB1c2VmdWwuIFRoaXMgaXMgYSB2ZXJ5IGVzdGFibGlzaGVkIHBhdHRlcm4gaW4gbWFudWFsIHJl Z2lzdHJhdGlvbjogSSBrbm93IG9mIG1hbnksIG1hbnkgT0F1dGgyIHNlcnZlcnMgYW5kIGNsaWVu dHMgdGhhdCBhcmUgc2V0IHVwIHdoZXJlIHRoZSBjbGllbnQgbXVzdCBwcmUtcmVnaXN0ZXIgYSBz ZXQgb2Ygc2NvcGVzLg0KDQpJIGRvbid0IGxpa2UgdGhlIGxhbmd1YWdlIG9mICJ0aGUgY2xpZW50 IGlzIGRlY2xhcmluZyIgYmVjYXVzZSBpdCdzIHRvbyBvbmUtc2lkZWQuIFRoZSBjbGllbnQgbWln aHQgbm90IGhhdmUgZGVjbGFyZWQgYW55dGhpbmcsIGFuZCBpdCBtaWdodCBiZSB0aGUgc2VydmVy IHRoYXQncyBkZWNsYXJpbmcgc29tZXRoaW5nIHRvIHRoZSBjbGllbnQuIERlbGV0aW5nIHRoZSAi aXMgZGVjbGFyaW5nIiBiaXQgcmVtb3ZlcyB0aGF0IHVuaW50ZW5kZWQgcmVzdHJpY3Rpb24gb2Yg dGhlIGxhbmd1YWdlIHdoaWxlIGtlZXBpbmcgdGhlIG9yaWdpbmFsIG1lYW5pbmcgaW50YWN0LiBJ IGFjdHVhbGx5IHRob3VnaHQgdGhhdCBJIGhhZCBmaXhlZCB0aGF0IGJlZm9yZSB0aGUgbGFzdCBk cmFmdCB3ZW50IGluIGJ1dCBhcHBhcmVudGx5IEkgbWlzc2VkIHRoaXMgb25lLg0KDQpJIHdpbGwg d29yayBvbiBjbGFyaWZ5aW5nIHRoZSBpbnRlbnQgb2YgdGhlIHdob2xlIG1ldGFkYXRhIHNldCBp biBpdHMgaW50cm9kdWN0b3J5IHBhcmFncmFwaChzKSBzbyB0aGF0IGl0J3MgY2xlYXIgdGhhdCBh bGwgb2YgdGhlc2UgZmllbGRzIGFyZSB1c2VkIGluIGJvdGggb2YgdGhlc2Ugc2l0dWF0aW9uczoN Cg0KIDEpIFRoZSBjbGllbnQgZGVjbGFyaW5nIHRvIHRoZSBzZXJ2ZXIgaXRzIGRlc2lyZSB0byB1 c2UgYSBwYXJ0aWN1bGFyIHZhbHVlDQogMikgVGhlIHNlcnZlciBkZWNsYXJpbmcgdG8gdGhlIGNs aWVudCB0aGF0IGl0IGhhcyBiZWVuIHJlZ2lzdGVyZWQgd2l0aCBhIHBhcnRpY3VsYXIgdmFsdWUN Cg0KVGhpcyBzaG91bGQgaG9wZWZ1bGx5IGNsZWFyIHVwIHRoZSBpc3N1ZSBpbiB0aGUgZWRpdG9y J3Mgbm90ZSB0aGF0IEkgY3VycmVudGx5IGhhdmUgYXQgdGhlIHRvcCBvZiB0aGF0IHNlY3Rpb24g cmlnaHQgbm93LCB0b28uDQoNCk1pa2UsIHNpbmNlIHlvdSB3ZXJlIHRoZSBvbmUgd2hvIG9yaWdp bmFsbHkgYnJvdWdodCB1cCB0aGUgaXNzdWUsIGFuZCB5b3UncmUgZmluZSB3aXRoIHRoZSBleGlz dGluZyB0ZXh0LCBjYW4gSSB0YWtlIHRoaXMgYXMgY2xvc2VkIG5vdz8gQXNzdW1pbmcgdGhhdCB5 b3UgYWdyZWUgd2l0aCBkZWxldGluZyAiaXMgZGVjbGFyaW5nIiBmb3IgcmVhc29ucyBzdGF0ZWQg YWJvdmUsIEknbSBmaW5lIHdpdGggbGVhdmluZyBldmVyeXRoaW5nIGVsc2UgYXMgaXMgYW5kIHN0 YXlpbmcgcXVpZXQgb24gd2hhdCB0aGUgc2VydmVyIGhhcyB0byBkbyB3aXRoIHRoZSBzY29wZXMu DQoNCiAtLSBKdXN0aW4NCk9uIDA0LzE1LzIwMTMgMTI6NDQgUE0sIE1pa2UgSm9uZXMgd3JvdGU6 DQpJIHRoaW5rIHRoYXQgdGhlIGV4aXN0aW5nIHdvcmRpbmcgaXMgc3VwZXJpb3IgdG8gdGhlIHBy b3Bvc2VkIGNoYW5nZWQgd29yZGluZy4gIFRoZSBleGlzdGluZyB3b3JkaW5nIGlzOg0KDQogICBz Y29wZQ0KICAgICAgT1BUSU9OQUwuICBTcGFjZSBzZXBhcmF0ZWQgbGlzdCBvZiBzY29wZSB2YWx1 ZXMgKGFzIGRlc2NyaWJlZCBpbg0KICAgICAgT0F1dGggMi4wIFNlY3Rpb24gMy4zIFtSRkM2NzQ5 XTxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2NzQ5I3NlY3Rpb24tMy4zPikgdGhhdCB0 aGUgY2xpZW50IGlzIGRlY2xhcmluZyB0aGF0DQogICAgICBpdCBtYXkgdXNlIHdoZW4gcmVxdWVz dGluZyBhY2Nlc3MgdG9rZW5zLiAgSWYgb21pdHRlZCwgYW4NCiAgICAgIEF1dGhvcml6YXRpb24g U2VydmVyIE1BWSByZWdpc3RlciBhIENsaWVudCB3aXRoIGEgZGVmYXVsdCBzZXQgb2YNCiAgICAg IHNjb3Blcy4NCg0KRm9yIGluc3RhbmNlLCB0aGUgY3VycmVudCDigJxjbGllbnQgaXMgZGVjbGFy aW5n4oCdIHdvcmRpbmcgd2lsbCBhbHdheXMgYmUgY29ycmVjdCwgd2hlcmVhcyBhcyB0aGUgY2hh bmdlIHRvIOKAnGNsaWVudCBjYW4gdXNl4oCdIHdvcmRpbmcgaW1wbGllcyBhIHJlc3RyaWN0aW9u IG9uIGNsaWVudCBiZWhhdmlvciB0aGF0IGlzIG5vdCBhbHdheXMgYXBwbGljYWJsZS4gIFRoZSDi gJxjbGllbnQgaXMgZGVjbGFyaW5n4oCdIHdvcmRpbmcgd2FzIHNwZWNpZmljIGFuZCBwdXJwb3Nl ZnVsbHkgY2hvc2VuLCBhbmQgSSB0aGluayBzaG91bGQgYmUgcmV0YWluZWQuICBJbiBwYXJ0aWN1 bGFyLCB3ZSBjYW7igJl0IGRvIGFueXRoaW5nIHRoYXQgaW1wbGllcyB0aGF0IG9ubHkgdGhlIHJl Z2lzdGVyZWQgc2NvcGVzIHZhbHVlcyBjYW4gYmUgdXNlZC4gIEF0IHRoZSBPQXV0aCBzcGVjIGxl dmVsLCB0aGlzIGlzIGEgaGludCBhcyB0byBwb3NzaWJsZSBmdXR1cmUgY2xpZW50IGJlaGF2aW9y IOKAkyBub3QgYSByZXN0cmljdGlvbiBvbiBmdXR1cmUgY2xpZW50IGJlaGF2aW9yLg0KDQpBbHNv LCBmb3IgdGhlIHJlYXNvbnMgdGhhdCBUaW0gc3RhdGVkLCBJ4oCZbSBzdHJvbmdseSBhZ2FpbnN0 IGFueSDigJxtYXRjaGluZ+KAnSBvciDigJxyZWdleOKAnSBsYW5ndWFnZSBpbiB0aGUgc3BlYyBw ZXJ0YWluaW5nIHRvIHNjb3BlcyDigJMgYXMgaXTigJlzIG5vdCBhY3Rpb25hYmxlLg0KDQpTbyBJ 4oCZZCBwcm9wb3NlIHRoYXQgd2UgbGVhdmUgdGhlIGV4aXN0aW5nIHNjb3BlIHdvcmRpbmcgaW4g cGxhY2UuICBBbHRlcm5hdGl2ZWx5LCBJ4oCZZCBhbHNvIGJlIGZpbmUgd2l0aCBkZWxldGluZyB0 aGlzIGZlYXR1cmUgZW50aXJlbHksIGFzIEkgZG9u4oCZdCB0aGluayBpdOKAmXMgdXNlZnVsIGlu IHRoZSBnZW5lcmFsIGNhc2UuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogb2F1dGgtYm91bmNlc0Bp ZXRmLm9yZzxtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpvYXV0aC1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSnVzdGluIFJpY2hlcg0KU2VudDogTW9uZGF5LCBB cHJpbCAxNSwgMjAxMyA4OjA1IEFNDQpUbzogVGltIEJyYXk7IG9hdXRoQGlldGYub3JnPG1haWx0 bzpvYXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFJlZ2lzdHJhdGlvbjog U2NvcGUgVmFsdWVzDQoNCk9uIDA0LzE1LzIwMTMgMTA6NTIgQU0sIFRpbSBCcmF5IHdyb3RlOg0K DQpJ4oCZZCB1c2UgdGhlIGV4aXN0aW5nIHdvcmRpbmc7IGl04oCZcyBwZXJmZWN0bHkgY2xlYXIu ICBGYWlsaW5nIHRoYXQsIGlmIHRoZXJl4oCZcyBzdHJvbmcgZGVtYW5kIGZvciByZWdpc3RyYXRp b24gb2Ygc3RydWN0dXJlZCBzY29wZXMsIGJsZXNzIHRoZSB1c2Ugb2YgcmVnZXhlcywgZWl0aGVy IFBDUkVzIG9yIHNvbWUgY2FyZWZ1bCBzdWJzZXQuDQoNClRoYW5rcyBmb3IgdGhlIGZlZWRiYWNr IC0tIE9mIHRoZXNlIHR3byBjaG9pY2VzLCBJJ2QgcmF0aGVyIGxlYXZlIGl0IGFzLWlzLg0KDQoN Cg0KSG93ZXZlciwgSeKAmWQgc3VidHJhY3QgdGhlIHNlbnRlbmNlIOKAnElmIG9taXR0ZWQsIGFu IEF1dGhvcml6YXRpb24gU2VydmVyIE1BWSByZWdpc3RlciBhIENsaWVudCB3aXRoIGEgZGVmYXVs dCBzZXQgb2YgIHNjb3Blcy7igJ0gIEl0IGFkZHMgbm8gdmFsdWU7IGlmIHRoZSBjbGllbnQgZG9l c27igJl0IGRlY2xhcmUgc2NvcGVzLCB0aGUgY2xpZW50IGRvZXNu4oCZdCBkZWNsYXJlIHNjb3Bl cywgdGhhdOKAmXMgYWxsLiAgLVQNCg0KUmVtZW1iZXIsIGFsbCBvZiB0aGVzZSBmaWVsZHMgYXJl bid0IGp1c3QgZm9yIHRoZSBjbGllbnQgKnJlcXVlc3QqLCB0aGV5J3JlIGFsc28gZm9yIHRoZSBz ZXJ2ZXIncyAqcmVzcG9uc2UqIHRvIGVpdGhlciBhIFBPU1QsIFBVVCwgb3IgR0VUIHJlcXVlc3Qu IChJIGRpZG4ndCByZWFsaXplIGl0LCBidXQgcGVyaGFwcyB0aGUgd29yZGluZyBhcyBzdGF0ZWQg cmlnaHQgbm93IGRvZXNuJ3QgbWFrZSB0aGF0IGNsZWFyIC0tIEkgbmVlZCB0byBmaXggdGhhdC4p IFRoZSB2YWx1ZSB0aGF0IGl0IGFkZHMgaXMgaWYgdGhlIGNsaWVudCBkb2Vzbid0IGFzayBmb3Ig YW55IHBhcnRpY3VsYXIgc2NvcGVzLCB0aGUgc2VydmVyIGNhbiBzdGlsbCBhc3NpZ24gaXQgc2Nv cGVzIGFuZCB0aGUgY2xpZW50IGNhbiBkbyBzb21ldGhpbmcgc21hcnQgd2l0aCB0aGF0LiBEdW1i IGNsaWVudHMgYXJlIGFsbG93ZWQgdG8gaWdub3JlIGl0IGlmIGl0IGRvZXNuJ3QgbWVhbiBhbnl0 aGluZyB0byB0aGVtLg0KDQpUaGlzIGlzIGhvdyBvdXIgc2VydmVyIGltcGxlbWVudGF0aW9uIGFj dHVhbGx5IHdvcmtzIHJpZ2h0IG5vdy4gSWYgdGhlIGNsaWVudCBkb2Vzbid0IGFzayBmb3IgYW55 dGhpbmcgc3BlY2lmaWMgYXQgcmVnaXN0cmF0aW9uLCB0aGUgc2VydmVyIGhhbmRzIGl0IGEgYmFn IG9mICJkZWZhdWx0IiBzY29wZXMuIFNhbWUgdGhpbmcgaGFwcGVucyBhdCBhdXRoIHRpbWUgLS0g aWYgdGhlIGNsaWVudCBkb2Vzbid0IGFzayBmb3IgYW55IHBhcnRpY3VsYXIgc2NvcGVzLCB0aGUg c2VydmVyIGhhbmRzIGl0IGFsbCBvZiBpdHMgcmVnaXN0ZXJlZCBzY29wZXMgYXMgYSBkZWZhdWx0 LiBHcmFudGVkLCBvbiBvdXIgc2VydmVyLCBzY29wZXMgYXJlIGp1c3Qgc2ltcGxlIHN0cmluZ3Mg cmlnaHQgbm93LCBzbyB0aGV5IGdldCBjb21wYXJlZCBhdCB0aGUgYXV0aCBlbmRwb2ludCB3aXRo IGFuIGV4YWN0IHN0cmluZy1tYXRjaCBtZXRyaWMgYW5kIHNldC1iYXNlZCBsb2dpYy4NCg0KIC0t IEp1c3Rpbg0KDQoNCg0KT24gTW9uLCBBcHIgMTUsIDIwMTMgYXQgNzozNSBBTSwgSnVzdGluIFJp Y2hlciA8anJpY2hlckBtaXRyZS5vcmc8bWFpbHRvOmpyaWNoZXJAbWl0cmUub3JnPj4gd3JvdGU6 DQpXaGF0IHdvdWxkIHlvdSBzdWdnZXN0IGZvciB3b3JkaW5nIGhlcmUsIHRoZW4/IEtlZXBpbmcg aW4gbWluZCB0aGF0IHdlIGNhbm5vdCAoYW5kIGRvbid0IHdhbnQgdG8pIHByb2hpYml0IGV4cHJl c3Npb24tYmFzZWQgc2NvcGVzLg0KDQogLS0gSnVzdGluDQoNCk9uIDA0LzE1LzIwMTMgMTA6MzMg QU0sIFRpbSBCcmF5IHdyb3RlOg0KTm8sIEkgbWVhbiBpdOKAmXMgbm90IGludGVyb3BlcmFibGUg YXQgdGhlIHNvZnR3YXJlLWRldmVsb3BlciBsZXZlbC4gIEkgY2Fu4oCZdCByZWdpc3RlciBzY29w ZXMgYXQgYXV0aG9yaXphdGlvbiB0aW1lIHdpdGggYW55IHByZWRpY3RhYmxlIGVmZmVjdCB0aGF0 IEkgY2FuIHdyaXRlIGNvZGUgdG8gc3VwcG9ydCwgZWl0aGVyIGNsaWVudCBvciBzZXJ2ZXIgc2lk ZSwgd2l0aG91dCBvdXQtb2YtbGluZSBub24taW50ZXJvcGVyYWJsZSBrbm93bGVkZ2UgYWJvdXQg dGhlIGJlaGF2aW9yIG9mIHRoZSBzZXJ2ZXIuDQoNCkkgZ3Vlc3MgSeKAmW0ganVzdCBub3QgdXNl ZCB0byBPQXV0aOKAmXMgY3VsdHVyZSBvZiBoYXZpbmcgbm8gZXhwZWN0YXRpb24gdGhhdCB0aGlu Z3Mgd2lsbCBiZSBzcGVjaWZpZWQgdGlnaHRseSBlbm91Z2ggdGhhdCBJIGNhbiB3cml0ZSBjb2Rl IHRvIGltcGxlbWVudCBhcyBzcGVjaWZpZWQuICAtVA0KDQpPbiBNb24sIEFwciAxNSwgMjAxMyBh dCA3OjE1IEFNLCBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdHJlLm9yZzxtYWlsdG86anJpY2hl ckBtaXRyZS5vcmc+PiB3cm90ZToNClNjb3BlcyBhcmVuJ3QgbWVhbnQgdG8gYmUgaW50ZXJvcGVy YWJsZSBiZXR3ZWVuIHNlcnZpY2VzIHNpbmNlIHRoZXkncmUgbmVjZXNzYXJpbHkgQVBJLXNwZWNp ZmljLiBUaGUgb25seSBpbnRlcm9wZXJhYmxlIGJpdCBpcyB0aGF0IHRoZXJlJ3MgKnNvbWUqIHBs YWNlIHRvIHB1dCB0aGUgdmFsdWVzIGFuZCB0aGF0IGl0J3MgZXhwcmVzc2VkIGFzIGEgYmFnIG9m IHNwYWNlLXNlcGFyYXRlZCBzdHJpbmdzLiBIb3cgdGhvc2Ugc3RyaW5ncyBnZXQgaW50ZXJwcmV0 ZWQgYW5kIGVuZm9yY2VkICh3aGljaCBpcyByZWFsbHkgd2hhdCdzIGF0IHN0YWtlIGhlcmUpIGlz IHVwIHRvIHRoZSBBUyBhbmQgUFIgKG9yIGEgaGlnaGVyLWxldmVsIHByb3RvY29sIGxpa2UgVU1B KS4NCg0KIC0tIEp1c3Rpbg0KDQpPbiAwNC8xNS8yMDEzIDEwOjEzIEFNLCBUaW0gQnJheSB3cm90 ZToNCg0KVGhpcywgYXMgd3JpdHRlbiwgaGFzIHplcm8gaW50ZXJvcGVyYWJpbGl0eS4gIEkgdGhp bmsgdGhpcyBmZWF0dXJlIGNhbiByZWFsbHkgb25seSBiZSBtYWRlIHVzZWZ1bCBpbiB0aGUgY2Fz ZSB3aGVyZSBzY29wZXMgYXJlIGZpeGVkIHN0cmluZ3MuDQoNCi1UDQpPbiBBcHIgMTUsIDIwMTMg Njo1NCBBTSwgIkp1c3RpbiBSaWNoZXIiIDxqcmljaGVyQG1pdHJlLm9yZzxtYWlsdG86anJpY2hl ckBtaXRyZS5vcmc+PiB3cm90ZToNCllvdSBhcmUgY29ycmVjdCB0aGF0IHRoZSBpZGVhIGJlaGlu ZCB0aGUgInNjb3BlIiBwYXJhbWV0ZXIgYXQgcmVnaXN0cmF0aW9uIGlzIGEgY29uc3RyYWludCBv biBhdXRob3JpemF0aW9uLXRpbWUgc2NvcGVzIHRoYXQgYXJlIG1hZGUgYXZhaWxhYmxlLiBJdCdz IGJvdGggYSBtZWFucyBmb3IgdGhlIGNsaWVudCB0byByZXF1ZXN0IGEgc2V0IG9mIHZhbGlkIHNj b3BlcyBhbmQgZm9yIHRoZSBzZXJ2ZXIgdG8gcHJvdmlzaW9uIChhbmQgZWNobyBiYWNrIHRvIHRo ZSBjbGllbnQpIGEgc2V0IG9mIHZhbGlkIHNjb3Blcy4NCg0KSSAqcmVhbGx5KiBkb24ndCB3YW50 IHRvIHRyeSB0byBkZWZpbmUgYSBtYXRjaGluZyBsYW5ndWFnZSBmb3Igc2NvcGUgZXhwcmVzc2lv bnMuIEZvciB0aGF0IHRvIHdvcmssIGFsbCBzZXJ2ZXJzIHdvdWxkIG5lZWQgdG8gYmUgYWJsZSB0 byBwcm9jZXNzIHRoZSByZWd1bGFyIGV4cHJlc3Npb25zIGZvciBhbGwgY2xpZW50cywgZXZlbiBp ZiB0aGUgc2VydmVycyB0aGVtc2VsdmVzIG9ubHkgc3VwcG9ydCBzaW1wbGUtc3RyaW5nIHNjb3Bl IHZhbHVlcy4gQW55IHJlZ3VsYXIgZXhwcmVzc2lvbiBzeW50YXggd2UgcGljayBoZXJlIGlzIGd1 YXJhbnRlZWQgdG8gYmUgaW5jb21wYXRpYmxlIHdpdGggc29tZXRoaW5nLCBhbmQgSSB0aGluayB0 aGUgY29tcGxleGl0eSBkb2Vzbid0IGJ1eSBtdWNoLiBBbHNvLCBJIHRoaW5rIHlvdSBzdWRkZW5s eSBoYXZlIGEgcG90ZW50aWFsIHNlY3VyaXR5IGlzc3VlIGlmIHlvdSBoYXZlIGEgYmFkIHJlZ2V4 IGluIHBsYWNlIG9uIGVpdGhlciBlbmQuDQoNCkFzIGl0IHN0YW5kcyB0b2RheSwgdGhlIHNlcnZl ciBjYW4gaW50ZXJwcmV0IHRoZSBpbmNvbWluZyByZWdpc3RyYXRpb24gc2NvcGVzIGFuZCBlbmZv cmNlIHRoZW0gaG93ZXZlciBpdCB3YW50cyB0by4gVGhlIHJlYWwgdHJpY2sgY29tZXMgbm90IGZy b20gYXNzaWduaW5nIHRoZSB2YWx1ZXMgdG8gYSBwYXJ0aWN1bGFyIGNsaWVudCBidXQgdG8gZW5m b3JjaW5nIHRoZW0sIGFuZCBJIHRoaW5rIHRoYXQncyBhbHdheXMgZ29pbmcgdG8gYmUgc2Vydmlj ZS1zcGVjaWZpYy4gV2UncmUganVzdCBub3QgYXMgY2xlYXIgb24gdGhhdCBhcyB3ZSBjb3VsZCBi ZS4NCg0KQWZ0ZXIgbG9va2luZyBvdmVyIGV2ZXJ5b25lJ3MgY29tbWVudHMgc28gZmFyLCBJJ2Qg bGlrZSB0byBwcm9wb3NlIHRoZSBmb2xsb3dpbmcgdGV4dCBmb3IgdGhhdCBzZWN0aW9uOg0KDQoN CiAgIHNjb3BlDQoNCiAgICAgIE9QVElPTkFMLiAgU3BhY2Ugc2VwYXJhdGVkIGxpc3Qgb2Ygc2Nv cGUgdmFsdWVzIChhcyBkZXNjcmliZWQgaW4NCg0KICAgICAgT0F1dGggMi4wIFNlY3Rpb24gMy4z IFtSRkM2NzQ5XTxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2NzQ5I3NlY3Rpb24tMy4z PikgdGhhdCB0aGUgY2xpZW50IGNhbiB1c2Ugd2hlbg0KDQogICAgICByZXF1ZXN0aW5nIGFjY2Vz cyB0b2tlbnMuICBBcyBzY29wZSB2YWx1ZXMgYXJlIHNlcnZpY2Utc3BlY2lmaWMsDQoNCiAgICAg IHRoZSBBdXRob3JpemF0aW9uIFNlcnZlciBNQVkgZGVmaW5lIGl0cyBvd24gbWF0Y2hpbmcgcnVs ZXMgd2hlbg0KDQogICAgICBkZXRlcm1pbmluZyBpZiBhIHNjb3BlIHZhbHVlIHVzZWQgZHVyaW5n IGFuIGF1dGhvcml6YXRpb24gcmVxdWVzdA0KDQogICAgICBpcyB2YWxpZCBhY2NvcmRpbmcgdG8g dGhlIHNjb3BlIHZhbHVlcyBhc3NpZ25lZCBkdXJpbmcNCg0KICAgICAgcmVnaXN0cmF0aW9uLiBQ b3NzaWJsZSBtYXRjaGluZyBydWxlcyBpbmNsdWRlIHdpbGRjYXJkIHBhdHRlcm5zLA0KDQogICAg ICByZWd1bGFyIGV4cHJlc3Npb25zLCBvciBleGFjdGx5IG1hdGNoaW5nIHRoZSBzdHJpbmcuIElm IG9taXR0ZWQsDQoNCiAgICAgIGFuIEF1dGhvcml6YXRpb24gU2VydmVyIE1BWSByZWdpc3RlciBh IENsaWVudCB3aXRoIGEgZGVmYXVsdA0KDQogICAgICBzZXQgb2Ygc2NvcGVzLg0KDQpDb21tZW50 cz8gSW1wcm92ZW1lbnRzPw0KDQogLS0gSnVzdGluDQoNCk9uIDA0LzE0LzIwMTMgMDg6MjMgUE0s IE1hbmdlciwgSmFtZXMgSCB3cm90ZToNCg0KUHJlc3VtYWJseSBhdCBhcHAgcmVnaXN0cmF0aW9u IHRpbWUgYW55IHNjb3BlIHNwZWNpZmljYXRpb24gaXMgcmVhbGx5IGEgY29uc3RyYWludCBvbiB0 aGUgc2NvcGUgdmFsdWVzIHRoYXQgY2FuIGJlIHJlcXVlc3RlZCBpbiBhbiBhdXRob3JpemF0aW9u IGZsb3cuDQoNCg0KDQpTbyBpZGVhbGx5IHJlZ2lzdHJhdGlvbiBzaG91bGQgYWNjZXB0IHJ1bGVz IGZvciBtYXRjaGluZyBzY29wZXMsIGFzIG9wcG9zZWQgdG8gYWN0dWFsIHNjb3BlIHZhbHVlcy4N Cg0KDQoNCllvdSBjYW4gdHJ5IHRvIHVzZSBzY29wZSB2YWx1ZXMgYXMgdGhlaXIgb3duIG1hdGNo aW5nIHJ1bGVzLiBUaGF0IGlzIGZpbmUgZm9yIGEgc21hbGwgc2V0IG9mICJzdGF0aWMiIHNjb3Bl cy4gSXQgc3RhcnRzIHRvIGZhaWwgd2hlbiB0aGVyZSBhcmUgYSBsYXJnZSBudW1iZXIgb2Ygc2Nv cGVzLCBvciBzY29wZXMgdGhhdCBjYW4gaW5jbHVkZSBwYXJhbWV0ZXJzIChyZXNvdXJjZSBwYXRo cz8gZW1haWwgYWRkcmVzc2VzPykuIFlvdSBjYW4gdHJ5IHRvIHBhdGNoIHRob3NlIGZhaWx1cmVz IGJ5IGFsbG93aW5nIHNlcnZpY2VzIHRvIGRlZmluZSBzZXJ2aWNlLXNwZWNpZmljIHNwZWNpYWwg IndpbGRjYXJkIiBzY29wZSB2YWx1ZXMgdGhhdCBjYW4gb25seSBiZSB1c2VkIGR1cmluZyByZWdp c3RyYXRpb24gKGVnICJyZWFkOioiKS4NCg0KDQoNCkFsdGVybmF0aXZlbHksIHJlcGxhY2UgJ3Nj b3BlJyBpbiByZWdpc3RyYXRpb24gd2l0aCAnc2NvcGVfcmVnZXgnIHRoYXQgaG9sZHMgYSByZWd1 bGFyIGV4cHJlc3Npb24gdGhhdCBhbGwgc2NvcGUgdmFsdWVzIGluIGFuIGF1dGhvcml6YXRpb24g ZmxvdyBtdXN0IG1hdGNoLg0KDQoNCg0KLS0NCg0KSmFtZXMgTWFuZ2VyDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCk9BdXRoIG1haWxpbmcgbGlz dA0KDQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBp ZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL29hdXRoDQoNCg0KDQoNCg0KDQoNCg0KDQo= --_000_d857b70d64e349a2ac0ff52a6aaf5a19BY2PR03MB041namprd03pro_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglw YW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyBcO2NvbG9yXDp3aW5kb3d0ZXh0Ijt9DQovKiBTdHlsZSBEZWZpbml0aW9u cyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46 MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVy bGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1z dHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpD b25zb2xhczt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1y ZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5 N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRp di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5JZiBJIGRvbuKAmXQgc3BlY2lmeSBhIHNjb3BlLCB0aGVuIHRo ZSBzZXJ2ZXIgY2FuIGFsbG9jYXRlIGEgZGVmYXVsdCAob3IgZGVmYXVsdCBzZXQpLCB0aHVzIHRo YXQgYnJlYWtzIHRoZSBzZW1hbnRpY3MgeW91IGRlc2NyaWJlPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9hPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IG9h dXRoLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+ T24gQmVoYWxmIE9mIDwvYj5UaW0gQnJheTxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgQXBy aWwgMTgsIDIwMTMgOTowNCBBTTxicj4NCjxiPlRvOjwvYj4gTWlrZSBKb25lczxicj4NCjxiPkNj OjwvYj4gb2F1dGhAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10g UmVnaXN0cmF0aW9uOiBTY29wZSBWYWx1ZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5J4oCZbSB1bmNvbnZpbmNlZCwgTWlrZS4gJm5ic3A7T2J2aW91c2x5IHlvdeKAmXJl IHJpZ2h0IGFib3V0IHRoZSBsb29zZW5lc3Mgb2YgT0F1dGgyIHNjb3BlIHNwZWNpZmljYXRpb24s IGJ1dCB0aGlzIGlzIGEgdmVyeSBzcGVjaWZpYyBzZW1hbnRpYyBvZiB3aGF0IGhhcHBlbnMgd2hl biB5b3UgcmVnaXN0ZXIsIGFuZCBJIGRvbuKAmXQgdGhpbmsgd2XigJlyZSBib3VuZCBieSBoaXN0 b3J5IGhlcmUuICZuYnNwOyBJZiB3ZSBjYW7igJl0IHNhZmVseQ0KIHNheSBhbnl0aGluZyBhYm91 dCB3aGF0IHRoZSBsaXN0IG9mIHNjb3BlcyBtZWFucywgdGhlbiBJJ20gd2l0aCB5b3UgbGV0J3Mg dGFrZSB0aGVtIG91dC4gJm5ic3A7QnV0IHRoZSBtb3N0IG9idmlvdXMgaW50ZW5kZWQgc2VtYW50 aWMgaXMgKGZyb20gdGhlIGNsaWVudCkg4oCcSSBwcm9taXNlIHRvIGFzayBvbmx5IGZvciB0aGVz ZeKAnSBhbmQgZnJvbSB0aGUgc2VydmVyIOKAnFRoZXNlIGFyZSB0aGUgb25seSBvbmVzIEnigJls bCBnaXZlIHlvdSB0b2tlbnMgZm9yLuKAnQ0KICZuYnNwO09yIGRvZXMgc29tZW9uZSBoYXZlIHVz ZS1jYXNlcyBmb3IgYW4gYWx0ZXJuYXRpdmUgc2VtYW50aWM/PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UbyBtYWtlIHRoaXMgY29uY3JldGUsIEkgcHJvcG9z ZSB0aGUgZm9sbG93aW5nOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPuKAnDwvc3Bhbj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlNwYWNlLXNl cGFyYXRlZCBsaXN0IG9mIHNjb3BlIHZhbHVlcyAoYXMgZGVzY3JpYmVkIGluIE9BdXRoIDIuMCZu YnNwOzxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY3NDkjc2VjdGlvbi0z LjMiIHRhcmdldD0iX2JsYW5rIj5TZWN0aW9uJm5ic3A7My4zDQogW1JGQzY3NDldPC9hPikgdGhh dCB0aGUgY2xpZW50IGlzIGRlY2xhcmluZyB0byB0aGUgc2VydmVyIHRoYXQgaXQgd2lsbCByZXN0 cmljdCBpdHNlbGYgdG8gd2hlbiByZXF1ZXN0aW5nIGFjY2VzcyB0b2tlbnMsIGFuZCB0aGF0IHRo ZSBzZXJ2ZXIgaXMgZGVjbGFyaW5nIHRvIHRoZSBjbGllbnQgdGhhdCBpdCBpcyByZWdpc3RlcmVk IHRvIHVzZSB3aGVuIHJlcXVlc3RpbmcgYWNjZXNzIHRva2Vucy4gJm5ic3A7PC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOmJsYWNrIj5DbGllbnRzDQogU0hPVUxEIGFzc3VtZSB0aGF0IHNlcnZlcnMgd2ls bCByZWZ1c2UgdG8gZ3JhbnQgYWNjZXNzIHRva2VucyBmb3Igc2NvcGVzIG5vdCBpbiB0aGUgbGlz dCBwcm92aWRlZCBieSB0aGUgc2VydmVyLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+4oCdPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzUwMDA1MCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBB cHIgMTgsIDIwMTMgYXQgODo1NSBBTSwgTWlrZSBKb25lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1p Y2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPk1pY2hhZWwuSm9uZXNA bWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBkb27igJl0IHRoaW5rIGl04oCZcyBwb3NzaWJsZSB0 byBkZWZpbmUgd2hhdCBpdCBtZWFucyBpbiBhbiBpbnRlcm9wZXJhYmxlIHdheSBiZWNhdXNlIE9B dXRoIGRpZG7igJl0DQogc3BlY2lmeSBzY29wZXMgaW4gYW4gaW50ZXJvcGVyYWJsZSB3YXkuJm5i c3A7IE5vLCBJIGRvbuKAmXQgbGlrZSB0aGF0IGVpdGhlciwgYnV0IEkgdGhpbmsgdGhhdOKAmXMg d2hlcmUgdGhpbmdzIGFyZS4mbmJzcDsgVGhhdOKAmXMgd2h5IEkgd2FzIGFkdm9jYXRpbmcgZGVs ZXRpbmcgdGhpcyByZWdpc3RyYXRpb24gZmVhdHVyZSBlbnRpcmVseS48L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5C dXQgdW5kZXJzdGFuZGluZyBpdCBtaWdodCBiZSB1c2VmdWwgaW4gc29tZSBjb250ZXh0cywgSeKA mW0gT0sga2VlcGluZyBpdCwgcHJvdmlkZWQgd2UgYmUgY2xlYXIgdGhhdA0KIHRoZSBzZW1hbnRp Y3Mgb2Yg4oCccmVnaXN0ZXJlZCB0byB1c2XigJ0gYXJlIHNlcnZpY2Utc3BlY2lmaWMuPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPiBUaW0gQnJheSBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzp0d2Jy YXlAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnR3YnJheUBnb29nbGUuY29tPC9hPl0NCjxi cj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgQXByaWwgMTgsIDIwMTMgODozNiBBTTxicj4NCjxi PlRvOjwvYj4gTWlrZSBKb25lczxicj4NCjxiPkNjOjwvYj4gSnVzdGluIFJpY2hlcjsgPGEgaHJl Zj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGhAaWV0Zi5vcmc8 L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gUmVnaXN0cmF0aW9uOiBT Y29wZSBWYWx1ZXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5PbiB0aGUgc2VydmVyLXRvLWNsaWVudCBzaWRlLCB3aGF0IGRv ZXMg4oCccmVnaXN0ZXJlZCB0byB1c2XigJ0gbWVhbj8gJm5ic3A7RG9lcyBpdCBtZWFuIHRoYXQg dGhlIGNsaWVudCBzaG91bGQgYXNzdW1lIHRoYXQgYW55IHNjb3BlcyBub3Qgb24gdGhlIGxpc3Qg V0lMTCBub3QgYmUgZ3JhbnRlZCwgTUFZIG5vdCBiZSBncmFudGVkLi4uLg0KIG9yIHdoYXQ/ICZu YnNwO0lzIHRoaXMgYWxyZWFkeSBjb3ZlcmVkIGVsc2V3aGVyZT8gLVQ8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBUaHUsIEFwciAxOCwgMjAxMyBhdCA4OjI4 IEFNLCBNaWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3Nv ZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcywg SnVzdGluLiZuYnNwOyBJIGFncmVlIHdpdGggdGhlIG5lZWQgZm9yIHRoZSBnZW5lcmljIHR3by1z aWRlZCBsYW5ndWFnZS4mbmJzcDsgSeKAmWQgc3RpbGwga2VlcCB0aGlzIGxhbmd1YWdlDQogZm9y IHNjb3BlLCBiZWNhdXNlIHdlIHdhbnQgdG8gY2FwdHVyZSB0aGUg4oCcZGVjbGFyaW5n4oCdIGFz cGVjdCBpbiB0aGlzIGNhc2U6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJn aW4tbGVmdDouNWluIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij7igJw8L3NwYW4+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+U3BhY2Ugc2VwYXJhdGVkIGxpc3Qgb2Ygc2NvcGUgdmFsdWVzIChhcyBk ZXNjcmliZWQgaW4gT0F1dGggMi4wDQo8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9yZmM2NzQ5I3NlY3Rpb24tMy4zIiB0YXJnZXQ9Il9ibGFuayI+U2VjdGlvbiZuYnNwOzMuMyBb UkZDNjc0OV08L2E+KSB0aGF0IHRoZSBjbGllbnQgaXMgZGVjbGFyaW5nIHRvIHRoZSBzZXJ2ZXIg dGhhdCBpdCBtYXkgdXNlIHdoZW4gcmVxdWVzdGluZyBhY2Nlc3MgdG9rZW5zIGFuZCB0aGF0IHRo ZSBzZXJ2ZXIgaXMgZGVjbGFyaW5nIHRvIHRoZSBjbGllbnQgdGhhdCBpdCBpcyByZWdpc3RlcmVk DQogdG8gdXNlIHdoZW4gcmVxdWVzdGluZyBhY2Nlc3MgdG9rZW5zLjwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+4oCdLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+WW91IHNob3VsZCBwcm9iYWJseSBhbHNvIHJlaW5mb3JjZSB0aGF0IHNjb3BlIHZhbHVlcyBh cmUgc2VydmljZS1zcGVjaWZpYyBhbmQgbWF5IG5vdCBjb25zaXN0IG9ubHkNCiBvZiBhIHN0YXRp YyBzZXQgb2Ygc3RyaW5nIHZhbHVlcywgYW5kIHRoYXQgdGhlcmVmb3JlLCBpbiBzb21lIGNhc2Vz LCBhbiBleGhhdXN0aXZlIGxpc3Qgb2YgcmVnaXN0ZXJlZCBzY29wZSB2YWx1ZXMgaXMgbm90IHBv c3NpYmxlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+IEp1c3RpbiBSaWNoZXIgW21haWx0bzo8YSBocmVmPSJtYWlsdG86anJpY2hlckBt aXRyZS5vcmciIHRhcmdldD0iX2JsYW5rIj5qcmljaGVyQG1pdHJlLm9yZzwvYT5dDQo8YnI+DQo8 Yj5TZW50OjwvYj4gTW9uZGF5LCBBcHJpbCAxNSwgMjAxMyAxMjoyOSBQTTwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YnI+DQo8Yj5U bzo8L2I+IE1pa2UgSm9uZXM8YnI+DQo8Yj5DYzo8L2I+IFRpbSBCcmF5OyA8YSBocmVmPSJtYWls dG86b2F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aEBpZXRmLm9yZzwvYT48YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gUmVnaXN0cmF0aW9uOiBTY29wZSBWYWx1 ZXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1i b3R0b206MTIuMHB0Ij5JIHRoaW5rIHRoYXQgYmVjYXVzZSB0aGUgJnF1b3Q7ZGVjbGFyYXRpb24m cXVvdDsgaXNzdWUgYWZmZWN0cyBhbGwgcGFyYW1ldGVycyBpbiB0aGUgbGlzdCwgbm90IGp1c3Qg c2NvcGUsIHdlIHNob3VsZCBhZG9wdCB0aGlzIGluIGEgaGlnaGVyIGxldmVsIHBhcmFncmFwaCBh bmQgbGVhdmUgaXQgb3V0IG9mIHRoZSBpbmRpdmlkdWFsIHBhcmFtZXRlcg0KIGRlc2NyaXB0aW9u cy4gVGh1cywgc29tZXRoaW5nIGxpa2UgdGhpcyBpbnNlcnRlZCBhcyB0aGUgc2Vjb25kIHBhcmFn cmFwaCBpbiBzZWN0aW9uIDI6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PlRoZSBjbGllbnQgbWV0YWRhdGEgdmFsdWVzIHNlcnZlIHR3byBwYXJhbGxlbCBwdXJwb3NlcyBp biB0aGUgb3ZlcmFsbCBPQXV0aCBEeW5hbWljIFJlZ2lzdHJhdGlvbiBwcm90b2NvbDoNCjxicj4N Cjxicj4NCiZuYnNwOy0gdGhlIENsaWVudCByZXF1ZXN0aW5nIGl0cyBkZXNpcmVkIHZhbHVlcyBm b3IgZWFjaCBwYXJhbWV0ZXIgdG8gdGhlIEF1dGhvcml6YXRpb24gU2VydmVyIGluIGEgW3JlZ2lz dGVyXSBvciBbdXBkYXRlXSByZXF1ZXN0LDxicj4NCiZuYnNwOy0gdGhlIEF1dGhvcml6YXRpb24g U2VydmVyIGluZm9ybWluZyB0aGUgQ2xpZW50IG9mIHRoZSBjdXJyZW50IHZhbHVlcyBvZiBlYWNo IHBhcmFtZXRlciB0aGF0IHRoZSBDbGllbnQgaGFzIGJlZW4gcmVnaXN0ZXJlZCB0byB1c2UgdGhy b3VnaCBhIFtjbGllbnQgaW5mb3JtYXRpb24gcmVzcG9uc2VdLg0KPGJyPg0KPGJyPg0KQW4gQXV0 aG9yaXphdGlvbiBTZXJ2ZXIgTUFZIG92ZXJyaWRlIGFueSB2YWx1ZSB0aGF0IGEgQ2xpZW50IHJl cXVlc3RzIGR1cmluZyB0aGUgcmVnaXN0cmF0aW9uIHByb2Nlc3MgKGluY2x1ZGluZyBhbnkgb21p dHRlZCB2YWx1ZXMpIGFuZCByZXBsYWNlIHRoZSByZXF1ZXN0ZWQgdmFsdWUgd2l0aCBhIGRlZmF1 bHQuIFRoZSBub3JtYXRpdmUgaW5kaWNhdGlvbnMgaW4gdGhlIGZvbGxvd2luZyBsaXN0IGFwcGx5 IHRvIHRoZSBDbGllbnQncyBkZWNsYXJhdGlvbg0KIG9mIGl0cyBkZXNpcmVkIHZhbHVlcy4gPGJy Pg0KPGJyPg0KVGhlIEF1dGhvcml6YXRpb24gU2VydmVyIFNIT1VMRCBwcm92aWRlIGRvY3VtZW50 YXRpb24gZm9yIGFueSBmaWVsZHMgdGhhdCBpdCByZXF1aXJlcyB0byBiZSBmaWxsZWQgaW4gYnkg dGhlIGNsaWVudCBvciB0byBoYXZlIHBhcnRpY3VsYXIgdmFsdWVzIG9yIGZvcm1hdHMuIEV4dGVu c2lvbnMgYW5kIHByb2ZpbGVzLi4uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxi cj4NCkFuZCB0aGVuIHJlbW92ZSB0aGUgc2lkZWRuZXNzLWxhbmd1YWdlIGZyb20gdGhlIHNjb3Bl IHBhcmFtZXRlciBhbmQgYW55IG90aGVyIHBhcmFtZXRlcnMgd2hlcmUgaXQgbWlnaHQgaGF2ZSBj cmVwdCBpbiBpbmFkdmVydGVudGx5Lg0KPGJyPg0KPGJyPg0KJm5ic3A7LS0gSnVzdGluPG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiAwNC8xNS8yMDEzIDAx OjI5IFBNLCBNaWtlIEpvbmVzIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPldlIGNvdWxkIGZpeCB0aGUgb25lLXNpZGVkIGxhbmd1YWdlIGJ5IGNoYW5naW5nPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4i Pg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPuKAnDwvc3Bhbj48 c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij5TcGFjZSBzZXBhcmF0ZWQgbGlzdCBvZiBzY29wZSB2YWx1ZXMgKGFzIGRlc2NyaWJlZCBpbiBP QXV0aCAyLjANCjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY3NDkjc2Vj dGlvbi0zLjMiIHRhcmdldD0iX2JsYW5rIj5TZWN0aW9uJm5ic3A7My4zIFtSRkM2NzQ5XTwvYT4p IHRoYXQgdGhlIGNsaWVudCBpcyBkZWNsYXJpbmcgdGhhdCBpdCBtYXkgdXNlIHdoZW4gcmVxdWVz dGluZyBhY2Nlc3MgdG9rZW5zLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+4oCdPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+dG88L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+ DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+4oCcPC9zcGFuPjxz cGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PlNwYWNlIHNlcGFyYXRlZCBsaXN0IG9mIHNjb3BlIHZhbHVlcyAoYXMgZGVzY3JpYmVkIGluIE9B dXRoIDIuMA0KPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjc0OSNzZWN0 aW9uLTMuMyIgdGFyZ2V0PSJfYmxhbmsiPlNlY3Rpb24mbmJzcDszLjMgW1JGQzY3NDldPC9hPikg dGhhdCB0aGUgY2xpZW50IGlzIGRlY2xhcmluZyB0byB0aGUgc2VydmVyIHRoYXQgaXQgbWF5IHVz ZSB3aGVuIHJlcXVlc3RpbmcgYWNjZXNzIHRva2VucyBhbmQgdGhhdCB0aGUgc2VydmVyIGlzIGRl Y2xhcmluZyB0byB0aGUgY2xpZW50IHRoYXQgaXQgaXMgcmVnaXN0ZXJlZA0KIHRvIHVzZSB3aGVu IHJlcXVlc3RpbmcgYWNjZXNzIHRva2Vucy48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPuKAnS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BZ2FpbiwgSSBjaG9zZSB0aGUg 4oCccmVnaXN0ZXJlZCB0byB1c2XigJ0gbGFuZ3VhZ2UgY2FyZWZ1bGx5IOKAkyBiZWNhdXNlIGlu IHRoZSBnZW5lcmFsIGNhc2UgaXTigJlzIG5vdA0KIGEgcmVzdHJpY3Rpb24gb24gdGhlIHZhbHVl cyB0aGF0IHRoZSBjbGllbnQgY2FuIHVzZSDigJMganVzdCBhIHN0YXRlbWVudCBieSB0aGUgc2Vy dmVyIHRvIHRoZSBjbGllbnQgdGhhdCBpdCBpcyByZWdpc3RlcmVkIHRvIHVzZSB0aG9zZSBwYXJ0 aWN1bGFyIHZhbHVlcy4mbmJzcDsgSW4gYm90aCBjYXNlcywgdGhlIHBhcnRpZXMgYXJlIG1ha2lu ZyBkZWNsYXJhdGlvbnMgdG8gb25lIGFub3RoZXIuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SWYgeW91IGFkb3B0 IHRoYXQgbGFuZ3VhZ2UgKG9yIGtlZXAgdGhlIG9yaWdpbmFsIGxhbmd1YWdlKSwgdGhlbiB5ZXMs IEnigJlkIGNvbnNpZGVyIHRoaXMgY2xvc2VkLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAt LSBNaWtlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEp1c3RpbiBSaWNoZXIgWzxhIGhyZWY9Im1h aWx0bzpqcmljaGVyQG1pdHJlLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpqcmljaGVyQG1p dHJlLm9yZzwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBBcHJpbCAxNSwgMjAxMyA5 OjU3IEFNPGJyPg0KPGI+VG86PC9iPiBNaWtlIEpvbmVzPGJyPg0KPGI+Q2M6PC9iPiBUaW0gQnJh eTsgPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGhA aWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIFJlZ2lzdHJh dGlvbjogU2NvcGUgVmFsdWVzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbTox Mi4wcHQiPkkgYWJzb2x1dGVseSBkbyBub3Qgd2FudCB0byBkZWxldGUgdGhpcyBmZWF0dXJlLCBh cyAoaGF2aW5nIGltcGxlbWVudGVkIGl0KSBJIHRoaW5rIGl0J3MgdmVyeSB1c2VmdWwuIFRoaXMg aXMgYSB2ZXJ5IGVzdGFibGlzaGVkIHBhdHRlcm4gaW4gbWFudWFsIHJlZ2lzdHJhdGlvbjogSSBr bm93IG9mIG1hbnksIG1hbnkgT0F1dGgyDQogc2VydmVycyBhbmQgY2xpZW50cyB0aGF0IGFyZSBz ZXQgdXAgd2hlcmUgdGhlIGNsaWVudCBtdXN0IHByZS1yZWdpc3RlciBhIHNldCBvZiBzY29wZXMu DQo8YnI+DQo8YnI+DQpJIGRvbid0IGxpa2UgdGhlIGxhbmd1YWdlIG9mICZxdW90O3RoZSBjbGll bnQgaXMgZGVjbGFyaW5nJnF1b3Q7IGJlY2F1c2UgaXQncyB0b28gb25lLXNpZGVkLiBUaGUgY2xp ZW50IG1pZ2h0IG5vdCBoYXZlIGRlY2xhcmVkIGFueXRoaW5nLCBhbmQgaXQgbWlnaHQgYmUgdGhl IHNlcnZlciB0aGF0J3MgZGVjbGFyaW5nIHNvbWV0aGluZyB0byB0aGUgY2xpZW50LiBEZWxldGlu ZyB0aGUgJnF1b3Q7aXMgZGVjbGFyaW5nJnF1b3Q7IGJpdCByZW1vdmVzIHRoYXQgdW5pbnRlbmRl ZCByZXN0cmljdGlvbg0KIG9mIHRoZSBsYW5ndWFnZSB3aGlsZSBrZWVwaW5nIHRoZSBvcmlnaW5h bCBtZWFuaW5nIGludGFjdC4gSSBhY3R1YWxseSB0aG91Z2h0IHRoYXQgSSBoYWQgZml4ZWQgdGhh dCBiZWZvcmUgdGhlIGxhc3QgZHJhZnQgd2VudCBpbiBidXQgYXBwYXJlbnRseSBJIG1pc3NlZCB0 aGlzIG9uZS48YnI+DQo8YnI+DQpJIHdpbGwgd29yayBvbiBjbGFyaWZ5aW5nIHRoZSBpbnRlbnQg b2YgdGhlIHdob2xlIG1ldGFkYXRhIHNldCBpbiBpdHMgaW50cm9kdWN0b3J5IHBhcmFncmFwaChz KSBzbyB0aGF0IGl0J3MgY2xlYXIgdGhhdCBhbGwgb2YgdGhlc2UgZmllbGRzIGFyZSB1c2VkIGlu IGJvdGggb2YgdGhlc2Ugc2l0dWF0aW9uczo8YnI+DQo8YnI+DQombmJzcDsxKSBUaGUgY2xpZW50 IGRlY2xhcmluZyB0byB0aGUgc2VydmVyIGl0cyBkZXNpcmUgdG8gdXNlIGEgcGFydGljdWxhciB2 YWx1ZTxicj4NCiZuYnNwOzIpIFRoZSBzZXJ2ZXIgZGVjbGFyaW5nIHRvIHRoZSBjbGllbnQgdGhh dCBpdCBoYXMgYmVlbiByZWdpc3RlcmVkIHdpdGggYSBwYXJ0aWN1bGFyIHZhbHVlPGJyPg0KPGJy Pg0KVGhpcyBzaG91bGQgaG9wZWZ1bGx5IGNsZWFyIHVwIHRoZSBpc3N1ZSBpbiB0aGUgZWRpdG9y J3Mgbm90ZSB0aGF0IEkgY3VycmVudGx5IGhhdmUgYXQgdGhlIHRvcCBvZiB0aGF0IHNlY3Rpb24g cmlnaHQgbm93LCB0b28uPGJyPg0KPGJyPg0KTWlrZSwgc2luY2UgeW91IHdlcmUgdGhlIG9uZSB3 aG8gb3JpZ2luYWxseSBicm91Z2h0IHVwIHRoZSBpc3N1ZSwgYW5kIHlvdSdyZSBmaW5lIHdpdGgg dGhlIGV4aXN0aW5nIHRleHQsIGNhbiBJIHRha2UgdGhpcyBhcyBjbG9zZWQgbm93PyBBc3N1bWlu ZyB0aGF0IHlvdSBhZ3JlZSB3aXRoIGRlbGV0aW5nICZxdW90O2lzIGRlY2xhcmluZyZxdW90OyBm b3IgcmVhc29ucyBzdGF0ZWQgYWJvdmUsIEknbSBmaW5lIHdpdGggbGVhdmluZyBldmVyeXRoaW5n IGVsc2UgYXMNCiBpcyBhbmQgc3RheWluZyBxdWlldCBvbiB3aGF0IHRoZSBzZXJ2ZXIgaGFzIHRv IGRvIHdpdGggdGhlIHNjb3Blcy48YnI+DQo8YnI+DQombmJzcDstLSBKdXN0aW48bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIDA0LzE1LzIwMTMgMTI6NDQg UE0sIE1pa2UgSm9uZXMgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ SSB0aGluayB0aGF0IHRoZSBleGlzdGluZyB3b3JkaW5nIGlzIHN1cGVyaW9yIHRvIHRoZSBwcm9w b3NlZCBjaGFuZ2VkIHdvcmRpbmcuJm5ic3A7IFRoZSBleGlzdGluZyB3b3JkaW5nDQogaXM6PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3IFw7Y29sb3JcOndpbmRvd3RleHQmcXVvdDsiPiZuYnNwOyZu YnNwOyBzY29wZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyBcO2Nv bG9yXDp3aW5kb3d0ZXh0JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgT1BU SU9OQUwuJm5ic3A7IFNwYWNlIHNlcGFyYXRlZCBsaXN0IG9mIHNjb3BlIHZhbHVlcyAoYXMgZGVz Y3JpYmVkIGluPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3IFw7Y29s b3JcOndpbmRvd3RleHQmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBPQXV0 aCAyLjANCjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY3NDkjc2VjdGlv bi0zLjMiIHRhcmdldD0iX2JsYW5rIj5TZWN0aW9uJm5ic3A7My4zIFtSRkM2NzQ5XTwvYT4pIHRo YXQgdGhlIGNsaWVudCBpcyBkZWNsYXJpbmcgdGhhdDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyBcO2NvbG9yXDp3aW5kb3d0ZXh0JnF1b3Q7Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgaXQgbWF5IHVzZSB3aGVuIHJlcXVlc3RpbmcgYWNjZXNzIHRva2Vu cy4mbmJzcDsgSWYgb21pdHRlZCwgYW48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcgXDtjb2xvclw6d2luZG93dGV4dCZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IEF1dGhvcml6YXRpb24gU2VydmVyIE1BWSByZWdpc3RlciBhIENsaWVudCB3aXRo IGEgZGVmYXVsdCBzZXQgb2Y8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcgXDtjb2xvclw6d2luZG93dGV4dCZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHNjb3Blcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Gb3IgaW5zdGFuY2UsIHRoZSBjdXJyZW50IOKAnGNs aWVudCBpcyBkZWNsYXJpbmfigJ0gd29yZGluZyB3aWxsIGFsd2F5cyBiZSBjb3JyZWN0LCB3aGVy ZWFzIGFzIHRoZSBjaGFuZ2UNCiB0byDigJxjbGllbnQgY2FuIHVzZeKAnSB3b3JkaW5nIGltcGxp ZXMgYSByZXN0cmljdGlvbiBvbiBjbGllbnQgYmVoYXZpb3IgdGhhdCBpcyBub3QgYWx3YXlzIGFw cGxpY2FibGUuJm5ic3A7IFRoZSDigJxjbGllbnQgaXMgZGVjbGFyaW5n4oCdIHdvcmRpbmcgd2Fz IHNwZWNpZmljIGFuZCBwdXJwb3NlZnVsbHkgY2hvc2VuLCBhbmQgSSB0aGluayBzaG91bGQgYmUg cmV0YWluZWQuJm5ic3A7IEluIHBhcnRpY3VsYXIsIHdlIGNhbuKAmXQgZG8gYW55dGhpbmcgdGhh dCBpbXBsaWVzIHRoYXQNCiBvbmx5IHRoZSByZWdpc3RlcmVkIHNjb3BlcyB2YWx1ZXMgY2FuIGJl IHVzZWQuJm5ic3A7IEF0IHRoZSBPQXV0aCBzcGVjIGxldmVsLCB0aGlzIGlzIGEgaGludCBhcyB0 byBwb3NzaWJsZSBmdXR1cmUgY2xpZW50IGJlaGF2aW9yIOKAkyBub3QgYSByZXN0cmljdGlvbiBv biBmdXR1cmUgY2xpZW50IGJlaGF2aW9yLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFsc28sIGZvciB0aGUgcmVh c29ucyB0aGF0IFRpbSBzdGF0ZWQsIEnigJltIHN0cm9uZ2x5IGFnYWluc3QgYW55IOKAnG1hdGNo aW5n4oCdIG9yIOKAnHJlZ2V44oCdIGxhbmd1YWdlIGluDQogdGhlIHNwZWMgcGVydGFpbmluZyB0 byBzY29wZXMg4oCTIGFzIGl04oCZcyBub3QgYWN0aW9uYWJsZS48L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TbyBJ 4oCZZCBwcm9wb3NlIHRoYXQgd2UgbGVhdmUgdGhlIGV4aXN0aW5nIHNjb3BlIHdvcmRpbmcgaW4g cGxhY2UuJm5ic3A7IEFsdGVybmF0aXZlbHksIEnigJlkIGFsc28gYmUgZmluZQ0KIHdpdGggZGVs ZXRpbmcgdGhpcyBmZWF0dXJlIGVudGlyZWx5LCBhcyBJIGRvbuKAmXQgdGhpbmsgaXTigJlzIHVz ZWZ1bCBpbiB0aGUgZ2VuZXJhbCBjYXNlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBN aWtlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+DQo8YSBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNl c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IFs8 YSBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1h aWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+SnVz dGluIFJpY2hlcjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEFwcmlsIDE1LCAyMDEzIDg6MDUg QU08YnI+DQo8Yj5Ubzo8L2I+IFRpbSBCcmF5OyA8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUmU6IFtPQVVUSC1XR10gUmVnaXN0cmF0aW9uOiBTY29wZSBWYWx1ZXM8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+T24gMDQvMTUvMjAxMyAxMDo1MiBBTSwg VGltIEJyYXkgd3JvdGU6PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5J4oCZZCB1c2UgdGhlIGV4aXN0aW5nIHdvcmRpbmc7IGl04oCZcyBw ZXJmZWN0bHkgY2xlYXIuICZuYnNwO0ZhaWxpbmcgdGhhdCwgaWYgdGhlcmXigJlzIHN0cm9uZyBk ZW1hbmQgZm9yIHJlZ2lzdHJhdGlvbiBvZiBzdHJ1Y3R1cmVkIHNjb3BlcywgYmxlc3MgdGhlIHVz ZSBvZiByZWdleGVzLCBlaXRoZXIgUENSRXMgb3Igc29tZQ0KIGNhcmVmdWwgc3Vic2V0LjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NClRoYW5rcyBmb3IgdGhl IGZlZWRiYWNrIC0tIE9mIHRoZXNlIHR3byBjaG9pY2VzLCBJJ2QgcmF0aGVyIGxlYXZlIGl0IGFz LWlzLiA8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SG93ZXZlciwgSeKAmWQgc3VidHJhY3QgdGhlIHNlbnRl bmNlIOKAnElmIG9taXR0ZWQsIGFuIEF1dGhvcml6YXRpb24gU2VydmVyIE1BWSByZWdpc3RlciBh IENsaWVudCB3aXRoIGEgZGVmYXVsdCBzZXQgb2YgJm5ic3A7c2NvcGVzLuKAnSAmbmJzcDtJdCBh ZGRzIG5vIHZhbHVlOyBpZiB0aGUgY2xpZW50IGRvZXNu4oCZdCBkZWNsYXJlIHNjb3BlcywNCiB0 aGUgY2xpZW50IGRvZXNu4oCZdCBkZWNsYXJlIHNjb3BlcywgdGhhdOKAmXMgYWxsLiAmbmJzcDst VDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0K UmVtZW1iZXIsIGFsbCBvZiB0aGVzZSBmaWVsZHMgYXJlbid0IGp1c3QgZm9yIHRoZSBjbGllbnQg KnJlcXVlc3QqLCB0aGV5J3JlIGFsc28gZm9yIHRoZSBzZXJ2ZXIncyAqcmVzcG9uc2UqIHRvIGVp dGhlciBhIFBPU1QsIFBVVCwgb3IgR0VUIHJlcXVlc3QuIChJIGRpZG4ndCByZWFsaXplIGl0LCBi dXQgcGVyaGFwcyB0aGUgd29yZGluZyBhcyBzdGF0ZWQgcmlnaHQgbm93IGRvZXNuJ3QgbWFrZSB0 aGF0IGNsZWFyIC0tIEkgbmVlZCB0byBmaXggdGhhdC4pDQogVGhlIHZhbHVlIHRoYXQgaXQgYWRk cyBpcyBpZiB0aGUgY2xpZW50IGRvZXNuJ3QgYXNrIGZvciBhbnkgcGFydGljdWxhciBzY29wZXMs IHRoZSBzZXJ2ZXIgY2FuIHN0aWxsIGFzc2lnbiBpdCBzY29wZXMgYW5kIHRoZSBjbGllbnQgY2Fu IGRvIHNvbWV0aGluZyBzbWFydCB3aXRoIHRoYXQuIER1bWIgY2xpZW50cyBhcmUgYWxsb3dlZCB0 byBpZ25vcmUgaXQgaWYgaXQgZG9lc24ndCBtZWFuIGFueXRoaW5nIHRvIHRoZW0uDQo8YnI+DQo8 YnI+DQpUaGlzIGlzIGhvdyBvdXIgc2VydmVyIGltcGxlbWVudGF0aW9uIGFjdHVhbGx5IHdvcmtz IHJpZ2h0IG5vdy4gSWYgdGhlIGNsaWVudCBkb2Vzbid0IGFzayBmb3IgYW55dGhpbmcgc3BlY2lm aWMgYXQgcmVnaXN0cmF0aW9uLCB0aGUgc2VydmVyIGhhbmRzIGl0IGEgYmFnIG9mICZxdW90O2Rl ZmF1bHQmcXVvdDsgc2NvcGVzLiBTYW1lIHRoaW5nIGhhcHBlbnMgYXQgYXV0aCB0aW1lIC0tIGlm IHRoZSBjbGllbnQgZG9lc24ndCBhc2sgZm9yIGFueSBwYXJ0aWN1bGFyIHNjb3BlcywNCiB0aGUg c2VydmVyIGhhbmRzIGl0IGFsbCBvZiBpdHMgcmVnaXN0ZXJlZCBzY29wZXMgYXMgYSBkZWZhdWx0 LiBHcmFudGVkLCBvbiBvdXIgc2VydmVyLCBzY29wZXMgYXJlIGp1c3Qgc2ltcGxlIHN0cmluZ3Mg cmlnaHQgbm93LCBzbyB0aGV5IGdldCBjb21wYXJlZCBhdCB0aGUgYXV0aCBlbmRwb2ludCB3aXRo IGFuIGV4YWN0IHN0cmluZy1tYXRjaCBtZXRyaWMgYW5kIHNldC1iYXNlZCBsb2dpYy4NCjxicj4N Cjxicj4NCiZuYnNwOy0tIEp1c3Rpbjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5PbiBNb24sIEFwciAxNSwgMjAxMyBhdCA3OjM1IEFNLCBKdXN0 aW4gUmljaGVyICZsdDs8YSBocmVmPSJtYWlsdG86anJpY2hlckBtaXRyZS5vcmciIHRhcmdldD0i X2JsYW5rIj5qcmljaGVyQG1pdHJlLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+V2hhdCB3b3VsZCB5b3Ugc3VnZ2VzdCBmb3Ig d29yZGluZyBoZXJlLCB0aGVuPyBLZWVwaW5nIGluIG1pbmQgdGhhdCB3ZSBjYW5ub3QgKGFuZCBk b24ndCB3YW50IHRvKSBwcm9oaWJpdCBleHByZXNzaW9uLWJhc2VkIHNjb3Blcy4NCjxicj4NCjxz cGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij48YnI+DQombmJzcDstLSBKdXN0aW48L3NwYW4+IDxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gMDQvMTUvMjAxMyAx MDozMyBBTSwgVGltIEJyYXkgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Tm8sIEkgbWVhbiBpdOKAmXMgbm90IGludGVyb3BlcmFi bGUgYXQgdGhlIHNvZnR3YXJlLWRldmVsb3BlciBsZXZlbC4gJm5ic3A7SSBjYW7igJl0IHJlZ2lz dGVyIHNjb3BlcyBhdCBhdXRob3JpemF0aW9uIHRpbWUgd2l0aCBhbnkgcHJlZGljdGFibGUgZWZm ZWN0IHRoYXQgSSBjYW4gd3JpdGUgY29kZSB0byBzdXBwb3J0LCBlaXRoZXINCiBjbGllbnQgb3Ig c2VydmVyIHNpZGUsIHdpdGhvdXQgb3V0LW9mLWxpbmUgbm9uLWludGVyb3BlcmFibGUga25vd2xl ZGdlIGFib3V0IHRoZSBiZWhhdmlvciBvZiB0aGUgc2VydmVyLiAmbmJzcDsNCjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgZ3Vlc3MgSeKAmW0ganVz dCBub3QgdXNlZCB0byBPQXV0aOKAmXMgY3VsdHVyZSBvZiBoYXZpbmcgbm8gZXhwZWN0YXRpb24g dGhhdCB0aGluZ3Mgd2lsbCBiZSBzcGVjaWZpZWQgdGlnaHRseSBlbm91Z2ggdGhhdCBJIGNhbiB3 cml0ZSBjb2RlIHRvIGltcGxlbWVudCBhcyBzcGVjaWZpZWQuICZuYnNwOy1UPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBNb24sIEFwciAxNSwg MjAxMyBhdCA3OjE1IEFNLCBKdXN0aW4gUmljaGVyICZsdDs8YSBocmVmPSJtYWlsdG86anJpY2hl ckBtaXRyZS5vcmciIHRhcmdldD0iX2JsYW5rIj5qcmljaGVyQG1pdHJlLm9yZzwvYT4mZ3Q7IHdy b3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+U2NvcGVz IGFyZW4ndCBtZWFudCB0byBiZSBpbnRlcm9wZXJhYmxlIGJldHdlZW4gc2VydmljZXMgc2luY2Ug dGhleSdyZSBuZWNlc3NhcmlseSBBUEktc3BlY2lmaWMuIFRoZSBvbmx5IGludGVyb3BlcmFibGUg Yml0IGlzIHRoYXQgdGhlcmUncyAqc29tZSogcGxhY2UgdG8gcHV0IHRoZSB2YWx1ZXMgYW5kIHRo YXQNCiBpdCdzIGV4cHJlc3NlZCBhcyBhIGJhZyBvZiBzcGFjZS1zZXBhcmF0ZWQgc3RyaW5ncy4g SG93IHRob3NlIHN0cmluZ3MgZ2V0IGludGVycHJldGVkIGFuZCBlbmZvcmNlZCAod2hpY2ggaXMg cmVhbGx5IHdoYXQncyBhdCBzdGFrZSBoZXJlKSBpcyB1cCB0byB0aGUgQVMgYW5kIFBSIChvciBh IGhpZ2hlci1sZXZlbCBwcm90b2NvbCBsaWtlIFVNQSkuPHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4 ODgiPjxicj4NCjxicj4NCiZuYnNwOy0tIEp1c3Rpbjwvc3Bhbj4gPG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiAwNC8xNS8yMDEzIDEwOjEzIEFNLCBUaW0gQnJh eSB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cD5UaGlzLCBhcyB3cml0dGVuLCBo YXMgemVybyBpbnRlcm9wZXJhYmlsaXR5LiZuYnNwOyBJIHRoaW5rIHRoaXMgZmVhdHVyZSBjYW4g cmVhbGx5IG9ubHkgYmUgbWFkZSB1c2VmdWwgaW4gdGhlIGNhc2Ugd2hlcmUgc2NvcGVzIGFyZSBm aXhlZCBzdHJpbmdzLjxvOnA+PC9vOnA+PC9wPg0KPHA+LVQ8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIEFwciAxNSwgMjAxMyA2OjU0IEFNLCAmcXVvdDtK dXN0aW4gUmljaGVyJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86anJpY2hlckBtaXRyZS5vcmci IHRhcmdldD0iX2JsYW5rIj5qcmljaGVyQG1pdHJlLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+WW91IGFyZSBjb3JyZWN0IHRoYXQgdGhl IGlkZWEgYmVoaW5kIHRoZSAmcXVvdDtzY29wZSZxdW90OyBwYXJhbWV0ZXIgYXQgcmVnaXN0cmF0 aW9uIGlzIGEgY29uc3RyYWludCBvbiBhdXRob3JpemF0aW9uLXRpbWUgc2NvcGVzIHRoYXQgYXJl IG1hZGUgYXZhaWxhYmxlLiBJdCdzIGJvdGggYSBtZWFucyBmb3IgdGhlIGNsaWVudCB0byByZXF1 ZXN0DQogYSBzZXQgb2YgdmFsaWQgc2NvcGVzIGFuZCBmb3IgdGhlIHNlcnZlciB0byBwcm92aXNp b24gKGFuZCBlY2hvIGJhY2sgdG8gdGhlIGNsaWVudCkgYSBzZXQgb2YgdmFsaWQgc2NvcGVzLjxi cj4NCjxicj4NCkkgKnJlYWxseSogZG9uJ3Qgd2FudCB0byB0cnkgdG8gZGVmaW5lIGEgbWF0Y2hp bmcgbGFuZ3VhZ2UgZm9yIHNjb3BlIGV4cHJlc3Npb25zLiBGb3IgdGhhdCB0byB3b3JrLCBhbGwg c2VydmVycyB3b3VsZCBuZWVkIHRvIGJlIGFibGUgdG8gcHJvY2VzcyB0aGUgcmVndWxhciBleHBy ZXNzaW9ucyBmb3IgYWxsIGNsaWVudHMsIGV2ZW4gaWYgdGhlIHNlcnZlcnMgdGhlbXNlbHZlcyBv bmx5IHN1cHBvcnQgc2ltcGxlLXN0cmluZyBzY29wZSB2YWx1ZXMuDQogQW55IHJlZ3VsYXIgZXhw cmVzc2lvbiBzeW50YXggd2UgcGljayBoZXJlIGlzIGd1YXJhbnRlZWQgdG8gYmUgaW5jb21wYXRp YmxlIHdpdGggc29tZXRoaW5nLCBhbmQgSSB0aGluayB0aGUgY29tcGxleGl0eSBkb2Vzbid0IGJ1 eSBtdWNoLiBBbHNvLCBJIHRoaW5rIHlvdSBzdWRkZW5seSBoYXZlIGEgcG90ZW50aWFsIHNlY3Vy aXR5IGlzc3VlIGlmIHlvdSBoYXZlIGEgYmFkIHJlZ2V4IGluIHBsYWNlIG9uIGVpdGhlciBlbmQu DQo8YnI+DQo8YnI+DQpBcyBpdCBzdGFuZHMgdG9kYXksIHRoZSBzZXJ2ZXIgY2FuIGludGVycHJl dCB0aGUgaW5jb21pbmcgcmVnaXN0cmF0aW9uIHNjb3BlcyBhbmQgZW5mb3JjZSB0aGVtIGhvd2V2 ZXIgaXQgd2FudHMgdG8uIFRoZSByZWFsIHRyaWNrIGNvbWVzIG5vdCBmcm9tIGFzc2lnbmluZyB0 aGUgdmFsdWVzIHRvIGEgcGFydGljdWxhciBjbGllbnQgYnV0IHRvIGVuZm9yY2luZyB0aGVtLCBh bmQgSSB0aGluayB0aGF0J3MgYWx3YXlzIGdvaW5nIHRvIGJlIHNlcnZpY2Utc3BlY2lmaWMuDQog V2UncmUganVzdCBub3QgYXMgY2xlYXIgb24gdGhhdCBhcyB3ZSBjb3VsZCBiZS48YnI+DQo8YnI+ DQpBZnRlciBsb29raW5nIG92ZXIgZXZlcnlvbmUncyBjb21tZW50cyBzbyBmYXIsIEknZCBsaWtl IHRvIHByb3Bvc2UgdGhlIGZvbGxvd2luZyB0ZXh0IGZvciB0aGF0IHNlY3Rpb246PGJyPg0KPGJy Pg0KPG86cD48L286cD48L3A+DQo8cHJlPiZuYnNwOyZuYnNwOyBzY29wZTxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBPUFRJT05BTC4mbmJzcDsg U3BhY2Ugc2VwYXJhdGVkIGxpc3Qgb2Ygc2NvcGUgdmFsdWVzIChhcyBkZXNjcmliZWQgaW48bzpw PjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgT0F1dGgg Mi4wIDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY3NDkjc2VjdGlvbi0z LjMiIHRhcmdldD0iX2JsYW5rIj5TZWN0aW9uJm5ic3A7My4zIFtSRkM2NzQ5XTwvYT4pIHRoYXQg dGhlIGNsaWVudCBjYW4gdXNlIHdoZW4gPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7cmVxdWVzdGluZyBhY2Nlc3MgdG9rZW5zLiZuYnNw OyBBcyBzY29wZSB2YWx1ZXMgYXJlIHNlcnZpY2Utc3BlY2lmaWMsIDxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3RoZSBBdXRob3JpemF0 aW9uIFNlcnZlciBNQVkgZGVmaW5lIGl0cyBvd24gbWF0Y2hpbmcgcnVsZXMgd2hlbjxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDtkZXRlcm1pbmlu ZyBpZiBhIHNjb3BlIHZhbHVlIHVzZWQgZHVyaW5nIGFuIGF1dGhvcml6YXRpb24gcmVxdWVzdDxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpcyB2 YWxpZCBhY2NvcmRpbmcgdG8gdGhlIHNjb3BlIHZhbHVlcyBhc3NpZ25lZCBkdXJpbmcgPG86cD48 L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7cmVn aXN0cmF0aW9uLiBQb3NzaWJsZSBtYXRjaGluZyBydWxlcyBpbmNsdWRlIHdpbGRjYXJkIHBhdHRl cm5zLDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJz cDtyZWd1bGFyIGV4cHJlc3Npb25zLCBvciBleGFjdGx5IG1hdGNoaW5nIHRoZSBzdHJpbmcuIElm IG9taXR0ZWQsIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwO2FuIEF1dGhvcml6YXRpb24gU2VydmVyIE1BWSByZWdpc3RlciBhIENsaWVu dCB3aXRoIGEgZGVmYXVsdCA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDtzZXQgb2Ygc2NvcGVzLjxvOnA+PC9vOnA+PC9wcmU+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJv dHRvbToxMi4wcHQiPjxicj4NCkNvbW1lbnRzPyBJbXByb3ZlbWVudHM/PGJyPg0KPGJyPg0KJm5i c3A7LS0gSnVzdGluPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5PbiAwNC8xNC8yMDEzIDA4OjIzIFBNLCBNYW5nZXIsIEphbWVzIEggd3Jv dGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT5QcmVzdW1hYmx5IGF0IGFwcCByZWdp c3RyYXRpb24gdGltZSBhbnkgc2NvcGUgc3BlY2lmaWNhdGlvbiBpcyByZWFsbHkgYSBjb25zdHJh aW50IG9uIHRoZSBzY29wZSB2YWx1ZXMgdGhhdCBjYW4gYmUgcmVxdWVzdGVkIGluIGFuIGF1dGhv cml6YXRpb24gZmxvdy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT5TbyBpZGVhbGx5IHJlZ2lzdHJhdGlvbiBzaG91bGQgYWNjZXB0IHJ1bGVzIGZv ciBtYXRjaGluZyBzY29wZXMsIGFzIG9wcG9zZWQgdG8gYWN0dWFsIHNjb3BlIHZhbHVlcy48bzpw PjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Zb3UgY2Fu IHRyeSB0byB1c2Ugc2NvcGUgdmFsdWVzIGFzIHRoZWlyIG93biBtYXRjaGluZyBydWxlcy4gVGhh dCBpcyBmaW5lIGZvciBhIHNtYWxsIHNldCBvZiAmcXVvdDtzdGF0aWMmcXVvdDsgc2NvcGVzLiBJ dCBzdGFydHMgdG8gZmFpbCB3aGVuIHRoZXJlIGFyZSBhIGxhcmdlIG51bWJlciBvZiBzY29wZXMs IG9yIHNjb3BlcyB0aGF0IGNhbiBpbmNsdWRlIHBhcmFtZXRlcnMgKHJlc291cmNlIHBhdGhzPyBl bWFpbCBhZGRyZXNzZXM/KS4gWW91IGNhbiB0cnkgdG8gcGF0Y2ggdGhvc2UgZmFpbHVyZXMgYnkg YWxsb3dpbmcgc2VydmljZXMgdG8gZGVmaW5lIHNlcnZpY2Utc3BlY2lmaWMgc3BlY2lhbCAmcXVv dDt3aWxkY2FyZCZxdW90OyBzY29wZSB2YWx1ZXMgdGhhdCBjYW4gb25seSBiZSB1c2VkIGR1cmlu ZyByZWdpc3RyYXRpb24gKGVnICZxdW90O3JlYWQ6KiZxdW90OykuPG86cD48L286cD48L3ByZT4N CjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+QWx0ZXJuYXRpdmVseSwgcmVwbGFj ZSAnc2NvcGUnIGluIHJlZ2lzdHJhdGlvbiB3aXRoICdzY29wZV9yZWdleCcgdGhhdCBob2xkcyBh IHJlZ3VsYXIgZXhwcmVzc2lvbiB0aGF0IGFsbCBzY29wZSB2YWx1ZXMgaW4gYW4gYXV0aG9yaXph dGlvbiBmbG93IG11c3QgbWF0Y2guPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48 L286cD48L3ByZT4NCjxwcmU+LS08bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5KYW1lcyBNYW5nZXI8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPk9BdXRoIG1haWxpbmcgbGlzdDxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9h PjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGgg bWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_d857b70d64e349a2ac0ff52a6aaf5a19BY2PR03MB041namprd03pro_-- From phil.hunt@oracle.com Thu Apr 18 09:18:54 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62FE121F8E4C for ; Thu, 18 Apr 2013 09:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.202 X-Spam-Level: X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 Ddk8sq-77Tpf for ; Thu, 18 Apr 2013 09:18:52 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id BDEB521F8E48 for ; Thu, 18 Apr 2013 09:18:51 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r3IGInVm007777 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 18 Apr 2013 16:18:50 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r3IGImPd004482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 18 Apr 2013 16:18:49 GMT Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r3IGImo2015787; Thu, 18 Apr 2013 16:18:48 GMT Received: from [192.168.1.8] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 18 Apr 2013 09:18:27 -0700 References: <255B9BB34FB7D647A506DC292726F6E1150C74DADA@WSMSG3153V.srv.dir.telstra.com> <516C069F.9090308@mitre.org> <516C0B9D.6000402@mitre.org> <516C101F.2090706@mitre.org> <516C1714.8070503@mitre.org> <4E1F6AAD24975D4BA5B168042967394367641A87@TK5EX14MBXC283.redmond.corp.microsoft.com> <516C3152.9070603@mitre.org> <4E1F6AAD24975D4BA5B168042967394367641FAB@TK5EX14MBXC283.redmond.corp.microsoft.com> <516C54F2.8040708@mitre.org> <4E1F6AAD24975D4BA5B16804296739436766BCC4@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739436766C964@TK5EX14MBXC284.redmond.corp.microsoft.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-6106BB0D-EF5B-4DA3-96E4-A2DE7165324A Content-Transfer-Encoding: 7bit Message-Id: <8192E67F-A531-4D98-95A1-5103E17812B3@oracle.com> X-Mailer: iPhone Mail (10B329) From: Phil Hunt Date: Thu, 18 Apr 2013 09:18:03 -0700 To: Tim Bray X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Registration: Scope Values X-BeenThere: oauth@ietf.org X-Mailman-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, 18 Apr 2013 16:18:54 -0000 --Apple-Mail-6106BB0D-EF5B-4DA3-96E4-A2DE7165324A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable There are a number of cases that all demand a more parsable scope.=20 One of the cases is multi resource scopes.=20 Would it not be reasonable to develop another draft that defines a simple js= on structure that allows different uris to be matched with specific scope va= lues? I also wonder if registration is the place to redefine or further define sco= pe.=20 IOW a separate draft can be totally optional. But can be used by multi-resou= rce sites to solve oauth2s limited scope capability.=20 Phil On 2013-04-18, at 9:03, Tim Bray wrote: > I=E2=80=99m unconvinced, Mike. Obviously you=E2=80=99re right about the l= ooseness of OAuth2 scope specification, but this is a very specific semantic= of what happens when you register, and I don=E2=80=99t think we=E2=80=99re b= ound by history here. If we can=E2=80=99t safely say anything about what t= he list of scopes means, then I'm with you let's take them out. But the mos= t obvious intended semantic is (from the client) =E2=80=9CI promise to ask o= nly for these=E2=80=9D and from the server =E2=80=9CThese are the only ones I= =E2=80=99ll give you tokens for.=E2=80=9D Or does someone have use-cases fo= r an alternative semantic? >=20 > To make this concrete, I propose the following: > =E2=80=9CSpace-separated list of scope values (as described in OAuth 2.0 S= ection 3.3 [RFC6749]) that the client is declaring to the server that it wil= l restrict itself to when requesting access tokens, and that the server is d= eclaring to the client that it is registered to use when requesting access t= okens. Clients SHOULD assume that servers will refuse to grant access token= s for scopes not in the list provided by the server.=E2=80=9D >=20 >=20 >=20 >=20 >=20 > On Thu, Apr 18, 2013 at 8:55 AM, Mike Jones w= rote: >> I don=E2=80=99t think it=E2=80=99s possible to define what it means in an= interoperable way because OAuth didn=E2=80=99t specify scopes in an interop= erable way. No, I don=E2=80=99t like that either, but I think that=E2=80=99= s where things are. That=E2=80=99s why I was advocating deleting this regis= tration feature entirely. >>=20 >> =20 >>=20 >> But understanding it might be useful in some contexts, I=E2=80=99m OK kee= ping it, provided we be clear that the semantics of =E2=80=9Cregistered to u= se=E2=80=9D are service-specific. >>=20 >> =20 >>=20 >> -- Mike >>=20 >> =20 >>=20 >> From: Tim Bray [mailto:twbray@google.com]=20 >> Sent: Thursday, April 18, 2013 8:36 AM >> To: Mike Jones >> Cc: Justin Richer; oauth@ietf.org >>=20 >>=20 >> Subject: Re: [OAUTH-WG] Registration: Scope Values >> =20 >>=20 >> On the server-to-client side, what does =E2=80=9Cregistered to use=E2=80=9D= mean? Does it mean that the client should assume that any scopes not on th= e list WILL not be granted, MAY not be granted.... or what? Is this already= covered elsewhere? -T >>=20 >> =20 >>=20 >> On Thu, Apr 18, 2013 at 8:28 AM, Mike Jones = wrote: >>=20 >> Thanks, Justin. I agree with the need for the generic two-sided language= . I=E2=80=99d still keep this language for scope, because we want to captur= e the =E2=80=9Cdeclaring=E2=80=9D aspect in this case: >>=20 >> =20 >>=20 >> =E2=80=9CSpace separated list of scope values (as described in OAuth 2.0 S= ection 3.3 [RFC6749]) that the client is declaring to the server that it may= use when requesting access tokens and that the server is declaring to the c= lient that it is registered to use when requesting access tokens.=E2=80=9D. >>=20 >> =20 >>=20 >> You should probably also reinforce that scope values are service-specific= and may not consist only of a static set of string values, and that therefo= re, in some cases, an exhaustive list of registered scope values is not poss= ible. >>=20 >> =20 >>=20 >> -- Mike >>=20 >> =20 >>=20 >> From: Justin Richer [mailto:jricher@mitre.org]=20 >> Sent: Monday, April 15, 2013 12:29 PM >>=20 >>=20 >> To: Mike Jones >> Cc: Tim Bray; oauth@ietf.org >> Subject: Re: [OAUTH-WG] Registration: Scope Values >>=20 >> =20 >>=20 >> I think that because the "declaration" issue affects all parameters in th= e list, not just scope, we should adopt this in a higher level paragraph and= leave it out of the individual parameter descriptions. Thus, something like= this inserted as the second paragraph in section 2: >>=20 >> The client metadata values serve two parallel purposes in the overall OAu= th Dynamic Registration protocol:=20 >>=20 >> - the Client requesting its desired values for each parameter to the Aut= horization Server in a [register] or [update] request, >> - the Authorization Server informing the Client of the current values of= each parameter that the Client has been registered to use through a [client= information response].=20 >>=20 >> An Authorization Server MAY override any value that a Client requests dur= ing the registration process (including any omitted values) and replace the r= equested value with a default. The normative indications in the following li= st apply to the Client's declaration of its desired values.=20 >>=20 >> The Authorization Server SHOULD provide documentation for any fields that= it requires to be filled in by the client or to have particular values or f= ormats. Extensions and profiles... >>=20 >>=20 >> And then remove the sidedness-language from the scope parameter and any o= ther parameters where it might have crept in inadvertently.=20 >>=20 >> -- Justin >>=20 >> On 04/15/2013 01:29 PM, Mike Jones wrote: >>=20 >> We could fix the one-sided language by changing >>=20 >> =E2=80=9CSpace separated list of scope values (as described in OAuth 2.0 S= ection 3.3 [RFC6749]) that the client is declaring that it may use when requ= esting access tokens.=E2=80=9D >>=20 >> to >>=20 >> =E2=80=9CSpace separated list of scope values (as described in OAuth 2.0 S= ection 3.3 [RFC6749]) that the client is declaring to the server that it may= use when requesting access tokens and that the server is declaring to the c= lient that it is registered to use when requesting access tokens.=E2=80=9D. >>=20 >> =20 >>=20 >> Again, I chose the =E2=80=9Cregistered to use=E2=80=9D language carefully= =E2=80=93 because in the general case it=E2=80=99s not a restriction on the= values that the client can use =E2=80=93 just a statement by the server to t= he client that it is registered to use those particular values. In both cas= es, the parties are making declarations to one another. >>=20 >> =20 >>=20 >> If you adopt that language (or keep the original language), then yes, I=E2= =80=99d consider this closed. >>=20 >> =20 >>=20 >> -- Mike >>=20 >> =20 >>=20 >> From: Justin Richer [mailto:jricher@mitre.org]=20 >> Sent: Monday, April 15, 2013 9:57 AM >> To: Mike Jones >> Cc: Tim Bray; oauth@ietf.org >> Subject: Re: [OAUTH-WG] Registration: Scope Values >>=20 >> =20 >>=20 >> I absolutely do not want to delete this feature, as (having implemented i= t) I think it's very useful. This is a very established pattern in manual re= gistration: I know of many, many OAuth2 servers and clients that are set up w= here the client must pre-register a set of scopes.=20 >>=20 >> I don't like the language of "the client is declaring" because it's too o= ne-sided. The client might not have declared anything, and it might be the s= erver that's declaring something to the client. Deleting the "is declaring" b= it removes that unintended restriction of the language while keeping the ori= ginal meaning intact. I actually thought that I had fixed that before the la= st draft went in but apparently I missed this one. >>=20 >> I will work on clarifying the intent of the whole metadata set in its int= roductory paragraph(s) so that it's clear that all of these fields are used i= n both of these situations: >>=20 >> 1) The client declaring to the server its desire to use a particular val= ue >> 2) The server declaring to the client that it has been registered with a= particular value >>=20 >> This should hopefully clear up the issue in the editor's note that I curr= ently have at the top of that section right now, too. >>=20 >> Mike, since you were the one who originally brought up the issue, and you= 're fine with the existing text, can I take this as closed now? Assuming tha= t you agree with deleting "is declaring" for reasons stated above, I'm fine w= ith leaving everything else as is and staying quiet on what the server has t= o do with the scopes. >>=20 >> -- Justin >>=20 >>=20 >> On 04/15/2013 12:44 PM, Mike Jones wrote: >>=20 >> I think that the existing wording is superior to the proposed changed wor= ding. The existing wording is: >>=20 >> =20 >>=20 >> scope >>=20 >> OPTIONAL. Space separated list of scope values (as described in >>=20 >> OAuth 2.0 Section 3.3 [RFC6749]) that the client is declaring that >>=20 >> it may use when requesting access tokens. If omitted, an >>=20 >> Authorization Server MAY register a Client with a default set of >>=20 >> scopes. >>=20 >> =20 >>=20 >> For instance, the current =E2=80=9Cclient is declaring=E2=80=9D wording w= ill always be correct, whereas as the change to =E2=80=9Cclient can use=E2=80= =9D wording implies a restriction on client behavior that is not always appl= icable. The =E2=80=9Cclient is declaring=E2=80=9D wording was specific and p= urposefully chosen, and I think should be retained. In particular, we can=E2= =80=99t do anything that implies that only the registered scopes values can b= e used. At the OAuth spec level, this is a hint as to possible future clien= t behavior =E2=80=93 not a restriction on future client behavior. >>=20 >> =20 >>=20 >> Also, for the reasons that Tim stated, I=E2=80=99m strongly against any =E2= =80=9Cmatching=E2=80=9D or =E2=80=9Cregex=E2=80=9D language in the spec pert= aining to scopes =E2=80=93 as it=E2=80=99s not actionable. >>=20 >> =20 >>=20 >> So I=E2=80=99d propose that we leave the existing scope wording in place.= Alternatively, I=E2=80=99d also be fine with deleting this feature entirel= y, as I don=E2=80=99t think it=E2=80=99s useful in the general case. >>=20 >> =20 >>=20 >> -- Mike >>=20 >> =20 >>=20 >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of= Justin Richer >> Sent: Monday, April 15, 2013 8:05 AM >> To: Tim Bray; oauth@ietf.org >> Subject: Re: [OAUTH-WG] Registration: Scope Values >>=20 >> =20 >>=20 >> On 04/15/2013 10:52 AM, Tim Bray wrote: >>=20 >>=20 >>=20 >> I=E2=80=99d use the existing wording; it=E2=80=99s perfectly clear. Fail= ing that, if there=E2=80=99s strong demand for registration of structured sc= opes, bless the use of regexes, either PCREs or some careful subset. >>=20 >>=20 >> Thanks for the feedback -- Of these two choices, I'd rather leave it as-i= s.=20 >>=20 >>=20 >>=20 >>=20 >> =20 >>=20 >> However, I=E2=80=99d subtract the sentence =E2=80=9CIf omitted, an Author= ization Server MAY register a Client with a default set of scopes.=E2=80=9D= It adds no value; if the client doesn=E2=80=99t declare scopes, the clien= t doesn=E2=80=99t declare scopes, that=E2=80=99s all. -T >>=20 >>=20 >> Remember, all of these fields aren't just for the client *request*, they'= re also for the server's *response* to either a POST, PUT, or GET request. (= I didn't realize it, but perhaps the wording as stated right now doesn't mak= e that clear -- I need to fix that.) The value that it adds is if the client= doesn't ask for any particular scopes, the server can still assign it scope= s and the client can do something smart with that. Dumb clients are allowed t= o ignore it if it doesn't mean anything to them.=20 >>=20 >> This is how our server implementation actually works right now. If the cl= ient doesn't ask for anything specific at registration, the server hands it a= bag of "default" scopes. Same thing happens at auth time -- if the client d= oesn't ask for any particular scopes, the server hands it all of its registe= red scopes as a default. Granted, on our server, scopes are just simple stri= ngs right now, so they get compared at the auth endpoint with an exact strin= g-match metric and set-based logic.=20 >>=20 >> -- Justin >>=20 >>=20 >>=20 >>=20 >> =20 >>=20 >> On Mon, Apr 15, 2013 at 7:35 AM, Justin Richer wrote:= >>=20 >> What would you suggest for wording here, then? Keeping in mind that we ca= nnot (and don't want to) prohibit expression-based scopes.=20 >>=20 >> -- Justin >>=20 >> =20 >>=20 >> On 04/15/2013 10:33 AM, Tim Bray wrote: >>=20 >> No, I mean it=E2=80=99s not interoperable at the software-developer level= . I can=E2=80=99t register scopes at authorization time with any predictabl= e effect that I can write code to support, either client or server side, wit= hout out-of-line non-interoperable knowledge about the behavior of the serve= r. =20 >>=20 >> =20 >>=20 >> I guess I=E2=80=99m just not used to OAuth=E2=80=99s culture of having no= expectation that things will be specified tightly enough that I can write c= ode to implement as specified. -T >>=20 >> =20 >>=20 >> On Mon, Apr 15, 2013 at 7:15 AM, Justin Richer wrote:= >>=20 >> Scopes aren't meant to be interoperable between services since they're ne= cessarily API-specific. The only interoperable bit is that there's *some* pl= ace to put the values and that it's expressed as a bag of space-separated st= rings. How those strings get interpreted and enforced (which is really what'= s at stake here) is up to the AS and PR (or a higher-level protocol like UMA= ). >>=20 >> -- Justin >>=20 >> =20 >>=20 >> On 04/15/2013 10:13 AM, Tim Bray wrote: >>=20 >> This, as written, has zero interoperability. I think this feature can re= ally only be made useful in the case where scopes are fixed strings. >>=20 >> -T >>=20 >> On Apr 15, 2013 6:54 AM, "Justin Richer" wrote: >>=20 >> You are correct that the idea behind the "scope" parameter at registratio= n is a constraint on authorization-time scopes that are made available. It's= both a means for the client to request a set of valid scopes and for the se= rver to provision (and echo back to the client) a set of valid scopes. >>=20 >> I *really* don't want to try to define a matching language for scope expr= essions. For that to work, all servers would need to be able to process the r= egular expressions for all clients, even if the servers themselves only supp= ort simple-string scope values. Any regular expression syntax we pick here i= s guaranteed to be incompatible with something, and I think the complexity d= oesn't buy much. Also, I think you suddenly have a potential security issue i= f you have a bad regex in place on either end.=20 >>=20 >> As it stands today, the server can interpret the incoming registration sc= opes and enforce them however it wants to. The real trick comes not from ass= igning the values to a particular client but to enforcing them, and I think t= hat's always going to be service-specific. We're just not as clear on that a= s we could be. >>=20 >> After looking over everyone's comments so far, I'd like to propose the fo= llowing text for that section: >>=20 >>=20 >>=20 >> scope >> OPTIONAL. Space separated list of scope values (as described in >> OAuth 2.0 Section 3.3 [RFC6749]) that the client can use when=20 >> requesting access tokens. As scope values are service-specific,=20= >> the Authorization Server MAY define its own matching rules when >> determining if a scope value used during an authorization request >> is valid according to the scope values assigned during=20 >> registration. Possible matching rules include wildcard patterns, >> regular expressions, or exactly matching the string. If omitted,=20= >> an Authorization Server MAY register a Client with a default=20 >> set of scopes. >>=20 >> Comments? Improvements? >>=20 >> -- Justin >>=20 >>=20 >>=20 >> On 04/14/2013 08:23 PM, Manger, James H wrote: >>=20 >> Presumably at app registration time any scope specification is really a c= onstraint on the scope values that can be requested in an authorization flow= . >> =20 >> So ideally registration should accept rules for matching scopes, as oppos= ed to actual scope values. >> =20 >> You can try to use scope values as their own matching rules. That is fine= for a small set of "static" scopes. It starts to fail when there are a larg= e number of scopes, or scopes that can include parameters (resource paths? e= mail addresses?). You can try to patch those failures by allowing services t= o define service-specific special "wildcard" scope values that can only be u= sed during registration (eg "read:*"). >> =20 >> Alternatively, replace 'scope' in registration with 'scope_regex' that ho= lds a regular expression that all scope values in an authorization flow must= match. >> =20 >> -- >> James Manger >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> =20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-6106BB0D-EF5B-4DA3-96E4-A2DE7165324A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
There are a number of cases that all d= emand a more parsable scope. 

One of the cases= is multi resource scopes. 

Would it not be re= asonable to develop another draft that defines a simple json structure that a= llows different uris to be matched with specific scope values?
I also wonder if registration is the place to redefine or furthe= r define scope. 

IOW a separate draft can be t= otally optional. But can be used by multi-resource sites to solve oauth2s li= mited scope capability. 

Phil

On 2013-04-18, at 9:= 03, Tim Bray <twbray@google.com&= gt; wrote:

I=E2= =80=99m unconvinced, Mike.  Obviously you=E2=80=99re right about the lo= oseness of OAuth2 scope specification, but this is a very specific semantic o= f what happens when you register, and I don=E2=80=99t think we=E2=80=99re bo= und by history here.   If we can=E2=80=99t safely say anything about wh= at the list of scopes means, then I'm with you let's take them out.  Bu= t the most obvious intended semantic is (from the client) =E2=80=9CI promise= to ask only for these=E2=80=9D and from the server =E2=80=9CThese are the o= nly ones I=E2=80=99ll give you tokens for.=E2=80=9D  Or does someone ha= ve use-cases for an alternative semantic?

To make this concrete, I propose the following:

=E2=80=9CSpace-sepa= rated list of scope values (as described in OAuth 2.0 Section 3.3 [RFC6749]) that the client is declaring to the server t= hat it will restrict itself to when requesting access tokens, and that the s= erver is declaring to the client that it is registered to use when requestin= g access tokens.  Clients SHOULD assume that servers will refuse to grant access t= okens for scopes not in the list provided by the server.=E2=80=9D=




On Thu, Apr 18, 2013 at= 8:55 AM, Mike Jones <Michael.Jones@microsoft.com> w= rote:

I don=E2=80=99t think it=E2= =80=99s possible to define what it means in an interoperable way because OAu= th didn=E2=80=99t specify scopes in an interoperable way.  No, I don=E2= =80=99t like that either, but I think that=E2=80=99s where things are.  That=E2=80=99s w= hy I was advocating deleting this registration feature entirely.

 =

But understanding it might b= e useful in some contexts, I=E2=80=99m OK keeping it, provided we be clear t= hat the semantics of =E2=80=9Cregistered to use=E2=80=9D are service-specifi= c.

 =

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

 =

From: Tim Bray [m= ailto:twbray@google.c= om]
Sent: Thursday, April 18, 2013 8:36 AM
To: Mike Jones
Cc: Justin Richer; oauth@ietf.org


Subject: Re: [OAUTH-WG] Registration: Scope Values

 

On the server-to-client side, what does =E2=80=9Cregi= stered to use=E2=80=9D mean?  Does it mean that the client should assum= e that any scopes not on the list WILL not be granted, MAY not be granted...= . or what?  Is this already covered elsewhere? -T

 

On Thu, Apr 18, 2013 at 8:28 AM, Mike Jones <Michael.Jones@mi= crosoft.com> wrote:

Thanks, Justin.  I agr= ee with the need for the generic two-sided language.  I=E2=80=99d still= keep this language for scope, because we want to capture the =E2=80=9Cdeclaring=E2=80=9D aspec= t in this case:

 =

=E2=80=9CSpace separated list of scope values (as descr= ibed in OAuth 2.0 Section 3.3 [RFC6749]) that the client is declaring to the server t= hat it may use when requesting access tokens and that the server is declarin= g to the client that it is registered to use when requesting access tokens.=E2=80= =9D.

 =

You should probably also re= inforce that scope values are service-specific and may not consist only of a static set of string values, and that therefore, in some cases, an exh= austive list of registered scope values is not possible.

 =

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

 =

From: Justin Rich= er [mailto:jricher@mi= tre.org]
Sent: Monday, April 15, 2013 12:29 PM


To: Mike Jones
Cc: Tim Bray; oau= th@ietf.org
Subject: Re: [OAUTH-WG] Registration: Scope Values

 

I think that because t= he "declaration" issue affects all parameters in the list, not just scope, w= e should adopt this in a higher level paragraph and leave it out of the indi= vidual parameter descriptions. Thus, something like this inserted as the second paragraph in= section 2:

The client metadata values serve two parallel purpose= s in the overall OAuth Dynamic Registration protocol:

 - the Client requesting its desired values for each parameter to the A= uthorization Server in a [register] or [update] request,
 - the Authorization Server informing the Client of the current values o= f each parameter that the Client has been registered to use through a [clien= t information response].

An Authorization Server MAY override any value that a Client requests during= the registration process (including any omitted values) and replace the req= uested value with a default. The normative indications in the following list= apply to the Client's declaration of its desired values.

The Authorization Server SHOULD provide documentation for any fields that it= requires to be filled in by the client or to have particular values or form= ats. Extensions and profiles...


And then remove the sidedness-language from the scope parameter and any othe= r parameters where it might have crept in inadvertently.

 -- Justin

On 04/15/2013 01:29 PM, Mike Jones wrote:

We could fix the one-sided l= anguage by changing

=E2=80=9CSpace separated list of scope values (as descr= ibed in OAuth 2.0 Section 3.3 [RFC6749]) that the client is declaring that it may us= e when requesting access tokens.=E2=80=9D

to

=

=E2=80=9CSpace separated list of scope values (as descr= ibed in OAuth 2.0 Section 3.3 [RFC6749]) that the client is declaring to the server t= hat it may use when requesting access tokens and that the server is declarin= g to the client that it is registered to use when requesting access tokens.=E2=80= =9D.

 =

Again, I chose the =E2=80=9C= registered to use=E2=80=9D language carefully =E2=80=93 because in the gener= al case it=E2=80=99s not a restriction on the values that the client can use =E2=80=93 just a statem= ent by the server to the client that it is registered to use those particula= r values.  In both cases, the parties are making declarations to one an= other.

 =

If you adopt that language (= or keep the original language), then yes, I=E2=80=99d consider this closed.<= /span>

 =

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

 =

From: Justin Rich= er [mailto:jricher@mi= tre.org]
Sent: Monday, April 15, 2013 9:57 AM
To: Mike Jones
Cc: Tim Bray; oau= th@ietf.org
Subject: Re: [OAUTH-WG] Registration: Scope Values

 

I absolutely do not wa= nt to delete this feature, as (having implemented it) I think it's very usef= ul. This is a very established pattern in manual registration: I know of man= y, many OAuth2 servers and clients that are set up where the client must pre-register a se= t of scopes.

I don't like the language of "the client is declaring" because it's too one-= sided. The client might not have declared anything, and it might be the serv= er that's declaring something to the client. Deleting the "is declaring" bit= removes that unintended restriction of the language while keeping the original meaning intact. I actually thoug= ht that I had fixed that before the last draft went in but apparently I miss= ed this one.

I will work on clarifying the intent of the whole metadata set in its introd= uctory paragraph(s) so that it's clear that all of these fields are used in b= oth of these situations:

 1) The client declaring to the server its desire to use a particular v= alue
 2) The server declaring to the client that it has been registered with= a particular value

This should hopefully clear up the issue in the editor's note that I current= ly have at the top of that section right now, too.

Mike, since you were the one who originally brought up the issue, and you're= fine with the existing text, can I take this as closed now? Assuming that y= ou agree with deleting "is declaring" for reasons stated above, I'm fine wit= h leaving everything else as is and staying quiet on what the server has to do with the scopes.

 -- Justin

On 04/15/2013 12:44 PM, Mike Jones wrote:

I think that the existing w= ording is superior to the proposed changed wording.  The existing wordi= ng is:

 =

   scope

     = OPTIONAL.  Space separated list of scope values (as described in

     = OAuth 2.0 Section 3.3 [RFC6749]) that the client is declaring that=

     = it may use when requesting access tokens.  If omitted, an

     = Authorization Server MAY register a Client with a default set of<= /u>

     = scopes.

 =

For instance, the current =E2= =80=9Cclient is declaring=E2=80=9D wording will always be correct, whereas a= s the change to =E2=80=9Cclient can use=E2=80=9D wording implies a restriction on client= behavior that is not always applicable.  The =E2=80=9Cclient is declar= ing=E2=80=9D wording was specific and purposefully chosen, and I think shoul= d be retained.  In particular, we can=E2=80=99t do anything that implie= s that only the registered scopes values can be used.  At the OAuth spec leve= l, this is a hint as to possible future client behavior =E2=80=93 not a rest= riction on future client behavior.

 =

Also, for the reasons that T= im stated, I=E2=80=99m strongly against any =E2=80=9Cmatching=E2=80=9D or =E2= =80=9Cregex=E2=80=9D language in the spec pertaining to scopes =E2=80=93 as it=E2=80=99s not actionable.

 =

So I=E2=80=99d propose that= we leave the existing scope wording in place.  Alternatively, I=E2=80=99= d also be fine with deleting this feature entirely, as I don=E2=80=99t think it=E2=80=99s u= seful in the general case.

 =

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

 =

From: oauth-bounces@ie= tf.org [mail= to:oauth-bounces@ietf.org] On Behalf Of Justin Richer
Sent: Monday, April 15, 2013 8:05 AM
To: Tim Bray; oau= th@ietf.org
Subject: Re: [OAUTH-WG] Registration: Scope Values

 

On 04/15/2013 10:52 AM= , Tim Bray wrote:


I=E2=80=99d use the existing wording; it=E2=80=99s pe= rfectly clear.  Failing that, if there=E2=80=99s strong demand for regi= stration of structured scopes, bless the use of regexes, either PCREs or som= e careful subset.


Thanks for the feedback -- Of these two choices, I'd rather leave it as-is. <= br>


 

However, I=E2=80=99d subtract the sentence =E2=80=9CI= f omitted, an Authorization Server MAY register a Client with a default set o= f  scopes.=E2=80=9D  It adds no value; if the client doesn=E2=80=99= t declare scopes, the client doesn=E2=80=99t declare scopes, that=E2=80=99s all.  -T<= /u>


Remember, all of these fields aren't just for the client *request*, they're a= lso for the server's *response* to either a POST, PUT, or GET request. (I di= dn't realize it, but perhaps the wording as stated right now doesn't make th= at clear -- I need to fix that.) The value that it adds is if the client doesn't ask for any particular scop= es, the server can still assign it scopes and the client can do something sm= art with that. Dumb clients are allowed to ignore it if it doesn't mean anyt= hing to them.

This is how our server implementation actually works right now. If the clien= t doesn't ask for anything specific at registration, the server hands it a b= ag of "default" scopes. Same thing happens at auth time -- if the client doe= sn't ask for any particular scopes, the server hands it all of its registered scopes as a default. Granted, on o= ur server, scopes are just simple strings right now, so they get compared at= the auth endpoint with an exact string-match metric and set-based logic.

 -- Justin



 

On Mon, Apr 15, 2013 at 7:35 AM, Justin Richer <jricher@mitre.org&g= t; wrote:

What would you suggest for wording here, then? Keepin= g in mind that we cannot (and don't want to) prohibit expression-based scope= s.

 -- Justin

 

On 04/15/2013 10:33 AM, Tim Bray wrote:=

No, I mean it=E2=80=99s not interoperable at the soft= ware-developer level.  I can=E2=80=99t register scopes at authorization= time with any predictable effect that I can write code to support, either client or server side, without out-of-line non-interoperable knowledge abou= t the behavior of the server.  

 

I guess I=E2=80=99m just not used to OAuth=E2=80=99s c= ulture of having no expectation that things will be specified tightly enough= that I can write code to implement as specified.  -T

=

 

On Mon, Apr 15, 2013 at 7:15 AM, Justin Richer <jricher@mitre.org&g= t; wrote:

Scopes aren't meant to be interoperable between servi= ces since they're necessarily API-specific. The only interoperable bit is th= at there's *some* place to put the values and that it's expressed as a bag of space-separated strings. How those strings get i= nterpreted and enforced (which is really what's at stake here) is up to the A= S and PR (or a higher-level protocol like UMA).

 -- Justin

 

On 04/15/2013 10:13 AM, Tim Bray wrote:=

This, as written, has zero interoperability.  I think this feature c= an really only be made useful in the case where scopes are fixed strings.=

-T

On Apr 15, 2013 6:54 AM, "Justin Richer" <jricher@mitre.org> wrote= :

You are correct that t= he idea behind the "scope" parameter at registration is a constraint on auth= orization-time scopes that are made available. It's both a means for the cli= ent to request a set of valid scopes and for the server to provision (and echo back to the= client) a set of valid scopes.

I *really* don't want to try to define a matching language for scope express= ions. For that to work, all servers would need to be able to process the reg= ular expressions for all clients, even if the servers themselves only suppor= t simple-string scope values. Any regular expression syntax we pick here is guaranteed to be incompatible= with something, and I think the complexity doesn't buy much. Also, I think y= ou suddenly have a potential security issue if you have a bad regex in place= on either end.

As it stands today, the server can interpret the incoming registration scope= s and enforce them however it wants to. The real trick comes not from assign= ing the values to a particular client but to enforcing them, and I think tha= t's always going to be service-specific. We're just not as clear on that as we could be.

After looking over everyone's comments so far, I'd like to propose the follo= wing text for that section:


   scope
      OPTIONAL.  Space separated list of s=
cope values (as described in
      OAuth 2.0 Section 3.3 [RFC6749]) that the client can use when 
      requesting access tokens.  As s=
cope values are service-specific, 
      the Authorization Server MAY define=
 its own matching rules when
      determining if a scope value used during=
 an authorization request
      is valid according to the scope values a=
ssigned during 
      registration. Possible matching rul=
es include wildcard patterns,
      regular expressions, or exactly matching=
 the string. If omitted, 
      an Authorization Server MAY registe=
r a Client with a default 
      set of scopes.


Comments? Improvements?

 -- Justin


On 04/14/2013 08:23 PM, Manger, James H wrote:= 

Presumably at app registration time any scope specification is really a=
 constraint on the scope values that can be requested in an authorization fl=
ow.
 
So ideally registration should accept rules for matching scopes, as opp=
osed to actual scope values.
 
You can try to use scope values as their own matching rules. That is fi=
ne for a small set of "static" scopes. It starts to fail when there are a la=
rge number of scopes, or scopes that can include parameters (resource paths?=
 email addresses?). You can try to patch those failures by allowing services=
 to define service-specific special "wildcard" scope values that can only be=
 used during registration (eg "read:*").
 
Alternatively, replace 'scope' in registration with 'scope_regex' that h=
olds a regular expression that all scope values in an authorization flow mus=
t match.
 
--
James Manger
_______________________________________________
OAuth mailing list
OAuth@ietf.org<=
u>
https://www.ietf.org/mailman/listinfo/oauth

 


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

 

 

 

 

 

 

 

 


____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth
= --Apple-Mail-6106BB0D-EF5B-4DA3-96E4-A2DE7165324A-- From jricher@mitre.org Thu Apr 18 09:26:05 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F11E21F900D for ; Thu, 18 Apr 2013 09:26:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OHkrf9Rq5KnA for ; Thu, 18 Apr 2013 09:26:01 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2981021F9003 for ; Thu, 18 Apr 2013 09:25:57 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id BE80F1F0455; Thu, 18 Apr 2013 12:25:54 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id A8E1C1F0466; Thu, 18 Apr 2013 12:25:54 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.87]) by IMCCAS01.MITRE.ORG ([129.83.29.68]) with mapi id 14.02.0342.003; Thu, 18 Apr 2013 12:25:54 -0400 From: "Richer, Justin P." To: Phil Hunt Thread-Topic: [OAUTH-WG] Registration: Scope Values Thread-Index: AQHOPEqHd6C7VU3yEUySOmKL/JxeopjcZKaAgAACc4CAAAP6gIAAAa4A Date: Thu, 18 Apr 2013 16:25:53 +0000 Message-ID: <2D8F67A0-1190-4234-A836-118C56B4F5AE@mitre.org> References: <255B9BB34FB7D647A506DC292726F6E1150C74DADA@WSMSG3153V.srv.dir.telstra.com> <516C069F.9090308@mitre.org> <516C0B9D.6000402@mitre.org> <516C101F.2090706@mitre.org> <516C1714.8070503@mitre.org> <4E1F6AAD24975D4BA5B168042967394367641A87@TK5EX14MBXC283.redmond.corp.microsoft.com> <516C3152.9070603@mitre.org> <4E1F6AAD24975D4BA5B168042967394367641FAB@TK5EX14MBXC283.redmond.corp.microsoft.com> <516C54F2.8040708@mitre.org> <4E1F6AAD24975D4BA5B16804296739436766BCC4@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739436766C964@TK5EX14MBXC284.redmond.corp.microsoft.com> <8192E67F-A531-4D98-95A1-5103E17812B3@oracle.com> In-Reply-To: <8192E67F-A531-4D98-95A1-5103E17812B3@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.31] Content-Type: multipart/alternative; boundary="_000_2D8F67A011904234A836118C56B4F5AEmitreorg_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Registration: Scope Values X-BeenThere: oauth@ietf.org X-Mailman-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, 18 Apr 2013 16:26:05 -0000 --_000_2D8F67A011904234A836118C56B4F5AEmitreorg_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I agree that we shouldn't try to "solve" scope in registration. I think it = makes the most sense for registration to be as hands-off about scope as cor= e OAuth is. -- Justin On Apr 18, 2013, at 12:18 PM, Phil Hunt > wrote: There are a number of cases that all demand a more parsable scope. One of the cases is multi resource scopes. Would it not be reasonable to develop another draft that defines a simple j= son structure that allows different uris to be matched with specific scope = values? I also wonder if registration is the place to redefine or further define sc= ope. IOW a separate draft can be totally optional. But can be used by multi-reso= urce sites to solve oauth2s limited scope capability. Phil On 2013-04-18, at 9:03, Tim Bray > wrote: I=92m unconvinced, Mike. Obviously you=92re right about the looseness of O= Auth2 scope specification, but this is a very specific semantic of what hap= pens when you register, and I don=92t think we=92re bound by history here. = If we can=92t safely say anything about what the list of scopes means, th= en I'm with you let's take them out. But the most obvious intended semanti= c is (from the client) =93I promise to ask only for these=94 and from the s= erver =93These are the only ones I=92ll give you tokens for.=94 Or does so= meone have use-cases for an alternative semantic? To make this concrete, I propose the following: =93Space-separated list of scope values (as described in OAuth 2.0 Section = 3.3 [RFC6749]) that the cli= ent is declaring to the server that it will restrict itself to when request= ing access tokens, and that the server is declaring to the client that it i= s registered to use when requesting access tokens. Clients SHOULD assume t= hat servers will refuse to grant access tokens for scopes not in the list p= rovided by the server.=94 On Thu, Apr 18, 2013 at 8:55 AM, Mike Jones > wrote: I don=92t think it=92s possible to define what it means in an interoperable= way because OAuth didn=92t specify scopes in an interoperable way. No, I = don=92t like that either, but I think that=92s where things are. That=92s = why I was advocating deleting this registration feature entirely. But understanding it might be useful in some contexts, I=92m OK keeping it,= provided we be clear that the semantics of =93registered to use=94 are ser= vice-specific. -- Mike From: Tim Bray [mailto:twbray@google.com] Sent: Thursday, April 18, 2013 8:36 AM To: Mike Jones Cc: Justin Richer; oauth@ietf.org Subject: Re: [OAUTH-WG] Registration: Scope Values On the server-to-client side, what does =93registered to use=94 mean? Does= it mean that the client should assume that any scopes not on the list WILL= not be granted, MAY not be granted.... or what? Is this already covered e= lsewhere? -T On Thu, Apr 18, 2013 at 8:28 AM, Mike Jones > wrote: Thanks, Justin. I agree with the need for the generic two-sided language. = I=92d still keep this language for scope, because we want to capture the = =93declaring=94 aspect in this case: =93Space separated list of scope values (as described in OAuth 2.0 Section = 3.3 [RFC6749]) that the cli= ent is declaring to the server that it may use when requesting access token= s and that the server is declaring to the client that it is registered to u= se when requesting access tokens.=94. You should probably also reinforce that scope values are service-specific a= nd may not consist only of a static set of string values, and that therefor= e, in some cases, an exhaustive list of registered scope values is not poss= ible. -- Mike From: Justin Richer [mailto:jricher@mitre.org] Sent: Monday, April 15, 2013 12:29 PM To: Mike Jones Cc: Tim Bray; oauth@ietf.org Subject: Re: [OAUTH-WG] Registration: Scope Values I think that because the "declaration" issue affects all parameters in the = list, not just scope, we should adopt this in a higher level paragraph and = leave it out of the individual parameter descriptions. Thus, something like= this inserted as the second paragraph in section 2: The client metadata values serve two parallel purposes in the overall OAuth= Dynamic Registration protocol: - the Client requesting its desired values for each parameter to the Autho= rization Server in a [register] or [update] request, - the Authorization Server informing the Client of the current values of e= ach parameter that the Client has been registered to use through a [client = information response]. An Authorization Server MAY override any value that a Client requests durin= g the registration process (including any omitted values) and replace the r= equested value with a default. The normative indications in the following l= ist apply to the Client's declaration of its desired values. The Authorization Server SHOULD provide documentation for any fields that i= t requires to be filled in by the client or to have particular values or fo= rmats. Extensions and profiles... And then remove the sidedness-language from the scope parameter and any oth= er parameters where it might have crept in inadvertently. -- Justin On 04/15/2013 01:29 PM, Mike Jones wrote: We could fix the one-sided language by changing =93Space separated list of scope values (as described in OAuth 2.0 Section = 3.3 [RFC6749]) that the cli= ent is declaring that it may use when requesting access tokens.=94 to =93Space separated list of scope values (as described in OAuth 2.0 Section = 3.3 [RFC6749]) that the cli= ent is declaring to the server that it may use when requesting access token= s and that the server is declaring to the client that it is registered to u= se when requesting access tokens.=94. Again, I chose the =93registered to use=94 language carefully =96 because i= n the general case it=92s not a restriction on the values that the client c= an use =96 just a statement by the server to the client that it is register= ed to use those particular values. In both cases, the parties are making d= eclarations to one another. If you adopt that language (or keep the original language), then yes, I=92d= consider this closed. -- Mike From: Justin Richer [mailto:jricher@mitre.org] Sent: Monday, April 15, 2013 9:57 AM To: Mike Jones Cc: Tim Bray; oauth@ietf.org Subject: Re: [OAUTH-WG] Registration: Scope Values I absolutely do not want to delete this feature, as (having implemented it)= I think it's very useful. This is a very established pattern in manual reg= istration: I know of many, many OAuth2 servers and clients that are set up = where the client must pre-register a set of scopes. I don't like the language of "the client is declaring" because it's too one= -sided. The client might not have declared anything, and it might be the se= rver that's declaring something to the client. Deleting the "is declaring" = bit removes that unintended restriction of the language while keeping the o= riginal meaning intact. I actually thought that I had fixed that before the= last draft went in but apparently I missed this one. I will work on clarifying the intent of the whole metadata set in its intro= ductory paragraph(s) so that it's clear that all of these fields are used i= n both of these situations: 1) The client declaring to the server its desire to use a particular value 2) The server declaring to the client that it has been registered with a p= articular value This should hopefully clear up the issue in the editor's note that I curren= tly have at the top of that section right now, too. Mike, since you were the one who originally brought up the issue, and you'r= e fine with the existing text, can I take this as closed now? Assuming that= you agree with deleting "is declaring" for reasons stated above, I'm fine = with leaving everything else as is and staying quiet on what the server has= to do with the scopes. -- Justin On 04/15/2013 12:44 PM, Mike Jones wrote: I think that the existing wording is superior to the proposed changed wordi= ng. The existing wording is: scope OPTIONAL. Space separated list of scope values (as described in OAuth 2.0 Section 3.3 [RFC6749]) that the client is declaring that it may use when requesting access tokens. If omitted, an Authorization Server MAY register a Client with a default set of scopes. For instance, the current =93client is declaring=94 wording will always be = correct, whereas as the change to =93client can use=94 wording implies a re= striction on client behavior that is not always applicable. The =93client = is declaring=94 wording was specific and purposefully chosen, and I think s= hould be retained. In particular, we can=92t do anything that implies that= only the registered scopes values can be used. At the OAuth spec level, t= his is a hint as to possible future client behavior =96 not a restriction o= n future client behavior. Also, for the reasons that Tim stated, I=92m strongly against any =93matchi= ng=94 or =93regex=94 language in the spec pertaining to scopes =96 as it=92= s not actionable. So I=92d propose that we leave the existing scope wording in place. Altern= atively, I=92d also be fine with deleting this feature entirely, as I don= =92t think it=92s useful in the general case. -- Mike From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Justin Richer Sent: Monday, April 15, 2013 8:05 AM To: Tim Bray; oauth@ietf.org Subject: Re: [OAUTH-WG] Registration: Scope Values On 04/15/2013 10:52 AM, Tim Bray wrote: I=92d use the existing wording; it=92s perfectly clear. Failing that, if t= here=92s strong demand for registration of structured scopes, bless the use= of regexes, either PCREs or some careful subset. Thanks for the feedback -- Of these two choices, I'd rather leave it as-is. However, I=92d subtract the sentence =93If omitted, an Authorization Server= MAY register a Client with a default set of scopes.=94 It adds no value;= if the client doesn=92t declare scopes, the client doesn=92t declare scope= s, that=92s all. -T Remember, all of these fields aren't just for the client *request*, they're= also for the server's *response* to either a POST, PUT, or GET request. (I= didn't realize it, but perhaps the wording as stated right now doesn't mak= e that clear -- I need to fix that.) The value that it adds is if the clien= t doesn't ask for any particular scopes, the server can still assign it sco= pes and the client can do something smart with that. Dumb clients are allow= ed to ignore it if it doesn't mean anything to them. This is how our server implementation actually works right now. If the clie= nt doesn't ask for anything specific at registration, the server hands it a= bag of "default" scopes. Same thing happens at auth time -- if the client = doesn't ask for any particular scopes, the server hands it all of its regis= tered scopes as a default. Granted, on our server, scopes are just simple s= trings right now, so they get compared at the auth endpoint with an exact s= tring-match metric and set-based logic. -- Justin On Mon, Apr 15, 2013 at 7:35 AM, Justin Richer > wrote: What would you suggest for wording here, then? Keeping in mind that we cann= ot (and don't want to) prohibit expression-based scopes. -- Justin On 04/15/2013 10:33 AM, Tim Bray wrote: No, I mean it=92s not interoperable at the software-developer level. I can= =92t register scopes at authorization time with any predictable effect that= I can write code to support, either client or server side, without out-of-= line non-interoperable knowledge about the behavior of the server. I guess I=92m just not used to OAuth=92s culture of having no expectation t= hat things will be specified tightly enough that I can write code to implem= ent as specified. -T On Mon, Apr 15, 2013 at 7:15 AM, Justin Richer > wrote: Scopes aren't meant to be interoperable between services since they're nece= ssarily API-specific. The only interoperable bit is that there's *some* pla= ce to put the values and that it's expressed as a bag of space-separated st= rings. How those strings get interpreted and enforced (which is really what= 's at stake here) is up to the AS and PR (or a higher-level protocol like U= MA). -- Justin On 04/15/2013 10:13 AM, Tim Bray wrote: This, as written, has zero interoperability. I think this feature can real= ly only be made useful in the case where scopes are fixed strings. -T On Apr 15, 2013 6:54 AM, "Justin Richer" > wrote: You are correct that the idea behind the "scope" parameter at registration = is a constraint on authorization-time scopes that are made available. It's = both a means for the client to request a set of valid scopes and for the se= rver to provision (and echo back to the client) a set of valid scopes. I *really* don't want to try to define a matching language for scope expres= sions. For that to work, all servers would need to be able to process the r= egular expressions for all clients, even if the servers themselves only sup= port simple-string scope values. Any regular expression syntax we pick here= is guaranteed to be incompatible with something, and I think the complexit= y doesn't buy much. Also, I think you suddenly have a potential security is= sue if you have a bad regex in place on either end. As it stands today, the server can interpret the incoming registration scop= es and enforce them however it wants to. The real trick comes not from assi= gning the values to a particular client but to enforcing them, and I think = that's always going to be service-specific. We're just not as clear on that= as we could be. After looking over everyone's comments so far, I'd like to propose the foll= owing text for that section: scope OPTIONAL. Space separated list of scope values (as described in OAuth 2.0 Section 3.3 [RFC6749]) that the client can use when requesting access tokens. As scope values are service-specific, the Authorization Server MAY define its own matching rules when determining if a scope value used during an authorization request is valid according to the scope values assigned during registration. Possible matching rules include wildcard patterns, regular expressions, or exactly matching the string. If omitted, an Authorization Server MAY register a Client with a default set of scopes. Comments? Improvements? -- Justin On 04/14/2013 08:23 PM, Manger, James H wrote: Presumably at app registration time any scope specification is really a con= straint on the scope values that can be requested in an authorization flow. So ideally registration should accept rules for matching scopes, as opposed= to actual scope values. You can try to use scope values as their own matching rules. That is fine f= or a small set of "static" scopes. It starts to fail when there are a large= number of scopes, or scopes that can include parameters (resource paths? e= mail addresses?). You can try to patch those failures by allowing services = to define service-specific special "wildcard" scope values that can only be= used during registration (eg "read:*"). Alternatively, replace 'scope' in registration with 'scope_regex' that hold= s a regular expression that all scope values in an authorization flow must = match. -- James Manger _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_2D8F67A011904234A836118C56B4F5AEmitreorg_ Content-Type: text/html; charset="Windows-1252" Content-ID: <5F77B3DC81C49346911EB2C5492E3FF0@imc.mitre.org> Content-Transfer-Encoding: quoted-printable I agree that we shouldn't try to "solve" scope in registration. I= think it makes the most sense for registration to be as hands-off about sc= ope as core OAuth is. 

 -- Justin

On Apr 18, 2013, at 12:18 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

There are a number of cases that all demand a more parsable scope.&nbs= p;

One of the cases is multi resource scopes. 

Would it not be reasonable to develop another draft that defines a sim= ple json structure that allows different uris to be matched with specific s= cope values?

I also wonder if registration is the place to redefine or further defi= ne scope. 

IOW a separate draft can be totally optional. But can be used by multi= -resource sites to solve oauth2s limited scope capability. 

Phil

On 2013-04-18, at 9:03, Tim Bray <t= wbray@google.com> wrote:

I=92m unconvinced, Mike.  Obviously you=92re right ab= out the looseness of OAuth2 scope specification, but this is a very specifi= c semantic of what happens when you register, and I don=92t think we=92re b= ound by history here.   If we can=92t safely say anything about what the list of scopes means, then I'm with you let's take= them out.  But the most obvious intended semantic is (from the client= ) =93I promise to ask only for these=94 and from the server =93These are th= e only ones I=92ll give you tokens for.=94  Or does someone have use-cases for an alternative semantic?

To make this concrete, I propose the following:

=93Space-separated list of scope values (as described in OAuth 2= .0 Section 3.3 [RFC6749]) that the client is declaring to the server that it will res= trict itself to when requesting access tokens, and that the server is decla= ring to the client that it is registered to use when requesting access toke= ns.  Clients SHOULD assume that servers will refuse to grant access tokens for scopes n= ot in the list provided by the server.=94




On Thu, Apr 18, 2013 at 8:55 AM, Mike Jones <Michae= l.Jones@microsoft.com> wrote:

I don=92t think it=92s po= ssible to define what it means in an interoperable way because OAuth didn= =92t specify scopes in an interoperable way.  No, I don=92t like that either, but I think that=92s where things are.  That=92s why I was ad= vocating deleting this registration feature entirely.<= /p>

 

But understanding it migh= t be useful in some contexts, I=92m OK keeping it, provided we be clear tha= t the semantics of =93registered to use=94 are service-specific.<= /u>

 

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

 

From: Tim Bray= [mailto:twbray@goog= le.com]
Sent: Thursday, April 18, 2013 8:36 AM
To: Mike Jones
Cc: Justin Richer; oauth@ietf.org


Subject: Re: [OAUTH-WG] Registration: Scope Values

 

On the server-to-client side, what does =93registere= d to use=94 mean?  Does it mean that the client should assume that any= scopes not on the list WILL not be granted, MAY not be granted.... or what= ?  Is this already covered elsewhere? -T

 <= /p>

On Thu, Apr 18, 2013 at 8:28 AM, Mike Jones <Michael.Jones@= microsoft.com> wrote:

Thanks, Justin.  I a= gree with the need for the generic two-sided language.  I=92d still ke= ep this language for scope, because we want to capture the =93declaring=94 aspect in this case:

 

Space separated list of scope values (as described in OAuth 2.0 Section 3.3 [RFC6749]) that the client is declaring to the serve= r that it may use when requesting access tokens and that the server is decl= aring to the client that it is registered to use when requesting access tokens.=94= .

 

You should probably also = reinforce that scope values are service-specific and may not consist only o= f a static set of string values, and that therefore, in some cases, an exhaustive list of registered scope values is not possible.=

 

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

 

From: Justin R= icher [mailto:jriche= r@mitre.org]
Sent: Monday, April 15, 2013 12:29 PM


To: Mike Jones
Cc: Tim Bray; oa= uth@ietf.org
Subject: Re: [OAUTH-WG] Registration: Scope Values

 

I think that because = the "declaration" issue affects all parameters in the list, not j= ust scope, we should adopt this in a higher level paragraph and leave it ou= t of the individual parameter descriptions. Thus, something like this inserted as the second paragraph in section 2:<= u>

The client metadata values serve two parallel purpos= es in the overall OAuth Dynamic Registration protocol:

 - the Client requesting its desired values for each parameter to the = Authorization Server in a [register] or [update] request,
 - the Authorization Server informing the Client of the current values= of each parameter that the Client has been registered to use through a [cl= ient information response].

An Authorization Server MAY override any value that a Client requests durin= g the registration process (including any omitted values) and replace the r= equested value with a default. The normative indications in the following l= ist apply to the Client's declaration of its desired values.

The Authorization Server SHOULD provide documentation for any fields that i= t requires to be filled in by the client or to have particular values or fo= rmats. Extensions and profiles...


And then remove the sidedness-language from the scope parameter and any oth= er parameters where it might have crept in inadvertently.

 -- Justin

On 04/15/2013 01:29 PM, Mike Jones wrote:<= /u>

We could fix the one-side= d language by changing

Space separated list of scope values (as described in OAuth 2.0 Section 3.3 [RFC6749]) that the client is declaring that it may = use when requesting access tokens.=94

to

Space separated list of scope values (as described in OAuth 2.0 Section 3.3 [RFC6749]) that the client is declaring to the serve= r that it may use when requesting access tokens and that the server is decl= aring to the client that it is registered to use when requesting access tokens.=94= .

 

Again, I chose the =93reg= istered to use=94 language carefully =96 because in the general case it=92s= not a restriction on the values that the client can use =96 just a statement by the server to the client that it is registered to use those= particular values.  In both cases, the parties are making declaration= s to one another.

 

If you adopt that languag= e (or keep the original language), then yes, I=92d consider this closed.

 

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

 

From: Justin R= icher [mailto:jriche= r@mitre.org]
Sent: Monday, April 15, 2013 9:57 AM
To: Mike Jones
Cc: Tim Bray; oa= uth@ietf.org
Subject: Re: [OAUTH-WG] Registration: Scope Values<= /u>

 

I absolutely do not w= ant to delete this feature, as (having implemented it) I think it's very us= eful. This is a very established pattern in manual registration: I know of = many, many OAuth2 servers and clients that are set up where the client must pre-register a set of scopes.

I don't like the language of "the client is declaring" because it= 's too one-sided. The client might not have declared anything, and it might= be the server that's declaring something to the client. Deleting the "= ;is declaring" bit removes that unintended restriction of the language while keeping the original meaning intact. I actually thou= ght that I had fixed that before the last draft went in but apparently I mi= ssed this one.

I will work on clarifying the intent of the whole metadata set in its intro= ductory paragraph(s) so that it's clear that all of these fields are used i= n both of these situations:

 1) The client declaring to the server its desire to use a particular = value
 2) The server declaring to the client that it has been registered wit= h a particular value

This should hopefully clear up the issue in the editor's note that I curren= tly have at the top of that section right now, too.

Mike, since you were the one who originally brought up the issue, and you'r= e fine with the existing text, can I take this as closed now? Assuming that= you agree with deleting "is declaring" for reasons stated above,= I'm fine with leaving everything else as is and staying quiet on what the server has to do with the scopes.

 -- Justin

On 04/15/2013 12:44 PM, Mike Jones wrote:<= /u>

I think that the existing= wording is superior to the proposed changed wording.  The existing wo= rding is:

 

   scope

    &nb= sp; OPTIONAL.  Space separated list of scope values (as described in

    &nb= sp; OAuth 2.0 Section 3.3 [RFC6749]) that the client is declaring that<= u>

    &nb= sp; it may use when requesting access tokens.  If omitted, an

    &nb= sp; Authorization Server MAY register a Client with a default set of=

    &nb= sp; scopes.

 

For instance, the current= =93client is declaring=94 wording will always be correct, whereas as the c= hange to =93client can use=94 wording implies a restriction on client behavior that is not always applicable.  The =93client is declaring= =94 wording was specific and purposefully chosen, and I think should be ret= ained.  In particular, we can=92t do anything that implies that only t= he registered scopes values can be used.  At the OAuth spec level, this is a hint as to possible future client behavior =96 not a= restriction on future client behavior.

 

Also, for the reasons tha= t Tim stated, I=92m strongly against any =93matching=94 or =93regex=94 lang= uage in the spec pertaining to scopes =96 as it=92s not actionable.<= u>

 

So I=92d propose that we = leave the existing scope wording in place.  Alternatively, I=92d also = be fine with deleting this feature entirely, as I don=92t think it=92s useful in the general case.

 

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

 

From: oauth-bounces@i= etf.org [ma= ilto:oauth-bounces@ietf.org] On Behalf Of Justin Richer
Sent: Monday, April 15, 2013 8:05 AM
To: Tim Bray; oa= uth@ietf.org
Subject: Re: [OAUTH-WG] Registration: Scope Values<= /u>

 

On 04/15/2013 10:52 A= M, Tim Bray wrote:


I=92d use the existing wording; it=92s perfectly cle= ar.  Failing that, if there=92s strong demand for registration of stru= ctured scopes, bless the use of regexes, either PCREs or some careful subse= t.


Thanks for the feedback -- Of these two choices, I'd rather leave it as-is.=



 

However, I=92d subtract the sentence =93If omitted, = an Authorization Server MAY register a Client with a default set of  s= copes.=94  It adds no value; if the client doesn=92t declare scopes, t= he client doesn=92t declare scopes, that=92s all.  -T


Remember, all of these fields aren't just for the client *request*, they're= also for the server's *response* to either a POST, PUT, or GET request. (I= didn't realize it, but perhaps the wording as stated right now doesn't mak= e that clear -- I need to fix that.) The value that it adds is if the client doesn't ask for any particular sco= pes, the server can still assign it scopes and the client can do something = smart with that. Dumb clients are allowed to ignore it if it doesn't mean a= nything to them.

This is how our server implementation actually works right now. If the clie= nt doesn't ask for anything specific at registration, the server hands it a= bag of "default" scopes. Same thing happens at auth time -- if t= he client doesn't ask for any particular scopes, the server hands it all of its registered scopes as a default. Granted, on= our server, scopes are just simple strings right now, so they get compared= at the auth endpoint with an exact string-match metric and set-based logic= .

 -- Justin



 <= /p>

On Mon, Apr 15, 2013 at 7:35 AM, Justin Richer <<= a href=3D"mailto:jricher@mitre.org" target=3D"_blank">jricher@mitre.org= > wrote:

What would you suggest for wording here, then? Keepi= ng in mind that we cannot (and don't want to) prohibit expression-based sco= pes.

 -- Justin

 <= /p>

On 04/15/2013 10:33 AM, Tim Bray wrote:

No, I mean it=92s not interoperable at the software-= developer level.  I can=92t register scopes at authorization time with= any predictable effect that I can write code to support, either client or = server side, without out-of-line non-interoperable knowledge about the behavior of the server.  

 

I guess I=92m just not used to OAuth=92s culture of = having no expectation that things will be specified tightly enough that I c= an write code to implement as specified.  -T

 <= /p>

On Mon, Apr 15, 2013 at 7:15 AM, Justin Richer <<= a href=3D"mailto:jricher@mitre.org" target=3D"_blank">jricher@mitre.org= > wrote:

Scopes aren't meant to be interoperable between serv= ices since they're necessarily API-specific. The only interoperable bit is = that there's *some* place to put the values and that it's expressed as a ba= g of space-separated strings. How those strings get interpreted and enforced (which is really what's at stak= e here) is up to the AS and PR (or a higher-level protocol like UMA).

 -- Justin

 <= /p>

On 04/15/2013 10:13 AM, Tim Bray wrote:

This, as written, has zero interoperability.  I think this feature = can really only be made useful in the case where scopes are fixed strings.<= u>

-T

On Apr 15, 2013 6:54 AM, "Justin Richer" &= lt;jricher@mitre.org= > wrote:

You are correct that = the idea behind the "scope" parameter at registration is a constr= aint on authorization-time scopes that are made available. It's both a mean= s for the client to request a set of valid scopes and for the server to provision (and echo back to the client) a set of val= id scopes.

I *really* don't want to try to define a matching language for scope expres= sions. For that to work, all servers would need to be able to process the r= egular expressions for all clients, even if the servers themselves only sup= port simple-string scope values. Any regular expression syntax we pick here is guaranteed to be incompatibl= e with something, and I think the complexity doesn't buy much. Also, I thin= k you suddenly have a potential security issue if you have a bad regex in p= lace on either end.

As it stands today, the server can interpret the incoming registration scop= es and enforce them however it wants to. The real trick comes not from assi= gning the values to a particular client but to enforcing them, and I think = that's always going to be service-specific. We're just not as clear on that as we could be.

After looking over everyone's comments so far, I'd like to propose the foll= owing text for that section:


   scope
      OPTIONAL.  Space separated list of=
 scope values (as described in
      OAuth 2.0 Section 3.3 [RFC6749]<=
/a>) that the client can use when 
      requesting access tokens.  As=
 scope values are service-specific, 
      the Authorization Server MAY defin=
e its own matching rules when
      determining if a scope value used durin=
g an authorization request
      is valid according to the scope values =
assigned during 
      registration. Possible matching ru=
les include wildcard patterns,
      regular expressions, or exactly matchin=
g the string. If omitted, 
      an Authorization Server MAY regist=
er a Client with a default 
      set of scopes.


Comments? Improvements?

 -- Justin


On 04/14/2013 08:23 PM, Manger, James H wrote:

Presumably at app registration time any scope specification is really =
a constraint on the scope values that can be requested in an authorization =
flow.
 
So ideally registration should accept rules for matching scopes, as op=
posed to actual scope values.
 
You can try to use scope values as their own matching rules. That is f=
ine for a small set of "static" scopes. It starts to fail when th=
ere are a large number of scopes, or scopes that can include parameters (re=
source paths? email addresses?). You can try to patch those failures by all=
owing services to define service-specific special "wildcard" scop=
e values that can only be used during registration (eg "read:*").=

 
Alternatively, replace 'scope' in registration with 'scope_regex' that=
 holds a regular expression that all scope values in an authorization flow =
must match.
 
--
James Manger
_______________________________________________
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
https://www.i= etf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--_000_2D8F67A011904234A836118C56B4F5AEmitreorg_-- From jricher@mitre.org Thu Apr 18 09:26:05 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2761821F9021 for ; Thu, 18 Apr 2013 09:26:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SgLk+BUOiXyr for ; Thu, 18 Apr 2013 09:26:02 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 297AF21F8FE8 for ; Thu, 18 Apr 2013 09:25:57 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A2BC11F041B; Thu, 18 Apr 2013 12:25:54 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 86E311F04B9; Thu, 18 Apr 2013 12:25:54 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.87]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.02.0342.003; Thu, 18 Apr 2013 12:25:54 -0400 From: "Richer, Justin P." To: Anthony Nadalin Thread-Topic: [OAUTH-WG] Registration: Scope Values Thread-Index: AQHOPEqHd6C7VU3yEUySOmKL/JxeopjcZKaAgAACc4CAAALDAIAAAquA Date: Thu, 18 Apr 2013 16:25:53 +0000 Message-ID: References: <255B9BB34FB7D647A506DC292726F6E1150C74DADA@WSMSG3153V.srv.dir.telstra.com> <516C069F.9090308@mitre.org> <516C0B9D.6000402@mitre.org> <516C101F.2090706@mitre.org> <516C1714.8070503@mitre.org> <4E1F6AAD24975D4BA5B168042967394367641A87@TK5EX14MBXC283.redmond.corp.microsoft.com> <516C3152.9070603@mitre.org> <4E1F6AAD24975D4BA5B168042967394367641FAB@TK5EX14MBXC283.redmond.corp.microsoft.com> <516C54F2.8040708@mitre.org> <4E1F6AAD24975D4BA5B16804296739436766BCC4@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739436766C964@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: [172.31.20.31] Content-Type: multipart/alternative; boundary="_000_DE8865A9465647B28315FDC1585CEDABmitreorg_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Registration: Scope Values X-BeenThere: oauth@ietf.org X-Mailman-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, 18 Apr 2013 16:26:05 -0000 --_000_DE8865A9465647B28315FDC1585CEDABmitreorg_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable This doesn't actually break the semantics because the client MUST accept wh= at the server tells it over anything that it asks for in the first place. T= he server has the final say. So in this case, if your client asks for nothi= ng, the server says "A B C", the client now knows it can ask for "A B C" sc= opes. I'm still in favor of not putting the restricting language in the scope def= inition at all, instead have it say something like: =93Space-separated list of scope values (as described in OAuth 2.0 Section = 3.3 [RFC6749]) that the Cli= ent can use when requesting access tokens from the Authorization Server. As= scope values are service specific, the means of the Authorization Server e= nforcing this restriction are outside the scope of this specification.=94 Couple this with the overall paragraph that says that the client is request= ing values that the server is potentially overriding with its declarations,= and I think that addresses everything without getting into confusing langu= age that doesn't add to interoperability. -- Justin On Apr 18, 2013, at 12:13 PM, Anthony Nadalin > wrote: If I don=92t specify a scope, then the server can allocate a default (or de= fault set), thus that breaks the semantics you describe From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Tim Bray Sent: Thursday, April 18, 2013 9:04 AM To: Mike Jones Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Registration: Scope Values I=92m unconvinced, Mike. Obviously you=92re right about the looseness of O= Auth2 scope specification, but this is a very specific semantic of what hap= pens when you register, and I don=92t think we=92re bound by history here. = If we can=92t safely say anything about what the list of scopes means, th= en I'm with you let's take them out. But the most obvious intended semanti= c is (from the client) =93I promise to ask only for these=94 and from the s= erver =93These are the only ones I=92ll give you tokens for.=94 Or does so= meone have use-cases for an alternative semantic? To make this concrete, I propose the following: =93Space-separated list of scope values (as described in OAuth 2.0 Section = 3.3 [RFC6749]) that the cli= ent is declaring to the server that it will restrict itself to when request= ing access tokens, and that the server is declaring to the client that it i= s registered to use when requesting access tokens. Clients SHOULD assume t= hat servers will refuse to grant access tokens for scopes not in the list p= rovided by the server.=94 On Thu, Apr 18, 2013 at 8:55 AM, Mike Jones > wrote: I don=92t think it=92s possible to define what it means in an interoperable= way because OAuth didn=92t specify scopes in an interoperable way. No, I = don=92t like that either, but I think that=92s where things are. That=92s = why I was advocating deleting this registration feature entirely. But understanding it might be useful in some contexts, I=92m OK keeping it,= provided we be clear that the semantics of =93registered to use=94 are ser= vice-specific. -- Mike From: Tim Bray [mailto:twbray@google.com] Sent: Thursday, April 18, 2013 8:36 AM To: Mike Jones Cc: Justin Richer; oauth@ietf.org Subject: Re: [OAUTH-WG] Registration: Scope Values On the server-to-client side, what does =93registered to use=94 mean? Does= it mean that the client should assume that any scopes not on the list WILL= not be granted, MAY not be granted.... or what? Is this already covered e= lsewhere? -T On Thu, Apr 18, 2013 at 8:28 AM, Mike Jones > wrote: Thanks, Justin. I agree with the need for the generic two-sided language. = I=92d still keep this language for scope, because we want to capture the = =93declaring=94 aspect in this case: =93Space separated list of scope values (as described in OAuth 2.0 Section = 3.3 [RFC6749]) that the cli= ent is declaring to the server that it may use when requesting access token= s and that the server is declaring to the client that it is registered to u= se when requesting access tokens.=94. You should probably also reinforce that scope values are service-specific a= nd may not consist only of a static set of string values, and that therefor= e, in some cases, an exhaustive list of registered scope values is not poss= ible. -- Mike From: Justin Richer [mailto:jricher@mitre.org] Sent: Monday, April 15, 2013 12:29 PM To: Mike Jones Cc: Tim Bray; oauth@ietf.org Subject: Re: [OAUTH-WG] Registration: Scope Values I think that because the "declaration" issue affects all parameters in the = list, not just scope, we should adopt this in a higher level paragraph and = leave it out of the individual parameter descriptions. Thus, something like= this inserted as the second paragraph in section 2: The client metadata values serve two parallel purposes in the overall OAuth= Dynamic Registration protocol: - the Client requesting its desired values for each parameter to the Autho= rization Server in a [register] or [update] request, - the Authorization Server informing the Client of the current values of e= ach parameter that the Client has been registered to use through a [client = information response]. An Authorization Server MAY override any value that a Client requests durin= g the registration process (including any omitted values) and replace the r= equested value with a default. The normative indications in the following l= ist apply to the Client's declaration of its desired values. The Authorization Server SHOULD provide documentation for any fields that i= t requires to be filled in by the client or to have particular values or fo= rmats. Extensions and profiles... And then remove the sidedness-language from the scope parameter and any oth= er parameters where it might have crept in inadvertently. -- Justin On 04/15/2013 01:29 PM, Mike Jones wrote: We could fix the one-sided language by changing =93Space separated list of scope values (as described in OAuth 2.0 Section = 3.3 [RFC6749]) that the cli= ent is declaring that it may use when requesting access tokens.=94 to =93Space separated list of scope values (as described in OAuth 2.0 Section = 3.3 [RFC6749]) that the cli= ent is declaring to the server that it may use when requesting access token= s and that the server is declaring to the client that it is registered to u= se when requesting access tokens.=94. Again, I chose the =93registered to use=94 language carefully =96 because i= n the general case it=92s not a restriction on the values that the client c= an use =96 just a statement by the server to the client that it is register= ed to use those particular values. In both cases, the parties are making d= eclarations to one another. If you adopt that language (or keep the original language), then yes, I=92d= consider this closed. -- Mike From: Justin Richer [mailto:jricher@mitre.org] Sent: Monday, April 15, 2013 9:57 AM To: Mike Jones Cc: Tim Bray; oauth@ietf.org Subject: Re: [OAUTH-WG] Registration: Scope Values I absolutely do not want to delete this feature, as (having implemented it)= I think it's very useful. This is a very established pattern in manual reg= istration: I know of many, many OAuth2 servers and clients that are set up = where the client must pre-register a set of scopes. I don't like the language of "the client is declaring" because it's too one= -sided. The client might not have declared anything, and it might be the se= rver that's declaring something to the client. Deleting the "is declaring" = bit removes that unintended restriction of the language while keeping the o= riginal meaning intact. I actually thought that I had fixed that before the= last draft went in but apparently I missed this one. I will work on clarifying the intent of the whole metadata set in its intro= ductory paragraph(s) so that it's clear that all of these fields are used i= n both of these situations: 1) The client declaring to the server its desire to use a particular value 2) The server declaring to the client that it has been registered with a p= articular value This should hopefully clear up the issue in the editor's note that I curren= tly have at the top of that section right now, too. Mike, since you were the one who originally brought up the issue, and you'r= e fine with the existing text, can I take this as closed now? Assuming that= you agree with deleting "is declaring" for reasons stated above, I'm fine = with leaving everything else as is and staying quiet on what the server has= to do with the scopes. -- Justin On 04/15/2013 12:44 PM, Mike Jones wrote: I think that the existing wording is superior to the proposed changed wordi= ng. The existing wording is: scope OPTIONAL. Space separated list of scope values (as described in OAuth 2.0 Section 3.3 [RFC6749]) that the client is declaring that it may use when requesting access tokens. If omitted, an Authorization Server MAY register a Client with a default set of scopes. For instance, the current =93client is declaring=94 wording will always be = correct, whereas as the change to =93client can use=94 wording implies a re= striction on client behavior that is not always applicable. The =93client = is declaring=94 wording was specific and purposefully chosen, and I think s= hould be retained. In particular, we can=92t do anything that implies that= only the registered scopes values can be used. At the OAuth spec level, t= his is a hint as to possible future client behavior =96 not a restriction o= n future client behavior. Also, for the reasons that Tim stated, I=92m strongly against any =93matchi= ng=94 or =93regex=94 language in the spec pertaining to scopes =96 as it=92= s not actionable. So I=92d propose that we leave the existing scope wording in place. Altern= atively, I=92d also be fine with deleting this feature entirely, as I don= =92t think it=92s useful in the general case. -- Mike From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org]On Behalf Of Justin Richer Sent: Monday, April 15, 2013 8:05 AM To: Tim Bray; oauth@ietf.org Subject: Re: [OAUTH-WG] Registration: Scope Values On 04/15/2013 10:52 AM, Tim Bray wrote: I=92d use the existing wording; it=92s perfectly clear. Failing that, if t= here=92s strong demand for registration of structured scopes, bless the use= of regexes, either PCREs or some careful subset. Thanks for the feedback -- Of these two choices, I'd rather leave it as-is. However, I=92d subtract the sentence =93If omitted, an Authorization Server= MAY register a Client with a default set of scopes.=94 It adds no value;= if the client doesn=92t declare scopes, the client doesn=92t declare scope= s, that=92s all. -T Remember, all of these fields aren't just for the client *request*, they're= also for the server's *response* to either a POST, PUT, or GET request. (I= didn't realize it, but perhaps the wording as stated right now doesn't mak= e that clear -- I need to fix that.) The value that it adds is if the clien= t doesn't ask for any particular scopes, the server can still assign it sco= pes and the client can do something smart with that. Dumb clients are allow= ed to ignore it if it doesn't mean anything to them. This is how our server implementation actually works right now. If the clie= nt doesn't ask for anything specific at registration, the server hands it a= bag of "default" scopes. Same thing happens at auth time -- if the client = doesn't ask for any particular scopes, the server hands it all of its regis= tered scopes as a default. Granted, on our server, scopes are just simple s= trings right now, so they get compared at the auth endpoint with an exact s= tring-match metric and set-based logic. -- Justin On Mon, Apr 15, 2013 at 7:35 AM, Justin Richer > wrote: What would you suggest for wording here, then? Keeping in mind that we cann= ot (and don't want to) prohibit expression-based scopes. -- Justin On 04/15/2013 10:33 AM, Tim Bray wrote: No, I mean it=92s not interoperable at the software-developer level. I can= =92t register scopes at authorization time with any predictable effect that= I can write code to support, either client or server side, without out-of-= line non-interoperable knowledge about the behavior of the server. I guess I=92m just not used to OAuth=92s culture of having no expectation t= hat things will be specified tightly enough that I can write code to implem= ent as specified. -T On Mon, Apr 15, 2013 at 7:15 AM, Justin Richer > wrote: Scopes aren't meant to be interoperable between services since they're nece= ssarily API-specific. The only interoperable bit is that there's *some* pla= ce to put the values and that it's expressed as a bag of space-separated st= rings. How those strings get interpreted and enforced (which is really what= 's at stake here) is up to the AS and PR (or a higher-level protocol like U= MA). -- Justin On 04/15/2013 10:13 AM, Tim Bray wrote: This, as written, has zero interoperability. I think this feature can real= ly only be made useful in the case where scopes are fixed strings. -T On Apr 15, 2013 6:54 AM, "Justin Richer" > wrote: You are correct that the idea behind the "scope" parameter at registration = is a constraint on authorization-time scopes that are made available. It's = both a means for the client to request a set of valid scopes and for the se= rver to provision (and echo back to the client) a set of valid scopes. I *really* don't want to try to define a matching language for scope expres= sions. For that to work, all servers would need to be able to process the r= egular expressions for all clients, even if the servers themselves only sup= port simple-string scope values. Any regular expression syntax we pick here= is guaranteed to be incompatible with something, and I think the complexit= y doesn't buy much. Also, I think you suddenly have a potential security is= sue if you have a bad regex in place on either end. As it stands today, the server can interpret the incoming registration scop= es and enforce them however it wants to. The real trick comes not from assi= gning the values to a particular client but to enforcing them, and I think = that's always going to be service-specific. We're just not as clear on that= as we could be. After looking over everyone's comments so far, I'd like to propose the foll= owing text for that section: scope OPTIONAL. Space separated list of scope values (as described in OAuth 2.0 Section 3.3 [RFC6749]) that the client can use when requesting access tokens. As scope values are service-specific, the Authorization Server MAY define its own matching rules when determining if a scope value used during an authorization request is valid according to the scope values assigned during registration. Possible matching rules include wildcard patterns, regular expressions, or exactly matching the string. If omitted, an Authorization Server MAY register a Client with a default set of scopes. Comments? Improvements? -- Justin On 04/14/2013 08:23 PM, Manger, James H wrote: Presumably at app registration time any scope specification is really a con= straint on the scope values that can be requested in an authorization flow. So ideally registration should accept rules for matching scopes, as opposed= to actual scope values. You can try to use scope values as their own matching rules. That is fine f= or a small set of "static" scopes. It starts to fail when there are a large= number of scopes, or scopes that can include parameters (resource paths? e= mail addresses?). You can try to patch those failures by allowing services = to define service-specific special "wildcard" scope values that can only be= used during registration (eg "read:*"). Alternatively, replace 'scope' in registration with 'scope_regex' that hold= s a regular expression that all scope values in an authorization flow must = match. -- James Manger _______________________________________________ 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_DE8865A9465647B28315FDC1585CEDABmitreorg_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
This doesn't actually break the semantics because the client MUST acce= pt what the server tells it over anything that it asks for in the first pla= ce. The server has the final say. So in this case, if your client asks for = nothing, the server says "A B C", the client now knows it can ask for "A B C" scopes. 

I'm still in favor of not putting the restricting language in the scop= e definition at all, instead have it say something like:

=93Space-separated list of scope values (as describ= ed in OAuth 2.0 Section 3.3 [RFC6749]) that the Client can use when requesting access tokens from = the Authorization Server. As scope values are service specific, the means o= f the Authorization Server enforcing this restriction are outside the scope= of this specification.=94

Couple this with the overall paragraph that says that the client is re= questing values that the server is potentially overriding with its declarat= ions, and I think that addresses everything without getting into confusing = language that doesn't add to interoperability. 

 -- Justin

On Apr 18, 2013, at 12:13 PM, Anthony Nadalin <tonynad@microsoft.com> wrote:

If I don=92t specify a scope, then the server can allocat= e a default (or default set), thus that breaks the semantics you describe
From= : oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Tim Bray
Sent: Thursday, Ap= ril 18, 2013 9:04 AM
To: Mike Jones
Cc: oauth@ietf.org
Subject: Re: [OAUT= H-WG] Registration: Scope Values
 
I=92m unconvinced, Mike.  Obviously you=92re right about the looseness= of OAuth2 scope specification, but this is a very specific semantic of wha= t happens when you register, and I don=92t think we=92re bound by history h= ere.   If we can=92t safely say anything about what the list of scopes means, then I'm with you let's take them out. &nbs= p;But the most obvious intended semantic is (from the client) =93I promise = to ask only for these=94 and from the server =93These are the only ones I= =92ll give you tokens for.=94  Or does someone have use-cases for an alternative semantic?
 
To make this concrete, I propose the following:

 

On Thu, Apr 18, 2013 at 8:55 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:
I don=92t think it=92s possible to define what it means i= n an interoperable way because OAuth didn=92t specify scopes in an interope= rable way.  No, I don=92t like that either, but I think that=92s where things are.  That=92s why I was advocating= deleting this registration feature entirely.
 
But understanding it might be useful in some contexts, I= =92m OK keeping it, provided we be clear that the semantics of =93registere= d to use=94 are service-specific.
 
         &nb= sp;            =             &nb= sp;            =              --= Mike
 
From:=  Tim Bray [mailto:twbray@google.com] 
Sent: Thursday, Ap= ril 18, 2013 8:36 AM
To: Mike Jones
Cc: Justin Richer;=  oauth@ietf.org

Subject: Re: [OAUT= H-WG] Registration: Scope Values
 
On the server-to-client side, what does =93registered to use=94 mean?  = ;Does it mean that the client should assume that any scopes not on the list= WILL not be granted, MAY not be granted.... or what?  Is this already= covered elsewhere? -T

 

On Thu, Apr 18, 2013 at 8:28 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:
Thanks, Justin.  I agree with the need for the gener= ic two-sided language.  I=92d still keep this language for scope, beca= use we want to capture the =93declaring=94 aspect in this case:
 
=93Space separated list of scope values (as described in OAuth 2.0 Section 3.3 [RFC6749]) that the client is declaring to the server that it may use = when requesting access tokens and that the server is declaring to the clien= t that it is registered to use when requesting access tokens.=94.
 
You should probably also reinforce that scope values are = service-specific and may not consist only of a static set of string values,= and that therefore, in some cases, an exhaustive list of registered scope values is not possible.=
 
         &nb= sp;            =             &nb= sp;            =              --= Mike
 
From:=  Justin Richer [mailto= :jricher@mitre.org] 
Sent: Monday, Apri= l 15, 2013 12:29 PM

To: Mike Jones
Cc: Tim Bray;  Re: [OAUT= H-WG] Registration: Scope Values
 

I think that because the "declaration" issue affects all paramete= rs in the list, not just scope, we should adopt this in a higher level para= graph and leave it out of the individual parameter descriptions. Thus, some= thing like this inserted as the second paragraph in section 2:

The client metadata values serve two parallel purposes in the overall OAuth= Dynamic Registration protocol: =

 - the Client requesting its desired values for each parameter to the = Authorization Server in a [register] or [update] request,
 - the Authorization Server informing the Client of the current values= of each parameter that the Client has been registered to use through a [cl= ient information response]. 

An Authorization Server MAY override any value that a Client requests durin= g the registration process (including any omitted values) and replace the r= equested value with a default. The normative indications in the following l= ist apply to the Client's declaration of its desired values. <= br>
The Authorization Server SHOULD provide documentation for any fields that i= t requires to be filled in by the client or to have particular values or fo= rmats. Extensions and profiles...


And then remove the sidedness-language from the scope parameter and any oth= er parameters where it might have crept in inadvertently. 

 -- Justin

On 04/15/2013 01:29 PM, Mike Jones wrote:
We could fix the one-sided language by changing
=93Space separated list of scope values (as described in OAuth 2.0 Section 3.3 [RFC6749]) that the client is declaring that it may use when requestin= g access tokens.=94
to
=93Space separated list of scope values (as described in OAuth 2.0 Section 3.3 [RFC6749]) that the client is declaring to the server that it may use = when requesting access tokens and that the server is declaring to the clien= t that it is registered to use when requesting access tokens.=94.
 
Again, I chose the =93registered to use=94 language caref= ully =96 because in the general case it=92s not a restriction on the values= that the client can use =96 just a statement by the server to the client that it is registered to use those particular = values.  In both cases, the parties are making declarations to one ano= ther.
 
If you adopt that language (or keep the original language= ), then yes, I=92d consider this closed.
 
         &nb= sp;            =             &nb= sp;            =              --= Mike
 
From:=  Justin Richer [mailto:jricher@mitre.org] 
Sent: Monday, Apri= l 15, 2013 9:57 AM
To: Mike Jones
Cc: Tim Bray;  Re: [OAUT= H-WG] Registration: Scope Values
 

I absolutely do not want to delete this feature, as (having implemented it)= I think it's very useful. This is a very established pattern in manual reg= istration: I know of many, many OAuth2 servers and clients that are set up = where the client must pre-register a set of scopes. 

I don't like the language of "the client is declaring" because it= 's too one-sided. The client might not have declared anything, and it might= be the server that's declaring something to the client. Deleting the "= ;is declaring" bit removes that unintended restriction of the language while keeping the original meaning intact. I actually thou= ght that I had fixed that before the last draft went in but apparently I mi= ssed this one.

I will work on clarifying the intent of the whole metadata set in its intro= ductory paragraph(s) so that it's clear that all of these fields are used i= n both of these situations:

 1) The client declaring to the server its desire to use a particular = value
 2) The server declaring to the client that it has been registered wit= h a particular value

This should hopefully clear up the issue in the editor's note that I curren= tly have at the top of that section right now, too.

Mike, since you were the one who originally brought up the issue, and you'r= e fine with the existing text, can I take this as closed now? Assuming that= you agree with deleting "is declaring" for reasons stated above,= I'm fine with leaving everything else as is and staying quiet on what the server has to do with the scopes.

 -- Justin

On 04/15/2013 12:44 PM, Mike Jones wrote:
I think that the existing wording is superior to the prop= osed changed wording.  The existing wording is:
 
=    scope
=       OPTIONAL.  Space separated list of scop= e values (as described in
=       OAuth 2.0 Sec= tion 3.3 [RFC6749]) that the client is declaring that
=       it may use when requesting access tokens.&nb= sp; If omitted, an
=       Authorization Server MAY register a Client w= ith a default set of
=       scopes.
 
For instance, the current =93client is declaring=94 wordi= ng will always be correct, whereas as the change to =93client can use=94 wo= rding implies a restriction on client behavior that is not always applicable.  The =93client is declaring=94 wording= was specific and purposefully chosen, and I think should be retained. = ; In particular, we can=92t do anything that implies that only the register= ed scopes values can be used.  At the OAuth spec level, this is a hint as to possible future client behavior =96 not a rest= riction on future client behavior.
 
Also, for the reasons that Tim stated, I=92m strongly aga= inst any =93matching=94 or =93regex=94 language in the spec pertaining to s= copes =96 as it=92s not actionable.
 
So I=92d propose that we leave the existing scope wording= in place.  Alternatively, I=92d also be fine with deleting this featu= re entirely, as I don=92t think it=92s useful in the general case.
 
         &nb= sp;            =             &nb= sp;            =              --= Mike
 
From:=  oauth-bounces@ietf.org [mailto:oauth-bo= unces@ietf.org]On Behalf Of Justin Ric= her
Sent: Monday, Apri= l 15, 2013 8:05 AM
To: Tim Bray;  Re: [OAUT= H-WG] Registration: Scope Values
 

On 04/15/2013 10:52 AM, Tim Bray wrote:

I=92d use the existing wording; it=92s perfectly clear.  Failing that,= if there=92s strong demand for registration of structured scopes, bless th= e use of regexes, either PCREs or some careful subset.


Thanks for the feedback -- Of these two choices, I'd rather leave it as-is.=  


 
However, I=92d subtract the sentence =93If omitted, an Authorization Server= MAY register a Client with a default set of  scopes.=94  It adds= no value; if the client doesn=92t declare scopes, the client doesn=92t dec= lare scopes, that=92s all.  -T


Remember, all of these fields aren't just for the client *request*, they're= also for the server's *response* to either a POST, PUT, or GET request. (I= didn't realize it, but perhaps the wording as stated right now doesn't mak= e that clear -- I need to fix that.) The value that it adds is if the client doesn't ask for any particular sco= pes, the server can still assign it scopes and the client can do something = smart with that. Dumb clients are allowed to ignore it if it doesn't mean a= nything to them. 

This is how our server implementation actually works right now. If the clie= nt doesn't ask for anything specific at registration, the server hands it a= bag of "default" scopes. Same thing happens at auth time -- if t= he client doesn't ask for any particular scopes, the server hands it all of its registered scopes as a default. Granted, on= our server, scopes are just simple strings right now, so they get compared= at the auth endpoint with an exact string-match metric and set-based logic= . 

 -- Justin


 

What would you suggest for wording here, then? Keeping in mind that we cann= ot (and don't want to) prohibit expression-based scopes. 

 -- Justin

 

On 04/15/2013 10:33 AM, Tim Bray wrote:
No, I mean it=92s not interoperable at the software-developer level.  = I can=92t register scopes at authorization time with any predictable effect= that I can write code to support, either client or server side, without ou= t-of-line non-interoperable knowledge about the behavior of the server.  
 
I guess I=92m just not used to OAuth=92s culture of having no expectation t= hat things will be specified tightly enough that I can write code to implem= ent as specified.  -T

 

On Mon, Apr 15, 2013 at 7:15 AM, Justin Richer <jricher@mitre.org> wrote:
Scopes aren't meant to be interoperable between services since they're nece= ssarily API-specific. The only interoperable bit is that there's *some* pla= ce to put the values and that it's expressed as a bag of space-separated st= rings. How those strings get interpreted and enforced (which is really what's at stake here) is up to the AS and PR= (or a higher-level protocol like UMA).

 -- Justin

 

On 04/15/2013 10:13 AM, Tim Bray wrote:

This, as written, has zero interoperability.  I think this feature can= really only be made useful in the case where scopes are fixed strings.

-T

On Apr 15, 2013 6:54 AM, "Justin Richer" <jricher@mitre.org> wrote:

You are correct that the idea behind the "scope" parameter at reg= istration is a constraint on authorization-time scopes that are made availa= ble. It's both a means for the client to request a set of valid scopes and = for the server to provision (and echo back to the client) a set of valid scopes.

I *really* don't want to try to define a matching language for scope expres= sions. For that to work, all servers would need to be able to process the r= egular expressions for all clients, even if the servers themselves only sup= port simple-string scope values. Any regular expression syntax we pick here is guaranteed to be incompatibl= e with something, and I think the complexity doesn't buy much. Also, I thin= k you suddenly have a potential security issue if you have a bad regex in p= lace on either end. 

As it stands today, the server can interpret the incoming registration scop= es and enforce them however it wants to. The real trick comes not from assi= gning the values to a particular client but to enforcing them, and I think = that's always going to be service-specific. We're just not as clear on that as we could be.

After looking over everyone's comments so far, I'd like to propose the foll= owing text for that section:

   scope
      OPTIONAL.  Space separated =
list of scope values (as described in
      OAuth 2.0 Section 3.3 [RFC6749]) that the =
client can use when 
      requesting access tokens.&n=
bsp; As scope values are service-specific, 
      the Authorization Server MA=
Y define its own matching rules when
      determining if a scope value use=
d during an authorization request
      is valid according to the scope =
values assigned during 
      registration. Possible matc=
hing rules include wildcard patterns,
      regular expressions, or exactly =
matching the string. If omitted, 
      an Authorization Server MAY=
 register a Client with a default 
      set of scopes.




Comments? Improvements?



 -- Justin









On 04/14/2013 08:23 PM, Manger, James H wrote:






Presumably at app registration time any scope specification is =
really a constraint on the scope values that can be requested in an authori=
zation flow.


 


So ideally registration should accept rules for matching scopes=
, as opposed to actual scope values.


 


You can try to use scope values as their own matching rules. Th=
at is fine for a small set of "static" scopes. It starts to fail =
when there are a large number of scopes, or scopes that can include paramet=
ers (resource paths? email addresses?). You can try to patch those failures=
 by allowing services to define service-specific special "wildcard&quo=
t; scope values that can only be used during registration (eg "read:*&=
quot;).


 


Alternatively, replace 'scope' in registration with 'scope_rege=
x' that holds a regular expression that all scope values in an authorizatio=
n flow must match.


 


--


James Manger


_______________________________________________

OAuth mailing list


OAuth@ietf.org

https://w=
ww.ietf.org/mailman/listinfo/oauth





 


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

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

--_000_DE8865A9465647B28315FDC1585CEDABmitreorg_-- From twbray@google.com Thu Apr 18 09:26:37 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC99621F913C for ; Thu, 18 Apr 2013 09:26:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQageZTYyqGa for ; Thu, 18 Apr 2013 09:26:35 -0700 (PDT) Received: from mail-ia0-x234.google.com (mail-ia0-x234.google.com [IPv6:2607:f8b0:4001:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 5F26021F9130 for ; Thu, 18 Apr 2013 09:26:34 -0700 (PDT) Received: by mail-ia0-f180.google.com with SMTP id p22so1536577iad.39 for ; Thu, 18 Apr 2013 09:26:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=U+XnZTJZT/eGQTBzEl9eEagz7mzpFw1bfTJ+cJlEFvI=; b=RuvAO4phAMVZ0HjQ+gMx0/ZSZsh3fTkqduKFKCc/SDe8MbIt4hi52qyulfVNIJpcYm VOQZUuti16HZgBds9whIABZZSm52VXXZRLOTbe2+nADst6qLYnc8NA9DfuBARl0CYK94 Dx9aP4P2VtDggLv8Redd2mcwsmtFiqvUin9lhhSnFbolsw9Ar2d/7YB1jmckFv9hKsCg EfRs1rbcCfRwHF6Tt26gzpFybrKaj+fct6Eyvt6Yrd9/KZueUbYdnWARyUIXHT8w5cWJ YttVUzhy1t9qaDdK4VsJHSfurj5r0DDTuFs/XSEmrAvEdzqHPvwSAj0mNDD4SITGTjY8 eMog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=U+XnZTJZT/eGQTBzEl9eEagz7mzpFw1bfTJ+cJlEFvI=; b=JNXV4fjH1iylD4YmxuxjLDtokJzL2yBwzgIAm2GZQbq/QgG5jVR29anx7hyEECWcIc JZkWEGdNk3JAK2Oj75dhocYUMk4tf89YdB9VzZJTkJFq5mXK0T4kqYYz2kppQNdpfhg6 Lr2cxYr1/DZ+ARZrxPaZhez4TLLYDX8nHNifCml7XiqYACE3vGQflT6Walf8tGsj0cRW xoNYZisfY1wP2cbeWxjaCVq0gojNI+hahDm1LwC79Q8mBxo3l0j8tMjzmhTBbTLFPiqR c8AUgWs+HyTivAalVXMrPuPOA7hheoisor+DIb3+K9BvmPs/cdStg9pp4k9AwBbF1GhJ Y0+w== X-Received: by 10.50.135.105 with SMTP id pr9mr249318igb.6.1366302391572; Thu, 18 Apr 2013 09:26:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.31.35 with HTTP; Thu, 18 Apr 2013 09:26:01 -0700 (PDT) In-Reply-To: References: <255B9BB34FB7D647A506DC292726F6E1150C74DADA@WSMSG3153V.srv.dir.telstra.com> <516C069F.9090308@mitre.org> <516C0B9D.6000402@mitre.org> <516C101F.2090706@mitre.org> <516C1714.8070503@mitre.org> <4E1F6AAD24975D4BA5B168042967394367641A87@TK5EX14MBXC283.redmond.corp.microsoft.com> <516C3152.9070603@mitre.org> <4E1F6AAD24975D4BA5B168042967394367641FAB@TK5EX14MBXC283.redmond.corp.microsoft.com> <516C54F2.8040708@mitre.org> <4E1F6AAD24975D4BA5B16804296739436766BCC4@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739436766C964@TK5EX14MBXC284.redmond.corp.microsoft.com> From: Tim Bray Date: Thu, 18 Apr 2013 09:26:01 -0700 Message-ID: To: Anthony Nadalin Content-Type: multipart/alternative; boundary=e89a8f923b66b4b85504daa5101d X-Gm-Message-State: ALoCoQmk3NuZWVdlfDQZFBHSJNOtffc6xv2Cock0n33niALYDLnpESrhap6lnCRtlrkqQ3HfPcdyOeSx10qN4jF/0L20FTm5XZ+32WiYsarhV7oSFBCK/P3Djz6+YMVh7Z8xKk0v08oqWM8fbru8IO9nCJAIFG7rTczWhF6iU1uOXNB+5CpNFxBaPfq6i1cWXSl29hvZj9xX Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Registration: Scope Values X-BeenThere: oauth@ietf.org X-Mailman-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, 18 Apr 2013 16:26:38 -0000 --e89a8f923b66b4b85504daa5101d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hm... how so? If a server is able to specify in advance which set of scopes it will honor (which may or may not be related to what the client specified in the registration) I can see that being useful. I don=E2=80=99= t see a requirement for a linkage between the client=E2=80=99s request and the serv= er=E2=80=99s response. -T On Thu, Apr 18, 2013 at 9:13 AM, Anthony Nadalin wro= te: > If I don=E2=80=99t specify a scope, then the server can allocate a defau= lt (or > default set), thus that breaks the semantics you describe**** > > ** ** > > *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf > Of *Tim Bray > *Sent:* Thursday, April 18, 2013 9:04 AM > *To:* Mike Jones > *Cc:* oauth@ietf.org > > *Subject:* Re: [OAUTH-WG] Registration: Scope Values**** > > ** ** > > I=E2=80=99m unconvinced, Mike. Obviously you=E2=80=99re right about the = looseness of > OAuth2 scope specification, but this is a very specific semantic of what > happens when you register, and I don=E2=80=99t think we=E2=80=99re bound = by history here. > If we can=E2=80=99t safely say anything about what the list of scopes mea= ns, then > I'm with you let's take them out. But the most obvious intended semantic > is (from the client) =E2=80=9CI promise to ask only for these=E2=80=9D an= d from the server > =E2=80=9CThese are the only ones I=E2=80=99ll give you tokens for.=E2=80= =9D Or does someone have > use-cases for an alternative semantic?**** > > ** ** > > To make this concrete, I propose the following:**** > > =E2=80=9CSpace-separated list of scope values (as described in OAuth 2.0 = Section 3.3 > [RFC6749] ) that the > client is declaring to the server that it will restrict itself to when > requesting access tokens, and that the server is declaring to the client > that it is registered to use when requesting access tokens. Clients > SHOULD assume that servers will refuse to grant access tokens for scopes > not in the list provided by the server.=E2=80=9D**** > > ** ** > > ** ** > > On Thu, Apr 18, 2013 at 8:55 AM, Mike Jones > wrote:**** > > I don=E2=80=99t think it=E2=80=99s possible to define what it means in a= n interoperable > way because OAuth didn=E2=80=99t specify scopes in an interoperable way. = No, I > don=E2=80=99t like that either, but I think that=E2=80=99s where things a= re. That=E2=80=99s why I > was advocating deleting this registration feature entirely.**** > > **** > > But understanding it might be useful in some contexts, I=E2=80=99m OK kee= ping it, > provided we be clear that the semantics of =E2=80=9Cregistered to use=E2= =80=9D are > service-specific.**** > > **** > > -- Mike**** > > **** > > *From:* Tim Bray [mailto:twbray@google.com] > *Sent:* Thursday, April 18, 2013 8:36 AM > *To:* Mike Jones > *Cc:* Justin Richer; oauth@ietf.org**** > > > *Subject:* Re: [OAUTH-WG] Registration: Scope Values**** > > **** > > On the server-to-client side, what does =E2=80=9Cregistered to use=E2=80= =9D mean? Does it > mean that the client should assume that any scopes not on the list WILL n= ot > be granted, MAY not be granted.... or what? Is this already covered > elsewhere? -T**** > > **** > > On Thu, Apr 18, 2013 at 8:28 AM, Mike Jones > wrote:**** > > Thanks, Justin. I agree with the need for the generic two-sided > language. I=E2=80=99d still keep this language for scope, because we wan= t to > capture the =E2=80=9Cdeclaring=E2=80=9D aspect in this case:**** > > **** > > =E2=80=9CSpace separated list of scope values (as described in OAuth 2.0 = Section 3.3 > [RFC6749] ) that the > client is declaring to the server that it may use when requesting access > tokens and that the server is declaring to the client that it is register= ed > to use when requesting access tokens.=E2=80=9D.**** > > **** > > You should probably also reinforce that scope values are service-specific > and may not consist only of a static set of string values, and that > therefore, in some cases, an exhaustive list of registered scope values i= s > not possible.**** > > **** > > -- Mike**** > > **** > > *From:* Justin Richer [mailto:jricher@mitre.org] > *Sent:* Monday, April 15, 2013 12:29 PM**** > > > *To:* Mike Jones > *Cc:* Tim Bray; oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Registration: Scope Values**** > > **** > > I think that because the "declaration" issue affects all parameters in th= e > list, not just scope, we should adopt this in a higher level paragraph an= d > leave it out of the individual parameter descriptions. Thus, something li= ke > this inserted as the second paragraph in section 2:**** > > The client metadata values serve two parallel purposes in the overall > OAuth Dynamic Registration protocol: > > - the Client requesting its desired values for each parameter to the > Authorization Server in a [register] or [update] request, > - the Authorization Server informing the Client of the current values of > each parameter that the Client has been registered to use through a [clie= nt > information response]. > > An Authorization Server MAY override any value that a Client requests > during the registration process (including any omitted values) and replac= e > the requested value with a default. The normative indications in the > following list apply to the Client's declaration of its desired values. > > The Authorization Server SHOULD provide documentation for any fields that > it requires to be filled in by the client or to have particular values or > formats. Extensions and profiles...**** > > > And then remove the sidedness-language from the scope parameter and any > other parameters where it might have crept in inadvertently. > > -- Justin**** > > On 04/15/2013 01:29 PM, Mike Jones wrote:**** > > We could fix the one-sided language by changing**** > > =E2=80=9CSpace separated list of scope values (as described in OAuth 2.0 = Section 3.3 > [RFC6749] ) that the > client is declaring that it may use when requesting access tokens.=E2=80= =9D**** > > to**** > > =E2=80=9CSpace separated list of scope values (as described in OAuth 2.0 = Section 3.3 > [RFC6749] ) that the > client is declaring to the server that it may use when requesting access > tokens and that the server is declaring to the client that it is register= ed > to use when requesting access tokens.=E2=80=9D.**** > > **** > > Again, I chose the =E2=80=9Cregistered to use=E2=80=9D language carefully= =E2=80=93 because in the > general case it=E2=80=99s not a restriction on the values that the client= can use =E2=80=93 > just a statement by the server to the client that it is registered to use > those particular values. In both cases, the parties are making > declarations to one another.**** > > **** > > If you adopt that language (or keep the original language), then yes, I= =E2=80=99d > consider this closed.**** > > **** > > -- Mike**** > > **** > > *From:* Justin Richer [mailto:jricher@mitre.org ] > *Sent:* Monday, April 15, 2013 9:57 AM > *To:* Mike Jones > *Cc:* Tim Bray; oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Registration: Scope Values**** > > **** > > I absolutely do not want to delete this feature, as (having implemented > it) I think it's very useful. This is a very established pattern in manua= l > registration: I know of many, many OAuth2 servers and clients that are se= t > up where the client must pre-register a set of scopes. > > I don't like the language of "the client is declaring" because it's too > one-sided. The client might not have declared anything, and it might be t= he > server that's declaring something to the client. Deleting the "is > declaring" bit removes that unintended restriction of the language while > keeping the original meaning intact. I actually thought that I had fixed > that before the last draft went in but apparently I missed this one. > > I will work on clarifying the intent of the whole metadata set in its > introductory paragraph(s) so that it's clear that all of these fields are > used in both of these situations: > > 1) The client declaring to the server its desire to use a particular val= ue > 2) The server declaring to the client that it has been registered with a > particular value > > This should hopefully clear up the issue in the editor's note that I > currently have at the top of that section right now, too. > > Mike, since you were the one who originally brought up the issue, and > you're fine with the existing text, can I take this as closed now? Assumi= ng > that you agree with deleting "is declaring" for reasons stated above, I'm > fine with leaving everything else as is and staying quiet on what the > server has to do with the scopes. > > -- Justin**** > > On 04/15/2013 12:44 PM, Mike Jones wrote:**** > > I think that the existing wording is superior to the proposed changed > wording. The existing wording is:**** > > **** > > scope**** > > OPTIONAL. Space separated list of scope values (as described in***= * > > OAuth 2.0 Section 3.3 [RFC6749]) > that the client is declaring that**** > > it may use when requesting access tokens. If omitted, an**** > > Authorization Server MAY register a Client with a default set of***= * > > scopes.**** > > **** > > For instance, the current =E2=80=9Cclient is declaring=E2=80=9D wording w= ill always be > correct, whereas as the change to =E2=80=9Cclient can use=E2=80=9D wordin= g implies a > restriction on client behavior that is not always applicable. The =E2=80= =9Cclient > is declaring=E2=80=9D wording was specific and purposefully chosen, and I= think > should be retained. In particular, we can=E2=80=99t do anything that imp= lies that > only the registered scopes values can be used. At the OAuth spec level, > this is a hint as to possible future client behavior =E2=80=93 not a rest= riction on > future client behavior.**** > > **** > > Also, for the reasons that Tim stated, I=E2=80=99m strongly against any = =E2=80=9Cmatching=E2=80=9D > or =E2=80=9Cregex=E2=80=9D language in the spec pertaining to scopes =E2= =80=93 as it=E2=80=99s not > actionable.**** > > **** > > So I=E2=80=99d propose that we leave the existing scope wording in place. > Alternatively, I=E2=80=99d also be fine with deleting this feature entire= ly, as I > don=E2=80=99t think it=E2=80=99s useful in the general case.**** > > **** > > -- Mike**** > > **** > > *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] > *On Behalf Of *Justin Richer > *Sent:* Monday, April 15, 2013 8:05 AM > *To:* Tim Bray; oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Registration: Scope Values**** > > **** > > On 04/15/2013 10:52 AM, Tim Bray wrote: > > **** > > I=E2=80=99d use the existing wording; it=E2=80=99s perfectly clear. Fail= ing that, if > there=E2=80=99s strong demand for registration of structured scopes, bles= s the use > of regexes, either PCREs or some careful subset.**** > > > Thanks for the feedback -- Of these two choices, I'd rather leave it > as-is. > > > **** > > **** > > However, I=E2=80=99d subtract the sentence =E2=80=9CIf omitted, an Author= ization Server > MAY register a Client with a default set of scopes.=E2=80=9D It adds no= value; if > the client doesn=E2=80=99t declare scopes, the client doesn=E2=80=99t dec= lare scopes, > that=E2=80=99s all. -T**** > > > Remember, all of these fields aren't just for the client *request*, > they're also for the server's *response* to either a POST, PUT, or GET > request. (I didn't realize it, but perhaps the wording as stated right no= w > doesn't make that clear -- I need to fix that.) The value that it adds is > if the client doesn't ask for any particular scopes, the server can still > assign it scopes and the client can do something smart with that. Dumb > clients are allowed to ignore it if it doesn't mean anything to them. > > This is how our server implementation actually works right now. If the > client doesn't ask for anything specific at registration, the server hand= s > it a bag of "default" scopes. Same thing happens at auth time -- if the > client doesn't ask for any particular scopes, the server hands it all of > its registered scopes as a default. Granted, on our server, scopes are ju= st > simple strings right now, so they get compared at the auth endpoint with = an > exact string-match metric and set-based logic. > > -- Justin > > > **** > > **** > > On Mon, Apr 15, 2013 at 7:35 AM, Justin Richer wrote:= * > *** > > What would you suggest for wording here, then? Keeping in mind that we > cannot (and don't want to) prohibit expression-based scopes. > > -- Justin **** > > **** > > On 04/15/2013 10:33 AM, Tim Bray wrote:**** > > No, I mean it=E2=80=99s not interoperable at the software-developer leve= l. I > can=E2=80=99t register scopes at authorization time with any predictable = effect > that I can write code to support, either client or server side, without > out-of-line non-interoperable knowledge about the behavior of the server. > **** > > **** > > I guess I=E2=80=99m just not used to OAuth=E2=80=99s culture of having no= expectation that > things will be specified tightly enough that I can write code to implemen= t > as specified. -T**** > > **** > > On Mon, Apr 15, 2013 at 7:15 AM, Justin Richer wrote:= * > *** > > Scopes aren't meant to be interoperable between services since they're > necessarily API-specific. The only interoperable bit is that there's *som= e* > place to put the values and that it's expressed as a bag of space-separat= ed > strings. How those strings get interpreted and enforced (which is really > what's at stake here) is up to the AS and PR (or a higher-level protocol > like UMA). > > -- Justin **** > > **** > > On 04/15/2013 10:13 AM, Tim Bray wrote:**** > > This, as written, has zero interoperability. I think this feature can > really only be made useful in the case where scopes are fixed strings.***= * > > -T**** > > On Apr 15, 2013 6:54 AM, "Justin Richer" wrote:**** > > You are correct that the idea behind the "scope" parameter at registratio= n > is a constraint on authorization-time scopes that are made available. It'= s > both a means for the client to request a set of valid scopes and for the > server to provision (and echo back to the client) a set of valid scopes. > > I *really* don't want to try to define a matching language for scope > expressions. For that to work, all servers would need to be able to proce= ss > the regular expressions for all clients, even if the servers themselves > only support simple-string scope values. Any regular expression syntax we > pick here is guaranteed to be incompatible with something, and I think th= e > complexity doesn't buy much. Also, I think you suddenly have a potential > security issue if you have a bad regex in place on either end. > > As it stands today, the server can interpret the incoming registration > scopes and enforce them however it wants to. The real trick comes not fro= m > assigning the values to a particular client but to enforcing them, and I > think that's always going to be service-specific. We're just not as clear > on that as we could be. > > After looking over everyone's comments so far, I'd like to propose the > following text for that section: > > **** > > scope**** > > OPTIONAL. Space separated list of scope values (as described in***= * > > OAuth 2.0 Section 3.3 [RFC6749] ) that the client can use when **** > > requesting access tokens. As scope values are service-specific, **= ** > > the Authorization Server MAY define its own matching rules when**** > > determining if a scope value used during an authorization request**= ** > > is valid according to the scope values assigned during **** > > registration. Possible matching rules include wildcard patterns,***= * > > regular expressions, or exactly matching the string. If omitted, **= ** > > an Authorization Server MAY register a Client with a default **** > > set of scopes.**** > > > Comments? Improvements? > > -- Justin > > **** > > On 04/14/2013 08:23 PM, Manger, James H wrote:**** > > Presumably at app registration time any scope specification is really a c= onstraint on the scope values that can be requested in an authorization flo= w.**** > > **** > > So ideally registration should accept rules for matching scopes, as oppos= ed to actual scope values.**** > > **** > > You can try to use scope values as their own matching rules. That is fine= for a small set of "static" scopes. It starts to fail when there are a lar= ge number of scopes, or scopes that can include parameters (resource paths?= email addresses?). You can try to patch those failures by allowing service= s to define service-specific special "wildcard" scope values that can only = be used during registration (eg "read:*").**** > > **** > > Alternatively, replace 'scope' in registration with 'scope_regex' that ho= lds a regular expression that all scope values in an authorization flow mus= t match.**** > > **** > > --**** > > James Manger**** > > _______________________________________________**** > > 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**** > > **** > > **** > > **** > > **** > > **** > > **** > > **** > > **** > > ** ** > --e89a8f923b66b4b85504daa5101d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hm... how so? =C2=A0If a server is able to specify in adva= nce which set of scopes it will honor (which may or may not be related to w= hat the client specified in the registration) I can see that being useful. = =C2=A0I don=E2=80=99t see a requirement for a linkage between the client=E2= =80=99s request and the server=E2=80=99s response. =C2=A0-T


On Thu, Apr 1= 8, 2013 at 9:13 AM, Anthony Nadalin <tonynad@microsoft.com> wrote:

If I don=E2=80=99t specif= y a scope, then the server can allocate a default (or default set), thus th= at breaks the semantics you describe

=C2=A0

From: oauth-bounces@ietf.or= g [mailto:o= auth-bounces@ietf.org] On Behalf Of Tim Bray
Sent: Thursday, April 18, 2013 9:04 AM
To: Mike Jones
Cc: oauth@ietf.o= rg


Subject: Re: [OAUTH-WG] Registration: Scope Values

=C2=A0

I=E2=80=99m unconvinced, Mike. =C2=A0Obviously you= =E2=80=99re right about the looseness of OAuth2 scope specification, but th= is is a very specific semantic of what happens when you register, and I don= =E2=80=99t think we=E2=80=99re bound by history here. =C2=A0 If we can=E2= =80=99t safely say anything about what the list of scopes means, then I'm with you le= t's take them out. =C2=A0But the most obvious intended semantic is (fro= m the client) =E2=80=9CI promise to ask only for these=E2=80=9D and from th= e server =E2=80=9CThese are the only ones I=E2=80=99ll give you tokens for.= =E2=80=9D =C2=A0Or does someone have use-cases for an alternative semantic?

=C2=A0

To make this concrete, I propose the following:

=E2=80=9CSpace-separated list of sc= ope values (as described in OAuth 2.0=C2=A0Section=C2=A03.3 [RFC6749]) that the client is declaring to the server that it will res= trict itself to when requesting access tokens, and that the server is decla= ring to the client that it is registered to use when requesting access toke= ns. =C2=A0Clients SHOULD assume that servers will refuse to grant access tokens for scopes n= ot in the list provided by the server.=E2= =80=9D

=C2=A0

=C2=A0<= /p>

On Thu, Apr 18, 2013 at 8:55 AM, Mike Jones <Michael.Jones@= microsoft.com> wrote:

I don=E2=80=99t think it= =E2=80=99s possible to define what it means in an interoperable way because= OAuth didn=E2=80=99t specify scopes in an interoperable way.=C2=A0 No, I don=E2=80=99t like tha= t either, but I think that=E2=80=99s where things are.=C2=A0 That=E2=80=99s= why I was advocating deleting this registration feature entirely.

=C2=A0

But understanding it migh= t be useful in some contexts, I=E2=80=99m OK keeping it, provided we be cle= ar that the semantics of =E2=80=9Cregistered to use=E2=80=9D are service-specific.=

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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

=C2=A0

From: Tim Bray= [mailto:twbray@goog= le.com]
Sent: Thursday, April 18, 2013 8:36 AM
To: Mike Jones
Cc: Justin Richer; oauth@ietf.org


Subject: Re: [OAUTH-WG] Registration: Scope Values

=C2=A0

On the server-to-client side, what does =E2=80=9Creg= istered to use=E2=80=9D mean? =C2=A0Does it mean that the client should ass= ume that any scopes not on the list WILL not be granted, MAY not be granted= .... or what? =C2=A0Is this already covered elsewhere? -T

=C2=A0<= /p>

On Thu, Apr 18, 2013 at 8:28 AM, Mike Jones <Michael.Jones@= microsoft.com> wrote:

Thanks, Justin.=C2=A0 I a= gree with the need for the generic two-sided language.=C2=A0 I=E2=80=99d st= ill keep this language for scope, because we want to capture the =E2=80=9Cdeclaring=E2=80=9D aspe= ct in this case:

=C2=A0

=E2=80=9CSpace separated list of scope values (as de= scribed in OAuth 2.0 Section=C2=A03.3 [RFC6749]) that the client is declaring to the serve= r that it may use when requesting access tokens and that the server is decl= aring to the client that it is registered to use when requesting access tokens.=E2= =80=9D.

=C2=A0

You should probably also = reinforce that scope values are service-specific and may not consist only of a static set of string values, and that therefore, in some cases, an ex= haustive list of registered scope values is not possible.<= /u>

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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

=C2=A0

From: Justin R= icher [mailto:jriche= r@mitre.org]
Sent: Monday, April 15, 2013 12:29 PM


To: Mike Jones
Cc: Tim Bray; oa= uth@ietf.org
Subject: Re: [OAUTH-WG] Registration: Scope Values

=C2=A0

I think that because = the "declaration" issue affects all parameters in the list, not j= ust scope, we should adopt this in a higher level paragraph and leave it ou= t of the individual parameter descriptions. Thus, something like this inserted as the second paragraph i= n section 2:

The client metadata values serve two parallel purpos= es in the overall OAuth Dynamic Registration protocol:

=C2=A0- the Client requesting its desired values for each parameter to the = Authorization Server in a [register] or [update] request,
=C2=A0- the Authorization Server informing the Client of the current values= of each parameter that the Client has been registered to use through a [cl= ient information response].

An Authorization Server MAY override any value that a Client requests durin= g the registration process (including any omitted values) and replace the r= equested value with a default. The normative indications in the following l= ist apply to the Client's declaration of its desired values.

The Authorization Server SHOULD provide documentation for any fields that i= t requires to be filled in by the client or to have particular values or fo= rmats. Extensions and profiles...


And then remove the sidedness-language from the scope parameter and any oth= er parameters where it might have crept in inadvertently.

=C2=A0-- Justin

On 04/15/2013 01:29 PM, Mike Jones wrote:<= /u>

We could fix the one-side= d language by changing

=E2=80=9CSpace separated list of scope values (as de= scribed in OAuth 2.0 Section=C2=A03.3 [RFC6749]) that the client is declaring that it may = use when requesting access tokens.=E2=80= =9D

to

=E2=80=9CSpace separated list of scope values (as de= scribed in OAuth 2.0 Section=C2=A03.3 [RFC6749]) that the client is declaring to the serve= r that it may use when requesting access tokens and that the server is decl= aring to the client that it is registered to use when requesting access tokens.=E2= =80=9D.

=C2=A0

Again, I chose the =E2=80= =9Cregistered to use=E2=80=9D language carefully =E2=80=93 because in the g= eneral case it=E2=80=99s not a restriction on the values that the client can use =E2=80=93 just a state= ment by the server to the client that it is registered to use those particu= lar values.=C2=A0 In both cases, the parties are making declarations to one= another.

=C2=A0

If you adopt that languag= e (or keep the original language), then yes, I=E2=80=99d consider this clos= ed.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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

=C2=A0

From: Justin R= icher [mailto:jriche= r@mitre.org]
Sent: Monday, April 15, 2013 9:57 AM
To: Mike Jones
Cc: Tim Bray; oa= uth@ietf.org
Subject: Re: [OAUTH-WG] Registration: Scope Values<= /u>

=C2=A0

I absolutely do not w= ant to delete this feature, as (having implemented it) I think it's ver= y useful. This is a very established pattern in manual registration: I know= of many, many OAuth2 servers and clients that are set up where the client must pre-register a s= et of scopes.

I don't like the language of "the client is declaring" becaus= e it's too one-sided. The client might not have declared anything, and = it might be the server that's declaring something to the client. Deleti= ng the "is declaring" bit removes that unintended restriction of the language while keeping the original meaning intact. I actually thou= ght that I had fixed that before the last draft went in but apparently I mi= ssed this one.

I will work on clarifying the intent of the whole metadata set in its intro= ductory paragraph(s) so that it's clear that all of these fields are us= ed in both of these situations:

=C2=A01) The client declaring to the server its desire to use a particular = value
=C2=A02) The server declaring to the client that it has been registered wit= h a particular value

This should hopefully clear up the issue in the editor's note that I cu= rrently have at the top of that section right now, too.

Mike, since you were the one who originally brought up the issue, and you&#= 39;re fine with the existing text, can I take this as closed now? Assuming = that you agree with deleting "is declaring" for reasons stated ab= ove, I'm fine with leaving everything else as is and staying quiet on what the server has to do with the scopes.

=C2=A0-- Justin

On 04/15/2013 12:44 PM, Mike Jones wrote:<= /u>

I think that the existing= wording is superior to the proposed changed wording.=C2=A0 The existing wo= rding is:

=C2=A0

=C2=A0=C2=A0 scope

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 OPTIONAL.=C2= =A0 Space separated list of scope values (as described in<= /u>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 OAuth 2.0 Section=C2=A03.3 [RFC6749]) that the client is declaring that<= u>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 it may use whe= n requesting access tokens.=C2=A0 If omitted, an

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Authorization = Server MAY register a Client with a default set of

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 scopes.=

=C2=A0

For instance, the current= =E2=80=9Cclient is declaring=E2=80=9D wording will always be correct, wher= eas as the change to =E2=80=9Cclient can use=E2=80=9D wording implies a restriction on clien= t behavior that is not always applicable.=C2=A0 The =E2=80=9Cclient is decl= aring=E2=80=9D wording was specific and purposefully chosen, and I think sh= ould be retained.=C2=A0 In particular, we can=E2=80=99t do anything that im= plies that only the registered scopes values can be used.=C2=A0 At the OAuth spec lev= el, this is a hint as to possible future client behavior =E2=80=93 not a re= striction on future client behavior.

=C2=A0

Also, for the reasons tha= t Tim stated, I=E2=80=99m strongly against any =E2=80=9Cmatching=E2=80=9D o= r =E2=80=9Cregex=E2=80=9D language in the spec pertaining to scopes =E2=80=93 as it=E2=80=99s not actionable.

=C2=A0

So I=E2=80=99d propose th= at we leave the existing scope wording in place.=C2=A0 Alternatively, I=E2= =80=99d also be fine with deleting this feature entirely, as I don=E2=80=99t think it=E2=80=99s= useful in the general case.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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

=C2=A0

From: oauth-bounces@i= etf.org [ma= ilto:oauth-bounces@ietf.org] On Behalf Of Justin Richer
Sent: Monday, April 15, 2013 8:05 AM
To: Tim Bray; oa= uth@ietf.org
Subject: Re: [OAUTH-WG] Registration: Scope Values<= /u>

=C2=A0

On 04/15/2013 10:52 A= M, Tim Bray wrote:

I=E2=80=99d use the existing wording; it=E2=80=99s p= erfectly clear. =C2=A0Failing that, if there=E2=80=99s strong demand for re= gistration of structured scopes, bless the use of regexes, either PCREs or = some careful subset.


Thanks for the feedback -- Of these two choices, I'd rather leave it as= -is.


=C2=A0

However, I=E2=80=99d subtract the sentence =E2=80=9C= If omitted, an Authorization Server MAY register a Client with a default se= t of =C2=A0scopes.=E2=80=9D =C2=A0It adds no value; if the client doesn=E2= =80=99t declare scopes, the client doesn=E2=80=99t declare scopes, that=E2=80=99s all. =C2=A0-T=


Remember, all of these fields aren't just for the client *request*, the= y're also for the server's *response* to either a POST, PUT, or GET= request. (I didn't realize it, but perhaps the wording as stated right= now doesn't make that clear -- I need to fix that.) The value that it adds is if the client doesn't ask for any particular= scopes, the server can still assign it scopes and the client can do someth= ing smart with that. Dumb clients are allowed to ignore it if it doesn'= t mean anything to them.

This is how our server implementation actually works right now. If the clie= nt doesn't ask for anything specific at registration, the server hands = it a bag of "default" scopes. Same thing happens at auth time -- = if the client doesn't ask for any particular scopes, the server hands it all of its registered scopes as a default. Granted, on= our server, scopes are just simple strings right now, so they get compared= at the auth endpoint with an exact string-match metric and set-based logic= .

=C2=A0-- Justin


=C2=A0<= /p>

On Mon, Apr 15, 2013 at 7:35 AM, Justin Richer <<= a href=3D"mailto:jricher@mitre.org" target=3D"_blank">jricher@mitre.org= > wrote:

What would you suggest for wording here, then? Keepi= ng in mind that we cannot (and don't want to) prohibit expression-based= scopes.

=C2=A0-- Justin

=C2=A0<= /p>

On 04/15/2013 10:33 AM, Tim Bray wrote:

No, I mean it=E2=80=99s not interoperable at the sof= tware-developer level. =C2=A0I can=E2=80=99t register scopes at authorizati= on time with any predictable effect that I can write code to support, eithe= r client or server side, without out-of-line non-interoperable knowledge abo= ut the behavior of the server. =C2=A0

=C2=A0

I guess I=E2=80=99m just not used to OAuth=E2=80=99s= culture of having no expectation that things will be specified tightly eno= ugh that I can write code to implement as specified. =C2=A0-T=

=C2=A0<= /p>

On Mon, Apr 15, 2013 at 7:15 AM, Justin Richer <<= a href=3D"mailto:jricher@mitre.org" target=3D"_blank">jricher@mitre.org= > wrote:

Scopes aren't meant to be interoperable between = services since they're necessarily API-specific. The only interoperable= bit is that there's *some* place to put the values and that it's expressed as a bag of space-separated strings. How those strings = get interpreted and enforced (which is really what's at stake here) is = up to the AS and PR (or a higher-level protocol like UMA).

=C2=A0-- Justin

=C2=A0<= /p>

On 04/15/2013 10:13 AM, Tim Bray wrote:

This, as written, has zero interoperability.=C2=A0 I think this feature = can really only be made useful in the case where scopes are fixed strings.<= u>

-T

On Apr 15, 2013 6:54 AM, "Justin Richer" &= lt;jricher@mitre.org= > wrote:

You are correct that = the idea behind the "scope" parameter at registration is a constr= aint on authorization-time scopes that are made available. It's both a = means for the client to request a set of valid scopes and for the server to provision (and echo back to th= e client) a set of valid scopes.

I *really* don't want to try to define a matching language for scope ex= pressions. For that to work, all servers would need to be able to process t= he regular expressions for all clients, even if the servers themselves only= support simple-string scope values. Any regular expression syntax we pick here is guaranteed to be incompatibl= e with something, and I think the complexity doesn't buy much. Also, I = think you suddenly have a potential security issue if you have a bad regex = in place on either end.

As it stands today, the server can interpret the incoming registration scop= es and enforce them however it wants to. The real trick comes not from assi= gning the values to a particular client but to enforcing them, and I think = that's always going to be service-specific. We're just not as clear on that as we could be.

After looking over everyone's comments so far, I'd like to propose = the following text for that section:

=C2=A0=C2=A0 scope
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 OPTIONAL.=C2=A0 Space separated list of=
 scope values (as described in
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 OAuth 2.0 Section=C2=A03.3 [RFC6749]<=
/a>) that the client can use when 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0requesting access tokens.=C2=A0 As=
 scope values are service-specific, 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0the Authorization Server MAY defin=
e its own matching rules when
=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0determining if a scope value used durin=
g an authorization request
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 is valid according to the scope values =
assigned during 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0registration. Possible matching ru=
les include wildcard patterns,
=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0regular expressions, or exactly matchin=
g the string. If omitted, 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0an Authorization Server MAY regist=
er a Client with a default 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0set of scopes.


Comments? Improvements?

=C2=A0-- Justin

On 04/14/2013 08:23 PM, Manger, James H wrote:

Presumably at app registration time any scope specification is really =
a constraint on the scope values that can be requested in an authorization =
flow.
=C2=A0
So ideally registration should accept rules for matching scopes, as op=
posed to actual scope values.
=C2=A0
You can try to use scope values as their own matching rules. That is f=
ine for a small set of "static" scopes. It starts to fail when th=
ere are a large number of scopes, or scopes that can include parameters (re=
source paths? email addresses?). You can try to patch those failures by all=
owing services to define service-specific special "wildcard" scop=
e values that can only be used during registration (eg "read:*").=

=C2=A0
Alternatively, replace 'scope' in registration with 'scope=
_regex' that holds a regular expression that all scope values in an aut=
horization flow must match.
=C2=A0
--
James Manger
_______________________________________________
OAuth mailing list
OAuth@ietf.org=

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

=C2=A0


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

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0


--e89a8f923b66b4b85504daa5101d-- From jwernicke1988@gmail.com Thu Apr 18 09:30:46 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55F7E21F9156 for ; Thu, 18 Apr 2013 09:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.383 X-Spam-Level: X-Spam-Status: No, score=0.383 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MISSING_SUBJECT=1.762, RCVD_IN_DNSWL_LOW=-1, TVD_SPACE_RATIO=2.219] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FwVjoXOfx+TZ for ; Thu, 18 Apr 2013 09:30:46 -0700 (PDT) Received: from mail-oa0-f46.google.com (mail-oa0-f46.google.com [209.85.219.46]) by ietfa.amsl.com (Postfix) with ESMTP id 77FFF21F914C for ; Thu, 18 Apr 2013 09:30:44 -0700 (PDT) Received: by mail-oa0-f46.google.com with SMTP id k3so265820oag.19 for ; Thu, 18 Apr 2013 09:30:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=rG1+V+L0haLXLWIALYYX+H4IoloChxydyVmoE6+9fO0=; b=FGfdNp44h0SNB2dpheMnKecSUdq1UoNEH3dbZySCNeMkFStLIpwJI0rMpdj4iBW7HB MDbktTY7MjesVopJZ/VSZP0X804udKjFEK9l8Joaafx4gQ/ItTuvyOy5+WUKBQWrSoZd Bw8X5H51MM67ZMMsgIzoQwnWz9V2H/Sh/4qndKt5UoCmPjfWwBu9pDvDbMj5u86V3bsI fHS/nbFdyC09m/Zi6r5Ohjus4PSBrcl/dKw7Uw7nhE43/0sN/30mnSz04HL0NUnG4loW MWJWZqqk8y5nqh07R1tGmttbWIAI2zupI0qkQco9i1uyhtRMopeNHNV3nYmSgNBvuIgU r3Ag== MIME-Version: 1.0 X-Received: by 10.60.118.131 with SMTP id km3mr928849oeb.137.1366302644504; Thu, 18 Apr 2013 09:30:44 -0700 (PDT) Received: by 10.76.114.228 with HTTP; Thu, 18 Apr 2013 09:30:44 -0700 (PDT) Received: by 10.76.114.228 with HTTP; Thu, 18 Apr 2013 09:30:44 -0700 (PDT) Date: Thu, 18 Apr 2013 12:30:44 -0400 Message-ID: From: Josh Wernicke To: oauth@ietf.org Content-Type: multipart/alternative; boundary=047d7b3a9bd8c8110804daa51fe2 Subject: [OAUTH-WG] (no subject) X-BeenThere: oauth@ietf.org X-Mailman-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, 18 Apr 2013 16:30:46 -0000 --047d7b3a9bd8c8110804daa51fe2 Content-Type: text/plain; charset=ISO-8859-1 Stop --047d7b3a9bd8c8110804daa51fe2 Content-Type: text/html; charset=ISO-8859-1

Stop

--047d7b3a9bd8c8110804daa51fe2-- From tonynad@microsoft.com Thu Apr 18 09:35:56 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87A8721F85B3 for ; Thu, 18 Apr 2013 09:35:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.534 X-Spam-Level: X-Spam-Status: No, score=0.534 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mVpWAzQC4VbM for ; Thu, 18 Apr 2013 09:35:54 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0238.outbound.protection.outlook.com [207.46.163.238]) by ietfa.amsl.com (Postfix) with ESMTP id 2E85B21F8F6D for ; Thu, 18 Apr 2013 09:35:53 -0700 (PDT) Received: from BL2FFO11FD027.protection.gbl (10.173.161.204) by BL2FFO11HUB032.protection.gbl (10.173.161.56) with Microsoft SMTP Server (TLS) id 15.0.675.0; Thu, 18 Apr 2013 16:33:42 +0000 Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD027.mail.protection.outlook.com (10.173.161.106) with Microsoft SMTP Server (TLS) id 15.0.675.0 via Frontend Transport; Thu, 18 Apr 2013 16:33:42 +0000 Received: from va3outboundpool.messaging.microsoft.com (157.54.51.113) by mail.microsoft.com (157.54.80.25) with Microsoft SMTP Server (TLS) id 14.2.318.3; Thu, 18 Apr 2013 16:33:37 +0000 Received: from mail4-va3-R.bigfish.com (10.7.14.237) by VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id 14.1.225.23; Thu, 18 Apr 2013 16:31:48 +0000 Received: from mail4-va3 (localhost [127.0.0.1]) by mail4-va3-R.bigfish.com (Postfix) with ESMTP id AB8342203EF for ; Thu, 18 Apr 2013 16:31:48 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT002.namprd03.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -24 X-BigFish: PS-24(zzbb2dI98dI9371Ic89bh1418Ic857h4015I199bI1447Idf9Izz1f42h1fc6h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1082kzz1033IL17326ah18c673h8275bh8275dh15d4Iz31h2a8h668h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh9a9j1155h) Received-SPF: softfail (mail4-va3: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=tonynad@microsoft.com; helo=BL2PRD0310HT002.namprd03.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BY2PR03MB041; H:BY2PR03MB041.namprd03.prod.outlook.com; LANG:en; Received: from mail4-va3 (localhost.localdomain [127.0.0.1]) by mail4-va3 (MessageSwitch) id 1366302702540811_9886; Thu, 18 Apr 2013 16:31:42 +0000 (UTC) Received: from VA3EHSMHS014.bigfish.com (unknown [10.7.14.235]) by mail4-va3.bigfish.com (Postfix) with ESMTP id 7797C20011C; Thu, 18 Apr 2013 16:31:42 +0000 (UTC) Received: from BL2PRD0310HT002.namprd03.prod.outlook.com (157.56.240.21) by VA3EHSMHS014.bigfish.com (10.7.99.24) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 18 Apr 2013 16:31:40 +0000 Received: from BY2PR03MB041.namprd03.prod.outlook.com (10.255.241.145) by BL2PRD0310HT002.namprd03.prod.outlook.com (10.255.97.37) with Microsoft SMTP Server (TLS) id 14.16.299.2; Thu, 18 Apr 2013 16:31:38 +0000 Received: from BY2PR03MB041.namprd03.prod.outlook.com (10.255.241.145) by BY2PR03MB041.namprd03.prod.outlook.com (10.255.241.145) with Microsoft SMTP Server (TLS) id 15.0.670.13; Thu, 18 Apr 2013 16:31:36 +0000 Received: from BY2PR03MB041.namprd03.prod.outlook.com ([169.254.8.206]) by BY2PR03MB041.namprd03.prod.outlook.com ([169.254.8.18]) with mapi id 15.00.0670.000; Thu, 18 Apr 2013 16:31:36 +0000 From: Anthony Nadalin To: Tim Bray Thread-Topic: [OAUTH-WG] Registration: Scope Values Thread-Index: AQHOOeqUpTbAsDaRHkORyYtY57tExZjXfRiAgAADhACAAAk/gIAAITkAgARzy4CAAAIrAIAABU6AgAACc4CAAAJxoIAAA8KAgAAAy0A= Date: Thu, 18 Apr 2013 16:31:35 +0000 Message-ID: <04cb3c88970842de9b0ec1162e8a86db@BY2PR03MB041.namprd03.prod.outlook.com> References: <255B9BB34FB7D647A506DC292726F6E1150C74DADA@WSMSG3153V.srv.dir.telstra.com> <516C069F.9090308@mitre.org> <516C0B9D.6000402@mitre.org> <516C101F.2090706@mitre.org> <516C1714.8070503@mitre.org> <4E1F6AAD24975D4BA5B168042967394367641A87@TK5EX14MBXC283.redmond.corp.microsoft.com> <516C3152.9070603@mitre.org> <4E1F6AAD24975D4BA5B168042967394367641FAB@TK5EX14MBXC283.redmond.corp.microsoft.com> <516C54F2.8040708@mitre.org> <4E1F6AAD24975D4BA5B16804296739436766BCC4@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739436766C964@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: [212.47.23.197] Content-Type: multipart/alternative; boundary="_000_04cb3c88970842de9b0ec1162e8a86dbBY2PR03MB041namprd03pro_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: BY2PR03MB041.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%GOOGLE.COM$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC104.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC104.redmond.corp.microsoft.com X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(80022001)(65816001)(47446002)(6806003)(81342001)(512874001)(71186001)(20776003)(74662001)(54356001)(81542001)(51856001)(564824004)(46102001)(44976003)(79102001)(74502001)(53806001)(33646001)(63696002)(66066001)(47736001)(47976001)(31966008)(77982001)(16676001)(4396001)(49866001)(59766001)(56816002)(76482001)(54316002)(69226001)(50986001)(56776001)(42262001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB032; H:TK5EX14HUBC104.redmond.corp.microsoft.com; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 08200063E9 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Registration: Scope Values X-BeenThere: oauth@ietf.org X-Mailman-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, 18 Apr 2013 16:35:56 -0000 --_000_04cb3c88970842de9b0ec1162e8a86dbBY2PR03MB041namprd03pro_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q2xpZW50IGFza3MgZm9yIG5vdGhpbmcgYW5kIHRoZSBzZXJ2ZXIgcmV0dXJucyDigJxB4oCdLCB0 aHVzIGRvZXMgbm90IG1hdGNoIHlvdXIg4oCcSSBwcm9taXNlIHRvIGFzayBvbmx5IGZvciB0aGVz ZeKAnSBhbmQgZnJvbSB0aGUgc2VydmVyIOKAnFRoZXNlIGFyZSB0aGUgb25seSBvbmVzIEnigJls bCBnaXZlIHlvdSB0b2tlbnMgZm9yLuKAneKAnSBBcyB0aGUgY2xpZW50IG1heSBhbHNvIGFzayBm b3IgWCBhbmQgZ2V0IFguDQoNCkZyb206IFRpbSBCcmF5IFttYWlsdG86dHdicmF5QGdvb2dsZS5j b21dDQpTZW50OiBUaHVyc2RheSwgQXByaWwgMTgsIDIwMTMgOToyNiBBTQ0KVG86IEFudGhvbnkg TmFkYWxpbg0KQ2M6IE1pa2UgSm9uZXM7IG9hdXRoQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW09B VVRILVdHXSBSZWdpc3RyYXRpb246IFNjb3BlIFZhbHVlcw0KDQpIbS4uLiBob3cgc28/ICBJZiBh IHNlcnZlciBpcyBhYmxlIHRvIHNwZWNpZnkgaW4gYWR2YW5jZSB3aGljaCBzZXQgb2Ygc2NvcGVz IGl0IHdpbGwgaG9ub3IgKHdoaWNoIG1heSBvciBtYXkgbm90IGJlIHJlbGF0ZWQgdG8gd2hhdCB0 aGUgY2xpZW50IHNwZWNpZmllZCBpbiB0aGUgcmVnaXN0cmF0aW9uKSBJIGNhbiBzZWUgdGhhdCBi ZWluZyB1c2VmdWwuICBJIGRvbuKAmXQgc2VlIGEgcmVxdWlyZW1lbnQgZm9yIGEgbGlua2FnZSBi ZXR3ZWVuIHRoZSBjbGllbnTigJlzIHJlcXVlc3QgYW5kIHRoZSBzZXJ2ZXLigJlzIHJlc3BvbnNl LiAgLVQNCg0KT24gVGh1LCBBcHIgMTgsIDIwMTMgYXQgOToxMyBBTSwgQW50aG9ueSBOYWRhbGlu IDx0b255bmFkQG1pY3Jvc29mdC5jb208bWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0LmNvbT4+IHdy b3RlOg0KSWYgSSBkb27igJl0IHNwZWNpZnkgYSBzY29wZSwgdGhlbiB0aGUgc2VydmVyIGNhbiBh bGxvY2F0ZSBhIGRlZmF1bHQgKG9yIGRlZmF1bHQgc2V0KSwgdGh1cyB0aGF0IGJyZWFrcyB0aGUg c2VtYW50aWNzIHlvdSBkZXNjcmliZQ0KDQpGcm9tOiBvYXV0aC1ib3VuY2VzQGlldGYub3JnPG1h aWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5v cmc8bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgVGltIEJyYXkN ClNlbnQ6IFRodXJzZGF5LCBBcHJpbCAxOCwgMjAxMyA5OjA0IEFNDQpUbzogTWlrZSBKb25lcw0K Q2M6IG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4NCg0KU3ViamVjdDogUmU6 IFtPQVVUSC1XR10gUmVnaXN0cmF0aW9uOiBTY29wZSBWYWx1ZXMNCg0KSeKAmW0gdW5jb252aW5j ZWQsIE1pa2UuICBPYnZpb3VzbHkgeW914oCZcmUgcmlnaHQgYWJvdXQgdGhlIGxvb3NlbmVzcyBv ZiBPQXV0aDIgc2NvcGUgc3BlY2lmaWNhdGlvbiwgYnV0IHRoaXMgaXMgYSB2ZXJ5IHNwZWNpZmlj IHNlbWFudGljIG9mIHdoYXQgaGFwcGVucyB3aGVuIHlvdSByZWdpc3RlciwgYW5kIEkgZG9u4oCZ dCB0aGluayB3ZeKAmXJlIGJvdW5kIGJ5IGhpc3RvcnkgaGVyZS4gICBJZiB3ZSBjYW7igJl0IHNh ZmVseSBzYXkgYW55dGhpbmcgYWJvdXQgd2hhdCB0aGUgbGlzdCBvZiBzY29wZXMgbWVhbnMsIHRo ZW4gSSdtIHdpdGggeW91IGxldCdzIHRha2UgdGhlbSBvdXQuICBCdXQgdGhlIG1vc3Qgb2J2aW91 cyBpbnRlbmRlZCBzZW1hbnRpYyBpcyAoZnJvbSB0aGUgY2xpZW50KSDigJxJIHByb21pc2UgdG8g YXNrIG9ubHkgZm9yIHRoZXNl4oCdIGFuZCBmcm9tIHRoZSBzZXJ2ZXIg4oCcVGhlc2UgYXJlIHRo ZSBvbmx5IG9uZXMgSeKAmWxsIGdpdmUgeW91IHRva2VucyBmb3Iu4oCdICBPciBkb2VzIHNvbWVv bmUgaGF2ZSB1c2UtY2FzZXMgZm9yIGFuIGFsdGVybmF0aXZlIHNlbWFudGljPw0KDQpUbyBtYWtl IHRoaXMgY29uY3JldGUsIEkgcHJvcG9zZSB0aGUgZm9sbG93aW5nOg0K4oCcU3BhY2Utc2VwYXJh dGVkIGxpc3Qgb2Ygc2NvcGUgdmFsdWVzIChhcyBkZXNjcmliZWQgaW4gT0F1dGggMi4wIFNlY3Rp b24gMy4zIFtSRkM2NzQ5XTxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2NzQ5I3NlY3Rp b24tMy4zPikgdGhhdCB0aGUgY2xpZW50IGlzIGRlY2xhcmluZyB0byB0aGUgc2VydmVyIHRoYXQg aXQgd2lsbCByZXN0cmljdCBpdHNlbGYgdG8gd2hlbiByZXF1ZXN0aW5nIGFjY2VzcyB0b2tlbnMs IGFuZCB0aGF0IHRoZSBzZXJ2ZXIgaXMgZGVjbGFyaW5nIHRvIHRoZSBjbGllbnQgdGhhdCBpdCBp cyByZWdpc3RlcmVkIHRvIHVzZSB3aGVuIHJlcXVlc3RpbmcgYWNjZXNzIHRva2Vucy4gIENsaWVu dHMgU0hPVUxEIGFzc3VtZSB0aGF0IHNlcnZlcnMgd2lsbCByZWZ1c2UgdG8gZ3JhbnQgYWNjZXNz IHRva2VucyBmb3Igc2NvcGVzIG5vdCBpbiB0aGUgbGlzdCBwcm92aWRlZCBieSB0aGUgc2VydmVy LuKAnQ0KDQoNCk9uIFRodSwgQXByIDE4LCAyMDEzIGF0IDg6NTUgQU0sIE1pa2UgSm9uZXMgPE1p Y2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQu Y29tPj4gd3JvdGU6DQpJIGRvbuKAmXQgdGhpbmsgaXTigJlzIHBvc3NpYmxlIHRvIGRlZmluZSB3 aGF0IGl0IG1lYW5zIGluIGFuIGludGVyb3BlcmFibGUgd2F5IGJlY2F1c2UgT0F1dGggZGlkbuKA mXQgc3BlY2lmeSBzY29wZXMgaW4gYW4gaW50ZXJvcGVyYWJsZSB3YXkuICBObywgSSBkb27igJl0 IGxpa2UgdGhhdCBlaXRoZXIsIGJ1dCBJIHRoaW5rIHRoYXTigJlzIHdoZXJlIHRoaW5ncyBhcmUu ICBUaGF04oCZcyB3aHkgSSB3YXMgYWR2b2NhdGluZyBkZWxldGluZyB0aGlzIHJlZ2lzdHJhdGlv biBmZWF0dXJlIGVudGlyZWx5Lg0KDQpCdXQgdW5kZXJzdGFuZGluZyBpdCBtaWdodCBiZSB1c2Vm dWwgaW4gc29tZSBjb250ZXh0cywgSeKAmW0gT0sga2VlcGluZyBpdCwgcHJvdmlkZWQgd2UgYmUg Y2xlYXIgdGhhdCB0aGUgc2VtYW50aWNzIG9mIOKAnHJlZ2lzdGVyZWQgdG8gdXNl4oCdIGFyZSBz ZXJ2aWNlLXNwZWNpZmljLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IFRpbSBCcmF5IFttYWlsdG86 dHdicmF5QGdvb2dsZS5jb208bWFpbHRvOnR3YnJheUBnb29nbGUuY29tPl0NClNlbnQ6IFRodXJz ZGF5LCBBcHJpbCAxOCwgMjAxMyA4OjM2IEFNDQpUbzogTWlrZSBKb25lcw0KQ2M6IEp1c3RpbiBS aWNoZXI7IG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4NCg0KU3ViamVjdDog UmU6IFtPQVVUSC1XR10gUmVnaXN0cmF0aW9uOiBTY29wZSBWYWx1ZXMNCg0KT24gdGhlIHNlcnZl ci10by1jbGllbnQgc2lkZSwgd2hhdCBkb2VzIOKAnHJlZ2lzdGVyZWQgdG8gdXNl4oCdIG1lYW4/ ICBEb2VzIGl0IG1lYW4gdGhhdCB0aGUgY2xpZW50IHNob3VsZCBhc3N1bWUgdGhhdCBhbnkgc2Nv cGVzIG5vdCBvbiB0aGUgbGlzdCBXSUxMIG5vdCBiZSBncmFudGVkLCBNQVkgbm90IGJlIGdyYW50 ZWQuLi4uIG9yIHdoYXQ/ICBJcyB0aGlzIGFscmVhZHkgY292ZXJlZCBlbHNld2hlcmU/IC1UDQoN Ck9uIFRodSwgQXByIDE4LCAyMDEzIGF0IDg6MjggQU0sIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9u ZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj4gd3Jv dGU6DQpUaGFua3MsIEp1c3Rpbi4gIEkgYWdyZWUgd2l0aCB0aGUgbmVlZCBmb3IgdGhlIGdlbmVy aWMgdHdvLXNpZGVkIGxhbmd1YWdlLiAgSeKAmWQgc3RpbGwga2VlcCB0aGlzIGxhbmd1YWdlIGZv ciBzY29wZSwgYmVjYXVzZSB3ZSB3YW50IHRvIGNhcHR1cmUgdGhlIOKAnGRlY2xhcmluZ+KAnSBh c3BlY3QgaW4gdGhpcyBjYXNlOg0KDQrigJxTcGFjZSBzZXBhcmF0ZWQgbGlzdCBvZiBzY29wZSB2 YWx1ZXMgKGFzIGRlc2NyaWJlZCBpbiBPQXV0aCAyLjAgU2VjdGlvbiAzLjMgW1JGQzY3NDldPGh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY3NDkjc2VjdGlvbi0zLjM+KSB0aGF0IHRoZSBj bGllbnQgaXMgZGVjbGFyaW5nIHRvIHRoZSBzZXJ2ZXIgdGhhdCBpdCBtYXkgdXNlIHdoZW4gcmVx dWVzdGluZyBhY2Nlc3MgdG9rZW5zIGFuZCB0aGF0IHRoZSBzZXJ2ZXIgaXMgZGVjbGFyaW5nIHRv IHRoZSBjbGllbnQgdGhhdCBpdCBpcyByZWdpc3RlcmVkIHRvIHVzZSB3aGVuIHJlcXVlc3Rpbmcg YWNjZXNzIHRva2Vucy7igJ0uDQoNCllvdSBzaG91bGQgcHJvYmFibHkgYWxzbyByZWluZm9yY2Ug dGhhdCBzY29wZSB2YWx1ZXMgYXJlIHNlcnZpY2Utc3BlY2lmaWMgYW5kIG1heSBub3QgY29uc2lz dCBvbmx5IG9mIGEgc3RhdGljIHNldCBvZiBzdHJpbmcgdmFsdWVzLCBhbmQgdGhhdCB0aGVyZWZv cmUsIGluIHNvbWUgY2FzZXMsIGFuIGV4aGF1c3RpdmUgbGlzdCBvZiByZWdpc3RlcmVkIHNjb3Bl IHZhbHVlcyBpcyBub3QgcG9zc2libGUuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogSnVzdGluIFJp Y2hlciBbbWFpbHRvOmpyaWNoZXJAbWl0cmUub3JnPG1haWx0bzpqcmljaGVyQG1pdHJlLm9yZz5d DQpTZW50OiBNb25kYXksIEFwcmlsIDE1LCAyMDEzIDEyOjI5IFBNDQoNClRvOiBNaWtlIEpvbmVz DQpDYzogVGltIEJyYXk7IG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4NClN1 YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFJlZ2lzdHJhdGlvbjogU2NvcGUgVmFsdWVzDQoNCkkgdGhp bmsgdGhhdCBiZWNhdXNlIHRoZSAiZGVjbGFyYXRpb24iIGlzc3VlIGFmZmVjdHMgYWxsIHBhcmFt ZXRlcnMgaW4gdGhlIGxpc3QsIG5vdCBqdXN0IHNjb3BlLCB3ZSBzaG91bGQgYWRvcHQgdGhpcyBp biBhIGhpZ2hlciBsZXZlbCBwYXJhZ3JhcGggYW5kIGxlYXZlIGl0IG91dCBvZiB0aGUgaW5kaXZp ZHVhbCBwYXJhbWV0ZXIgZGVzY3JpcHRpb25zLiBUaHVzLCBzb21ldGhpbmcgbGlrZSB0aGlzIGlu c2VydGVkIGFzIHRoZSBzZWNvbmQgcGFyYWdyYXBoIGluIHNlY3Rpb24gMjoNClRoZSBjbGllbnQg bWV0YWRhdGEgdmFsdWVzIHNlcnZlIHR3byBwYXJhbGxlbCBwdXJwb3NlcyBpbiB0aGUgb3ZlcmFs bCBPQXV0aCBEeW5hbWljIFJlZ2lzdHJhdGlvbiBwcm90b2NvbDoNCg0KIC0gdGhlIENsaWVudCBy ZXF1ZXN0aW5nIGl0cyBkZXNpcmVkIHZhbHVlcyBmb3IgZWFjaCBwYXJhbWV0ZXIgdG8gdGhlIEF1 dGhvcml6YXRpb24gU2VydmVyIGluIGEgW3JlZ2lzdGVyXSBvciBbdXBkYXRlXSByZXF1ZXN0LA0K IC0gdGhlIEF1dGhvcml6YXRpb24gU2VydmVyIGluZm9ybWluZyB0aGUgQ2xpZW50IG9mIHRoZSBj dXJyZW50IHZhbHVlcyBvZiBlYWNoIHBhcmFtZXRlciB0aGF0IHRoZSBDbGllbnQgaGFzIGJlZW4g cmVnaXN0ZXJlZCB0byB1c2UgdGhyb3VnaCBhIFtjbGllbnQgaW5mb3JtYXRpb24gcmVzcG9uc2Vd Lg0KDQpBbiBBdXRob3JpemF0aW9uIFNlcnZlciBNQVkgb3ZlcnJpZGUgYW55IHZhbHVlIHRoYXQg YSBDbGllbnQgcmVxdWVzdHMgZHVyaW5nIHRoZSByZWdpc3RyYXRpb24gcHJvY2VzcyAoaW5jbHVk aW5nIGFueSBvbWl0dGVkIHZhbHVlcykgYW5kIHJlcGxhY2UgdGhlIHJlcXVlc3RlZCB2YWx1ZSB3 aXRoIGEgZGVmYXVsdC4gVGhlIG5vcm1hdGl2ZSBpbmRpY2F0aW9ucyBpbiB0aGUgZm9sbG93aW5n IGxpc3QgYXBwbHkgdG8gdGhlIENsaWVudCdzIGRlY2xhcmF0aW9uIG9mIGl0cyBkZXNpcmVkIHZh bHVlcy4NCg0KVGhlIEF1dGhvcml6YXRpb24gU2VydmVyIFNIT1VMRCBwcm92aWRlIGRvY3VtZW50 YXRpb24gZm9yIGFueSBmaWVsZHMgdGhhdCBpdCByZXF1aXJlcyB0byBiZSBmaWxsZWQgaW4gYnkg dGhlIGNsaWVudCBvciB0byBoYXZlIHBhcnRpY3VsYXIgdmFsdWVzIG9yIGZvcm1hdHMuIEV4dGVu c2lvbnMgYW5kIHByb2ZpbGVzLi4uDQoNCkFuZCB0aGVuIHJlbW92ZSB0aGUgc2lkZWRuZXNzLWxh bmd1YWdlIGZyb20gdGhlIHNjb3BlIHBhcmFtZXRlciBhbmQgYW55IG90aGVyIHBhcmFtZXRlcnMg d2hlcmUgaXQgbWlnaHQgaGF2ZSBjcmVwdCBpbiBpbmFkdmVydGVudGx5Lg0KDQogLS0gSnVzdGlu DQpPbiAwNC8xNS8yMDEzIDAxOjI5IFBNLCBNaWtlIEpvbmVzIHdyb3RlOg0KV2UgY291bGQgZml4 IHRoZSBvbmUtc2lkZWQgbGFuZ3VhZ2UgYnkgY2hhbmdpbmcNCuKAnFNwYWNlIHNlcGFyYXRlZCBs aXN0IG9mIHNjb3BlIHZhbHVlcyAoYXMgZGVzY3JpYmVkIGluIE9BdXRoIDIuMCBTZWN0aW9uIDMu MyBbUkZDNjc0OV08aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjc0OSNzZWN0aW9uLTMu Mz4pIHRoYXQgdGhlIGNsaWVudCBpcyBkZWNsYXJpbmcgdGhhdCBpdCBtYXkgdXNlIHdoZW4gcmVx dWVzdGluZyBhY2Nlc3MgdG9rZW5zLuKAnQ0KdG8NCuKAnFNwYWNlIHNlcGFyYXRlZCBsaXN0IG9m IHNjb3BlIHZhbHVlcyAoYXMgZGVzY3JpYmVkIGluIE9BdXRoIDIuMCBTZWN0aW9uIDMuMyBbUkZD Njc0OV08aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjc0OSNzZWN0aW9uLTMuMz4pIHRo YXQgdGhlIGNsaWVudCBpcyBkZWNsYXJpbmcgdG8gdGhlIHNlcnZlciB0aGF0IGl0IG1heSB1c2Ug d2hlbiByZXF1ZXN0aW5nIGFjY2VzcyB0b2tlbnMgYW5kIHRoYXQgdGhlIHNlcnZlciBpcyBkZWNs YXJpbmcgdG8gdGhlIGNsaWVudCB0aGF0IGl0IGlzIHJlZ2lzdGVyZWQgdG8gdXNlIHdoZW4gcmVx dWVzdGluZyBhY2Nlc3MgdG9rZW5zLuKAnS4NCg0KQWdhaW4sIEkgY2hvc2UgdGhlIOKAnHJlZ2lz dGVyZWQgdG8gdXNl4oCdIGxhbmd1YWdlIGNhcmVmdWxseSDigJMgYmVjYXVzZSBpbiB0aGUgZ2Vu ZXJhbCBjYXNlIGl04oCZcyBub3QgYSByZXN0cmljdGlvbiBvbiB0aGUgdmFsdWVzIHRoYXQgdGhl IGNsaWVudCBjYW4gdXNlIOKAkyBqdXN0IGEgc3RhdGVtZW50IGJ5IHRoZSBzZXJ2ZXIgdG8gdGhl IGNsaWVudCB0aGF0IGl0IGlzIHJlZ2lzdGVyZWQgdG8gdXNlIHRob3NlIHBhcnRpY3VsYXIgdmFs dWVzLiAgSW4gYm90aCBjYXNlcywgdGhlIHBhcnRpZXMgYXJlIG1ha2luZyBkZWNsYXJhdGlvbnMg dG8gb25lIGFub3RoZXIuDQoNCklmIHlvdSBhZG9wdCB0aGF0IGxhbmd1YWdlIChvciBrZWVwIHRo ZSBvcmlnaW5hbCBsYW5ndWFnZSksIHRoZW4geWVzLCBJ4oCZZCBjb25zaWRlciB0aGlzIGNsb3Nl ZC4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBKdXN0aW4gUmljaGVyIFttYWlsdG86anJpY2hlckBt aXRyZS5vcmddDQpTZW50OiBNb25kYXksIEFwcmlsIDE1LCAyMDEzIDk6NTcgQU0NClRvOiBNaWtl IEpvbmVzDQpDYzogVGltIEJyYXk7IG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9y Zz4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFJlZ2lzdHJhdGlvbjogU2NvcGUgVmFsdWVzDQoN CkkgYWJzb2x1dGVseSBkbyBub3Qgd2FudCB0byBkZWxldGUgdGhpcyBmZWF0dXJlLCBhcyAoaGF2 aW5nIGltcGxlbWVudGVkIGl0KSBJIHRoaW5rIGl0J3MgdmVyeSB1c2VmdWwuIFRoaXMgaXMgYSB2 ZXJ5IGVzdGFibGlzaGVkIHBhdHRlcm4gaW4gbWFudWFsIHJlZ2lzdHJhdGlvbjogSSBrbm93IG9m IG1hbnksIG1hbnkgT0F1dGgyIHNlcnZlcnMgYW5kIGNsaWVudHMgdGhhdCBhcmUgc2V0IHVwIHdo ZXJlIHRoZSBjbGllbnQgbXVzdCBwcmUtcmVnaXN0ZXIgYSBzZXQgb2Ygc2NvcGVzLg0KDQpJIGRv bid0IGxpa2UgdGhlIGxhbmd1YWdlIG9mICJ0aGUgY2xpZW50IGlzIGRlY2xhcmluZyIgYmVjYXVz ZSBpdCdzIHRvbyBvbmUtc2lkZWQuIFRoZSBjbGllbnQgbWlnaHQgbm90IGhhdmUgZGVjbGFyZWQg YW55dGhpbmcsIGFuZCBpdCBtaWdodCBiZSB0aGUgc2VydmVyIHRoYXQncyBkZWNsYXJpbmcgc29t ZXRoaW5nIHRvIHRoZSBjbGllbnQuIERlbGV0aW5nIHRoZSAiaXMgZGVjbGFyaW5nIiBiaXQgcmVt b3ZlcyB0aGF0IHVuaW50ZW5kZWQgcmVzdHJpY3Rpb24gb2YgdGhlIGxhbmd1YWdlIHdoaWxlIGtl ZXBpbmcgdGhlIG9yaWdpbmFsIG1lYW5pbmcgaW50YWN0LiBJIGFjdHVhbGx5IHRob3VnaHQgdGhh dCBJIGhhZCBmaXhlZCB0aGF0IGJlZm9yZSB0aGUgbGFzdCBkcmFmdCB3ZW50IGluIGJ1dCBhcHBh cmVudGx5IEkgbWlzc2VkIHRoaXMgb25lLg0KDQpJIHdpbGwgd29yayBvbiBjbGFyaWZ5aW5nIHRo ZSBpbnRlbnQgb2YgdGhlIHdob2xlIG1ldGFkYXRhIHNldCBpbiBpdHMgaW50cm9kdWN0b3J5IHBh cmFncmFwaChzKSBzbyB0aGF0IGl0J3MgY2xlYXIgdGhhdCBhbGwgb2YgdGhlc2UgZmllbGRzIGFy ZSB1c2VkIGluIGJvdGggb2YgdGhlc2Ugc2l0dWF0aW9uczoNCg0KIDEpIFRoZSBjbGllbnQgZGVj bGFyaW5nIHRvIHRoZSBzZXJ2ZXIgaXRzIGRlc2lyZSB0byB1c2UgYSBwYXJ0aWN1bGFyIHZhbHVl DQogMikgVGhlIHNlcnZlciBkZWNsYXJpbmcgdG8gdGhlIGNsaWVudCB0aGF0IGl0IGhhcyBiZWVu IHJlZ2lzdGVyZWQgd2l0aCBhIHBhcnRpY3VsYXIgdmFsdWUNCg0KVGhpcyBzaG91bGQgaG9wZWZ1 bGx5IGNsZWFyIHVwIHRoZSBpc3N1ZSBpbiB0aGUgZWRpdG9yJ3Mgbm90ZSB0aGF0IEkgY3VycmVu dGx5IGhhdmUgYXQgdGhlIHRvcCBvZiB0aGF0IHNlY3Rpb24gcmlnaHQgbm93LCB0b28uDQoNCk1p a2UsIHNpbmNlIHlvdSB3ZXJlIHRoZSBvbmUgd2hvIG9yaWdpbmFsbHkgYnJvdWdodCB1cCB0aGUg aXNzdWUsIGFuZCB5b3UncmUgZmluZSB3aXRoIHRoZSBleGlzdGluZyB0ZXh0LCBjYW4gSSB0YWtl IHRoaXMgYXMgY2xvc2VkIG5vdz8gQXNzdW1pbmcgdGhhdCB5b3UgYWdyZWUgd2l0aCBkZWxldGlu ZyAiaXMgZGVjbGFyaW5nIiBmb3IgcmVhc29ucyBzdGF0ZWQgYWJvdmUsIEknbSBmaW5lIHdpdGgg bGVhdmluZyBldmVyeXRoaW5nIGVsc2UgYXMgaXMgYW5kIHN0YXlpbmcgcXVpZXQgb24gd2hhdCB0 aGUgc2VydmVyIGhhcyB0byBkbyB3aXRoIHRoZSBzY29wZXMuDQoNCiAtLSBKdXN0aW4NCk9uIDA0 LzE1LzIwMTMgMTI6NDQgUE0sIE1pa2UgSm9uZXMgd3JvdGU6DQpJIHRoaW5rIHRoYXQgdGhlIGV4 aXN0aW5nIHdvcmRpbmcgaXMgc3VwZXJpb3IgdG8gdGhlIHByb3Bvc2VkIGNoYW5nZWQgd29yZGlu Zy4gIFRoZSBleGlzdGluZyB3b3JkaW5nIGlzOg0KDQogICBzY29wZQ0KICAgICAgT1BUSU9OQUwu ICBTcGFjZSBzZXBhcmF0ZWQgbGlzdCBvZiBzY29wZSB2YWx1ZXMgKGFzIGRlc2NyaWJlZCBpbg0K ICAgICAgT0F1dGggMi4wIFNlY3Rpb24gMy4zIFtSRkM2NzQ5XTxodHRwOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9yZmM2NzQ5I3NlY3Rpb24tMy4zPikgdGhhdCB0aGUgY2xpZW50IGlzIGRlY2xhcmlu ZyB0aGF0DQogICAgICBpdCBtYXkgdXNlIHdoZW4gcmVxdWVzdGluZyBhY2Nlc3MgdG9rZW5zLiAg SWYgb21pdHRlZCwgYW4NCiAgICAgIEF1dGhvcml6YXRpb24gU2VydmVyIE1BWSByZWdpc3RlciBh IENsaWVudCB3aXRoIGEgZGVmYXVsdCBzZXQgb2YNCiAgICAgIHNjb3Blcy4NCg0KRm9yIGluc3Rh bmNlLCB0aGUgY3VycmVudCDigJxjbGllbnQgaXMgZGVjbGFyaW5n4oCdIHdvcmRpbmcgd2lsbCBh bHdheXMgYmUgY29ycmVjdCwgd2hlcmVhcyBhcyB0aGUgY2hhbmdlIHRvIOKAnGNsaWVudCBjYW4g dXNl4oCdIHdvcmRpbmcgaW1wbGllcyBhIHJlc3RyaWN0aW9uIG9uIGNsaWVudCBiZWhhdmlvciB0 aGF0IGlzIG5vdCBhbHdheXMgYXBwbGljYWJsZS4gIFRoZSDigJxjbGllbnQgaXMgZGVjbGFyaW5n 4oCdIHdvcmRpbmcgd2FzIHNwZWNpZmljIGFuZCBwdXJwb3NlZnVsbHkgY2hvc2VuLCBhbmQgSSB0 aGluayBzaG91bGQgYmUgcmV0YWluZWQuICBJbiBwYXJ0aWN1bGFyLCB3ZSBjYW7igJl0IGRvIGFu eXRoaW5nIHRoYXQgaW1wbGllcyB0aGF0IG9ubHkgdGhlIHJlZ2lzdGVyZWQgc2NvcGVzIHZhbHVl cyBjYW4gYmUgdXNlZC4gIEF0IHRoZSBPQXV0aCBzcGVjIGxldmVsLCB0aGlzIGlzIGEgaGludCBh cyB0byBwb3NzaWJsZSBmdXR1cmUgY2xpZW50IGJlaGF2aW9yIOKAkyBub3QgYSByZXN0cmljdGlv biBvbiBmdXR1cmUgY2xpZW50IGJlaGF2aW9yLg0KDQpBbHNvLCBmb3IgdGhlIHJlYXNvbnMgdGhh dCBUaW0gc3RhdGVkLCBJ4oCZbSBzdHJvbmdseSBhZ2FpbnN0IGFueSDigJxtYXRjaGluZ+KAnSBv ciDigJxyZWdleOKAnSBsYW5ndWFnZSBpbiB0aGUgc3BlYyBwZXJ0YWluaW5nIHRvIHNjb3BlcyDi gJMgYXMgaXTigJlzIG5vdCBhY3Rpb25hYmxlLg0KDQpTbyBJ4oCZZCBwcm9wb3NlIHRoYXQgd2Ug bGVhdmUgdGhlIGV4aXN0aW5nIHNjb3BlIHdvcmRpbmcgaW4gcGxhY2UuICBBbHRlcm5hdGl2ZWx5 LCBJ4oCZZCBhbHNvIGJlIGZpbmUgd2l0aCBkZWxldGluZyB0aGlzIGZlYXR1cmUgZW50aXJlbHks IGFzIEkgZG9u4oCZdCB0aGluayBpdOKAmXMgdXNlZnVsIGluIHRoZSBnZW5lcmFsIGNhc2UuDQoN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIC0tIE1pa2UNCg0KRnJvbTogb2F1dGgtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86b2F1dGgt Ym91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgSnVzdGluIFJpY2hlcg0KU2VudDogTW9uZGF5LCBBcHJpbCAxNSwgMjAxMyA4OjA1IEFN DQpUbzogVGltIEJyYXk7IG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4NClN1 YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFJlZ2lzdHJhdGlvbjogU2NvcGUgVmFsdWVzDQoNCk9uIDA0 LzE1LzIwMTMgMTA6NTIgQU0sIFRpbSBCcmF5IHdyb3RlOg0KSeKAmWQgdXNlIHRoZSBleGlzdGlu ZyB3b3JkaW5nOyBpdOKAmXMgcGVyZmVjdGx5IGNsZWFyLiAgRmFpbGluZyB0aGF0LCBpZiB0aGVy ZeKAmXMgc3Ryb25nIGRlbWFuZCBmb3IgcmVnaXN0cmF0aW9uIG9mIHN0cnVjdHVyZWQgc2NvcGVz LCBibGVzcyB0aGUgdXNlIG9mIHJlZ2V4ZXMsIGVpdGhlciBQQ1JFcyBvciBzb21lIGNhcmVmdWwg c3Vic2V0Lg0KDQpUaGFua3MgZm9yIHRoZSBmZWVkYmFjayAtLSBPZiB0aGVzZSB0d28gY2hvaWNl cywgSSdkIHJhdGhlciBsZWF2ZSBpdCBhcy1pcy4NCg0KDQpIb3dldmVyLCBJ4oCZZCBzdWJ0cmFj dCB0aGUgc2VudGVuY2Ug4oCcSWYgb21pdHRlZCwgYW4gQXV0aG9yaXphdGlvbiBTZXJ2ZXIgTUFZ IHJlZ2lzdGVyIGEgQ2xpZW50IHdpdGggYSBkZWZhdWx0IHNldCBvZiAgc2NvcGVzLuKAnSAgSXQg YWRkcyBubyB2YWx1ZTsgaWYgdGhlIGNsaWVudCBkb2VzbuKAmXQgZGVjbGFyZSBzY29wZXMsIHRo ZSBjbGllbnQgZG9lc27igJl0IGRlY2xhcmUgc2NvcGVzLCB0aGF04oCZcyBhbGwuICAtVA0KDQpS ZW1lbWJlciwgYWxsIG9mIHRoZXNlIGZpZWxkcyBhcmVuJ3QganVzdCBmb3IgdGhlIGNsaWVudCAq cmVxdWVzdCosIHRoZXkncmUgYWxzbyBmb3IgdGhlIHNlcnZlcidzICpyZXNwb25zZSogdG8gZWl0 aGVyIGEgUE9TVCwgUFVULCBvciBHRVQgcmVxdWVzdC4gKEkgZGlkbid0IHJlYWxpemUgaXQsIGJ1 dCBwZXJoYXBzIHRoZSB3b3JkaW5nIGFzIHN0YXRlZCByaWdodCBub3cgZG9lc24ndCBtYWtlIHRo YXQgY2xlYXIgLS0gSSBuZWVkIHRvIGZpeCB0aGF0LikgVGhlIHZhbHVlIHRoYXQgaXQgYWRkcyBp cyBpZiB0aGUgY2xpZW50IGRvZXNuJ3QgYXNrIGZvciBhbnkgcGFydGljdWxhciBzY29wZXMsIHRo ZSBzZXJ2ZXIgY2FuIHN0aWxsIGFzc2lnbiBpdCBzY29wZXMgYW5kIHRoZSBjbGllbnQgY2FuIGRv IHNvbWV0aGluZyBzbWFydCB3aXRoIHRoYXQuIER1bWIgY2xpZW50cyBhcmUgYWxsb3dlZCB0byBp Z25vcmUgaXQgaWYgaXQgZG9lc24ndCBtZWFuIGFueXRoaW5nIHRvIHRoZW0uDQoNClRoaXMgaXMg aG93IG91ciBzZXJ2ZXIgaW1wbGVtZW50YXRpb24gYWN0dWFsbHkgd29ya3MgcmlnaHQgbm93LiBJ ZiB0aGUgY2xpZW50IGRvZXNuJ3QgYXNrIGZvciBhbnl0aGluZyBzcGVjaWZpYyBhdCByZWdpc3Ry YXRpb24sIHRoZSBzZXJ2ZXIgaGFuZHMgaXQgYSBiYWcgb2YgImRlZmF1bHQiIHNjb3Blcy4gU2Ft ZSB0aGluZyBoYXBwZW5zIGF0IGF1dGggdGltZSAtLSBpZiB0aGUgY2xpZW50IGRvZXNuJ3QgYXNr IGZvciBhbnkgcGFydGljdWxhciBzY29wZXMsIHRoZSBzZXJ2ZXIgaGFuZHMgaXQgYWxsIG9mIGl0 cyByZWdpc3RlcmVkIHNjb3BlcyBhcyBhIGRlZmF1bHQuIEdyYW50ZWQsIG9uIG91ciBzZXJ2ZXIs IHNjb3BlcyBhcmUganVzdCBzaW1wbGUgc3RyaW5ncyByaWdodCBub3csIHNvIHRoZXkgZ2V0IGNv bXBhcmVkIGF0IHRoZSBhdXRoIGVuZHBvaW50IHdpdGggYW4gZXhhY3Qgc3RyaW5nLW1hdGNoIG1l dHJpYyBhbmQgc2V0LWJhc2VkIGxvZ2ljLg0KDQogLS0gSnVzdGluDQoNCg0KT24gTW9uLCBBcHIg MTUsIDIwMTMgYXQgNzozNSBBTSwgSnVzdGluIFJpY2hlciA8anJpY2hlckBtaXRyZS5vcmc8bWFp bHRvOmpyaWNoZXJAbWl0cmUub3JnPj4gd3JvdGU6DQpXaGF0IHdvdWxkIHlvdSBzdWdnZXN0IGZv ciB3b3JkaW5nIGhlcmUsIHRoZW4/IEtlZXBpbmcgaW4gbWluZCB0aGF0IHdlIGNhbm5vdCAoYW5k IGRvbid0IHdhbnQgdG8pIHByb2hpYml0IGV4cHJlc3Npb24tYmFzZWQgc2NvcGVzLg0KDQogLS0g SnVzdGluDQoNCk9uIDA0LzE1LzIwMTMgMTA6MzMgQU0sIFRpbSBCcmF5IHdyb3RlOg0KTm8sIEkg bWVhbiBpdOKAmXMgbm90IGludGVyb3BlcmFibGUgYXQgdGhlIHNvZnR3YXJlLWRldmVsb3BlciBs ZXZlbC4gIEkgY2Fu4oCZdCByZWdpc3RlciBzY29wZXMgYXQgYXV0aG9yaXphdGlvbiB0aW1lIHdp dGggYW55IHByZWRpY3RhYmxlIGVmZmVjdCB0aGF0IEkgY2FuIHdyaXRlIGNvZGUgdG8gc3VwcG9y dCwgZWl0aGVyIGNsaWVudCBvciBzZXJ2ZXIgc2lkZSwgd2l0aG91dCBvdXQtb2YtbGluZSBub24t aW50ZXJvcGVyYWJsZSBrbm93bGVkZ2UgYWJvdXQgdGhlIGJlaGF2aW9yIG9mIHRoZSBzZXJ2ZXIu DQoNCkkgZ3Vlc3MgSeKAmW0ganVzdCBub3QgdXNlZCB0byBPQXV0aOKAmXMgY3VsdHVyZSBvZiBo YXZpbmcgbm8gZXhwZWN0YXRpb24gdGhhdCB0aGluZ3Mgd2lsbCBiZSBzcGVjaWZpZWQgdGlnaHRs eSBlbm91Z2ggdGhhdCBJIGNhbiB3cml0ZSBjb2RlIHRvIGltcGxlbWVudCBhcyBzcGVjaWZpZWQu ICAtVA0KDQpPbiBNb24sIEFwciAxNSwgMjAxMyBhdCA3OjE1IEFNLCBKdXN0aW4gUmljaGVyIDxq cmljaGVyQG1pdHJlLm9yZzxtYWlsdG86anJpY2hlckBtaXRyZS5vcmc+PiB3cm90ZToNClNjb3Bl cyBhcmVuJ3QgbWVhbnQgdG8gYmUgaW50ZXJvcGVyYWJsZSBiZXR3ZWVuIHNlcnZpY2VzIHNpbmNl IHRoZXkncmUgbmVjZXNzYXJpbHkgQVBJLXNwZWNpZmljLiBUaGUgb25seSBpbnRlcm9wZXJhYmxl IGJpdCBpcyB0aGF0IHRoZXJlJ3MgKnNvbWUqIHBsYWNlIHRvIHB1dCB0aGUgdmFsdWVzIGFuZCB0 aGF0IGl0J3MgZXhwcmVzc2VkIGFzIGEgYmFnIG9mIHNwYWNlLXNlcGFyYXRlZCBzdHJpbmdzLiBI b3cgdGhvc2Ugc3RyaW5ncyBnZXQgaW50ZXJwcmV0ZWQgYW5kIGVuZm9yY2VkICh3aGljaCBpcyBy ZWFsbHkgd2hhdCdzIGF0IHN0YWtlIGhlcmUpIGlzIHVwIHRvIHRoZSBBUyBhbmQgUFIgKG9yIGEg aGlnaGVyLWxldmVsIHByb3RvY29sIGxpa2UgVU1BKS4NCg0KIC0tIEp1c3Rpbg0KDQpPbiAwNC8x NS8yMDEzIDEwOjEzIEFNLCBUaW0gQnJheSB3cm90ZToNCg0KVGhpcywgYXMgd3JpdHRlbiwgaGFz IHplcm8gaW50ZXJvcGVyYWJpbGl0eS4gIEkgdGhpbmsgdGhpcyBmZWF0dXJlIGNhbiByZWFsbHkg b25seSBiZSBtYWRlIHVzZWZ1bCBpbiB0aGUgY2FzZSB3aGVyZSBzY29wZXMgYXJlIGZpeGVkIHN0 cmluZ3MuDQoNCi1UDQpPbiBBcHIgMTUsIDIwMTMgNjo1NCBBTSwgIkp1c3RpbiBSaWNoZXIiIDxq cmljaGVyQG1pdHJlLm9yZzxtYWlsdG86anJpY2hlckBtaXRyZS5vcmc+PiB3cm90ZToNCllvdSBh cmUgY29ycmVjdCB0aGF0IHRoZSBpZGVhIGJlaGluZCB0aGUgInNjb3BlIiBwYXJhbWV0ZXIgYXQg cmVnaXN0cmF0aW9uIGlzIGEgY29uc3RyYWludCBvbiBhdXRob3JpemF0aW9uLXRpbWUgc2NvcGVz IHRoYXQgYXJlIG1hZGUgYXZhaWxhYmxlLiBJdCdzIGJvdGggYSBtZWFucyBmb3IgdGhlIGNsaWVu dCB0byByZXF1ZXN0IGEgc2V0IG9mIHZhbGlkIHNjb3BlcyBhbmQgZm9yIHRoZSBzZXJ2ZXIgdG8g cHJvdmlzaW9uIChhbmQgZWNobyBiYWNrIHRvIHRoZSBjbGllbnQpIGEgc2V0IG9mIHZhbGlkIHNj b3Blcy4NCg0KSSAqcmVhbGx5KiBkb24ndCB3YW50IHRvIHRyeSB0byBkZWZpbmUgYSBtYXRjaGlu ZyBsYW5ndWFnZSBmb3Igc2NvcGUgZXhwcmVzc2lvbnMuIEZvciB0aGF0IHRvIHdvcmssIGFsbCBz ZXJ2ZXJzIHdvdWxkIG5lZWQgdG8gYmUgYWJsZSB0byBwcm9jZXNzIHRoZSByZWd1bGFyIGV4cHJl c3Npb25zIGZvciBhbGwgY2xpZW50cywgZXZlbiBpZiB0aGUgc2VydmVycyB0aGVtc2VsdmVzIG9u bHkgc3VwcG9ydCBzaW1wbGUtc3RyaW5nIHNjb3BlIHZhbHVlcy4gQW55IHJlZ3VsYXIgZXhwcmVz c2lvbiBzeW50YXggd2UgcGljayBoZXJlIGlzIGd1YXJhbnRlZWQgdG8gYmUgaW5jb21wYXRpYmxl IHdpdGggc29tZXRoaW5nLCBhbmQgSSB0aGluayB0aGUgY29tcGxleGl0eSBkb2Vzbid0IGJ1eSBt dWNoLiBBbHNvLCBJIHRoaW5rIHlvdSBzdWRkZW5seSBoYXZlIGEgcG90ZW50aWFsIHNlY3VyaXR5 IGlzc3VlIGlmIHlvdSBoYXZlIGEgYmFkIHJlZ2V4IGluIHBsYWNlIG9uIGVpdGhlciBlbmQuDQoN CkFzIGl0IHN0YW5kcyB0b2RheSwgdGhlIHNlcnZlciBjYW4gaW50ZXJwcmV0IHRoZSBpbmNvbWlu ZyByZWdpc3RyYXRpb24gc2NvcGVzIGFuZCBlbmZvcmNlIHRoZW0gaG93ZXZlciBpdCB3YW50cyB0 by4gVGhlIHJlYWwgdHJpY2sgY29tZXMgbm90IGZyb20gYXNzaWduaW5nIHRoZSB2YWx1ZXMgdG8g YSBwYXJ0aWN1bGFyIGNsaWVudCBidXQgdG8gZW5mb3JjaW5nIHRoZW0sIGFuZCBJIHRoaW5rIHRo YXQncyBhbHdheXMgZ29pbmcgdG8gYmUgc2VydmljZS1zcGVjaWZpYy4gV2UncmUganVzdCBub3Qg YXMgY2xlYXIgb24gdGhhdCBhcyB3ZSBjb3VsZCBiZS4NCg0KQWZ0ZXIgbG9va2luZyBvdmVyIGV2 ZXJ5b25lJ3MgY29tbWVudHMgc28gZmFyLCBJJ2QgbGlrZSB0byBwcm9wb3NlIHRoZSBmb2xsb3dp bmcgdGV4dCBmb3IgdGhhdCBzZWN0aW9uOg0KDQogICBzY29wZQ0KDQogICAgICBPUFRJT05BTC4g IFNwYWNlIHNlcGFyYXRlZCBsaXN0IG9mIHNjb3BlIHZhbHVlcyAoYXMgZGVzY3JpYmVkIGluDQoN CiAgICAgIE9BdXRoIDIuMCBTZWN0aW9uIDMuMyBbUkZDNjc0OV08aHR0cDovL3Rvb2xzLmlldGYu b3JnL2h0bWwvcmZjNjc0OSNzZWN0aW9uLTMuMz4pIHRoYXQgdGhlIGNsaWVudCBjYW4gdXNlIHdo ZW4NCg0KICAgICAgcmVxdWVzdGluZyBhY2Nlc3MgdG9rZW5zLiAgQXMgc2NvcGUgdmFsdWVzIGFy ZSBzZXJ2aWNlLXNwZWNpZmljLA0KDQogICAgICB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgTUFZ IGRlZmluZSBpdHMgb3duIG1hdGNoaW5nIHJ1bGVzIHdoZW4NCg0KICAgICAgZGV0ZXJtaW5pbmcg aWYgYSBzY29wZSB2YWx1ZSB1c2VkIGR1cmluZyBhbiBhdXRob3JpemF0aW9uIHJlcXVlc3QNCg0K ICAgICAgaXMgdmFsaWQgYWNjb3JkaW5nIHRvIHRoZSBzY29wZSB2YWx1ZXMgYXNzaWduZWQgZHVy aW5nDQoNCiAgICAgIHJlZ2lzdHJhdGlvbi4gUG9zc2libGUgbWF0Y2hpbmcgcnVsZXMgaW5jbHVk ZSB3aWxkY2FyZCBwYXR0ZXJucywNCg0KICAgICAgcmVndWxhciBleHByZXNzaW9ucywgb3IgZXhh Y3RseSBtYXRjaGluZyB0aGUgc3RyaW5nLiBJZiBvbWl0dGVkLA0KDQogICAgICBhbiBBdXRob3Jp emF0aW9uIFNlcnZlciBNQVkgcmVnaXN0ZXIgYSBDbGllbnQgd2l0aCBhIGRlZmF1bHQNCg0KICAg ICAgc2V0IG9mIHNjb3Blcy4NCg0KQ29tbWVudHM/IEltcHJvdmVtZW50cz8NCg0KIC0tIEp1c3Rp bg0KT24gMDQvMTQvMjAxMyAwODoyMyBQTSwgTWFuZ2VyLCBKYW1lcyBIIHdyb3RlOg0KDQpQcmVz dW1hYmx5IGF0IGFwcCByZWdpc3RyYXRpb24gdGltZSBhbnkgc2NvcGUgc3BlY2lmaWNhdGlvbiBp cyByZWFsbHkgYSBjb25zdHJhaW50IG9uIHRoZSBzY29wZSB2YWx1ZXMgdGhhdCBjYW4gYmUgcmVx dWVzdGVkIGluIGFuIGF1dGhvcml6YXRpb24gZmxvdy4NCg0KDQoNClNvIGlkZWFsbHkgcmVnaXN0 cmF0aW9uIHNob3VsZCBhY2NlcHQgcnVsZXMgZm9yIG1hdGNoaW5nIHNjb3BlcywgYXMgb3Bwb3Nl ZCB0byBhY3R1YWwgc2NvcGUgdmFsdWVzLg0KDQoNCg0KWW91IGNhbiB0cnkgdG8gdXNlIHNjb3Bl IHZhbHVlcyBhcyB0aGVpciBvd24gbWF0Y2hpbmcgcnVsZXMuIFRoYXQgaXMgZmluZSBmb3IgYSBz bWFsbCBzZXQgb2YgInN0YXRpYyIgc2NvcGVzLiBJdCBzdGFydHMgdG8gZmFpbCB3aGVuIHRoZXJl IGFyZSBhIGxhcmdlIG51bWJlciBvZiBzY29wZXMsIG9yIHNjb3BlcyB0aGF0IGNhbiBpbmNsdWRl IHBhcmFtZXRlcnMgKHJlc291cmNlIHBhdGhzPyBlbWFpbCBhZGRyZXNzZXM/KS4gWW91IGNhbiB0 cnkgdG8gcGF0Y2ggdGhvc2UgZmFpbHVyZXMgYnkgYWxsb3dpbmcgc2VydmljZXMgdG8gZGVmaW5l IHNlcnZpY2Utc3BlY2lmaWMgc3BlY2lhbCAid2lsZGNhcmQiIHNjb3BlIHZhbHVlcyB0aGF0IGNh biBvbmx5IGJlIHVzZWQgZHVyaW5nIHJlZ2lzdHJhdGlvbiAoZWcgInJlYWQ6KiIpLg0KDQoNCg0K QWx0ZXJuYXRpdmVseSwgcmVwbGFjZSAnc2NvcGUnIGluIHJlZ2lzdHJhdGlvbiB3aXRoICdzY29w ZV9yZWdleCcgdGhhdCBob2xkcyBhIHJlZ3VsYXIgZXhwcmVzc2lvbiB0aGF0IGFsbCBzY29wZSB2 YWx1ZXMgaW4gYW4gYXV0aG9yaXphdGlvbiBmbG93IG11c3QgbWF0Y2guDQoNCg0KDQotLQ0KDQpK YW1lcyBNYW5nZXINCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCg0KT0F1dGggbWFpbGluZyBsaXN0DQoNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0 aEBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0 aA0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpP QXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KDQoNCg0KDQoN Cg0KDQoNCg0K --_000_04cb3c88970842de9b0ec1162e8a86dbBY2PR03MB041namprd03pro_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglw YW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyBcO2NvbG9yXDp3aW5kb3d0ZXh0Ijt9DQovKiBTdHlsZSBEZWZpbml0aW9u cyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46 MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVy bGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1z dHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpD b25zb2xhczt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1y ZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5 N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRp di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5DbGllbnQgYXNrcyBmb3Igbm90aGluZyBhbmQgdGhlIHNlcnZl ciByZXR1cm5zIOKAnEHigJ0sIHRodXMgZG9lcyBub3QgbWF0Y2ggeW91ciDigJxJIHByb21pc2Ug dG8gYXNrIG9ubHkgZm9yIHRoZXNl4oCdIGFuZCBmcm9tIHRoZSBzZXJ2ZXIg4oCcVGhlc2UgYXJl IHRoZSBvbmx5IG9uZXMNCiBJ4oCZbGwgZ2l2ZSB5b3UgdG9rZW5zIGZvci7igJ3igJ0gQXMgdGhl IGNsaWVudCBtYXkgYWxzbyBhc2sgZm9yIFggYW5kIGdldCBYLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvYT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBU aW0gQnJheSBbbWFpbHRvOnR3YnJheUBnb29nbGUuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRo dXJzZGF5LCBBcHJpbCAxOCwgMjAxMyA5OjI2IEFNPGJyPg0KPGI+VG86PC9iPiBBbnRob255IE5h ZGFsaW48YnI+DQo8Yj5DYzo8L2I+IE1pa2UgSm9uZXM7IG9hdXRoQGlldGYub3JnPGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIFJlZ2lzdHJhdGlvbjogU2NvcGUgVmFsdWVzPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SG0uLi4gaG93IHNvPyAmbmJzcDtJ ZiBhIHNlcnZlciBpcyBhYmxlIHRvIHNwZWNpZnkgaW4gYWR2YW5jZSB3aGljaCBzZXQgb2Ygc2Nv cGVzIGl0IHdpbGwgaG9ub3IgKHdoaWNoIG1heSBvciBtYXkgbm90IGJlIHJlbGF0ZWQgdG8gd2hh dCB0aGUgY2xpZW50IHNwZWNpZmllZCBpbiB0aGUgcmVnaXN0cmF0aW9uKSBJIGNhbiBzZWUgdGhh dCBiZWluZyB1c2VmdWwuICZuYnNwO0kgZG9u4oCZdCBzZWUgYSByZXF1aXJlbWVudCBmb3IgYQ0K IGxpbmthZ2UgYmV0d2VlbiB0aGUgY2xpZW504oCZcyByZXF1ZXN0IGFuZCB0aGUgc2VydmVy4oCZ cyByZXNwb25zZS4gJm5ic3A7LVQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBBcHIgMTgsIDIw MTMgYXQgOToxMyBBTSwgQW50aG9ueSBOYWRhbGluICZsdDs8YSBocmVmPSJtYWlsdG86dG9ueW5h ZEBtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+dG9ueW5hZEBtaWNyb3NvZnQuY29tPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5JZiBJIGRvbuKAmXQgc3BlY2lmeSBhIHNjb3BlLCB0aGVuIHRoZSBzZXJ2ZXIgY2Fu IGFsbG9jYXRlIGEgZGVmYXVsdCAob3IgZGVmYXVsdCBzZXQpLCB0aHVzIHRoYXQgYnJlYWtzDQog dGhlIHNlbWFudGljcyB5b3UgZGVzY3JpYmU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxhIG5hbWU9IjEzZTFkZWVkZWEyMDE0YWRfX01haWxFbmRDb21wb3Nl Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4NCjxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT4gW21haWx0bzo8YSBocmVmPSJtYWls dG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoLWJvdW5jZXNA aWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5UaW0gQnJheTxicj4NCjxiPlNlbnQ6 PC9iPiBUaHVyc2RheSwgQXByaWwgMTgsIDIwMTMgOTowNCBBTTxicj4NCjxiPlRvOjwvYj4gTWlr ZSBKb25lczxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+b2F1dGhAaWV0Zi5vcmc8L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8Yj5TdWJqZWN0OjwvYj4g UmU6IFtPQVVUSC1XR10gUmVnaXN0cmF0aW9uOiBTY29wZSBWYWx1ZXM8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5J4oCZbSB1 bmNvbnZpbmNlZCwgTWlrZS4gJm5ic3A7T2J2aW91c2x5IHlvdeKAmXJlIHJpZ2h0IGFib3V0IHRo ZSBsb29zZW5lc3Mgb2YgT0F1dGgyIHNjb3BlIHNwZWNpZmljYXRpb24sIGJ1dCB0aGlzIGlzIGEg dmVyeSBzcGVjaWZpYyBzZW1hbnRpYyBvZiB3aGF0IGhhcHBlbnMgd2hlbiB5b3UgcmVnaXN0ZXIs IGFuZCBJIGRvbuKAmXQNCiB0aGluayB3ZeKAmXJlIGJvdW5kIGJ5IGhpc3RvcnkgaGVyZS4gJm5i c3A7IElmIHdlIGNhbuKAmXQgc2FmZWx5IHNheSBhbnl0aGluZyBhYm91dCB3aGF0IHRoZSBsaXN0 IG9mIHNjb3BlcyBtZWFucywgdGhlbiBJJ20gd2l0aCB5b3UgbGV0J3MgdGFrZSB0aGVtIG91dC4g Jm5ic3A7QnV0IHRoZSBtb3N0IG9idmlvdXMgaW50ZW5kZWQgc2VtYW50aWMgaXMgKGZyb20gdGhl IGNsaWVudCkg4oCcSSBwcm9taXNlIHRvIGFzayBvbmx5IGZvciB0aGVzZeKAnSBhbmQgZnJvbSB0 aGUgc2VydmVyDQog4oCcVGhlc2UgYXJlIHRoZSBvbmx5IG9uZXMgSeKAmWxsIGdpdmUgeW91IHRv a2VucyBmb3Iu4oCdICZuYnNwO09yIGRvZXMgc29tZW9uZSBoYXZlIHVzZS1jYXNlcyBmb3IgYW4g YWx0ZXJuYXRpdmUgc2VtYW50aWM/PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+VG8gbWFrZSB0aGlzIGNvbmNyZXRlLCBJIHByb3Bvc2UgdGhlIGZvbGxv d2luZzo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzttYXJnaW4tbGVmdDouNWluIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj7igJw8L3NwYW4+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5TcGFjZS1zZXBhcmF0ZWQgbGlz dCBvZiBzY29wZSB2YWx1ZXMgKGFzIGRlc2NyaWJlZCBpbiBPQXV0aCAyLjAmbmJzcDs8YSBocmVm PSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2NzQ5I3NlY3Rpb24tMy4zIiB0YXJnZXQ9 Il9ibGFuayI+U2VjdGlvbiZuYnNwOzMuMw0KIFtSRkM2NzQ5XTwvYT4pIHRoYXQgdGhlIGNsaWVu dCBpcyBkZWNsYXJpbmcgdG8gdGhlIHNlcnZlciB0aGF0IGl0IHdpbGwgcmVzdHJpY3QgaXRzZWxm IHRvIHdoZW4gcmVxdWVzdGluZyBhY2Nlc3MgdG9rZW5zLCBhbmQgdGhhdCB0aGUgc2VydmVyIGlz IGRlY2xhcmluZyB0byB0aGUgY2xpZW50IHRoYXQgaXQgaXMgcmVnaXN0ZXJlZCB0byB1c2Ugd2hl biByZXF1ZXN0aW5nIGFjY2VzcyB0b2tlbnMuICZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Q2xpZW50 cw0KIFNIT1VMRCBhc3N1bWUgdGhhdCBzZXJ2ZXJzIHdpbGwgcmVmdXNlIHRvIGdyYW50IGFjY2Vz cyB0b2tlbnMgZm9yIHNjb3BlcyBub3QgaW4gdGhlIGxpc3QgcHJvdmlkZWQgYnkgdGhlIHNlcnZl ci48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPuKAnTwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9t OjEyLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5PbiBUaHUsIEFwciAxOCwgMjAxMyBhdCA4OjU1IEFNLCBNaWtlIEpvbmVzICZsdDs8YSBo cmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+ TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+ DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND QyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+SSBkb27igJl0IHRoaW5rIGl04oCZcyBwb3NzaWJsZSB0byBkZWZp bmUgd2hhdCBpdCBtZWFucyBpbiBhbiBpbnRlcm9wZXJhYmxlIHdheSBiZWNhdXNlIE9BdXRoIGRp ZG7igJl0DQogc3BlY2lmeSBzY29wZXMgaW4gYW4gaW50ZXJvcGVyYWJsZSB3YXkuJm5ic3A7IE5v LCBJIGRvbuKAmXQgbGlrZSB0aGF0IGVpdGhlciwgYnV0IEkgdGhpbmsgdGhhdOKAmXMgd2hlcmUg dGhpbmdzIGFyZS4mbmJzcDsgVGhhdOKAmXMgd2h5IEkgd2FzIGFkdm9jYXRpbmcgZGVsZXRpbmcg dGhpcyByZWdpc3RyYXRpb24gZmVhdHVyZSBlbnRpcmVseS48L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CdXQgdW5k ZXJzdGFuZGluZyBpdCBtaWdodCBiZSB1c2VmdWwgaW4gc29tZSBjb250ZXh0cywgSeKAmW0gT0sg a2VlcGluZyBpdCwgcHJvdmlkZWQgd2UgYmUgY2xlYXIgdGhhdA0KIHRoZSBzZW1hbnRpY3Mgb2Yg 4oCccmVnaXN0ZXJlZCB0byB1c2XigJ0gYXJlIHNlcnZpY2Utc3BlY2lmaWMuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPiBUaW0gQnJheSBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzp0d2JyYXlAZ29v Z2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnR3YnJheUBnb29nbGUuY29tPC9hPl0NCjxicj4NCjxi PlNlbnQ6PC9iPiBUaHVyc2RheSwgQXByaWwgMTgsIDIwMTMgODozNiBBTTxicj4NCjxiPlRvOjwv Yj4gTWlrZSBKb25lczxicj4NCjxiPkNjOjwvYj4gSnVzdGluIFJpY2hlcjsgPGEgaHJlZj0ibWFp bHRvOm9hdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGhAaWV0Zi5vcmc8L2E+PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i Pjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBSZWdpc3RyYXRpb246IFNjb3Bl IFZhbHVlczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPk9uIHRoZSBzZXJ2ZXItdG8tY2xpZW50IHNpZGUsIHdoYXQgZG9lcyDi gJxyZWdpc3RlcmVkIHRvIHVzZeKAnSBtZWFuPyAmbmJzcDtEb2VzIGl0IG1lYW4gdGhhdCB0aGUg Y2xpZW50IHNob3VsZCBhc3N1bWUgdGhhdCBhbnkgc2NvcGVzIG5vdCBvbiB0aGUgbGlzdCBXSUxM IG5vdCBiZSBncmFudGVkLCBNQVkgbm90IGJlIGdyYW50ZWQuLi4uDQogb3Igd2hhdD8gJm5ic3A7 SXMgdGhpcyBhbHJlYWR5IGNvdmVyZWQgZWxzZXdoZXJlPyAtVDxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIFRodSwgQXByIDE4LCAyMDEzIGF0IDg6MjggQU0s IE1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5j b20iIHRhcmdldD0iX2JsYW5rIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzLCBKdXN0 aW4uJm5ic3A7IEkgYWdyZWUgd2l0aCB0aGUgbmVlZCBmb3IgdGhlIGdlbmVyaWMgdHdvLXNpZGVk IGxhbmd1YWdlLiZuYnNwOyBJ4oCZZCBzdGlsbCBrZWVwIHRoaXMgbGFuZ3VhZ2UNCiBmb3Igc2Nv cGUsIGJlY2F1c2Ugd2Ugd2FudCB0byBjYXB0dXJlIHRoZSDigJxkZWNsYXJpbmfigJ0gYXNwZWN0 IGluIHRoaXMgY2FzZTo8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1s ZWZ0Oi41aW4iPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPuKA nDwvc3Bhbj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij5TcGFjZSBzZXBhcmF0ZWQgbGlzdCBvZiBzY29wZSB2YWx1ZXMgKGFzIGRlc2Ny aWJlZCBpbiBPQXV0aCAyLjANCjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3Jm YzY3NDkjc2VjdGlvbi0zLjMiIHRhcmdldD0iX2JsYW5rIj5TZWN0aW9uJm5ic3A7My4zIFtSRkM2 NzQ5XTwvYT4pIHRoYXQgdGhlIGNsaWVudCBpcyBkZWNsYXJpbmcgdG8gdGhlIHNlcnZlciB0aGF0 IGl0IG1heSB1c2Ugd2hlbiByZXF1ZXN0aW5nIGFjY2VzcyB0b2tlbnMgYW5kIHRoYXQgdGhlIHNl cnZlciBpcyBkZWNsYXJpbmcgdG8gdGhlIGNsaWVudCB0aGF0IGl0IGlzIHJlZ2lzdGVyZWQNCiB0 byB1c2Ugd2hlbiByZXF1ZXN0aW5nIGFjY2VzcyB0b2tlbnMuPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj7igJ0uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Z b3Ugc2hvdWxkIHByb2JhYmx5IGFsc28gcmVpbmZvcmNlIHRoYXQgc2NvcGUgdmFsdWVzIGFyZSBz ZXJ2aWNlLXNwZWNpZmljIGFuZCBtYXkgbm90IGNvbnNpc3Qgb25seQ0KIG9mIGEgc3RhdGljIHNl dCBvZiBzdHJpbmcgdmFsdWVzLCBhbmQgdGhhdCB0aGVyZWZvcmUsIGluIHNvbWUgY2FzZXMsIGFu IGV4aGF1c3RpdmUgbGlzdCBvZiByZWdpc3RlcmVkIHNjb3BlIHZhbHVlcyBpcyBub3QgcG9zc2li bGUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij4gSnVzdGluIFJpY2hlciBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpqcmljaGVyQG1pdHJl Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmpyaWNoZXJAbWl0cmUub3JnPC9hPl0NCjxicj4NCjxiPlNl bnQ6PC9iPiBNb25kYXksIEFwcmlsIDE1LCAyMDEzIDEyOjI5IFBNPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxicj4NCjxiPlRvOjwv Yj4gTWlrZSBKb25lczxicj4NCjxiPkNjOjwvYj4gVGltIEJyYXk7IDxhIGhyZWY9Im1haWx0bzpv YXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoQGlldGYub3JnPC9hPjxicj4NCjxi PlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBSZWdpc3RyYXRpb246IFNjb3BlIFZhbHVlczxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRv bToxMi4wcHQiPkkgdGhpbmsgdGhhdCBiZWNhdXNlIHRoZSAmcXVvdDtkZWNsYXJhdGlvbiZxdW90 OyBpc3N1ZSBhZmZlY3RzIGFsbCBwYXJhbWV0ZXJzIGluIHRoZSBsaXN0LCBub3QganVzdCBzY29w ZSwgd2Ugc2hvdWxkIGFkb3B0IHRoaXMgaW4gYSBoaWdoZXIgbGV2ZWwgcGFyYWdyYXBoIGFuZCBs ZWF2ZSBpdCBvdXQgb2YgdGhlIGluZGl2aWR1YWwgcGFyYW1ldGVyDQogZGVzY3JpcHRpb25zLiBU aHVzLCBzb21ldGhpbmcgbGlrZSB0aGlzIGluc2VydGVkIGFzIHRoZSBzZWNvbmQgcGFyYWdyYXBo IGluIHNlY3Rpb24gMjo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhl IGNsaWVudCBtZXRhZGF0YSB2YWx1ZXMgc2VydmUgdHdvIHBhcmFsbGVsIHB1cnBvc2VzIGluIHRo ZSBvdmVyYWxsIE9BdXRoIER5bmFtaWMgUmVnaXN0cmF0aW9uIHByb3RvY29sOg0KPGJyPg0KPGJy Pg0KJm5ic3A7LSB0aGUgQ2xpZW50IHJlcXVlc3RpbmcgaXRzIGRlc2lyZWQgdmFsdWVzIGZvciBl YWNoIHBhcmFtZXRlciB0byB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgaW4gYSBbcmVnaXN0ZXJd IG9yIFt1cGRhdGVdIHJlcXVlc3QsPGJyPg0KJm5ic3A7LSB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2 ZXIgaW5mb3JtaW5nIHRoZSBDbGllbnQgb2YgdGhlIGN1cnJlbnQgdmFsdWVzIG9mIGVhY2ggcGFy YW1ldGVyIHRoYXQgdGhlIENsaWVudCBoYXMgYmVlbiByZWdpc3RlcmVkIHRvIHVzZSB0aHJvdWdo IGEgW2NsaWVudCBpbmZvcm1hdGlvbiByZXNwb25zZV0uDQo8YnI+DQo8YnI+DQpBbiBBdXRob3Jp emF0aW9uIFNlcnZlciBNQVkgb3ZlcnJpZGUgYW55IHZhbHVlIHRoYXQgYSBDbGllbnQgcmVxdWVz dHMgZHVyaW5nIHRoZSByZWdpc3RyYXRpb24gcHJvY2VzcyAoaW5jbHVkaW5nIGFueSBvbWl0dGVk IHZhbHVlcykgYW5kIHJlcGxhY2UgdGhlIHJlcXVlc3RlZCB2YWx1ZSB3aXRoIGEgZGVmYXVsdC4g VGhlIG5vcm1hdGl2ZSBpbmRpY2F0aW9ucyBpbiB0aGUgZm9sbG93aW5nIGxpc3QgYXBwbHkgdG8g dGhlIENsaWVudCdzIGRlY2xhcmF0aW9uDQogb2YgaXRzIGRlc2lyZWQgdmFsdWVzLiA8YnI+DQo8 YnI+DQpUaGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgU0hPVUxEIHByb3ZpZGUgZG9jdW1lbnRhdGlv biBmb3IgYW55IGZpZWxkcyB0aGF0IGl0IHJlcXVpcmVzIHRvIGJlIGZpbGxlZCBpbiBieSB0aGUg Y2xpZW50IG9yIHRvIGhhdmUgcGFydGljdWxhciB2YWx1ZXMgb3IgZm9ybWF0cy4gRXh0ZW5zaW9u cyBhbmQgcHJvZmlsZXMuLi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0K QW5kIHRoZW4gcmVtb3ZlIHRoZSBzaWRlZG5lc3MtbGFuZ3VhZ2UgZnJvbSB0aGUgc2NvcGUgcGFy YW1ldGVyIGFuZCBhbnkgb3RoZXIgcGFyYW1ldGVycyB3aGVyZSBpdCBtaWdodCBoYXZlIGNyZXB0 IGluIGluYWR2ZXJ0ZW50bHkuDQo8YnI+DQo8YnI+DQombmJzcDstLSBKdXN0aW48bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIDA0LzE1LzIwMTMgMDE6Mjkg UE0sIE1pa2UgSm9uZXMgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ V2UgY291bGQgZml4IHRoZSBvbmUtc2lkZWQgbGFuZ3VhZ2UgYnkgY2hhbmdpbmc8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQo8 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+4oCcPC9zcGFuPjxzcGFu IGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlNw YWNlIHNlcGFyYXRlZCBsaXN0IG9mIHNjb3BlIHZhbHVlcyAoYXMgZGVzY3JpYmVkIGluIE9BdXRo IDIuMA0KPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjc0OSNzZWN0aW9u LTMuMyIgdGFyZ2V0PSJfYmxhbmsiPlNlY3Rpb24mbmJzcDszLjMgW1JGQzY3NDldPC9hPikgdGhh dCB0aGUgY2xpZW50IGlzIGRlY2xhcmluZyB0aGF0IGl0IG1heSB1c2Ugd2hlbiByZXF1ZXN0aW5n IGFjY2VzcyB0b2tlbnMuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj7igJ08L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj50bzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj7igJw8L3NwYW4+PHNwYW4g bGFuZz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+U3Bh Y2Ugc2VwYXJhdGVkIGxpc3Qgb2Ygc2NvcGUgdmFsdWVzIChhcyBkZXNjcmliZWQgaW4gT0F1dGgg Mi4wDQo8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2NzQ5I3NlY3Rpb24t My4zIiB0YXJnZXQ9Il9ibGFuayI+U2VjdGlvbiZuYnNwOzMuMyBbUkZDNjc0OV08L2E+KSB0aGF0 IHRoZSBjbGllbnQgaXMgZGVjbGFyaW5nIHRvIHRoZSBzZXJ2ZXIgdGhhdCBpdCBtYXkgdXNlIHdo ZW4gcmVxdWVzdGluZyBhY2Nlc3MgdG9rZW5zIGFuZCB0aGF0IHRoZSBzZXJ2ZXIgaXMgZGVjbGFy aW5nIHRvIHRoZSBjbGllbnQgdGhhdCBpdCBpcyByZWdpc3RlcmVkDQogdG8gdXNlIHdoZW4gcmVx dWVzdGluZyBhY2Nlc3MgdG9rZW5zLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+4oCdLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFnYWluLCBJIGNob3NlIHRoZSDigJxy ZWdpc3RlcmVkIHRvIHVzZeKAnSBsYW5ndWFnZSBjYXJlZnVsbHkg4oCTIGJlY2F1c2UgaW4gdGhl IGdlbmVyYWwgY2FzZSBpdOKAmXMgbm90DQogYSByZXN0cmljdGlvbiBvbiB0aGUgdmFsdWVzIHRo YXQgdGhlIGNsaWVudCBjYW4gdXNlIOKAkyBqdXN0IGEgc3RhdGVtZW50IGJ5IHRoZSBzZXJ2ZXIg dG8gdGhlIGNsaWVudCB0aGF0IGl0IGlzIHJlZ2lzdGVyZWQgdG8gdXNlIHRob3NlIHBhcnRpY3Vs YXIgdmFsdWVzLiZuYnNwOyBJbiBib3RoIGNhc2VzLCB0aGUgcGFydGllcyBhcmUgbWFraW5nIGRl Y2xhcmF0aW9ucyB0byBvbmUgYW5vdGhlci48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JZiB5b3UgYWRvcHQgdGhh dCBsYW5ndWFnZSAob3Iga2VlcCB0aGUgb3JpZ2luYWwgbGFuZ3VhZ2UpLCB0aGVuIHllcywgSeKA mWQgY29uc2lkZXIgdGhpcyBjbG9zZWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1p a2U8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gSnVzdGluIFJpY2hlciBbPGEgaHJlZj0ibWFpbHRv OmpyaWNoZXJAbWl0cmUub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOmpyaWNoZXJAbWl0cmUu b3JnPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEFwcmlsIDE1LCAyMDEzIDk6NTcg QU08YnI+DQo8Yj5Ubzo8L2I+IE1pa2UgSm9uZXM8YnI+DQo8Yj5DYzo8L2I+IFRpbSBCcmF5OyA8 YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aEBpZXRm Lm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gUmVnaXN0cmF0aW9u OiBTY29wZSBWYWx1ZXM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBw dCI+SSBhYnNvbHV0ZWx5IGRvIG5vdCB3YW50IHRvIGRlbGV0ZSB0aGlzIGZlYXR1cmUsIGFzICho YXZpbmcgaW1wbGVtZW50ZWQgaXQpIEkgdGhpbmsgaXQncyB2ZXJ5IHVzZWZ1bC4gVGhpcyBpcyBh IHZlcnkgZXN0YWJsaXNoZWQgcGF0dGVybiBpbiBtYW51YWwgcmVnaXN0cmF0aW9uOiBJIGtub3cg b2YgbWFueSwgbWFueSBPQXV0aDINCiBzZXJ2ZXJzIGFuZCBjbGllbnRzIHRoYXQgYXJlIHNldCB1 cCB3aGVyZSB0aGUgY2xpZW50IG11c3QgcHJlLXJlZ2lzdGVyIGEgc2V0IG9mIHNjb3Blcy4NCjxi cj4NCjxicj4NCkkgZG9uJ3QgbGlrZSB0aGUgbGFuZ3VhZ2Ugb2YgJnF1b3Q7dGhlIGNsaWVudCBp cyBkZWNsYXJpbmcmcXVvdDsgYmVjYXVzZSBpdCdzIHRvbyBvbmUtc2lkZWQuIFRoZSBjbGllbnQg bWlnaHQgbm90IGhhdmUgZGVjbGFyZWQgYW55dGhpbmcsIGFuZCBpdCBtaWdodCBiZSB0aGUgc2Vy dmVyIHRoYXQncyBkZWNsYXJpbmcgc29tZXRoaW5nIHRvIHRoZSBjbGllbnQuIERlbGV0aW5nIHRo ZSAmcXVvdDtpcyBkZWNsYXJpbmcmcXVvdDsgYml0IHJlbW92ZXMgdGhhdCB1bmludGVuZGVkIHJl c3RyaWN0aW9uDQogb2YgdGhlIGxhbmd1YWdlIHdoaWxlIGtlZXBpbmcgdGhlIG9yaWdpbmFsIG1l YW5pbmcgaW50YWN0LiBJIGFjdHVhbGx5IHRob3VnaHQgdGhhdCBJIGhhZCBmaXhlZCB0aGF0IGJl Zm9yZSB0aGUgbGFzdCBkcmFmdCB3ZW50IGluIGJ1dCBhcHBhcmVudGx5IEkgbWlzc2VkIHRoaXMg b25lLjxicj4NCjxicj4NCkkgd2lsbCB3b3JrIG9uIGNsYXJpZnlpbmcgdGhlIGludGVudCBvZiB0 aGUgd2hvbGUgbWV0YWRhdGEgc2V0IGluIGl0cyBpbnRyb2R1Y3RvcnkgcGFyYWdyYXBoKHMpIHNv IHRoYXQgaXQncyBjbGVhciB0aGF0IGFsbCBvZiB0aGVzZSBmaWVsZHMgYXJlIHVzZWQgaW4gYm90 aCBvZiB0aGVzZSBzaXR1YXRpb25zOjxicj4NCjxicj4NCiZuYnNwOzEpIFRoZSBjbGllbnQgZGVj bGFyaW5nIHRvIHRoZSBzZXJ2ZXIgaXRzIGRlc2lyZSB0byB1c2UgYSBwYXJ0aWN1bGFyIHZhbHVl PGJyPg0KJm5ic3A7MikgVGhlIHNlcnZlciBkZWNsYXJpbmcgdG8gdGhlIGNsaWVudCB0aGF0IGl0 IGhhcyBiZWVuIHJlZ2lzdGVyZWQgd2l0aCBhIHBhcnRpY3VsYXIgdmFsdWU8YnI+DQo8YnI+DQpU aGlzIHNob3VsZCBob3BlZnVsbHkgY2xlYXIgdXAgdGhlIGlzc3VlIGluIHRoZSBlZGl0b3IncyBu b3RlIHRoYXQgSSBjdXJyZW50bHkgaGF2ZSBhdCB0aGUgdG9wIG9mIHRoYXQgc2VjdGlvbiByaWdo dCBub3csIHRvby48YnI+DQo8YnI+DQpNaWtlLCBzaW5jZSB5b3Ugd2VyZSB0aGUgb25lIHdobyBv cmlnaW5hbGx5IGJyb3VnaHQgdXAgdGhlIGlzc3VlLCBhbmQgeW91J3JlIGZpbmUgd2l0aCB0aGUg ZXhpc3RpbmcgdGV4dCwgY2FuIEkgdGFrZSB0aGlzIGFzIGNsb3NlZCBub3c/IEFzc3VtaW5nIHRo YXQgeW91IGFncmVlIHdpdGggZGVsZXRpbmcgJnF1b3Q7aXMgZGVjbGFyaW5nJnF1b3Q7IGZvciBy ZWFzb25zIHN0YXRlZCBhYm92ZSwgSSdtIGZpbmUgd2l0aCBsZWF2aW5nIGV2ZXJ5dGhpbmcgZWxz ZSBhcw0KIGlzIGFuZCBzdGF5aW5nIHF1aWV0IG9uIHdoYXQgdGhlIHNlcnZlciBoYXMgdG8gZG8g d2l0aCB0aGUgc2NvcGVzLjxicj4NCjxicj4NCiZuYnNwOy0tIEp1c3RpbjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gMDQvMTUvMjAxMyAxMjo0NCBQTSwg TWlrZSBKb25lcyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHRo aW5rIHRoYXQgdGhlIGV4aXN0aW5nIHdvcmRpbmcgaXMgc3VwZXJpb3IgdG8gdGhlIHByb3Bvc2Vk IGNoYW5nZWQgd29yZGluZy4mbmJzcDsgVGhlIGV4aXN0aW5nIHdvcmRpbmcNCiBpczo8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcgXDtjb2xvclw6d2luZG93dGV4dCZxdW90OyI+Jm5ic3A7Jm5ic3A7 IHNjb3BlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3IFw7Y29sb3Jc OndpbmRvd3RleHQmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBPUFRJT05B TC4mbmJzcDsgU3BhY2Ugc2VwYXJhdGVkIGxpc3Qgb2Ygc2NvcGUgdmFsdWVzIChhcyBkZXNjcmli ZWQgaW48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgXDtjb2xvclw6 d2luZG93dGV4dCZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9BdXRoIDIu MA0KPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjc0OSNzZWN0aW9uLTMu MyIgdGFyZ2V0PSJfYmxhbmsiPlNlY3Rpb24mbmJzcDszLjMgW1JGQzY3NDldPC9hPikgdGhhdCB0 aGUgY2xpZW50IGlzIGRlY2xhcmluZyB0aGF0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3IFw7Y29sb3JcOndpbmRvd3RleHQmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBpdCBtYXkgdXNlIHdoZW4gcmVxdWVzdGluZyBhY2Nlc3MgdG9rZW5zLiZu YnNwOyBJZiBvbWl0dGVkLCBhbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyBcO2NvbG9yXDp3aW5kb3d0ZXh0JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgTUFZIHJlZ2lzdGVyIGEgQ2xpZW50IHdpdGggYSBk ZWZhdWx0IHNldCBvZjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyBc O2NvbG9yXDp3aW5kb3d0ZXh0JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg c2NvcGVzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkZvciBpbnN0YW5jZSwgdGhlIGN1cnJlbnQg4oCcY2xpZW50 IGlzIGRlY2xhcmluZ+KAnSB3b3JkaW5nIHdpbGwgYWx3YXlzIGJlIGNvcnJlY3QsIHdoZXJlYXMg YXMgdGhlIGNoYW5nZQ0KIHRvIOKAnGNsaWVudCBjYW4gdXNl4oCdIHdvcmRpbmcgaW1wbGllcyBh IHJlc3RyaWN0aW9uIG9uIGNsaWVudCBiZWhhdmlvciB0aGF0IGlzIG5vdCBhbHdheXMgYXBwbGlj YWJsZS4mbmJzcDsgVGhlIOKAnGNsaWVudCBpcyBkZWNsYXJpbmfigJ0gd29yZGluZyB3YXMgc3Bl Y2lmaWMgYW5kIHB1cnBvc2VmdWxseSBjaG9zZW4sIGFuZCBJIHRoaW5rIHNob3VsZCBiZSByZXRh aW5lZC4mbmJzcDsgSW4gcGFydGljdWxhciwgd2UgY2Fu4oCZdCBkbyBhbnl0aGluZyB0aGF0IGlt cGxpZXMgdGhhdA0KIG9ubHkgdGhlIHJlZ2lzdGVyZWQgc2NvcGVzIHZhbHVlcyBjYW4gYmUgdXNl ZC4mbmJzcDsgQXQgdGhlIE9BdXRoIHNwZWMgbGV2ZWwsIHRoaXMgaXMgYSBoaW50IGFzIHRvIHBv c3NpYmxlIGZ1dHVyZSBjbGllbnQgYmVoYXZpb3Ig4oCTIG5vdCBhIHJlc3RyaWN0aW9uIG9uIGZ1 dHVyZSBjbGllbnQgYmVoYXZpb3IuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QWxzbywgZm9yIHRoZSByZWFzb25z IHRoYXQgVGltIHN0YXRlZCwgSeKAmW0gc3Ryb25nbHkgYWdhaW5zdCBhbnkg4oCcbWF0Y2hpbmfi gJ0gb3Ig4oCccmVnZXjigJ0gbGFuZ3VhZ2UgaW4NCiB0aGUgc3BlYyBwZXJ0YWluaW5nIHRvIHNj b3BlcyDigJMgYXMgaXTigJlzIG5vdCBhY3Rpb25hYmxlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNvIEnigJlk IHByb3Bvc2UgdGhhdCB3ZSBsZWF2ZSB0aGUgZXhpc3Rpbmcgc2NvcGUgd29yZGluZyBpbiBwbGFj ZS4mbmJzcDsgQWx0ZXJuYXRpdmVseSwgSeKAmWQgYWxzbyBiZSBmaW5lDQogd2l0aCBkZWxldGlu ZyB0aGlzIGZlYXR1cmUgZW50aXJlbHksIGFzIEkgZG9u4oCZdCB0aGluayBpdOKAmXMgdXNlZnVs IGluIHRoZSBnZW5lcmFsIGNhc2UuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVD NERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4NCjxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT4gWzxhIGhy ZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRv Om9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5KdXN0aW4g UmljaGVyPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgQXByaWwgMTUsIDIwMTMgODowNSBBTTxi cj4NCjxiPlRvOjwvYj4gVGltIEJyYXk7IDxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPm9hdXRoQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogW09BVVRILVdHXSBSZWdpc3RyYXRpb246IFNjb3BlIFZhbHVlczwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij5PbiAwNC8xNS8yMDEzIDEwOjUyIEFNLCBUaW0g QnJheSB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PknigJlkIHVzZSB0aGUgZXhpc3Rpbmcgd29yZGluZzsgaXTigJlzIHBlcmZlY3RseSBjbGVhci4g Jm5ic3A7RmFpbGluZyB0aGF0LCBpZiB0aGVyZeKAmXMgc3Ryb25nIGRlbWFuZCBmb3IgcmVnaXN0 cmF0aW9uIG9mIHN0cnVjdHVyZWQgc2NvcGVzLCBibGVzcyB0aGUgdXNlIG9mIHJlZ2V4ZXMsIGVp dGhlciBQQ1JFcyBvciBzb21lDQogY2FyZWZ1bCBzdWJzZXQuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt YXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KVGhhbmtzIGZvciB0aGUgZmVlZGJhY2sgLS0gT2Yg dGhlc2UgdHdvIGNob2ljZXMsIEknZCByYXRoZXIgbGVhdmUgaXQgYXMtaXMuIDxicj4NCjxicj4N CjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5Ib3dldmVyLCBJ4oCZZCBzdWJ0cmFjdCB0aGUgc2VudGVuY2Ug4oCcSWYgb21pdHRlZCwgYW4g QXV0aG9yaXphdGlvbiBTZXJ2ZXIgTUFZIHJlZ2lzdGVyIGEgQ2xpZW50IHdpdGggYSBkZWZhdWx0 IHNldCBvZiAmbmJzcDtzY29wZXMu4oCdICZuYnNwO0l0IGFkZHMgbm8gdmFsdWU7IGlmIHRoZSBj bGllbnQgZG9lc27igJl0IGRlY2xhcmUgc2NvcGVzLA0KIHRoZSBjbGllbnQgZG9lc27igJl0IGRl Y2xhcmUgc2NvcGVzLCB0aGF04oCZcyBhbGwuICZuYnNwOy1UPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpSZW1lbWJlciwgYWxsIG9mIHRoZXNl IGZpZWxkcyBhcmVuJ3QganVzdCBmb3IgdGhlIGNsaWVudCAqcmVxdWVzdCosIHRoZXkncmUgYWxz byBmb3IgdGhlIHNlcnZlcidzICpyZXNwb25zZSogdG8gZWl0aGVyIGEgUE9TVCwgUFVULCBvciBH RVQgcmVxdWVzdC4gKEkgZGlkbid0IHJlYWxpemUgaXQsIGJ1dCBwZXJoYXBzIHRoZSB3b3JkaW5n IGFzIHN0YXRlZCByaWdodCBub3cgZG9lc24ndCBtYWtlIHRoYXQgY2xlYXIgLS0gSSBuZWVkIHRv IGZpeCB0aGF0LikNCiBUaGUgdmFsdWUgdGhhdCBpdCBhZGRzIGlzIGlmIHRoZSBjbGllbnQgZG9l c24ndCBhc2sgZm9yIGFueSBwYXJ0aWN1bGFyIHNjb3BlcywgdGhlIHNlcnZlciBjYW4gc3RpbGwg YXNzaWduIGl0IHNjb3BlcyBhbmQgdGhlIGNsaWVudCBjYW4gZG8gc29tZXRoaW5nIHNtYXJ0IHdp dGggdGhhdC4gRHVtYiBjbGllbnRzIGFyZSBhbGxvd2VkIHRvIGlnbm9yZSBpdCBpZiBpdCBkb2Vz bid0IG1lYW4gYW55dGhpbmcgdG8gdGhlbS4NCjxicj4NCjxicj4NClRoaXMgaXMgaG93IG91ciBz ZXJ2ZXIgaW1wbGVtZW50YXRpb24gYWN0dWFsbHkgd29ya3MgcmlnaHQgbm93LiBJZiB0aGUgY2xp ZW50IGRvZXNuJ3QgYXNrIGZvciBhbnl0aGluZyBzcGVjaWZpYyBhdCByZWdpc3RyYXRpb24sIHRo ZSBzZXJ2ZXIgaGFuZHMgaXQgYSBiYWcgb2YgJnF1b3Q7ZGVmYXVsdCZxdW90OyBzY29wZXMuIFNh bWUgdGhpbmcgaGFwcGVucyBhdCBhdXRoIHRpbWUgLS0gaWYgdGhlIGNsaWVudCBkb2Vzbid0IGFz ayBmb3IgYW55IHBhcnRpY3VsYXIgc2NvcGVzLA0KIHRoZSBzZXJ2ZXIgaGFuZHMgaXQgYWxsIG9m IGl0cyByZWdpc3RlcmVkIHNjb3BlcyBhcyBhIGRlZmF1bHQuIEdyYW50ZWQsIG9uIG91ciBzZXJ2 ZXIsIHNjb3BlcyBhcmUganVzdCBzaW1wbGUgc3RyaW5ncyByaWdodCBub3csIHNvIHRoZXkgZ2V0 IGNvbXBhcmVkIGF0IHRoZSBhdXRoIGVuZHBvaW50IHdpdGggYW4gZXhhY3Qgc3RyaW5nLW1hdGNo IG1ldHJpYyBhbmQgc2V0LWJhc2VkIGxvZ2ljLg0KPGJyPg0KPGJyPg0KJm5ic3A7LS0gSnVzdGlu PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIE1vbiwg QXByIDE1LCAyMDEzIGF0IDc6MzUgQU0sIEp1c3RpbiBSaWNoZXIgJmx0OzxhIGhyZWY9Im1haWx0 bzpqcmljaGVyQG1pdHJlLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmpyaWNoZXJAbWl0cmUub3JnPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5XaGF0IHdvdWxkIHlvdSBzdWdnZXN0IGZvciB3b3JkaW5nIGhlcmUsIHRoZW4/IEtlZXBpbmcg aW4gbWluZCB0aGF0IHdlIGNhbm5vdCAoYW5kIGRvbid0IHdhbnQgdG8pIHByb2hpYml0IGV4cHJl c3Npb24tYmFzZWQgc2NvcGVzLg0KPGJyPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxi cj4NCiZuYnNwOy0tIEp1c3Rpbjwvc3Bhbj4gPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJn aW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5PbiAwNC8xNS8yMDEzIDEwOjMzIEFNLCBUaW0gQnJheSB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Obywg SSBtZWFuIGl04oCZcyBub3QgaW50ZXJvcGVyYWJsZSBhdCB0aGUgc29mdHdhcmUtZGV2ZWxvcGVy IGxldmVsLiAmbmJzcDtJIGNhbuKAmXQgcmVnaXN0ZXIgc2NvcGVzIGF0IGF1dGhvcml6YXRpb24g dGltZSB3aXRoIGFueSBwcmVkaWN0YWJsZSBlZmZlY3QgdGhhdCBJIGNhbiB3cml0ZSBjb2RlIHRv IHN1cHBvcnQsIGVpdGhlcg0KIGNsaWVudCBvciBzZXJ2ZXIgc2lkZSwgd2l0aG91dCBvdXQtb2Yt bGluZSBub24taW50ZXJvcGVyYWJsZSBrbm93bGVkZ2UgYWJvdXQgdGhlIGJlaGF2aW9yIG9mIHRo ZSBzZXJ2ZXIuICZuYnNwOw0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+SSBndWVzcyBJ4oCZbSBqdXN0IG5vdCB1c2VkIHRvIE9BdXRo4oCZcyBjdWx0 dXJlIG9mIGhhdmluZyBubyBleHBlY3RhdGlvbiB0aGF0IHRoaW5ncyB3aWxsIGJlIHNwZWNpZmll ZCB0aWdodGx5IGVub3VnaCB0aGF0IEkgY2FuIHdyaXRlIGNvZGUgdG8gaW1wbGVtZW50IGFzIHNw ZWNpZmllZC4gJm5ic3A7LVQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdp bi1ib3R0b206MTIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPk9uIE1vbiwgQXByIDE1LCAyMDEzIGF0IDc6MTUgQU0sIEp1c3RpbiBSaWNo ZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpqcmljaGVyQG1pdHJlLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PmpyaWNoZXJAbWl0cmUub3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5TY29wZXMgYXJlbid0IG1lYW50IHRvIGJlIGludGVyb3Bl cmFibGUgYmV0d2VlbiBzZXJ2aWNlcyBzaW5jZSB0aGV5J3JlIG5lY2Vzc2FyaWx5IEFQSS1zcGVj aWZpYy4gVGhlIG9ubHkgaW50ZXJvcGVyYWJsZSBiaXQgaXMgdGhhdCB0aGVyZSdzICpzb21lKiBw bGFjZSB0byBwdXQgdGhlIHZhbHVlcyBhbmQgdGhhdA0KIGl0J3MgZXhwcmVzc2VkIGFzIGEgYmFn IG9mIHNwYWNlLXNlcGFyYXRlZCBzdHJpbmdzLiBIb3cgdGhvc2Ugc3RyaW5ncyBnZXQgaW50ZXJw cmV0ZWQgYW5kIGVuZm9yY2VkICh3aGljaCBpcyByZWFsbHkgd2hhdCdzIGF0IHN0YWtlIGhlcmUp IGlzIHVwIHRvIHRoZSBBUyBhbmQgUFIgKG9yIGEgaGlnaGVyLWxldmVsIHByb3RvY29sIGxpa2Ug VU1BKS48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PGJyPg0KPGJyPg0KJm5ic3A7LS0gSnVz dGluPC9zcGFuPiA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0 Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9u IDA0LzE1LzIwMTMgMTA6MTMgQU0sIFRpbSBCcmF5IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxwPlRoaXMsIGFzIHdyaXR0ZW4sIGhhcyB6ZXJvIGludGVyb3BlcmFiaWxpdHkuJm5i c3A7IEkgdGhpbmsgdGhpcyBmZWF0dXJlIGNhbiByZWFsbHkgb25seSBiZSBtYWRlIHVzZWZ1bCBp biB0aGUgY2FzZSB3aGVyZSBzY29wZXMgYXJlIGZpeGVkIHN0cmluZ3MuPG86cD48L286cD48L3A+ DQo8cD4tVDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24g QXByIDE1LCAyMDEzIDY6NTQgQU0sICZxdW90O0p1c3RpbiBSaWNoZXImcXVvdDsgJmx0OzxhIGhy ZWY9Im1haWx0bzpqcmljaGVyQG1pdHJlLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmpyaWNoZXJAbWl0 cmUub3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIu MHB0Ij5Zb3UgYXJlIGNvcnJlY3QgdGhhdCB0aGUgaWRlYSBiZWhpbmQgdGhlICZxdW90O3Njb3Bl JnF1b3Q7IHBhcmFtZXRlciBhdCByZWdpc3RyYXRpb24gaXMgYSBjb25zdHJhaW50IG9uIGF1dGhv cml6YXRpb24tdGltZSBzY29wZXMgdGhhdCBhcmUgbWFkZSBhdmFpbGFibGUuIEl0J3MgYm90aCBh IG1lYW5zIGZvciB0aGUgY2xpZW50IHRvIHJlcXVlc3QNCiBhIHNldCBvZiB2YWxpZCBzY29wZXMg YW5kIGZvciB0aGUgc2VydmVyIHRvIHByb3Zpc2lvbiAoYW5kIGVjaG8gYmFjayB0byB0aGUgY2xp ZW50KSBhIHNldCBvZiB2YWxpZCBzY29wZXMuPGJyPg0KPGJyPg0KSSAqcmVhbGx5KiBkb24ndCB3 YW50IHRvIHRyeSB0byBkZWZpbmUgYSBtYXRjaGluZyBsYW5ndWFnZSBmb3Igc2NvcGUgZXhwcmVz c2lvbnMuIEZvciB0aGF0IHRvIHdvcmssIGFsbCBzZXJ2ZXJzIHdvdWxkIG5lZWQgdG8gYmUgYWJs ZSB0byBwcm9jZXNzIHRoZSByZWd1bGFyIGV4cHJlc3Npb25zIGZvciBhbGwgY2xpZW50cywgZXZl biBpZiB0aGUgc2VydmVycyB0aGVtc2VsdmVzIG9ubHkgc3VwcG9ydCBzaW1wbGUtc3RyaW5nIHNj b3BlIHZhbHVlcy4NCiBBbnkgcmVndWxhciBleHByZXNzaW9uIHN5bnRheCB3ZSBwaWNrIGhlcmUg aXMgZ3VhcmFudGVlZCB0byBiZSBpbmNvbXBhdGlibGUgd2l0aCBzb21ldGhpbmcsIGFuZCBJIHRo aW5rIHRoZSBjb21wbGV4aXR5IGRvZXNuJ3QgYnV5IG11Y2guIEFsc28sIEkgdGhpbmsgeW91IHN1 ZGRlbmx5IGhhdmUgYSBwb3RlbnRpYWwgc2VjdXJpdHkgaXNzdWUgaWYgeW91IGhhdmUgYSBiYWQg cmVnZXggaW4gcGxhY2Ugb24gZWl0aGVyIGVuZC4NCjxicj4NCjxicj4NCkFzIGl0IHN0YW5kcyB0 b2RheSwgdGhlIHNlcnZlciBjYW4gaW50ZXJwcmV0IHRoZSBpbmNvbWluZyByZWdpc3RyYXRpb24g c2NvcGVzIGFuZCBlbmZvcmNlIHRoZW0gaG93ZXZlciBpdCB3YW50cyB0by4gVGhlIHJlYWwgdHJp Y2sgY29tZXMgbm90IGZyb20gYXNzaWduaW5nIHRoZSB2YWx1ZXMgdG8gYSBwYXJ0aWN1bGFyIGNs aWVudCBidXQgdG8gZW5mb3JjaW5nIHRoZW0sIGFuZCBJIHRoaW5rIHRoYXQncyBhbHdheXMgZ29p bmcgdG8gYmUgc2VydmljZS1zcGVjaWZpYy4NCiBXZSdyZSBqdXN0IG5vdCBhcyBjbGVhciBvbiB0 aGF0IGFzIHdlIGNvdWxkIGJlLjxicj4NCjxicj4NCkFmdGVyIGxvb2tpbmcgb3ZlciBldmVyeW9u ZSdzIGNvbW1lbnRzIHNvIGZhciwgSSdkIGxpa2UgdG8gcHJvcG9zZSB0aGUgZm9sbG93aW5nIHRl eHQgZm9yIHRoYXQgc2VjdGlvbjo8bzpwPjwvbzpwPjwvcD4NCjxwcmU+Jm5ic3A7Jm5ic3A7IHNj b3BlPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IE9QVElPTkFMLiZuYnNwOyBTcGFjZSBzZXBhcmF0ZWQgbGlzdCBvZiBzY29wZSB2YWx1ZXMgKGFz IGRlc2NyaWJlZCBpbjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBPQXV0aCAyLjAgPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv cmZjNjc0OSNzZWN0aW9uLTMuMyIgdGFyZ2V0PSJfYmxhbmsiPlNlY3Rpb24mbmJzcDszLjMgW1JG QzY3NDldPC9hPikgdGhhdCB0aGUgY2xpZW50IGNhbiB1c2Ugd2hlbiA8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtyZXF1ZXN0aW5nIGFj Y2VzcyB0b2tlbnMuJm5ic3A7IEFzIHNjb3BlIHZhbHVlcyBhcmUgc2VydmljZS1zcGVjaWZpYywg PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7dGhlIEF1dGhvcml6YXRpb24gU2VydmVyIE1BWSBkZWZpbmUgaXRzIG93biBtYXRjaGluZyBy dWxlcyB3aGVuPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZuYnNwO2RldGVybWluaW5nIGlmIGEgc2NvcGUgdmFsdWUgdXNlZCBkdXJpbmcgYW4gYXV0aG9y aXphdGlvbiByZXF1ZXN0PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IGlzIHZhbGlkIGFjY29yZGluZyB0byB0aGUgc2NvcGUgdmFsdWVzIGFzc2ln bmVkIGR1cmluZyA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDtyZWdpc3RyYXRpb24uIFBvc3NpYmxlIG1hdGNoaW5nIHJ1bGVzIGluY2x1 ZGUgd2lsZGNhcmQgcGF0dGVybnMsPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZuYnNwO3JlZ3VsYXIgZXhwcmVzc2lvbnMsIG9yIGV4YWN0bHkgbWF0Y2hp bmcgdGhlIHN0cmluZy4gSWYgb21pdHRlZCwgPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7YW4gQXV0aG9yaXphdGlvbiBTZXJ2ZXIgTUFZ IHJlZ2lzdGVyIGEgQ2xpZW50IHdpdGggYSBkZWZhdWx0IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3NldCBvZiBzY29wZXMuPG86cD48 L286cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KQ29tbWVudHM/IEltcHJvdmVtZW50 cz88YnI+DQo8YnI+DQombmJzcDstLSBKdXN0aW48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPk9uIDA0LzE0LzIwMTMgMDg6MjMgUE0sIE1hbmdlciwgSmFtZXMg SCB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPlByZXN1bWFibHkgYXQgYXBw IHJlZ2lzdHJhdGlvbiB0aW1lIGFueSBzY29wZSBzcGVjaWZpY2F0aW9uIGlzIHJlYWxseSBhIGNv bnN0cmFpbnQgb24gdGhlIHNjb3BlIHZhbHVlcyB0aGF0IGNhbiBiZSByZXF1ZXN0ZWQgaW4gYW4g YXV0aG9yaXphdGlvbiBmbG93LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPlNvIGlkZWFsbHkgcmVnaXN0cmF0aW9uIHNob3VsZCBhY2NlcHQgcnVs ZXMgZm9yIG1hdGNoaW5nIHNjb3BlcywgYXMgb3Bwb3NlZCB0byBhY3R1YWwgc2NvcGUgdmFsdWVz LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPllv dSBjYW4gdHJ5IHRvIHVzZSBzY29wZSB2YWx1ZXMgYXMgdGhlaXIgb3duIG1hdGNoaW5nIHJ1bGVz LiBUaGF0IGlzIGZpbmUgZm9yIGEgc21hbGwgc2V0IG9mICZxdW90O3N0YXRpYyZxdW90OyBzY29w ZXMuIEl0IHN0YXJ0cyB0byBmYWlsIHdoZW4gdGhlcmUgYXJlIGEgbGFyZ2UgbnVtYmVyIG9mIHNj b3Blcywgb3Igc2NvcGVzIHRoYXQgY2FuIGluY2x1ZGUgcGFyYW1ldGVycyAocmVzb3VyY2UgcGF0 aHM/IGVtYWlsIGFkZHJlc3Nlcz8pLiBZb3UgY2FuIHRyeSB0byBwYXRjaCB0aG9zZSBmYWlsdXJl cyBieSBhbGxvd2luZyBzZXJ2aWNlcyB0byBkZWZpbmUgc2VydmljZS1zcGVjaWZpYyBzcGVjaWFs ICZxdW90O3dpbGRjYXJkJnF1b3Q7IHNjb3BlIHZhbHVlcyB0aGF0IGNhbiBvbmx5IGJlIHVzZWQg ZHVyaW5nIHJlZ2lzdHJhdGlvbiAoZWcgJnF1b3Q7cmVhZDoqJnF1b3Q7KS48bzpwPjwvbzpwPjwv cHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5BbHRlcm5hdGl2ZWx5LCBy ZXBsYWNlICdzY29wZScgaW4gcmVnaXN0cmF0aW9uIHdpdGggJ3Njb3BlX3JlZ2V4JyB0aGF0IGhv bGRzIGEgcmVndWxhciBleHByZXNzaW9uIHRoYXQgYWxsIHNjb3BlIHZhbHVlcyBpbiBhbiBhdXRo b3JpemF0aW9uIGZsb3cgbXVzdCBtYXRjaC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4tLTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkphbWVzIE1h bmdlcjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3ByZT4NCjxwcmU+T0F1dGggbWFpbGluZyBs aXN0PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3ByZT4NCjxw cmU+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1 dGg8L2E+PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJy Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpP QXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_04cb3c88970842de9b0ec1162e8a86dbBY2PR03MB041namprd03pro_-- From Michael.Jones@microsoft.com Thu Apr 18 10:05:22 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE95721F8F63 for ; Thu, 18 Apr 2013 10:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.067, 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 UYTxrl4XXGpI for ; Thu, 18 Apr 2013 10:05:05 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0204.outbound.protection.outlook.com [207.46.163.204]) by ietfa.amsl.com (Postfix) with ESMTP id AAD9821F8FF1 for ; Thu, 18 Apr 2013 10:05:04 -0700 (PDT) Received: from BL2FFO11FD017.protection.gbl (10.173.161.203) by BL2FFO11HUB012.protection.gbl (10.173.161.118) with Microsoft SMTP Server (TLS) id 15.0.675.0; Thu, 18 Apr 2013 17:05:01 +0000 Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD017.mail.protection.outlook.com (10.173.161.35) with Microsoft SMTP Server (TLS) id 15.0.675.0 via Frontend Transport; Thu, 18 Apr 2013 17:05:01 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.245]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.02.0318.003; Thu, 18 Apr 2013 17:04:29 +0000 From: Mike Jones To: "Richer, Justin P." , Anthony Nadalin Thread-Topic: [OAUTH-WG] Registration: Scope Values Thread-Index: AQHOOeqUFpSaFgMeSEqfp5thtJ9Xm5jXeeUggAAGtwCAAAX9QIAAJHsAgARy+OCAAAL+AIAABHrwgAADR4CAAALDAIAAA2eAgAAI58A= Date: Thu, 18 Apr 2013 17:04:28 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436766D8B9@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <255B9BB34FB7D647A506DC292726F6E1150C74DADA@WSMSG3153V.srv.dir.telstra.com> <516C069F.9090308@mitre.org> <516C0B9D.6000402@mitre.org> <516C101F.2090706@mitre.org> <516C1714.8070503@mitre.org> <4E1F6AAD24975D4BA5B168042967394367641A87@TK5EX14MBXC283.redmond.corp.microsoft.com> <516C3152.9070603@mitre.org> <4E1F6AAD24975D4BA5B168042967394367641FAB@TK5EX14MBXC283.redmond.corp.microsoft.com> <516C54F2.8040708@mitre.org> <4E1F6AAD24975D4BA5B16804296739436766BCC4@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739436766C964@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.35] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436766D8B9TK5EX14MBXC284r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(479174001)(65554002)(35774002)(377454001)(24454001)(164054002)(51914002)(55885003)(51444002)(564824004)(47976001)(59766001)(54316002)(47736001)(65816001)(69226001)(56776001)(1511001)(50986001)(46102001)(49866001)(16406001)(53806001)(15202345002)(81342001)(74662001)(47446002)(31966008)(6806003)(55846006)(66066001)(56816002)(4396001)(16236675002)(77982001)(80022001)(54356001)(51856001)(74502001)(44976003)(76482001)(81542001)(33656001)(20776003)(71186001)(512954001)(63696002)(79102001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB012; H:TK5EX14HUBC106.redmond.corp.microsoft.com; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 08200063E9 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Registration: Scope Values X-BeenThere: oauth@ietf.org X-Mailman-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, 18 Apr 2013 17:05:22 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436766D8B9TK5EX14MBXC284r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Saying anything normative about "enforcing restrictions" is going beyond RF= C 6749 semantics. Indeed, you'd said that "I agree that we shouldn't try t= o "solve" scope in registration.", but talking about restrictions is going = down the slippery "solving it" path. At most we can say that the two parties are making declarations to one anot= her about scopes that they may choose to use, but we can't assume that this= is an exclusive list and that other scope values such as "urn:example:chan= nel=3DHBO&urn:example:rating=3DG,PG-13" might not be used, even if the clie= nt registers saying that it intends to use the "OATC" scope value. We coul= d maybe even say that some services may use a static set of scopes and migh= t choose to limit the scopes that a client may use to those that it declare= d to the server or to those that the server returned to the client. That's= a HINT that some services might do this. But we can't say anything normat= ive about such possible behaviors, because it goes beyond RFC 6749. -- Mike From: Richer, Justin P. [mailto:jricher@mitre.org] Sent: Thursday, April 18, 2013 9:26 AM To: Anthony Nadalin Cc: Tim Bray; Mike Jones; oauth@ietf.org Subject: Re: [OAUTH-WG] Registration: Scope Values This doesn't actually break the semantics because the client MUST accept wh= at the server tells it over anything that it asks for in the first place. T= he server has the final say. So in this case, if your client asks for nothi= ng, the server says "A B C", the client now knows it can ask for "A B C" sc= opes. I'm still in favor of not putting the restricting language in the scope def= inition at all, instead have it say something like: "Space-separated list of scope values (as described in OAuth 2.0 Section 3.= 3 [RFC6749]) that the Clien= t can use when requesting access tokens from the Authorization Server. As s= cope values are service specific, the means of the Authorization Server enf= orcing this restriction are outside the scope of this specification." Couple this with the overall paragraph that says that the client is request= ing values that the server is potentially overriding with its declarations,= and I think that addresses everything without getting into confusing langu= age that doesn't add to interoperability. -- Justin On Apr 18, 2013, at 12:13 PM, Anthony Nadalin > wrote: If I don't specify a scope, then the server can allocate a default (or defa= ult set), thus that breaks the semantics you describe From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Tim Bray Sent: Thursday, April 18, 2013 9:04 AM To: Mike Jones Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Registration: Scope Values I'm unconvinced, Mike. Obviously you're right about the looseness of OAuth= 2 scope specification, but this is a very specific semantic of what happens= when you register, and I don't think we're bound by history here. If we = can't safely say anything about what the list of scopes means, then I'm wit= h you let's take them out. But the most obvious intended semantic is (from= the client) "I promise to ask only for these" and from the server "These a= re the only ones I'll give you tokens for." Or does someone have use-cases= for an alternative semantic? To make this concrete, I propose the following: "Space-separated list of scope values (as described in OAuth 2.0 Section 3.= 3 [RFC6749]) that the clien= t is declaring to the server that it will restrict itself to when requestin= g access tokens, and that the server is declaring to the client that it is = registered to use when requesting access tokens. Clients SHOULD assume tha= t servers will refuse to grant access tokens for scopes not in the list pro= vided by the server." On Thu, Apr 18, 2013 at 8:55 AM, Mike Jones > wrote: I don't think it's possible to define what it means in an interoperable way= because OAuth didn't specify scopes in an interoperable way. No, I don't = like that either, but I think that's where things are. That's why I was ad= vocating deleting this registration feature entirely. But understanding it might be useful in some contexts, I'm OK keeping it, p= rovided we be clear that the semantics of "registered to use" are service-s= pecific. -- Mike From: Tim Bray [mailto:twbray@google.com] Sent: Thursday, April 18, 2013 8:36 AM To: Mike Jones Cc: Justin Richer; oauth@ietf.org Subject: Re: [OAUTH-WG] Registration: Scope Values On the server-to-client side, what does "registered to use" mean? Does it = mean that the client should assume that any scopes not on the list WILL not= be granted, MAY not be granted.... or what? Is this already covered elsew= here? -T On Thu, Apr 18, 2013 at 8:28 AM, Mike Jones > wrote: Thanks, Justin. I agree with the need for the generic two-sided language. = I'd still keep this language for scope, because we want to capture the "de= claring" aspect in this case: "Space separated list of scope values (as described in OAuth 2.0 Section 3.= 3 [RFC6749]) that the clien= t is declaring to the server that it may use when requesting access tokens = and that the server is declaring to the client that it is registered to use= when requesting access tokens.". You should probably also reinforce that scope values are service-specific a= nd may not consist only of a static set of string values, and that therefor= e, in some cases, an exhaustive list of registered scope values is not poss= ible. -- Mike From: Justin Richer [mailto:jricher@mitre.org] Sent: Monday, April 15, 2013 12:29 PM To: Mike Jones Cc: Tim Bray; oauth@ietf.org Subject: Re: [OAUTH-WG] Registration: Scope Values I think that because the "declaration" issue affects all parameters in the = list, not just scope, we should adopt this in a higher level paragraph and = leave it out of the individual parameter descriptions. Thus, something like= this inserted as the second paragraph in section 2: The client metadata values serve two parallel purposes in the overall OAuth= Dynamic Registration protocol: - the Client requesting its desired values for each parameter to the Autho= rization Server in a [register] or [update] request, - the Authorization Server informing the Client of the current values of e= ach parameter that the Client has been registered to use through a [client = information response]. An Authorization Server MAY override any value that a Client requests durin= g the registration process (including any omitted values) and replace the r= equested value with a default. The normative indications in the following l= ist apply to the Client's declaration of its desired values. The Authorization Server SHOULD provide documentation for any fields that i= t requires to be filled in by the client or to have particular values or fo= rmats. Extensions and profiles... And then remove the sidedness-language from the scope parameter and any oth= er parameters where it might have crept in inadvertently. -- Justin On 04/15/2013 01:29 PM, Mike Jones wrote: We could fix the one-sided language by changing "Space separated list of scope values (as described in OAuth 2.0 Section 3.= 3 [RFC6749]) that the clien= t is declaring that it may use when requesting access tokens." to "Space separated list of scope values (as described in OAuth 2.0 Section 3.= 3 [RFC6749]) that the clien= t is declaring to the server that it may use when requesting access tokens = and that the server is declaring to the client that it is registered to use= when requesting access tokens.". Again, I chose the "registered to use" language carefully - because in the = general case it's not a restriction on the values that the client can use -= just a statement by the server to the client that it is registered to use = those particular values. In both cases, the parties are making declaration= s to one another. If you adopt that language (or keep the original language), then yes, I'd c= onsider this closed. -- Mike From: Justin Richer [mailto:jricher@mitre.org] Sent: Monday, April 15, 2013 9:57 AM To: Mike Jones Cc: Tim Bray; oauth@ietf.org Subject: Re: [OAUTH-WG] Registration: Scope Values I absolutely do not want to delete this feature, as (having implemented it)= I think it's very useful. This is a very established pattern in manual reg= istration: I know of many, many OAuth2 servers and clients that are set up = where the client must pre-register a set of scopes. I don't like the language of "the client is declaring" because it's too one= -sided. The client might not have declared anything, and it might be the se= rver that's declaring something to the client. Deleting the "is declaring" = bit removes that unintended restriction of the language while keeping the o= riginal meaning intact. I actually thought that I had fixed that before the= last draft went in but apparently I missed this one. I will work on clarifying the intent of the whole metadata set in its intro= ductory paragraph(s) so that it's clear that all of these fields are used i= n both of these situations: 1) The client declaring to the server its desire to use a particular value 2) The server declaring to the client that it has been registered with a p= articular value This should hopefully clear up the issue in the editor's note that I curren= tly have at the top of that section right now, too. Mike, since you were the one who originally brought up the issue, and you'r= e fine with the existing text, can I take this as closed now? Assuming that= you agree with deleting "is declaring" for reasons stated above, I'm fine = with leaving everything else as is and staying quiet on what the server has= to do with the scopes. -- Justin On 04/15/2013 12:44 PM, Mike Jones wrote: I think that the existing wording is superior to the proposed changed wordi= ng. The existing wording is: scope OPTIONAL. Space separated list of scope values (as described in OAuth 2.0 Section 3.3 [RFC6749]) that the client is declaring that it may use when requesting access tokens. If omitted, an Authorization Server MAY register a Client with a default set of scopes. For instance, the current "client is declaring" wording will always be corr= ect, whereas as the change to "client can use" wording implies a restrictio= n on client behavior that is not always applicable. The "client is declari= ng" wording was specific and purposefully chosen, and I think should be ret= ained. In particular, we can't do anything that implies that only the regi= stered scopes values can be used. At the OAuth spec level, this is a hint = as to possible future client behavior - not a restriction on future client = behavior. Also, for the reasons that Tim stated, I'm strongly against any "matching" = or "regex" language in the spec pertaining to scopes - as it's not actionab= le. So I'd propose that we leave the existing scope wording in place. Alternat= ively, I'd also be fine with deleting this feature entirely, as I don't thi= nk it's useful in the general case. -- Mike From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org]On Behalf Of Justin Richer Sent: Monday, April 15, 2013 8:05 AM To: Tim Bray; oauth@ietf.org Subject: Re: [OAUTH-WG] Registration: Scope Values On 04/15/2013 10:52 AM, Tim Bray wrote: I'd use the existing wording; it's perfectly clear. Failing that, if there= 's strong demand for registration of structured scopes, bless the use of re= gexes, either PCREs or some careful subset. Thanks for the feedback -- Of these two choices, I'd rather leave it as-is. However, I'd subtract the sentence "If omitted, an Authorization Server MAY= register a Client with a default set of scopes." It adds no value; if th= e client doesn't declare scopes, the client doesn't declare scopes, that's = all. -T Remember, all of these fields aren't just for the client *request*, they're= also for the server's *response* to either a POST, PUT, or GET request. (I= didn't realize it, but perhaps the wording as stated right now doesn't mak= e that clear -- I need to fix that.) The value that it adds is if the clien= t doesn't ask for any particular scopes, the server can still assign it sco= pes and the client can do something smart with that. Dumb clients are allow= ed to ignore it if it doesn't mean anything to them. This is how our server implementation actually works right now. If the clie= nt doesn't ask for anything specific at registration, the server hands it a= bag of "default" scopes. Same thing happens at auth time -- if the client = doesn't ask for any particular scopes, the server hands it all of its regis= tered scopes as a default. Granted, on our server, scopes are just simple s= trings right now, so they get compared at the auth endpoint with an exact s= tring-match metric and set-based logic. -- Justin On Mon, Apr 15, 2013 at 7:35 AM, Justin Richer > wrote: What would you suggest for wording here, then? Keeping in mind that we cann= ot (and don't want to) prohibit expression-based scopes. -- Justin On 04/15/2013 10:33 AM, Tim Bray wrote: No, I mean it's not interoperable at the software-developer level. I can't= register scopes at authorization time with any predictable effect that I c= an write code to support, either client or server side, without out-of-line= non-interoperable knowledge about the behavior of the server. I guess I'm just not used to OAuth's culture of having no expectation that = things will be specified tightly enough that I can write code to implement = as specified. -T On Mon, Apr 15, 2013 at 7:15 AM, Justin Richer > wrote: Scopes aren't meant to be interoperable between services since they're nece= ssarily API-specific. The only interoperable bit is that there's *some* pla= ce to put the values and that it's expressed as a bag of space-separated st= rings. How those strings get interpreted and enforced (which is really what= 's at stake here) is up to the AS and PR (or a higher-level protocol like U= MA). -- Justin On 04/15/2013 10:13 AM, Tim Bray wrote: This, as written, has zero interoperability. I think this feature can real= ly only be made useful in the case where scopes are fixed strings. -T On Apr 15, 2013 6:54 AM, "Justin Richer" > wrote: You are correct that the idea behind the "scope" parameter at registration = is a constraint on authorization-time scopes that are made available. It's = both a means for the client to request a set of valid scopes and for the se= rver to provision (and echo back to the client) a set of valid scopes. I *really* don't want to try to define a matching language for scope expres= sions. For that to work, all servers would need to be able to process the r= egular expressions for all clients, even if the servers themselves only sup= port simple-string scope values. Any regular expression syntax we pick here= is guaranteed to be incompatible with something, and I think the complexit= y doesn't buy much. Also, I think you suddenly have a potential security is= sue if you have a bad regex in place on either end. As it stands today, the server can interpret the incoming registration scop= es and enforce them however it wants to. The real trick comes not from assi= gning the values to a particular client but to enforcing them, and I think = that's always going to be service-specific. We're just not as clear on that= as we could be. After looking over everyone's comments so far, I'd like to propose the foll= owing text for that section: scope OPTIONAL. Space separated list of scope values (as described in OAuth 2.0 Section 3.3 [RFC6749]) that the client can use when requesting access tokens. As scope values are service-specific, the Authorization Server MAY define its own matching rules when determining if a scope value used during an authorization request is valid according to the scope values assigned during registration. Possible matching rules include wildcard patterns, regular expressions, or exactly matching the string. If omitted, an Authorization Server MAY register a Client with a default set of scopes. Comments? Improvements? -- Justin On 04/14/2013 08:23 PM, Manger, James H wrote: Presumably at app registration time any scope specification is really a con= straint on the scope values that can be requested in an authorization flow. So ideally registration should accept rules for matching scopes, as opposed= to actual scope values. You can try to use scope values as their own matching rules. That is fine f= or a small set of "static" scopes. It starts to fail when there are a large= number of scopes, or scopes that can include parameters (resource paths? e= mail addresses?). You can try to patch those failures by allowing services = to define service-specific special "wildcard" scope values that can only be= used during registration (eg "read:*"). Alternatively, replace 'scope' in registration with 'scope_regex' that hold= s a regular expression that all scope values in an authorization flow must = match. -- James Manger _______________________________________________ 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_4E1F6AAD24975D4BA5B16804296739436766D8B9TK5EX14MBXC284r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Saying anything normative= about “enforcing restrictions” is going beyond RFC 6749 semant= ics.  Indeed, you’d said that “I agree that we shou= ldn't try to "solve" scope in registration.R= 21;, but talking about restrictions is going down the slippery “solvi= ng it” path.

 <= /p>

At most we can say that t= he two parties are making declarations to one another about scopes that the= y may choose to use, but we can’t assume that this is an exclusive list and that other scope values such as “urn:example:channel=3DHBO&urn:example:rating=3DG,PG-13<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:#1F497D">” might not be used, even if the client reg= isters saying that it intends to use the “OATC” scope value.  We= could maybe even say that some services may use a static set of scopes and= might choose to limit the scopes that a client may use to those that it de= clared to the server or to those that the server returned to the client.  That’s a HINT that some services might= do this.  But we can’t say anything normative about such possib= le behaviors, because it goes beyond RFC 6749.

 <= /p>

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

 <= /p>

From: Richer, = Justin P. [mailto:jricher@mitre.org]
Sent: Thursday, April 18, 2013 9:26 AM
To: Anthony Nadalin
Cc: Tim Bray; Mike Jones; oauth@ietf.org
Subject: Re: [OAUTH-WG] Registration: Scope Values=

 

This doesn't actually break the semantics because th= e client MUST accept what the server tells it over anything that it asks fo= r in the first place. The server has the final say. So in this case, if you= r client asks for nothing, the server says "A B C", the client now knows it can ask for "A B C&qu= ot; scopes. 

 

I'm still in favor of not putting the restricting la= nguage in the scope definition at all, instead have it say something like:<= o:p>

 

“Spac= e-separated list of scope values (as described in OAuth 2.0 Section 3.3 [RFC6749]) that the Client can use when requesting access token= s from the Authorization Server. As scope values are service specific, the = means of the Authorization Server enforcing this restriction are outside th= e scope of this specification.”

 

Couple this with the overall paragraph that says tha= t the client is requesting values that the server is potentially overriding= with its declarations, and I think that addresses everything without getti= ng into confusing language that doesn't add to interoperability. 

 

 -- Justin

 

On Apr 18, 2013, at 12:13 PM, Anthony Nadalin <tonynad@microsoft.com> wrote:=



If I don’t specify = a scope, then the server can allocate a default (or default set), thus that= breaks the semantics you describe

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Tim Bray
Sent: Thursday, Ap= ril 18, 2013 9:04 AM
To: Mike Jones
Cc: oauth@ietf.org
Subject: Re: [OAUT= H-WG] Registration: Scope Values

 

I’m unconvinced, Mike.  Obviously youR= 17;re right about the looseness of OAuth2 scope specification, but this is = a very specific semantic of what happens when you register, and I don’= ;t think we’re bound by history here.   If we can’t safely say anything about what the list of scopes means, then I'm with you let's = take them out.  But the most obvious intended semantic is (from the cl= ient) “I promise to ask only for these” and from the server = 220;These are the only ones I’ll give you tokens for.”  Or does someone have use-cases for an alternative semantic?

 

To make this concrete, I propose the following:=

“Spac= e-separated list of scope values (as described in OAuth 2.0 Section 3.3 [RFC6749]) that the client is declaring to the server that it w= ill restrict itself to when requesting access tokens, and that the server i= s declaring to the client that it is registered to use when requesting acce= ss tokens.  Clients SHOULD assume that servers will refuse to grant access tokens for scopes n= ot in the list provided by the server.= 221;

 

 

On Thu, Apr 18, 2013 at 8:55 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:=

I don’t think it= 217;s possible to define what it means in an interoperable way because OAut= h didn’t specify scopes in an interoperable way.  No, I don̵= 7;t like that either, but I think that’s where things are.  That’s why = I was advocating deleting this registration feature entirely.

 <= /p>

But understanding it migh= t be useful in some contexts, I’m OK keeping it, provided we be clear= that the semantics of “registered to use” are service-specific= .

 <= /p>

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

 <= /p>

From: Tim Bray [mailto:twbray@google.com] 
Sent: Thursday, Ap= ril 18, 2013 8:36 AM
To: Mike Jones
Cc: Justin Richer;=  oauth@ietf.org


Subject: Re: [OAUT= H-WG] Registration: Scope Values

 

On the server-to-client side, what does “regis= tered to use” mean?  Does it mean that the client should assume = that any scopes not on the list WILL not be granted, MAY not be granted....= or what?  Is this already covered elsewhere? -T

 

On Thu, Apr 18, 2013 at 8:28 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:=

Thanks, Justin.  I a= gree with the need for the generic two-sided language.  I’d stil= l keep this language for scope, because we want to capture the “decla= ring” aspect in this case:

 <= /p>

“Space separated list = of scope values (as described in OAuth 2.0 Section 3.3 [RFC6749]) that the client is declaring to the server that it m= ay use when requesting access tokens and that the server is declaring to th= e client that it is registered to use when requesting access tokens.= ”.

 <= /p>

You should probably also = reinforce that scope values are service-specific and may not consist only o= f a static set of string values, and that therefore, in some cases, an exhaustive list of registered scope values is not possible.=

 <= /p>

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

 <= /p>

From: Justin Richer [mailto:jricher@mitre.org] 
Sent: Monday, Apri= l 15, 2013 12:29 PM

 

I think that because = the "declaration" issue affects all parameters in the list, not j= ust scope, we should adopt this in a higher level paragraph and leave it ou= t of the individual parameter descriptions. Thus, something like this inserted as the second paragraph in section 2:

The client metadata values serve two parallel purpos= es in the overall OAuth Dynamic Registration protocol: 

 - the Client requesting its desired values for each parameter to the = Authorization Server in a [register] or [update] request,
 - the Authorization Server informing the Client of the current values= of each parameter that the Client has been registered to use through a [cl= ient information response]. 

An Authorization Server MAY override any value that a Client requests durin= g the registration process (including any omitted values) and replace the r= equested value with a default. The normative indications in the following l= ist apply to the Client's declaration of its desired values. <= br>
The Authorization Server SHOULD provide documentation for any fields that i= t requires to be filled in by the client or to have particular values or fo= rmats. Extensions and profiles...


And then remove the sidedness-language from the scope parameter and any oth= er parameters where it might have crept in inadvertently. 

 -- Justin

On 04/15/2013 01:29 PM, Mike Jones wrote:=

We could fix the one-side= d language by changing

“Space separated list = of scope values (as described in OAuth 2.0 Section 3.3 [RFC6749]) that the client is declaring that it may use when re= questing access tokens.”

to

“Space separated list = of scope values (as described in OAuth 2.0 Section 3.3 [RFC6749]) that the client is declaring to the server that it m= ay use when requesting access tokens and that the server is declaring to th= e client that it is registered to use when requesting access tokens.= ”.

 <= /p>

Again, I chose the “= ;registered to use” language carefully – because in the general= case it’s not a restriction on the values that the client can use &#= 8211; just a statement by the server to the client that it is registered to use those= particular values.  In both cases, the parties are making declaration= s to one another.

 <= /p>

If you adopt that languag= e (or keep the original language), then yes, I’d consider this closed= .

 <= /p>

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

 <= /p>

From: Justin Richer [mailto:jricher@mitre.org] 
Sent: Monday, Apri= l 15, 2013 9:57 AM
To: Mike Jones
Cc: Tim Bray; oauth@ietf.org
Subject: Re: [OAUT= H-WG] Registration: Scope Values

 

I absolutely do not w= ant to delete this feature, as (having implemented it) I think it's very us= eful. This is a very established pattern in manual registration: I know of = many, many OAuth2 servers and clients that are set up where the client must pre-register a set of scopes. 

I don't like the language of "the client is declaring" because it= 's too one-sided. The client might not have declared anything, and it might= be the server that's declaring something to the client. Deleting the "= ;is declaring" bit removes that unintended restriction of the language while keeping the original meaning intact. I actually thou= ght that I had fixed that before the last draft went in but apparently I mi= ssed this one.

I will work on clarifying the intent of the whole metadata set in its intro= ductory paragraph(s) so that it's clear that all of these fields are used i= n both of these situations:

 1) The client declaring to the server its desire to use a particular = value
 2) The server declaring to the client that it has been registered wit= h a particular value

This should hopefully clear up the issue in the editor's note that I curren= tly have at the top of that section right now, too.

Mike, since you were the one who originally brought up the issue, and you'r= e fine with the existing text, can I take this as closed now? Assuming that= you agree with deleting "is declaring" for reasons stated above,= I'm fine with leaving everything else as is and staying quiet on what the server has to do with the scopes.

 -- Justin

On 04/15/2013 12:44 PM, Mike Jones wrote:=

I think that the existing= wording is superior to the proposed changed wording.  The existing wo= rding is:

 <= /p>

   scope

    &nb= sp; OPTIONAL.  Space separated list of scope values (as described in

    &nb= sp; OAuth 2.0 Section 3.3 [RFC6749]) that the client is declaring that<= /p>

    &nb= sp; it may use when requesting access tokens.  If omitted, an

    &nb= sp; Authorization Server MAY register a Client with a default set of=

    &nb= sp; scopes.

 <= /p>

For instance, the current= “client is declaring” wording will always be correct, whereas = as the change to “client can use” wording implies a restriction= on client behavior that is not always applicable.  The “client is declari= ng” wording was specific and purposefully chosen, and I think should = be retained.  In particular, we can’t do anything that implies t= hat only the registered scopes values can be used.  At the OAuth spec level, this is a hint as to possible future client behavior – n= ot a restriction on future client behavior.

 <= /p>

Also, for the reasons tha= t Tim stated, I’m strongly against any “matching” or R= 20;regex” language in the spec pertaining to scopes – as itR= 17;s not actionable.

 <= /p>

So I’d propose that= we leave the existing scope wording in place.  Alternatively, I’= ;d also be fine with deleting this feature entirely, as I don’t think= it’s useful in the general case.

 <= /p>

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

 <= /p>

From: = oauth-bounces@ietf.org&nbs= p;[mailto:oauth-bounces@ietf.org]On Behalf Of Justin Ric= her
Sent: Monday, Apri= l 15, 2013 8:05 AM
To: Tim Bray; oauth@ietf.org
Subject: Re: [OAUT= H-WG] Registration: Scope Values

 

On 04/15/2013 10:52 A= M, Tim Bray wrote:


I’d use the existing wording; it’s perfe= ctly clear.  Failing that, if there’s strong demand for registra= tion of structured scopes, bless the use of regexes, either PCREs or some c= areful subset.


Thanks for the feedback -- Of these two choices, I'd rather leave it as-is.=  



 

However, I’d subtract the sentence “If o= mitted, an Authorization Server MAY register a Client with a default set of=  scopes.”  It adds no value; if the client doesn’t d= eclare scopes, the client doesn’t declare scopes, that’s all. &= nbsp;-T


Remember, all of these fields aren't just for the client *request*, they're= also for the server's *response* to either a POST, PUT, or GET request. (I= didn't realize it, but perhaps the wording as stated right now doesn't mak= e that clear -- I need to fix that.) The value that it adds is if the client doesn't ask for any particular sco= pes, the server can still assign it scopes and the client can do something = smart with that. Dumb clients are allowed to ignore it if it doesn't mean a= nything to them. 

This is how our server implementation actually works right now. If the clie= nt doesn't ask for anything specific at registration, the server hands it a= bag of "default" scopes. Same thing happens at auth time -- if t= he client doesn't ask for any particular scopes, the server hands it all of its registered scopes as a default. Granted, on= our server, scopes are just simple strings right now, so they get compared= at the auth endpoint with an exact string-match metric and set-based logic= . 

 -- Justin



 

What would you suggest for wording here, then? Keepi= ng in mind that we cannot (and don't want to) prohibit expression-based sco= pes. 

 -- Justin

 

On 04/15/2013 10:33 AM, Tim Bray wrote:

No, I mean it’s not interoperable at the softw= are-developer level.  I can’t register scopes at authorization t= ime with any predictable effect that I can write code to support, either cl= ient or server side, without out-of-line non-interoperable knowledge about the behavior of the server.  

 

I guess I’m just not used to OAuth’s cul= ture of having no expectation that things will be specified tightly enough = that I can write code to implement as specified.  -T

 

On Mon, Apr 15, 2013 at 7:15 AM, Justin Richer <<= a href=3D"mailto:jricher@mitre.org" target=3D"_blank">jricher@mitre.org> wrote:

Scopes aren't meant to be interoperable between serv= ices since they're necessarily API-specific. The only interoperable bit is = that there's *some* place to put the values and that it's expressed as a ba= g of space-separated strings. How those strings get interpreted and enforced (which is really what's at stak= e here) is up to the AS and PR (or a higher-level protocol like UMA).

 -- Justin

 

On 04/15/2013 10:13 AM, Tim Bray wrote:

This, as written, has zero interoperability.  I think this feature = can really only be made useful in the case where scopes are fixed strings.<= o:p>

-T

On Apr 15, 2013 6:54 AM, "Justin Richer" &= lt;jricher@mitre.org> wrote:

You are correct that = the idea behind the "scope" parameter at registration is a constr= aint on authorization-time scopes that are made available. It's both a mean= s for the client to request a set of valid scopes and for the server to provision (and echo back to the client) a set of val= id scopes.

I *really* don't want to try to define a matching language for scope expres= sions. For that to work, all servers would need to be able to process the r= egular expressions for all clients, even if the servers themselves only sup= port simple-string scope values. Any regular expression syntax we pick here is guaranteed to be incompatibl= e with something, and I think the complexity doesn't buy much. Also, I thin= k you suddenly have a potential security issue if you have a bad regex in p= lace on either end. 

As it stands today, the server can interpret the incoming registration scop= es and enforce them however it wants to. The real trick comes not from assi= gning the values to a particular client but to enforcing them, and I think = that's always going to be service-specific. We're just not as clear on that as we could be.

After looking over everyone's comments so far, I'd like to propose the foll= owing text for that section:


   scope
      OPTIONAL.  Space separated list of=
 scope values (as described in
      OAuth 2.0 Section 3.3 [RFC6749]) that the client can use when =

      requesting access tokens.  As=
 scope values are service-specific, 
      the Authorization Server MAY defin=
e its own matching rules when
      determining if a scope value used durin=
g an authorization request
      is valid according to the scope values =
assigned during 
      registration. Possible matching ru=
les include wildcard patterns,
      regular expressions, or exactly matchin=
g the string. If omitted, 
      an Authorization Server MAY regist=
er a Client with a default 
      set of scopes.


Comments? Improvements?

 -- Justin


On 04/14/2013 08:23 PM, Manger, James H wrote:<= /o:p>

Presumably at app registration time any scope specification is really =
a constraint on the scope values that can be requested in an authorization =
flow.
 
So ideally registration should accept rules for matching scopes, as op=
posed to actual scope values.
 
You can try to use scope values as their own matching rules. That is f=
ine for a small set of "static" scopes. It starts to fail when th=
ere are a large number of scopes, or scopes that can include parameters (re=
source paths? email addresses?). You can try to patch those failures by all=
owing services to define service-specific special "wildcard" scop=
e values that can only be used during registration (eg "read:*").=

 
Alternatively, replace 'scope' in registration with 'scope_regex' that=
 holds a regular expression that all scope values in an authorization flow =
must match.
 
--
James Manger
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oaut=
h

 


_______________________________________________
OAuth mailing list
OAuth@ietf.org
<= span style=3D"color:purple">https://www.ietf.org/mailman/listinfo/oauth

 

 

 

 

 

 

 

 

 

_____________________________________= __________
OAuth mailing list
OAuth@ietf.o= rg
https://www.ietf.org/mailman/listinfo/oauth=

 

--_000_4E1F6AAD24975D4BA5B16804296739436766D8B9TK5EX14MBXC284r_-- From twbray@google.com Thu Apr 18 10:10:21 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7FC421F912C for ; Thu, 18 Apr 2013 10:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r1vDwfYeaxI6 for ; Thu, 18 Apr 2013 10:10:19 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id E810B21F9057 for ; Thu, 18 Apr 2013 10:10:18 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id e11so3637373iej.16 for ; Thu, 18 Apr 2013 10:10:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=XsHwHtIjggSL49ejSrB7EpRaR8Fo1KiI2JEYnTIvdtY=; b=QANbfyBcI5FNfIVFLAdQ8HbzycsSfslFwh8iOviIzm7O75AzzkGouIieIBsO+MdPPx ikRtwfmsR1l+1UXG/Hr1dmntJYE8Npq0t+JrkC+WOVX9nZS85Pkncb1ltzi6totZCtCl YErEvXM40Z8tlV4UoGNVHn1huvg681a7LwFlE0PB1iSMBjPTTd2p6jO1pFd7tG+JbxEE 7xEvRmVmEM58ZCjexCWqtvqJ9Q3OnSjwpqHOll7xMkhqG0FsWrWwvt6jFV54GF1G7T+H +b8LrsKfBOAiGcnyDbsqMTierqvvPFwEFxNvXItQJMoihYTBkBCn95ud38090/4rYAuo B4kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=XsHwHtIjggSL49ejSrB7EpRaR8Fo1KiI2JEYnTIvdtY=; b=G2ndR9ph5fQlPM08jp+TKDRSvwn0bXXxfU+vt8iNhrpUMdJ3/JZMRGZUtUudahcBip fTKbA/0rv43J5uDzixpuWKpjV5GGIc2iZarmncuwTYBf997GJ6hp38GyFrSTqD25Epwy 78oVzQB3c/HeUqP/E8Xec5ut8h0z2IAV20AVkUV1e/f5/dGTUOUWdB312LDZBKIG9ciq gkWM5teb63+IJqjsMaMsXtAC89oa0sE50msJcJEr3ExW1JnBR2g7nSFs6vu28nQo2XNg 5zEISpk8PiQGNku8q2xh8+d8Xm1oRaGIt3gYaKjn4SvVY1GAtE1f48Z/c8MnC3qZQsFI wm8g== X-Received: by 10.50.115.42 with SMTP id jl10mr7327727igb.71.1366305018516; Thu, 18 Apr 2013 10:10:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.31.35 with HTTP; Thu, 18 Apr 2013 10:09:48 -0700 (PDT) In-Reply-To: <04cb3c88970842de9b0ec1162e8a86db@BY2PR03MB041.namprd03.prod.outlook.com> References: <255B9BB34FB7D647A506DC292726F6E1150C74DADA@WSMSG3153V.srv.dir.telstra.com> <516C069F.9090308@mitre.org> <516C0B9D.6000402@mitre.org> <516C101F.2090706@mitre.org> <516C1714.8070503@mitre.org> <4E1F6AAD24975D4BA5B168042967394367641A87@TK5EX14MBXC283.redmond.corp.microsoft.com> <516C3152.9070603@mitre.org> <4E1F6AAD24975D4BA5B168042967394367641FAB@TK5EX14MBXC283.redmond.corp.microsoft.com> <516C54F2.8040708@mitre.org> <4E1F6AAD24975D4BA5B16804296739436766BCC4@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739436766C964@TK5EX14MBXC284.redmond.corp.microsoft.com> <04cb3c88970842de9b0ec1162e8a86db@BY2PR03MB041.namprd03.prod.outlook.com> From: Tim Bray Date: Thu, 18 Apr 2013 10:09:48 -0700 Message-ID: To: Anthony Nadalin Content-Type: multipart/alternative; boundary=089e0116058248a84004daa5adab X-Gm-Message-State: ALoCoQkrH6cR45M7+Lt8rqlMlNqijORhREDsWcSrukBKXce5CEvT2oy4yMA+lOmpa4GjYM5ERMZXZSDbJu5Yg6dsw1cAYsAH6mHYUASjjn4cHr7QMVu1OxB8dA5BkUmBMT/camvFbeGyxGNM3gIMxn67inn4AT7aYfF10HwsTlnCNQRlxhZh7RZzEMcWSybJrtXx+7qQMdgY Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Registration: Scope Values X-BeenThere: oauth@ietf.org X-Mailman-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, 18 Apr 2013 17:10:22 -0000 --089e0116058248a84004daa5adab Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable OK, I went in a corner and thought about this: 1. We currently are an OAuth 2 provider for a wide range of resources, and we=E2=80=99re feeling the demand for a registration endpoint. Regis= tration endpoints are tricky and involve legal (Terms-of-service) and business issues. 2. I=E2=80=99m thinking that if we do get into registration, it=E2=80=99= s going to be super helpful, when someone wants to register for a Client ID/Secret, to know what they=E2=80=99re going to use it for. I suspect our business/l= egal thinking would be very different between someone registering to access G= +, and someone registering to use the big advertising APIs. 3. So we could probably make good use of a client-asserted list of =E2= =80=9Cwhat we=E2=80=99re going to ask for=E2=80=9D and feel comfy in rejecting toke= n requests from clients for scopes that aren=E2=80=99t on the list they registered with.= Or even rejecting registrations if we don=E2=80=99t like their list of scopes. 4. On the other hand, we could probably also solve the problem by having a separate registration endpoint for each API. 5. I=E2=80=99m having real trouble thinking of good use that a client co= uld make of a server-provided list of scopes that they are prepared to give token= s for. 6. It=E2=80=99s also the case that people are going to insist on using t= okens with fancy internal structures, and there=E2=80=99s no good interoperabl= e way to use these registration-time scope lists to deal with this situation. 7. I=E2=80=99d really like to stop the OAuth bleeding by resisting putti= ng anything in the spec that doesn=E2=80=99t have crisply defined and inter= operable semantics. So, absent more plausible use cases, I=E2=80=99d be comfy with: 1. Dropping the whole registration-time list of scopes, as Mike suggested, or 2. Dropping the server-to-client part of it, and for client-to-server specify the semantic that the client MUST NOT request tokens for scopes = not in the registration-time list, or 3. Retaining both directions only if they come with crisply defined interoperable semantics On Thu, Apr 18, 2013 at 9:31 AM, Anthony Nadalin wro= te: > Client asks for nothing and the server returns =E2=80=9CA=E2=80=9D, thus= does not match > your =E2=80=9CI promise to ask only for these=E2=80=9D and from the serve= r =E2=80=9CThese are the > only ones I=E2=80=99ll give you tokens for.=E2=80=9D=E2=80=9D As the clie= nt may also ask for X and > get X.**** > > ** ** > > *From:* Tim Bray [mailto:twbray@google.com] > *Sent:* Thursday, April 18, 2013 9:26 AM > *To:* Anthony Nadalin > *Cc:* Mike Jones; oauth@ietf.org > > *Subject:* Re: [OAUTH-WG] Registration: Scope Values**** > > ** ** > > Hm... how so? If a server is able to specify in advance which set of > scopes it will honor (which may or may not be related to what the client > specified in the registration) I can see that being useful. I don=E2=80= =99t see a > requirement for a linkage between the client=E2=80=99s request and the se= rver=E2=80=99s > response. -T**** > > ** ** > > On Thu, Apr 18, 2013 at 9:13 AM, Anthony Nadalin > wrote:**** > > If I don=E2=80=99t specify a scope, then the server can allocate a defau= lt (or > default set), thus that breaks the semantics you describe**** > > **** > > *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf > Of *Tim Bray > *Sent:* Thursday, April 18, 2013 9:04 AM > *To:* Mike Jones > *Cc:* oauth@ietf.org**** > > > *Subject:* Re: [OAUTH-WG] Registration: Scope Values**** > > **** > > I=E2=80=99m unconvinced, Mike. Obviously you=E2=80=99re right about the = looseness of > OAuth2 scope specification, but this is a very specific semantic of what > happens when you register, and I don=E2=80=99t think we=E2=80=99re bound = by history here. > If we can=E2=80=99t safely say anything about what the list of scopes mea= ns, then > I'm with you let's take them out. But the most obvious intended semantic > is (from the client) =E2=80=9CI promise to ask only for these=E2=80=9D an= d from the server > =E2=80=9CThese are the only ones I=E2=80=99ll give you tokens for.=E2=80= =9D Or does someone have > use-cases for an alternative semantic?**** > > **** > > To make this concrete, I propose the following:**** > > =E2=80=9CSpace-separated list of scope values (as described in OAuth 2.0 = Section 3.3 > [RFC6749] ) that the > client is declaring to the server that it will restrict itself to when > requesting access tokens, and that the server is declaring to the client > that it is registered to use when requesting access tokens. Clients > SHOULD assume that servers will refuse to grant access tokens for scopes > not in the list provided by the server.=E2=80=9D**** > > **** > > **** > > On Thu, Apr 18, 2013 at 8:55 AM, Mike Jones > wrote:**** > > I don=E2=80=99t think it=E2=80=99s possible to define what it means in a= n interoperable > way because OAuth didn=E2=80=99t specify scopes in an interoperable way. = No, I > don=E2=80=99t like that either, but I think that=E2=80=99s where things a= re. That=E2=80=99s why I > was advocating deleting this registration feature entirely.**** > > **** > > But understanding it might be useful in some contexts, I=E2=80=99m OK kee= ping it, > provided we be clear that the semantics of =E2=80=9Cregistered to use=E2= =80=9D are > service-specific.**** > > **** > > -- Mike**** > > **** > > *From:* Tim Bray [mailto:twbray@google.com] > *Sent:* Thursday, April 18, 2013 8:36 AM > *To:* Mike Jones > *Cc:* Justin Richer; oauth@ietf.org**** > > > *Subject:* Re: [OAUTH-WG] Registration: Scope Values**** > > **** > > On the server-to-client side, what does =E2=80=9Cregistered to use=E2=80= =9D mean? Does it > mean that the client should assume that any scopes not on the list WILL n= ot > be granted, MAY not be granted.... or what? Is this already covered > elsewhere? -T**** > > **** > > On Thu, Apr 18, 2013 at 8:28 AM, Mike Jones > wrote:**** > > Thanks, Justin. I agree with the need for the generic two-sided > language. I=E2=80=99d still keep this language for scope, because we wan= t to > capture the =E2=80=9Cdeclaring=E2=80=9D aspect in this case:**** > > **** > > =E2=80=9CSpace separated list of scope values (as described in OAuth 2.0 = Section 3.3 > [RFC6749] ) that the > client is declaring to the server that it may use when requesting access > tokens and that the server is declaring to the client that it is register= ed > to use when requesting access tokens.=E2=80=9D.**** > > **** > > You should probably also reinforce that scope values are service-specific > and may not consist only of a static set of string values, and that > therefore, in some cases, an exhaustive list of registered scope values i= s > not possible.**** > > **** > > -- Mike**** > > **** > > *From:* Justin Richer [mailto:jricher@mitre.org] > *Sent:* Monday, April 15, 2013 12:29 PM**** > > > *To:* Mike Jones > *Cc:* Tim Bray; oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Registration: Scope Values**** > > **** > > I think that because the "declaration" issue affects all parameters in th= e > list, not just scope, we should adopt this in a higher level paragraph an= d > leave it out of the individual parameter descriptions. Thus, something li= ke > this inserted as the second paragraph in section 2:**** > > The client metadata values serve two parallel purposes in the overall > OAuth Dynamic Registration protocol: > > - the Client requesting its desired values for each parameter to the > Authorization Server in a [register] or [update] request, > - the Authorization Server informing the Client of the current values of > each parameter that the Client has been registered to use through a [clie= nt > information response]. > > An Authorization Server MAY override any value that a Client requests > during the registration process (including any omitted values) and replac= e > the requested value with a default. The normative indications in the > following list apply to the Client's declaration of its desired values. > > The Authorization Server SHOULD provide documentation for any fields that > it requires to be filled in by the client or to have particular values or > formats. Extensions and profiles...**** > > > And then remove the sidedness-language from the scope parameter and any > other parameters where it might have crept in inadvertently. > > -- Justin**** > > On 04/15/2013 01:29 PM, Mike Jones wrote:**** > > We could fix the one-sided language by changing**** > > =E2=80=9CSpace separated list of scope values (as described in OAuth 2.0 = Section 3.3 > [RFC6749] ) that the > client is declaring that it may use when requesting access tokens.=E2=80= =9D**** > > to**** > > =E2=80=9CSpace separated list of scope values (as described in OAuth 2.0 = Section 3.3 > [RFC6749] ) that the > client is declaring to the server that it may use when requesting access > tokens and that the server is declaring to the client that it is register= ed > to use when requesting access tokens.=E2=80=9D.**** > > **** > > Again, I chose the =E2=80=9Cregistered to use=E2=80=9D language carefully= =E2=80=93 because in the > general case it=E2=80=99s not a restriction on the values that the client= can use =E2=80=93 > just a statement by the server to the client that it is registered to use > those particular values. In both cases, the parties are making > declarations to one another.**** > > **** > > If you adopt that language (or keep the original language), then yes, I= =E2=80=99d > consider this closed.**** > > **** > > -- Mike**** > > **** > > *From:* Justin Richer [mailto:jricher@mitre.org ] > *Sent:* Monday, April 15, 2013 9:57 AM > *To:* Mike Jones > *Cc:* Tim Bray; oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Registration: Scope Values**** > > **** > > I absolutely do not want to delete this feature, as (having implemented > it) I think it's very useful. This is a very established pattern in manua= l > registration: I know of many, many OAuth2 servers and clients that are se= t > up where the client must pre-register a set of scopes. > > I don't like the language of "the client is declaring" because it's too > one-sided. The client might not have declared anything, and it might be t= he > server that's declaring something to the client. Deleting the "is > declaring" bit removes that unintended restriction of the language while > keeping the original meaning intact. I actually thought that I had fixed > that before the last draft went in but apparently I missed this one. > > I will work on clarifying the intent of the whole metadata set in its > introductory paragraph(s) so that it's clear that all of these fields are > used in both of these situations: > > 1) The client declaring to the server its desire to use a particular val= ue > 2) The server declaring to the client that it has been registered with a > particular value > > This should hopefully clear up the issue in the editor's note that I > currently have at the top of that section right now, too. > > Mike, since you were the one who originally brought up the issue, and > you're fine with the existing text, can I take this as closed now? Assumi= ng > that you agree with deleting "is declaring" for reasons stated above, I'm > fine with leaving everything else as is and staying quiet on what the > server has to do with the scopes. > > -- Justin**** > > On 04/15/2013 12:44 PM, Mike Jones wrote:**** > > I think that the existing wording is superior to the proposed changed > wording. The existing wording is:**** > > **** > > scope**** > > OPTIONAL. Space separated list of scope values (as described in***= * > > OAuth 2.0 Section 3.3 [RFC6749]) > that the client is declaring that**** > > it may use when requesting access tokens. If omitted, an**** > > Authorization Server MAY register a Client with a default set of***= * > > scopes.**** > > **** > > For instance, the current =E2=80=9Cclient is declaring=E2=80=9D wording w= ill always be > correct, whereas as the change to =E2=80=9Cclient can use=E2=80=9D wordin= g implies a > restriction on client behavior that is not always applicable. The =E2=80= =9Cclient > is declaring=E2=80=9D wording was specific and purposefully chosen, and I= think > should be retained. In particular, we can=E2=80=99t do anything that imp= lies that > only the registered scopes values can be used. At the OAuth spec level, > this is a hint as to possible future client behavior =E2=80=93 not a rest= riction on > future client behavior.**** > > **** > > Also, for the reasons that Tim stated, I=E2=80=99m strongly against any = =E2=80=9Cmatching=E2=80=9D > or =E2=80=9Cregex=E2=80=9D language in the spec pertaining to scopes =E2= =80=93 as it=E2=80=99s not > actionable.**** > > **** > > So I=E2=80=99d propose that we leave the existing scope wording in place. > Alternatively, I=E2=80=99d also be fine with deleting this feature entire= ly, as I > don=E2=80=99t think it=E2=80=99s useful in the general case.**** > > **** > > -- Mike**** > > **** > > *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] > *On Behalf Of *Justin Richer > *Sent:* Monday, April 15, 2013 8:05 AM > *To:* Tim Bray; oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Registration: Scope Values**** > > **** > > On 04/15/2013 10:52 AM, Tim Bray wrote:**** > > I=E2=80=99d use the existing wording; it=E2=80=99s perfectly clear. Fail= ing that, if > there=E2=80=99s strong demand for registration of structured scopes, bles= s the use > of regexes, either PCREs or some careful subset.**** > > > Thanks for the feedback -- Of these two choices, I'd rather leave it > as-is. > > **** > > **** > > However, I=E2=80=99d subtract the sentence =E2=80=9CIf omitted, an Author= ization Server > MAY register a Client with a default set of scopes.=E2=80=9D It adds no= value; if > the client doesn=E2=80=99t declare scopes, the client doesn=E2=80=99t dec= lare scopes, > that=E2=80=99s all. -T**** > > > Remember, all of these fields aren't just for the client *request*, > they're also for the server's *response* to either a POST, PUT, or GET > request. (I didn't realize it, but perhaps the wording as stated right no= w > doesn't make that clear -- I need to fix that.) The value that it adds is > if the client doesn't ask for any particular scopes, the server can still > assign it scopes and the client can do something smart with that. Dumb > clients are allowed to ignore it if it doesn't mean anything to them. > > This is how our server implementation actually works right now. If the > client doesn't ask for anything specific at registration, the server hand= s > it a bag of "default" scopes. Same thing happens at auth time -- if the > client doesn't ask for any particular scopes, the server hands it all of > its registered scopes as a default. Granted, on our server, scopes are ju= st > simple strings right now, so they get compared at the auth endpoint with = an > exact string-match metric and set-based logic. > > -- Justin > > **** > > **** > > On Mon, Apr 15, 2013 at 7:35 AM, Justin Richer wrote:= * > *** > > What would you suggest for wording here, then? Keeping in mind that we > cannot (and don't want to) prohibit expression-based scopes. > > -- Justin **** > > **** > > On 04/15/2013 10:33 AM, Tim Bray wrote:**** > > No, I mean it=E2=80=99s not interoperable at the software-developer leve= l. I > can=E2=80=99t register scopes at authorization time with any predictable = effect > that I can write code to support, either client or server side, without > out-of-line non-interoperable knowledge about the behavior of the server. > **** > > **** > > I guess I=E2=80=99m just not used to OAuth=E2=80=99s culture of having no= expectation that > things will be specified tightly enough that I can write code to implemen= t > as specified. -T**** > > **** > > On Mon, Apr 15, 2013 at 7:15 AM, Justin Richer wrote:= * > *** > > Scopes aren't meant to be interoperable between services since they're > necessarily API-specific. The only interoperable bit is that there's *som= e* > place to put the values and that it's expressed as a bag of space-separat= ed > strings. How those strings get interpreted and enforced (which is really > what's at stake here) is up to the AS and PR (or a higher-level protocol > like UMA). > > -- Justin **** > > **** > > On 04/15/2013 10:13 AM, Tim Bray wrote:**** > > This, as written, has zero interoperability. I think this feature can > really only be made useful in the case where scopes are fixed strings.***= * > > -T**** > > On Apr 15, 2013 6:54 AM, "Justin Richer" wrote:**** > > You are correct that the idea behind the "scope" parameter at registratio= n > is a constraint on authorization-time scopes that are made available. It'= s > both a means for the client to request a set of valid scopes and for the > server to provision (and echo back to the client) a set of valid scopes. > > I *really* don't want to try to define a matching language for scope > expressions. For that to work, all servers would need to be able to proce= ss > the regular expressions for all clients, even if the servers themselves > only support simple-string scope values. Any regular expression syntax we > pick here is guaranteed to be incompatible with something, and I think th= e > complexity doesn't buy much. Also, I think you suddenly have a potential > security issue if you have a bad regex in place on either end. > > As it stands today, the server can interpret the incoming registration > scopes and enforce them however it wants to. The real trick comes not fro= m > assigning the values to a particular client but to enforcing them, and I > think that's always going to be service-specific. We're just not as clear > on that as we could be. > > After looking over everyone's comments so far, I'd like to propose the > following text for that section:**** > > scope**** > > OPTIONAL. Space separated list of scope values (as described in***= * > > OAuth 2.0 Section 3.3 [RFC6749] ) that the client can use when **** > > requesting access tokens. As scope values are service-specific, **= ** > > the Authorization Server MAY define its own matching rules when**** > > determining if a scope value used during an authorization request**= ** > > is valid according to the scope values assigned during **** > > registration. Possible matching rules include wildcard patterns,***= * > > regular expressions, or exactly matching the string. If omitted, **= ** > > an Authorization Server MAY register a Client with a default **** > > set of scopes.**** > > > Comments? Improvements? > > -- Justin**** > > On 04/14/2013 08:23 PM, Manger, James H wrote:**** > > Presumably at app registration time any scope specification is really a c= onstraint on the scope values that can be requested in an authorization flo= w.**** > > **** > > So ideally registration should accept rules for matching scopes, as oppos= ed to actual scope values.**** > > **** > > You can try to use scope values as their own matching rules. That is fine= for a small set of "static" scopes. It starts to fail when there are a lar= ge number of scopes, or scopes that can include parameters (resource paths?= email addresses?). You can try to patch those failures by allowing service= s to define service-specific special "wildcard" scope values that can only = be used during registration (eg "read:*").**** > > **** > > Alternatively, replace 'scope' in registration with 'scope_regex' that ho= lds a regular expression that all scope values in an authorization flow mus= t match.**** > > **** > > --**** > > James Manger**** > > _______________________________________________**** > > 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**** > > **** > > **** > > **** > > **** > > **** > > **** > > **** > > **** > > **** > > ** ** > --089e0116058248a84004daa5adab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
OK, I went in a corner and thought about this:
  1. We currently are an OAuth 2 provider for a wide range of resou= rces, and we=E2=80=99re feeling the demand for a registration endpoint. =C2= =A0Registration endpoints are tricky and involve legal (Terms-of-service) a= nd business issues.
  2. I=E2=80=99m thinking that if we do get into registration, it=E2= =80=99s going to be super helpful, when someone wants to register for a Cli= ent ID/Secret, to know what they=E2=80=99re going to use it for. =C2=A0I su= spect our business/legal thinking would be very different between someone r= egistering to access G+, and someone registering to use the big advertising= APIs.
  3. So we could probably make good use of a client-asserted list of = =E2=80=9Cwhat we=E2=80=99re going to ask for=E2=80=9D and feel comfy in rej= ecting token requests from clients for scopes that aren=E2=80=99t on the li= st they registered with. =C2=A0Or even rejecting registrations if we don=E2= =80=99t like their list of scopes.
  4. On the other hand, we could probably also solve the problem by ha= ving a separate registration endpoint for each API.
  5. I=E2=80= =99m having real trouble thinking of good use that a client could make of a= server-provided list of scopes that they are prepared to give tokens for.<= /li>
  6. It=E2=80=99s also the case that people are going to insist on usi= ng tokens with fancy internal structures, and there=E2=80=99s no good inter= operable way to use these registration-time scope lists to deal with this s= ituation.
  7. I=E2=80=99d really like to stop the OAuth bleeding by resisting p= utting anything in the spec that doesn=E2=80=99t have crisply defined and i= nteroperable semantics.
So, absent more plausible use c= ases, I=E2=80=99d be comfy with:
  1. Dropping the whole registration-time list of= scopes, as Mike suggested, or
  2. Dropping the server-to-client = part of it, and for client-to-server specify the semantic that the client M= UST NOT request tokens for scopes not in the registration-time list, or
  3. Retaining both directions only if they come with crisply defined = interoperable semantics



On Thu, Apr 18, 2013 a= t 9:31 AM, Anthony Nadalin <tonynad@microsoft.com> wrote= :

Client asks for nothing a= nd the server returns =E2=80=9CA=E2=80=9D, thus does not match your =E2=80= =9CI promise to ask only for these=E2=80=9D and from the server =E2=80=9CTh= ese are the only ones I=E2=80=99ll give you tokens for.=E2=80=9D=E2=80=9D As the client may also= ask for X and get X.

=C2=A0

From: Tim Br= ay [mailto:twbray@go= ogle.com]
Sent: Thursday, April 18, 2013 9:26 AM
To: Anthony Nadalin
Cc: Mike Jones; = oauth@ietf.org


Subject: Re: [OAUTH-WG] Registration: Scope Values

=C2=A0

Hm... how so? =C2=A0If a server is able to specify i= n advance which set of scopes it will honor (which may or may not be relate= d to what the client specified in the registration) I can see that being us= eful. =C2=A0I don=E2=80=99t see a requirement for a linkage between the client=E2=80=99s request and the server=E2=80=99s resp= onse. =C2=A0-T

=C2=A0<= /p>

On Thu, Apr 18, 2013 at 9:13 AM, Anthony Nadalin <= ;tonynad@microso= ft.com> wrote:

If I don=E2=80=99t specif= y a scope, then the server can allocate a default (or default set), thus th= at breaks the semantics you describe

=C2=A0

From: oauth-bounces@i= etf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Tim Bray
Sent: Thursday, April 18, 2013 9:04 AM
To: Mike Jones
Cc: oauth@ietf.o= rg


Subject: Re: [OAUTH-WG] Registration: Scope Values

=C2=A0

I=E2=80=99m unconvinced, Mike. =C2=A0Obviously you= =E2=80=99re right about the looseness of OAuth2 scope specification, but th= is is a very specific semantic of what happens when you register, and I don= =E2=80=99t think we=E2=80=99re bound by history here. =C2=A0 If we can=E2=80=99t safe= ly say anything about what the list of scopes means, then I'm with you = let's take them out. =C2=A0But the most obvious intended semantic is (f= rom the client) =E2=80=9CI promise to ask only for these=E2=80=9D and from = the server =E2=80=9CThese are the only ones I=E2=80=99ll give you tokens for.=E2=80= =9D =C2=A0Or does someone have use-cases for an alternative semantic?

=C2=A0

To make this concrete, I propose the following:

=E2=80=9CSpace-separated list of sc= ope values (as described in OAuth 2.0=C2=A0Section=C2=A03.3 [RFC6749]) that the client is declaring to the server that it will res= trict itself to when requesting access tokens, and that the server is decla= ring to the client that it is registered to use when requesting access toke= ns. =C2=A0Clients SHOULD assume that servers will refuse to grant access tokens for scopes n= ot in the list provided by the server.=E2= =80=9D

=C2=A0

=C2=A0<= /p>

On Thu, Apr 18, 2013 at 8:55 AM, Mike Jones <Michael.Jones@= microsoft.com> wrote:

I don=E2=80=99t think it= =E2=80=99s possible to define what it means in an interoperable way because= OAuth didn=E2=80=99t specify scopes in an interoperable way.=C2=A0 No, I don=E2=80=99t like tha= t either, but I think that=E2=80=99s where things are.=C2=A0 That=E2=80=99s= why I was advocating deleting this registration feature entirely.

=C2=A0

But understanding it migh= t be useful in some contexts, I=E2=80=99m OK keeping it, provided we be cle= ar that the semantics of =E2=80=9Cregistered to use=E2=80=9D are service-specific.=

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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

=C2=A0

From: Tim Bray= [mailto:twbray@goog= le.com]
Sent: Thursday, April 18, 2013 8:36 AM
To: Mike Jones
Cc: Justin Richer; oauth@ietf.org


Subject: Re: [OAUTH-WG] Registration: Scope Values

=C2=A0

On the server-to-client side, what does =E2=80=9Creg= istered to use=E2=80=9D mean? =C2=A0Does it mean that the client should ass= ume that any scopes not on the list WILL not be granted, MAY not be granted= .... or what? =C2=A0Is this already covered elsewhere? -T

=C2=A0<= /p>

On Thu, Apr 18, 2013 at 8:28 AM, Mike Jones <Michael.Jones@= microsoft.com> wrote:

Thanks, Justin.=C2=A0 I a= gree with the need for the generic two-sided language.=C2=A0 I=E2=80=99d st= ill keep this language for scope, because we want to capture the =E2=80=9Cdeclaring=E2=80=9D aspe= ct in this case:

=C2=A0

=E2=80=9CSpace separated list of scope values (as de= scribed in OAuth 2.0 Section=C2=A03.3 [RFC6749]) that the client is declaring to the serve= r that it may use when requesting access tokens and that the server is decl= aring to the client that it is registered to use when requesting access tokens.=E2= =80=9D.

=C2=A0

You should probably also = reinforce that scope values are service-specific and may not consist only of a static set of string values, and that therefore, in some cases, an ex= haustive list of registered scope values is not possible.<= /u>

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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

=C2=A0

From: Justin R= icher [mailto:jriche= r@mitre.org]
Sent: Monday, April 15, 2013 12:29 PM


To: Mike Jones
Cc: Tim Bray; oa= uth@ietf.org
Subject: Re: [OAUTH-WG] Registration: Scope Values

=C2=A0

I think that because = the "declaration" issue affects all parameters in the list, not j= ust scope, we should adopt this in a higher level paragraph and leave it ou= t of the individual parameter descriptions. Thus, something like this inserted as the second paragraph i= n section 2:

The client metadata values serve two parallel purpos= es in the overall OAuth Dynamic Registration protocol:

=C2=A0- the Client requesting its desired values for each parameter to the = Authorization Server in a [register] or [update] request,
=C2=A0- the Authorization Server informing the Client of the current values= of each parameter that the Client has been registered to use through a [cl= ient information response].

An Authorization Server MAY override any value that a Client requests durin= g the registration process (including any omitted values) and replace the r= equested value with a default. The normative indications in the following l= ist apply to the Client's declaration of its desired values.

The Authorization Server SHOULD provide documentation for any fields that i= t requires to be filled in by the client or to have particular values or fo= rmats. Extensions and profiles...


And then remove the sidedness-language from the scope parameter and any oth= er parameters where it might have crept in inadvertently.

=C2=A0-- Justin

On 04/15/2013 01:29 PM, Mike Jones wrote:<= /u>

We could fix the one-side= d language by changing

=E2=80=9CSpace separated list of scope values (as de= scribed in OAuth 2.0 Section=C2=A03.3 [RFC6749]) that the client is declaring that it may = use when requesting access tokens.=E2=80= =9D

to

=E2=80=9CSpace separated list of scope values (as de= scribed in OAuth 2.0 Section=C2=A03.3 [RFC6749]) that the client is declaring to the serve= r that it may use when requesting access tokens and that the server is decl= aring to the client that it is registered to use when requesting access tokens.=E2= =80=9D.

=C2=A0

Again, I chose the =E2=80= =9Cregistered to use=E2=80=9D language carefully =E2=80=93 because in the g= eneral case it=E2=80=99s not a restriction on the values that the client can use =E2=80=93 just a state= ment by the server to the client that it is registered to use those particu= lar values.=C2=A0 In both cases, the parties are making declarations to one= another.

=C2=A0

If you adopt that languag= e (or keep the original language), then yes, I=E2=80=99d consider this clos= ed.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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

=C2=A0

From: Justin R= icher [mailto:jriche= r@mitre.org]
Sent: Monday, April 15, 2013 9:57 AM
To: Mike Jones
Cc: Tim Bray; oa= uth@ietf.org
Subject: Re: [OAUTH-WG] Registration: Scope Values<= /u>

=C2=A0

I absolutely do not w= ant to delete this feature, as (having implemented it) I think it's ver= y useful. This is a very established pattern in manual registration: I know= of many, many OAuth2 servers and clients that are set up where the client must pre-register a s= et of scopes.

I don't like the language of "the client is declaring" becaus= e it's too one-sided. The client might not have declared anything, and = it might be the server that's declaring something to the client. Deleti= ng the "is declaring" bit removes that unintended restriction of the language while keeping the original meaning intact. I actually thou= ght that I had fixed that before the last draft went in but apparently I mi= ssed this one.

I will work on clarifying the intent of the whole metadata set in its intro= ductory paragraph(s) so that it's clear that all of these fields are us= ed in both of these situations:

=C2=A01) The client declaring to the server its desire to use a particular = value
=C2=A02) The server declaring to the client that it has been registered wit= h a particular value

This should hopefully clear up the issue in the editor's note that I cu= rrently have at the top of that section right now, too.

Mike, since you were the one who originally brought up the issue, and you&#= 39;re fine with the existing text, can I take this as closed now? Assuming = that you agree with deleting "is declaring" for reasons stated ab= ove, I'm fine with leaving everything else as is and staying quiet on what the server has to do with the scopes.

=C2=A0-- Justin

On 04/15/2013 12:44 PM, Mike Jones wrote:<= /u>

I think that the existing= wording is superior to the proposed changed wording.=C2=A0 The existing wo= rding is:

=C2=A0

=C2=A0=C2=A0 scope

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 OPTIONAL.=C2= =A0 Space separated list of scope values (as described in<= /u>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 OAuth 2.0 Section=C2=A03.3 [RFC6749]) that the client is declaring that<= u>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 it may use whe= n requesting access tokens.=C2=A0 If omitted, an

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Authorization = Server MAY register a Client with a default set of

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 scopes.=

=C2=A0

For instance, the current= =E2=80=9Cclient is declaring=E2=80=9D wording will always be correct, wher= eas as the change to =E2=80=9Cclient can use=E2=80=9D wording implies a restriction on clien= t behavior that is not always applicable.=C2=A0 The =E2=80=9Cclient is decl= aring=E2=80=9D wording was specific and purposefully chosen, and I think sh= ould be retained.=C2=A0 In particular, we can=E2=80=99t do anything that im= plies that only the registered scopes values can be used.=C2=A0 At the OAuth spec lev= el, this is a hint as to possible future client behavior =E2=80=93 not a re= striction on future client behavior.

=C2=A0

Also, for the reasons tha= t Tim stated, I=E2=80=99m strongly against any =E2=80=9Cmatching=E2=80=9D o= r =E2=80=9Cregex=E2=80=9D language in the spec pertaining to scopes =E2=80=93 as it=E2=80=99s not actionable.

=C2=A0

So I=E2=80=99d propose th= at we leave the existing scope wording in place.=C2=A0 Alternatively, I=E2= =80=99d also be fine with deleting this feature entirely, as I don=E2=80=99t think it=E2=80=99s= useful in the general case.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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

=C2=A0

From: oauth-bounces@i= etf.org [ma= ilto:oauth-bounces@ietf.org] On Behalf Of Justin Richer
Sent: Monday, April 15, 2013 8:05 AM
To: Tim Bray; oa= uth@ietf.org
Subject: Re: [OAUTH-WG] Registration: Scope Values<= /u>

=C2=A0

On 04/15/2013 10:52 A= M, Tim Bray wrote:

I=E2=80=99d use the existing wording; it=E2=80=99s p= erfectly clear. =C2=A0Failing that, if there=E2=80=99s strong demand for re= gistration of structured scopes, bless the use of regexes, either PCREs or = some careful subset.


Thanks for the feedback -- Of these two choices, I'd rather leave it as= -is.

=C2=A0

However, I=E2=80=99d subtract the sentence =E2=80=9C= If omitted, an Authorization Server MAY register a Client with a default se= t of =C2=A0scopes.=E2=80=9D =C2=A0It adds no value; if the client doesn=E2= =80=99t declare scopes, the client doesn=E2=80=99t declare scopes, that=E2=80=99s all. =C2=A0-T=


Remember, all of these fields aren't just for the client *request*, the= y're also for the server's *response* to either a POST, PUT, or GET= request. (I didn't realize it, but perhaps the wording as stated right= now doesn't make that clear -- I need to fix that.) The value that it adds is if the client doesn't ask for any particular= scopes, the server can still assign it scopes and the client can do someth= ing smart with that. Dumb clients are allowed to ignore it if it doesn'= t mean anything to them.

This is how our server implementation actually works right now. If the clie= nt doesn't ask for anything specific at registration, the server hands = it a bag of "default" scopes. Same thing happens at auth time -- = if the client doesn't ask for any particular scopes, the server hands it all of its registered scopes as a default. Granted, on= our server, scopes are just simple strings right now, so they get compared= at the auth endpoint with an exact string-match metric and set-based logic= .

=C2=A0-- Justin

=C2=A0<= /p>

On Mon, Apr 15, 2013 at 7:35 AM, Justin Richer <<= a href=3D"mailto:jricher@mitre.org" target=3D"_blank">jricher@mitre.org= > wrote:

What would you suggest for wording here, then? Keepi= ng in mind that we cannot (and don't want to) prohibit expression-based= scopes.

=C2=A0-- Justin

=C2=A0<= /p>

On 04/15/2013 10:33 AM, Tim Bray wrote:

No, I mean it=E2=80=99s not interoperable at the sof= tware-developer level. =C2=A0I can=E2=80=99t register scopes at authorizati= on time with any predictable effect that I can write code to support, eithe= r client or server side, without out-of-line non-interoperable knowledge abo= ut the behavior of the server. =C2=A0

=C2=A0

I guess I=E2=80=99m just not used to OAuth=E2=80=99s= culture of having no expectation that things will be specified tightly eno= ugh that I can write code to implement as specified. =C2=A0-T=

=C2=A0<= /p>

On Mon, Apr 15, 2013 at 7:15 AM, Justin Richer <<= a href=3D"mailto:jricher@mitre.org" target=3D"_blank">jricher@mitre.org= > wrote:

Scopes aren't meant to be interoperable between = services since they're necessarily API-specific. The only interoperable= bit is that there's *some* place to put the values and that it's expressed as a bag of space-separated strings. How those strings = get interpreted and enforced (which is really what's at stake here) is = up to the AS and PR (or a higher-level protocol like UMA).

=C2=A0-- Justin

=C2=A0<= /p>

On 04/15/2013 10:13 AM, Tim Bray wrote:

This, as written, has zero interoperability.=C2=A0 I think this feature = can really only be made useful in the case where scopes are fixed strings.<= u>

-T

On Apr 15, 2013 6:54 AM, "Justin Richer" &= lt;jricher@mitre.org= > wrote:

You are correct that = the idea behind the "scope" parameter at registration is a constr= aint on authorization-time scopes that are made available. It's both a = means for the client to request a set of valid scopes and for the server to provision (and echo back to th= e client) a set of valid scopes.

I *really* don't want to try to define a matching language for scope ex= pressions. For that to work, all servers would need to be able to process t= he regular expressions for all clients, even if the servers themselves only= support simple-string scope values. Any regular expression syntax we pick here is guaranteed to be incompatibl= e with something, and I think the complexity doesn't buy much. Also, I = think you suddenly have a potential security issue if you have a bad regex = in place on either end.

As it stands today, the server can interpret the incoming registration scop= es and enforce them however it wants to. The real trick comes not from assi= gning the values to a particular client but to enforcing them, and I think = that's always going to be service-specific. We're just not as clear on that as we could be.

After looking over everyone's comments so far, I'd like to propose = the following text for that section:

=C2=A0=C2=A0 scope
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 OPTIONAL.=C2=A0 Space separated list of=
 scope values (as described in
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 OAuth 2.0 Section=C2=A03.3 [RFC6749]<=
/a>) that the client can use when 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0requesting access tokens.=C2=A0 As=
 scope values are service-specific, 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0the Authorization Server MAY defin=
e its own matching rules when
=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0determining if a scope value used durin=
g an authorization request
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 is valid according to the scope values =
assigned during 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0registration. Possible matching ru=
les include wildcard patterns,
=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0regular expressions, or exactly matchin=
g the string. If omitted, 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0an Authorization Server MAY regist=
er a Client with a default 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0set of scopes.


Comments? Improvements?

=C2=A0-- Justin

On 04/14/2013 08:23 PM, Manger, James H wrote:

Presumably at app registration time any scope specification is really =
a constraint on the scope values that can be requested in an authorization =
flow.
=C2=A0
So ideally registration should accept rules for matching scopes, as op=
posed to actual scope values.
=C2=A0
You can try to use scope values as their own matching rules. That is f=
ine for a small set of "static" scopes. It starts to fail when th=
ere are a large number of scopes, or scopes that can include parameters (re=
source paths? email addresses?). You can try to patch those failures by all=
owing services to define service-specific special "wildcard" scop=
e values that can only be used during registration (eg "read:*").=

=C2=A0
Alternatively, replace 'scope' in registration with 'scope=
_regex' that holds a regular expression that all scope values in an aut=
horization flow must match.
=C2=A0
--
James Manger
_______________________________________________
OAuth mailing list
OAuth@ietf.org=

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

=C2=A0


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

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0


--089e0116058248a84004daa5adab-- From jricher@mitre.org Thu Apr 18 10:47:28 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61D3921F8F75 for ; Thu, 18 Apr 2013 10:47:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, J_CHICKENPOX_26=0.6, 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 ARSaGSTJRg7U for ; Thu, 18 Apr 2013 10:47:19 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 28F3D21F8FFC for ; Thu, 18 Apr 2013 10:47:19 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id BEBB71F062F; Thu, 18 Apr 2013 13:47:18 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 8D0191F0595; Thu, 18 Apr 2013 13:47:18 -0400 (EDT) Received: from [10.146.15.29] (129.83.31.58) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.342.3; Thu, 18 Apr 2013 13:47:18 -0400 Message-ID: <5170319A.5080903@mitre.org> Date: Thu, 18 Apr 2013 13:47:06 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Mike Jones References: <255B9BB34FB7D647A506DC292726F6E1150C74DADA@WSMSG3153V.srv.dir.telstra.com> <516C101F.2090706@mitre.org> <516C1714.8070503@mitre.org> <4E1F6AAD24975D4BA5B168042967394367641A87@TK5EX14MBXC283.redmond.corp.microsoft.com> <516C3152.9070603@mitre.org> <4E1F6AAD24975D4BA5B168042967394367641FAB@TK5EX14MBXC283.redmond.corp.microsoft.com> <516C54F2.8040708@mitre.org> <4E1F6AAD24975D4BA5B16804296739436766BCC4@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739436766C964@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739436766D8B9@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436766D8B9@TK5EX14MBXC284.redmond.corp.microsoft.com> Content-Type: multipart/alternative; boundary="------------070109070807050807030302" X-Originating-IP: [129.83.31.58] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Registration: Scope Values X-BeenThere: oauth@ietf.org X-Mailman-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, 18 Apr 2013 17:47:28 -0000 --------------070109070807050807030302 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Thing is, there's nothing normative about the enforcing statement that I made below, so I don't think it's any more restrictive than RFC 6749 which lets the AS replace a client's requested scopes at the time of token issuance with whatever it pleases. But that said, I'd be just as happy to leave it like this with no further restrictions: Space-separated list of scope values (as described in OAuth 2.0 Section 3.3 [RFC6749] ) that the Client can use when requesting access tokens from the Authorization Server. And call it a day. This parallels the text for grant_types ("Array of OAuth 2.0 grant types that the Client may use [when accessing the Token Endpoint].") and response_types ("Array of the OAuth 2.0 response types that the Client may use [when accessing the Authorization Endpoint]."), and I think this is the correct approach. I only started to add the restrictive text because I thought that people were making the argument that it was necessary -- I'd rather not have it. Plus, it's an optional field in the metadata, so if you've got structured scopes where this doesn't make sense, don't use it. If you don't do a per-client scope restriction, don't use it. The interoperability is defined in light of the interoperability of scopes themselves: this is a field to request/grant a bag of strings that only make sense in light of a given API. For that to make real sense, I think that we need to differentiate an OAuth client as a generic *library* from an OAuth client as a generic accessing *application*. It's very useful for a generic *library* that handles the authorization layer for an application to have a slot for registering scopes and finding out what scopes the app's been registered for. It's up to the app (not the library) to figure out how to translate those into scopes to ask for at authorization time. Sometimes that means just passing the string, and sometimes it means the construction of a structured value like "urn:example:channel=HBO&urn:example:rating=G,PG-13". The library doesn't care, the application does, and we should focus on interoperability from the library's perspective. Similarly, on the server side, the libraries will tell you the bag of scopes that the client was registered for, and what bag of scopes the client asked for during authorization. It's up to the server *application* to harmonize those two in a way that makes sense for the API that it's protecting. Just like it's up to the protected resource *application* to figure out what a scope means in a given context. So let's just leave it unrestricted but keep the slot for communicating this piece of information with the same semantics that the communication between the client and server take on for every other field: client asks for a thing, server says that client actually gets a thing, and it's implicitly up to the server to do the right thing and enforce things in a way that makes sense for the application no matter what the client does. To take Tony's example, client requests no scopes at registration, server grants scope "A" at registration. Client then requests scope "X" at authorization, server is free to deny the request (invalid_scope error), allow authorization because it knows how "A" and "X" are related, require user intervention, or really, whatever it likes. The libraries, where I argue the interoperability cries really matter, don't care, and shouldn't care. -- Justin On 04/18/2013 01:04 PM, Mike Jones wrote: > > Saying anything normative about "enforcing restrictions" is going > beyond RFC 6749 semantics. Indeed, you'd said that "I agree that we > shouldn't try to "solve" scope in registration.", but talking about > restrictions is going down the slippery "solving it" path. > > At most we can say that the two parties are making declarations to one > another about scopes that they may choose to use, but we can't assume > that this is an exclusive list and that other scope values such as > "urn:example:channel=HBO&urn:example:rating=G,PG-13" might not be > used, even if the client registers saying that it intends to use the > "OATC" scope value. We could maybe even say that some services may > use a static set of scopes and might choose to limit the scopes that a > client may use to those that it declared to the server or to those > that the server returned to the client. That's a HINT that some > services might do this. But we can't say anything normative about > such possible behaviors, because it goes beyond RFC 6749. > > -- Mike > > *From:*Richer, Justin P. [mailto:jricher@mitre.org] > *Sent:* Thursday, April 18, 2013 9:26 AM > *To:* Anthony Nadalin > *Cc:* Tim Bray; Mike Jones; oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Registration: Scope Values > > This doesn't actually break the semantics because the client MUST > accept what the server tells it over anything that it asks for in the > first place. The server has the final say. So in this case, if your > client asks for nothing, the server says "A B C", the client now knows > it can ask for "A B C" scopes. > > I'm still in favor of not putting the restricting language in the > scope definition at all, instead have it say something like: > > "Space-separated list of scope values (as described in OAuth 2.0 > Section 3.3 [RFC6749] > ) that the Client > can use when requesting access tokens from the Authorization > Server. As scope values are service specific, the means of the > Authorization Server enforcing this restriction are outside the > scope of this specification." > > Couple this with the overall paragraph that says that the client is > requesting values that the server is potentially overriding with its > declarations, and I think that addresses everything without getting > into confusing language that doesn't add to interoperability. > > -- Justin > > On Apr 18, 2013, at 12:13 PM, Anthony Nadalin > wrote: > > > > If I don't specify a scope, then the server can allocate a default (or > default set), thus that breaks the semantics you describe > > *From:*oauth-bounces@ietf.org > [mailto:oauth-bounces@ietf.org ]*On Behalf > Of*Tim Bray > *Sent:*Thursday, April 18, 2013 9:04 AM > *To:*Mike Jones > *Cc:*oauth@ietf.org > *Subject:*Re: [OAUTH-WG] Registration: Scope Values > > I'm unconvinced, Mike. Obviously you're right about the looseness of > OAuth2 scope specification, but this is a very specific semantic of > what happens when you register, and I don't think we're bound by > history here. If we can't safely say anything about what the list of > scopes means, then I'm with you let's take them out. But the most > obvious intended semantic is (from the client) "I promise to ask only > for these" and from the server "These are the only ones I'll give you > tokens for." Or does someone have use-cases for an alternative semantic? > > To make this concrete, I propose the following: > > "Space-separated list of scope values (as described in OAuth 2.0 > Section 3.3 [RFC6749] > ) that the client is > declaring to the server that it will restrict itself to when > requesting access tokens, and that the server is declaring to the > client that it is registered to use when requesting access tokens. > Clients SHOULD assume that servers will refuse to grant access tokens > for scopes not in the list provided by the server." > > On Thu, Apr 18, 2013 at 8:55 AM, Mike Jones > > wrote: > > I don't think it's possible to define what it means in an > interoperable way because OAuth didn't specify scopes in an > interoperable way. No, I don't like that either, but I think > that's where things are. That's why I was advocating deleting > this registration feature entirely. > > But understanding it might be useful in some contexts, I'm OK > keeping it, provided we be clear that the semantics of "registered > to use" are service-specific. > > -- Mike > > *From:*Tim Bray [mailto:twbray@google.com ] > *Sent:*Thursday, April 18, 2013 8:36 AM > *To:*Mike Jones > *Cc:*Justin Richer;oauth@ietf.org > > > *Subject:*Re: [OAUTH-WG] Registration: Scope Values > > On the server-to-client side, what does "registered to use" mean? > Does it mean that the client should assume that any scopes not on > the list WILL not be granted, MAY not be granted.... or what? Is > this already covered elsewhere? -T > > On Thu, Apr 18, 2013 at 8:28 AM, Mike Jones > > > wrote: > > Thanks, Justin. I agree with the need for the generic two-sided > language. I'd still keep this language for scope, because we want > to capture the "declaring" aspect in this case: > > "Space separated list of scope values (as described in OAuth > 2.0Section 3.3 [RFC6749] > ) that the client > is declaring to the server that it may use when requesting access > tokens and that the server is declaring to the client that it is > registered to use when requesting access tokens.". > > You should probably also reinforce that scope values are > service-specific and may not consist only of a static set of > string values, and that therefore, in some cases, an exhaustive > list of registered scope values is not possible. > > -- Mike > > *From:*Justin Richer [mailto:jricher@mitre.org > ] > *Sent:*Monday, April 15, 2013 12:29 PM > > > *To:*Mike Jones > *Cc:*Tim Bray;oauth@ietf.org > *Subject:*Re: [OAUTH-WG] Registration: Scope Values > > I think that because the "declaration" issue affects all > parameters in the list, not just scope, we should adopt this in a > higher level paragraph and leave it out of the individual > parameter descriptions. Thus, something like this inserted as the > second paragraph in section 2: > > The client metadata values serve two parallel purposes in the > overall OAuth Dynamic Registration protocol: > > - the Client requesting its desired values for each parameter to > the Authorization Server in a [register] or [update] request, > - the Authorization Server informing the Client of the current > values of each parameter that the Client has been registered to > use through a [client information response]. > > An Authorization Server MAY override any value that a Client > requests during the registration process (including any omitted > values) and replace the requested value with a default. The > normative indications in the following list apply to the Client's > declaration of its desired values. > > The Authorization Server SHOULD provide documentation for any > fields that it requires to be filled in by the client or to have > particular values or formats. Extensions and profiles... > > > And then remove the sidedness-language from the scope parameter > and any other parameters where it might have crept in inadvertently. > > -- Justin > > On 04/15/2013 01:29 PM, Mike Jones wrote: > > We could fix the one-sided language by changing > > "Space separated list of scope values (as described in OAuth > 2.0Section 3.3 [RFC6749] > ) that the > client is declaring that it may use when requesting access > tokens." > > to > > "Space separated list of scope values (as described in OAuth > 2.0Section 3.3 [RFC6749] > ) that the > client is declaring to the server that it may use when > requesting access tokens and that the server is declaring to > the client that it is registered to use when requesting access > tokens.". > > Again, I chose the "registered to use" language carefully -- > because in the general case it's not a restriction on the > values that the client can use -- just a statement by the > server to the client that it is registered to use those > particular values. In both cases, the parties are making > declarations to one another. > > If you adopt that language (or keep the original language), > then yes, I'd consider this closed. > > -- Mike > > *From:*Justin Richer [mailto:jricher@mitre.org] > *Sent:*Monday, April 15, 2013 9:57 AM > *To:*Mike Jones > *Cc:*Tim Bray;oauth@ietf.org > *Subject:*Re: [OAUTH-WG] Registration: Scope Values > > I absolutely do not want to delete this feature, as (having > implemented it) I think it's very useful. This is a very > established pattern in manual registration: I know of many, > many OAuth2 servers and clients that are set up where the > client must pre-register a set of scopes. > > I don't like the language of "the client is declaring" because > it's too one-sided. The client might not have declared > anything, and it might be the server that's declaring > something to the client. Deleting the "is declaring" bit > removes that unintended restriction of the language while > keeping the original meaning intact. I actually thought that I > had fixed that before the last draft went in but apparently I > missed this one. > > I will work on clarifying the intent of the whole metadata set > in its introductory paragraph(s) so that it's clear that all > of these fields are used in both of these situations: > > 1) The client declaring to the server its desire to use a > particular value > 2) The server declaring to the client that it has been > registered with a particular value > > This should hopefully clear up the issue in the editor's note > that I currently have at the top of that section right now, too. > > Mike, since you were the one who originally brought up the > issue, and you're fine with the existing text, can I take this > as closed now? Assuming that you agree with deleting "is > declaring" for reasons stated above, I'm fine with leaving > everything else as is and staying quiet on what the server has > to do with the scopes. > > -- Justin > > On 04/15/2013 12:44 PM, Mike Jones wrote: > > I think that the existing wording is superior to the > proposed changed wording. The existing wording is: > > scope > > OPTIONAL. Space separated list of scope values (as > described in > > OAuth 2.0Section 3.3 [RFC6749] > ) that the > client is declaring that > > it may use when requesting access tokens. If > omitted, an > > Authorization Server MAY register a Client with a > default set of > > scopes. > > For instance, the current "client is declaring" wording > will always be correct, whereas as the change to "client > can use" wording implies a restriction on client behavior > that is not always applicable. The "client is declaring" > wording was specific and purposefully chosen, and I think > should be retained. In particular, we can't do anything > that implies that only the registered scopes values can be > used. At the OAuth spec level, this is a hint as to > possible future client behavior -- not a restriction on > future client behavior. > > Also, for the reasons that Tim stated, I'm strongly > against any "matching" or "regex" language in the spec > pertaining to scopes -- as it's not actionable. > > So I'd propose that we leave the existing scope wording in > place. Alternatively, I'd also be fine with deleting this > feature entirely, as I don't think it's useful in the > general case. > > -- Mike > > *From:*oauth-bounces@ietf.org > [mailto:oauth-bounces@ietf.org]*On > Behalf Of*Justin Richer > *Sent:*Monday, April 15, 2013 8:05 AM > *To:*Tim Bray;oauth@ietf.org > *Subject:*Re: [OAUTH-WG] Registration: Scope Values > > On 04/15/2013 10:52 AM, Tim Bray wrote: > > > I'd use the existing wording; it's perfectly clear. > Failing that, if there's strong demand for registration > of structured scopes, bless the use of regexes, either > PCREs or some careful subset. > > > Thanks for the feedback -- Of these two choices, I'd > rather leave it as-is. > > > > However, I'd subtract the sentence "If omitted, an > Authorization Server MAY register a Client with a default > set of scopes." It adds no value; if the client doesn't > declare scopes, the client doesn't declare scopes, that's > all. -T > > > Remember, all of these fields aren't just for the client > *request*, they're also for the server's *response* to > either a POST, PUT, or GET request. (I didn't realize it, > but perhaps the wording as stated right now doesn't make > that clear -- I need to fix that.) The value that it adds > is if the client doesn't ask for any particular scopes, > the server can still assign it scopes and the client can > do something smart with that. Dumb clients are allowed to > ignore it if it doesn't mean anything to them. > > This is how our server implementation actually works right > now. If the client doesn't ask for anything specific at > registration, the server hands it a bag of "default" > scopes. Same thing happens at auth time -- if the client > doesn't ask for any particular scopes, the server hands it > all of its registered scopes as a default. Granted, on our > server, scopes are just simple strings right now, so they > get compared at the auth endpoint with an exact > string-match metric and set-based logic. > > -- Justin > > > > On Mon, Apr 15, 2013 at 7:35 AM, Justin Richer > > wrote: > > What would you suggest for wording here, then? Keeping in > mind that we cannot (and don't want to) prohibit > expression-based scopes. > > -- Justin > > On 04/15/2013 10:33 AM, Tim Bray wrote: > > No, I mean it's not interoperable at the > software-developer level. I can't register scopes at > authorization time with any predictable effect that I > can write code to support, either client or server > side, without out-of-line non-interoperable knowledge > about the behavior of the server. > > I guess I'm just not used to OAuth's culture of having > no expectation that things will be specified tightly > enough that I can write code to implement as > specified. -T > > On Mon, Apr 15, 2013 at 7:15 AM, Justin Richer > > wrote: > > Scopes aren't meant to be interoperable between > services since they're necessarily API-specific. The > only interoperable bit is that there's *some* place to > put the values and that it's expressed as a bag of > space-separated strings. How those strings get > interpreted and enforced (which is really what's at > stake here) is up to the AS and PR (or a higher-level > protocol like UMA). > > -- Justin > > On 04/15/2013 10:13 AM, Tim Bray wrote: > > This, as written, has zero interoperability. I > think this feature can really only be made useful > in the case where scopes are fixed strings. > > -T > > On Apr 15, 2013 6:54 AM, "Justin Richer" > > wrote: > > You are correct that the idea behind the "scope" > parameter at registration is a constraint on > authorization-time scopes that are made available. > It's both a means for the client to request a set > of valid scopes and for the server to provision > (and echo back to the client) a set of valid scopes. > > I *really* don't want to try to define a matching > language for scope expressions. For that to work, > all servers would need to be able to process the > regular expressions for all clients, even if the > servers themselves only support simple-string > scope values. Any regular expression syntax we > pick here is guaranteed to be incompatible with > something, and I think the complexity doesn't buy > much. Also, I think you suddenly have a potential > security issue if you have a bad regex in place on > either end. > > As it stands today, the server can interpret the > incoming registration scopes and enforce them > however it wants to. The real trick comes not from > assigning the values to a particular client but to > enforcing them, and I think that's always going to > be service-specific. We're just not as clear on > that as we could be. > > After looking over everyone's comments so far, I'd > like to propose the following text for that section: > > > scope > > OPTIONAL. Space separated list of scope values (as described in > > OAuth 2.0Section 3.3 [RFC6749] ) that the client can use when > > requesting access tokens. As scope values are service-specific, > > the Authorization Server MAY define its own matching rules when > > determining if a scope value used during an authorization request > > is valid according to the scope values assigned during > > registration. Possible matching rules include wildcard patterns, > > regular expressions, or exactly matching the string. If omitted, > > an Authorization Server MAY register a Client with a default > > set of scopes. > > > Comments? Improvements? > > -- Justin > > > On 04/14/2013 08:23 PM, Manger, James H wrote: > > Presumably at app registration time any scope specification is really a constraint on the scope values that can be requested in an authorization flow. > > > > So ideally registration should accept rules for matching scopes, as opposed to actual scope values. > > > > You can try to use scope values as their own matching rules. That is fine for a small set of "static" scopes. It starts to fail when there are a large number of scopes, or scopes that can include parameters (resource paths? email addresses?). You can try to patch those failures by allowing services to define service-specific special "wildcard" scope values that can only be used during registration (eg "read:*"). > > > > Alternatively, replace 'scope' in registration with 'scope_regex' that holds a regular expression that all scope values in an authorization flow must match. > > > > -- > > James Manger > > _______________________________________________ > > 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 > --------------070109070807050807030302 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Thing is, there's nothing normative about the enforcing statement that I made below, so I don't think it's any more restrictive than RFC 6749 which lets the AS replace a client's requested scopes at the time of token issuance with whatever it pleases. But that said, I'd be just as happy to leave it like this with no further restrictions:

Space-separated list of scope values (as described in OAuth 2.0 Section 3.3 [RFC6749]) that the Client can use when requesting access tokens from the Authorization Server.

And call it a day. This parallels the text for grant_types ("Array of OAuth 2.0 grant types that the Client may use [when accessing the Token Endpoint].") and response_types ("Array of the OAuth 2.0 response types that the Client may use [when accessing the Authorization Endpoint]."), and I think this is the correct approach. I only started to add the restrictive text because I thought that people were making the argument that it was necessary -- I'd rather not have it.

    Plus, it's an optional field in the metadata, so if you've got
    structured scopes where this doesn't make sense, don't use it. If
    you don't do a per-client scope restriction, don't use it. 

    

    The interoperability is defined in light of the interoperability of
    scopes themselves: this is a field to request/grant a bag of strings
    that only make sense in light of a given API. For that to make real
    sense, I think that we need to differentiate an OAuth client as a
    generic *library* from an OAuth client as a generic accessing
    *application*. It's very useful for a generic *library* that handles
    the authorization layer for an application to have a slot for
    registering scopes and finding out what scopes the app's been
    registered for. It's up to the app (not the library) to figure out
    how to translate those into scopes to ask for at authorization time.
    Sometimes that means just passing the string, and sometimes it means
    the construction of a structured value like "urn:example:channel=HBO&urn:example:rating=G,PG-13".
      The library doesn't care, the application does, and we should
      focus on interoperability from the library's perspective.
      Similarly, on the server side, the libraries will tell you
    the bag of scopes that the client was registered for, and what bag
    of scopes the client asked for during authorization. It's up to the
    server *application* to harmonize those two in a way that makes
    sense for the API that it's protecting. Just like it's up to the
    protected resource *application* to figure out what a scope means in
    a given context.

    

    So let's just leave it unrestricted but keep the slot for
    communicating this piece of information with the same semantics that
    the communication between the client and server take on for every
    other field: client asks for a thing, server says that client
    actually gets a thing, and it's implicitly up to the server to do
    the right thing and enforce things in a way that makes sense for the
    application no matter what the client does. 

    

    To take Tony's example, client requests no scopes at registration,
    server grants scope "A" at registration. Client then requests scope
    "X" at authorization, server is free to deny the request
    (invalid_scope error), allow authorization because it knows how "A"
    and "X" are related, require user intervention, or really, whatever
    it likes. The libraries, where I argue the interoperability cries
    really matter, don't care, and shouldn't care.

    

     -- Justin

    

    
On 04/18/2013 01:04 PM, Mike Jones
      wrote:

    

    

      
      
      
      

        
Saying
            anything normative about “enforcing restrictions” is going
            beyond RFC 6749 semantics.  Indeed, you’d said that “I
          agree that we shouldn't try to "solve" scope in registration.”,
            but talking about restrictions is going down the slippery
            “solving it” path.

        
 

        
At
            most we can say that the two parties are making declarations
            to one another about scopes that they may choose to use, but
            we can’t assume that this is an exclusive list and that
            other scope values such as “urn:example:channel=HBO&urn:example:rating=G,PG-13”
            might not be used, even if the client registers saying that
            it intends to use the “OATC” scope value.  We could maybe
            even say that some services may use a static set of scopes
            and might choose to limit the scopes that a client may use
            to those that it declared to the server or to those that the
            server returned to the client.  That’s a HINT that some
            services might do this.  But we can’t say anything normative
            about such possible behaviors, because it goes beyond RFC
            6749.

        
 

        
                                                           
            -- Mike

        
 

        

          

            
From:
                Richer, Justin P. [mailto:jricher@mitre.org]
                

                Sent: Thursday, April 18, 2013 9:26 AM

                To: Anthony Nadalin

                Cc: Tim Bray; Mike Jones; oauth@ietf.org

                Subject: Re: [OAUTH-WG] Registration: Scope
                Values

          

        

        
 

        

          
This doesn't actually break the semantics
            because the client MUST accept what the server tells it over
            anything that it asks for in the first place. The server has
            the final say. So in this case, if your client asks for
            nothing, the server says "A B C", the client now knows it
            can ask for "A B C" scopes. 

        

        

          
 

        

        

          
I'm still in favor of not putting the
            restricting language in the scope definition at all, instead
            have it say something like:

        

        

          
 

        

        

          

            

              

                
“Space-separated list of scope
                    values (as described in OAuth 2.0 Section 3.3

                        [RFC6749]) that the Client can use
                    when requesting access tokens from the Authorization
                    Server. As scope values are service specific, the
                    means of the Authorization Server enforcing this
                    restriction are outside the scope of this
                    specification.”

              

            

          

          
 

        

        

          
Couple this with the overall paragraph
            that says that the client is requesting values that the
            server is potentially overriding with its declarations, and
            I think that addresses everything without getting into
            confusing language that doesn't add to interoperability. 

        

        

          
 

        

        

          
 -- Justin

        

        

          
 

          

            

              
On Apr 18, 2013, at 12:13 PM, Anthony
                Nadalin <tonynad@microsoft.com>
                wrote:

            

            


              

              

            

              

                
If
                    I don’t specify a scope, then the server can
                    allocate a default (or default set), thus that
                    breaks the semantics you describe

              

              

                
 

              

              

                
From: oauth-bounces@ietf.org
                    [mailto:oauth-bounces@ietf.org] On Behalf
                      Of Tim
                    Bray

                    Sent: Thursday,
                    April 18, 2013 9:04 AM

                    To: Mike
                    Jones

                    Cc: oauth@ietf.org

                    Subject: Re:
                    [OAUTH-WG] Registration: Scope Values

              

              

                
 

              

              

                

                  
I’m unconvinced, Mike.  Obviously
                    you’re right about the looseness of OAuth2 scope
                    specification, but this is a very specific semantic
                    of what happens when you register, and I don’t think
                    we’re bound by history here.   If we can’t safely
                    say anything about what the list of scopes means,
                    then I'm with you let's take them out.  But the most
                    obvious intended semantic is (from the client) “I
                    promise to ask only for these” and from the server
                    “These are the only ones I’ll give you tokens for.”
                     Or does someone have use-cases for an alternative
                    semantic?

                

                

                  

                    
 

                  

                

                

                  

                    
To make this concrete, I
                      propose the following:

                  

                

                

                  

                    
“Space-separated list of
                        scope values (as described in OAuth 2.0 Section 3.3

                            [RFC6749]) that the client is
                        declaring to the server that it will restrict
                        itself to when requesting access tokens, and
                        that the server is declaring to the client that
                        it is registered to use when requesting access
                        tokens.  Clients SHOULD assume that servers
                        will refuse to grant access tokens for scopes
                        not in the list provided by the server.”

                  

                  

                    

                      
 

                    

                  

                

              

              

                
 

                

                  

                    
On Thu, Apr 18, 2013 at 8:55
                      AM, Mike Jones <Michael.Jones@microsoft.com>
                      wrote:

                  

                  

                    

                      
I
                          don’t think it’s possible to define what it
                          means in an interoperable way because OAuth
                          didn’t specify scopes in an interoperable
                          way.  No, I don’t like that either, but I
                          think that’s where things are.  That’s why I
                          was advocating deleting this registration
                          feature entirely.

                    

                    

                      
 

                    

                    

                      
But
                          understanding it might be useful in some
                          contexts, I’m OK keeping it, provided we be
                          clear that the semantics of “registered to
                          use” are service-specific.

                    

                    

                      
 

                    

                    

                      
                                                           
                          -- Mike

                    

                    

                      
 

                    

                    

                      
From: Tim

                          Bray [mailto:twbray@google.com] 

                          Sent: Thursday,
                          April 18, 2013 8:36 AM

                          To: Mike
                          Jones

                          Cc: Justin
                          Richer; oauth@ietf.org

                    

                    

                      

                        


                          Subject: Re:
                          [OAUTH-WG] Registration: Scope Values

                      

                    

                    

                      

                        
 

                      

                      

                        

                          
On the server-to-client
                            side, what does “registered to use” mean?
                             Does it mean that the client should assume
                            that any scopes not on the list WILL not be
                            granted, MAY not be granted.... or what?  Is
                            this already covered elsewhere? -T

                        

                      

                      

                        
 

                        

                          

                            
On Thu, Apr 18, 2013 at
                              8:28 AM, Mike Jones <Michael.Jones@microsoft.com>
                              wrote:

                          

                          

                            

                              
Thanks,
                                  Justin.  I agree with the need for the
                                  generic two-sided language.  I’d still
                                  keep this language for scope, because
                                  we want to capture the “declaring”
                                  aspect in this case:

                            

                            

                              

                                
 

                              

                              

                                
“Space separated
                                    list of scope values (as described
                                    in OAuth 2.0 Section 3.3
                                        [RFC6749]) that the
                                    client is declaring to the server
                                    that it may use when requesting
                                    access tokens and that the server is
                                    declaring to the client that it is
                                    registered to use when requesting
                                    access tokens.”.

                              

                              

                                
 

                              

                            

                            

                              
You
                                  should probably also reinforce that
                                  scope values are service-specific and
                                  may not consist only of a static set
                                  of string values, and that therefore,
                                  in some cases, an exhaustive list of
                                  registered scope values is not
                                  possible.

                            

                            

                              
 

                            

                            

                              
                                                           
                                  -- Mike

                            

                            

                              
 

                            

                            

                              

                                

                                  
From: Justin

                                      Richer [mailto:jricher@mitre.org] 

                                      Sent: Monday,
                                      April 15, 2013 12:29 PM

                                

                                

                                  

                                    


                                      To: Mike
                                      Jones

                                      Cc: Tim
                                      Bray; oauth@ietf.org

                                      Subject: Re:
                                      [OAUTH-WG] Registration: Scope
                                      Values

                                  

                                

                              

                            

                            

                              

                                
 

                              

                              
I think
                                that because the "declaration" issue
                                affects all parameters in the list, not
                                just scope, we should adopt this in a
                                higher level paragraph and leave it out
                                of the individual parameter
                                descriptions. Thus, something like this
                                inserted as the second paragraph in
                                section 2:

                              

                                
The client metadata
                                  values serve two parallel purposes in
                                  the overall OAuth Dynamic Registration
                                  protocol: 

                                  

                                   - the Client requesting its desired
                                  values for each parameter to the
                                  Authorization Server in a [register]
                                  or [update] request,

                                   - the Authorization Server informing
                                  the Client of the current values of
                                  each parameter that the Client has
                                  been registered to use through a
                                  [client information response]. 

                                  

                                  An Authorization Server MAY override
                                  any value that a Client requests
                                  during the registration process
                                  (including any omitted values) and
                                  replace the requested value with a
                                  default. The normative indications in
                                  the following list apply to the
                                  Client's declaration of its desired
                                  values. 

                                  

                                  The Authorization Server SHOULD
                                  provide documentation for any fields
                                  that it requires to be filled in by
                                  the client or to have particular
                                  values or formats. Extensions and
                                  profiles...

                              

                              


                                And then remove the sidedness-language
                                from the scope parameter and any other
                                parameters where it might have crept in
                                inadvertently. 

                                

                                 -- Justin

                              

                                

                                  
On 04/15/2013
                                    01:29 PM, Mike Jones wrote:

                                

                              

                              

                                

                                  
We
                                      could fix the one-sided language
                                      by changing

                                

                                

                                  
“Space
                                      separated list of scope values (as
                                      described in OAuth 2.0 Section 3.3

                                          [RFC6749]) that the
                                      client is declaring that it may
                                      use when requesting access tokens.”

                                

                                

                                  
to

                                

                                

                                  
“Space
                                      separated list of scope values (as
                                      described in OAuth 2.0 Section 3.3

                                          [RFC6749]) that the
                                      client is declaring to the server
                                      that it may use when requesting
                                      access tokens and that the server
                                      is declaring to the client that it
                                      is registered to use when
                                      requesting access tokens.”.

                                

                                

                                  
 

                                

                                

                                  
Again,
                                      I chose the “registered to use”
                                      language carefully – because in
                                      the general case it’s not a
                                      restriction on the values that the
                                      client can use – just a statement
                                      by the server to the client that
                                      it is registered to use those
                                      particular values.  In both cases,
                                      the parties are making
                                      declarations to one another.

                                

                                

                                  
 

                                

                                

                                  
If
                                      you adopt that language (or keep
                                      the original language), then yes,
                                      I’d consider this closed.

                                

                                

                                  
 

                                

                                

                                  
                                                           
                                      -- Mike

                                

                                

                                  
 

                                

                                

                                  

                                    

                                      
From: Justin

                                          Richer [mailto:jricher@mitre.org] 

                                          Sent: Monday,
                                          April 15, 2013 9:57 AM

                                          To: Mike
                                          Jones

                                          Cc: Tim
                                          Bray; oauth@ietf.org

                                          Subject: Re:
                                          [OAUTH-WG] Registration: Scope
                                          Values

                                    

                                  

                                

                                

                                  
 

                                

                                
I
                                  absolutely do not want to delete this
                                  feature, as (having implemented it) I
                                  think it's very useful. This is a very
                                  established pattern in manual
                                  registration: I know of many, many
                                  OAuth2 servers and clients that are
                                  set up where the client must
                                  pre-register a set of scopes. 

                                  

                                  I don't like the language of "the
                                  client is declaring" because it's too
                                  one-sided. The client might not have
                                  declared anything, and it might be the
                                  server that's declaring something to
                                  the client. Deleting the "is
                                  declaring" bit removes that unintended
                                  restriction of the language while
                                  keeping the original meaning intact. I
                                  actually thought that I had fixed that
                                  before the last draft went in but
                                  apparently I missed this one.

                                  

                                  I will work on clarifying the intent
                                  of the whole metadata set in its
                                  introductory paragraph(s) so that it's
                                  clear that all of these fields are
                                  used in both of these situations:

                                  

                                   1) The client declaring to the server
                                  its desire to use a particular value

                                   2) The server declaring to the client
                                  that it has been registered with a
                                  particular value

                                  

                                  This should hopefully clear up the
                                  issue in the editor's note that I
                                  currently have at the top of that
                                  section right now, too.

                                  

                                  Mike, since you were the one who
                                  originally brought up the issue, and
                                  you're fine with the existing text,
                                  can I take this as closed now?
                                  Assuming that you agree with deleting
                                  "is declaring" for reasons stated
                                  above, I'm fine with leaving
                                  everything else as is and staying
                                  quiet on what the server has to do
                                  with the scopes.

                                  

                                   -- Justin

                                

                                  

                                    
On 04/15/2013
                                      12:44 PM, Mike Jones wrote:

                                  

                                

                                

                                  

                                    
I
                                        think that the existing wording
                                        is superior to the proposed
                                        changed wording.  The existing
                                        wording is:

                                  

                                  

                                    
 

                                  

                                  

                                    
   scope

                                  

                                  

                                    
      OPTIONAL.  Space
                                        separated list of scope values
                                        (as described in

                                  

                                  

                                    
      OAuth 2.0 Section 3.3

                                            [RFC6749]) that
                                        the client is declaring that

                                  

                                  

                                    
      it may use when
                                        requesting access tokens.  If
                                        omitted, an

                                  

                                  

                                    
      Authorization
                                        Server MAY register a Client
                                        with a default set of

                                  

                                  

                                    
      scopes.

                                  

                                  

                                    
 

                                  

                                  

                                    
For
                                        instance, the current “client is
                                        declaring” wording will always
                                        be correct, whereas as the
                                        change to “client can use”
                                        wording implies a restriction on
                                        client behavior that is not
                                        always applicable.  The “client
                                        is declaring” wording was
                                        specific and purposefully
                                        chosen, and I think should be
                                        retained.  In particular, we
                                        can’t do anything that implies
                                        that only the registered scopes
                                        values can be used.  At the
                                        OAuth spec level, this is a hint
                                        as to possible future client
                                        behavior – not a restriction on
                                        future client behavior.

                                  

                                  

                                    
 

                                  

                                  

                                    
Also,
                                        for the reasons that Tim stated,
                                        I’m strongly against any
                                        “matching” or “regex” language
                                        in the spec pertaining to scopes
                                        – as it’s not actionable.

                                  

                                  

                                    
 

                                  

                                  

                                    
So
                                        I’d propose that we leave the
                                        existing scope wording in
                                        place.  Alternatively, I’d also
                                        be fine with deleting this
                                        feature entirely, as I don’t
                                        think it’s useful in the general
                                        case.

                                  

                                  

                                    
 

                                  

                                  

                                    
                                                           
                                        -- Mike

                                  

                                  

                                    
 

                                  

                                  

                                    

                                      

                                        
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]On

                                              Behalf Of Justin
                                            Richer

                                            Sent: Monday,
                                            April 15, 2013 8:05 AM

                                            To: Tim
                                            Bray; oauth@ietf.org

                                            Subject: Re:
                                            [OAUTH-WG] Registration:
                                            Scope Values

                                      

                                    

                                  

                                  

                                    
 

                                  

                                  
On
                                    04/15/2013 10:52 AM, Tim Bray wrote:

                                    

                                    

                                    

                                  

                                    

                                      
I’d use the
                                        existing wording; it’s perfectly
                                        clear.  Failing that, if there’s
                                        strong demand for registration
                                        of structured scopes, bless the
                                        use of regexes, either PCREs or
                                        some careful subset.

                                    

                                  

                                  


                                    Thanks for the feedback -- Of these
                                    two choices, I'd rather leave it
                                    as-is. 

                                    

                                    

                                    

                                    

                                  

                                    

                                      

                                        
 

                                      

                                    

                                    

                                      

                                        
However,
                                          I’d subtract the sentence “If
                                          omitted, an Authorization
                                          Server MAY register a Client
                                          with a default set of
                                           scopes.”  It adds no value;
                                          if the client doesn’t declare
                                          scopes, the client doesn’t
                                          declare scopes, that’s all.
                                           -T

                                      

                                    

                                  

                                  


                                    Remember, all of these fields aren't
                                    just for the client *request*,
                                    they're also for the server's
                                    *response* to either a POST, PUT, or
                                    GET request. (I didn't realize it,
                                    but perhaps the wording as stated
                                    right now doesn't make that clear --
                                    I need to fix that.) The value that
                                    it adds is if the client doesn't ask
                                    for any particular scopes, the
                                    server can still assign it scopes
                                    and the client can do something
                                    smart with that. Dumb clients are
                                    allowed to ignore it if it doesn't
                                    mean anything to them. 

                                    

                                    This is how our server
                                    implementation actually works right
                                    now. If the client doesn't ask for
                                    anything specific at registration,
                                    the server hands it a bag of
                                    "default" scopes. Same thing happens
                                    at auth time -- if the client
                                    doesn't ask for any particular
                                    scopes, the server hands it all of
                                    its registered scopes as a default.
                                    Granted, on our server, scopes are
                                    just simple strings right now, so
                                    they get compared at the auth
                                    endpoint with an exact string-match
                                    metric and set-based logic. 

                                    

                                     -- Justin

                                    

                                    

                                    

                                    

                                  

                                    
 

                                    

                                      

                                        
On Mon, Apr
                                          15, 2013 at 7:35 AM, Justin
                                          Richer <jricher@mitre.org>
                                          wrote:

                                      

                                      

                                        

                                          
What
                                            would you suggest for
                                            wording here, then? Keeping
                                            in mind that we cannot (and
                                            don't want to) prohibit
                                            expression-based scopes. 

                                            

                                               -- Justin

                                        

                                        

                                          
 

                                          

                                            

                                              
On
                                                04/15/2013 10:33 AM, Tim
                                                Bray wrote:

                                            

                                          

                                          

                                            

                                              

                                                
No,
                                                  I mean it’s not
                                                  interoperable at the
                                                  software-developer
                                                  level.  I can’t
                                                  register scopes at
                                                  authorization time
                                                  with any predictable
                                                  effect that I can
                                                  write code to support,
                                                  either client or
                                                  server side, without
                                                  out-of-line
                                                  non-interoperable
                                                  knowledge about the
                                                  behavior of the
                                                  server.  

                                              

                                              

                                                

                                                  
 

                                                

                                              

                                              

                                                

                                                  
I
                                                    guess I’m just not
                                                    used to OAuth’s
                                                    culture of having no
                                                    expectation that
                                                    things will be
                                                    specified tightly
                                                    enough that I can
                                                    write code to
                                                    implement as
                                                    specified.  -T

                                                

                                              

                                            

                                            

                                              
 

                                              

                                                

                                                  
On
                                                    Mon, Apr 15, 2013 at
                                                    7:15 AM, Justin
                                                    Richer <jricher@mitre.org>
                                                    wrote:

                                                

                                                

                                                  

                                                    
Scopes
                                                      aren't meant to be
                                                      interoperable
                                                      between services
                                                      since they're
                                                      necessarily
                                                      API-specific. The
                                                      only interoperable
                                                      bit is that
                                                      there's *some*
                                                      place to put the
                                                      values and that
                                                      it's expressed as
                                                      a bag of
                                                      space-separated
                                                      strings. How those
                                                      strings get
                                                      interpreted and
                                                      enforced (which is
                                                      really what's at
                                                      stake here) is up
                                                      to the AS and PR
                                                      (or a higher-level
                                                      protocol like
                                                      UMA).

                                                        

                                                         -- Justin

                                                  

                                                  

                                                    
 

                                                    

                                                      

                                                        
On
                                                          04/15/2013
                                                          10:13 AM, Tim
                                                          Bray wrote:

                                                      

                                                    

                                                    

                                                      
This, as
                                                        written, has
                                                        zero
                                                        interoperability. 
                                                        I think this
                                                        feature can
                                                        really only be
                                                        made useful in
                                                        the case where
                                                        scopes are fixed
                                                        strings.

                                                      
-T

                                                      

                                                        

                                                          
On
                                                          Apr 15, 2013
                                                          6:54 AM,
                                                          "Justin
                                                          Richer" <jricher@mitre.org> wrote:

                                                        

                                                        

                                                          
You are correct that the idea behind the
                                                          "scope"
                                                          parameter at
                                                          registration
                                                          is a
                                                          constraint on
                                                          authorization-time
                                                          scopes that
                                                          are made
                                                          available.
                                                          It's both a
                                                          means for the
                                                          client to
                                                          request a set
                                                          of valid
                                                          scopes and for
                                                          the server to
                                                          provision (and
                                                          echo back to
                                                          the client) a
                                                          set of valid
                                                          scopes.

                                                          

                                                          I *really*
                                                          don't want to
                                                          try to define
                                                          a matching
                                                          language for
                                                          scope
                                                          expressions.
                                                          For that to
                                                          work, all
                                                          servers would
                                                          need to be
                                                          able to
                                                          process the
                                                          regular
                                                          expressions
                                                          for all
                                                          clients, even
                                                          if the servers
                                                          themselves
                                                          only support
                                                          simple-string
                                                          scope values.
                                                          Any regular
                                                          expression
                                                          syntax we pick
                                                          here is
                                                          guaranteed to
                                                          be
                                                          incompatible
                                                          with
                                                          something, and
                                                          I think the
                                                          complexity
                                                          doesn't buy
                                                          much. Also, I
                                                          think you
                                                          suddenly have
                                                          a potential
                                                          security issue
                                                          if you have a
                                                          bad regex in
                                                          place on
                                                          either end. 

                                                          

                                                          As it stands
                                                          today, the
                                                          server can
                                                          interpret the
                                                          incoming
                                                          registration
                                                          scopes and
                                                          enforce them
                                                          however it
                                                          wants to. The
                                                          real trick
                                                          comes not from
                                                          assigning the
                                                          values to a
                                                          particular
                                                          client but to
                                                          enforcing
                                                          them, and I
                                                          think that's
                                                          always going
                                                          to be
                                                          service-specific.
                                                          We're just not
                                                          as clear on
                                                          that as we
                                                          could be.

                                                          

                                                          After looking
                                                          over
                                                          everyone's
                                                          comments so
                                                          far, I'd like
                                                          to propose the
                                                          following text
                                                          for that
                                                          section:

                                                          

                                                          

                                                          

                                                          
   scope

                                                          
      OPTIONAL.  Space separated list of scope values (as described in

                                                          
      OAuth 2.0 Section 3.3 [RFC6749]) that the client can use when 

                                                          
      requesting access tokens.  As scope values are service-specific, 

                                                          
      the Authorization Server MAY define its own matching rules when

                                                          
      determining if a scope value used during an authorization request

                                                          
      is valid according to the scope values assigned during 

                                                          
      registration. Possible matching rules include wildcard patterns,

                                                          
      regular expressions, or exactly matching the string. If omitted, 

                                                          
      an Authorization Server MAY register a Client with a default 

                                                          
      set of scopes.

                                                          


                                                          Comments?
                                                          Improvements?

                                                          

                                                           -- Justin

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
On
                                                          04/14/2013
                                                          08:23 PM,
                                                          Manger, James
                                                          H wrote:

                                                          

                                                          

                                                          

                                                          
Presumably at app registration time any scope specification is really a constraint on the scope values that can be requested in an authorization flow.

                                                          
 

                                                          
So ideally registration should accept rules for matching scopes, as opposed to actual scope values.

                                                          
 

                                                          
You can try to use scope values as their own matching rules. That is fine for a small set of "static" scopes. It starts to fail when there are a large number of scopes, or scopes that can include parameters (resource paths? email addresses?). You can try to patch those failures by allowing services to define service-specific special "wildcard" scope values that can only be used during registration (eg "read:*").

                                                          
 

                                                          
Alternatively, replace 'scope' in registration with 'scope_regex' that holds a regular expression that all scope values in an authorization flow must match.

                                                          
 

                                                          
--

                                                          
James Manger

                                                          
_______________________________________________

                                                          
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

            

          

          
 

        

      

    

    

  


--------------070109070807050807030302--

From Michael.Jones@microsoft.com  Thu Apr 18 10:53:39 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12C3821F86E8 for ; Thu, 18 Apr 2013 10:53:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.534
X-Spam-Level: 
X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.064,  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 U8q8ECDd1iGq for ; Thu, 18 Apr 2013 10:53:24 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0244.outbound.protection.outlook.com [207.46.163.244]) by ietfa.amsl.com (Postfix) with ESMTP id 982A821F86D3 for ; Thu, 18 Apr 2013 10:53:18 -0700 (PDT)
Received: from BN1AFFO11FD003.protection.gbl (10.58.52.202) by BN1AFFO11HUB017.protection.gbl (10.58.52.127) with Microsoft SMTP Server (TLS) id 15.0.675.0; Thu, 18 Apr 2013 17:53:15 +0000
Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.37) by BN1AFFO11FD003.mail.protection.outlook.com (10.58.52.63) with Microsoft SMTP Server (TLS) id 15.0.675.0 via Frontend Transport; Thu, 18 Apr 2013 17:53:14 +0000
Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.245]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.02.0318.003; Thu, 18 Apr 2013 17:52:46 +0000
From: Mike Jones 
To: Justin Richer 
Thread-Topic: [OAUTH-WG] Registration: Scope Values
Thread-Index: AQHOOeqUFpSaFgMeSEqfp5thtJ9Xm5jXeeUggAAGtwCAAAX9QIAAJHsAgARy+OCAAAL+AIAABHrwgAADR4CAAALDAIAAA2eAgAAI58CAAA3KAIAAAM7g
Date: Thu, 18 Apr 2013 17:52:45 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739436766EDB1@TK5EX14MBXC284.redmond.corp.microsoft.com>
References: <255B9BB34FB7D647A506DC292726F6E1150C74DADA@WSMSG3153V.srv.dir.telstra.com> <516C101F.2090706@mitre.org>  <516C1714.8070503@mitre.org> <4E1F6AAD24975D4BA5B168042967394367641A87@TK5EX14MBXC283.redmond.corp.microsoft.com> <516C3152.9070603@mitre.org> <4E1F6AAD24975D4BA5B168042967394367641FAB@TK5EX14MBXC283.redmond.corp.microsoft.com> <516C54F2.8040708@mitre.org> <4E1F6AAD24975D4BA5B16804296739436766BCC4@TK5EX14MBXC284.redmond.corp.microsoft.com>  <4E1F6AAD24975D4BA5B16804296739436766C964@TK5EX14MBXC284.redmond.corp.microsoft.com>    <4E1F6AAD24975D4BA5B16804296739436766D8B9@TK5EX14MBXC284.redmond.corp.microsoft.com> <5170319A.5080903@mitre.org>
In-Reply-To: <5170319A.5080903@mitre.org>
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_4E1F6AAD24975D4BA5B16804296739436766EDB1TK5EX14MBXC284r_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(55885003)(51444002)(164054002)(51914002)(35774002)(479174001)(24454001)(65554002)(377454001)(49866001)(59766001)(47976001)(79102001)(69226001)(46102001)(54356001)(66066001)(47736001)(63696002)(15202345002)(71186001)(81342001)(20776003)(564824004)(56816002)(77982001)(55846006)(51856001)(16406001)(53806001)(47446002)(74502001)(31966008)(74662001)(33656001)(512954001)(6806003)(54316002)(16236675002)(50986001)(81542001)(80022001)(65816001)(76482001)(56776001)(4396001); DIR:OUT; SFP:; SCL:1; SRVR:BN1AFFO11HUB017; H:TK5EX14HUBC105.redmond.corp.microsoft.com; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 08200063E9
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: Scope Values
X-BeenThere: oauth@ietf.org
X-Mailman-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, 18 Apr 2013 17:53:39 -0000

--_000_4E1F6AAD24975D4BA5B16804296739436766EDB1TK5EX14MBXC284r_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I could live with it if you expanded the text slightly as follows.  Otherwi=
se people will keep asking questions that they deserve an answer to, even i=
f the answer is "see the service documentation".

Space-separated list of scope values (as described in OAuth 2.0 Section 3.3=
 [RFC6749]) that the Client=
 can use when requesting access tokens from the Authorization Server.  The =
semantics of this list are service specific.

                                                                -- Mike


From: Justin Richer [mailto:jricher@mitre.org]
Sent: Thursday, April 18, 2013 10:47 AM
To: Mike Jones
Cc: Anthony Nadalin; Tim Bray; oauth@ietf.org
Subject: Re: [OAUTH-WG] Registration: Scope Values

Thing is, there's nothing normative about the enforcing statement that I ma=
de below, so I don't think it's any more restrictive than RFC 6749 which le=
ts the AS replace a client's requested scopes at the time of token issuance=
 with whatever it pleases. But that said, I'd be just as happy to leave it =
like this with no further restrictions:

Space-separated list of scope values (as described in OAuth 2.0 Section 3.3=
 [RFC6749]) that the Client=
 can use when requesting access tokens from the Authorization Server.

And call it a day. This parallels the text for grant_types ("Array of OAuth=
 2.0 grant types that the Client may use [when accessing the Token Endpoint=
].") and response_types ("Array of the OAuth 2.0 response types that the Cl=
ient may use [when accessing the Authorization Endpoint]."), and I think th=
is is the correct approach. I only started to add the restrictive text beca=
use I thought that people were making the argument that it was necessary --=
 I'd rather not have it.


Plus, it's an optional field in the metadata, so if you've got structured s=
copes where this doesn't make sense, don't use it. If you don't do a per-cl=
ient scope restriction, don't use it.

The interoperability is defined in light of the interoperability of scopes =
themselves: this is a field to request/grant a bag of strings that only mak=
e sense in light of a given API. For that to make real sense, I think that =
we need to differentiate an OAuth client as a generic *library* from an OAu=
th client as a generic accessing *application*. It's very useful for a gene=
ric *library* that handles the authorization layer for an application to ha=
ve a slot for registering scopes and finding out what scopes the app's been=
 registered for. It's up to the app (not the library) to figure out how to =
translate those into scopes to ask for at authorization time. Sometimes tha=
t means just passing the string, and sometimes it means the construction of=
 a structured value like "urn:example:channel=3DHBO&urn:example:rating=3DG,=
PG-13". The library doesn't care, the application does, and we should focus=
 on interoperability from the library's perspective. Similarly, on the serv=
er side, the libraries will tell you the bag of scopes that the client was =
registered for, and what bag of scopes the client asked for during authoriz=
ation. It's up to the server *application* to harmonize those two in a way =
that makes sense for the API that it's protecting. Just like it's up to the=
 protected resource *application* to figure out what a scope means in a giv=
en context.

So let's just leave it unrestricted but keep the slot for communicating thi=
s piece of information with the same semantics that the communication betwe=
en the client and server take on for every other field: client asks for a t=
hing, server says that client actually gets a thing, and it's implicitly up=
 to the server to do the right thing and enforce things in a way that makes=
 sense for the application no matter what the client does.

To take Tony's example, client requests no scopes at registration, server g=
rants scope "A" at registration. Client then requests scope "X" at authoriz=
ation, server is free to deny the request (invalid_scope error), allow auth=
orization because it knows how "A" and "X" are related, require user interv=
ention, or really, whatever it likes. The libraries, where I argue the inte=
roperability cries really matter, don't care, and shouldn't care.

 -- Justin
On 04/18/2013 01:04 PM, Mike Jones wrote:
Saying anything normative about "enforcing restrictions" is going beyond RF=
C 6749 semantics.  Indeed, you'd said that "I agree that we shouldn't try t=
o "solve" scope in registration.", but talking about restrictions is going =
down the slippery "solving it" path.

At most we can say that the two parties are making declarations to one anot=
her about scopes that they may choose to use, but we can't assume that this=
 is an exclusive list and that other scope values such as "urn:example:chan=
nel=3DHBO&urn:example:rating=3DG,PG-13" might not be used, even if the clie=
nt registers saying that it intends to use the "OATC" scope value.  We coul=
d maybe even say that some services may use a static set of scopes and migh=
t choose to limit the scopes that a client may use to those that it declare=
d to the server or to those that the server returned to the client.  That's=
 a HINT that some services might do this.  But we can't say anything normat=
ive about such possible behaviors, because it goes beyond RFC 6749.

                                                            -- Mike

From: Richer, Justin P. [mailto:jricher@mitre.org]
Sent: Thursday, April 18, 2013 9:26 AM
To: Anthony Nadalin
Cc: Tim Bray; Mike Jones; oauth@ietf.org
Subject: Re: [OAUTH-WG] Registration: Scope Values

This doesn't actually break the semantics because the client MUST accept wh=
at the server tells it over anything that it asks for in the first place. T=
he server has the final say. So in this case, if your client asks for nothi=
ng, the server says "A B C", the client now knows it can ask for "A B C" sc=
opes.

I'm still in favor of not putting the restricting language in the scope def=
inition at all, instead have it say something like:

"Space-separated list of scope values (as described in OAuth 2.0 Section 3.=
3 [RFC6749]) that the Clien=
t can use when requesting access tokens from the Authorization Server. As s=
cope values are service specific, the means of the Authorization Server enf=
orcing this restriction are outside the scope of this specification."

Couple this with the overall paragraph that says that the client is request=
ing values that the server is potentially overriding with its declarations,=
 and I think that addresses everything without getting into confusing langu=
age that doesn't add to interoperability.

 -- Justin

On Apr 18, 2013, at 12:13 PM, Anthony Nadalin > wrote:



If I don't specify a scope, then the server can allocate a default (or defa=
ult set), thus that breaks the semantics you describe

From: oauth-bounces@ietf.org [mailto:oauth-b=
ounces@ietf.org] On Behalf Of Tim Bray
Sent: Thursday, April 18, 2013 9:04 AM
To: Mike Jones
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Registration: Scope Values

I'm unconvinced, Mike.  Obviously you're right about the looseness of OAuth=
2 scope specification, but this is a very specific semantic of what happens=
 when you register, and I don't think we're bound by history here.   If we =
can't safely say anything about what the list of scopes means, then I'm wit=
h you let's take them out.  But the most obvious intended semantic is (from=
 the client) "I promise to ask only for these" and from the server "These a=
re the only ones I'll give you tokens for."  Or does someone have use-cases=
 for an alternative semantic?

To make this concrete, I propose the following:
"Space-separated list of scope values (as described in OAuth 2.0 Section 3.=
3 [RFC6749]) that the clien=
t is declaring to the server that it will restrict itself to when requestin=
g access tokens, and that the server is declaring to the client that it is =
registered to use when requesting access tokens.  Clients SHOULD assume tha=
t servers will refuse to grant access tokens for scopes not in the list pro=
vided by the server."


On Thu, Apr 18, 2013 at 8:55 AM, Mike Jones > wrote:
I don't think it's possible to define what it means in an interoperable way=
 because OAuth didn't specify scopes in an interoperable way.  No, I don't =
like that either, but I think that's where things are.  That's why I was ad=
vocating deleting this registration feature entirely.

But understanding it might be useful in some contexts, I'm OK keeping it, p=
rovided we be clear that the semantics of "registered to use" are service-s=
pecific.

                                                            -- Mike

From: Tim Bray [mailto:twbray@google.com]
Sent: Thursday, April 18, 2013 8:36 AM
To: Mike Jones
Cc: Justin Richer; oauth@ietf.org

Subject: Re: [OAUTH-WG] Registration: Scope Values

On the server-to-client side, what does "registered to use" mean?  Does it =
mean that the client should assume that any scopes not on the list WILL not=
 be granted, MAY not be granted.... or what?  Is this already covered elsew=
here? -T

On Thu, Apr 18, 2013 at 8:28 AM, Mike Jones > wrote:
Thanks, Justin.  I agree with the need for the generic two-sided language. =
 I'd still keep this language for scope, because we want to capture the "de=
claring" aspect in this case:

"Space separated list of scope values (as described in OAuth 2.0 Section 3.=
3 [RFC6749]) that the clien=
t is declaring to the server that it may use when requesting access tokens =
and that the server is declaring to the client that it is registered to use=
 when requesting access tokens.".

You should probably also reinforce that scope values are service-specific a=
nd may not consist only of a static set of string values, and that therefor=
e, in some cases, an exhaustive list of registered scope values is not poss=
ible.

                                                            -- Mike

From: Justin Richer [mailto:jricher@mitre.org]
Sent: Monday, April 15, 2013 12:29 PM

To: Mike Jones
Cc: Tim Bray; oauth@ietf.org
Subject: Re: [OAUTH-WG] Registration: Scope Values

I think that because the "declaration" issue affects all parameters in the =
list, not just scope, we should adopt this in a higher level paragraph and =
leave it out of the individual parameter descriptions. Thus, something like=
 this inserted as the second paragraph in section 2:
The client metadata values serve two parallel purposes in the overall OAuth=
 Dynamic Registration protocol:

 - the Client requesting its desired values for each parameter to the Autho=
rization Server in a [register] or [update] request,
 - the Authorization Server informing the Client of the current values of e=
ach parameter that the Client has been registered to use through a [client =
information response].

An Authorization Server MAY override any value that a Client requests durin=
g the registration process (including any omitted values) and replace the r=
equested value with a default. The normative indications in the following l=
ist apply to the Client's declaration of its desired values.

The Authorization Server SHOULD provide documentation for any fields that i=
t requires to be filled in by the client or to have particular values or fo=
rmats. Extensions and profiles...

And then remove the sidedness-language from the scope parameter and any oth=
er parameters where it might have crept in inadvertently.

 -- Justin
On 04/15/2013 01:29 PM, Mike Jones wrote:
We could fix the one-sided language by changing
"Space separated list of scope values (as described in OAuth 2.0 Section 3.=
3 [RFC6749]) that the clien=
t is declaring that it may use when requesting access tokens."
to
"Space separated list of scope values (as described in OAuth 2.0 Section 3.=
3 [RFC6749]) that the clien=
t is declaring to the server that it may use when requesting access tokens =
and that the server is declaring to the client that it is registered to use=
 when requesting access tokens.".

Again, I chose the "registered to use" language carefully - because in the =
general case it's not a restriction on the values that the client can use -=
 just a statement by the server to the client that it is registered to use =
those particular values.  In both cases, the parties are making declaration=
s to one another.

If you adopt that language (or keep the original language), then yes, I'd c=
onsider this closed.

                                                            -- Mike

From: Justin Richer [mailto:jricher@mitre.org]
Sent: Monday, April 15, 2013 9:57 AM
To: Mike Jones
Cc: Tim Bray; oauth@ietf.org
Subject: Re: [OAUTH-WG] Registration: Scope Values

I absolutely do not want to delete this feature, as (having implemented it)=
 I think it's very useful. This is a very established pattern in manual reg=
istration: I know of many, many OAuth2 servers and clients that are set up =
where the client must pre-register a set of scopes.

I don't like the language of "the client is declaring" because it's too one=
-sided. The client might not have declared anything, and it might be the se=
rver that's declaring something to the client. Deleting the "is declaring" =
bit removes that unintended restriction of the language while keeping the o=
riginal meaning intact. I actually thought that I had fixed that before the=
 last draft went in but apparently I missed this one.

I will work on clarifying the intent of the whole metadata set in its intro=
ductory paragraph(s) so that it's clear that all of these fields are used i=
n both of these situations:

 1) The client declaring to the server its desire to use a particular value
 2) The server declaring to the client that it has been registered with a p=
articular value

This should hopefully clear up the issue in the editor's note that I curren=
tly have at the top of that section right now, too.

Mike, since you were the one who originally brought up the issue, and you'r=
e fine with the existing text, can I take this as closed now? Assuming that=
 you agree with deleting "is declaring" for reasons stated above, I'm fine =
with leaving everything else as is and staying quiet on what the server has=
 to do with the scopes.

 -- Justin
On 04/15/2013 12:44 PM, Mike Jones wrote:
I think that the existing wording is superior to the proposed changed wordi=
ng.  The existing wording is:

   scope
      OPTIONAL.  Space separated list of scope values (as described in
      OAuth 2.0 Section 3.3 [RFC6749]) that the client is declaring that
      it may use when requesting access tokens.  If omitted, an
      Authorization Server MAY register a Client with a default set of
      scopes.

For instance, the current "client is declaring" wording will always be corr=
ect, whereas as the change to "client can use" wording implies a restrictio=
n on client behavior that is not always applicable.  The "client is declari=
ng" wording was specific and purposefully chosen, and I think should be ret=
ained.  In particular, we can't do anything that implies that only the regi=
stered scopes values can be used.  At the OAuth spec level, this is a hint =
as to possible future client behavior - not a restriction on future client =
behavior.

Also, for the reasons that Tim stated, I'm strongly against any "matching" =
or "regex" language in the spec pertaining to scopes - as it's not actionab=
le.

So I'd propose that we leave the existing scope wording in place.  Alternat=
ively, I'd also be fine with deleting this feature entirely, as I don't thi=
nk it's useful in the general case.

                                                            -- Mike

From: oauth-bounces@ietf.org [mailto:oauth-b=
ounces@ietf.org]On Behalf Of Justin Richer
Sent: Monday, April 15, 2013 8:05 AM
To: Tim Bray; oauth@ietf.org
Subject: Re: [OAUTH-WG] Registration: Scope Values

On 04/15/2013 10:52 AM, Tim Bray wrote:



I'd use the existing wording; it's perfectly clear.  Failing that, if there=
's strong demand for registration of structured scopes, bless the use of re=
gexes, either PCREs or some careful subset.

Thanks for the feedback -- Of these two choices, I'd rather leave it as-is.





However, I'd subtract the sentence "If omitted, an Authorization Server MAY=
 register a Client with a default set of  scopes."  It adds no value; if th=
e client doesn't declare scopes, the client doesn't declare scopes, that's =
all.  -T

Remember, all of these fields aren't just for the client *request*, they're=
 also for the server's *response* to either a POST, PUT, or GET request. (I=
 didn't realize it, but perhaps the wording as stated right now doesn't mak=
e that clear -- I need to fix that.) The value that it adds is if the clien=
t doesn't ask for any particular scopes, the server can still assign it sco=
pes and the client can do something smart with that. Dumb clients are allow=
ed to ignore it if it doesn't mean anything to them.

This is how our server implementation actually works right now. If the clie=
nt doesn't ask for anything specific at registration, the server hands it a=
 bag of "default" scopes. Same thing happens at auth time -- if the client =
doesn't ask for any particular scopes, the server hands it all of its regis=
tered scopes as a default. Granted, on our server, scopes are just simple s=
trings right now, so they get compared at the auth endpoint with an exact s=
tring-match metric and set-based logic.

 -- Justin





On Mon, Apr 15, 2013 at 7:35 AM, Justin Richer > wrote:
What would you suggest for wording here, then? Keeping in mind that we cann=
ot (and don't want to) prohibit expression-based scopes.

 -- Justin

On 04/15/2013 10:33 AM, Tim Bray wrote:
No, I mean it's not interoperable at the software-developer level.  I can't=
 register scopes at authorization time with any predictable effect that I c=
an write code to support, either client or server side, without out-of-line=
 non-interoperable knowledge about the behavior of the server.

I guess I'm just not used to OAuth's culture of having no expectation that =
things will be specified tightly enough that I can write code to implement =
as specified.  -T

On Mon, Apr 15, 2013 at 7:15 AM, Justin Richer > wrote:
Scopes aren't meant to be interoperable between services since they're nece=
ssarily API-specific. The only interoperable bit is that there's *some* pla=
ce to put the values and that it's expressed as a bag of space-separated st=
rings. How those strings get interpreted and enforced (which is really what=
's at stake here) is up to the AS and PR (or a higher-level protocol like U=
MA).

 -- Justin

On 04/15/2013 10:13 AM, Tim Bray wrote:

This, as written, has zero interoperability.  I think this feature can real=
ly only be made useful in the case where scopes are fixed strings.

-T
On Apr 15, 2013 6:54 AM, "Justin Richer" > wrote:
You are correct that the idea behind the "scope" parameter at registration =
is a constraint on authorization-time scopes that are made available. It's =
both a means for the client to request a set of valid scopes and for the se=
rver to provision (and echo back to the client) a set of valid scopes.

I *really* don't want to try to define a matching language for scope expres=
sions. For that to work, all servers would need to be able to process the r=
egular expressions for all clients, even if the servers themselves only sup=
port simple-string scope values. Any regular expression syntax we pick here=
 is guaranteed to be incompatible with something, and I think the complexit=
y doesn't buy much. Also, I think you suddenly have a potential security is=
sue if you have a bad regex in place on either end.

As it stands today, the server can interpret the incoming registration scop=
es and enforce them however it wants to. The real trick comes not from assi=
gning the values to a particular client but to enforcing them, and I think =
that's always going to be service-specific. We're just not as clear on that=
 as we could be.

After looking over everyone's comments so far, I'd like to propose the foll=
owing text for that section:




   scope

      OPTIONAL.  Space separated list of scope values (as described in

      OAuth 2.0 Section 3.3 [RFC6749]) that the client can use when

      requesting access tokens.  As scope values are service-specific,

      the Authorization Server MAY define its own matching rules when

      determining if a scope value used during an authorization request

      is valid according to the scope values assigned during

      registration. Possible matching rules include wildcard patterns,

      regular expressions, or exactly matching the string. If omitted,

      an Authorization Server MAY register a Client with a default

      set of scopes.

Comments? Improvements?

 -- Justin



On 04/14/2013 08:23 PM, Manger, James H wrote:

Presumably at app registration time any scope specification is really a con=
straint on the scope values that can be requested in an authorization flow.



So ideally registration should accept rules for matching scopes, as opposed=
 to actual scope values.



You can try to use scope values as their own matching rules. That is fine f=
or a small set of "static" scopes. It starts to fail when there are a large=
 number of scopes, or scopes that can include parameters (resource paths? e=
mail addresses?). You can try to patch those failures by allowing services =
to define service-specific special "wildcard" scope values that can only be=
 used during registration (eg "read:*").



Alternatively, replace 'scope' in registration with 'scope_regex' that hold=
s a regular expression that all scope values in an authorization flow must =
match.



--

James Manger

_______________________________________________

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_4E1F6AAD24975D4BA5B16804296739436766EDB1TK5EX14MBXC284r_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











I could live with it if y=
ou expanded the text slightly as follows.  Otherwise people will keep =
asking questions that they deserve an answer to, even if the
 answer is “see the service documentation”.

 <=
/p>

Space-separated list of scop=
e values (as described in OAuth 2.0 Sec=
tion 3.3
 [RFC6749]) that the Client can use when requesting access token=
s from the Authorization Server.  The semantics of this list are servi=
ce specific.






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


 <=
/p>

 <=
/p>





From: Justin Richer [mailto:jricher@mitre.org]


Sent: Thursday, April 18, 2013 10:47 AM

To: Mike Jones

Cc: Anthony Nadalin; Tim Bray; oauth@ietf.org

Subject: Re: [OAUTH-WG] Registration: Scope Values=







 


Thing is, there's nothing normative about the enforc=
ing statement that I made below, so I don't think it's any more restrictive=
 than RFC 6749 which lets the AS replace a client's requested scopes at the=
 time of token issuance with whatever
 it pleases. But that said, I'd be just as happy to leave it like this with=
 no further restrictions:



Space-separated list of scope values (as described =
in OAuth 2.0 Section 3.3 [RFC6749]=
)
 that the Client can use when requesting access tokens from the Authorizati=
on Server.



And call it a day. This parallels the text for grant_types ("Ar=
ray of OAuth 2.0 grant types that the Client may use [when accessing the To=
ken Endpoint].") and response_types ("Array of the OAuth 2.0 resp=
onse types that the Client may use [when accessing
 the Authorization Endpoint]."), and I think this is the correct appro=
ach. I only started to add the restrictive text because I thought that peop=
le were making the argument that it was necessary -- I'd rather not have it=
.


 


Plus, it's an optiona=
l field in the metadata, so if you've got structured scopes where this does=
n't make sense, don't use it. If you don't do a per-client scope restrictio=
n, don't use it.




The interoperability is defined in light of the interoperability of scopes =
themselves: this is a field to request/grant a bag of strings that only mak=
e sense in light of a given API. For that to make real sense, I think that =
we need to differentiate an OAuth
 client as a generic *library* from an OAuth client as a generic accessing =
*application*. It's very useful for a generic *library* that handles the au=
thorization layer for an application to have a slot for registering scopes =
and finding out what scopes the
 app's been registered for. It's up to the app (not the library) to figure =
out how to translate those into scopes to ask for at authorization time. So=
metimes that means just passing the string, and sometimes it means the cons=
truction of a structured value like
 "urn:example:channel=3DHBO&urn:example:rating=
=3DG,PG-13". The library doesn't care, the application does, and we sh=
ould focus on interoperability from the library's perspective. Similarly, o=
n the server side, the libraries will tell you
 the bag of scopes that the client was registered for, and what bag of scop=
es the client asked for during authorization. It's up to the server *applic=
ation* to harmonize those two in a way that makes sense for the API that it=
's protecting. Just like it's up
 to the protected resource *application* to figure out what a scope means i=
n a given context.



So let's just leave it unrestricted but keep the slot for communicating thi=
s piece of information with the same semantics that the communication betwe=
en the client and server take on for every other field: client asks for a t=
hing, server says that client actually
 gets a thing, and it's implicitly up to the server to do the right thing a=
nd enforce things in a way that makes sense for the application no matter w=
hat the client does.




To take Tony's example, client requests no scopes at registration, server g=
rants scope "A" at registration. Client then requests scope "=
;X" at authorization, server is free to deny the request (invalid_scop=
e error), allow authorization because it knows how "A"
 and "X" are related, require user intervention, or really, whate=
ver it likes. The libraries, where I argue the interoperability cries reall=
y matter, don't care, and shouldn't care.



 -- Justin




On 04/18/2013 01:04 PM, Mike Jones wrote:=







Saying anything normative=
 about “enforcing restrictions” is going beyond RFC 6749 semant=
ics.  Indeed, you’d said that “I agree that we shou=
ldn't try
 to "solve" scope in registration.R=
21;, but talking about restrictions is going down the slippery “solvi=
ng it” path.


 <=
/p>

At most we can say that t=
he two parties are making declarations to one another about scopes that the=
y may choose to use, but we can’t assume that this is an
 exclusive list and that other scope values such as “urn:example:channel=3DHBO&urn:example:rating=3DG,PG-13<=
span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s=
erif";color:#1F497D">” might not be used, even if the client reg=
isters
 saying that it intends to use the “OATC” scope value.  We=
 could maybe even say that some services may use a static set of scopes and=
 might choose to limit the scopes that a client may use to those that it de=
clared to the server or to those that the server
 returned to the client.  That’s a HINT that some services might=
 do this.  But we can’t say anything normative about such possib=
le behaviors, because it goes beyond RFC 6749.


 <=
/p>

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


 <=
/p>



 




This doesn't actually break the semantics because th=
e client MUST accept what the server tells it over anything that it asks fo=
r in the first place. The server has the final say. So in this case, if you=
r client asks for nothing, the server
 says "A B C", the client now knows it can ask for "A B C&qu=
ot; scopes. 






 






I'm still in favor of not putting the restricting la=
nguage in the scope definition at all, instead have it say something like:<=
o:p>






 












“Space-separated list of scope values (as described in OAuth 2=
.0 Section 3.3
 [RFC6749]) that the Client can use when requesting access token=
s from the Authorization Server. As scope values are service specific, the =
means of the Authorization Server enforcing this restriction are outside th=
e scope of this specification.”








 






Couple this with the overall paragraph that says tha=
t the client is requesting values that the server is potentially overriding=
 with its declarations, and I think that addresses everything without getti=
ng into confusing language that doesn't
 add to interoperability. 






 






 -- Justin






 






On Apr 18, 2013, at 12:13 PM, Anthony Nadalin <tonynad@microsoft.com> wrote:=


















If I don’t specify =
a scope, then the server can allocate a default (or default set), thus that=
 breaks the semantics you describe






 






From: oauth-bounces@ietf.org
 [mailto:oauth-bounces@ietf.org] On Behalf Of Tim=
 Bray

Sent: Thursday, Ap=
ril 18, 2013 9:04 AM

To: Mike Jones

Cc: oauth@ietf.org

Subject: Re: [OAUT=
H-WG] Registration: Scope Values






 








I’m unconvinced, Mike.  Obviously youR=
17;re right about the looseness of OAuth2 scope specification, but this is =
a very specific semantic of what happens when you register, and I don’=
;t think we’re bound by history here.   If we can’t safely
 say anything about what the list of scopes means, then I'm with you let's =
take them out.  But the most obvious intended semantic is (from the cl=
ient) “I promise to ask only for these” and from the server =
220;These are the only ones I’ll give you tokens for.”
  Or does someone have use-cases for an alternative semantic?








 










To make this concrete, I propose the following:=











“Space-separated list of scope values (as described in OAuth 2=
.0 Section 3.3
 [RFC6749]) that the client is declaring to the server that it w=
ill restrict itself to when requesting access tokens, and that the server i=
s declaring to the client that it is registered to use when requesting acce=
ss tokens.  Clients
 SHOULD assume that servers will refuse to grant access tokens for scopes n=
ot in the list provided by the server.=
221;








 












 






On Thu, Apr 18, 2013 at 8:55 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:=









I don’t think it=
217;s possible to define what it means in an interoperable way because OAut=
h didn’t specify scopes in an interoperable way.  No, I don̵=
7;t like that
 either, but I think that’s where things are.  That’s why =
I was advocating deleting this registration feature entirely.






 <=
/p>





But understanding it migh=
t be useful in some contexts, I’m OK keeping it, provided we be clear=
 that the semantics of “registered to use” are service-specific=
.






 <=
/p>





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






 <=
/p>





From: Tim
 Bray [mailto:twbray@google.com] 

Sent: Thursday, Ap=
ril 18, 2013 8:36 AM

To: Mike Jones

Cc: Justin Richer;=
 oauth@ietf.org










Subject: Re: [OAUT=
H-WG] Registration: Scope Values










 








On the server-to-client side, what does “regis=
tered to use” mean?  Does it mean that the client should assume =
that any scopes not on the list WILL not be granted, MAY not be granted....=
 or what?  Is this already covered elsewhere? -T








 






On Thu, Apr 18, 2013 at 8:28 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:=









Thanks, Justin.  I a=
gree with the need for the generic two-sided language.  I’d stil=
l keep this language for scope, because we want to capture the “decla=
ring”
 aspect in this case:








 <=
/p>





“Spa=
ce separated list of scope values (as described in OAuth 2.0 Section&=
nbsp;3.3
 [RFC6749]) that the client is declaring to the server that it m=
ay use when requesting access tokens and that the server is declaring to th=
e client that it is registered to use when requesting access tokens.=
”.






 <=
/p>







You should probably also =
reinforce that scope values are service-specific and may not consist only o=
f a static set of string values, and that therefore, in
 some cases, an exhaustive list of registered scope values is not possible.=







 <=
/p>





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






 <=
/p>









From: Justin
 Richer [mailto:jricher@mitre.org] 

Sent: Monday, Apri=
l 15, 2013 12:29 PM













 




I think that because =
the "declaration" issue affects all parameters in the list, not j=
ust scope, we should adopt this in a higher level paragraph and leave it ou=
t of the individual parameter descriptions. Thus,
 something like this inserted as the second paragraph in section 2:




The client metadata values serve two parallel purpos=
es in the overall OAuth Dynamic Registration protocol: 



 - the Client requesting its desired values for each parameter to the =
Authorization Server in a [register] or [update] request,

 - the Authorization Server informing the Client of the current values=
 of each parameter that the Client has been registered to use through a [cl=
ient information response]. 



An Authorization Server MAY override any value that a Client requests durin=
g the registration process (including any omitted values) and replace the r=
equested value with a default. The normative indications in the following l=
ist apply to the Client's declaration
 of its desired values. <=
br>


The Authorization Server SHOULD provide documentation for any fields that i=
t requires to be filled in by the client or to have particular values or fo=
rmats. Extensions and profiles...






And then remove the sidedness-language from the scope parameter and any oth=
er parameters where it might have crept in inadvertently. 



 -- Justin






On 04/15/2013 01:29 PM, Mike Jones wrote:=











We could fix the one-side=
d language by changing






“Spa=
ce separated list of scope values (as described in OAuth 2.0 Section&=
nbsp;3.3
 [RFC6749]) that the client is declaring that it may use when re=
questing access tokens.”






to






“Spa=
ce separated list of scope values (as described in OAuth 2.0 Section&=
nbsp;3.3
 [RFC6749]) that the client is declaring to the server that it m=
ay use when requesting access tokens and that the server is declaring to th=
e client that it is registered to use when requesting access tokens.=
”.






 <=
/p>





Again, I chose the “=
;registered to use” language carefully – because in the general=
 case it’s not a restriction on the values that the client can use &#=
8211; just
 a statement by the server to the client that it is registered to use those=
 particular values.  In both cases, the parties are making declaration=
s to one another.






 <=
/p>





If you adopt that languag=
e (or keep the original language), then yes, I’d consider this closed=
.






 <=
/p>





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






 <=
/p>









From: Justin
 Richer [mailto:jricher@mitre.org] 

Sent: Monday, Apri=
l 15, 2013 9:57 AM

To: Mike Jones

Cc: Tim Bray; oauth@ietf.org

Subject: Re: [OAUT=
H-WG] Registration: Scope Values










 




I absolutely do not w=
ant to delete this feature, as (having implemented it) I think it's very us=
eful. This is a very established pattern in manual registration: I know of =
many, many OAuth2 servers and clients
 that are set up where the client must pre-register a set of scopes. 



I don't like the language of "the client is declaring" because it=
's too one-sided. The client might not have declared anything, and it might=
 be the server that's declaring something to the client. Deleting the "=
;is declaring" bit removes that unintended restriction
 of the language while keeping the original meaning intact. I actually thou=
ght that I had fixed that before the last draft went in but apparently I mi=
ssed this one.



I will work on clarifying the intent of the whole metadata set in its intro=
ductory paragraph(s) so that it's clear that all of these fields are used i=
n both of these situations:



 1) The client declaring to the server its desire to use a particular =
value

 2) The server declaring to the client that it has been registered wit=
h a particular value



This should hopefully clear up the issue in the editor's note that I curren=
tly have at the top of that section right now, too.



Mike, since you were the one who originally brought up the issue, and you'r=
e fine with the existing text, can I take this as closed now? Assuming that=
 you agree with deleting "is declaring" for reasons stated above,=
 I'm fine with leaving everything else as
 is and staying quiet on what the server has to do with the scopes.



 -- Justin






On 04/15/2013 12:44 PM, Mike Jones wrote:=











I think that the existing=
 wording is superior to the proposed changed wording.  The existing wo=
rding is:






 <=
/p>





   scope






      OPTIONAL. =
; Space separated list of scope values (as described in





      OAuth 2.0 Section 3.3 [RFC6749])
 that the client is declaring that






      it may use whe=
n requesting access tokens.  If omitted, an






      Authorization =
Server MAY register a Client with a default set of






      scopes.=







 <=
/p>





For instance, the current=
 “client is declaring” wording will always be correct, whereas =
as the change to “client can use” wording implies a restriction=
 on client
 behavior that is not always applicable.  The “client is declari=
ng” wording was specific and purposefully chosen, and I think should =
be retained.  In particular, we can’t do anything that implies t=
hat only the registered scopes values can be used.  At the OAuth
 spec level, this is a hint as to possible future client behavior – n=
ot a restriction on future client behavior.






 <=
/p>





Also, for the reasons tha=
t Tim stated, I’m strongly against any “matching” or R=
20;regex” language in the spec pertaining to scopes – as itR=
17;s not actionable.






 <=
/p>





So I’d propose that=
 we leave the existing scope wording in place.  Alternatively, I’=
;d also be fine with deleting this feature entirely, as I don’t think=
 it’s
 useful in the general case.






 <=
/p>





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






 <=
/p>









From: =
oauth-bounces@ietf.org&nbs=
p;[mailto:oauth-bounces@ietf.org]On
 Behalf Of Justin Ric=
her

Sent: Monday, Apri=
l 15, 2013 8:05 AM

To: Tim Bray; oauth@ietf.org

Subject: Re: [OAUT=
H-WG] Registration: Scope Values










 




On 04/15/2013 10:52 A=
M, Tim Bray wrote:














I’d use the existing wording; it’s perfe=
ctly clear.  Failing that, if there’s strong demand for registra=
tion of structured scopes, bless the use of regexes, either PCREs or some c=
areful subset.








Thanks for the feedback -- Of these two choices, I'd rather leave it as-is.=
 


















 










However, I’d subtract the sentence “If o=
mitted, an Authorization Server MAY register a Client with a default set of=
  scopes.”  It adds no value; if the client doesn’t d=
eclare scopes, the client doesn’t declare scopes, that’s all. &=
nbsp;-T










Remember, all of these fields aren't just for the client *request*, they're=
 also for the server's *response* to either a POST, PUT, or GET request. (I=
 didn't realize it, but perhaps the wording as stated right now doesn't mak=
e that clear -- I need to fix that.)
 The value that it adds is if the client doesn't ask for any particular sco=
pes, the server can still assign it scopes and the client can do something =
smart with that. Dumb clients are allowed to ignore it if it doesn't mean a=
nything to them. 



This is how our server implementation actually works right now. If the clie=
nt doesn't ask for anything specific at registration, the server hands it a=
 bag of "default" scopes. Same thing happens at auth time -- if t=
he client doesn't ask for any particular scopes,
 the server hands it all of its registered scopes as a default. Granted, on=
 our server, scopes are just simple strings right now, so they get compared=
 at the auth endpoint with an exact string-match metric and set-based logic=
. 



 -- Justin














 









What would you suggest for wording here, then? Keepi=
ng in mind that we cannot (and don't want to) prohibit expression-based sco=
pes. 



 -- Justin






 






On 04/15/2013 10:33 AM, Tim Bray wrote:











No, I mean it’s not interoperable at the softw=
are-developer level.  I can’t register scopes at authorization t=
ime with any predictable effect that I can write code to support, either cl=
ient or server side, without out-of-line non-interoperable
 knowledge about the behavior of the server.  








 










I guess I’m just not used to OAuth’s cul=
ture of having no expectation that things will be specified tightly enough =
that I can write code to implement as specified.  -T










 






On Mon, Apr 15, 2013 at 7:15 AM, Justin Richer <<=
a href=3D"mailto:jricher@mitre.org" target=3D"_blank">jricher@mitre.org> wrote:








Scopes aren't meant to be interoperable between serv=
ices since they're necessarily API-specific. The only interoperable bit is =
that there's *some* place to put the values and that it's expressed as a ba=
g of space-separated strings. How
 those strings get interpreted and enforced (which is really what's at stak=
e here) is up to the AS and PR (or a higher-level protocol like UMA).



 -- Justin






 






On 04/15/2013 10:13 AM, Tim Bray wrote:







This, as written, has zero interoperability.  I think this feature =
can really only be made useful in the case where scopes are fixed strings.<=
o:p>


-T






On Apr 15, 2013 6:54 AM, "Justin Richer" &=
lt;jricher@mitre.org> wrote:






You are correct that =
the idea behind the "scope" parameter at registration is a constr=
aint on authorization-time scopes that are made available. It's both a mean=
s for the client to request a set of valid scopes
 and for the server to provision (and echo back to the client) a set of val=
id scopes.



I *really* don't want to try to define a matching language for scope expres=
sions. For that to work, all servers would need to be able to process the r=
egular expressions for all clients, even if the servers themselves only sup=
port simple-string scope values.
 Any regular expression syntax we pick here is guaranteed to be incompatibl=
e with something, and I think the complexity doesn't buy much. Also, I thin=
k you suddenly have a potential security issue if you have a bad regex in p=
lace on either end. 



As it stands today, the server can interpret the incoming registration scop=
es and enforce them however it wants to. The real trick comes not from assi=
gning the values to a particular client but to enforcing them, and I think =
that's always going to be service-specific.
 We're just not as clear on that as we could be.



After looking over everyone's comments so far, I'd like to propose the foll=
owing text for that section:










   scope


      OPTIONAL.  Space separated list of=
 scope values (as described in


      OAuth 2.0 Section 3.3 [RFC6749]) that the client can use when =



      requesting access tokens.  As=
 scope values are service-specific, 


      the Authorization Server MAY defin=
e its own matching rules when


      determining if a scope value used durin=
g an authorization request


      is valid according to the scope values =
assigned during 


      registration. Possible matching ru=
les include wildcard patterns,


      regular expressions, or exactly matchin=
g the string. If omitted, 


      an Authorization Server MAY regist=
er a Client with a default 


      set of scopes.




Comments? Improvements?



 -- Justin














On 04/14/2013 08:23 PM, Manger, James H wrote:<=
/o:p>








Presumably at app registration time any scope specification is really =
a constraint on the scope values that can be requested in an authorization =
flow.


 


So ideally registration should accept rules for matching scopes, as op=
posed to actual scope values.


 


You can try to use scope values as their own matching rules. That is f=
ine for a small set of "static" scopes. It starts to fail when th=
ere are a large number of scopes, or scopes that can include parameters (re=
source paths? email addresses?). You can try to patch those failures by all=
owing services to define service-specific special "wildcard" scop=
e values that can only be used during registration (eg "read:*").=



 


Alternatively, replace 'scope' in registration with 'scope_regex' that=
 holds a regular expression that all scope values in an authorization flow =
must match.


 


--


James Manger


_______________________________________________


OAuth mailing list


OAuth@ietf.org


https://www.ietf.org/mailman/listinfo/oaut=
h






 








_______________________________________________

OAuth mailing list

OAuth@ietf.org

<=
span style=3D"color:purple">https://www.ietf.org/mailman/listinfo/oauth








 












 










 












 








 








 








 












 














 






_____________________________________=
__________

OAuth mailing list

OAuth@ietf.o=
rg

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






 






 






--_000_4E1F6AAD24975D4BA5B16804296739436766EDB1TK5EX14MBXC284r_--

From phil.hunt@oracle.com  Thu Apr 18 10:54:18 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAF8321F8709 for ; Thu, 18 Apr 2013 10:54:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.9
X-Spam-Level: 
X-Spam-Status: No, score=-5.9 tagged_above=-999 required=5 tests=[AWL=0.698, 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 GbzZnF6yGVwC for ; Thu, 18 Apr 2013 10:54:14 -0700 (PDT)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 8625321F86D3 for ; Thu, 18 Apr 2013 10:54:14 -0700 (PDT)
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r3IHsCD0023331 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 18 Apr 2013 17:54:13 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r3IHsCm4021287 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 18 Apr 2013 17:54:12 GMT
Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r3IHsBLh001885; Thu, 18 Apr 2013 17:54:11 GMT
Received: from [192.168.1.14] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 18 Apr 2013 10:54:09 -0700
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: multipart/alternative; boundary="Apple-Mail=_7F953BAB-6B45-4905-BFC6-0659AE12BB11"
From: Phil Hunt 
In-Reply-To: <5170319A.5080903@mitre.org>
Date: Thu, 18 Apr 2013 10:54:07 -0700
Message-Id: 
References: <255B9BB34FB7D647A506DC292726F6E1150C74DADA@WSMSG3153V.srv.dir.telstra.com> <516C101F.2090706@mitre.org>  <516C1714.8070503@mitre.org> <4E1F6AAD24975D4BA5B168042967394367641A87@TK5EX14MBXC283.redmond.corp.microsoft.com> <516C3152.9070603@mitre.org> <4E1F6AAD24975D4BA5B168042967394367641FAB@TK5EX14MBXC283.redmond.corp.microsoft.com> <516C54F2.8040708@mitre.org> <4E1F6AAD24975D4BA5B16804296739436766BCC4@TK5EX14MBXC284.redmond.corp.microsoft.com>  <4E1F6AAD24975D4BA5B16804296739436766C964@TK5EX14MBXC284.redmond.corp.microsoft.com>    <4E1F6AAD24975D4BA5B16804296739436766D8B9@TK5EX14MBXC284.redmond.corp.microsoft.com> <5170319A.5080903@mitre.org>
To: Justin Richer 
X-Mailer: Apple Mail (2.1283)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: Scope Values
X-BeenThere: oauth@ietf.org
X-Mailman-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, 18 Apr 2013 17:54:19 -0000

--Apple-Mail=_7F953BAB-6B45-4905-BFC6-0659AE12BB11
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Why not:

> "A value corresponding to scope as described in OAuth 2, Section 3.3 =
[RFC6749]. The registered Client may use these to indicate all of the =
scopes that a client MAY use when requesting tokens from an =
Authorization Server."

In the above, I avoid re-defining scope at all. However describing why =
they are included in registration is useful.  IMHO I think scope at =
registration is useful for life-cycle approval workflows.

In some cases you could say they are also the default list, but I'm not =
sure it helps inter-operability so its not clear it needs to be =
mentioned.

Phil

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





On 2013-04-18, at 10:47 AM, Justin Richer wrote:

> Thing is, there's nothing normative about the enforcing statement that =
I made below, so I don't think it's any more restrictive than RFC 6749 =
which lets the AS replace a client's requested scopes at the time of =
token issuance with whatever it pleases. But that said, I'd be just as =
happy to leave it like this with no further restrictions:
>=20
> Space-separated list of scope values (as described in OAuth 2.0 =
Section 3.3 [RFC6749]) that the Client can use when requesting access =
tokens from the Authorization Server.
>=20
> And call it a day. This parallels the text for grant_types ("Array of =
OAuth 2.0 grant types that the Client may use [when accessing the Token =
Endpoint].") and     response_types ("Array of the OAuth 2.0 response =
types that the Client may use [when accessing the Authorization =
Endpoint]."), and I think this is the correct approach. I only started =
to add the restrictive text because I thought that people were making =
the argument that it was necessary -- I'd rather not have it.
> Plus, it's an optional field in the metadata, so if you've got =
structured scopes where this doesn't make sense, don't use it. If you =
don't do a per-client scope restriction, don't use it.=20
>=20
> The interoperability is defined in light of the interoperability of =
scopes themselves: this is a field to request/grant a bag of strings =
that only make sense in light of a given API. For that to make real =
sense, I think that we need to differentiate an OAuth client as a =
generic *library* from an OAuth client as a generic accessing =
*application*. It's very useful for a generic *library* that handles the =
authorization layer for an application to have a slot for registering =
scopes and finding out what scopes the app's been registered for. It's =
up to the app (not the library) to figure out how to translate those =
into scopes to ask for at authorization time. Sometimes that means just =
passing the string, and sometimes it means the construction of a =
structured value like =
"urn:example:channel=3DHBO&urn:example:rating=3DG,PG-13". The library =
doesn't care, the application does, and we should focus on =
interoperability from the library's perspective. Similarly, on the =
server side, the libraries will tell you the bag of scopes that the =
client was registered for, and what bag of scopes the client asked for =
during authorization. It's up to the server *application* to harmonize =
those two in a way that makes sense for the API that it's protecting. =
Just like it's up to the protected resource *application* to figure out =
what a scope means in a given context.
>=20
> So let's just leave it unrestricted but keep the slot for =
communicating this piece of information with the same semantics that the =
communication between the client and server take on for every other =
field: client asks for a thing, server says that client actually gets a =
thing, and it's implicitly up to the server to do the right thing and =
enforce things in a way that makes sense for the application no matter =
what the client does.=20
>=20
> To take Tony's example, client requests no scopes at registration, =
server grants scope "A" at registration. Client then requests scope "X" =
at authorization, server is free to deny the request (invalid_scope =
error), allow authorization because it knows how "A" and "X" are =
related, require user intervention, or really, whatever it likes. The =
libraries, where I argue the interoperability cries really matter, don't =
care, and shouldn't care.
>=20
>  -- Justin
>=20
> On 04/18/2013 01:04 PM, Mike Jones wrote:
>> Saying anything normative about =93enforcing restrictions=94 is going =
beyond RFC 6749 semantics.  Indeed, you=92d said that =93I agree that we =
shouldn't try to "solve" scope in registration.=94, but talking about =
restrictions is going down the slippery =93solving it=94 path.
>> =20
>> At most we can say that the two parties are making declarations to =
one another about scopes that they may choose to use, but we can=92t =
assume that this is an exclusive list and that other scope values such =
as =93urn:example:channel=3DHBO&urn:example:rating=3DG,PG-13=94 might =
not be used, even if the client registers saying that it intends to use =
the =93OATC=94 scope value.  We could maybe even say that some services =
may use a static set of scopes and might choose to limit the scopes that =
a client may use to those that it declared to the server or to those =
that the server returned to the client.  That=92s a HINT that some =
services might do this.  But we can=92t say anything normative about =
such possible behaviors, because it goes beyond RFC 6749.
>> =20
>>                                                             -- Mike
>> =20
>> From: Richer, Justin P. [mailto:jricher@mitre.org]=20
>> Sent: Thursday, April 18, 2013 9:26 AM
>> To: Anthony Nadalin
>> Cc: Tim Bray; Mike Jones; oauth@ietf.org
>> Subject: Re: [OAUTH-WG] Registration: Scope Values
>> =20
>> This doesn't actually break the semantics because the client MUST =
accept what the server tells it over anything that it asks for in the =
first place. The server has the final say. So in this case, if your =
client asks for nothing, the server says "A B C", the client now knows =
it can ask for "A B C" scopes.=20
>> =20
>> I'm still in favor of not putting the restricting language in the =
scope definition at all, instead have it say something like:
>> =20
>> =93Space-separated list of scope values (as described in OAuth 2.0 =
Section 3.3 [RFC6749]) that the Client can use when requesting access =
tokens from the Authorization Server. As scope values are service =
specific, the means of the Authorization Server enforcing this =
restriction are outside the scope of this specification.=94
>> =20
>> Couple this with the overall paragraph that says that the client is =
requesting values that the server is potentially overriding with its =
declarations, and I think that addresses everything without getting into =
confusing language that doesn't add to interoperability.=20
>> =20
>>  -- Justin
>> =20
>> On Apr 18, 2013, at 12:13 PM, Anthony Nadalin  =
wrote:
>>=20
>>=20
>> If I don=92t specify a scope, then the server can allocate a default =
(or default set), thus that breaks the semantics you describe
>> =20
>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On =
Behalf Of Tim Bray
>> Sent: Thursday, April 18, 2013 9:04 AM
>> To: Mike Jones
>> Cc: oauth@ietf.org
>> Subject: Re: [OAUTH-WG] Registration: Scope Values
>> =20
>> I=92m unconvinced, Mike.  Obviously you=92re right about the =
looseness of OAuth2 scope specification, but this is a very specific =
semantic of what happens when you register, and I don=92t think we=92re =
bound by history here.   If we can=92t safely say anything about what =
the list of scopes means, then I'm with you let's take them out.  But =
the most obvious intended semantic is (from the client) =93I             =
        promise to ask only for these=94 and from the server =93These =
are the only ones I=92ll give you tokens for.=94  Or does someone have =
use-cases for an alternative semantic?
>> =20
>> To make this concrete, I propose the following:
>> =93Space-separated list of scope values (as described in OAuth 2.0 =
Section 3.3 [RFC6749]) that the client is declaring to the server that =
it will restrict itself to when requesting access tokens, and that the =
server is declaring to the client that it is registered to use when =
requesting access tokens.  Clients SHOULD assume that servers will =
refuse to grant access tokens for scopes not in the list provided by the =
server.=94
>> =20
>> =20
>>=20
>> On Thu, Apr 18, 2013 at 8:55 AM, Mike Jones =
 wrote:
>> I don=92t think it=92s possible to define what it means in an =
interoperable way because OAuth didn=92t specify scopes in an =
interoperable way.  No, I don=92t like that either, but I think that=92s =
where things are.  That=92s why I was advocating deleting this =
registration feature entirely.
>> =20
>> But understanding it might be useful in some contexts, I=92m OK =
keeping it, provided we be clear that the semantics of =93registered to =
use=94 are service-specific.
>> =20
>>                                                             -- Mike
>> =20
>> From: Tim Bray [mailto:twbray@google.com]=20
>> Sent: Thursday, April 18, 2013 8:36 AM
>> To: Mike Jones
>> Cc: Justin Richer; oauth@ietf.org
>>=20
>> Subject: Re: [OAUTH-WG] Registration: Scope Values
>> =20
>> On the server-to-client side, what does =93registered to use=94 mean? =
 Does it mean that the client should assume that any scopes not on the =
list WILL not be granted, MAY not be granted.... or what?  Is this =
already covered elsewhere? -T
>> =20
>>=20
>> On Thu, Apr 18, 2013 at 8:28 AM, Mike Jones =
 wrote:
>> Thanks, Justin.  I agree with the need for the generic two-sided =
language.  I=92d still keep this language for scope, because we want to =
capture the =93declaring=94 aspect in this case:
>> =20
>> =93Space separated list of scope values (as described in OAuth 2.0 =
Section 3.3 [RFC6749]) that the client is declaring to the server that =
it may use when requesting access tokens and that the server is =
declaring to the client that it is registered to use when requesting =
access tokens.=94.
>> =20
>> You should probably also reinforce that scope values are =
service-specific and may not consist only of a static set of string =
values, and that therefore, in some cases, an exhaustive list of =
registered scope values is not possible.
>> =20
>>                                                             -- Mike
>> =20
>> From: Justin Richer [mailto:jricher@mitre.org]=20
>> Sent: Monday, April 15, 2013 12:29 PM
>>=20
>> To: Mike Jones
>> Cc: Tim Bray; oauth@ietf.org
>> Subject: Re: [OAUTH-WG] Registration: Scope Values
>> =20
>> I think that because the "declaration" issue affects all parameters =
in the list, not just scope, we should adopt this in a higher level =
paragraph and leave it out of the individual parameter descriptions. =
Thus, something like this inserted as the second paragraph in            =
                     section 2:
>>=20
>> The client metadata values serve two parallel purposes in the overall =
OAuth Dynamic Registration protocol:=20
>>=20
>>  - the Client requesting its desired values for each parameter to the =
Authorization Server in a [register] or [update] request,
>>  - the Authorization Server informing the Client of the current =
values of each parameter that the Client has been registered to use =
through a [client information response].=20
>>=20
>> An Authorization Server MAY override any value that a Client requests =
during the registration process (including any omitted values) and =
replace the requested value with a default. The normative indications in =
the following list apply to the Client's declaration of its desired =
values.=20
>>=20
>> The Authorization Server SHOULD provide documentation for any fields =
that it requires to be filled in by the client or to have particular =
values or formats. Extensions and profiles...
>>=20
>> And then remove the sidedness-language from the scope parameter and =
any other parameters where it might have crept in inadvertently.=20
>>=20
>>  -- Justin
>>=20
>> On 04/15/2013 01:29 PM, Mike Jones wrote:
>> We could fix the one-sided language by changing
>> =93Space separated list of scope values (as described in OAuth 2.0 =
Section 3.3 [RFC6749]) that the client is declaring that it may use when =
requesting access tokens.=94
>> to
>> =93Space separated list of scope values (as described in OAuth 2.0 =
Section 3.3 [RFC6749]) that the client is declaring to the server that =
it may use when requesting access tokens and that the server is =
declaring to the client that it is registered to use when requesting =
access tokens.=94.
>> =20
>> Again, I chose the =93registered to use=94 language carefully =96 =
because in the general case it=92s not a restriction on the values that =
the client can use =96 just a statement by the server to the client that =
it is registered to use those particular values.  In both cases, the =
parties are making declarations to one another.
>> =20
>> If you adopt that language (or keep the original language), then yes, =
I=92d consider this closed.
>> =20
>>                                                             -- Mike
>> =20
>> From: Justin Richer [mailto:jricher@mitre.org]=20
>> Sent: Monday, April 15, 2013 9:57 AM
>> To: Mike Jones
>> Cc: Tim Bray; oauth@ietf.org
>> Subject: Re: [OAUTH-WG] Registration: Scope Values
>> =20
>> I absolutely do not want to delete this feature, as (having =
implemented it) I think it's very useful. This is a very established =
pattern in manual registration: I know of many, many OAuth2 servers and =
clients that are set up where the client must pre-register a set of =
scopes.=20
>>=20
>> I don't like the language of "the client is declaring" because it's =
too one-sided. The client might not have declared anything, and it might =
be the server that's declaring something to the client. Deleting the "is =
declaring" bit removes that unintended restriction of the language while =
keeping the original meaning intact. I actually thought that I had fixed =
that before the last draft went in but apparently I missed this one.
>>=20
>> I will work on clarifying the intent of the whole metadata set in its =
introductory paragraph(s) so that it's clear that all of these fields =
are used in both of these situations:
>>=20
>>  1) The client declaring to the server its desire to use a particular =
value
>>  2) The server declaring to the client that it has been registered =
with a particular value
>>=20
>> This should hopefully clear up the issue in the editor's note that I =
currently have at the top of that section right now, too.
>>=20
>> Mike, since you were the one who originally brought up the issue, and =
you're fine with the existing text, can I take this as closed now? =
Assuming that you agree with deleting "is declaring" for reasons stated =
above, I'm fine with leaving everything else as is and staying quiet on =
what the server has to do with the scopes.
>>=20
>>  -- Justin
>>=20
>> On 04/15/2013 12:44 PM, Mike Jones wrote:
>> I think that the existing wording is superior to the proposed changed =
wording.  The existing wording is:
>> =20
>>    scope
>>       OPTIONAL.  Space separated list of scope values (as described =
in
>>       OAuth 2.0 Section 3.3 [RFC6749]) that the client is declaring =
that
>>       it may use when requesting access tokens.  If omitted, an
>>       Authorization Server MAY register a Client with a default set =
of
>>       scopes.
>> =20
>> For instance, the current =93client is declaring=94 wording will =
always be correct, whereas as the change to =93client can use=94 wording =
implies a restriction on client behavior that is not always applicable.  =
The =93client is declaring=94 wording was specific and purposefully =
chosen, and I think should be retained.  In particular, we can=92t do =
anything that implies that only the registered scopes values can be =
used.  At the OAuth spec level, this is a hint as to possible future =
client behavior =96 not a restriction on future client behavior.
>> =20
>> Also, for the reasons that Tim stated, I=92m strongly against any =
=93matching=94 or =93regex=94 language in the spec pertaining to scopes =
=96 as it=92s not actionable.
>> =20
>> So I=92d propose that we leave the existing scope wording in place.  =
Alternatively, I=92d also be fine with deleting this feature entirely, =
as I don=92t think it=92s useful in the general case.
>> =20
>>                                                             -- Mike
>> =20
>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]On Behalf =
Of Justin Richer
>> Sent: Monday, April 15, 2013 8:05 AM
>> To: Tim Bray; oauth@ietf.org
>> Subject: Re: [OAUTH-WG] Registration: Scope Values
>> =20
>> On 04/15/2013 10:52 AM, Tim Bray wrote:
>>=20
>>=20
>>=20
>> I=92d use the existing wording; it=92s perfectly clear.  Failing =
that, if there=92s strong demand for registration of structured scopes, =
bless the use of regexes, either PCREs or some careful subset.
>>=20
>> Thanks for the feedback -- Of these two choices, I'd rather leave it =
as-is.=20
>>=20
>>=20
>>=20
>>=20
>> =20
>> However, I=92d subtract the sentence =93If omitted, an Authorization =
Server MAY register a Client with a default set of  scopes.=94  It adds =
no value; if the client doesn=92t declare scopes, the client doesn=92t =
declare scopes, that=92s all.  -T
>>=20
>> Remember, all of these fields aren't just for the client *request*, =
they're also for the server's *response* to either a POST, PUT, or GET =
request. (I didn't realize it, but perhaps the wording as stated right =
now doesn't make that clear -- I need to fix that.) The value that it =
adds is if the client doesn't ask for any particular scopes, the server =
can still assign it scopes and the client can do something smart with =
that. Dumb clients are allowed to ignore it if it doesn't mean anything =
to them.=20
>>=20
>> This is how our server implementation actually works right now. If =
the client doesn't ask for anything specific at registration, the server =
hands it a bag of "default" scopes. Same thing happens at auth time -- =
if the client doesn't ask for any particular scopes, the server hands it =
all of its registered scopes as a default. Granted, on our server, =
scopes are just simple strings right now, so they get compared at the =
auth endpoint with an exact string-match metric and set-based logic.=20
>>=20
>>  -- Justin
>>=20
>>=20
>>=20
>>=20
>> =20
>>=20
>> On Mon, Apr 15, 2013 at 7:35 AM, Justin Richer  =
wrote:
>> What would you suggest for wording here, then? Keeping in mind that =
we cannot (and don't want to) prohibit expression-based scopes.=20
>>=20
>>  -- Justin
>> =20
>>=20
>> On 04/15/2013 10:33 AM, Tim Bray wrote:
>> No, I mean it=92s not interoperable at the software-developer level.  =
I can=92t register scopes at                                             =
      authorization time with any predictable effect that I can write =
code to support, either client or server side, without out-of-line =
non-interoperable knowledge about the behavior of the server. =20
>> =20
>> I guess I=92m just not used to OAuth=92s culture of having no =
expectation that things will be specified tightly enough that I can =
write code to implement as specified.  -T
>> =20
>>=20
>> On Mon, Apr 15, 2013 at 7:15 AM, Justin Richer  =
wrote:
>> Scopes aren't meant to be interoperable between services since =
they're necessarily API-specific. The only interoperable bit is that =
there's *some* place to put the values and that it's expressed as a bag =
of space-separated strings. How those strings get interpreted and =
enforced (which is really what's at stake here) is up to the AS and PR =
(or a higher-level protocol like UMA).
>>=20
>>  -- Justin
>> =20
>>=20
>> On 04/15/2013 10:13 AM, Tim Bray wrote:
>> This, as written, has zero interoperability.  I think this feature =
can really only be made useful in the case where scopes are fixed =
strings.
>>=20
>> -T
>>=20
>> On Apr 15, 2013 6:54 AM, "Justin Richer"  wrote:
>> You are correct that the idea behind the "scope" parameter at =
registration is a                                                        =
   constraint on authorization-time scopes that are made available. It's =
both a means for the client to request a set of valid scopes and for the =
server to provision (and echo back to the client) a set of valid scopes.
>>=20
>> I *really* don't want to try to define a matching language for scope =
expressions. For that to work, all servers would need to be able to =
process the                                                           =
regular expressions for all clients, even if the servers themselves only =
support                                                           =
simple-string scope values. Any regular expression syntax we pick here =
is guaranteed to be incompatible with something, and I think the =
complexity doesn't buy much. Also, I think you suddenly have a potential =
security issue if you have a bad regex in place on either end.=20
>>=20
>> As it stands today, the server can interpret the incoming =
registration scopes and enforce them however it wants to. The real trick =
comes not from assigning the values to a particular client but to =
enforcing them, and I think that's always going to be service-specific. =
We're just not as clear on that as we could be.
>>=20
>> After looking over everyone's comments so far, I'd like to propose =
the following text for that section:
>>=20
>>=20
>>=20
>>    scope
>>       OPTIONAL.  Space separated list of scope values (as described =
in
>>       OAuth 2.0 Section 3.3 [RFC6749]) that the client can use when=20=

>>       requesting access tokens.  As scope values are =
service-specific,=20
>>       the Authorization Server MAY define its own matching rules when
>>       determining if a scope value used during an authorization =
request
>>       is valid according to the scope values assigned during=20
>>       registration. Possible matching rules include wildcard =
patterns,
>>       regular expressions, or exactly matching the string. If =
omitted,=20
>>       an Authorization Server MAY register a Client with a default=20
>>       set of scopes.
>>=20
>> Comments? Improvements?
>>=20
>>  -- Justin
>>=20
>>=20
>>=20
>> On 04/14/2013 08:23 PM, Manger, James H wrote:
>> Presumably at app registration time any scope specification is really =
a constraint on the scope values that can be requested in an =
authorization flow.
>> =20
>> So ideally registration should accept rules for matching scopes, as =
opposed to actual scope values.
>> =20
>> You can try to use scope values as their own matching rules. That is =
fine for a small set of "static" scopes. It starts to fail when there =
are a large number of scopes, or scopes that can include parameters =
(resource paths? email addresses?). You can try to patch those failures =
by allowing services to define service-specific special "wildcard" scope =
values that can only be used during registration (eg "read:*").
>> =20
>> Alternatively, replace 'scope' in registration with 'scope_regex' =
that holds a regular expression that all scope values in an =
authorization flow must match.
>> =20
>> --
>> James Manger
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>> =20
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>> =20
>> =20
>> =20
>> =20
>> =20
>> =20
>> =20
>> =20
>> =20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>> =20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_7F953BAB-6B45-4905-BFC6-0659AE12BB11
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

Why =
not:

"A value =
corresponding to scope as described in OAuth 2, Section 3.3 [RFC6749]. =
The registered Client may use these to indicate all of the scopes that a =
client MAY use when requesting tokens from an Authorization =
Server."

In the above, I avoid =
re-defining scope at all. However describing why they are included in =
registration is useful.  IMHO I think scope at registration is =
useful for life-cycle approval workflows.

In =
some cases you could say they are also the default list, but I'm not =
sure it helps inter-operability so its not clear it needs to be =
mentioned.



Phil

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








On 2013-04-18, at 10:47 AM, Justin Richer wrote:


 =20
    
 =20
  

    Thing is, there's nothing normative about the enforcing statement
    that I made below, so I don't think it's any more restrictive than
    RFC 6749 which lets the AS replace a client's requested scopes at
    the time of token issuance with whatever it pleases. But that said,
    I'd be just as happy to leave it like this with no further
    restrictions:

    

    Space-separated list of scope values (as described in
      OAuth 2.0 Section 3.3 =
[RFC6749])
      that the Client can use when requesting access tokens from the
      Authorization Server.

      

    And call it a day. This parallels =
the
    text for grant_types ("Array of OAuth 2.0 grant types that the
    Client may use [when accessing the Token Endpoint].") and
    response_types ("Array of the OAuth 2.0 response types that the
    Client may use [when accessing the Authorization Endpoint]."), and I
    think this is the correct approach. I only started to add the
    restrictive text because I thought that people were making the
    argument that it was necessary -- I'd rather not have it.

    

    Plus, it's an optional field in the metadata, so if you've got
    structured scopes where this doesn't make sense, don't use it. If
    you don't do a per-client scope restriction, don't use it. 

    

    The interoperability is defined in light of the interoperability of
    scopes themselves: this is a field to request/grant a bag of strings
    that only make sense in light of a given API. For that to make real
    sense, I think that we need to differentiate an OAuth client as a
    generic *library* from an OAuth client as a generic accessing
    *application*. It's very useful for a generic *library* that handles
    the authorization layer for an application to have a slot for
    registering scopes and finding out what scopes the app's been
    registered for. It's up to the app (not the library) to figure out
    how to translate those into scopes to ask for at authorization time.
    Sometimes that means just passing the string, and sometimes it means
    the construction of a structured value like "urn:example:channel=3DHBO&urn:example:rating=3DG,PG-13".
      The library doesn't care, the application does, and we should
      focus on interoperability from the library's perspective.
      Similarly, on the server side, the libraries will tell you
    the bag of scopes that the client was registered for, and what bag
    of scopes the client asked for during authorization. It's up to the
    server *application* to harmonize those two in a way that makes
    sense for the API that it's protecting. Just like it's up to the
    protected resource *application* to figure out what a scope means in
    a given context.

    

    So let's just leave it unrestricted but keep the slot for
    communicating this piece of information with the same semantics that
    the communication between the client and server take on for every
    other field: client asks for a thing, server says that client
    actually gets a thing, and it's implicitly up to the server to do
    the right thing and enforce things in a way that makes sense for the
    application no matter what the client does. 

    

    To take Tony's example, client requests no scopes at registration,
    server grants scope "A" at registration. Client then requests scope
    "X" at authorization, server is free to deny the request
    (invalid_scope error), allow authorization because it knows how "A"
    and "X" are related, require user intervention, or really, whatever
    it likes. The libraries, where I argue the interoperability cries
    really matter, don't care, and shouldn't care.

    

     -- Justin

    

    
On 04/18/2013 01:04 PM, Mike Jones
      wrote:

    

    

      
      
      
      
Saying
            anything normative about =93enforcing restrictions=94 is =
going
            beyond RFC 6749 semantics.  Indeed, you=92d said that =
=93I
          agree that we shouldn't try to "solve" scope in =
registration.=94,
            but talking about restrictions is going down the slippery
            =93solving it=94 path.
 
At
            most we can say that the two parties are making declarations
            to one another about scopes that they may choose to use, but
            we can=92t assume that this is an exclusive list and that
            other scope values such as =93urn:example:channel=3DHBO&urn:example:rating=3DG,PG-13=94
            might not be used, even if the client registers saying that
            it intends to use the =93OATC=94 scope value.  We could =
maybe
            even say that some services may use a static set of scopes
            and might choose to limit the scopes that a client may use
            to those that it declared to the server or to those that the
            server returned to the client.  That=92s a HINT that =
some
            services might do this.  But we can=92t say anything =
normative
            about such possible behaviors, because it goes beyond RFC
            6749.
 
        &nbs=
p;            =
            &n=
bsp;           &nbs=
p;            =
 
            -- Mike
 

        

          
From:
                Richer, Justin P. [mailto:jricher@mitre.org]
                

                Sent: Thursday, April 18, 2013 9:26 AM

                To: Anthony Nadalin

                Cc: Tim Bray; Mike Jones; oauth@ietf.org

                Subject: Re: [OAUTH-WG] Registration: Scope
                Values

          

        
 

        
This doesn't actually break the =
semantics
            because the client MUST accept what the server tells it over
            anything that it asks for in the first place. The server has
            the final say. So in this case, if your client asks for
            nothing, the server says "A B C", the client now knows it
            can ask for "A B C" scopes. 

        

        
 

        

        
I'm still in favor of not putting =
the
            restricting language in the scope definition at all, instead
            have it say something like:

        

        
 

        

        

          

            

              
=93Space-separated list of scope
                    values (as described in OAuth 2.0 Section 3.3

                        [RFC6749]) that the Client can use
                    when requesting access tokens from the Authorization
                    Server. As scope values are service specific, the
                    means of the Authorization Server enforcing this
                    restriction are outside the scope of this
                    specification.=94

              

            

          
 

        

        
Couple this with the overall =
paragraph
            that says that the client is requesting values that the
            server is potentially overriding with its declarations, and
            I think that addresses everything without getting into
            confusing language that doesn't add to =
interoperability. 

        

        
 

        

        
 -- Justin

        

        
 

          

            
On Apr 18, 2013, at 12:13 PM, =
Anthony
                Nadalin <tonynad@microsoft.com>
                wrote:

            


              

              

            

              
If
                    I don=92t specify a scope, then the server can
                    allocate a default (or default set), thus that
                    breaks the semantics you =
describe

              

              
              
From: oauth-bounces@ietf.org
                    [mailto:oauth-bounces@ietf.org] On Behalf
                      Of Tim
                    Bray

                    Sent: Thursday,
                    April 18, 2013 9:04 AM

                    To: Mike
                    Jones

                    Cc: oauth@ietf.org

                    Subject: Re:
                    [OAUTH-WG] Registration: Scope =
Values

              

              
 

              

              

                
I=92m unconvinced, Mike. =
 Obviously
                    you=92re right about the looseness of OAuth2 scope
                    specification, but this is a very specific semantic
                    of what happens when you register, and I don=92t =
think
                    we=92re bound by history here.   If we can=92t =
safely
                    say anything about what the list of scopes means,
                    then I'm with you let's take them out.  But the =
most
                    obvious intended semantic is (from the client) =93I
                    promise to ask only for these=94 and from the server
                    =93These are the only ones I=92ll give you tokens =
for.=94
                     Or does someone have use-cases for an =
alternative
                    semantic?

                

                

                  
 

                  

                

                

                  
To make this concrete, I
                      propose the following:

                  

                

                

                  
=93Space-separated list of
                        scope values (as described in OAuth 2.0 Section 3.3

                            [RFC6749]) that the client is
                        declaring to the server that it will restrict
                        itself to when requesting access tokens, and
                        that the server is declaring to the client that
                        it is registered to use when requesting access
                        tokens.  Clients SHOULD assume that servers
                        will refuse to grant access tokens for scopes
                        not in the list provided by the =
server.=94

                  

                  

                    
 

                    

                  

                

              

              
 

                

                  
On Thu, Apr 18, 2013 at =
8:55
                      AM, Mike Jones <Michael.Jones@microsoft.com>
                      wrote:

                  

                  

                    
I
                          don=92t think it=92s possible to define what =
it
                          means in an interoperable way because OAuth
                          didn=92t specify scopes in an interoperable
                          way.  No, I don=92t like that either, but =
I
                          think that=92s where things are.  That=92s =
why I
                          was advocating deleting this registration
                          feature entirely.

                    

                    
 

                    

                    
But
                          understanding it might be useful in some
                          contexts, I=92m OK keeping it, provided we be
                          clear that the semantics of =93registered to
                          use=94 are =
service-specific.

                    

                    
 

                    

                    
        &nbs=
p;            =
            &n=
bsp;           &nbs=
p;            =
 
                          -- Mike

                    

                    
 

                    

                    
From: Tim

                          Bray [mailto:twbray@google.com] 

                          Sent: Thursday,
                          April 18, 2013 8:36 AM

                          To: Mike
                          Jones

                          Cc: Justin
                          Richer; oauth@ietf.org

                    

                    

                      


                          Subject: Re:
                          [OAUTH-WG] Registration: Scope =
Values

                      

                    

                    

                      
 

                      

                      

                        
On the =
server-to-client
                            side, what does =93registered to use=94 =
mean?
                             Does it mean that the client should =
assume
                            that any scopes not on the list WILL not be
                            granted, MAY not be granted.... or what? =
 Is
                            this already covered elsewhere? =
-T

                        

                      

                      
 

                        

                          
On Thu, Apr 18, =
2013 at
                              8:28 AM, Mike Jones <Michael.Jones@microsoft.com>
                              wrote:

                          

                          

                            
Thanks,
                                  Justin.  I agree with the need =
for the
                                  generic two-sided language.  I=92d =
still
                                  keep this language for scope, because
                                  we want to capture the =93declaring=94
                                  aspect in this =
case:

                            

                            

                              
 

                              

                              
=93Space =
separated
                                    list of scope values (as described
                                    in OAuth 2.0 Section 3.3
                                        [RFC6749]) that the
                                    client is declaring to the server
                                    that it may use when requesting
                                    access tokens and that the server is
                                    declaring to the client that it is
                                    registered to use when requesting
                                    access tokens.=94.

                              

                              
 

                              

                            

                            
You
                                  should probably also reinforce that
                                  scope values are service-specific and
                                  may not consist only of a static set
                                  of string values, and that therefore,
                                  in some cases, an exhaustive list of
                                  registered scope values is not
                                  possible.

                            

                            
 

                            

                            
        &nbs=
p;            =
            &n=
bsp;           &nbs=
p;            =
 
                                  -- Mike

                            

                            
 

                            

                            

                              

                                
From: Justin

                                      Richer [mailto:jricher@mitre.org] 

                                      Sent: Monday,
                                      April 15, 2013 12:29 =
PM

                                

                                

                                  


                                      To: Mike
                                      Jones

                                      Cc: Tim
                                      Bray; oauth@ietf.org

                                      Subject: Re:
                                      [OAUTH-WG] Registration: Scope
                                      Values

                                  

                                

                              

                            

                            

                              
 

                              
I think
                                that because the "declaration" issue
                                affects all parameters in the list, not
                                just scope, we should adopt this in a
                                higher level paragraph and leave it out
                                of the individual parameter
                                descriptions. Thus, something like this
                                inserted as the second paragraph in
                                section 2:

                              
The client =
metadata
                                  values serve two parallel purposes in
                                  the overall OAuth Dynamic Registration
                                  protocol: 

                                  

                                   - the Client requesting its =
desired
                                  values for each parameter to the
                                  Authorization Server in a [register]
                                  or [update] request,

                                   - the Authorization Server =
informing
                                  the Client of the current values of
                                  each parameter that the Client has
                                  been registered to use through a
                                  [client information response]. 

                                  

                                  An Authorization Server MAY override
                                  any value that a Client requests
                                  during the registration process
                                  (including any omitted values) and
                                  replace the requested value with a
                                  default. The normative indications in
                                  the following list apply to the
                                  Client's declaration of its desired
                                  values. 

                                  

                                  The Authorization Server SHOULD
                                  provide documentation for any fields
                                  that it requires to be filled in by
                                  the client or to have particular
                                  values or formats. Extensions and
                                  profiles...

                              


                                And then remove the sidedness-language
                                from the scope parameter and any other
                                parameters where it might have crept in
                                inadvertently. 

                                

                                 -- Justin

                              

                                
On =
04/15/2013
                                    01:29 PM, Mike Jones =
wrote:

                                

                              

                              

                                
We
                                      could fix the one-sided language
                                      by changing

                                

                                
=93Space
                                      separated list of scope values (as
                                      described in OAuth 2.0 Section 3.3

                                          [RFC6749]) that the
                                      client is declaring that it may
                                      use when requesting access =
tokens.=94

                                

                                
to

                                

                                
=93Space
                                      separated list of scope values (as
                                      described in OAuth 2.0 Section 3.3

                                          [RFC6749]) that the
                                      client is declaring to the server
                                      that it may use when requesting
                                      access tokens and that the server
                                      is declaring to the client that it
                                      is registered to use when
                                      requesting access =
tokens.=94.

                                

                                
 

                                

                                
Again,
                                      I chose the =93registered to use=94
                                      language carefully =96 because in
                                      the general case it=92s not a
                                      restriction on the values that the
                                      client can use =96 just a =
statement
                                      by the server to the client that
                                      it is registered to use those
                                      particular values.  In both =
cases,
                                      the parties are making
                                      declarations to one =
another.

                                

                                
 

                                

                                
If
                                      you adopt that language (or keep
                                      the original language), then yes,
                                      I=92d consider this =
closed.

                                

                                
 

                                

                                
        &nbs=
p;            =
            &n=
bsp;           &nbs=
p;            =
 
                                      -- Mike

                                

                                
 

                                

                                

                                  

                                    
From: Justin

                                          Richer [mailto:jricher@mitre.org] 

                                          Sent: Monday,
                                          April 15, 2013 9:57 AM

                                          To: Mike
                                          Jones

                                          Cc: Tim
                                          Bray; oauth@ietf.org

                                          Subject: Re:
                                          [OAUTH-WG] Registration: Scope
                                          Values

                                    

                                  

                                

                                
 

                                
I
                                  absolutely do not want to delete this
                                  feature, as (having implemented it) I
                                  think it's very useful. This is a very
                                  established pattern in manual
                                  registration: I know of many, many
                                  OAuth2 servers and clients that are
                                  set up where the client must
                                  pre-register a set of scopes. 

                                  

                                  I don't like the language of "the
                                  client is declaring" because it's too
                                  one-sided. The client might not have
                                  declared anything, and it might be the
                                  server that's declaring something to
                                  the client. Deleting the "is
                                  declaring" bit removes that unintended
                                  restriction of the language while
                                  keeping the original meaning intact. I
                                  actually thought that I had fixed that
                                  before the last draft went in but
                                  apparently I missed this one.

                                  

                                  I will work on clarifying the intent
                                  of the whole metadata set in its
                                  introductory paragraph(s) so that it's
                                  clear that all of these fields are
                                  used in both of these situations:

                                  

                                   1) The client declaring to the =
server
                                  its desire to use a particular =
value

                                   2) The server declaring to the =
client
                                  that it has been registered with a
                                  particular value

                                  

                                  This should hopefully clear up the
                                  issue in the editor's note that I
                                  currently have at the top of that
                                  section right now, too.

                                  

                                  Mike, since you were the one who
                                  originally brought up the issue, and
                                  you're fine with the existing text,
                                  can I take this as closed now?
                                  Assuming that you agree with deleting
                                  "is declaring" for reasons stated
                                  above, I'm fine with leaving
                                  everything else as is and staying
                                  quiet on what the server has to do
                                  with the scopes.

                                  

                                   -- Justin

                                

                                  
On =
04/15/2013
                                      12:44 PM, Mike Jones =
wrote:

                                  

                                

                                

                                  
I
                                        think that the existing wording
                                        is superior to the proposed
                                        changed wording.  The =
existing
                                        wording =
is:

                                  

                                  
 

                                  

                                  
   =
scope

                                  

                                  
      OPTIONAL.  Space
                                        separated list of scope values
                                        (as described =
in

                                  

                                  
      OAuth 2.0 Section 3.3

                                            [RFC6749]) that
                                        the client is declaring =
that

                                  

                                  
      it may use when
                                        requesting access tokens.  =
If
                                        omitted, =
an

                                  

                                  
      Authorization
                                        Server MAY register a Client
                                        with a default set =
of

                                  

                                  
      scopes.

                                  

                                  
 

                                  

                                  
For
                                        instance, the current =93client =
is
                                        declaring=94 wording will always
                                        be correct, whereas as the
                                        change to =93client can use=94
                                        wording implies a restriction on
                                        client behavior that is not
                                        always applicable.  The =
=93client
                                        is declaring=94 wording was
                                        specific and purposefully
                                        chosen, and I think should be
                                        retained.  In particular, =
we
                                        can=92t do anything that implies
                                        that only the registered scopes
                                        values can be used.  At the
                                        OAuth spec level, this is a hint
                                        as to possible future client
                                        behavior =96 not a restriction =
on
                                        future client =
behavior.

                                  

                                  
 

                                  

                                  
Also,
                                        for the reasons that Tim stated,
                                        I=92m strongly against any
                                        =93matching=94 or =93regex=94 =
language
                                        in the spec pertaining to scopes
                                        =96 as it=92s not =
actionable.

                                  

                                  
 

                                  

                                  
So
                                        I=92d propose that we leave the
                                        existing scope wording in
                                        place.  Alternatively, I=92d =
also
                                        be fine with deleting this
                                        feature entirely, as I don=92t
                                        think it=92s useful in the =
general
                                        case.

                                  

                                  
 

                                  

                                  
        &nbs=
p;            =
            &n=
bsp;           &nbs=
p;            =
 
                                        -- Mike

                                  

                                  
 

                                  

                                  

                                    

                                      
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]On

                                              Behalf Of Justin
                                            Richer

                                            Sent: Monday,
                                            April 15, 2013 8:05 AM

                                            To: Tim
                                            Bray; oauth@ietf.org

                                            Subject: Re:
                                            [OAUTH-WG] Registration:
                                            Scope =
Values

                                      

                                    

                                  

                                  
 

                                  
On
                                    04/15/2013 10:52 AM, Tim Bray =
wrote:

                                    

                                    

                                    

                                  

                                    
I=92d =
use the
                                        existing wording; it=92s =
perfectly
                                        clear.  Failing that, if =
there=92s
                                        strong demand for registration
                                        of structured scopes, bless the
                                        use of regexes, either PCREs or
                                        some careful =
subset.

                                    

                                  


                                    Thanks for the feedback -- Of these
                                    two choices, I'd rather leave it
                                    as-is. 

                                    

                                    

                                    

                                    

                                  

                                    

                                      
 

                                      

                                    

                                    

                                      
However,=

                                          I=92d subtract the sentence =
=93If
                                          omitted, an Authorization
                                          Server MAY register a Client
                                          with a default set of
                                           scopes.=94  It adds =
no value;
                                          if the client doesn=92t =
declare
                                          scopes, the client doesn=92t
                                          declare scopes, that=92s all.
                                           -T

                                      

                                    

                                  


                                    Remember, all of these fields aren't
                                    just for the client *request*,
                                    they're also for the server's
                                    *response* to either a POST, PUT, or
                                    GET request. (I didn't realize it,
                                    but perhaps the wording as stated
                                    right now doesn't make that clear --
                                    I need to fix that.) The value that
                                    it adds is if the client doesn't ask
                                    for any particular scopes, the
                                    server can still assign it scopes
                                    and the client can do something
                                    smart with that. Dumb clients are
                                    allowed to ignore it if it doesn't
                                    mean anything to them. 

                                    

                                    This is how our server
                                    implementation actually works right
                                    now. If the client doesn't ask for
                                    anything specific at registration,
                                    the server hands it a bag of
                                    "default" scopes. Same thing happens
                                    at auth time -- if the client
                                    doesn't ask for any particular
                                    scopes, the server hands it all of
                                    its registered scopes as a default.
                                    Granted, on our server, scopes are
                                    just simple strings right now, so
                                    they get compared at the auth
                                    endpoint with an exact string-match
                                    metric and set-based logic. 

                                    

                                     -- Justin

                                    

                                    

                                    

                                    

                                  
 

                                    

                                      
On =
Mon, Apr
                                          15, 2013 at 7:35 AM, Justin
                                          Richer <jricher@mitre.org>
                                          wrote:

                                      

                                      

                                        
What
                                            would you suggest for
                                            wording here, then? Keeping
                                            in mind that we cannot (and
                                            don't want to) prohibit
                                            expression-based =
scopes. 

                                            

                                               -- =
Justin

                                        

                                        
 

                                          

                                            
On=

                                                04/15/2013 10:33 AM, Tim
                                                Bray =
wrote:

                                            

                                          

                                          

                                            

                                              
No,
                                                  I mean it=92s not
                                                  interoperable at the
                                                  software-developer
                                                  level.  I can=92t
                                                  register scopes at
                                                  authorization time
                                                  with any predictable
                                                  effect that I can
                                                  write code to support,
                                                  either client or
                                                  server side, without
                                                  out-of-line
                                                  non-interoperable
                                                  knowledge about the
                                                  behavior of the
                                                  server. =
 

                                              

                                              

                                                
 

                                                

                                              

                                              

                                                
I
                                                    guess I=92m just not
                                                    used to OAuth=92s
                                                    culture of having no
                                                    expectation that
                                                    things will be
                                                    specified tightly
                                                    enough that I can
                                                    write code to
                                                    implement as
                                                    specified. =
 -T

                                                

                                              

                                            

                                            
 

                                              

                                                
On
                                                    Mon, Apr 15, 2013 at
                                                    7:15 AM, Justin
                                                    Richer <jricher@mitre.org>
                                                    =
wrote:

                                                

                                                

                                                  
Scopes
                                                      aren't meant to be
                                                      interoperable
                                                      between services
                                                      since they're
                                                      necessarily
                                                      API-specific. The
                                                      only interoperable
                                                      bit is that
                                                      there's *some*
                                                      place to put the
                                                      values and that
                                                      it's expressed as
                                                      a bag of
                                                      space-separated
                                                      strings. How those
                                                      strings get
                                                      interpreted and
                                                      enforced (which is
                                                      really what's at
                                                      stake here) is up
                                                      to the AS and PR
                                                      (or a higher-level
                                                      protocol like
                                                      UMA).

                                                        

                                                         -- =
Justin

                                                  

                                                  
 

                                                    

                                                      
On
                                                          04/15/2013
                                                          10:13 AM, Tim
                                                          Bray =
wrote:

                                                      

                                                    

                                                    
This, as
                                                        written, has
                                                        zero
                                                        =
interoperability. 
                                                        I think this
                                                        feature can
                                                        really only be
                                                        made useful in
                                                        the case where
                                                        scopes are fixed
                                                        =
strings.
-T

                                                      

                                                        
On
                                                          Apr 15, 2013
                                                          6:54 AM,
                                                          "Justin
                                                          Richer" <jricher@mitre.org> =
wrote:

                                                        

                                                        
You are correct that =
the idea behind the
                                                          "scope"
                                                          parameter at
                                                          registration
                                                          is a
                                                          constraint on
                                                          =
authorization-time
                                                          scopes that
                                                          are made
                                                          available.
                                                          It's both a
                                                          means for the
                                                          client to
                                                          request a set
                                                          of valid
                                                          scopes and for
                                                          the server to
                                                          provision (and
                                                          echo back to
                                                          the client) a
                                                          set of valid
                                                          scopes.

                                                          

                                                          I *really*
                                                          don't want to
                                                          try to define
                                                          a matching
                                                          language for
                                                          scope
                                                          expressions.
                                                          For that to
                                                          work, all
                                                          servers would
                                                          need to be
                                                          able to
                                                          process the
                                                          regular
                                                          expressions
                                                          for all
                                                          clients, even
                                                          if the servers
                                                          themselves
                                                          only support
                                                          simple-string
                                                          scope values.
                                                          Any regular
                                                          expression
                                                          syntax we pick
                                                          here is
                                                          guaranteed to
                                                          be
                                                          incompatible
                                                          with
                                                          something, and
                                                          I think the
                                                          complexity
                                                          doesn't buy
                                                          much. Also, I
                                                          think you
                                                          suddenly have
                                                          a potential
                                                          security issue
                                                          if you have a
                                                          bad regex in
                                                          place on
                                                          either =
end. 

                                                          

                                                          As it stands
                                                          today, the
                                                          server can
                                                          interpret the
                                                          incoming
                                                          registration
                                                          scopes and
                                                          enforce them
                                                          however it
                                                          wants to. The
                                                          real trick
                                                          comes not from
                                                          assigning the
                                                          values to a
                                                          particular
                                                          client but to
                                                          enforcing
                                                          them, and I
                                                          think that's
                                                          always going
                                                          to be
                                                          =
service-specific.
                                                          We're just not
                                                          as clear on
                                                          that as we
                                                          could be.

                                                          

                                                          After looking
                                                          over
                                                          everyone's
                                                          comments so
                                                          far, I'd like
                                                          to propose the
                                                          following text
                                                          for that
                                                          section:

                                                          

                                                          

                                                          =


                                                          =

   scope

                                                          =

      OPTIONAL.  Space separated list =
of scope values (as described in

                                                          =

      OAuth 2.0 Section 3.3 =
[RFC6749]) that the client can use when 

                                                          =

      requesting access tokens.  =
As scope values are service-specific, 

                                                          =

      the Authorization Server MAY =
define its own matching rules when

                                                          =

      determining if a scope value used =
during an authorization request

                                                          =

      is valid according to the scope =
values assigned during 

                                                          =

      registration. Possible matching =
rules include wildcard patterns,

                                                          =

      regular expressions, or exactly =
matching the string. If omitted, 

                                                          =

      an Authorization Server MAY =
register a Client with a default 

                                                          =

      set of =
scopes.


                                                          Comments?
                                                          =
Improvements?

                                                          

                                                           -- =
Justin

                                                          

                                                          

                                                          =


                                                          

                                                          
On
                                                          04/14/2013
                                                          08:23 PM,
                                                          Manger, James
                                                          H =
wrote:

                                                          

                                                          

                                                          

                                                          =

Presumably at app registration time any scope specification is =
really a constraint on the scope values that can be requested in an =
authorization flow.

                                                          =

 

                                                          
So =
ideally registration should accept rules for matching scopes, as opposed =
to actual scope values.

                                                          =

 

                                                          
You can =
try to use scope values as their own matching rules. That is fine for a =
small set of "static" scopes. It starts to fail when there are a large =
number of scopes, or scopes that can include parameters (resource paths? =
email addresses?). You can try to patch those failures by allowing =
services to define service-specific special "wildcard" scope values that =
can only be used during registration (eg "read:*").

                                                          =

 

                                                          =

Alternatively, replace 'scope' in registration with 'scope_regex' =
that holds a regular expression that all scope values in an =
authorization flow must match.

                                                          =

 

                                                          =

--

                                                          
James =
Manger

                                                          =

_______________________________________________

                                                          
OAuth =
mailing list

                                                          
OAuth@ietf.org

                                                          
https://www.ietf.org/mailman/listinfo/oauth<=
/a>

                                                          

                                                          
 

                                                          

                                                        


_______________________________________________

                                                          OAuth mailing
                                                          list

                                                          OAuth@ietf.org

                                                          https://www.ietf.org/mailman/listinfo/oauth<=
/a>

                                                      

                                                    

                                                    
 

                                                    

                                                  

                                                

                                              

                                              
 

                                              

                                            

                                          

                                          
 

                                          

                                        

                                      

                                    

                                    
 

                                    

                                  

                                  
 

                                  

                                

                                
 

                                

                              

                              
 

                              

                            

                          

                        

                        
 

                        

                      

                    

                  

                

                
 

                

              
_______________________________________________

                  OAuth mailing list

                  OAuth@ietf.org

                  https://www.ietf.org/mailman/listinfo/oauth<=
/a>

            

          
 

        

      

    

    

  


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

=

--Apple-Mail=_7F953BAB-6B45-4905-BFC6-0659AE12BB11--

From twbray@google.com  Thu Apr 18 10:57:35 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EAAA21F90EB for ; Thu, 18 Apr 2013 10:57:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.977
X-Spam-Level: 
X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Sj2kgLoa3yF for ; Thu, 18 Apr 2013 10:57:20 -0700 (PDT)
Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id E258821F8FE8 for ; Thu, 18 Apr 2013 10:57:17 -0700 (PDT)
Received: by mail-ie0-f174.google.com with SMTP id 10so3714959ied.33 for ; Thu, 18 Apr 2013 10:57:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=kkA6n0vlY4+2AsOPX6fZLRFsmnP9wOXS4fXoqd8YlS8=; b=eoQabC7NoMylOO5adPfFg80fLEvt6tJL0OKszpmf8lzt3y+2eUv6VMBdUA2GdzERRV 6F7jx5+FOzlOaQaNePY3ULLRWidjU/ZPFcwakw+4Kj9hfxIH5AmFwmXUGcqU+aJeyZb0 bLcxcJ3aHE1LuhvjYQdI5ECh4Accrbf8fFJl7El3reiCNx1IxU9eT+2Q3fUtsxPKD2LB LnJ+LvKJBRsAxH7cTgOUreged3ntJyYEJEnhNakjnEpPrRxdbQ+4pjfE/mW0gT9oLNGE UUDp8O5vDJBfvGKYXVG5sKH1G+UgCNA0DRzhS3EXnlylSNpvh9Ny59eXXdKqxMXxXOta 4Elw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=kkA6n0vlY4+2AsOPX6fZLRFsmnP9wOXS4fXoqd8YlS8=; b=IjkDTV9Sy38qAVhkKAfY7Ghx+/4N5e4olADTFItMgfPaIOYeutYieBE2348e6y7h9s iSpzzs3TpKQQ+s8jwtJOF2TQ6FDd9hVzLvl7j3vi2mMl+m8N1JjzJeFTgukfZif+AEXI d5J/jmoSuscQP4tmmU8oOFHg8uFsPLF7gNETDWJILGVVy/Fi5U91TmHl9OY4e3DGE96A 0kMMqrwXNtyljK+uXOFCzmbsLX4H2B05HPoKznKvoW8EdH68dN9dRMrrv/NK1TZoS3nc T4xpX/Yi3E/RmfIr0EF97b6WnaRRQ/KOXtNveEqvK0+REsNFnri2ZkXL3SxkemdC+c0i q0xA==
X-Received: by 10.43.90.137 with SMTP id bi9mr6271716icc.51.1366307837370; Thu, 18 Apr 2013 10:57:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.31.35 with HTTP; Thu, 18 Apr 2013 10:56:46 -0700 (PDT)
In-Reply-To: <5170319A.5080903@mitre.org>
References: <255B9BB34FB7D647A506DC292726F6E1150C74DADA@WSMSG3153V.srv.dir.telstra.com> <516C101F.2090706@mitre.org>  <516C1714.8070503@mitre.org> <4E1F6AAD24975D4BA5B168042967394367641A87@TK5EX14MBXC283.redmond.corp.microsoft.com> <516C3152.9070603@mitre.org> <4E1F6AAD24975D4BA5B168042967394367641FAB@TK5EX14MBXC283.redmond.corp.microsoft.com> <516C54F2.8040708@mitre.org> <4E1F6AAD24975D4BA5B16804296739436766BCC4@TK5EX14MBXC284.redmond.corp.microsoft.com>  <4E1F6AAD24975D4BA5B16804296739436766C964@TK5EX14MBXC284.redmond.corp.microsoft.com>    <4E1F6AAD24975D4BA5B16804296739436766D8B9@TK5EX14MBXC284.redmond.corp.microsoft.com> <5170319A.5080903@mitre.org>
From: Tim Bray 
Date: Thu, 18 Apr 2013 10:56:46 -0700
Message-ID: 
To: Justin Richer 
Content-Type: multipart/alternative; boundary=bcaec51867784d0f0204daa655b2
X-Gm-Message-State: ALoCoQmDQ0kgjq/z/eDFigm+EXWl6k05S6KjZiWlVAgPILaJDqDtfE7NYaGOfF+TVviPaZXc2tD5MLd2aiYhrerw++o1Bzn84nKpRSFWjbfTXX5EfauL40gP8HNlB4cF+iKFQS31iO5OckKA3/2F0gohtt5uYWJQYDu7yNxOCNgJYwkB274PC4ce4IGtV06v1qumr/z4Ma0+
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: Scope Values
X-BeenThere: oauth@ietf.org
X-Mailman-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, 18 Apr 2013 17:57:35 -0000

--bcaec51867784d0f0204daa655b2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Apr 18, 2013 at 10:47 AM, Justin Richer  wrote:


> It's very useful for a generic *library* that handles the authorization
> layer for an application to have a slot for registering scopes and findin=
g
> out what scopes the app's been registered for.
>

I don=E2=80=99t see how it=E2=80=99s useful in the slightest if there=E2=80=
=99s no defined semantic
for what =E2=80=9Cregistration=E2=80=9D actually means, i.e. what result is=
 to be expected
when sending or receiving a list of scopes.   -T


>
>
>
> On 04/18/2013 01:04 PM, Mike Jones wrote:
>
>  Saying anything normative about =E2=80=9Cenforcing restrictions=E2=80=9D=
 is going beyond
> RFC 6749 semantics.  Indeed, you=E2=80=99d said that =E2=80=9CI agree tha=
t we shouldn't
> try to "solve" scope in registration.=E2=80=9D, but talking about restric=
tions is
> going down the slippery =E2=80=9Csolving it=E2=80=9D path.****
>
> ** **
>
> At most we can say that the two parties are making declarations to one
> another about scopes that they may choose to use, but we can=E2=80=99t as=
sume that
> this is an exclusive list and that other scope values such as =E2=80=9C
> urn:example:channel=3DHBO&urn:example:rating=3DG,PG-13=E2=80=9D might not=
 be used,
> even if the client registers saying that it intends to use the =E2=80=9CO=
ATC=E2=80=9D scope
> value.  We could maybe even say that some services may use a static set o=
f
> scopes and might choose to limit the scopes that a client may use to thos=
e
> that it declared to the server or to those that the server returned to th=
e
> client.  That=E2=80=99s a HINT that some services might do this.  But we =
can=E2=80=99t say
> anything normative about such possible behaviors, because it goes beyond
> RFC 6749.****
>
> ** **
>
>                                                             -- Mike****
>
> ** **
>
> *From:* Richer, Justin P. [mailto:jricher@mitre.org ]
> *Sent:* Thursday, April 18, 2013 9:26 AM
> *To:* Anthony Nadalin
> *Cc:* Tim Bray; Mike Jones; oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] Registration: Scope Values****
>
> ** **
>
> This doesn't actually break the semantics because the client MUST accept
> what the server tells it over anything that it asks for in the first plac=
e.
> The server has the final say. So in this case, if your client asks for
> nothing, the server says "A B C", the client now knows it can ask for "A =
B
> C" scopes. ****
>
> ** **
>
> I'm still in favor of not putting the restricting language in the scope
> definition at all, instead have it say something like:****
>
> ** **
>
>  =E2=80=9CSpace-separated list of scope values (as described in OAuth 2.0=
 Section 3.3
> [RFC6749] ) that the
> Client can use when requesting access tokens from the Authorization Serve=
r.
> As scope values are service specific, the means of the Authorization Serv=
er
> enforcing this restriction are outside the scope of this specification.=
=E2=80=9D**
> **
>
> ** **
>
> Couple this with the overall paragraph that says that the client is
> requesting values that the server is potentially overriding with its
> declarations, and I think that addresses everything without getting into
> confusing language that doesn't add to interoperability. ****
>
> ** **
>
>  -- Justin****
>
> ** **
>
> On Apr 18, 2013, at 12:13 PM, Anthony Nadalin 
> wrote:****
>
>
>
> ****
>
> If I don=E2=80=99t specify a scope, then the server can allocate a defaul=
t (or
> default set), thus that breaks the semantics you describe****
>
>  ****
>
> *From:* oauth-bounces@ietf.org [mailto:oauth -bounces@ietf.org] *O=
n
> Behalf Of *Tim Bray
> *Sent:* Thursday, April 18, 2013 9:04 AM
> *To:* Mike Jones
> *Cc:* oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] Registration: Scope Values****
>
>  ****
>
> I=E2=80=99m unconvinced, Mike.  Obviously you=E2=80=99re right about the =
looseness of
> OAuth2 scope specification, but this is a very specific semantic of what
> happens when you register, and I don=E2=80=99t think we=E2=80=99re bound =
by history here.
> If we can=E2=80=99t safely say anything about what the list of scopes mea=
ns, then
> I'm with you let's take them out.  But the most obvious intended semantic
> is (from the client) =E2=80=9CI promise to ask only for these=E2=80=9D an=
d from the server
> =E2=80=9CThese are the only ones I=E2=80=99ll give you tokens for.=E2=80=
=9D  Or does someone have
> use-cases for an alternative semantic?****
>
>  ****
>
> To make this concrete, I propose the following:****
>
> =E2=80=9CSpace-separated list of scope values (as described in OAuth 2.0 =
Section 3.3
> [RFC6749] ) that the
> client is declaring to the server that it will restrict itself to when
> requesting access tokens, and that the server is declaring to the client
> that it is registered to use when requesting access tokens.  Clients
> SHOULD assume that servers will refuse to grant access tokens for scopes
> not in the list provided by the server.=E2=80=9D****
>
>  ****
>
>  ****
>
> On Thu, Apr 18, 2013 at 8:55 AM, Mike Jones 
> wrote:****
>
>  I don=E2=80=99t think it=E2=80=99s possible to define what it means in a=
n interoperable
> way because OAuth didn=E2=80=99t specify scopes in an interoperable way. =
 No, I
> don=E2=80=99t like that either, but I think that=E2=80=99s where things a=
re.  That=E2=80=99s why I
> was advocating deleting this registration feature entirely.****
>
>  ****
>
> But understanding it might be useful in some contexts, I=E2=80=99m OK kee=
ping it,
> provided we be clear that the semantics of =E2=80=9Cregistered to use=E2=
=80=9D are
> service-specific.****
>
>  ****
>
>                                                             -- Mike****
>
>  ****
>
> *From:* Tim Bray [mailto:twbray@google.com]
> *Sent:* Thursday, April 18, 2013 8:36 AM
> *To:* Mike Jones
> *Cc:* Justin Richer; oauth@ietf.org****
>
>
> *Subject:* Re: [OAUTH-WG] Registration: Scope Values****
>
>  ****
>
> On the server-to-client side, what does =E2=80=9Cregistered to use=E2=80=
=9D mean?  Does it
> mean that the client should assume that any scopes not on the list WILL n=
ot
> be granted, MAY not be granted.... or what?  Is this already covered
> elsewhere? -T****
>
>  ****
>
> On Thu, Apr 18, 2013 at 8:28 AM, Mike Jones 
> wrote:****
>
> Thanks, Justin.  I agree with the need for the generic two-sided
> language.  I=E2=80=99d still keep this language for scope, because we wan=
t to
> capture the =E2=80=9Cdeclaring=E2=80=9D aspect in this case:****
>
>  ****
>
> =E2=80=9CSpace separated list of scope values (as described in OAuth 2.0 =
Section 3.3
> [RFC6749] ) that the
> client is declaring to the server that it may use when requesting access
> tokens and that the server is declaring to the client that it is register=
ed
> to use when requesting access tokens.=E2=80=9D.****
>
>  ****
>
> You should probably also reinforce that scope values are service-specific
> and may not consist only of a static set of string values, and that
> therefore, in some cases, an exhaustive list of registered scope values i=
s
> not possible.****
>
>  ****
>
>                                                             -- Mike****
>
>  ****
>
> *From:* Justin Richer [mailto:jricher@mitre.org]
> *Sent:* Monday, April 15, 2013 12:29 PM****
>
>
> *To:* Mike Jones
> *Cc:* Tim Bray; oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] Registration: Scope Values****
>
>  ****
>
> I think that because the "declaration" issue affects all parameters in th=
e
> list, not just scope, we should adopt this in a higher level paragraph an=
d
> leave it out of the individual parameter descriptions. Thus, something li=
ke
> this inserted as the second paragraph in section 2:****
>
> The client metadata values serve two parallel purposes in the overall
> OAuth Dynamic Registration protocol:
>
>  - the Client requesting its desired values for each parameter to the
> Authorization Server in a [register] or [update] request,
>  - the Authorization Server informing the Client of the current values of
> each parameter that the Client has been registered to use through a [clie=
nt
> information response].
>
> An Authorization Server MAY override any value that a Client requests
> during the registration process (including any omitted values) and replac=
e
> the requested value with a default. The normative indications in the
> following list apply to the Client's declaration of its desired values.
>
> The Authorization Server SHOULD provide documentation for any fields that
> it requires to be filled in by the client or to have particular values or
> formats. Extensions and profiles...****
>
>
> And then remove the sidedness-language from the scope parameter and any
> other parameters where it might have crept in inadvertently.
>
>  -- Justin****
>
> On 04/15/2013 01:29 PM, Mike Jones wrote:****
>
>  We could fix the one-sided language by changing****
>
> =E2=80=9CSpace separated list of scope values (as described in OAuth 2.0 =
Section 3.3
> [RFC6749] ) that the
> client is declaring that it may use when requesting access tokens.=E2=80=
=9D****
>
> to****
>
> =E2=80=9CSpace separated list of scope values (as described in OAuth 2.0 =
Section 3.3
> [RFC6749] ) that the
> client is declaring to the server that it may use when requesting access
> tokens and that the server is declaring to the client that it is register=
ed
> to use when requesting access tokens.=E2=80=9D.****
>
>  ****
>
> Again, I chose the =E2=80=9Cregistered to use=E2=80=9D language carefully=
 =E2=80=93 because in the
> general case it=E2=80=99s not a restriction on the values that the client=
 can use =E2=80=93
> just a statement by the server to the client that it is registered to use
> those particular values.  In both cases, the parties are making
> declarations to one another.****
>
>  ****
>
> If you adopt that language (or keep the original language), then yes, I=
=E2=80=99d
> consider this closed.****
>
>  ****
>
>                                                             -- Mike****
>
>  ****
>
> *From:* Justin Richer [mailto:jricher@mitre.org ]
> *Sent:* Monday, April 15, 2013 9:57 AM
> *To:* Mike Jones
> *Cc:* Tim Bray; oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] Registration: Scope Values****
>
>  ****
>
> I absolutely do not want to delete this feature, as (having implemented
> it) I think it's very useful. This is a very established pattern in manua=
l
> registration: I know of many, many OAuth2 servers and clients that are se=
t
> up where the client must pre-register a set of scopes.
>
> I don't like the language of "the client is declaring" because it's too
> one-sided. The client might not have declared anything, and it might be t=
he
> server that's declaring something to the client. Deleting the "is
> declaring" bit removes that unintended restriction of the language while
> keeping the original meaning intact. I actually thought that I had fixed
> that before the last draft went in but apparently I missed this one.
>
> I will work on clarifying the intent of the whole metadata set in its
> introductory paragraph(s) so that it's clear that all of these fields are
> used in both of these situations:
>
>  1) The client declaring to the server its desire to use a particular val=
ue
>  2) The server declaring to the client that it has been registered with a
> particular value
>
> This should hopefully clear up the issue in the editor's note that I
> currently have at the top of that section right now, too.
>
> Mike, since you were the one who originally brought up the issue, and
> you're fine with the existing text, can I take this as closed now? Assumi=
ng
> that you agree with deleting "is declaring" for reasons stated above, I'm
> fine with leaving everything else as is and staying quiet on what the
> server has to do with the scopes.
>
>  -- Justin****
>
> On 04/15/2013 12:44 PM, Mike Jones wrote:****
>
>  I think that the existing wording is superior to the proposed changed
> wording.  The existing wording is:****
>
>  ****
>
>    scope****
>
>       OPTIONAL.  Space separated list of scope values (as described in***=
*
>
>       OAuth 2.0 Section 3.3 [RFC6749])
> that the client is declaring that****
>
>       it may use when requesting access tokens.  If omitted, an****
>
>       Authorization Server MAY register a Client with a default set of***=
*
>
>       scopes.****
>
>  ****
>
> For instance, the current =E2=80=9Cclient is declaring=E2=80=9D wording w=
ill always be
> correct, whereas as the change to =E2=80=9Cclient can use=E2=80=9D wordin=
g implies a
> restriction on client behavior that is not always applicable.  The =E2=80=
=9Cclient
> is declaring=E2=80=9D wording was specific and purposefully chosen, and I=
 think
> should be retained.  In particular, we can=E2=80=99t do anything that imp=
lies that
> only the registered scopes values can be used.  At the OAuth spec level,
> this is a hint as to possible future client behavior =E2=80=93 not a rest=
riction on
> future client behavior.****
>
>  ****
>
> Also, for the reasons that Tim stated, I=E2=80=99m strongly against any =
=E2=80=9Cmatching=E2=80=9D
> or =E2=80=9Cregex=E2=80=9D language in the spec pertaining to scopes =E2=
=80=93 as it=E2=80=99s not
> actionable.****
>
>  ****
>
> So I=E2=80=99d propose that we leave the existing scope wording in place.
> Alternatively, I=E2=80=99d also be fine with deleting this feature entire=
ly, as I
> don=E2=80=99t think it=E2=80=99s useful in the general case.****
>
>  ****
>
>                                                             -- Mike****
>
>  ****
>
> *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org
> ]*On Behalf Of *Justin Richer
> *Sent:* Monday, April 15, 2013 8:05 AM
> *To:* Tim Bray; oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] Registration: Scope Values****
>
>  ****
>
> On 04/15/2013 10:52 AM, Tim Bray wrote:
>
>
> ****
>
> I=E2=80=99d use the existing wording; it=E2=80=99s perfectly clear.  Fail=
ing that, if
> there=E2=80=99s strong demand for registration of structured scopes, bles=
s the use
> of regexes, either PCREs or some careful subset.****
>
>
> Thanks for the feedback -- Of these two choices, I'd rather leave it as-i=
s.
>
>
>
>
> ****
>
>  ****
>
> However, I=E2=80=99d subtract the sentence =E2=80=9CIf omitted, an Author=
ization Server
> MAY register a Client with a default set of  scopes.=E2=80=9D  It adds no=
 value; if
> the client doesn=E2=80=99t declare scopes, the client doesn=E2=80=99t dec=
lare scopes,
> that=E2=80=99s all.  -T****
>
>
> Remember, all of these fields aren't just for the client *request*,
> they're also for the server's *response* to either a POST, PUT, or GET
> request. (I didn't realize it, but perhaps the wording as stated right no=
w
> doesn't make that clear -- I need to fix that.) The value that it adds is
> if the client doesn't ask for any particular scopes, the server can still
> assign it scopes and the client can do something smart with that. Dumb
> clients are allowed to ignore it if it doesn't mean anything to them.
>
> This is how our server implementation actually works right now. If the
> client doesn't ask for anything specific at registration, the server hand=
s
> it a bag of "default" scopes. Same thing happens at auth time -- if the
> client doesn't ask for any particular scopes, the server hands it all of
> its registered scopes as a default. Granted, on our server, scopes are ju=
st
> simple strings right now, so they get compared at the auth endpoint with =
an
> exact string-match metric and set-based logic.
>
>  -- Justin
>
>
>
> ****
>
>  ****
>
> On Mon, Apr 15, 2013 at 7:35 AM, Justin Richer  wrote:=
*
> ***
>
> What would you suggest for wording here, then? Keeping in mind that we
> cannot (and don't want to) prohibit expression-based scopes.
>
>  -- Justin****
>
>  ****
>
> On 04/15/2013 10:33 AM, Tim Bray wrote:****
>
>  No, I mean it=E2=80=99s not interoperable at the software-developer leve=
l.  I
> can=E2=80=99t register scopes at authorization time with any predictable =
effect
> that I can write code to support, either client or server side, without
> out-of-line non-interoperable knowledge about the behavior of the server.
> ****
>
>  ****
>
> I guess I=E2=80=99m just not used to OAuth=E2=80=99s culture of having no=
 expectation that
> things will be specified tightly enough that I can write code to implemen=
t
> as specified.  -T****
>
>  ****
>
> On Mon, Apr 15, 2013 at 7:15 AM, Justin Richer  wrote:=
*
> ***
>
> Scopes aren't meant to be interoperable between services since they're
> necessarily API-specific. The only interoperable bit is that there's *som=
e*
> place to put the values and that it's expressed as a bag of space-separat=
ed
> strings. How those strings get interpreted and enforced (which is really
> what's at stake here) is up to the AS and PR (or a higher-level protocol
> like UMA).
>
>  -- Justin****
>
>  ****
>
> On 04/15/2013 10:13 AM, Tim Bray wrote:****
>
> This, as written, has zero interoperability.  I think this feature can
> really only be made useful in the case where scopes are fixed strings.***=
*
>
> -T****
>
> On Apr 15, 2013 6:54 AM, "Justin Richer"  wrote:****
>
> You are correct that the idea behind the "scope" parameter at registratio=
n
> is a constraint on authorization-time scopes that are made available. It'=
s
> both a means for the client to request a set of valid scopes and for the
> server to provision (and echo back to the client) a set of valid scopes.
>
> I *really* don't want to try to define a matching language for scope
> expressions. For that to work, all servers would need to be able to proce=
ss
> the regular expressions for all clients, even if the servers themselves
> only support simple-string scope values. Any regular expression syntax we
> pick here is guaranteed to be incompatible with something, and I think th=
e
> complexity doesn't buy much. Also, I think you suddenly have a potential
> security issue if you have a bad regex in place on either end.
>
> As it stands today, the server can interpret the incoming registration
> scopes and enforce them however it wants to. The real trick comes not fro=
m
> assigning the values to a particular client but to enforcing them, and I
> think that's always going to be service-specific. We're just not as clear
> on that as we could be.
>
> After looking over everyone's comments so far, I'd like to propose the
> following text for that section:
>
>
> ****
>
>    scope****
>
>       OPTIONAL.  Space separated list of scope values (as described in***=
*
>
>       OAuth 2.0 Section 3.3 [RFC6749] ) that the client can use when ****
>
>       requesting access tokens.  As scope values are service-specific, **=
**
>
>       the Authorization Server MAY define its own matching rules when****
>
>       determining if a scope value used during an authorization request**=
**
>
>       is valid according to the scope values assigned during ****
>
>       registration. Possible matching rules include wildcard patterns,***=
*
>
>       regular expressions, or exactly matching the string. If omitted, **=
**
>
>       an Authorization Server MAY register a Client with a default ****
>
>       set of scopes.****
>
>
> Comments? Improvements?
>
>  -- Justin
>
>
> ****
>
> On 04/14/2013 08:23 PM, Manger, James H wrote:****
>
> Presumably at app registration time any scope specification is really a c=
onstraint on the scope values that can be requested in an authorization flo=
w.****
>
>  ****
>
> So ideally registration should accept rules for matching scopes, as oppos=
ed to actual scope values.****
>
>  ****
>
> You can try to use scope values as their own matching rules. That is fine=
 for a small set of "static" scopes. It starts to fail when there are a lar=
ge number of scopes, or scopes that can include parameters (resource paths?=
 email addresses?). You can try to patch those failures by allowing service=
s to define service-specific special "wildcard" scope values that can only =
be used during registration (eg "read:*").****
>
>  ****
>
> Alternatively, replace 'scope' in registration with 'scope_regex' that ho=
lds a regular expression that all scope values in an authorization flow mus=
t match.****
>
>  ****
>
> --****
>
> James Manger****
>
> _______________________________________________****
>
> 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****
>
> ** **
>
>
>

--bcaec51867784d0f0204daa655b2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On Thu, Apr 18, 2013 at 10:47 AM, Justin Richer <jricher@mitre.org> wrote:




=C2=A0
 It's very useful for a generic *library* that handles
    the authorization layer for an application to have a slot for
    registering scopes and finding out what scopes the app's been
    registered for.

I don=E2=80=99t s=
ee how it=E2=80=99s useful in the slightest if there=E2=80=99s no defined s=
emantic for what =E2=80=9Cregistration=E2=80=9D actually means, i.e. what r=
esult is to be expected when sending or receiving a list of scopes. =C2=A0 =
-T




=C2=A0



    

    
On 04/18/2013 01:04 PM, Mike Jones
      wrote:

    

    

     =20
     =20
     =20
      

        
Saying
            anything normative about =E2=80=9Cenforcing restrictions=E2=80=
=9D is going
            beyond RFC 6749 semantics.=C2=A0 Indeed, you=E2=80=99d said tha=
t =E2=80=9CI
          agree that we shouldn't try to "solve" scope in reg=
istration.=E2=80=9D,
            but talking about restrictions is going down the slippery
            =E2=80=9Csolving it=E2=80=9D path.

        
=C2=A0<=
/u>

        
At
            most we can say that the two parties are making declarations
            to one another about scopes that they may choose to use, but
            we can=E2=80=99t assume that this is an exclusive list and that
            other scope values such as =E2=80=9Cur=
n:example:channel=3DHBO&urn:example:rating=3DG,PG-13=E2=80=9D
            might not be used, even if the client registers saying that
            it intends to use the =E2=80=9COATC=E2=80=9D scope value.=C2=A0=
 We could maybe
            even say that some services may use a static set of scopes
            and might choose to limit the scopes that a client may use
            to those that it declared to the server or to those that the
            server returned to the client.=C2=A0 That=E2=80=99s a HINT that=
 some
            services might do this.=C2=A0 But we can=E2=80=99t say anything=
 normative
            about such possible behaviors, because it goes beyond RFC
            6749.

        
=C2=A0<=
/u>

        
=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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

        
=C2=A0<=
/u>

        

          

            
From:
                Richer, Justin P. [mailto:jricher@mitre.org]
                

                Sent: Thursday, April 18, 2013 9:26 AM

                To: Anthony Nadalin

                Cc: Tim Bray; Mike Jones; oauth@ietf.org

                Subject: Re: [OAUTH-WG] Registration: Scope
                Values

          

        

        
=C2=A0

        

          
This doesn't actually break the semant=
ics
            because the client MUST accept what the server tells it over
            anything that it asks for in the first place. The server has
            the final say. So in this case, if your client asks for
            nothing, the server says "A B C", the client now know=
s it
            can ask for "A B C" scopes.=C2=A0

        

        

          
=C2=A0

        

        

          
I'm still in favor of not putting the
            restricting language in the scope definition at all, instead
            have it say something like:

        

        

          
=C2=A0

        

        

          

            

              

                
=E2=80=9C=
Space-separated list of scope
                    values (as described in OAuth 2.0=C2=A0Section=C2=A03.3

                        [RFC6749]) that the Client can use
                    when requesting access tokens from the Authorization
                    Server. As scope values are service specific, the
                    means of the Authorization Server enforcing this
                    restriction are outside the scope of this
                    specification.=E2=80=
=9D

              

            

          

          
=C2=A0

        

        

          
Couple this with the overall paragraph
            that says that the client is requesting values that the
            server is potentially overriding with its declarations, and
            I think that addresses everything without getting into
            confusing language that doesn't add to interoperability.=C2=
=A0

        

        

          
=C2=A0

        

        

          
=C2=A0-- Justin

        

        

          
=C2=A0

          

            

              
On Apr 18, 2013, at 12:13 PM, Anthony
                Nadalin <tonynad@microsoft.com>
                wrote:

            

            


              

              

            

              

                
If
                    I don=E2=80=99t specify a scope, then the server can
                    allocate a default (or default set), thus that
                    breaks the semantics you describe<=
/p>
              

              
              

                
From:=C2=A0oauth-bounces@ietf.org
                    [mailto:oauth-bounces@ietf.org]=C2=A0On Behalf
                      Of=C2=A0Tim
                    Bray

                    Sent:=C2=A0Thursday,
                    April 18, 2013 9:04 AM

                    To:=C2=A0Mike
                    Jones

                    Cc:=C2=A0oauth@ietf.org

                    Subject:=C2=A0Re:
                    [OAUTH-WG] Registration: Scope Values<=
/u>

              

              

                
=C2=A0

              

              

                

                  
I=E2=80=99m unconvinced, Mike. =C2=
=A0Obviously
                    you=E2=80=99re right about the looseness of OAuth2 scop=
e
                    specification, but this is a very specific semantic
                    of what happens when you register, and I don=E2=80=99t =
think
                    we=E2=80=99re bound by history here. =C2=A0 If we can=
=E2=80=99t safely
                    say anything about what the list of scopes means,
                    then I'm with you let's take them out. =C2=A0Bu=
t the most
                    obvious intended semantic is (from the client) =E2=80=
=9CI
                    promise to ask only for these=E2=80=9D and from the ser=
ver
                    =E2=80=9CThese are the only ones I=E2=80=99ll give you =
tokens for.=E2=80=9D
                    =C2=A0Or does someone have use-cases for an alternative
                    semantic?

                

                

                  

                    
=C2=A0

                  

                

                

                  

                    
To make this concrete, I
                      propose the following:

                  

                

                

                  

                    
=E2=
=80=9CSpace-separated list of
                        scope values (as described in OAuth 2.0=C2=A0Section=C2=A03.3

                            [RFC6749]) that the client is
                        declaring to the server that it will restrict
                        itself to when requesting access tokens, and
                        that the server is declaring to the client that
                        it is registered to use when requesting access
                        tokens. =C2=A0Clients SHOULD assume th=
at servers
                        will refuse to grant access tokens for scopes
                        not in the list provided by the server.=E2=80=9D

                  

                  

                    

                      
=C2=A0

                    

                  

                

              

              

                
=C2=
=A0

                

                  

                    
On Thu, Apr 18, 2013 at 8:55
                      AM, Mike Jones <Michael.Jones@microsoft.com>
                      wrote:

                  

                  

                    

                      
I
                          don=E2=80=99t think it=E2=80=99s possible to defi=
ne what it
                          means in an interoperable way because OAuth
                          didn=E2=80=99t specify scopes in an interoperable
                          way.=C2=A0 No, I don=E2=80=99t like that either, =
but I
                          think that=E2=80=99s where things are.=C2=A0 That=
=E2=80=99s why I
                          was advocating deleting this registration
                          feature entirely.

                    

                    

                      
=C2=
=A0

                    

                    

                      
But
                          understanding it might be useful in some
                          contexts, I=E2=80=99m OK keeping it, provided we =
be
                          clear that the semantics of =E2=80=9Cregistered t=
o
                          use=E2=80=9D are service-specific.<=
u>

                    

                    

                      
=C2=
=A0

                    

                    

                      
=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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

                    

                    

                      
=C2=
=A0

                    

                    

                      
From:=C2=A0Tim

                          Bray [mailto:twbray@goo=
gle.com]=C2=A0

                          Sent:=C2=A0Thursday,
                          April 18, 2013 8:36 AM

                          To:=C2=A0Mike
                          Jones

                          Cc:=C2=A0Justin
                          Richer;=C2=A0=
oauth@ietf.org

                    

                    

                      

                        


                          Subject:=C2=A0Re:
                          [OAUTH-WG] Registration: Scope Values

                      

                    

                    

                      

                        
=C2=A0

                      

                      

                        

                          
On the server-to-client
                            side, what does =E2=80=9Cregistered to use=E2=
=80=9D mean?
                            =C2=A0Does it mean that the client should assum=
e
                            that any scopes not on the list WILL not be
                            granted, MAY not be granted.... or what? =C2=A0=
Is
                            this already covered elsewhere? -T

                        

                      

                      

                        
=C2=A0

                        

                          

                            
On Thu, Apr 18, 2013 at
                              8:28 AM, Mike Jones <Michael.Jones@microsoft.com>
                              wrote:

                          

                          

                            

                              
Thanks,
                                  Justin.=C2=A0 I agree with the need for t=
he
                                  generic two-sided language.=C2=A0 I=E2=80=
=99d still
                                  keep this language for scope, because
                                  we want to capture the =E2=80=9Cdeclaring=
=E2=80=9D
                                  aspect in this case:=


                            

                            

                              

                                
=C2=A0

                              

                              

                                
=E2=80=9CSpace separated
                                    list of scope values (as described
                                    in OAuth 2.0=C2=A0Section=C2=A03.3
                                        [RFC6749]) that the
                                    client is declaring to the server
                                    that it may use when requesting
                                    access tokens and that the server is
                                    declaring to the client that it is
                                    registered to use when requesting
                                    access tokens.=E2=80=9D.

                              

                              

                                
=C2=A0

                              

                            

                            

                              
You
                                  should probably also reinforce that
                                  scope values are service-specific and
                                  may not consist only of a static set
                                  of string values, and that therefore,
                                  in some cases, an exhaustive list of
                                  registered scope values is not
                                  possible.

                            

                            

                              
=C2=A0

                            

                            

                              
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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

                            

                            

                              
=C2=A0

                            

                            

                              

                                

                                  
Fro=
m:=C2=A0Justin

                                      Richer [mailto:jricher@mitre.org]=C2=A0

                                      Sent:=C2=A0Monday=
,
                                      April 15, 2013 12:29 PM=


                                

                                

                                  

                                    


                                      To:=C2=A0Mike
                                      Jones

                                      Cc:=C2=A0Tim
                                      Bray;=C2=A0oauth@ietf.org

                                      Subject:=C2=A0Re:
                                      [OAUTH-WG] Registration: Scope
                                      Values

                                  

                                

                              

                            

                            

                              

                                
=C2=A0=


                              

                              
I think
                                that because the "declaration" is=
sue
                                affects all parameters in the list, not
                                just scope, we should adopt this in a
                                higher level paragraph and leave it out
                                of the individual parameter
                                descriptions. Thus, something like this
                                inserted as the second paragraph in
                                section 2:

                              

                                
The client metadata
                                  values serve two parallel purposes in
                                  the overall OAuth Dynamic Registration
                                  protocol:=C2=A0

                                  

                                  =C2=A0- the Client requesting its desired
                                  values for each parameter to the
                                  Authorization Server in a [register]
                                  or [update] request,

                                  =C2=A0- the Authorization Server informin=
g
                                  the Client of the current values of
                                  each parameter that the Client has
                                  been registered to use through a
                                  [client information response].=C2=
=A0

                                  

                                  An Authorization Server MAY override
                                  any value that a Client requests
                                  during the registration process
                                  (including any omitted values) and
                                  replace the requested value with a
                                  default. The normative indications in
                                  the following list apply to the
                                  Client's declaration of its desired
                                  values.=C2=A0

                                  

                                  The Authorization Server SHOULD
                                  provide documentation for any fields
                                  that it requires to be filled in by
                                  the client or to have particular
                                  values or formats. Extensions and
                                  profiles...

                              

                              


                                And then remove the sidedness-language
                                from the scope parameter and any other
                                parameters where it might have crept in
                                inadvertently.=C2=A0

                                

                                =C2=A0-- Justin

                              

                                

                                  
On 04/15/2013
                                    01:29 PM, Mike Jones wrote:

                                

                              

                              

                                

                                  
We
                                      could fix the one-sided language
                                      by changing

                                

                                

                                  
=E2=80=9CSpace
                                      separated list of scope values (as
                                      described in OAuth 2.0=C2=A0Section=C2=A03.3

                                          [RFC6749]) that the
                                      client is declaring that it may
                                      use when requesting access tokens.=E2=80=9D

                                

                                

                                  
to

                                

                                

                                  
=E2=80=9CSpace
                                      separated list of scope values (as
                                      described in OAuth 2.0=C2=A0Section=C2=A03.3

                                          [RFC6749]) that the
                                      client is declaring to the server
                                      that it may use when requesting
                                      access tokens and that the server
                                      is declaring to the client that it
                                      is registered to use when
                                      requesting access tokens.=E2=80=9D.

                                

                                

                                  
=C2=A0

                                

                                

                                  
Again,
                                      I chose the =E2=80=9Cregistered to us=
e=E2=80=9D
                                      language carefully =E2=80=93 because =
in
                                      the general case it=E2=80=99s not a
                                      restriction on the values that the
                                      client can use =E2=80=93 just a state=
ment
                                      by the server to the client that
                                      it is registered to use those
                                      particular values.=C2=A0 In both case=
s,
                                      the parties are making
                                      declarations to one another.

                                

                                

                                  
=C2=A0

                                

                                

                                  
If
                                      you adopt that language (or keep
                                      the original language), then yes,
                                      I=E2=80=99d consider this closed.

                                

                                

                                  
=C2=A0

                                

                                

                                  
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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

                                

                                

                                  
=C2=A0

                                

                                

                                  

                                    

                                      
From:=C2=A0Justin

                                          Richer [mailto:jricher@mitre.org]=C2=A0

                                          Sent:=C2=A0Mo=
nday,
                                          April 15, 2013 9:57 AM

                                          To:=C2=A0Mike
                                          Jones

                                          Cc:=C2=A0Tim
                                          Bray;=C2=A0oauth@ietf.org

                                          Subject:=C2=A0Re:
                                          [OAUTH-WG] Registration: Scope
                                          Values

                                    

                                  

                                

                                

                                  
=C2=A0

                                

                                
I
                                  absolutely do not want to delete this
                                  feature, as (having implemented it) I
                                  think it's very useful. This is a ver=
y
                                  established pattern in manual
                                  registration: I know of many, many
                                  OAuth2 servers and clients that are
                                  set up where the client must
                                  pre-register a set of scopes.=C2=A0=


                                  

                                  I don't like the language of "th=
e
                                  client is declaring" because it'=
s too
                                  one-sided. The client might not have
                                  declared anything, and it might be the
                                  server that's declaring something to
                                  the client. Deleting the "is
                                  declaring" bit removes that unintend=
ed
                                  restriction of the language while
                                  keeping the original meaning intact. I
                                  actually thought that I had fixed that
                                  before the last draft went in but
                                  apparently I missed this one.

                                  

                                  I will work on clarifying the intent
                                  of the whole metadata set in its
                                  introductory paragraph(s) so that it'=
s
                                  clear that all of these fields are
                                  used in both of these situations:

                                  

                                  =C2=A01) The client declaring to the serv=
er
                                  its desire to use a particular value

                                  =C2=A02) The server declaring to the clie=
nt
                                  that it has been registered with a
                                  particular value

                                  

                                  This should hopefully clear up the
                                  issue in the editor's note that I
                                  currently have at the top of that
                                  section right now, too.

                                  

                                  Mike, since you were the one who
                                  originally brought up the issue, and
                                  you're fine with the existing text,
                                  can I take this as closed now?
                                  Assuming that you agree with deleting
                                  "is declaring" for reasons stat=
ed
                                  above, I'm fine with leaving
                                  everything else as is and staying
                                  quiet on what the server has to do
                                  with the scopes.

                                  

                                  =C2=A0-- Justin

                                

                                  

                                    
On 04/15/2013
                                      12:44 PM, Mike Jones wrote:=


                                  

                                

                                

                                  

                                    
I
                                        think that the existing wording
                                        is superior to the proposed
                                        changed wording.=C2=A0 The existing
                                        wording is:
                                  

                                  

                                    
=C2=A0

                                  

                                  

                                    
=C2=A0=C2=A0 scope

                                  

                                  

                                    
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 OPTIONAL.=C2=A0 Space
                                        separated list of scope values
                                        (as described in

                                  

                                  

                                    
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 OAuth 2.0=C2=A0Section=C2=A03.3

                                            [RFC6749]) that
                                        the client is declaring that=


                                  

                                  

                                    
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 it may use when
                                        requesting access tokens.=C2=A0 If
                                        omitted, an
                                  

                                  

                                    
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Authorization
                                        Server MAY register a Client
                                        with a default set of=


                                  

                                  

                                    
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 scopes.

                                  

                                  

                                    
=C2=A0

                                  

                                  

                                    
For
                                        instance, the current =E2=80=9Cclie=
nt is
                                        declaring=E2=80=9D wording will alw=
ays
                                        be correct, whereas as the
                                        change to =E2=80=9Cclient can use=
=E2=80=9D
                                        wording implies a restriction on
                                        client behavior that is not
                                        always applicable.=C2=A0 The =E2=80=
=9Cclient
                                        is declaring=E2=80=9D wording was
                                        specific and purposefully
                                        chosen, and I think should be
                                        retained.=C2=A0 In particular, we
                                        can=E2=80=99t do anything that impl=
ies
                                        that only the registered scopes
                                        values can be used.=C2=A0 At the
                                        OAuth spec level, this is a hint
                                        as to possible future client
                                        behavior =E2=80=93 not a restrictio=
n on
                                        future client behavior.

                                  

                                  

                                    
=C2=A0

                                  

                                  

                                    
Also,
                                        for the reasons that Tim stated,
                                        I=E2=80=99m strongly against any
                                        =E2=80=9Cmatching=E2=80=9D or =E2=
=80=9Cregex=E2=80=9D language
                                        in the spec pertaining to scopes
                                        =E2=80=93 as it=E2=80=99s not actio=
nable.

                                  

                                  

                                    
=C2=A0

                                  

                                  

                                    
So
                                        I=E2=80=99d propose that we leave t=
he
                                        existing scope wording in
                                        place.=C2=A0 Alternatively, I=E2=80=
=99d also
                                        be fine with deleting this
                                        feature entirely, as I don=E2=80=99=
t
                                        think it=E2=80=99s useful in the ge=
neral
                                        case.

                                  

                                  

                                    
=C2=A0

                                  

                                  

                                    
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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

                                  

                                  

                                    
=C2=A0

                                  

                                  

                                    

                                      

                                        
From:=C2=A0oauth-bounces@ietf.org=C2=A0[mailto:oauth-bounces@ietf.org]=
On

                                              Behalf Of=C2=A0<=
/b>Justin
                                            Richer

                                            Sent:=C2=A0=
Monday,
                                            April 15, 2013 8:05 AM

                                            To:=C2=A0Ti=
m
                                            Bray;=C2=A0oauth@ietf.org

                                            Subject:=C2=A0Re:
                                            [OAUTH-WG] Registration:
                                            Scope Values

                                      

                                    

                                  

                                  

                                    
=C2=A0=


                                  

                                  
On
                                    04/15/2013 10:52 AM, Tim Bray wrote:
                                    

                                    

                                    

                                  

                                    

                                      
I=E2=80=99d us=
e the
                                        existing wording; it=E2=80=99s perf=
ectly
                                        clear. =C2=A0Failing that, if there=
=E2=80=99s
                                        strong demand for registration
                                        of structured scopes, bless the
                                        use of regexes, either PCREs or
                                        some careful subset.<=
/p>
                                    

                                  

                                  


                                    Thanks for the feedback -- Of these
                                    two choices, I'd rather leave it
                                    as-is.=C2=A0

                                    

                                    

                                    

                                    

                                  

                                    

                                      

                                        
=C2=A0

                                      

                                    

                                    

                                      

                                        
However,
                                          I=E2=80=99d subtract the sentence=
 =E2=80=9CIf
                                          omitted, an Authorization
                                          Server MAY register a Client
                                          with a default set of
                                          =C2=A0scopes.=E2=80=9D =C2=A0It a=
dds no value;
                                          if the client doesn=E2=80=99t dec=
lare
                                          scopes, the client doesn=E2=80=99=
t
                                          declare scopes, that=E2=80=99s al=
l.
                                          =C2=A0-T

                                      

                                    

                                  

                                  


                                    Remember, all of these fields aren'=
t
                                    just for the client *request*,
                                    they're also for the server's
                                    *response* to either a POST, PUT, or
                                    GET request. (I didn't realize it,
                                    but perhaps the wording as stated
                                    right now doesn't make that clear -=
-
                                    I need to fix that.) The value that
                                    it adds is if the client doesn't as=
k
                                    for any particular scopes, the
                                    server can still assign it scopes
                                    and the client can do something
                                    smart with that. Dumb clients are
                                    allowed to ignore it if it doesn't
                                    mean anything to them.=C2=A0

                                    

                                    This is how our server
                                    implementation actually works right
                                    now. If the client doesn't ask for
                                    anything specific at registration,
                                    the server hands it a bag of
                                    "default" scopes. Same thing =
happens
                                    at auth time -- if the client
                                    doesn't ask for any particular
                                    scopes, the server hands it all of
                                    its registered scopes as a default.
                                    Granted, on our server, scopes are
                                    just simple strings right now, so
                                    they get compared at the auth
                                    endpoint with an exact string-match
                                    metric and set-based logic.=C2=A0=


                                    

                                    =C2=A0-- Justin

                                    

                                    

                                    

                                    

                                  

                                    
=C2=A0

                                    

                                      

                                        
On Mon, Apr
                                          15, 2013 at 7:35 AM, Justin
                                          Richer <jricher@mitre.org>
                                          wrote:

                                      

                                      

                                        

                                          
What
                                            would you suggest for
                                            wording here, then? Keeping
                                            in mind that we cannot (and
                                            don't want to) prohibit
                                            expression-based scopes.=
=C2=A0

                                            <=
br>
                                              =C2=A0-- Justin=


                                        

                                        

                                          
=C2=A0

                                          

                                            

                                              
On
                                                04/15/2013 10:33 AM, Tim
                                                Bray wrote:
                                            

                                          

                                          

                                            

                                              

                                                
No,
                                                  I mean it=E2=80=99s not
                                                  interoperable at the
                                                  software-developer
                                                  level. =C2=A0I can=E2=80=
=99t
                                                  register scopes at
                                                  authorization time
                                                  with any predictable
                                                  effect that I can
                                                  write code to support,
                                                  either client or
                                                  server side, without
                                                  out-of-line
                                                  non-interoperable
                                                  knowledge about the
                                                  behavior of the
                                                  server. =C2=A0<=
/u>

                                              

                                              

                                                

                                                  
=
=C2=A0

                                                

                                              

                                              

                                                

                                                  
I
                                                    guess I=E2=80=99m just =
not
                                                    used to OAuth=E2=80=99s
                                                    culture of having no
                                                    expectation that
                                                    things will be
                                                    specified tightly
                                                    enough that I can
                                                    write code to
                                                    implement as
                                                    specified. =C2=A0-T<=
/u>

                                                

                                              

                                            

                                            

                                              
=C2=A0

                                              

                                                

                                                  
On
                                                    Mon, Apr 15, 2013 at
                                                    7:15 AM, Justin
                                                    Richer <jricher@mitre.org>
                                                    wrote:
                                                

                                                

                                                  

                                                    
=
Scopes
                                                      aren't meant to b=
e
                                                      interoperable
                                                      between services
                                                      since they're
                                                      necessarily
                                                      API-specific. The
                                                      only interoperable
                                                      bit is that
                                                      there's *some*
                                                      place to put the
                                                      values and that
                                                      it's expressed as
                                                      a bag of
                                                      space-separated
                                                      strings. How those
                                                      strings get
                                                      interpreted and
                                                      enforced (which is
                                                      really what's at
                                                      stake here) is up
                                                      to the AS and PR
                                                      (or a higher-level
                                                      protocol like
                                                      UMA).

                                                        

                                                        =C2=A0-- Justin

                                                  

                                                  

                                                    
=C2=A0

                                                    

                                                      

                                                        
On
                                                          04/15/2013
                                                          10:13 AM, Tim
                                                          Bray wrote:

                                                      

                                                    

                                                    

                                                      
This, as
                                                        written, has
                                                        zero
                                                        interoperability.=
=C2=A0
                                                        I think this
                                                        feature can
                                                        really only be
                                                        made useful in
                                                        the case where
                                                        scopes are fixed
                                                        strings.<=
/u>

                                                      
-T
                                                      

                                                        

                                                          
On
                                                          Apr 15, 2013
                                                          6:54 AM,
                                                          "Justin
                                                          Richer" <=
jricher@mitre.org> wrote:=





                                                        

                                                        

                                                          
You are correct that the idea behind t=
he
                                                          "scope"
                                                          parameter at
                                                          registration
                                                          is a
                                                          constraint on
                                                          authorization-tim=
e
                                                          scopes that
                                                          are made
                                                          available.
                                                          It's both a
                                                          means for the
                                                          client to
                                                          request a set
                                                          of valid
                                                          scopes and for
                                                          the server to
                                                          provision (and
                                                          echo back to
                                                          the client) a
                                                          set of valid
                                                          scopes.

                                                          

                                                          I *really*
                                                          don't want to
                                                          try to define
                                                          a matching
                                                          language for
                                                          scope
                                                          expressions.
                                                          For that to
                                                          work, all
                                                          servers would
                                                          need to be
                                                          able to
                                                          process the
                                                          regular
                                                          expressions
                                                          for all
                                                          clients, even
                                                          if the servers
                                                          themselves
                                                          only support
                                                          simple-string
                                                          scope values.
                                                          Any regular
                                                          expression
                                                          syntax we pick
                                                          here is
                                                          guaranteed to
                                                          be
                                                          incompatible
                                                          with
                                                          something, and
                                                          I think the
                                                          complexity
                                                          doesn't buy
                                                          much. Also, I
                                                          think you
                                                          suddenly have
                                                          a potential
                                                          security issue
                                                          if you have a
                                                          bad regex in
                                                          place on
                                                          either end.=
=C2=A0

                                                          

                                                          As it stands
                                                          today, the
                                                          server can
                                                          interpret the
                                                          incoming
                                                          registration
                                                          scopes and
                                                          enforce them
                                                          however it
                                                          wants to. The
                                                          real trick
                                                          comes not from
                                                          assigning the
                                                          values to a
                                                          particular
                                                          client but to
                                                          enforcing
                                                          them, and I
                                                          think that's
                                                          always going
                                                          to be
                                                          service-specific.
                                                          We're just no=
t
                                                          as clear on
                                                          that as we
                                                          could be.

                                                          

                                                          After looking
                                                          over
                                                          everyone's
                                                          comments so
                                                          far, I'd like
                                                          to propose the
                                                          following text
                                                          for that
                                                          section:

                                                          

                                                          

                                                          
                                                          
=C2=A0=C2=A0=
 scope

                                                          
=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 OPTIONAL.=C2=A0 Space separated list of scope values (as=
 described in

                                                          
=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 OAuth 2.0 Section=C2=A03.3 [RFC6749]) that the client can use when 




                                                          
=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0requesting access tokens.=C2=A0 As scope values are=
 service-specific, 

                                                          
=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0the Authorization Server MAY define its own matchin=
g rules when

                                                          
=C2=A0=C2=A0=
=C2=A0=C2=A0 =C2=A0determining if a scope value used during an authorizatio=
n request

                                                          
=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 is valid according to the scope values assigned during <=
u>

                                                          
=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0registration. Possible matching rules include wildc=
ard patterns,

                                                          
=C2=A0=C2=A0=
=C2=A0=C2=A0 =C2=A0regular expressions, or exactly matching the string. If =
omitted, 

                                                          
=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0an Authorization Server MAY register a Client with =
a default 

                                                          
=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0set of scopes.

                                                          


                                                          Comments?
                                                          Improvements?

                                                          

                                                          =C2=A0-- Justin
                                                          

                                                          

                                                          
                                                          

                                                          

                                                          
On
                                                          04/14/2013
                                                          08:23 PM,
                                                          Manger, James
                                                          H wrote:

                                                          

                                                          

                                                          

                                                          
Presumably a=
t app registration time any scope specification is really a constraint on t=
he scope values that can be requested in an authorization flow.




                                                          
=C2=A0

                                                          
So ideally r=
egistration should accept rules for matching scopes, as opposed to actual s=
cope values.

                                                          
=C2=A0

                                                          
You can try =
to use scope values as their own matching rules. That is fine for a small s=
et of "static" scopes. It starts to fail when there are a large n=
umber of scopes, or scopes that can include parameters (resource paths? ema=
il addresses?). You can try to patch those failures by allowing services to=
 define service-specific special "wildcard" scope values that can=
 only be used during registration (eg "read:*").



                                                          
=C2=A0

                                                          
Alternativel=
y, replace 'scope' in registration with 'scope_regex' that =
holds a regular expression that all scope values in an authorization flow m=
ust match.




                                                          
=C2=A0

                                                          
--=


                                                          
James Manger=


                                                          
____________=
___________________________________

                                                          
OAuth mailin=
g list

                                                          
OAuth@ietf.org

                                                          
https://www.ietf.org/mailman/listinfo/oaut=
h




                                                          

                                                          

                                                          
=C2=A0

                                                          

                                                        

                                                        


_______________________________________________

                                                          OAuth mailing
                                                          list

                                                          OAuth@ietf.org

                                                          <=
span style=3D"color:purple">https://www.ietf.org/mailman/listinfo/oauth




                                                      

                                                    

                                                    

                                                      
=C2=A0

                                                    

                                                  

                                                

                                              

                                              

                                                
=C2=
=A0

                                              

                                            

                                          

                                          

                                            
=C2=A0

                                          

                                        

                                      

                                    

                                    

                                      
=C2=A0<=
u>

                                    

                                  

                                  

                                    
=C2=A0=


                                  

                                

                                

                                  
=C2=A0

                                

                              

                              

                                
=C2=A0=


                              

                            

                          

                        

                        

                          
=C2=A0

                        

                      

                    

                  

                

                

                  
=C2=A0

                

              

              
_______________________=
________________________

                  OAuth mailing list

                  OAuth@ietf.org

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

            

          

          
=C2=A0

        

      

    

    

  






--bcaec51867784d0f0204daa655b2--

From jricher@mitre.org  Thu Apr 18 10:59:53 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC58421F87B7 for ; Thu, 18 Apr 2013 10:59:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.944
X-Spam-Level: 
X-Spam-Status: No, score=-5.944 tagged_above=-999 required=5 tests=[AWL=-0.546, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, J_CHICKENPOX_26=0.6, 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 ujqRmBUcWerx for ; Thu, 18 Apr 2013 10:59:44 -0700 (PDT)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 214E021F9022 for ; Thu, 18 Apr 2013 10:59:44 -0700 (PDT)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id BB1941F058A; Thu, 18 Apr 2013 13:59:43 -0400 (EDT)
Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id A04741F0585; Thu, 18 Apr 2013 13:59:43 -0400 (EDT)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.342.3; Thu, 18 Apr 2013 13:59:43 -0400
Message-ID: <51703483.6060009@mitre.org>
Date: Thu, 18 Apr 2013 13:59:31 -0400
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130329 Thunderbird/17.0.5
MIME-Version: 1.0
To: Mike Jones 
References: <255B9BB34FB7D647A506DC292726F6E1150C74DADA@WSMSG3153V.srv.dir.telstra.com> <516C1714.8070503@mitre.org> <4E1F6AAD24975D4BA5B168042967394367641A87@TK5EX14MBXC283.redmond.corp.microsoft.com> <516C3152.9070603@mitre.org> <4E1F6AAD24975D4BA5B168042967394367641FAB@TK5EX14MBXC283.redmond.corp.microsoft.com> <516C54F2.8040708@mitre.org> <4E1F6AAD24975D4BA5B16804296739436766BCC4@TK5EX14MBXC284.redmond.corp.microsoft.com>  <4E1F6AAD24975D4BA5B16804296739436766C964@TK5EX14MBXC284.redmond.corp.microsoft.com>    <4E1F6AAD24975D4BA5B16804296739436766D8B9@TK5EX14MBXC284.redmond.corp.microsoft.com> <5170319A.5080903@mitre.org> <4E1F6AAD24975D4BA5B16804296739436766EDB1@TK5EX14MBXC284.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436766EDB1@TK5EX14MBXC284.redmond.corp.microsoft.com>
Content-Type: multipart/alternative; boundary="------------070409060707000302030606"
X-Originating-IP: [129.83.31.58]
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: Scope Values
X-BeenThere: oauth@ietf.org
X-Mailman-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, 18 Apr 2013 17:59:53 -0000

--------------070409060707000302030606
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

I would be fine with that addendum.

  -- Justin

On 04/18/2013 01:52 PM, Mike Jones wrote:
>
> I could live with it if you expanded the text slightly as follows.  
> Otherwise people will keep asking questions that they deserve an 
> answer to, even if the answer is "see the service documentation".
>
> Space-separated list of scope values (as described in OAuth 2.0 
> Section 3.3 [RFC6749] 
> ) that the Client can 
> use when requesting access tokens from the Authorization Server.  The 
> semantics of this list are service specific.
>
> -- Mike
>
> *From:*Justin Richer [mailto:jricher@mitre.org]
> *Sent:* Thursday, April 18, 2013 10:47 AM
> *To:* Mike Jones
> *Cc:* Anthony Nadalin; Tim Bray; oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] Registration: Scope Values
>
> Thing is, there's nothing normative about the enforcing statement that 
> I made below, so I don't think it's any more restrictive than RFC 6749 
> which lets the AS replace a client's requested scopes at the time of 
> token issuance with whatever it pleases. But that said, I'd be just as 
> happy to leave it like this with no further restrictions:
>
> Space-separated list of scope values (as described in OAuth 2.0 
> Section 3.3 [RFC6749] 
> ) that the Client can 
> use when requesting access tokens from the Authorization Server.
>
> And call it a day. This parallels the text for grant_types ("Array of 
> OAuth 2.0 grant types that the Client may use [when accessing the 
> Token Endpoint].") and response_types ("Array of the OAuth 2.0 
> response types that the Client may use [when accessing the 
> Authorization Endpoint]."), and I think this is the correct approach. 
> I only started to add the restrictive text because I thought that 
> people were making the argument that it was necessary -- I'd rather 
> not have it.
>
>   
>
> Plus, it's an optional field in the metadata, so if you've got 
> structured scopes where this doesn't make sense, don't use it. If you 
> don't do a per-client scope restriction, don't use it.
>
> The interoperability is defined in light of the interoperability of 
> scopes themselves: this is a field to request/grant a bag of strings 
> that only make sense in light of a given API. For that to make real 
> sense, I think that we need to differentiate an OAuth client as a 
> generic *library* from an OAuth client as a generic accessing 
> *application*. It's very useful for a generic *library* that handles 
> the authorization layer for an application to have a slot for 
> registering scopes and finding out what scopes the app's been 
> registered for. It's up to the app (not the library) to figure out how 
> to translate those into scopes to ask for at authorization time. 
> Sometimes that means just passing the string, and sometimes it means 
> the construction of a structured value like 
> "urn:example:channel=HBO&urn:example:rating=G,PG-13". The library 
> doesn't care, the application does, and we should focus on 
> interoperability from the library's perspective. Similarly, on the 
> server side, the libraries will tell you the bag of scopes that the 
> client was registered for, and what bag of scopes the client asked for 
> during authorization. It's up to the server *application* to harmonize 
> those two in a way that makes sense for the API that it's protecting. 
> Just like it's up to the protected resource *application* to figure 
> out what a scope means in a given context.
>
> So let's just leave it unrestricted but keep the slot for 
> communicating this piece of information with the same semantics that 
> the communication between the client and server take on for every 
> other field: client asks for a thing, server says that client actually 
> gets a thing, and it's implicitly up to the server to do the right 
> thing and enforce things in a way that makes sense for the application 
> no matter what the client does.
>
> To take Tony's example, client requests no scopes at registration, 
> server grants scope "A" at registration. Client then requests scope 
> "X" at authorization, server is free to deny the request 
> (invalid_scope error), allow authorization because it knows how "A" 
> and "X" are related, require user intervention, or really, whatever it 
> likes. The libraries, where I argue the interoperability cries really 
> matter, don't care, and shouldn't care.
>
>  -- Justin
>
> On 04/18/2013 01:04 PM, Mike Jones wrote:
>
>     Saying anything normative about "enforcing restrictions" is going
>     beyond RFC 6749 semantics.  Indeed, you'd said that "I agree that
>     we shouldn't try to "solve" scope in registration.", but talking
>     about restrictions is going down the slippery "solving it" path.
>
>     At most we can say that the two parties are making declarations to
>     one another about scopes that they may choose to use, but we can't
>     assume that this is an exclusive list and that other scope values
>     such as "urn:example:channel=HBO&urn:example:rating=G,PG-13" might
>     not be used, even if the client registers saying that it intends
>     to use the "OATC" scope value.  We could maybe even say that some
>     services may use a static set of scopes and might choose to limit
>     the scopes that a client may use to those that it declared to the
>     server or to those that the server returned to the client.  That's
>     a HINT that some services might do this.  But we can't say
>     anything normative about such possible behaviors, because it goes
>     beyond RFC 6749.
>
>     -- Mike
>
>     *From:*Richer, Justin P. [mailto:jricher@mitre.org]
>     *Sent:* Thursday, April 18, 2013 9:26 AM
>     *To:* Anthony Nadalin
>     *Cc:* Tim Bray; Mike Jones; oauth@ietf.org 
>     *Subject:* Re: [OAUTH-WG] Registration: Scope Values
>
>     This doesn't actually break the semantics because the client MUST
>     accept what the server tells it over anything that it asks for in
>     the first place. The server has the final say. So in this case, if
>     your client asks for nothing, the server says "A B C", the client
>     now knows it can ask for "A B C" scopes.
>
>     I'm still in favor of not putting the restricting language in the
>     scope definition at all, instead have it say something like:
>
>         "Space-separated list of scope values (as described in OAuth
>         2.0 Section 3.3 [RFC6749]
>         ) that the
>         Client can use when requesting access tokens from the
>         Authorization Server. As scope values are service specific,
>         the means of the Authorization Server enforcing this
>         restriction are outside the scope of this specification."
>
>     Couple this with the overall paragraph that says that the client
>     is requesting values that the server is potentially overriding
>     with its declarations, and I think that addresses everything
>     without getting into confusing language that doesn't add to
>     interoperability.
>
>      -- Justin
>
>     On Apr 18, 2013, at 12:13 PM, Anthony Nadalin
>     > wrote:
>
>
>
>
>     If I don't specify a scope, then the server can allocate a default
>     (or default set), thus that breaks the semantics you describe
>
>     *From:*oauth-bounces@ietf.org 
>     [mailto:oauth-bounces@ietf.org ]*On
>     Behalf Of*Tim Bray
>     *Sent:*Thursday, April 18, 2013 9:04 AM
>     *To:*Mike Jones
>     *Cc:*oauth@ietf.org 
>     *Subject:*Re: [OAUTH-WG] Registration: Scope Values
>
>     I'm unconvinced, Mike.  Obviously you're right about the looseness
>     of OAuth2 scope specification, but this is a very specific
>     semantic of what happens when you register, and I don't think
>     we're bound by history here.   If we can't safely say anything
>     about what the list of scopes means, then I'm with you let's take
>     them out.  But the most obvious intended semantic is (from the
>     client) "I promise to ask only for these" and from the server
>     "These are the only ones I'll give you tokens for."  Or does
>     someone have use-cases for an alternative semantic?
>
>     To make this concrete, I propose the following:
>
>     "Space-separated list of scope values (as described in OAuth 2.0
>     Section 3.3 [RFC6749]
>     ) that the client
>     is declaring to the server that it will restrict itself to when
>     requesting access tokens, and that the server is declaring to the
>     client that it is registered to use when requesting access tokens.
>     Clients SHOULD assume that servers will refuse to grant access
>     tokens for scopes not in the list provided by the server."
>
>     On Thu, Apr 18, 2013 at 8:55 AM, Mike Jones
>     >
>     wrote:
>
>         I don't think it's possible to define what it means in an
>         interoperable way because OAuth didn't specify scopes in an
>         interoperable way.  No, I don't like that either, but I think
>         that's where things are.  That's why I was advocating deleting
>         this registration feature entirely.
>
>         But understanding it might be useful in some contexts, I'm OK
>         keeping it, provided we be clear that the semantics of
>         "registered to use" are service-specific.
>
>         -- Mike
>
>         *From:*Tim Bray [mailto:twbray@google.com
>         ]
>         *Sent:*Thursday, April 18, 2013 8:36 AM
>         *To:*Mike Jones
>         *Cc:*Justin Richer;oauth@ietf.org 
>
>
>         *Subject:*Re: [OAUTH-WG] Registration: Scope Values
>
>         On the server-to-client side, what does "registered to use"
>         mean?  Does it mean that the client should assume that any
>         scopes not on the list WILL not be granted, MAY not be
>         granted.... or what?  Is this already covered elsewhere? -T
>
>         On Thu, Apr 18, 2013 at 8:28 AM, Mike Jones
>                  > wrote:
>
>         Thanks, Justin.  I agree with the need for the generic
>         two-sided language.  I'd still keep this language for scope,
>         because we want to capture the "declaring" aspect in this case:
>
>         "Space separated list of scope values (as described in OAuth
>         2.0Section 3.3 [RFC6749]
>         ) that the
>         client is declaring to the server that it may use when
>         requesting access tokens and that the server is declaring to
>         the client that it is registered to use when requesting access
>         tokens.".
>
>         You should probably also reinforce that scope values are
>         service-specific and may not consist only of a static set of
>         string values, and that therefore, in some cases, an
>         exhaustive list of registered scope values is not possible.
>
>         -- Mike
>
>         *From:*Justin Richer [mailto:jricher@mitre.org
>         ]
>         *Sent:*Monday, April 15, 2013 12:29 PM
>
>
>         *To:*Mike Jones
>         *Cc:*Tim Bray;oauth@ietf.org 
>         *Subject:*Re: [OAUTH-WG] Registration: Scope Values
>
>         I think that because the "declaration" issue affects all
>         parameters in the list, not just scope, we should adopt this
>         in a higher level paragraph and leave it out of the individual
>         parameter descriptions. Thus, something like this inserted as
>         the second paragraph in section 2:
>
>         The client metadata values serve two parallel purposes in the
>         overall OAuth Dynamic Registration protocol:
>
>          - the Client requesting its desired values for each parameter
>         to the Authorization Server in a [register] or [update] request,
>          - the Authorization Server informing the Client of the
>         current values of each parameter that the Client has been
>         registered to use through a [client information response].
>
>         An Authorization Server MAY override any value that a Client
>         requests during the registration process (including any
>         omitted values) and replace the requested value with a
>         default. The normative indications in the following list apply
>         to the Client's declaration of its desired values.
>
>         The Authorization Server SHOULD provide documentation for any
>         fields that it requires to be filled in by the client or to
>         have particular values or formats. Extensions and profiles...
>
>
>         And then remove the sidedness-language from the scope
>         parameter and any other parameters where it might have crept
>         in inadvertently.
>
>          -- Justin
>
>         On 04/15/2013 01:29 PM, Mike Jones wrote:
>
>             We could fix the one-sided language by changing
>
>             "Space separated list of scope values (as described in
>             OAuth 2.0Section 3.3 [RFC6749]
>             ) that the
>             client is declaring that it may use when requesting access
>             tokens."
>
>             to
>
>             "Space separated list of scope values (as described in
>             OAuth 2.0Section 3.3 [RFC6749]
>             ) that the
>             client is declaring to the server that it may use when
>             requesting access tokens and that the server is declaring
>             to the client that it is registered to use when requesting
>             access tokens.".
>
>             Again, I chose the "registered to use" language carefully
>             -- because in the general case it's not a restriction on
>             the values that the client can use -- just a statement by
>             the server to the client that it is registered to use
>             those particular values.  In both cases, the parties are
>             making declarations to one another.
>
>             If you adopt that language (or keep the original
>             language), then yes, I'd consider this closed.
>
>             -- Mike
>
>             *From:*Justin Richer [mailto:jricher@mitre.org]
>             *Sent:*Monday, April 15, 2013 9:57 AM
>             *To:*Mike Jones
>             *Cc:*Tim Bray;oauth@ietf.org 
>             *Subject:*Re: [OAUTH-WG] Registration: Scope Values
>
>             I absolutely do not want to delete this feature, as
>             (having implemented it) I think it's very useful. This is
>             a very established pattern in manual registration: I know
>             of many, many OAuth2 servers and clients that are set up
>             where the client must pre-register a set of scopes.
>
>             I don't like the language of "the client is declaring"
>             because it's too one-sided. The client might not have
>             declared anything, and it might be the server that's
>             declaring something to the client. Deleting the "is
>             declaring" bit removes that unintended restriction of the
>             language while keeping the original meaning intact. I
>             actually thought that I had fixed that before the last
>             draft went in but apparently I missed this one.
>
>             I will work on clarifying the intent of the whole metadata
>             set in its introductory paragraph(s) so that it's clear
>             that all of these fields are used in both of these situations:
>
>              1) The client declaring to the server its desire to use a
>             particular value
>              2) The server declaring to the client that it has been
>             registered with a particular value
>
>             This should hopefully clear up the issue in the editor's
>             note that I currently have at the top of that section
>             right now, too.
>
>             Mike, since you were the one who originally brought up the
>             issue, and you're fine with the existing text, can I take
>             this as closed now? Assuming that you agree with deleting
>             "is declaring" for reasons stated above, I'm fine with
>             leaving everything else as is and staying quiet on what
>             the server has to do with the scopes.
>
>              -- Justin
>
>             On 04/15/2013 12:44 PM, Mike Jones wrote:
>
>                 I think that the existing wording is superior to the
>                 proposed changed wording.  The existing wording is:
>
>                    scope
>
>                       OPTIONAL. Space separated list of scope values
>                 (as described in
>
>                       OAuth 2.0Section 3.3 [RFC6749]
>                 ) that
>                 the client is declaring that
>
>                       it may use when requesting access tokens.  If
>                 omitted, an
>
>                       Authorization Server MAY register a Client with
>                 a default set of
>
>                       scopes.
>
>                 For instance, the current "client is declaring"
>                 wording will always be correct, whereas as the change
>                 to "client can use" wording implies a restriction on
>                 client behavior that is not always applicable.  The
>                 "client is declaring" wording was specific and
>                 purposefully chosen, and I think should be retained. 
>                 In particular, we can't do anything that implies that
>                 only the registered scopes values can be used.  At the
>                 OAuth spec level, this is a hint as to possible future
>                 client behavior -- not a restriction on future client
>                 behavior.
>
>                 Also, for the reasons that Tim stated, I'm strongly
>                 against any "matching" or "regex" language in the spec
>                 pertaining to scopes -- as it's not actionable.
>
>                 So I'd propose that we leave the existing scope
>                 wording in place.  Alternatively, I'd also be fine
>                 with deleting this feature entirely, as I don't think
>                 it's useful in the general case.
>
>                 -- Mike
>
>                 *From:*oauth-bounces@ietf.org
>                 [mailto:oauth-bounces@ietf.org]*On
>                 Behalf Of*Justin Richer
>                 *Sent:*Monday, April 15, 2013 8:05 AM
>                 *To:*Tim Bray;oauth@ietf.org 
>                 *Subject:*Re: [OAUTH-WG] Registration: Scope Values
>
>                 On 04/15/2013 10:52 AM, Tim Bray wrote:
>
>
>
>                 I'd use the existing wording; it's perfectly clear.
>                  Failing that, if there's strong demand for
>                 registration of structured scopes, bless the use of
>                 regexes, either PCREs or some careful subset.
>
>
>                 Thanks for the feedback -- Of these two choices, I'd
>                 rather leave it as-is.
>
>
>
>
>                 However, I'd subtract the sentence "If omitted, an
>                 Authorization Server MAY register a Client with a
>                 default set of  scopes."  It adds no value; if the
>                 client doesn't declare scopes, the client doesn't
>                 declare scopes, that's all.  -T
>
>
>                 Remember, all of these fields aren't just for the
>                 client *request*, they're also for the server's
>                 *response* to either a POST, PUT, or GET request. (I
>                 didn't realize it, but perhaps the wording as stated
>                 right now doesn't make that clear -- I need to fix
>                 that.) The value that it adds is if the client doesn't
>                 ask for any particular scopes, the server can still
>                 assign it scopes and the client can do something smart
>                 with that. Dumb clients are allowed to ignore it if it
>                 doesn't mean anything to them.
>
>                 This is how our server implementation actually works
>                 right now. If the client doesn't ask for anything
>                 specific at registration, the server hands it a bag of
>                 "default" scopes. Same thing happens at auth time --
>                 if the client doesn't ask for any particular scopes,
>                 the server hands it all of its registered scopes as a
>                 default. Granted, on our server, scopes are just
>                 simple strings right now, so they get compared at the
>                 auth endpoint with an exact string-match metric and
>                 set-based logic.
>
>                  -- Justin
>
>
>
>
>                 On Mon, Apr 15, 2013 at 7:35 AM, Justin Richer
>                 > wrote:
>
>                 What would you suggest for wording here, then? Keeping
>                 in mind that we cannot (and don't want to) prohibit
>                 expression-based scopes.
>
>                  -- Justin
>
>                 On 04/15/2013 10:33 AM, Tim Bray wrote:
>
>                     No, I mean it's not interoperable at the
>                     software-developer level.  I can't register scopes
>                     at authorization time with any predictable effect
>                     that I can write code to support, either client or
>                     server side, without out-of-line non-interoperable
>                     knowledge about the behavior of the server.
>
>                     I guess I'm just not used to OAuth's culture of
>                     having no expectation that things will be
>                     specified tightly enough that I can write code to
>                     implement as specified.  -T
>
>                     On Mon, Apr 15, 2013 at 7:15 AM, Justin Richer
>                     > wrote:
>
>                     Scopes aren't meant to be interoperable between
>                     services since they're necessarily API-specific.
>                     The only interoperable bit is that there's *some*
>                     place to put the values and that it's expressed as
>                     a bag of space-separated strings. How those
>                     strings get interpreted and enforced (which is
>                     really what's at stake here) is up to the AS and
>                     PR (or a higher-level protocol like UMA).
>
>                      -- Justin
>
>                     On 04/15/2013 10:13 AM, Tim Bray wrote:
>
>                         This, as written, has zero interoperability. I
>                         think this feature can really only be made
>                         useful in the case where scopes are fixed strings.
>
>                         -T
>
>                         On Apr 15, 2013 6:54 AM, "Justin Richer"
>                         >
>                         wrote:
>
>                         You are correct that the idea behind the
>                         "scope" parameter at registration is a
>                         constraint on authorization-time scopes that
>                         are made available. It's both a means for the
>                         client to request a set of valid scopes and
>                         for the server to provision (and echo back to
>                         the client) a set of valid scopes.
>
>                         I *really* don't want to try to define a
>                         matching language for scope expressions. For
>                         that to work, all servers would need to be
>                         able to process the regular expressions for
>                         all clients, even if the servers themselves
>                         only support simple-string scope values. Any
>                         regular expression syntax we pick here is
>                         guaranteed to be incompatible with something,
>                         and I think the complexity doesn't buy much.
>                         Also, I think you suddenly have a potential
>                         security issue if you have a bad regex in
>                         place on either end.
>
>                         As it stands today, the server can interpret
>                         the incoming registration scopes and enforce
>                         them however it wants to. The real trick comes
>                         not from assigning the values to a particular
>                         client but to enforcing them, and I think
>                         that's always going to be service-specific.
>                         We're just not as clear on that as we could be.
>
>                         After looking over everyone's comments so far,
>                         I'd like to propose the following text for
>                         that section:
>
>
>
>                             scope
>
>                                OPTIONAL.  Space separated list of scope values (as described in
>
>                                OAuth 2.0Section 3.3 [RFC6749]  ) that the client can use when
>
>                                requesting access tokens.  As scope values are service-specific,
>
>                                the Authorization Server MAY define its own matching rules when
>
>                                determining if a scope value used during an authorization request
>
>                                is valid according to the scope values assigned during
>
>                                registration. Possible matching rules include wildcard patterns,
>
>                                regular expressions, or exactly matching the string. If omitted,
>
>                                an Authorization Server MAY register a Client with a default
>
>                                set of scopes.
>
>
>                         Comments? Improvements?
>
>                          -- Justin
>
>
>
>                         On 04/14/2013 08:23 PM, Manger, James H wrote:
>
>                             Presumably at app registration time any scope specification is really a constraint on the scope values that can be requested in an authorization flow.
>
>                               
>
>                             So ideally registration should accept rules for matching scopes, as opposed to actual scope values.
>
>                               
>
>                             You can try to use scope values as their own matching rules. That is fine for a small set of "static" scopes. It starts to fail when there are a large number of scopes, or scopes that can include parameters (resource paths? email addresses?). You can try to patch those failures by allowing services to define service-specific special "wildcard" scope values that can only be used during registration (eg "read:*").
>
>                               
>
>                             Alternatively, replace 'scope' in registration with 'scope_regex' that holds a regular expression that all scope values in an authorization flow must match.
>
>                               
>
>                             --
>
>                             James Manger
>
>                             _______________________________________________
>
>                             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
>


--------------070409060707000302030606
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit


  
    
  
  
    I would be fine with that addendum.

    

     -- Justin

    

    
On 04/18/2013 01:52 PM, Mike Jones
      wrote:

    

    

      
      
      
      

        
I
            could live with it if you expanded the text slightly as
            follows.  Otherwise people will keep asking questions that
            they deserve an answer to, even if the answer is “see the
            service documentation”.

        
 

        
Space-separated list
            of scope values (as described in OAuth 2.0 Section 3.3
                [RFC6749]) that the Client can use when
            requesting access tokens from the Authorization Server.  The
            semantics of this list are service specific.

            

          

        
                                                               
            -- Mike

        
 

        
 

        

          

            
From:
                Justin Richer [mailto:jricher@mitre.org]
                

                Sent: Thursday, April 18, 2013 10:47 AM

                To: Mike Jones

                Cc: Anthony Nadalin; Tim Bray; oauth@ietf.org

                Subject: Re: [OAUTH-WG] Registration: Scope
                Values

          

        

        
 

        
Thing is, there's nothing normative about
          the enforcing statement that I made below, so I don't think
          it's any more restrictive than RFC 6749 which lets the AS
          replace a client's requested scopes at the time of token
          issuance with whatever it pleases. But that said, I'd be just
          as happy to leave it like this with no further restrictions:

          

          Space-separated list
            of scope values (as described in OAuth 2.0 Section 3.3
                [RFC6749]) that the Client can use when
            requesting access tokens from the Authorization Server.

            

          And call it a day. This parallels the text for
          grant_types ("Array of OAuth 2.0 grant types that the Client
          may use [when accessing the Token Endpoint].") and
          response_types ("Array of the OAuth 2.0 response types that
          the Client may use [when accessing the Authorization
          Endpoint]."), and I think this is the correct approach. I only
          started to add the restrictive text because I thought that
          people were making the argument that it was necessary -- I'd
          rather not have it.

        
 

        
Plus, it's an
          optional field in the metadata, so if you've got structured
          scopes where this doesn't make sense, don't use it. If you
          don't do a per-client scope restriction, don't use it.
          

          

          The interoperability is defined in light of the
          interoperability of scopes themselves: this is a field to
          request/grant a bag of strings that only make sense in light
          of a given API. For that to make real sense, I think that we
          need to differentiate an OAuth client as a generic *library*
          from an OAuth client as a generic accessing *application*.
          It's very useful for a generic *library* that handles the
          authorization layer for an application to have a slot for
          registering scopes and finding out what scopes the app's been
          registered for. It's up to the app (not the library) to figure
          out how to translate those into scopes to ask for at
          authorization time. Sometimes that means just passing the
          string, and sometimes it means the construction of a
          structured value like "urn:example:channel=HBO&urn:example:rating=G,PG-13".
            The library doesn't care, the application does, and we
            should focus on interoperability from the library's
            perspective. Similarly, on the server side, the
          libraries will tell you the bag of scopes that the client was
          registered for, and what bag of scopes the client asked for
          during authorization. It's up to the server *application* to
          harmonize those two in a way that makes sense for the API that
          it's protecting. Just like it's up to the protected resource
          *application* to figure out what a scope means in a given
          context.

          

          So let's just leave it unrestricted but keep the slot for
          communicating this piece of information with the same
          semantics that the communication between the client and server
          take on for every other field: client asks for a thing, server
          says that client actually gets a thing, and it's implicitly up
          to the server to do the right thing and enforce things in a
          way that makes sense for the application no matter what the
          client does.
          

          

          To take Tony's example, client requests no scopes at
          registration, server grants scope "A" at registration. Client
          then requests scope "X" at authorization, server is free to
          deny the request (invalid_scope error), allow authorization
          because it knows how "A" and "X" are related, require user
          intervention, or really, whatever it likes. The libraries,
          where I argue the interoperability cries really matter, don't
          care, and shouldn't care.

          

           -- Justin

        

          
On 04/18/2013 01:04 PM, Mike Jones wrote:

        

        

          
Saying
              anything normative about “enforcing restrictions” is going
              beyond RFC 6749 semantics.  Indeed, you’d said that “I
            agree that we shouldn't try to "solve" scope in
            registration.”,
              but talking about restrictions is going down the slippery
              “solving it” path.

          
 

          
At
              most we can say that the two parties are making
              declarations to one another about scopes that they may
              choose to use, but we can’t assume that this is an
              exclusive list and that other scope values such as “urn:example:channel=HBO&urn:example:rating=G,PG-13”
              might not be used, even if the client registers saying
              that it intends to use the “OATC” scope value.  We could
              maybe even say that some services may use a static set of
              scopes and might choose to limit the scopes that a client
              may use to those that it declared to the server or to
              those that the server returned to the client.  That’s a
              HINT that some services might do this.  But we can’t say
              anything normative about such possible behaviors, because
              it goes beyond RFC 6749.

          
 

          
                                                           
              -- Mike

          
 

          

            

              
From:
                  Richer, Justin P. [mailto:jricher@mitre.org]
                  

                  Sent: Thursday, April 18, 2013 9:26 AM

                  To: Anthony Nadalin

                  Cc: Tim Bray; Mike Jones; oauth@ietf.org

                  Subject: Re: [OAUTH-WG] Registration: Scope
                  Values

            

          

          
 

          

            
This doesn't actually break the
              semantics because the client MUST accept what the server
              tells it over anything that it asks for in the first
              place. The server has the final say. So in this case, if
              your client asks for nothing, the server says "A B C", the
              client now knows it can ask for "A B C" scopes. 

          

          

            
 

          

          

            
I'm still in favor of not putting the
              restricting language in the scope definition at all,
              instead have it say something like:

          

          

            
 

          

          

            

              

                

                  
“Space-separated
                      list of scope values (as described in OAuth 2.0 Section 3.3

                          [RFC6749]) that the Client can use
                      when requesting access tokens from the
                      Authorization Server. As scope values are service
                      specific, the means of the Authorization Server
                      enforcing this restriction are outside the scope
                      of this specification.”

                

              

            

            
 

          

          

            
Couple this with the overall paragraph
              that says that the client is requesting values that the
              server is potentially overriding with its declarations,
              and I think that addresses everything without getting into
              confusing language that doesn't add to interoperability. 

          

          

            
 

          

          

            
 -- Justin

          

          

            
 

            

              

                
On Apr 18, 2013, at 12:13 PM,
                  Anthony Nadalin <tonynad@microsoft.com>
                  wrote:

              

              


                

                

                

              

                

                  
If
                      I don’t specify a scope, then the server can
                      allocate a default (or default set), thus that
                      breaks the semantics you describe

                

                

                  
 

                

                

                  
From: oauth-bounces@ietf.org
                      [mailto:oauth-bounces@ietf.org] On
                        Behalf Of Tim
                      Bray

                      Sent: Thursday,
                      April 18, 2013 9:04 AM

                      To: Mike
                      Jones

                      Cc: oauth@ietf.org

                      Subject: Re:
                      [OAUTH-WG] Registration: Scope Values

                

                

                  
 

                

                

                  

                    
I’m unconvinced, Mike.
                       Obviously you’re right about the looseness of
                      OAuth2 scope specification, but this is a very
                      specific semantic of what happens when you
                      register, and I don’t think we’re bound by history
                      here.   If we can’t safely say anything about what
                      the list of scopes means, then I'm with you let's
                      take them out.  But the most obvious intended
                      semantic is (from the client) “I promise to ask
                      only for these” and from the server “These are the
                      only ones I’ll give you tokens for.”  Or does
                      someone have use-cases for an alternative
                      semantic?

                  

                  

                    

                      
 

                    

                  

                  

                    

                      
To make this concrete, I
                        propose the following:

                    

                  

                  

                    

                      
“Space-separated
                          list of scope values (as described in OAuth
                          2.0 Section 3.3

                              [RFC6749]) that the client is
                          declaring to the server that it will restrict
                          itself to when requesting access tokens, and
                          that the server is declaring to the client
                          that it is registered to use when requesting
                          access tokens.  Clients SHOULD
                          assume that servers will refuse to grant
                          access tokens for scopes not in the list
                          provided by the server.”

                    

                    

                      

                        
 

                      

                    

                  

                

                

                  
 

                  

                    

                      
On Thu, Apr 18, 2013 at 8:55
                        AM, Mike Jones <Michael.Jones@microsoft.com>
                        wrote:

                    

                    

                      

                        
I
                            don’t think it’s possible to define what it
                            means in an interoperable way because OAuth
                            didn’t specify scopes in an interoperable
                            way.  No, I don’t like that either, but I
                            think that’s where things are.  That’s why I
                            was advocating deleting this registration
                            feature entirely.

                      

                      

                        
 

                      

                      

                        
But
                            understanding it might be useful in some
                            contexts, I’m OK keeping it, provided we be
                            clear that the semantics of “registered to
                            use” are service-specific.

                      

                      

                        
 

                      

                      

                        
                                                           
                            -- Mike

                      

                      

                        
 

                      

                      

                        
From: Tim

                            Bray [mailto:twbray@google.com] 

                            Sent: Thursday,
                            April 18, 2013 8:36 AM

                            To: Mike
                            Jones

                            Cc: Justin
                            Richer; oauth@ietf.org

                      

                      

                        

                          


                            Subject: Re:
                            [OAUTH-WG] Registration: Scope Values

                        

                      

                      

                        

                          
 

                        

                        

                          

                            
On the server-to-client
                              side, what does “registered to use” mean?
                               Does it mean that the client should
                              assume that any scopes not on the list
                              WILL not be granted, MAY not be
                              granted.... or what?  Is this already
                              covered elsewhere? -T

                          

                        

                        

                          
 

                          

                            

                              
On Thu, Apr 18, 2013
                                at 8:28 AM, Mike Jones <Michael.Jones@microsoft.com>
                                wrote:

                            

                            

                              

                                
Thanks,
                                    Justin.  I agree with the need for
                                    the generic two-sided language.  I’d
                                    still keep this language for scope,
                                    because we want to capture the
                                    “declaring” aspect in this case:

                              

                              

                                

                                  
 

                                

                                

                                  
“Space separated list of
                                      scope values (as described in
                                      OAuth 2.0 Section 3.3

                                          [RFC6749]) that the
                                      client is declaring to the server
                                      that it may use when requesting
                                      access tokens and that the server
                                      is declaring to the client that it
                                      is registered to use when
                                      requesting access tokens.”.

                                

                                

                                  
 

                                

                              

                              

                                
You
                                    should probably also reinforce that
                                    scope values are service-specific
                                    and may not consist only of a static
                                    set of string values, and that
                                    therefore, in some cases, an
                                    exhaustive list of registered scope
                                    values is not possible.

                              

                              

                                
 

                              

                              

                                
                                                           
                                    -- Mike

                              

                              

                                
 

                              

                              

                                

                                  

                                    
From: Justin

                                        Richer [mailto:jricher@mitre.org] 

                                        Sent: Monday,
                                        April 15, 2013 12:29 PM

                                  

                                  

                                    

                                      


                                        To: Mike
                                        Jones

                                        Cc: Tim
                                        Bray; oauth@ietf.org

                                        Subject: Re:
                                        [OAUTH-WG] Registration: Scope
                                        Values

                                    

                                  

                                

                              

                              

                                

                                  
 

                                

                                
I think
                                  that because the "declaration" issue
                                  affects all parameters in the list,
                                  not just scope, we should adopt this
                                  in a higher level paragraph and leave
                                  it out of the individual parameter
                                  descriptions. Thus, something like
                                  this inserted as the second paragraph
                                  in section 2:

                                

                                  
The client
                                    metadata values serve two parallel
                                    purposes in the overall OAuth
                                    Dynamic Registration protocol: 

                                    

                                     - the Client requesting its desired
                                    values for each parameter to the
                                    Authorization Server in a [register]
                                    or [update] request,

                                     - the Authorization Server
                                    informing the Client of the current
                                    values of each parameter that the
                                    Client has been registered to use
                                    through a [client information
                                    response]. 

                                    

                                    An Authorization Server MAY override
                                    any value that a Client requests
                                    during the registration process
                                    (including any omitted values) and
                                    replace the requested value with a
                                    default. The normative indications
                                    in the following list apply to the
                                    Client's declaration of its desired
                                    values. 

                                    

                                    The Authorization Server SHOULD
                                    provide documentation for any fields
                                    that it requires to be filled in by
                                    the client or to have particular
                                    values or formats. Extensions and
                                    profiles...

                                

                                


                                  And then remove the sidedness-language
                                  from the scope parameter and any other
                                  parameters where it might have crept
                                  in inadvertently. 

                                  

                                   -- Justin

                                

                                  

                                    
On 04/15/2013
                                      01:29 PM, Mike Jones wrote:

                                  

                                

                                

                                  

                                    
We
                                        could fix the one-sided language
                                        by changing

                                  

                                  

                                    
“Space separated list
                                        of scope values (as described in
                                        OAuth 2.0 Section 3.3

                                            [RFC6749]) that
                                        the client is declaring that it
                                        may use when requesting access
                                        tokens.”

                                  

                                  

                                    
to

                                  

                                  

                                    
“Space separated list
                                        of scope values (as described in
                                        OAuth 2.0 Section 3.3

                                            [RFC6749]) that
                                        the client is declaring to the
                                        server that it may use when
                                        requesting access tokens and
                                        that the server is declaring to
                                        the client that it is registered
                                        to use when requesting access
                                        tokens.”.

                                  

                                  

                                    
 

                                  

                                  

                                    
Again,
                                        I chose the “registered to use”
                                        language carefully – because in
                                        the general case it’s not a
                                        restriction on the values that
                                        the client can use – just a
                                        statement by the server to the
                                        client that it is registered to
                                        use those particular values.  In
                                        both cases, the parties are
                                        making declarations to one
                                        another.

                                  

                                  

                                    
 

                                  

                                  

                                    
If
                                        you adopt that language (or keep
                                        the original language), then
                                        yes, I’d consider this closed.

                                  

                                  

                                    
 

                                  

                                  

                                    
                                                           
                                        -- Mike

                                  

                                  

                                    
 

                                  

                                  

                                    

                                      

                                        
From: Justin

                                            Richer [mailto:jricher@mitre.org] 

                                            Sent: Monday,
                                            April 15, 2013 9:57 AM

                                            To: Mike
                                            Jones

                                            Cc: Tim
                                            Bray; oauth@ietf.org

                                            Subject: Re:
                                            [OAUTH-WG] Registration:
                                            Scope Values

                                      

                                    

                                  

                                  

                                    
 

                                  

                                  
I
                                    absolutely do not want to delete
                                    this feature, as (having implemented
                                    it) I think it's very useful. This
                                    is a very established pattern in
                                    manual registration: I know of many,
                                    many OAuth2 servers and clients that
                                    are set up where the client must
                                    pre-register a set of scopes. 

                                    

                                    I don't like the language of "the
                                    client is declaring" because it's
                                    too one-sided. The client might not
                                    have declared anything, and it might
                                    be the server that's declaring
                                    something to the client. Deleting
                                    the "is declaring" bit removes that
                                    unintended restriction of the
                                    language while keeping the original
                                    meaning intact. I actually thought
                                    that I had fixed that before the
                                    last draft went in but apparently I
                                    missed this one.

                                    

                                    I will work on clarifying the intent
                                    of the whole metadata set in its
                                    introductory paragraph(s) so that
                                    it's clear that all of these fields
                                    are used in both of these
                                    situations:

                                    

                                     1) The client declaring to the
                                    server its desire to use a
                                    particular value

                                     2) The server declaring to the
                                    client that it has been registered
                                    with a particular value

                                    

                                    This should hopefully clear up the
                                    issue in the editor's note that I
                                    currently have at the top of that
                                    section right now, too.

                                    

                                    Mike, since you were the one who
                                    originally brought up the issue, and
                                    you're fine with the existing text,
                                    can I take this as closed now?
                                    Assuming that you agree with
                                    deleting "is declaring" for reasons
                                    stated above, I'm fine with leaving
                                    everything else as is and staying
                                    quiet on what the server has to do
                                    with the scopes.

                                    

                                     -- Justin

                                  

                                    

                                      
On 04/15/2013
                                        12:44 PM, Mike Jones wrote:

                                    

                                  

                                  

                                    

                                      
I
                                          think that the existing
                                          wording is superior to the
                                          proposed changed wording.  The
                                          existing wording is:

                                    

                                    

                                      
 

                                    

                                    

                                      
   scope

                                    

                                    

                                      
      OPTIONAL. 
                                          Space separated list of scope
                                          values (as described in

                                    

                                    

                                      
      OAuth 2.0 Section 3.3
                                              [RFC6749]) that
                                          the client is declaring that

                                    

                                    

                                      
      it may use
                                          when requesting access
                                          tokens.  If omitted, an

                                    

                                    

                                      
      Authorization
                                          Server MAY register a Client
                                          with a default set of

                                    

                                    

                                      
      scopes.

                                    

                                    

                                      
 

                                    

                                    

                                      
For
                                          instance, the current “client
                                          is declaring” wording will
                                          always be correct, whereas as
                                          the change to “client can use”
                                          wording implies a restriction
                                          on client behavior that is not
                                          always applicable.  The
                                          “client is declaring” wording
                                          was specific and purposefully
                                          chosen, and I think should be
                                          retained.  In particular, we
                                          can’t do anything that implies
                                          that only the registered
                                          scopes values can be used.  At
                                          the OAuth spec level, this is
                                          a hint as to possible future
                                          client behavior – not a
                                          restriction on future client
                                          behavior.

                                    

                                    

                                      
 

                                    

                                    

                                      
Also,
                                          for the reasons that Tim
                                          stated, I’m strongly against
                                          any “matching” or “regex”
                                          language in the spec
                                          pertaining to scopes – as it’s
                                          not actionable.

                                    

                                    

                                      
 

                                    

                                    

                                      
So
                                          I’d propose that we leave the
                                          existing scope wording in
                                          place.  Alternatively, I’d
                                          also be fine with deleting
                                          this feature entirely, as I
                                          don’t think it’s useful in the
                                          general case.

                                    

                                    

                                      
 

                                    

                                    

                                      
                                                           
                                          -- Mike

                                    

                                    

                                      
 

                                    

                                    

                                      

                                        

                                          
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]On

                                                Behalf Of Justin
                                              Richer

                                              Sent: Monday,
                                              April 15, 2013 8:05 AM

                                              To: Tim
                                              Bray; oauth@ietf.org

                                              Subject: Re:
                                              [OAUTH-WG] Registration:
                                              Scope Values

                                        

                                      

                                    

                                    

                                      
 

                                    

                                    
On
                                      04/15/2013 10:52 AM, Tim Bray
                                      wrote:

                                      

                                      

                                      

                                      

                                    

                                      

                                        
I’d use the
                                          existing wording; it’s
                                          perfectly clear.  Failing
                                          that, if there’s strong demand
                                          for registration of structured
                                          scopes, bless the use of
                                          regexes, either PCREs or some
                                          careful subset.

                                      

                                    

                                    


                                      Thanks for the feedback -- Of
                                      these two choices, I'd rather
                                      leave it as-is. 

                                      

                                      

                                      

                                      

                                      

                                    

                                      

                                        

                                          
 

                                        

                                      

                                      

                                        

                                          
However,
                                            I’d subtract the sentence
                                            “If omitted, an
                                            Authorization Server MAY
                                            register a Client with a
                                            default set of  scopes.”  It
                                            adds no value; if the client
                                            doesn’t declare scopes, the
                                            client doesn’t declare
                                            scopes, that’s all.  -T

                                        

                                      

                                    

                                    


                                      Remember, all of these fields
                                      aren't just for the client
                                      *request*, they're also for the
                                      server's *response* to either a
                                      POST, PUT, or GET request. (I
                                      didn't realize it, but perhaps the
                                      wording as stated right now
                                      doesn't make that clear -- I need
                                      to fix that.) The value that it
                                      adds is if the client doesn't ask
                                      for any particular scopes, the
                                      server can still assign it scopes
                                      and the client can do something
                                      smart with that. Dumb clients are
                                      allowed to ignore it if it doesn't
                                      mean anything to them. 

                                      

                                      This is how our server
                                      implementation actually works
                                      right now. If the client doesn't
                                      ask for anything specific at
                                      registration, the server hands it
                                      a bag of "default" scopes. Same
                                      thing happens at auth time -- if
                                      the client doesn't ask for any
                                      particular scopes, the server
                                      hands it all of its registered
                                      scopes as a default. Granted, on
                                      our server, scopes are just simple
                                      strings right now, so they get
                                      compared at the auth endpoint with
                                      an exact string-match metric and
                                      set-based logic. 

                                      

                                       -- Justin

                                      

                                      

                                      

                                      

                                      

                                    

                                      
 

                                      

                                        

                                          
On Mon,
                                            Apr 15, 2013 at 7:35 AM,
                                            Justin Richer <jricher@mitre.org>
                                            wrote:

                                        

                                        

                                          

                                            
What
                                              would you suggest for
                                              wording here, then?
                                              Keeping in mind that we
                                              cannot (and don't want to)
                                              prohibit expression-based
                                              scopes. 

                                              

                                                 -- Justin

                                          

                                          

                                            
 

                                            

                                              

                                                
On
                                                  04/15/2013 10:33 AM,
                                                  Tim Bray wrote:

                                              

                                            

                                            

                                              

                                                

                                                  
No,
                                                    I mean it’s not
                                                    interoperable at the
                                                    software-developer
                                                    level.  I can’t
                                                    register scopes at
                                                    authorization time
                                                    with any predictable
                                                    effect that I can
                                                    write code to
                                                    support, either
                                                    client or server
                                                    side, without
                                                    out-of-line
                                                    non-interoperable
                                                    knowledge about the
                                                    behavior of the
                                                    server.  

                                                

                                                

                                                  

                                                    
 

                                                  

                                                

                                                

                                                  

                                                    
I
                                                      guess I’m just not
                                                      used to OAuth’s
                                                      culture of having
                                                      no expectation
                                                      that things will
                                                      be specified
                                                      tightly enough
                                                      that I can write
                                                      code to implement
                                                      as specified.  -T

                                                  

                                                

                                              

                                              

                                                
 

                                                

                                                  

                                                    
On
                                                      Mon, Apr 15, 2013
                                                      at 7:15 AM, Justin
                                                      Richer <jricher@mitre.org>
                                                      wrote:

                                                  

                                                  

                                                    

                                                      
Scopes
                                                        aren't meant to
                                                        be interoperable
                                                        between services
                                                        since they're
                                                        necessarily
                                                        API-specific.
                                                        The only
                                                        interoperable
                                                        bit is that
                                                        there's *some*
                                                        place to put the
                                                        values and that
                                                        it's expressed
                                                        as a bag of
                                                        space-separated
                                                        strings. How
                                                        those strings
                                                        get interpreted
                                                        and enforced
                                                        (which is really
                                                        what's at stake
                                                        here) is up to
                                                        the AS and PR
                                                        (or a
                                                        higher-level
                                                        protocol like
                                                        UMA).

                                                          

                                                           -- Justin

                                                    

                                                    

                                                      
 

                                                      

                                                        

                                                          
On
                                                          04/15/2013
                                                          10:13 AM, Tim
                                                          Bray wrote:

                                                        

                                                      

                                                      

                                                        
This, as
                                                          written, has
                                                          zero
                                                          interoperability. 
                                                          I think this
                                                          feature can
                                                          really only be
                                                          made useful in
                                                          the case where
                                                          scopes are
                                                          fixed strings.

                                                        
-T

                                                        

                                                          

                                                          
On
                                                          Apr 15, 2013
                                                          6:54 AM,
                                                          "Justin
                                                          Richer" <jricher@mitre.org> wrote:

                                                          

                                                          

                                                          
You are correct that the idea behind the
                                                          "scope"
                                                          parameter at
                                                          registration
                                                          is a
                                                          constraint on
                                                          authorization-time
                                                          scopes that
                                                          are made
                                                          available.
                                                          It's both a
                                                          means for the
                                                          client to
                                                          request a set
                                                          of valid
                                                          scopes and for
                                                          the server to
                                                          provision (and
                                                          echo back to
                                                          the client) a
                                                          set of valid
                                                          scopes.

                                                          

                                                          I *really*
                                                          don't want to
                                                          try to define
                                                          a matching
                                                          language for
                                                          scope
                                                          expressions.
                                                          For that to
                                                          work, all
                                                          servers would
                                                          need to be
                                                          able to
                                                          process the
                                                          regular
                                                          expressions
                                                          for all
                                                          clients, even
                                                          if the servers
                                                          themselves
                                                          only support
                                                          simple-string
                                                          scope values.
                                                          Any regular
                                                          expression
                                                          syntax we pick
                                                          here is
                                                          guaranteed to
                                                          be
                                                          incompatible
                                                          with
                                                          something, and
                                                          I think the
                                                          complexity
                                                          doesn't buy
                                                          much. Also, I
                                                          think you
                                                          suddenly have
                                                          a potential
                                                          security issue
                                                          if you have a
                                                          bad regex in
                                                          place on
                                                          either end. 

                                                          

                                                          As it stands
                                                          today, the
                                                          server can
                                                          interpret the
                                                          incoming
                                                          registration
                                                          scopes and
                                                          enforce them
                                                          however it
                                                          wants to. The
                                                          real trick
                                                          comes not from
                                                          assigning the
                                                          values to a
                                                          particular
                                                          client but to
                                                          enforcing
                                                          them, and I
                                                          think that's
                                                          always going
                                                          to be
                                                          service-specific.
                                                          We're just not
                                                          as clear on
                                                          that as we
                                                          could be.

                                                          

                                                          After looking
                                                          over
                                                          everyone's
                                                          comments so
                                                          far, I'd like
                                                          to propose the
                                                          following text
                                                          for that
                                                          section:

                                                          

                                                          

                                                          

                                                          

                                                          
   scope

                                                          
      OPTIONAL.  Space separated list of scope values (as described in

                                                          
      OAuth 2.0 Section 3.3 [RFC6749]) that the client can use when 

                                                          
      requesting access tokens.  As scope values are service-specific, 

                                                          
      the Authorization Server MAY define its own matching rules when

                                                          
      determining if a scope value used during an authorization request

                                                          
      is valid according to the scope values assigned during 

                                                          
      registration. Possible matching rules include wildcard patterns,

                                                          
      regular expressions, or exactly matching the string. If omitted, 

                                                          
      an Authorization Server MAY register a Client with a default 

                                                          
      set of scopes.

                                                          


                                                          Comments?
                                                          Improvements?

                                                          

                                                           -- Justin

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
On
                                                          04/14/2013
                                                          08:23 PM,
                                                          Manger, James
                                                          H wrote:

                                                          

                                                          

                                                          

                                                          
Presumably at app registration time any scope specification is really a constraint on the scope values that can be requested in an authorization flow.

                                                          
 

                                                          
So ideally registration should accept rules for matching scopes, as opposed to actual scope values.

                                                          
 

                                                          
You can try to use scope values as their own matching rules. That is fine for a small set of "static" scopes. It starts to fail when there are a large number of scopes, or scopes that can include parameters (resource paths? email addresses?). You can try to patch those failures by allowing services to define service-specific special "wildcard" scope values that can only be used during registration (eg "read:*").

                                                          
 

                                                          
Alternatively, replace 'scope' in registration with 'scope_regex' that holds a regular expression that all scope values in an authorization flow must match.

                                                          
 

                                                          
--

                                                          
James Manger

                                                          
_______________________________________________

                                                          
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

              

            

            
 

          

        

        
 

      

    

    

  


--------------070409060707000302030606--

From jricher@mitre.org  Thu Apr 18 11:05:19 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3FD621F8F5C for ; Thu, 18 Apr 2013 11:05:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.898
X-Spam-Level: 
X-Spam-Status: No, score=-5.898 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, J_CHICKENPOX_26=0.6, 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 g+xnlc8woPVD for ; Thu, 18 Apr 2013 11:05:16 -0700 (PDT)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 76CE721F8F0D for ; Thu, 18 Apr 2013 11:05:15 -0700 (PDT)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id CB6701F05CA; Thu, 18 Apr 2013 14:05:14 -0400 (EDT)
Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id A1E081F058A; Thu, 18 Apr 2013 14:05:14 -0400 (EDT)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.342.3; Thu, 18 Apr 2013 14:05:14 -0400
Message-ID: <517035CE.7000005@mitre.org>
Date: Thu, 18 Apr 2013 14:05:02 -0400
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130329 Thunderbird/17.0.5
MIME-Version: 1.0
To: Phil Hunt 
References: <255B9BB34FB7D647A506DC292726F6E1150C74DADA@WSMSG3153V.srv.dir.telstra.com> <516C1714.8070503@mitre.org> <4E1F6AAD24975D4BA5B168042967394367641A87@TK5EX14MBXC283.redmond.corp.microsoft.com> <516C3152.9070603@mitre.org> <4E1F6AAD24975D4BA5B168042967394367641FAB@TK5EX14MBXC283.redmond.corp.microsoft.com> <516C54F2.8040708@mitre.org> <4E1F6AAD24975D4BA5B16804296739436766BCC4@TK5EX14MBXC284.redmond.corp.microsoft.com>  <4E1F6AAD24975D4BA5B16804296739436766C964@TK5EX14MBXC284.redmond.corp.microsoft.com>    <4E1F6AAD24975D4BA5B16804296739436766D8B9@TK5EX14MBXC284.redmond.corp.microsoft.com> <5170319A.5080903@mitre.org> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------060705030801020905080507"
X-Originating-IP: [129.83.31.58]
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: Scope Values
X-BeenThere: oauth@ietf.org
X-Mailman-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, 18 Apr 2013 18:05:19 -0000

--------------060705030801020905080507
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 8bit

I wholeheartedly agree that scope at registration is a useful part of 
the lifecycle (and indeed, a required part of our own implementation of 
this very functionality). But the way I read it, the requirement of "all 
scopes ... MAY use" is too restrictive and it's open to 
misinterpretation, I think. If a client registers for "A" but asks for 
"A:b?param=foo", is that OK? This is the pattern that we've been talking 
about using with Blue Button [1], but it seems precluded by this 
definition if you've got a tight definition of "MAY use". In the case of 
simple strings, it's adequate, and I think that's the common case, but 
we don't want to restrict the usefulness of this field to the simple 
case. I had tried to address this with enumerating string matching and 
other things, others have suggested defining a regular expression 
language, but at the end of the day I don't think any of that actually 
buys you much interoperability.

  -- Justin

[1] http://blue-button.github.io/blue-button-plus-pull/

On 04/18/2013 01:54 PM, Phil Hunt wrote:
> Why not:
>
>> "A value corresponding to scope as described in OAuth 2, Section 3.3 
>> [RFC6749]. The registered Client may use these to indicate all of the 
>> scopes that a client MAY use when requesting tokens from an 
>> Authorization Server."
>
> In the above, I avoid re-defining scope at all. However describing why 
> they are included in registration is useful.  IMHO I think scope at 
> registration is useful for life-cycle approval workflows.
>
> In some cases you could say they are also the default list, but I'm 
> not sure it helps inter-operability so its not clear it needs to be 
> mentioned.
>
> Phil
>
> @independentid
> www.independentid.com 
> phil.hunt@oracle.com 
>
>
>
>
>
> On 2013-04-18, at 10:47 AM, Justin Richer wrote:
>
>> Thing is, there's nothing normative about the enforcing statement 
>> that I made below, so I don't think it's any more restrictive than 
>> RFC 6749 which lets the AS replace a client's requested scopes at the 
>> time of token issuance with whatever it pleases. But that said, I'd 
>> be just as happy to leave it like this with no further restrictions:
>>
>> Space-separated list of scope values (as described in OAuth 2.0 
>> Section 3.3 [RFC6749] 
>> ) that the Client can 
>> use when requesting access tokens from the Authorization Server.
>>
>> And call it a day. This parallels the text for grant_types ("Array of 
>> OAuth 2.0 grant types that the Client may use [when accessing the 
>> Token Endpoint].") and response_types ("Array of the OAuth 2.0 
>> response types that the Client may use [when accessing the 
>> Authorization Endpoint]."), and I think this is the correct approach. 
>> I only started to add the restrictive text because I thought that 
>> people were making the argument that it was necessary -- I'd rather 
>> not have it.
>> Plus, it's an optional field in the metadata, so if you've got 
>> structured scopes where this doesn't make sense, don't use it. If you 
>> don't do a per-client scope restriction, don't use it.
>>
>> The interoperability is defined in light of the interoperability of 
>> scopes themselves: this is a field to request/grant a bag of strings 
>> that only make sense in light of a given API. For that to make real 
>> sense, I think that we need to differentiate an OAuth client as a 
>> generic *library* from an OAuth client as a generic accessing 
>> *application*. It's very useful for a generic *library* that handles 
>> the authorization layer for an application to have a slot for 
>> registering scopes and finding out what scopes the app's been 
>> registered for. It's up to the app (not the library) to figure out 
>> how to translate those into scopes to ask for at authorization time. 
>> Sometimes that means just passing the string, and sometimes it means 
>> the construction of a structured value like 
>> "urn:example:channel=HBO&urn:example:rating=G,PG-13". The library 
>> doesn't care, the application does, and we should focus on 
>> interoperability from the library's perspective. Similarly, on the 
>> server side, the libraries will tell you the bag of scopes that the 
>> client was registered for, and what bag of scopes the client asked 
>> for during authorization. It's up to the server *application* to 
>> harmonize those two in a way that makes sense for the API that it's 
>> protecting. Just like it's up to the protected resource *application* 
>> to figure out what a scope means in a given context.
>>
>> So let's just leave it unrestricted but keep the slot for 
>> communicating this piece of information with the same semantics that 
>> the communication between the client and server take on for every 
>> other field: client asks for a thing, server says that client 
>> actually gets a thing, and it's implicitly up to the server to do the 
>> right thing and enforce things in a way that makes sense for the 
>> application no matter what the client does.
>>
>> To take Tony's example, client requests no scopes at registration, 
>> server grants scope "A" at registration. Client then requests scope 
>> "X" at authorization, server is free to deny the request 
>> (invalid_scope error), allow authorization because it knows how "A" 
>> and "X" are related, require user intervention, or really, whatever 
>> it likes. The libraries, where I argue the interoperability cries 
>> really matter, don't care, and shouldn't care.
>>
>>  -- Justin
>>
>> On 04/18/2013 01:04 PM, Mike Jones wrote:
>>>
>>> Saying anything normative about “enforcing restrictions” is going 
>>> beyond RFC 6749 semantics.  Indeed, you’d said that “I agree that we 
>>> shouldn't try to "solve" scope in registration.”, but talking about 
>>> restrictions is going down the slippery “solving it” path.
>>>
>>> At most we can say that the two parties are making declarations to 
>>> one another about scopes that they may choose to use, but we can’t 
>>> assume that this is an exclusive list and that other scope values 
>>> such as “urn:example:channel=HBO&urn:example:rating=G,PG-13” might 
>>> not be used, even if the client registers saying that it intends to 
>>> use the “OATC” scope value.  We could maybe even say that some 
>>> services may use a static set of scopes and might choose to limit 
>>> the scopes that a client may use to those that it declared to the 
>>> server or to those that the server returned to the client.  That’s a 
>>> HINT that some services might do this.  But we can’t say anything 
>>> normative about such possible behaviors, because it goes beyond RFC 
>>> 6749.
>>>
>>> -- Mike
>>>
>>> *From:*Richer, Justin P. [mailto:jricher@mitre.org]
>>> *Sent:* Thursday, April 18, 2013 9:26 AM
>>> *To:* Anthony Nadalin
>>> *Cc:* Tim Bray; Mike Jones; oauth@ietf.org
>>> *Subject:* Re: [OAUTH-WG] Registration: Scope Values
>>>
>>> This doesn't actually break the semantics because the client MUST 
>>> accept what the server tells it over anything that it asks for in 
>>> the first place. The server has the final say. So in this case, if 
>>> your client asks for nothing, the server says "A B C", the client 
>>> now knows it can ask for "A B C" scopes.
>>>
>>> I'm still in favor of not putting the restricting language in the 
>>> scope definition at all, instead have it say something like:
>>>
>>>     “Space-separated list of scope values (as described in OAuth 2.0
>>>     Section 3.3 [RFC6749]
>>>     ) that the
>>>     Client can use when requesting access tokens from the
>>>     Authorization Server. As scope values are service specific, the
>>>     means of the Authorization Server enforcing this restriction are
>>>     outside the scope of this specification.”
>>>
>>> Couple this with the overall paragraph that says that the client is 
>>> requesting values that the server is potentially overriding with its 
>>> declarations, and I think that addresses everything without getting 
>>> into confusing language that doesn't add to interoperability.
>>>
>>>  -- Justin
>>>
>>> On Apr 18, 2013, at 12:13 PM, Anthony Nadalin >> > wrote:
>>>
>>>
>>>
>>> If I don’t specify a scope, then the server can allocate a default 
>>> (or default set), thus that breaks the semantics you describe
>>>
>>> *From:*oauth-bounces@ietf.org  
>>> [mailto:oauth-bounces@ietf.org ]*On Behalf 
>>> Of*Tim Bray
>>> *Sent:*Thursday, April 18, 2013 9:04 AM
>>> *To:*Mike Jones
>>> *Cc:*oauth@ietf.org 
>>> *Subject:*Re: [OAUTH-WG] Registration: Scope Values
>>>
>>> I’m unconvinced, Mike.  Obviously you’re right about the looseness 
>>> of OAuth2 scope specification, but this is a very specific semantic 
>>> of what happens when you register, and I don’t think we’re bound by 
>>> history here. If we can’t safely say anything about what the list of 
>>> scopes means, then I'm with you let's take them out.  But the most 
>>> obvious intended semantic is (from the client) “I promise to ask 
>>> only for these” and from the server “These are the only ones I’ll 
>>> give you tokens for.”  Or does someone have use-cases for an 
>>> alternative semantic?
>>>
>>> To make this concrete, I propose the following:
>>>
>>> “Space-separated list of scope values (as described in OAuth 2.0 
>>> Section 3.3 [RFC6749] 
>>> ) that the client is 
>>> declaring to the server that it will restrict itself to when 
>>> requesting access tokens, and that the server is declaring to the 
>>> client that it is registered to use when requesting access tokens. 
>>> Clients SHOULD assume that servers will refuse to grant access 
>>> tokens for scopes not in the list provided by the server.”
>>>
>>> On Thu, Apr 18, 2013 at 8:55 AM, Mike Jones 
>>> > 
>>> wrote:
>>>
>>>     I don’t think it’s possible to define what it means in an
>>>     interoperable way because OAuth didn’t specify scopes in an
>>>     interoperable way.  No, I don’t like that either, but I think
>>>     that’s where things are. That’s why I was advocating deleting
>>>     this registration feature entirely.
>>>
>>>     But understanding it might be useful in some contexts, I’m OK
>>>     keeping it, provided we be clear that the semantics of
>>>     “registered to use” are service-specific.
>>>
>>>     -- Mike
>>>
>>>     *From:*Tim Bray [mailto:twbray@google.com
>>>     ]
>>>     *Sent:*Thursday, April 18, 2013 8:36 AM
>>>     *To:*Mike Jones
>>>     *Cc:*Justin Richer;oauth@ietf.org 
>>>
>>>
>>>     *Subject:*Re: [OAUTH-WG] Registration: Scope Values
>>>
>>>     On the server-to-client side, what does “registered to use”
>>>     mean?  Does it mean that the client should assume that any
>>>     scopes not on the list WILL not be granted, MAY not be
>>>     granted.... or what?  Is this already covered elsewhere? -T
>>>
>>>     On Thu, Apr 18, 2013 at 8:28 AM, Mike Jones
>>>     >>     > wrote:
>>>
>>>     Thanks, Justin.  I agree with the need for the generic two-sided
>>>     language.  I’d still keep this language for scope, because we
>>>     want to capture the “declaring” aspect in this case:
>>>
>>>     “Space separated list of scope values (as described in OAuth
>>>     2.0Section 3.3 [RFC6749]
>>>     ) that the
>>>     client is declaring to the server that it may use when
>>>     requesting access tokens and that the server is declaring to the
>>>     client that it is registered to use when requesting access tokens.”.
>>>
>>>     You should probably also reinforce that scope values are
>>>     service-specific and may not consist only of a static set of
>>>     string values, and that therefore, in some cases, an exhaustive
>>>     list of registered scope values is not possible.
>>>
>>>     -- Mike
>>>
>>>     *From:*Justin Richer [mailto:jricher@mitre.org
>>>     ]
>>>     *Sent:*Monday, April 15, 2013 12:29 PM
>>>
>>>
>>>     *To:*Mike Jones
>>>     *Cc:*Tim Bray;oauth@ietf.org 
>>>     *Subject:*Re: [OAUTH-WG] Registration: Scope Values
>>>
>>>     I think that because the "declaration" issue affects all
>>>     parameters in the list, not just scope, we should adopt this in
>>>     a higher level paragraph and leave it out of the individual
>>>     parameter descriptions. Thus, something like this inserted as
>>>     the second paragraph in section 2:
>>>
>>>     The client metadata values serve two parallel purposes in the
>>>     overall OAuth Dynamic Registration protocol:
>>>
>>>      - the Client requesting its desired values for each parameter
>>>     to the Authorization Server in a [register] or [update] request,
>>>      - the Authorization Server informing the Client of the current
>>>     values of each parameter that the Client has been registered to
>>>     use through a [client information response].
>>>
>>>     An Authorization Server MAY override any value that a Client
>>>     requests during the registration process (including any omitted
>>>     values) and replace the requested value with a default. The
>>>     normative indications in the following list apply to the
>>>     Client's declaration of its desired values.
>>>
>>>     The Authorization Server SHOULD provide documentation for any
>>>     fields that it requires to be filled in by the client or to have
>>>     particular values or formats. Extensions and profiles...
>>>
>>>
>>>     And then remove the sidedness-language from the scope parameter
>>>     and any other parameters where it might have crept in inadvertently.
>>>
>>>      -- Justin
>>>
>>>     On 04/15/2013 01:29 PM, Mike Jones wrote:
>>>
>>>         We could fix the one-sided language by changing
>>>
>>>         “Space separated list of scope values (as described in OAuth
>>>         2.0Section 3.3 [RFC6749]
>>>         ) that the
>>>         client is declaring that it may use when requesting access
>>>         tokens.”
>>>
>>>         to
>>>
>>>         “Space separated list of scope values (as described in OAuth
>>>         2.0Section 3.3 [RFC6749]
>>>         ) that the
>>>         client is declaring to the server that it may use when
>>>         requesting access tokens and that the server is declaring to
>>>         the client that it is registered to use when requesting
>>>         access tokens.”.
>>>
>>>         Again, I chose the “registered to use” language carefully –
>>>         because in the general case it’s not a restriction on the
>>>         values that the client can use – just a statement by the
>>>         server to the client that it is registered to use those
>>>         particular values.  In both cases, the parties are making
>>>         declarations to one another.
>>>
>>>         If you adopt that language (or keep the original language),
>>>         then yes, I’d consider this closed.
>>>
>>>         -- Mike
>>>
>>>         *From:*Justin Richer [mailto:jricher@mitre.org]
>>>         *Sent:*Monday, April 15, 2013 9:57 AM
>>>         *To:*Mike Jones
>>>         *Cc:*Tim Bray;oauth@ietf.org 
>>>         *Subject:*Re: [OAUTH-WG] Registration: Scope Values
>>>
>>>         I absolutely do not want to delete this feature, as (having
>>>         implemented it) I think it's very useful. This is a very
>>>         established pattern in manual registration: I know of many,
>>>         many OAuth2 servers and clients that are set up where the
>>>         client must pre-register a set of scopes.
>>>
>>>         I don't like the language of "the client is declaring"
>>>         because it's too one-sided. The client might not have
>>>         declared anything, and it might be the server that's
>>>         declaring something to the client. Deleting the "is
>>>         declaring" bit removes that unintended restriction of the
>>>         language while keeping the original meaning intact. I
>>>         actually thought that I had fixed that before the last draft
>>>         went in but apparently I missed this one.
>>>
>>>         I will work on clarifying the intent of the whole metadata
>>>         set in its introductory paragraph(s) so that it's clear that
>>>         all of these fields are used in both of these situations:
>>>
>>>          1) The client declaring to the server its desire to use a
>>>         particular value
>>>          2) The server declaring to the client that it has been
>>>         registered with a particular value
>>>
>>>         This should hopefully clear up the issue in the editor's
>>>         note that I currently have at the top of that section right
>>>         now, too.
>>>
>>>         Mike, since you were the one who originally brought up the
>>>         issue, and you're fine with the existing text, can I take
>>>         this as closed now? Assuming that you agree with deleting
>>>         "is declaring" for reasons stated above, I'm fine with
>>>         leaving everything else as is and staying quiet on what the
>>>         server has to do with the scopes.
>>>
>>>          -- Justin
>>>
>>>         On 04/15/2013 12:44 PM, Mike Jones wrote:
>>>
>>>             I think that the existing wording is superior to the
>>>             proposed changed wording.  The existing wording is:
>>>
>>>                scope
>>>
>>>             OPTIONAL.  Space separated list of scope values (as
>>>             described in
>>>
>>>                   OAuth 2.0Section 3.3 [RFC6749]
>>>             ) that
>>>             the client is declaring that
>>>
>>>                   it may use when requesting access tokens.  If
>>>             omitted, an
>>>
>>>             Authorization Server MAY register a Client with a
>>>             default set of
>>>
>>>             scopes.
>>>
>>>             For instance, the current “client is declaring” wording
>>>             will always be correct, whereas as the change to “client
>>>             can use” wording implies a restriction on client
>>>             behavior that is not always applicable.  The “client is
>>>             declaring” wording was specific and purposefully chosen,
>>>             and I think should be retained. In particular, we can’t
>>>             do anything that implies that only the registered scopes
>>>             values can be used. At the OAuth spec level, this is a
>>>             hint as to possible future client behavior – not a
>>>             restriction on future client behavior.
>>>
>>>             Also, for the reasons that Tim stated, I’m strongly
>>>             against any “matching” or “regex” language in the spec
>>>             pertaining to scopes – as it’s not actionable.
>>>
>>>             So I’d propose that we leave the existing scope wording
>>>             in place.  Alternatively, I’d also be fine with deleting
>>>             this feature entirely, as I don’t think it’s useful in
>>>             the general case.
>>>
>>>             -- Mike
>>>
>>>             *From:*oauth-bounces@ietf.org
>>>             [mailto:oauth-bounces@ietf.org]*On
>>>             Behalf Of*Justin Richer
>>>             *Sent:*Monday, April 15, 2013 8:05 AM
>>>             *To:*Tim Bray;oauth@ietf.org 
>>>             *Subject:*Re: [OAUTH-WG] Registration: Scope Values
>>>
>>>             On 04/15/2013 10:52 AM, Tim Bray wrote:
>>>
>>>
>>>             I’d use the existing wording; it’s perfectly clear.
>>>              Failing that, if there’s strong demand for registration
>>>             of structured scopes, bless the use of regexes, either
>>>             PCREs or some careful subset.
>>>
>>>
>>>             Thanks for the feedback -- Of these two choices, I'd
>>>             rather leave it as-is.
>>>
>>>
>>>
>>>             However, I’d subtract the sentence “If omitted, an
>>>             Authorization Server MAY register a Client with a
>>>             default set of  scopes.”  It adds no value; if the
>>>             client doesn’t declare scopes, the client doesn’t
>>>             declare scopes, that’s all.  -T
>>>
>>>
>>>             Remember, all of these fields aren't just for the client
>>>             *request*, they're also for the server's *response* to
>>>             either a POST, PUT, or GET request. (I didn't realize
>>>             it, but perhaps the wording as stated right now doesn't
>>>             make that clear -- I need to fix that.) The value that
>>>             it adds is if the client doesn't ask for any particular
>>>             scopes, the server can still assign it scopes and the
>>>             client can do something smart with that. Dumb clients
>>>             are allowed to ignore it if it doesn't mean anything to
>>>             them.
>>>
>>>             This is how our server implementation actually works
>>>             right now. If the client doesn't ask for anything
>>>             specific at registration, the server hands it a bag of
>>>             "default" scopes. Same thing happens at auth time -- if
>>>             the client doesn't ask for any particular scopes, the
>>>             server hands it all of its registered scopes as a
>>>             default. Granted, on our server, scopes are just simple
>>>             strings right now, so they get compared at the auth
>>>             endpoint with an exact string-match metric and set-based
>>>             logic.
>>>
>>>              -- Justin
>>>
>>>
>>>
>>>             On Mon, Apr 15, 2013 at 7:35 AM, Justin Richer
>>>             > wrote:
>>>
>>>             What would you suggest for wording here, then? Keeping
>>>             in mind that we cannot (and don't want to) prohibit
>>>             expression-based scopes.
>>>
>>>              -- Justin
>>>
>>>             On 04/15/2013 10:33 AM, Tim Bray wrote:
>>>
>>>                 No, I mean it’s not interoperable at the
>>>                 software-developer level.  I can’t register scopes
>>>                 at authorization time with any predictable effect
>>>                 that I can write code to support, either client or
>>>                 server side, without out-of-line non-interoperable
>>>                 knowledge about the behavior of the server.
>>>
>>>                 I guess I’m just not used to OAuth’s culture of
>>>                 having no expectation that things will be specified
>>>                 tightly enough that I can write code to implement as
>>>                 specified.  -T
>>>
>>>                 On Mon, Apr 15, 2013 at 7:15 AM, Justin Richer
>>>                 > wrote:
>>>
>>>                 Scopes aren't meant to be interoperable between
>>>                 services since they're necessarily API-specific. The
>>>                 only interoperable bit is that there's *some* place
>>>                 to put the values and that it's expressed as a bag
>>>                 of space-separated strings. How those strings get
>>>                 interpreted and enforced (which is really what's at
>>>                 stake here) is up to the AS and PR (or a
>>>                 higher-level protocol like UMA).
>>>
>>>                  -- Justin
>>>
>>>                 On 04/15/2013 10:13 AM, Tim Bray wrote:
>>>
>>>                     This, as written, has zero interoperability. I
>>>                     think this feature can really only be made
>>>                     useful in the case where scopes are fixed strings.
>>>
>>>                     -T
>>>
>>>                     On Apr 15, 2013 6:54 AM, "Justin Richer"
>>>                     >
>>>                     wrote:
>>>
>>>                     You are correct that the idea behind the "scope"
>>>                     parameter at registration is a constraint on
>>>                     authorization-time scopes that are made
>>>                     available. It's both a means for the client to
>>>                     request a set of valid scopes and for the server
>>>                     to provision (and echo back to the client) a set
>>>                     of valid scopes.
>>>
>>>                     I *really* don't want to try to define a
>>>                     matching language for scope expressions. For
>>>                     that to work, all servers would need to be able
>>>                     to process the regular expressions for all
>>>                     clients, even if the servers themselves only
>>>                     support simple-string scope values. Any regular
>>>                     expression syntax we pick here is guaranteed to
>>>                     be incompatible with something, and I think the
>>>                     complexity doesn't buy much. Also, I think you
>>>                     suddenly have a potential security issue if you
>>>                     have a bad regex in place on either end.
>>>
>>>                     As it stands today, the server can interpret the
>>>                     incoming registration scopes and enforce them
>>>                     however it wants to. The real trick comes not
>>>                     from assigning the values to a particular client
>>>                     but to enforcing them, and I think that's always
>>>                     going to be service-specific. We're just not as
>>>                     clear on that as we could be.
>>>
>>>                     After looking over everyone's comments so far,
>>>                     I'd like to propose the following text for that
>>>                     section:
>>>
>>>
>>>                         scope
>>>
>>>                            OPTIONAL.  Space separated list of scope values (as described in
>>>
>>>                            OAuth 2.0Section 3.3 [RFC6749]  ) that the client can use when
>>>
>>>                            requesting access tokens.  As scope values are service-specific,
>>>
>>>                            the Authorization Server MAY define its own matching rules when
>>>
>>>                            determining if a scope value used during an authorization request
>>>
>>>                            is valid according to the scope values assigned during
>>>
>>>                            registration. Possible matching rules include wildcard patterns,
>>>
>>>                            regular expressions, or exactly matching the string. If omitted,
>>>
>>>                            an Authorization Server MAY register a Client with a default
>>>
>>>                            set of scopes.
>>>
>>>
>>>                     Comments? Improvements?
>>>
>>>                      -- Justin
>>>
>>>
>>>                     On 04/14/2013 08:23 PM, Manger, James H wrote:
>>>
>>>                         Presumably at app registration time any scope specification is really a constraint on the scope values that can be requested in an authorization flow.
>>>
>>>                           
>>>
>>>                         So ideally registration should accept rules for matching scopes, as opposed to actual scope values.
>>>
>>>                           
>>>
>>>                         You can try to use scope values as their own matching rules. That is fine for a small set of "static" scopes. It starts to fail when there are a large number of scopes, or scopes that can include parameters (resource paths? email addresses?). You can try to patch those failures by allowing services to define service-specific special "wildcard" scope values that can only be used during registration (eg "read:*").
>>>
>>>                           
>>>
>>>                         Alternatively, replace 'scope' in registration with 'scope_regex' that holds a regular expression that all scope values in an authorization flow must match.
>>>
>>>                           
>>>
>>>                         --
>>>
>>>                         James Manger
>>>
>>>                         _______________________________________________
>>>
>>>                         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
>


--------------060705030801020905080507
Content-Type: text/html; charset="windows-1252"
Content-Transfer-Encoding: 8bit


  
    
  
  
    I wholeheartedly agree that scope at registration is a useful part
    of the lifecycle (and indeed, a required part of our own
    implementation of this very functionality). But the way I read it,
    the requirement of "all scopes ... MAY use" is too restrictive and
    it's open to misinterpretation, I think. If a client registers for
    "A" but asks for "A:b?param=foo", is that OK? This is the pattern
    that we've been talking about using with Blue Button [1], but it
    seems precluded by this definition if you've got a tight definition
    of "MAY use". In the case of simple strings, it's adequate, and I
    think that's the common case, but we don't want to restrict the
    usefulness of this field to the simple case. I had tried to address
    this with enumerating string matching and other things, others have
    suggested defining a regular expression language, but at the end of
    the day I don't think any of that actually buys you much
    interoperability.

    

     -- Justin

    

    [1] http://blue-button.github.io/blue-button-plus-pull/

    

    
On 04/18/2013 01:54 PM, Phil Hunt
      wrote:

    

    

      
      Why not:
      


      

      

        
"A value corresponding to scope as described in OAuth 2,
          Section 3.3 [RFC6749]. The registered Client may use these to
          indicate all of the scopes that a client MAY use when
          requesting tokens from an Authorization Server."

      

      


      

      
In the above, I avoid re-defining scope at all. However
        describing why they are included in registration is useful.
         IMHO I think scope at registration is useful for life-cycle
        approval workflows.

      


      

      
In some cases you could say they are also the default list,
        but I'm not sure it helps inter-operability so its not clear it
        needs to be mentioned.

      


      

      

        
        

        

          
On 2013-04-18, at 10:47 AM, Justin Richer wrote:

          

          

            
 Thing is, there's
              nothing normative about the enforcing statement that I
              made below, so I don't think it's any more restrictive
              than RFC 6749 which lets the AS replace a client's
              requested scopes at the time of token issuance with
              whatever it pleases. But that said, I'd be just as happy
              to leave it like this with no further restrictions:

              

              Space-separated list of scope
                values (as described in OAuth 2.0 Section 3.3
                    [RFC6749]) that the Client can use when
                requesting access tokens from the Authorization Server.

                

              And call it a day. This
              parallels the text for grant_types ("Array of OAuth 2.0
              grant types that the Client may use [when accessing the
              Token Endpoint].") and response_types ("Array of the OAuth
              2.0 response types that the Client may use [when accessing
              the Authorization Endpoint]."), and I think this is the
              correct approach. I only started to add the restrictive
              text because I thought that people were making the
              argument that it was necessary -- I'd rather not have it.

              Plus, it's an optional field in the metadata, so if you've
              got structured scopes where this doesn't make sense, don't
              use it. If you don't do a per-client scope restriction,
              don't use it. 

              

              The interoperability is defined in light of the
              interoperability of scopes themselves: this is a field to
              request/grant a bag of strings that only make sense in
              light of a given API. For that to make real sense, I think
              that we need to differentiate an OAuth client as a generic
              *library* from an OAuth client as a generic accessing
              *application*. It's very useful for a generic *library*
              that handles the authorization layer for an application to
              have a slot for registering scopes and finding out what
              scopes the app's been registered for. It's up to the app
              (not the library) to figure out how to translate those
              into scopes to ask for at authorization time. Sometimes
              that means just passing the string, and sometimes it means
              the construction of a structured value like "urn:example:channel=HBO&urn:example:rating=G,PG-13".

                The library doesn't care, the application does, and we
                should focus on interoperability from the library's
                perspective. Similarly, on the server side, the
              libraries will tell you the bag of scopes that the client
              was registered for, and what bag of scopes the client
              asked for during authorization. It's up to the server
              *application* to harmonize those two in a way that makes
              sense for the API that it's protecting. Just like it's up
              to the protected resource *application* to figure out what
              a scope means in a given context.

              

              So let's just leave it unrestricted but keep the slot for
              communicating this piece of information with the same
              semantics that the communication between the client and
              server take on for every other field: client asks for a
              thing, server says that client actually gets a thing, and
              it's implicitly up to the server to do the right thing and
              enforce things in a way that makes sense for the
              application no matter what the client does. 

              

              To take Tony's example, client requests no scopes at
              registration, server grants scope "A" at registration.
              Client then requests scope "X" at authorization, server is
              free to deny the request (invalid_scope error), allow
              authorization because it knows how "A" and "X" are
              related, require user intervention, or really, whatever it
              likes. The libraries, where I argue the interoperability
              cries really matter, don't care, and shouldn't care.

              

               -- Justin

              

              
On 04/18/2013 01:04 PM, Mike
                Jones wrote:

              

              

                
                
                

                  
Saying

                      anything normative about “enforcing restrictions”
                      is going beyond RFC 6749 semantics.  Indeed, you’d
                      said that “I agree that we shouldn't try to
                    "solve" scope in registration.”,

                      but talking about restrictions is going down the
                      slippery “solving it” path.

                  
 

                  
At

                      most we can say that the two parties are making
                      declarations to one another about scopes that they
                      may choose to use, but we can’t assume that this
                      is an exclusive list and that other scope values
                      such as “urn:example:channel=HBO&urn:example:rating=G,PG-13”
                      might not be used, even if the client registers
                      saying that it intends to use the “OATC” scope
                      value.  We could maybe even say that some services
                      may use a static set of scopes and might choose to
                      limit the scopes that a client may use to those
                      that it declared to the server or to those that
                      the server returned to the client.  That’s a HINT
                      that some services might do this.  But we can’t
                      say anything normative about such possible
                      behaviors, because it goes beyond RFC 6749.

                  
 

                  
                                                           

                      -- Mike

                  
 

                  

                    

                      
From:
                          Richer, Justin P. [mailto:jricher@mitre.org]
                          

                          Sent: Thursday, April 18, 2013 9:26 AM

                          To: Anthony Nadalin

                          Cc: Tim Bray; Mike Jones; oauth@ietf.org

                          Subject: Re: [OAUTH-WG] Registration:
                          Scope Values

                    

                  

                  
 

                  

                    
This doesn't actually break the
                      semantics because the client MUST accept what the
                      server tells it over anything that it asks for in
                      the first place. The server has the final say. So
                      in this case, if your client asks for nothing, the
                      server says "A B C", the client now knows it can
                      ask for "A B C" scopes. 

                  

                  

                    
 

                  

                  

                    
I'm still in favor of not
                      putting the restricting language in the scope
                      definition at all, instead have it say something
                      like:

                  

                  

                    
 

                  

                  

                    

                      

                        

                          
“Space-separated list
                              of scope values (as described in OAuth
                              2.0 Section 3.3
                                  [RFC6749]) that the Client
                              can use when requesting access tokens from
                              the Authorization Server. As scope values
                              are service specific, the means of the
                              Authorization Server enforcing this
                              restriction are outside the scope of this
                              specification.”

                        

                      

                    

                    
 

                  

                  

                    
Couple this with the overall
                      paragraph that says that the client is requesting
                      values that the server is potentially overriding
                      with its declarations, and I think that addresses
                      everything without getting into confusing language
                      that doesn't add to interoperability. 

                  

                  

                    
 

                  

                  

                    
 -- Justin

                  

                  

                    
 

                    

                      

                        
On Apr 18, 2013, at 12:13
                          PM, Anthony Nadalin <tonynad@microsoft.com>

                          wrote:

                      

                      


                        

                        

                      

                        

                          
If

                              I don’t specify a scope, then the server
                              can allocate a default (or default set),
                              thus that breaks the semantics you
                              describe

                        

                        

                          
 

                        

                        

                          
From: oauth-bounces@ietf.org
                              [mailto:oauth-bounces@ietf.org] On
                                Behalf Of Tim

                              Bray

                              Sent: Thursday,

                              April 18, 2013 9:04 AM

                              To: Mike

                              Jones

                              Cc: oauth@ietf.org

                              Subject: Re:

                              [OAUTH-WG] Registration: Scope Values

                        

                        

                          
 

                        

                        

                          

                            
I’m unconvinced, Mike.
                               Obviously you’re right about the
                              looseness of OAuth2 scope specification,
                              but this is a very specific semantic of
                              what happens when you register, and I
                              don’t think we’re bound by history here.  
                              If we can’t safely say anything about what
                              the list of scopes means, then I'm with
                              you let's take them out.  But the most
                              obvious intended semantic is (from the
                              client) “I promise to ask only for these”
                              and from the server “These are the only
                              ones I’ll give you tokens for.”  Or does
                              someone have use-cases for an alternative
                              semantic?

                          

                          

                            

                              
 

                            

                          

                          

                            

                              
To make this
                                concrete, I propose the following:

                            

                          

                          

                            

                              
“Space-separated
                                  list of scope values (as described in
                                  OAuth 2.0 Section 3.3
                                      [RFC6749]) that the
                                  client is declaring to the server that
                                  it will restrict itself to when
                                  requesting access tokens, and that the
                                  server is declaring to the client that
                                  it is registered to use when
                                  requesting access tokens.  Clients SHOULD assume that
                                  servers will refuse to grant access
                                  tokens for scopes not in the list
                                  provided by the server.”

                            

                            

                              

                                
 

                              

                            

                          

                        

                        

                          
 

                          

                            

                              
On Thu, Apr 18, 2013
                                at 8:55 AM, Mike Jones <Michael.Jones@microsoft.com>

                                wrote:

                            

                            

                              

                                
I
                                    don’t think it’s possible to define
                                    what it means in an interoperable
                                    way because OAuth didn’t specify
                                    scopes in an interoperable way.  No,
                                    I don’t like that either, but I
                                    think that’s where things are. 
                                    That’s why I was advocating deleting
                                    this registration feature entirely.

                              

                              

                                
 

                              

                              

                                
But

                                    understanding it might be useful in
                                    some contexts, I’m OK keeping it,
                                    provided we be clear that the
                                    semantics of “registered to use” are
                                    service-specific.

                              

                              

                                
 

                              

                              

                                
                                                           

                                    -- Mike

                              

                              

                                
 

                              

                              

                                
From: Tim


                                    Bray [mailto:twbray@google.com] 

                                    Sent: Thursday,

                                    April 18, 2013 8:36 AM

                                    To: Mike

                                    Jones

                                    Cc: Justin

                                    Richer; oauth@ietf.org

                              

                              

                                

                                  


                                    Subject: Re:

                                    [OAUTH-WG] Registration: Scope
                                    Values

                                

                              

                              

                                

                                  
 

                                

                                

                                  

                                    
On the
                                      server-to-client side, what does
                                      “registered to use” mean?  Does it
                                      mean that the client should assume
                                      that any scopes not on the list
                                      WILL not be granted, MAY not be
                                      granted.... or what?  Is this
                                      already covered elsewhere? -T

                                  

                                

                                

                                  
 

                                  

                                    

                                      
On Thu, Apr
                                        18, 2013 at 8:28 AM, Mike Jones
                                        <Michael.Jones@microsoft.com>

                                        wrote:

                                    

                                    

                                      

                                        
Thanks,

                                            Justin.  I agree with the
                                            need for the generic
                                            two-sided language.  I’d
                                            still keep this language for
                                            scope, because we want to
                                            capture the “declaring”
                                            aspect in this case:

                                      

                                      

                                        

                                          
 

                                        

                                        

                                          
“Space
                                              separated list of scope
                                              values (as described in
                                              OAuth 2.0 Section 3.3

                                                  [RFC6749])
                                              that the client is
                                              declaring to the server
                                              that it may use when
                                              requesting access tokens
                                              and that the server is
                                              declaring to the client
                                              that it is registered to
                                              use when requesting access
                                              tokens.”.

                                        

                                        

                                          
 

                                        

                                      

                                      

                                        
You

                                            should probably also
                                            reinforce that scope values
                                            are service-specific and may
                                            not consist only of a static
                                            set of string values, and
                                            that therefore, in some
                                            cases, an exhaustive list of
                                            registered scope values is
                                            not possible.

                                      

                                      

                                        
 

                                      

                                      

                                        
                                                           

                                            -- Mike

                                      

                                      

                                        
 

                                      

                                      

                                        

                                          

                                            
From: Justin


                                                Richer [mailto:jricher@mitre.org] 

                                                Sent: Monday,

                                                April 15, 2013 12:29 PM

                                          

                                          

                                            

                                              


                                                To: Mike

                                                Jones

                                                Cc: Tim

                                                Bray; oauth@ietf.org

                                                Subject: Re:

                                                [OAUTH-WG] Registration:
                                                Scope Values

                                            

                                          

                                        

                                      

                                      

                                        

                                          
 

                                        

                                        
I
                                          think that because the
                                          "declaration" issue affects
                                          all parameters in the list,
                                          not just scope, we should
                                          adopt this in a higher level
                                          paragraph and leave it out of
                                          the individual parameter
                                          descriptions. Thus, something
                                          like this inserted as the
                                          second paragraph in section 2:

                                        

                                          
The
                                            client metadata values serve
                                            two parallel purposes in the
                                            overall OAuth Dynamic
                                            Registration protocol: 

                                            

                                             - the Client requesting its
                                            desired values for each
                                            parameter to the
                                            Authorization Server in a
                                            [register] or [update]
                                            request,

                                             - the Authorization Server
                                            informing the Client of the
                                            current values of each
                                            parameter that the Client
                                            has been registered to use
                                            through a [client
                                            information response]. 

                                            

                                            An Authorization Server MAY
                                            override any value that a
                                            Client requests during the
                                            registration process
                                            (including any omitted
                                            values) and replace the
                                            requested value with a
                                            default. The normative
                                            indications in the following
                                            list apply to the Client's
                                            declaration of its desired
                                            values. 

                                            

                                            The Authorization Server
                                            SHOULD provide documentation
                                            for any fields that it
                                            requires to be filled in by
                                            the client or to have
                                            particular values or
                                            formats. Extensions and
                                            profiles...

                                        

                                        


                                          And then remove the
                                          sidedness-language from the
                                          scope parameter and any other
                                          parameters where it might have
                                          crept in inadvertently. 

                                          

                                           -- Justin

                                        

                                          

                                            
On
                                              04/15/2013 01:29 PM, Mike
                                              Jones wrote:

                                          

                                        

                                        

                                          

                                            
We

                                                could fix the one-sided
                                                language by changing

                                          

                                          

                                            
“Space

                                                separated list of scope
                                                values (as described in
                                                OAuth 2.0 Section 3.3


                                                    [RFC6749])
                                                that the client is
                                                declaring that it may
                                                use when requesting
                                                access tokens.”

                                          

                                          

                                            
to

                                          

                                          

                                            
“Space

                                                separated list of scope
                                                values (as described in
                                                OAuth 2.0 Section 3.3


                                                    [RFC6749])
                                                that the client is
                                                declaring to the server
                                                that it may use when
                                                requesting access tokens
                                                and that the server is
                                                declaring to the client
                                                that it is registered to
                                                use when requesting
                                                access tokens.”.

                                          

                                          

                                            
 

                                          

                                          

                                            
Again,

                                                I chose the “registered
                                                to use” language
                                                carefully – because in
                                                the general case it’s
                                                not a restriction on the
                                                values that the client
                                                can use – just a
                                                statement by the server
                                                to the client that it is
                                                registered to use those
                                                particular values.  In
                                                both cases, the parties
                                                are making declarations
                                                to one another.

                                          

                                          

                                            
 

                                          

                                          

                                            
If

                                                you adopt that language
                                                (or keep the original
                                                language), then yes, I’d
                                                consider this closed.

                                          

                                          

                                            
 

                                          

                                          

                                            
                                                           

                                                -- Mike

                                          

                                          

                                            
 

                                          

                                          

                                            

                                              

                                                
From: Justin


                                                    Richer [mailto:jricher@mitre.org] 

                                                    Sent: Monday,

                                                    April 15, 2013 9:57
                                                    AM

                                                    To: Mike

                                                    Jones

                                                    Cc: Tim

                                                    Bray; oauth@ietf.org

                                                    Subject: Re: [OAUTH-WG] Registration: Scope
                                                    Values

                                              

                                            

                                          

                                          

                                            
 

                                          

                                          
I
                                            absolutely do not want to
                                            delete this feature, as
                                            (having implemented it) I
                                            think it's very useful. This
                                            is a very established
                                            pattern in manual
                                            registration: I know of
                                            many, many OAuth2 servers
                                            and clients that are set up
                                            where the client must
                                            pre-register a set of
                                            scopes. 

                                            

                                            I don't like the language of
                                            "the client is declaring"
                                            because it's too one-sided.
                                            The client might not have
                                            declared anything, and it
                                            might be the server that's
                                            declaring something to the
                                            client. Deleting the "is
                                            declaring" bit removes that
                                            unintended restriction of
                                            the language while keeping
                                            the original meaning intact.
                                            I actually thought that I
                                            had fixed that before the
                                            last draft went in but
                                            apparently I missed this
                                            one.

                                            

                                            I will work on clarifying
                                            the intent of the whole
                                            metadata set in its
                                            introductory paragraph(s) so
                                            that it's clear that all of
                                            these fields are used in
                                            both of these situations:

                                            

                                             1) The client declaring to
                                            the server its desire to use
                                            a particular value

                                             2) The server declaring to
                                            the client that it has been
                                            registered with a particular
                                            value

                                            

                                            This should hopefully clear
                                            up the issue in the editor's
                                            note that I currently have
                                            at the top of that section
                                            right now, too.

                                            

                                            Mike, since you were the one
                                            who originally brought up
                                            the issue, and you're fine
                                            with the existing text, can
                                            I take this as closed now?
                                            Assuming that you agree with
                                            deleting "is declaring" for
                                            reasons stated above, I'm
                                            fine with leaving everything
                                            else as is and staying quiet
                                            on what the server has to do
                                            with the scopes.

                                            

                                             -- Justin

                                          

                                            

                                              
On
                                                04/15/2013 12:44 PM,
                                                Mike Jones wrote:

                                            

                                          

                                          

                                            

                                              
I
                                                  think that the
                                                  existing wording is
                                                  superior to the
                                                  proposed changed
                                                  wording.  The existing
                                                  wording is:

                                            

                                            

                                              
 

                                            

                                            

                                              
   scope

                                            

                                            

                                              
     
                                                  OPTIONAL.  Space
                                                  separated list of
                                                  scope values (as
                                                  described in

                                            

                                            

                                              
      OAuth
                                                  2.0 Section 3.3 [RFC6749]) that the client
                                                  is declaring that

                                            

                                            

                                              
      it may
                                                  use when requesting
                                                  access tokens.  If
                                                  omitted, an

                                            

                                            

                                              
     
                                                  Authorization Server
                                                  MAY register a Client
                                                  with a default set of

                                            

                                            

                                              
     
                                                  scopes.

                                            

                                            

                                              
 

                                            

                                            

                                              
For

                                                  instance, the current
                                                  “client is declaring”
                                                  wording will always be
                                                  correct, whereas as
                                                  the change to “client
                                                  can use” wording
                                                  implies a restriction
                                                  on client behavior
                                                  that is not always
                                                  applicable.  The
                                                  “client is declaring”
                                                  wording was specific
                                                  and purposefully
                                                  chosen, and I think
                                                  should be retained. 
                                                  In particular, we
                                                  can’t do anything that
                                                  implies that only the
                                                  registered scopes
                                                  values can be used. 
                                                  At the OAuth spec
                                                  level, this is a hint
                                                  as to possible future
                                                  client behavior – not
                                                  a restriction on
                                                  future client
                                                  behavior.

                                            

                                            

                                              
 

                                            

                                            

                                              
Also,

                                                  for the reasons that
                                                  Tim stated, I’m
                                                  strongly against any
                                                  “matching” or “regex”
                                                  language in the spec
                                                  pertaining to scopes –
                                                  as it’s not
                                                  actionable.

                                            

                                            

                                              
 

                                            

                                            

                                              
So

                                                  I’d propose that we
                                                  leave the existing
                                                  scope wording in
                                                  place.  Alternatively,
                                                  I’d also be fine with
                                                  deleting this feature
                                                  entirely, as I don’t
                                                  think it’s useful in
                                                  the general case.

                                            

                                            

                                              
 

                                            

                                            

                                              
                                                           

                                                  -- Mike

                                            

                                            

                                              
 

                                            

                                            

                                              

                                                

                                                  
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]On
                                                        Behalf Of Justin

                                                      Richer

                                                      Sent: Monday, April 15, 2013 8:05 AM

                                                      To: Tim

                                                      Bray; oauth@ietf.org

                                                      Subject: Re: [OAUTH-WG] Registration: Scope
                                                      Values

                                                

                                              

                                            

                                            

                                              
 

                                            

                                            
On

                                              04/15/2013 10:52 AM, Tim
                                              Bray wrote:

                                              

                                              

                                              

                                            

                                              

                                                
I’d
                                                  use the existing
                                                  wording; it’s
                                                  perfectly clear.
                                                   Failing that, if
                                                  there’s strong demand
                                                  for registration of
                                                  structured scopes,
                                                  bless the use of
                                                  regexes, either PCREs
                                                  or some careful
                                                  subset.

                                              

                                            

                                            


                                              Thanks for the feedback --
                                              Of these two choices, I'd
                                              rather leave it as-is. 

                                              

                                              

                                              

                                              

                                            

                                              

                                                

                                                  
 

                                                

                                              

                                              

                                                

                                                  
However,

                                                    I’d subtract the
                                                    sentence “If
                                                    omitted, an
                                                    Authorization Server
                                                    MAY register a
                                                    Client with a
                                                    default set of
                                                     scopes.”  It adds
                                                    no value; if the
                                                    client doesn’t
                                                    declare scopes, the
                                                    client doesn’t
                                                    declare scopes,
                                                    that’s all.  -T

                                                

                                              

                                            

                                            


                                              Remember, all of these
                                              fields aren't just for the
                                              client *request*, they're
                                              also for the server's
                                              *response* to either a
                                              POST, PUT, or GET request.
                                              (I didn't realize it, but
                                              perhaps the wording as
                                              stated right now doesn't
                                              make that clear -- I need
                                              to fix that.) The value
                                              that it adds is if the
                                              client doesn't ask for any
                                              particular scopes, the
                                              server can still assign it
                                              scopes and the client can
                                              do something smart with
                                              that. Dumb clients are
                                              allowed to ignore it if it
                                              doesn't mean anything to
                                              them. 

                                              

                                              This is how our server
                                              implementation actually
                                              works right now. If the
                                              client doesn't ask for
                                              anything specific at
                                              registration, the server
                                              hands it a bag of
                                              "default" scopes. Same
                                              thing happens at auth time
                                              -- if the client doesn't
                                              ask for any particular
                                              scopes, the server hands
                                              it all of its registered
                                              scopes as a default.
                                              Granted, on our server,
                                              scopes are just simple
                                              strings right now, so they
                                              get compared at the auth
                                              endpoint with an exact
                                              string-match metric and
                                              set-based logic. 

                                              

                                               -- Justin

                                              

                                              

                                              

                                              

                                            

                                              
 

                                              

                                                

                                                  
On
                                                    Mon, Apr 15, 2013 at
                                                    7:35 AM, Justin
                                                    Richer <jricher@mitre.org>

                                                    wrote:

                                                

                                                

                                                  

                                                    
What

                                                      would you suggest
                                                      for wording here,
                                                      then? Keeping in
                                                      mind that we
                                                      cannot (and don't
                                                      want to) prohibit
                                                      expression-based
                                                      scopes. 

                                                      

                                                         -- Justin

                                                  

                                                  

                                                    
 

                                                    

                                                      

                                                        
On

                                                          04/15/2013
                                                          10:33 AM, Tim
                                                          Bray wrote:

                                                      

                                                    

                                                    

                                                      

                                                        

                                                          
No,

                                                          I mean it’s
                                                          not
                                                          interoperable
                                                          at the
                                                          software-developer
                                                          level.  I
                                                          can’t register
                                                          scopes at
                                                          authorization
                                                          time with any
                                                          predictable
                                                          effect that I
                                                          can write code
                                                          to support,
                                                          either client
                                                          or server
                                                          side, without
                                                          out-of-line
                                                          non-interoperable
                                                          knowledge
                                                          about the
                                                          behavior of
                                                          the server.  

                                                        

                                                        

                                                          

                                                          
 

                                                          

                                                        

                                                        

                                                          

                                                          
I
                                                          guess I’m just
                                                          not used to
                                                          OAuth’s
                                                          culture of
                                                          having no
                                                          expectation
                                                          that things
                                                          will be
                                                          specified
                                                          tightly enough
                                                          that I can
                                                          write code to
                                                          implement as
                                                          specified.  -T

                                                          

                                                        

                                                      

                                                      

                                                        
 

                                                        

                                                          

                                                          
On

                                                          Mon, Apr 15,
                                                          2013 at 7:15
                                                          AM, Justin
                                                          Richer <jricher@mitre.org> wrote:

                                                          

                                                          

                                                          

                                                          
Scopes

                                                          aren't meant
                                                          to be
                                                          interoperable
                                                          between
                                                          services since
                                                          they're
                                                          necessarily
                                                          API-specific.
                                                          The only
                                                          interoperable
                                                          bit is that
                                                          there's *some*
                                                          place to put
                                                          the values and
                                                          that it's
                                                          expressed as a
                                                          bag of
                                                          space-separated
                                                          strings. How
                                                          those strings
                                                          get
                                                          interpreted
                                                          and enforced
                                                          (which is
                                                          really what's
                                                          at stake here)
                                                          is up to the
                                                          AS and PR (or
                                                          a higher-level
                                                          protocol like
                                                          UMA).

                                                          

                                                           -- Justin

                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          
On

                                                          04/15/2013
                                                          10:13 AM, Tim
                                                          Bray wrote:

                                                          

                                                          

                                                          

                                                          
This, as
                                                          written, has
                                                          zero
                                                          interoperability. 
                                                          I think this
                                                          feature can
                                                          really only be
                                                          made useful in
                                                          the case where
                                                          scopes are
                                                          fixed strings.

                                                          
-T

                                                          

                                                          

                                                          
On

                                                          Apr 15, 2013
                                                          6:54 AM,
                                                          "Justin
                                                          Richer" <jricher@mitre.org> wrote:

                                                          

                                                          

                                                          
You are correct that the idea behind the
                                                          "scope"
                                                          parameter at
                                                          registration
                                                          is a
                                                          constraint on
                                                          authorization-time

                                                          scopes that
                                                          are made
                                                          available.
                                                          It's both a
                                                          means for the
                                                          client to
                                                          request a set
                                                          of valid
                                                          scopes and for
                                                          the server to
                                                          provision (and
                                                          echo back to
                                                          the client) a
                                                          set of valid
                                                          scopes.

                                                          

                                                          I *really*
                                                          don't want to
                                                          try to define
                                                          a matching
                                                          language for
                                                          scope
                                                          expressions.
                                                          For that to
                                                          work, all
                                                          servers would
                                                          need to be
                                                          able to
                                                          process the
                                                          regular
                                                          expressions
                                                          for all
                                                          clients, even
                                                          if the servers
                                                          themselves
                                                          only support
                                                          simple-string
                                                          scope values.
                                                          Any regular
                                                          expression
                                                          syntax we pick
                                                          here is
                                                          guaranteed to
                                                          be
                                                          incompatible
                                                          with
                                                          something, and
                                                          I think the
                                                          complexity
                                                          doesn't buy
                                                          much. Also, I
                                                          think you
                                                          suddenly have
                                                          a potential
                                                          security issue
                                                          if you have a
                                                          bad regex in
                                                          place on
                                                          either end. 

                                                          

                                                          As it stands
                                                          today, the
                                                          server can
                                                          interpret the
                                                          incoming
                                                          registration
                                                          scopes and
                                                          enforce them
                                                          however it
                                                          wants to. The
                                                          real trick
                                                          comes not from
                                                          assigning the
                                                          values to a
                                                          particular
                                                          client but to
                                                          enforcing
                                                          them, and I
                                                          think that's
                                                          always going
                                                          to be
                                                          service-specific.
                                                          We're just not
                                                          as clear on
                                                          that as we
                                                          could be.

                                                          

                                                          After looking
                                                          over
                                                          everyone's
                                                          comments so
                                                          far, I'd like
                                                          to propose the
                                                          following text
                                                          for that
                                                          section:

                                                          

                                                          

                                                          

                                                          
   scope

                                                          
      OPTIONAL.  Space separated list of scope values (as described in

                                                          
      OAuth 2.0 Section 3.3 [RFC6749]) that the client can use when 

                                                          
      requesting access tokens.  As scope values are service-specific, 

                                                          
      the Authorization Server MAY define its own matching rules when

                                                          
      determining if a scope value used during an authorization request

                                                          
      is valid according to the scope values assigned during 

                                                          
      registration. Possible matching rules include wildcard patterns,

                                                          
      regular expressions, or exactly matching the string. If omitted, 

                                                          
      an Authorization Server MAY register a Client with a default 

                                                          
      set of scopes.

                                                          


                                                          Comments?
                                                          Improvements?

                                                          

                                                           -- Justin

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
On

                                                          04/14/2013
                                                          08:23 PM,
                                                          Manger, James
                                                          H wrote:

                                                          

                                                          

                                                          

                                                          
Presumably at app registration time any scope specification is really a constraint on the scope values that can be requested in an authorization flow.

                                                          
 

                                                          
So ideally registration should accept rules for matching scopes, as opposed to actual scope values.

                                                          
 

                                                          
You can try to use scope values as their own matching rules. That is fine for a small set of "static" scopes. It starts to fail when there are a large number of scopes, or scopes that can include parameters (resource paths? email addresses?). You can try to patch those failures by allowing services to define service-specific special "wildcard" scope values that can only be used during registration (eg "read:*").

                                                          
 

                                                          
Alternatively, replace 'scope' in registration with 'scope_regex' that holds a regular expression that all scope values in an authorization flow must match.

                                                          
 

                                                          
--

                                                          
James Manger

                                                          
_______________________________________________

                                                          
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

          

        

        

      

    

    

  


--------------060705030801020905080507--

From jricher@mitre.org  Thu Apr 18 11:15:48 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1D8B21F913C for ; Thu, 18 Apr 2013 11:15:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.86
X-Spam-Level: 
X-Spam-Status: No, score=-5.86 tagged_above=-999 required=5 tests=[AWL=-0.462,  BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, J_CHICKENPOX_26=0.6, 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 gw0JjZQ7PPHZ for ; Thu, 18 Apr 2013 11:15:41 -0700 (PDT)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6787021F920B for ; Thu, 18 Apr 2013 11:15:40 -0700 (PDT)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id F17352650008; Thu, 18 Apr 2013 14:15:39 -0400 (EDT)
Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 4D68D1F0686; Thu, 18 Apr 2013 14:15:39 -0400 (EDT)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.342.3; Thu, 18 Apr 2013 14:15:38 -0400
Message-ID: <5170383E.3070603@mitre.org>
Date: Thu, 18 Apr 2013 14:15:26 -0400
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130329 Thunderbird/17.0.5
MIME-Version: 1.0
To: Tim Bray 
References: <255B9BB34FB7D647A506DC292726F6E1150C74DADA@WSMSG3153V.srv.dir.telstra.com> <516C1714.8070503@mitre.org> <4E1F6AAD24975D4BA5B168042967394367641A87@TK5EX14MBXC283.redmond.corp.microsoft.com> <516C3152.9070603@mitre.org> <4E1F6AAD24975D4BA5B168042967394367641FAB@TK5EX14MBXC283.redmond.corp.microsoft.com> <516C54F2.8040708@mitre.org> <4E1F6AAD24975D4BA5B16804296739436766BCC4@TK5EX14MBXC284.redmond.corp.microsoft.com>  <4E1F6AAD24975D4BA5B16804296739436766C964@TK5EX14MBXC284.redmond.corp.microsoft.com>    <4E1F6AAD24975D4BA5B16804296739436766D8B9@TK5EX14MBXC284.redmond.corp.microsoft.com> <5170319A.5080903@mitre.org> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------060004030703030409040901"
X-Originating-IP: [129.83.31.58]
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: Scope Values
X-BeenThere: oauth@ietf.org
X-Mailman-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, 18 Apr 2013 18:15:48 -0000

--------------060004030703030409040901
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit

Say you're building an application that uses a particular API. You'll be 
building that application to access that API and do stuff. You use 
libraries to handle the OAuth bits for that API, so you do something like:

clientProperties = oauth2.register("http://server/register", "My 
Client", "a b c d", ["http://client/return"]);

The server registers you, and clientProperties gets a client_id, a 
client_name of "My Client", and a scope field of "a b d" since the 
server said you couldn't dynamically register for "c" for whatever reason.

Now let's say that you use the library to request authorization to do 
something on the API. Your app can look inside of clientProperties.scope 
to see what scopes you can do something with. This will have the string 
"a b", which means something (to the app) in the context of the API it's 
registering for, and it knows it wants a token for "a b". Apps are going 
to need to know that, but the library will do what the app tells it to. 
So the app calls the library:

oauth2.authorize("http://server/authorize", "code", "a b", 
"http://client/return", "STATEVALUE@#$I(RJ@#")

A dumb app could even pass in whatever the value of 
clientProperties.scope is (or a blank value) to try to get all of its 
scopes. Or the app could know that the scopes are structured and call:

oauth2.authorize("http://server/authorize", "code", "a:read 
b:readwrite", "http://client/return", "STATEVALUE@#$I(RJ@#")

Eventually you get back a code, then a token:

token = oauth2.token("http://server/token", code, clientProperties)

(note that clientProperties will have the client_id, client_secret, 
redirect_uri, and anything else needed here.)

Now, this token will *also* have a "scope" field. Let's say that the 
user only authorized you for scope "a". If you want to be smart about 
it, you can avoid calling endpoints that require "b". Or you could just 
try it and be prepared to deal with a failing token, like all OAuth 
clients must be able to do anyway.

I hope this makes sense, please forgive the off-the-cuff pseudocode.

  -- Justin


On 04/18/2013 01:56 PM, Tim Bray wrote:
> On Thu, Apr 18, 2013 at 10:47 AM, Justin Richer  > wrote:
>
>     It's very useful for a generic *library* that handles the
>     authorization layer for an application to have a slot for
>     registering scopes and finding out what scopes the app's been
>     registered for.
>
>
> I don’t see how it’s useful in the slightest if there’s no defined 
> semantic for what “registration” actually means, i.e. what result is 
> to be expected when sending or receiving a list of scopes.   -T
>
>
>
>
>     On 04/18/2013 01:04 PM, Mike Jones wrote:
>>
>>     Saying anything normative about “enforcing restrictions” is going
>>     beyond RFC 6749 semantics.  Indeed, you’d said that “I agree that
>>     we shouldn't try to "solve" scope in registration.”, but talking
>>     about restrictions is going down the slippery “solving it” path.
>>
>>     At most we can say that the two parties are making declarations
>>     to one another about scopes that they may choose to use, but we
>>     can’t assume that this is an exclusive list and that other scope
>>     values such as
>>     “urn:example:channel=HBO&urn:example:rating=G,PG-13” might not be
>>     used, even if the client registers saying that it intends to use
>>     the “OATC” scope value.  We could maybe even say that some
>>     services may use a static set of scopes and might choose to limit
>>     the scopes that a client may use to those that it declared to the
>>     server or to those that the server returned to the client. 
>>     That’s a HINT that some services might do this.  But we can’t say
>>     anything normative about such possible behaviors, because it goes
>>     beyond RFC 6749.
>>
>>     -- Mike
>>
>>     *From:*Richer, Justin P. [mailto:jricher@mitre.org]
>>     *Sent:* Thursday, April 18, 2013 9:26 AM
>>     *To:* Anthony Nadalin
>>     *Cc:* Tim Bray; Mike Jones; oauth@ietf.org 
>>     *Subject:* Re: [OAUTH-WG] Registration: Scope Values
>>
>>     This doesn't actually break the semantics because the client MUST
>>     accept what the server tells it over anything that it asks for in
>>     the first place. The server has the final say. So in this case,
>>     if your client asks for nothing, the server says "A B C", the
>>     client now knows it can ask for "A B C" scopes.
>>
>>     I'm still in favor of not putting the restricting language in the
>>     scope definition at all, instead have it say something like:
>>
>>         “Space-separated list of scope values (as described in OAuth
>>         2.0 Section 3.3 [RFC6749]
>>         ) that the
>>         Client can use when requesting access tokens from the
>>         Authorization Server. As scope values are service specific,
>>         the means of the Authorization Server enforcing this
>>         restriction are outside the scope of this specification.”
>>
>>     Couple this with the overall paragraph that says that the client
>>     is requesting values that the server is potentially overriding
>>     with its declarations, and I think that addresses everything
>>     without getting into confusing language that doesn't add to
>>     interoperability.
>>
>>      -- Justin
>>
>>     On Apr 18, 2013, at 12:13 PM, Anthony Nadalin
>>     > wrote:
>>
>>
>>
>>     If I don’t specify a scope, then the server can allocate a
>>     default (or default set), thus that breaks the semantics you describe
>>
>>     *From:*oauth-bounces@ietf.org 
>>     [mailto:oauth-bounces@ietf.org ]*On
>>     Behalf Of*Tim Bray
>>     *Sent:*Thursday, April 18, 2013 9:04 AM
>>     *To:*Mike Jones
>>     *Cc:*oauth@ietf.org 
>>     *Subject:*Re: [OAUTH-WG] Registration: Scope Values
>>
>>     I’m unconvinced, Mike.  Obviously you’re right about the
>>     looseness of OAuth2 scope specification, but this is a very
>>     specific semantic of what happens when you register, and I don’t
>>     think we’re bound by history here.   If we can’t safely say
>>     anything about what the list of scopes means, then I'm with you
>>     let's take them out.  But the most obvious intended semantic is
>>     (from the client) “I promise to ask only for these” and from the
>>     server “These are the only ones I’ll give you tokens for.”  Or
>>     does someone have use-cases for an alternative semantic?
>>
>>     To make this concrete, I propose the following:
>>
>>     “Space-separated list of scope values (as described in OAuth 2.0
>>     Section 3.3 [RFC6749]
>>     ) that the client
>>     is declaring to the server that it will restrict itself to when
>>     requesting access tokens, and that the server is declaring to the
>>     client that it is registered to use when requesting access
>>     tokens. Clients SHOULD assume that servers will refuse to grant
>>     access tokens for scopes not in the list provided by the server.”
>>
>>     On Thu, Apr 18, 2013 at 8:55 AM, Mike Jones
>>     >     > wrote:
>>
>>         I don’t think it’s possible to define what it means in an
>>         interoperable way because OAuth didn’t specify scopes in an
>>         interoperable way.  No, I don’t like that either, but I think
>>         that’s where things are.  That’s why I was advocating
>>         deleting this registration feature entirely.
>>
>>         But understanding it might be useful in some contexts, I’m OK
>>         keeping it, provided we be clear that the semantics of
>>         “registered to use” are service-specific.
>>
>>         -- Mike
>>
>>         *From:*Tim Bray [mailto:twbray@google.com
>>         ]
>>         *Sent:*Thursday, April 18, 2013 8:36 AM
>>         *To:*Mike Jones
>>         *Cc:*Justin Richer;oauth@ietf.org 
>>
>>
>>         *Subject:*Re: [OAUTH-WG] Registration: Scope Values
>>
>>         On the server-to-client side, what does “registered to use”
>>         mean?  Does it mean that the client should assume that any
>>         scopes not on the list WILL not be granted, MAY not be
>>         granted.... or what?  Is this already covered elsewhere? -T
>>
>>         On Thu, Apr 18, 2013 at 8:28 AM, Mike Jones
>>         >         > wrote:
>>
>>         Thanks, Justin.  I agree with the need for the generic
>>         two-sided language.  I’d still keep this language for scope,
>>         because we want to capture the “declaring” aspect in this case:
>>
>>         “Space separated list of scope values (as described in OAuth
>>         2.0Section 3.3 [RFC6749]
>>         ) that the
>>         client is declaring to the server that it may use when
>>         requesting access tokens and that the server is declaring to
>>         the client that it is registered to use when requesting
>>         access tokens.”.
>>
>>         You should probably also reinforce that scope values are
>>         service-specific and may not consist only of a static set of
>>         string values, and that therefore, in some cases, an
>>         exhaustive list of registered scope values is not possible.
>>
>>         -- Mike
>>
>>         *From:*Justin Richer [mailto:jricher@mitre.org
>>         ]
>>         *Sent:*Monday, April 15, 2013 12:29 PM
>>
>>
>>         *To:*Mike Jones
>>         *Cc:*Tim Bray;oauth@ietf.org 
>>         *Subject:*Re: [OAUTH-WG] Registration: Scope Values
>>
>>         I think that because the "declaration" issue affects all
>>         parameters in the list, not just scope, we should adopt this
>>         in a higher level paragraph and leave it out of the
>>         individual parameter descriptions. Thus, something like this
>>         inserted as the second paragraph in section 2:
>>
>>         The client metadata values serve two parallel purposes in the
>>         overall OAuth Dynamic Registration protocol:
>>
>>          - the Client requesting its desired values for each
>>         parameter to the Authorization Server in a [register] or
>>         [update] request,
>>          - the Authorization Server informing the Client of the
>>         current values of each parameter that the Client has been
>>         registered to use through a [client information response].
>>
>>         An Authorization Server MAY override any value that a Client
>>         requests during the registration process (including any
>>         omitted values) and replace the requested value with a
>>         default. The normative indications in the following list
>>         apply to the Client's declaration of its desired values.
>>
>>         The Authorization Server SHOULD provide documentation for any
>>         fields that it requires to be filled in by the client or to
>>         have particular values or formats. Extensions and profiles...
>>
>>
>>         And then remove the sidedness-language from the scope
>>         parameter and any other parameters where it might have crept
>>         in inadvertently.
>>
>>          -- Justin
>>
>>         On 04/15/2013 01:29 PM, Mike Jones wrote:
>>
>>             We could fix the one-sided language by changing
>>
>>             “Space separated list of scope values (as described in
>>             OAuth 2.0Section 3.3 [RFC6749]
>>             ) that
>>             the client is declaring that it may use when requesting
>>             access tokens.”
>>
>>             to
>>
>>             “Space separated list of scope values (as described in
>>             OAuth 2.0Section 3.3 [RFC6749]
>>             ) that
>>             the client is declaring to the server that it may use
>>             when requesting access tokens and that the server is
>>             declaring to the client that it is registered to use when
>>             requesting access tokens.”.
>>
>>             Again, I chose the “registered to use” language carefully
>>             – because in the general case it’s not a restriction on
>>             the values that the client can use – just a statement by
>>             the server to the client that it is registered to use
>>             those particular values.  In both cases, the parties are
>>             making declarations to one another.
>>
>>             If you adopt that language (or keep the original
>>             language), then yes, I’d consider this closed.
>>
>>             -- Mike
>>
>>             *From:*Justin Richer [mailto:jricher@mitre.org]
>>             *Sent:*Monday, April 15, 2013 9:57 AM
>>             *To:*Mike Jones
>>             *Cc:*Tim Bray;oauth@ietf.org 
>>             *Subject:*Re: [OAUTH-WG] Registration: Scope Values
>>
>>             I absolutely do not want to delete this feature, as
>>             (having implemented it) I think it's very useful. This is
>>             a very established pattern in manual registration: I know
>>             of many, many OAuth2 servers and clients that are set up
>>             where the client must pre-register a set of scopes.
>>
>>             I don't like the language of "the client is declaring"
>>             because it's too one-sided. The client might not have
>>             declared anything, and it might be the server that's
>>             declaring something to the client. Deleting the "is
>>             declaring" bit removes that unintended restriction of the
>>             language while keeping the original meaning intact. I
>>             actually thought that I had fixed that before the last
>>             draft went in but apparently I missed this one.
>>
>>             I will work on clarifying the intent of the whole
>>             metadata set in its introductory paragraph(s) so that
>>             it's clear that all of these fields are used in both of
>>             these situations:
>>
>>              1) The client declaring to the server its desire to use
>>             a particular value
>>              2) The server declaring to the client that it has been
>>             registered with a particular value
>>
>>             This should hopefully clear up the issue in the editor's
>>             note that I currently have at the top of that section
>>             right now, too.
>>
>>             Mike, since you were the one who originally brought up
>>             the issue, and you're fine with the existing text, can I
>>             take this as closed now? Assuming that you agree with
>>             deleting "is declaring" for reasons stated above, I'm
>>             fine with leaving everything else as is and staying quiet
>>             on what the server has to do with the scopes.
>>
>>              -- Justin
>>
>>             On 04/15/2013 12:44 PM, Mike Jones wrote:
>>
>>                 I think that the existing wording is superior to the
>>                 proposed changed wording.  The existing wording is:
>>
>>                 scope
>>
>>                 OPTIONAL.  Space separated list of scope values (as
>>                 described in
>>
>>                 OAuth 2.0Section 3.3 [RFC6749]
>>                 )
>>                 that the client is declaring that
>>
>>                 it may use when requesting access tokens. If omitted, an
>>
>>                 Authorization Server MAY register a Client with a
>>                 default set of
>>
>>                 scopes.
>>
>>                 For instance, the current “client is declaring”
>>                 wording will always be correct, whereas as the change
>>                 to “client can use” wording implies a restriction on
>>                 client behavior that is not always applicable.  The
>>                 “client is declaring” wording was specific and
>>                 purposefully chosen, and I think should be retained. 
>>                 In particular, we can’t do anything that implies that
>>                 only the registered scopes values can be used.  At
>>                 the OAuth spec level, this is a hint as to possible
>>                 future client behavior – not a restriction on future
>>                 client behavior.
>>
>>                 Also, for the reasons that Tim stated, I’m strongly
>>                 against any “matching” or “regex” language in the
>>                 spec pertaining to scopes – as it’s not actionable.
>>
>>                 So I’d propose that we leave the existing scope
>>                 wording in place. Alternatively, I’d also be fine
>>                 with deleting this feature entirely, as I don’t think
>>                 it’s useful in the general case.
>>
>>                 -- Mike
>>
>>                 *From:*oauth-bounces@ietf.org
>>                 [mailto:oauth-bounces@ietf.org]*On
>>                 Behalf Of*Justin Richer
>>                 *Sent:*Monday, April 15, 2013 8:05 AM
>>                 *To:*Tim Bray;oauth@ietf.org 
>>                 *Subject:*Re: [OAUTH-WG] Registration: Scope Values
>>
>>                 On 04/15/2013 10:52 AM, Tim Bray wrote:
>>
>>
>>                 I’d use the existing wording; it’s perfectly clear.
>>                  Failing that, if there’s strong demand for
>>                 registration of structured scopes, bless the use of
>>                 regexes, either PCREs or some careful subset.
>>
>>
>>                 Thanks for the feedback -- Of these two choices, I'd
>>                 rather leave it as-is.
>>
>>
>>
>>                 However, I’d subtract the sentence “If omitted, an
>>                 Authorization Server MAY register a Client with a
>>                 default set of  scopes.”  It adds no value; if the
>>                 client doesn’t declare scopes, the client doesn’t
>>                 declare scopes, that’s all.  -T
>>
>>
>>                 Remember, all of these fields aren't just for the
>>                 client *request*, they're also for the server's
>>                 *response* to either a POST, PUT, or GET request. (I
>>                 didn't realize it, but perhaps the wording as stated
>>                 right now doesn't make that clear -- I need to fix
>>                 that.) The value that it adds is if the client
>>                 doesn't ask for any particular scopes, the server can
>>                 still assign it scopes and the client can do
>>                 something smart with that. Dumb clients are allowed
>>                 to ignore it if it doesn't mean anything to them.
>>
>>                 This is how our server implementation actually works
>>                 right now. If the client doesn't ask for anything
>>                 specific at registration, the server hands it a bag
>>                 of "default" scopes. Same thing happens at auth time
>>                 -- if the client doesn't ask for any particular
>>                 scopes, the server hands it all of its registered
>>                 scopes as a default. Granted, on our server, scopes
>>                 are just simple strings right now, so they get
>>                 compared at the auth endpoint with an exact
>>                 string-match metric and set-based logic.
>>
>>                  -- Justin
>>
>>
>>
>>                 On Mon, Apr 15, 2013 at 7:35 AM, Justin Richer
>>                 > wrote:
>>
>>                 What would you suggest for wording here, then?
>>                 Keeping in mind that we cannot (and don't want to)
>>                 prohibit expression-based scopes.
>>
>>                  -- Justin
>>
>>                 On 04/15/2013 10:33 AM, Tim Bray wrote:
>>
>>                     No, I mean it’s not interoperable at the
>>                     software-developer level.  I can’t register
>>                     scopes at authorization time with any predictable
>>                     effect that I can write code to support, either
>>                     client or server side, without out-of-line
>>                     non-interoperable knowledge about the behavior of
>>                     the server.
>>
>>                     I guess I’m just not used to OAuth’s culture of
>>                     having no expectation that things will be
>>                     specified tightly enough that I can write code to
>>                     implement as specified.  -T
>>
>>                     On Mon, Apr 15, 2013 at 7:15 AM, Justin Richer
>>                     > wrote:
>>
>>                     Scopes aren't meant to be interoperable between
>>                     services since they're necessarily API-specific.
>>                     The only interoperable bit is that there's *some*
>>                     place to put the values and that it's expressed
>>                     as a bag of space-separated strings. How those
>>                     strings get interpreted and enforced (which is
>>                     really what's at stake here) is up to the AS and
>>                     PR (or a higher-level protocol like UMA).
>>
>>                      -- Justin
>>
>>                     On 04/15/2013 10:13 AM, Tim Bray wrote:
>>
>>                         This, as written, has zero interoperability.
>>                         I think this feature can really only be made
>>                         useful in the case where scopes are fixed
>>                         strings.
>>
>>                         -T
>>
>>                         On Apr 15, 2013 6:54 AM, "Justin Richer"
>>                         >                         > wrote:
>>
>>                         You are correct that the idea behind the
>>                         "scope" parameter at registration is a
>>                         constraint on authorization-time scopes that
>>                         are made available. It's both a means for the
>>                         client to request a set of valid scopes and
>>                         for the server to provision (and echo back to
>>                         the client) a set of valid scopes.
>>
>>                         I *really* don't want to try to define a
>>                         matching language for scope expressions. For
>>                         that to work, all servers would need to be
>>                         able to process the regular expressions for
>>                         all clients, even if the servers themselves
>>                         only support simple-string scope values. Any
>>                         regular expression syntax we pick here is
>>                         guaranteed to be incompatible with something,
>>                         and I think the complexity doesn't buy much.
>>                         Also, I think you suddenly have a potential
>>                         security issue if you have a bad regex in
>>                         place on either end.
>>
>>                         As it stands today, the server can interpret
>>                         the incoming registration scopes and enforce
>>                         them however it wants to. The real trick
>>                         comes not from assigning the values to a
>>                         particular client but to enforcing them, and
>>                         I think that's always going to be
>>                         service-specific. We're just not as clear on
>>                         that as we could be.
>>
>>                         After looking over everyone's comments so
>>                         far, I'd like to propose the following text
>>                         for that section:
>>
>>
>>                             scope
>>
>>                                OPTIONAL.  Space separated list of scope values (as described in
>>
>>                                OAuth 2.0Section 3.3 [RFC6749]  ) that the client can use when
>>
>>                                requesting access tokens.  As scope values are service-specific,
>>
>>                                the Authorization Server MAY define its own matching rules when
>>
>>                                determining if a scope value used during an authorization request
>>
>>                                is valid according to the scope values assigned during
>>
>>                                registration. Possible matching rules include wildcard patterns,
>>
>>                                regular expressions, or exactly matching the string. If omitted,
>>
>>                                an Authorization Server MAY register a Client with a default
>>
>>                                set of scopes.
>>
>>
>>                         Comments? Improvements?
>>
>>                          -- Justin
>>
>>
>>                         On 04/14/2013 08:23 PM, Manger, James H wrote:
>>
>>                             Presumably at app registration time any scope specification is really a constraint on the scope values that can be requested in an authorization flow.
>>
>>                               
>>
>>                             So ideally registration should accept rules for matching scopes, as opposed to actual scope values.
>>
>>                               
>>
>>                             You can try to use scope values as their own matching rules. That is fine for a small set of "static" scopes. It starts to fail when there are a large number of scopes, or scopes that can include parameters (resource paths? email addresses?). You can try to patch those failures by allowing services to define service-specific special "wildcard" scope values that can only be used during registration (eg "read:*").
>>
>>                               
>>
>>                             Alternatively, replace 'scope' in registration with 'scope_regex' that holds a regular expression that all scope values in an authorization flow must match.
>>
>>                               
>>
>>                             --
>>
>>                             James Manger
>>
>>                             _______________________________________________
>>
>>                             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
>>
>
>


--------------060004030703030409040901
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: 8bit


  
    
  
  
    Say you're building an application that uses a particular API.
    You'll be building that application to access that API and do stuff.
    You use libraries to handle the OAuth bits for that API, so you do
    something like:

    

    clientProperties = oauth2.register("http://server/register", "My
    Client", "a b c d", ["http://client/return"]);

    

    The server registers you, and clientProperties gets a client_id, a
    client_name of "My Client", and a scope field of "a b d" since the
    server said you couldn't dynamically register for "c" for whatever
    reason.

    

    Now let's say that you use the library to request authorization to
    do something on the API. Your app can look inside of
    clientProperties.scope to see what scopes you can do something with.
    This will have the string "a b", which means something (to the app)
    in the context of the API it's registering for, and it knows it
    wants a token for "a b". Apps are going to need to know that, but
    the library will do what the app tells it to. So the app calls the
    library:

    

    oauth2.authorize("http://server/authorize", "code", "a b",
    "http://client/return", "STATEVALUE@#$I(RJ@#")

    

    A dumb app could even pass in whatever the value of
    clientProperties.scope is (or a blank value) to try to get all of
    its scopes. Or the app could know that the scopes are structured and
    call:

    

    oauth2.authorize("http://server/authorize", "code", "a:read
    b:readwrite", "http://client/return", "STATEVALUE@#$I(RJ@#")

    

    Eventually you get back a code, then a token:

    

    token = oauth2.token("http://server/token", code, clientProperties)

    

    (note that clientProperties will have the client_id, client_secret,
    redirect_uri, and anything else needed here.)

    

    Now, this token will *also* have a "scope" field. Let's say that the
    user only authorized you for scope "a". If you want to be smart
    about it, you can avoid calling endpoints that require "b". Or you
    could just try it and be prepared to deal with a failing token, like
    all OAuth clients must be able to do anyway.

    

    I hope this makes sense, please forgive the off-the-cuff pseudocode.

    

     -- Justin

    

    

    
On 04/18/2013 01:56 PM, Tim Bray wrote:

    

    

      
      
On Thu, Apr 18, 2013 at 10:47 AM, Justin Richer <jricher@mitre.org> wrote:

        

          

            
 

            

              
 It's very useful
                for a generic *library* that handles the authorization
                layer for an application to have a slot for registering
                scopes and finding out what scopes the app's been
                registered for.

            

            


            

            
I don’t see how it’s useful in the slightest if there’s
              no defined semantic for what “registration” actually
              means, i.e. what result is to be expected when sending or
              receiving a list of scopes.   -T

            
 

            

              


                

                  


                    

                    
On 04/18/2013 01:04 PM, Mike Jones wrote:

                    

                    

                      

                        
Saying

                            anything normative about “enforcing
                            restrictions” is going beyond RFC 6749
                            semantics.  Indeed, you’d said that “I
                          agree that we shouldn't try to "solve" scope
                          in registration.”,

                            but talking about restrictions is going down
                            the slippery “solving it” path.

                        
 

                        
At

                            most we can say that the two parties are
                            making declarations to one another about
                            scopes that they may choose to use, but we
                            can’t assume that this is an exclusive list
                            and that other scope values such as “urn:example:channel=HBO&urn:example:rating=G,PG-13”
                            might not be used, even if the client
                            registers saying that it intends to use the
                            “OATC” scope value.  We could maybe even say
                            that some services may use a static set of
                            scopes and might choose to limit the scopes
                            that a client may use to those that it
                            declared to the server or to those that the
                            server returned to the client.  That’s a
                            HINT that some services might do this.  But
                            we can’t say anything normative about such
                            possible behaviors, because it goes beyond
                            RFC 6749.

                        
 

                        
                                                           

                            -- Mike

                        
 

                        

                          

                            
From:
                                Richer, Justin P. [mailto:jricher@mitre.org]
                                

                                Sent: Thursday, April 18, 2013
                                9:26 AM

                                To: Anthony Nadalin

                                Cc: Tim Bray; Mike Jones; oauth@ietf.org

                                Subject: Re: [OAUTH-WG]
                                Registration: Scope Values

                          

                        

                        
 

                        

                          
This doesn't actually
                            break the semantics because the client MUST
                            accept what the server tells it over
                            anything that it asks for in the first
                            place. The server has the final say. So in
                            this case, if your client asks for nothing,
                            the server says "A B C", the client now
                            knows it can ask for "A B C" scopes. 

                        

                        

                          
 

                        

                        

                          
I'm still in favor of not
                            putting the restricting language in the
                            scope definition at all, instead have it say
                            something like:

                        

                        

                          
 

                        

                        

                          

                            

                              

                                
“Space-separated list of
                                    scope values (as described in OAuth
                                    2.0 Section 3.3
                                        [RFC6749]) that the
                                    Client can use when requesting
                                    access tokens from the Authorization
                                    Server. As scope values are service
                                    specific, the means of the
                                    Authorization Server enforcing this
                                    restriction are outside the scope of
                                    this specification.”

                              

                            

                          

                          
 

                        

                        

                          
Couple this with the
                            overall paragraph that says that the client
                            is requesting values that the server is
                            potentially overriding with its
                            declarations, and I think that addresses
                            everything without getting into confusing
                            language that doesn't add to
                            interoperability. 

                        

                        

                          
 

                        

                        

                          
 -- Justin

                        

                        

                          
 

                          

                            

                              
On Apr 18, 2013, at
                                12:13 PM, Anthony Nadalin <tonynad@microsoft.com>

                                wrote:

                            

                            


                              

                            

                            

                              

                                
If

                                    I don’t specify a scope, then the
                                    server can allocate a default (or
                                    default set), thus that breaks the
                                    semantics you describe

                              

                              
                              

                                
From: oauth-bounces@ietf.org
                                    [mailto:oauth-bounces@ietf.org] On
                                      Behalf Of Tim
                                    Bray

                                    Sent: Thursday,
                                    April 18, 2013 9:04 AM

                                    To: Mike Jones

                                    Cc: oauth@ietf.org

                                    Subject: Re:
                                    [OAUTH-WG] Registration: Scope
                                    Values

                              

                              

                                
 

                              

                              

                                

                                  
I’m unconvinced,
                                    Mike.  Obviously you’re right about
                                    the looseness of OAuth2 scope
                                    specification, but this is a very
                                    specific semantic of what happens
                                    when you register, and I don’t think
                                    we’re bound by history here.   If we
                                    can’t safely say anything about what
                                    the list of scopes means, then I'm
                                    with you let's take them out.  But
                                    the most obvious intended semantic
                                    is (from the client) “I promise to
                                    ask only for these” and from the
                                    server “These are the only ones I’ll
                                    give you tokens for.”  Or does
                                    someone have use-cases for an
                                    alternative semantic?

                                

                                

                                  

                                    
 

                                  

                                

                                

                                  

                                    
To make this
                                      concrete, I propose the following:

                                  

                                

                                

                                  

                                    
“Space-separated list
                                        of scope values (as described in
                                        OAuth 2.0 Section 3.3


                                            [RFC6749]) that
                                        the client is declaring to the
                                        server that it will restrict
                                        itself to when requesting access
                                        tokens, and that the server is
                                        declaring to the client that it
                                        is registered to use when
                                        requesting access tokens.  Clients
                                        SHOULD assume that servers will
                                        refuse to grant access tokens
                                        for scopes not in the list
                                        provided by the server.”

                                  

                                  

                                    

                                      
 

                                    

                                  

                                

                              

                              

                                
 

                                

                                  

                                    
On Thu, Apr 18,
                                      2013 at 8:55 AM, Mike Jones <Michael.Jones@microsoft.com>

                                      wrote:

                                  

                                  

                                    

                                      
I
                                          don’t think it’s possible to
                                          define what it means in an
                                          interoperable way because
                                          OAuth didn’t specify scopes in
                                          an interoperable way.  No, I
                                          don’t like that either, but I
                                          think that’s where things
                                          are.  That’s why I was
                                          advocating deleting this
                                          registration feature entirely.

                                    

                                    

                                      
 

                                    

                                    

                                      
But

                                          understanding it might be
                                          useful in some contexts, I’m
                                          OK keeping it, provided we be
                                          clear that the semantics of
                                          “registered to use” are
                                          service-specific.

                                    

                                    

                                      
 

                                    

                                    

                                      
                                                           

                                          -- Mike

                                    

                                    

                                      
 

                                    

                                    

                                      
From: Tim


                                          Bray [mailto:twbray@google.com] 

                                          Sent: Thursday,

                                          April 18, 2013 8:36 AM

                                          To: Mike
                                          Jones

                                          Cc: Justin
                                          Richer; oauth@ietf.org

                                    

                                    

                                      

                                        


                                          Subject: Re:

                                          [OAUTH-WG] Registration: Scope
                                          Values

                                      

                                    

                                    

                                      

                                        
 

                                      

                                      

                                        

                                          
On the
                                            server-to-client side, what
                                            does “registered to use”
                                            mean?  Does it mean that the
                                            client should assume that
                                            any scopes not on the list
                                            WILL not be granted, MAY not
                                            be granted.... or what?  Is
                                            this already covered
                                            elsewhere? -T

                                        

                                      

                                      

                                        
 

                                        

                                          

                                            
On Thu,
                                              Apr 18, 2013 at 8:28 AM,
                                              Mike Jones <Michael.Jones@microsoft.com>

                                              wrote:

                                          

                                          

                                            

                                              
Thanks,

                                                  Justin.  I agree with
                                                  the need for the
                                                  generic two-sided
                                                  language.  I’d still
                                                  keep this language for
                                                  scope, because we want
                                                  to capture the
                                                  “declaring” aspect in
                                                  this case:

                                            

                                            

                                              

                                                
 

                                              

                                              

                                                
“Space
                                                    separated list of
                                                    scope values (as
                                                    described in OAuth
                                                    2.0 Section 3.3 [RFC6749]) that the client
                                                    is declaring to the
                                                    server that it may
                                                    use when requesting
                                                    access tokens and
                                                    that the server is
                                                    declaring to the
                                                    client that it is
                                                    registered to use
                                                    when requesting
                                                    access tokens.”.

                                              

                                              

                                                
 

                                              

                                            

                                            

                                              
You

                                                  should probably also
                                                  reinforce that scope
                                                  values are
                                                  service-specific and
                                                  may not consist only
                                                  of a static set of
                                                  string values, and
                                                  that therefore, in
                                                  some cases, an
                                                  exhaustive list of
                                                  registered scope
                                                  values is not
                                                  possible.

                                            

                                            

                                              
 

                                            

                                            

                                              
                                                           

                                                  -- Mike

                                            

                                            

                                              
 

                                            

                                            

                                              

                                                

                                                  
From: Justin


                                                      Richer [mailto:jricher@mitre.org] 

                                                      Sent: Monday,

                                                      April 15, 2013
                                                      12:29 PM

                                                

                                                

                                                  

                                                    


                                                      To: Mike

                                                      Jones

                                                      Cc: Tim

                                                      Bray; oauth@ietf.org

                                                      Subject: Re:

                                                      [OAUTH-WG]
                                                      Registration:
                                                      Scope Values

                                                  

                                                

                                              

                                            

                                            

                                              

                                                
 

                                              

                                              
I
                                                think that because the
                                                "declaration" issue
                                                affects all parameters
                                                in the list, not just
                                                scope, we should adopt
                                                this in a higher level
                                                paragraph and leave it
                                                out of the individual
                                                parameter descriptions.
                                                Thus, something like
                                                this inserted as the
                                                second paragraph in
                                                section 2:

                                              

                                                
The
                                                  client metadata values
                                                  serve two parallel
                                                  purposes in the
                                                  overall OAuth Dynamic
                                                  Registration protocol: 

                                                  

                                                   - the Client
                                                  requesting its desired
                                                  values for each
                                                  parameter to the
                                                  Authorization Server
                                                  in a [register] or
                                                  [update] request,

                                                   - the Authorization
                                                  Server informing the
                                                  Client of the current
                                                  values of each
                                                  parameter that the
                                                  Client has been
                                                  registered to use
                                                  through a [client
                                                  information response]. 

                                                  

                                                  An Authorization
                                                  Server MAY override
                                                  any value that a
                                                  Client requests during
                                                  the registration
                                                  process (including any
                                                  omitted values) and
                                                  replace the requested
                                                  value with a default.
                                                  The normative
                                                  indications in the
                                                  following list apply
                                                  to the Client's
                                                  declaration of its
                                                  desired values. 

                                                  

                                                  The Authorization
                                                  Server SHOULD provide
                                                  documentation for any
                                                  fields that it
                                                  requires to be filled
                                                  in by the client or to
                                                  have particular values
                                                  or formats. Extensions
                                                  and profiles...

                                              

                                              


                                                And then remove the
                                                sidedness-language from
                                                the scope parameter and
                                                any other parameters
                                                where it might have
                                                crept in inadvertently. 

                                                

                                                 -- Justin

                                              

                                                

                                                  
On
                                                    04/15/2013 01:29 PM,
                                                    Mike Jones wrote:

                                                

                                              

                                              

                                                

                                                  
We

                                                      could fix the
                                                      one-sided language
                                                      by changing

                                                

                                                

                                                  
“Space
                                                      separated list of
                                                      scope values (as
                                                      described in OAuth
                                                      2.0 Section 3.3 [RFC6749]) that the client
                                                      is declaring that
                                                      it may use when
                                                      requesting access
                                                      tokens.”

                                                

                                                

                                                  
to

                                                

                                                

                                                  
“Space
                                                      separated list of
                                                      scope values (as
                                                      described in OAuth
                                                      2.0 Section 3.3 [RFC6749]) that the client
                                                      is declaring to
                                                      the server that it
                                                      may use when
                                                      requesting access
                                                      tokens and that
                                                      the server is
                                                      declaring to the
                                                      client that it is
                                                      registered to use
                                                      when requesting
                                                      access tokens.”.

                                                

                                                

                                                  
 

                                                

                                                

                                                  
Again,

                                                      I chose the
                                                      “registered to
                                                      use” language
                                                      carefully –
                                                      because in the
                                                      general case it’s
                                                      not a restriction
                                                      on the values that
                                                      the client can use
                                                      – just a statement
                                                      by the server to
                                                      the client that it
                                                      is registered to
                                                      use those
                                                      particular
                                                      values.  In both
                                                      cases, the parties
                                                      are making
                                                      declarations to
                                                      one another.

                                                

                                                

                                                  
 

                                                

                                                

                                                  
If

                                                      you adopt that
                                                      language (or keep
                                                      the original
                                                      language), then
                                                      yes, I’d consider
                                                      this closed.

                                                

                                                

                                                  
 

                                                

                                                

                                                  
                                                           

                                                      -- Mike

                                                

                                                

                                                  
 

                                                

                                                

                                                  

                                                    

                                                      
From: Justin


                                                          Richer [mailto:jricher@mitre.org] 

                                                          Sent: Monday,

                                                          April 15, 2013
                                                          9:57 AM

                                                          To: Mike

                                                          Jones

                                                          Cc: Tim

                                                          Bray; oauth@ietf.org

                                                          Subject: Re:

                                                          [OAUTH-WG]
                                                          Registration:
                                                          Scope Values

                                                    

                                                  

                                                

                                                

                                                  
 

                                                

                                                
I
                                                  absolutely do not want
                                                  to delete this
                                                  feature, as (having
                                                  implemented it) I
                                                  think it's very
                                                  useful. This is a very
                                                  established pattern in
                                                  manual registration: I
                                                  know of many, many
                                                  OAuth2 servers and
                                                  clients that are set
                                                  up where the client
                                                  must pre-register a
                                                  set of scopes. 

                                                  

                                                  I don't like the
                                                  language of "the
                                                  client is declaring"
                                                  because it's too
                                                  one-sided. The client
                                                  might not have
                                                  declared anything, and
                                                  it might be the server
                                                  that's declaring
                                                  something to the
                                                  client. Deleting the
                                                  "is declaring" bit
                                                  removes that
                                                  unintended restriction
                                                  of the language while
                                                  keeping the original
                                                  meaning intact. I
                                                  actually thought that
                                                  I had fixed that
                                                  before the last draft
                                                  went in but apparently
                                                  I missed this one.

                                                  

                                                  I will work on
                                                  clarifying the intent
                                                  of the whole metadata
                                                  set in its
                                                  introductory
                                                  paragraph(s) so that
                                                  it's clear that all of
                                                  these fields are used
                                                  in both of these
                                                  situations:

                                                  

                                                   1) The client
                                                  declaring to the
                                                  server its desire to
                                                  use a particular value

                                                   2) The server
                                                  declaring to the
                                                  client that it has
                                                  been registered with a
                                                  particular value

                                                  

                                                  This should hopefully
                                                  clear up the issue in
                                                  the editor's note that
                                                  I currently have at
                                                  the top of that
                                                  section right now,
                                                  too.

                                                  

                                                  Mike, since you were
                                                  the one who originally
                                                  brought up the issue,
                                                  and you're fine with
                                                  the existing text, can
                                                  I take this as closed
                                                  now? Assuming that you
                                                  agree with deleting
                                                  "is declaring" for
                                                  reasons stated above,
                                                  I'm fine with leaving
                                                  everything else as is
                                                  and staying quiet on
                                                  what the server has to
                                                  do with the scopes.

                                                  

                                                   -- Justin

                                                

                                                  

                                                    
On
                                                      04/15/2013 12:44
                                                      PM, Mike Jones
                                                      wrote:

                                                  

                                                

                                                

                                                  

                                                    
I
                                                        think that the
                                                        existing wording
                                                        is superior to
                                                        the proposed
                                                        changed
                                                        wording.  The
                                                        existing wording
                                                        is:

                                                  

                                                  

                                                    
 

                                                  

                                                  

                                                    
  
                                                        scope

                                                  

                                                  

                                                    
     
                                                        OPTIONAL.  Space
                                                        separated list
                                                        of scope values
                                                        (as described in

                                                  

                                                  

                                                    
     
                                                        OAuth 2.0 Section 3.3
                                                          [RFC6749])
                                                        that the client
                                                        is declaring
                                                        that

                                                  

                                                  

                                                    
     
                                                        it may use when
                                                        requesting
                                                        access tokens. 
                                                        If omitted, an

                                                  

                                                  

                                                    
     
                                                        Authorization
                                                        Server MAY
                                                        register a
                                                        Client with a
                                                        default set of

                                                  

                                                  

                                                    
     
                                                        scopes.

                                                  

                                                  

                                                    
 

                                                  

                                                  

                                                    
For

                                                        instance, the
                                                        current “client
                                                        is declaring”
                                                        wording will
                                                        always be
                                                        correct, whereas
                                                        as the change to
                                                        “client can use”
                                                        wording implies
                                                        a restriction on
                                                        client behavior
                                                        that is not
                                                        always
                                                        applicable.  The
                                                        “client is
                                                        declaring”
                                                        wording was
                                                        specific and
                                                        purposefully
                                                        chosen, and I
                                                        think should be
                                                        retained.  In
                                                        particular, we
                                                        can’t do
                                                        anything that
                                                        implies that
                                                        only the
                                                        registered
                                                        scopes values
                                                        can be used.  At
                                                        the OAuth spec
                                                        level, this is a
                                                        hint as to
                                                        possible future
                                                        client behavior
                                                        – not a
                                                        restriction on
                                                        future client
                                                        behavior.

                                                  

                                                  

                                                    
 

                                                  

                                                  

                                                    
Also,

                                                        for the reasons
                                                        that Tim stated,
                                                        I’m strongly
                                                        against any
                                                        “matching” or
                                                        “regex” language
                                                        in the spec
                                                        pertaining to
                                                        scopes – as it’s
                                                        not actionable.

                                                  

                                                  

                                                    
 

                                                  

                                                  

                                                    
So

                                                        I’d propose that
                                                        we leave the
                                                        existing scope
                                                        wording in
                                                        place. 
                                                        Alternatively,
                                                        I’d also be fine
                                                        with deleting
                                                        this feature
                                                        entirely, as I
                                                        don’t think it’s
                                                        useful in the
                                                        general case.

                                                  

                                                  

                                                    
 

                                                  

                                                  

                                                    
                                                           

                                                        -- Mike

                                                  

                                                  

                                                    
 

                                                  

                                                  

                                                    

                                                      

                                                        
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]On
                                                          Behalf Of Justin

                                                          Richer

                                                          Sent: Monday,

                                                          April 15, 2013
                                                          8:05 AM

                                                          To: Tim

                                                          Bray; oauth@ietf.org

                                                          Subject: Re:

                                                          [OAUTH-WG]
                                                          Registration:
                                                          Scope Values

                                                      

                                                    

                                                  

                                                  

                                                    
 

                                                  

                                                  
On

                                                    04/15/2013 10:52 AM,
                                                    Tim Bray wrote:

                                                    

                                                    

                                                  

                                                  

                                                    

                                                      
I’d
                                                        use the existing
                                                        wording; it’s
                                                        perfectly clear.
                                                         Failing that,
                                                        if there’s
                                                        strong demand
                                                        for registration
                                                        of structured
                                                        scopes, bless
                                                        the use of
                                                        regexes, either
                                                        PCREs or some
                                                        careful subset.

                                                    

                                                  

                                                  


                                                    Thanks for the
                                                    feedback -- Of these
                                                    two choices, I'd
                                                    rather leave it
                                                    as-is. 

                                                    

                                                    

                                                    

                                                  

                                                  

                                                    

                                                      

                                                        
 

                                                      

                                                    

                                                    

                                                      

                                                        
However,

                                                          I’d subtract
                                                          the sentence
                                                          “If omitted,
                                                          an
                                                          Authorization
                                                          Server MAY
                                                          register a
                                                          Client with a
                                                          default set of
                                                           scopes.”  It
                                                          adds no value;
                                                          if the client
                                                          doesn’t
                                                          declare
                                                          scopes, the
                                                          client doesn’t
                                                          declare
                                                          scopes, that’s
                                                          all.  -T

                                                      

                                                    

                                                  

                                                  


                                                    Remember, all of
                                                    these fields aren't
                                                    just for the client
                                                    *request*, they're
                                                    also for the
                                                    server's *response*
                                                    to either a POST,
                                                    PUT, or GET request.
                                                    (I didn't realize
                                                    it, but perhaps the
                                                    wording as stated
                                                    right now doesn't
                                                    make that clear -- I
                                                    need to fix that.)
                                                    The value that it
                                                    adds is if the
                                                    client doesn't ask
                                                    for any particular
                                                    scopes, the server
                                                    can still assign it
                                                    scopes and the
                                                    client can do
                                                    something smart with
                                                    that. Dumb clients
                                                    are allowed to
                                                    ignore it if it
                                                    doesn't mean
                                                    anything to them. 

                                                    

                                                    This is how our
                                                    server
                                                    implementation
                                                    actually works right
                                                    now. If the client
                                                    doesn't ask for
                                                    anything specific at
                                                    registration, the
                                                    server hands it a
                                                    bag of "default"
                                                    scopes. Same thing
                                                    happens at auth time
                                                    -- if the client
                                                    doesn't ask for any
                                                    particular scopes,
                                                    the server hands it
                                                    all of its
                                                    registered scopes as
                                                    a default. Granted,
                                                    on our server,
                                                    scopes are just
                                                    simple strings right
                                                    now, so they get
                                                    compared at the auth
                                                    endpoint with an
                                                    exact string-match
                                                    metric and set-based
                                                    logic. 

                                                    

                                                     -- Justin

                                                    

                                                    

                                                    

                                                  

                                                  

                                                    
 

                                                    

                                                      

                                                        
On
                                                          Mon, Apr 15,
                                                          2013 at 7:35
                                                          AM, Justin
                                                          Richer <jricher@mitre.org> wrote:

                                                      

                                                      

                                                        

                                                          
What

                                                          would you
                                                          suggest for
                                                          wording here,
                                                          then? Keeping
                                                          in mind that
                                                          we cannot (and
                                                          don't want to)
                                                          prohibit
                                                          expression-based
                                                          scopes. 

                                                          

                                                           -- Justin

                                                        

                                                        

                                                          
 

                                                          

                                                          

                                                          
On

                                                          04/15/2013
                                                          10:33 AM, Tim
                                                          Bray wrote:

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
No,

                                                          I mean it’s
                                                          not
                                                          interoperable
                                                          at the
                                                          software-developer
                                                          level.  I
                                                          can’t register
                                                          scopes at
                                                          authorization
                                                          time with any
                                                          predictable
                                                          effect that I
                                                          can write code
                                                          to support,
                                                          either client
                                                          or server
                                                          side, without
                                                          out-of-line
                                                          non-interoperable
                                                          knowledge
                                                          about the
                                                          behavior of
                                                          the server.  

                                                          

                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          

                                                          

                                                          
I
                                                          guess I’m just
                                                          not used to
                                                          OAuth’s
                                                          culture of
                                                          having no
                                                          expectation
                                                          that things
                                                          will be
                                                          specified
                                                          tightly enough
                                                          that I can
                                                          write code to
                                                          implement as
                                                          specified.  -T

                                                          

                                                          

                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          
On

                                                          Mon, Apr 15,
                                                          2013 at 7:15
                                                          AM, Justin
                                                          Richer <jricher@mitre.org> wrote:

                                                          

                                                          

                                                          

                                                          
Scopes

                                                          aren't meant
                                                          to be
                                                          interoperable
                                                          between
                                                          services since
                                                          they're
                                                          necessarily
                                                          API-specific.
                                                          The only
                                                          interoperable
                                                          bit is that
                                                          there's *some*
                                                          place to put
                                                          the values and
                                                          that it's
                                                          expressed as a
                                                          bag of
                                                          space-separated
                                                          strings. How
                                                          those strings
                                                          get
                                                          interpreted
                                                          and enforced
                                                          (which is
                                                          really what's
                                                          at stake here)
                                                          is up to the
                                                          AS and PR (or
                                                          a higher-level
                                                          protocol like
                                                          UMA).

                                                          

                                                           -- Justin

                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          
On

                                                          04/15/2013
                                                          10:13 AM, Tim
                                                          Bray wrote:

                                                          

                                                          

                                                          

                                                          
This, as
                                                          written, has
                                                          zero
                                                          interoperability. 
                                                          I think this
                                                          feature can
                                                          really only be
                                                          made useful in
                                                          the case where
                                                          scopes are
                                                          fixed strings.

                                                          
-T

                                                          

                                                          

                                                          
On

                                                          Apr 15, 2013
                                                          6:54 AM,
                                                          "Justin
                                                          Richer" <jricher@mitre.org> wrote:

                                                          

                                                          

                                                          
You are correct that the idea behind the
                                                          "scope"
                                                          parameter at
                                                          registration
                                                          is a
                                                          constraint on
                                                          authorization-time

                                                          scopes that
                                                          are made
                                                          available.
                                                          It's both a
                                                          means for the
                                                          client to
                                                          request a set
                                                          of valid
                                                          scopes and for
                                                          the server to
                                                          provision (and
                                                          echo back to
                                                          the client) a
                                                          set of valid
                                                          scopes.

                                                          

                                                          I *really*
                                                          don't want to
                                                          try to define
                                                          a matching
                                                          language for
                                                          scope
                                                          expressions.
                                                          For that to
                                                          work, all
                                                          servers would
                                                          need to be
                                                          able to
                                                          process the
                                                          regular
                                                          expressions
                                                          for all
                                                          clients, even
                                                          if the servers
                                                          themselves
                                                          only support
                                                          simple-string
                                                          scope values.
                                                          Any regular
                                                          expression
                                                          syntax we pick
                                                          here is
                                                          guaranteed to
                                                          be
                                                          incompatible
                                                          with
                                                          something, and
                                                          I think the
                                                          complexity
                                                          doesn't buy
                                                          much. Also, I
                                                          think you
                                                          suddenly have
                                                          a potential
                                                          security issue
                                                          if you have a
                                                          bad regex in
                                                          place on
                                                          either end. 

                                                          

                                                          As it stands
                                                          today, the
                                                          server can
                                                          interpret the
                                                          incoming
                                                          registration
                                                          scopes and
                                                          enforce them
                                                          however it
                                                          wants to. The
                                                          real trick
                                                          comes not from
                                                          assigning the
                                                          values to a
                                                          particular
                                                          client but to
                                                          enforcing
                                                          them, and I
                                                          think that's
                                                          always going
                                                          to be
                                                          service-specific.
                                                          We're just not
                                                          as clear on
                                                          that as we
                                                          could be.

                                                          

                                                          After looking
                                                          over
                                                          everyone's
                                                          comments so
                                                          far, I'd like
                                                          to propose the
                                                          following text
                                                          for that
                                                          section:

                                                          

                                                          

                                                          

                                                          
   scope

                                                          
      OPTIONAL.  Space separated list of scope values (as described in

                                                          
      OAuth 2.0 Section 3.3 [RFC6749]) that the client can use when 

                                                          
      requesting access tokens.  As scope values are service-specific, 

                                                          
      the Authorization Server MAY define its own matching rules when

                                                          
      determining if a scope value used during an authorization request

                                                          
      is valid according to the scope values assigned during 

                                                          
      registration. Possible matching rules include wildcard patterns,

                                                          
      regular expressions, or exactly matching the string. If omitted, 

                                                          
      an Authorization Server MAY register a Client with a default 

                                                          
      set of scopes.

                                                          


                                                          Comments?
                                                          Improvements?

                                                          

                                                           -- Justin

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
On

                                                          04/14/2013
                                                          08:23 PM,
                                                          Manger, James
                                                          H wrote:

                                                          

                                                          

                                                          

                                                          
Presumably at app registration time any scope specification is really a constraint on the scope values that can be requested in an authorization flow.

                                                          
 

                                                          
So ideally registration should accept rules for matching scopes, as opposed to actual scope values.

                                                          
 

                                                          
You can try to use scope values as their own matching rules. That is fine for a small set of "static" scopes. It starts to fail when there are a large number of scopes, or scopes that can include parameters (resource paths? email addresses?). You can try to patch those failures by allowing services to define service-specific special "wildcard" scope values that can only be used during registration (eg "read:*").

                                                          
 

                                                          
Alternatively, replace 'scope' in registration with 'scope_regex' that holds a regular expression that all scope values in an authorization flow must match.

                                                          
 

                                                          
--

                                                          
James Manger

                                                          
_______________________________________________

                                                          
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

                            

                          

                          
 

                        

                      

                    

                    

                  

                

              

            

          

          

        

      

    

    

  


--------------060004030703030409040901--

From phil.hunt@oracle.com  Thu Apr 18 11:19:01 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 134A021F925A for ; Thu, 18 Apr 2013 11:19:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.349,  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 w2k4rOupTmf2 for ; Thu, 18 Apr 2013 11:18:57 -0700 (PDT)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 082B021F91C3 for ; Thu, 18 Apr 2013 11:18:56 -0700 (PDT)
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r3IIItJ3012973 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 18 Apr 2013 18:18:56 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r3IIItaX003961 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 18 Apr 2013 18:18:55 GMT
Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r3IIIsVn016609; Thu, 18 Apr 2013 18:18:54 GMT
Received: from [192.168.1.14] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 18 Apr 2013 11:17:58 -0700
MIME-Version: 1.0
Message-ID: <272B02C0-9368-4D48-B6CB-9F01C3D23E92@oracle.com>
Date: Thu, 18 Apr 2013 11:17:57 -0700 (PDT)
From: Phil Hunt 
To: Justin Richer 
References: <255B9BB34FB7D647A506DC292726F6E1150C74DADA@WSMSG3153V.srv.dir.telstra.com> <516C1714.8070503@mitre.org> <4E1F6AAD24975D4BA5B168042967394367641A87@TK5EX14MBXC283.redmond.corp.microsoft.com> <516C3152.9070603@mitre.org> <4E1F6AAD24975D4BA5B168042967394367641FAB@TK5EX14MBXC283.redmond.corp.microsoft.com> <516C54F2.8040708@mitre.org> <4E1F6AAD24975D4BA5B16804296739436766BCC4@TK5EX14MBXC284.redmond.corp.microsoft.com>  <4E1F6AAD24975D4BA5B16804296739436766C964@TK5EX14MBXC284.redmond.corp.microsoft.com>    <4E1F6AAD24975D4BA5B16804296739436766D8B9@TK5EX14MBXC284.redmond.corp.microsoft.com> <5170319A.5080903@mitre.org>  <517035CE.7000005@mitre.org>
In-Reply-To: <517035CE.7000005@mitre.org>
X-Mailer: Apple Mail (2.1283)
Content-Type: multipart/alternative; boundary="__1366309134615181232abhmt104.oracle.com"
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: Scope Values
X-BeenThere: oauth@ietf.org
X-Mailman-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, 18 Apr 2013 18:19:01 -0000

--__1366309134615181232abhmt104.oracle.com
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Justin,

I agree. Even in my attempt I was too restrictive.=20
>>> "A value corresponding to scope as described in OAuth 2, Section 3.3 =
[RFC6749]. Scope is provided as a way to indicate the maximum features a =
client may access with scope when requesting access tokens from an OAuth =
2 authorization server.

Hopefully someone can simplify further.

What I've not said, but I don't think it needs to be in the spec is =
that:

* The registration life-cycle management could define what scope a =
client uses out-of-band (e.g. could be policy driven)
* The registration with scope could also imply a default set of scopes.


Phil

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





On 2013-04-18, at 11:05 AM, Justin Richer wrote:

> I wholeheartedly agree that scope at registration is a useful part of =
the lifecycle (and indeed, a required part of our own implementation of =
this very functionality). But the way I read it, the requirement of "all =
scopes ... MAY use" is too restrictive and it's open to =
misinterpretation, I think. If a client registers for "A" but asks for =
"A:b?param=3Dfoo", is that OK? This is the pattern that we've been =
talking about using with Blue Button [1], but it seems precluded by this =
definition if you've got a tight definition of "MAY use". In the case of =
simple strings, it's adequate, and I think that's the common case, but =
we don't want to restrict the usefulness of this field to the simple =
case. I had tried to address this with enumerating string matching and =
other things, others have suggested defining a regular expression =
language, but at the end of the day I don't think any of that actually =
buys you much interoperability.
>=20
>  -- Justin
>=20
> [1] http://blue-button.github.io/blue-button-plus-pull/
>=20
> On 04/18/2013 01:54 PM, Phil Hunt wrote:
>> Why not:
>>=20
>>> "A value corresponding to scope as described in OAuth 2, Section 3.3 =
[RFC6749]. The registered Client may use these to indicate all of the =
scopes that a client MAY use when requesting tokens from an =
Authorization Server."
>>=20
>> In the above, I avoid re-defining scope at all. However describing =
why they are included in registration is useful.  IMHO I think scope at =
registration is useful for life-cycle approval workflows.
>>=20
>> In some cases you could say they are also the default list, but I'm =
not sure it helps inter-operability so its not clear it needs to be =
mentioned.
>>=20
>> Phil
>>=20
>> @independentid
>> www.independentid.com
>> phil.hunt@oracle.com
>>=20
>>=20
>>=20
>>=20
>>=20
>> On 2013-04-18, at 10:47 AM, Justin Richer wrote:
>>=20
>>> Thing is, there's nothing normative about the enforcing statement =
that I made below, so I don't think it's any more restrictive than RFC =
6749 which lets the AS replace a client's requested scopes at the time =
of token issuance with whatever it pleases. But that said, I'd be just =
as happy to leave it like this with no further restrictions:
>>>=20
>>> Space-separated list of scope values (as described in OAuth 2.0 =
Section 3.3 [RFC6749]) that the Client can use when requesting access =
tokens from the Authorization Server.
>>>=20
>>> And call it a day. This parallels the text for grant_types ("Array =
of OAuth 2.0 grant types that the Client may use [when accessing the =
Token Endpoint].") and response_types ("Array of the OAuth 2.0 response =
types that the Client may use [when accessing the Authorization =
Endpoint]."), and I think this is the correct approach. I only started =
to add the restrictive text because I thought that people were making =
the argument that it was necessary -- I'd rather not have it.
>>> Plus, it's an optional field in the metadata, so if you've got =
structured scopes where this doesn't make sense, don't use it. If you =
don't do a per-client scope restriction, don't use it.=20
>>>=20
>>> The interoperability is defined in light of the interoperability of =
scopes themselves: this is a field to request/grant a bag of strings =
that only make sense in light of a given API. For that to make real =
sense, I think that we need to differentiate an OAuth client as a =
generic *library* from an OAuth client as a generic accessing =
*application*. It's very useful for a generic *library* that handles the =
authorization layer for an application to have a slot for registering =
scopes and finding out what scopes the app's been registered for. It's =
up to the app (not the library) to figure out how to translate those =
into scopes to ask for at authorization time. Sometimes that means just =
passing the string, and sometimes it means the construction of a =
structured value like =
"urn:example:channel=3DHBO&urn:example:rating=3DG,PG-13". The library =
doesn't care, the application does, and we should focus on =
interoperability from the library's perspective. Similarly, on the =
server side, the libraries will tell you the bag of scopes that the =
client was registered for, and what bag of scopes the client asked for =
during authorization. It's up to the server *application* to harmonize =
those two in a way that makes sense for the API that it's protecting. =
Just like it's up to the protected resource *application* to figure out =
what a scope means in a given context.
>>>=20
>>> So let's just leave it unrestricted but keep the slot for =
communicating this piece of information with the same semantics that the =
communication between the client and server take on for every other =
field: client asks for a thing, server says that client actually gets a =
thing, and it's implicitly up to the server to do the right thing and =
enforce things in a way that makes sense for the application no matter =
what the client does.=20
>>>=20
>>> To take Tony's example, client requests no scopes at registration, =
server grants scope "A" at registration. Client then requests scope "X" =
at authorization, server is free to deny the request (invalid_scope =
error), allow authorization because it knows how "A" and "X" are =
related, require user intervention, or really, whatever it likes. The =
libraries, where I argue the interoperability cries really matter, don't =
care, and shouldn't care.
>>>=20
>>>  -- Justin
>>>=20
>>> On 04/18/2013 01:04 PM, Mike Jones wrote:
>>>> Saying anything normative about =93enforcing restrictions=94 is =
going beyond RFC 6749 semantics.  Indeed, you=92d said that =93I agree =
that we shouldn't try to "solve" scope in registration.=94, but talking =
about restrictions is going down the slippery =93solving it=94 path.
>>>> =20
>>>> At most we can say that the two parties are making declarations to =
one another about scopes that they may choose to use, but we can=92t =
assume that this is an exclusive list and that other scope values such =
as =93urn:example:channel=3DHBO&urn:example:rating=3DG,PG-13=94 might =
not be used, even if the client registers saying that it intends to use =
the =93OATC=94 scope value.  We could maybe even say that some services =
may use a static set of scopes and might choose to limit the scopes that =
a client may use to those that it declared to the server or to those =
that the server returned to the client.  That=92s a HINT that some =
services might do this.  But we can=92t say anything normative about =
such possible behaviors, because it goes beyond RFC 6749.
>>>> =20
>>>>                                                             -- Mike
>>>> =20
>>>> From: Richer, Justin P. [mailto:jricher@mitre.org]=20
>>>> Sent: Thursday, April 18, 2013 9:26 AM
>>>> To: Anthony Nadalin
>>>> Cc: Tim Bray; Mike Jones; oauth@ietf.org
>>>> Subject: Re: [OAUTH-WG] Registration: Scope Values
>>>> =20
>>>> This doesn't actually break the semantics because the client MUST =
accept what the server tells it over anything that it asks for in the =
first place. The server has the final say. So in this case, if your =
client asks for nothing, the server says "A B C", the client now knows =
it can ask for "A B C" scopes.=20
>>>> =20
>>>> I'm still in favor of not putting the restricting language in the =
scope definition at all, instead have it say something like:
>>>> =20
>>>> =93Space-separated list of scope values (as described in OAuth 2.0 =
Section 3.3 [RFC6749]) that the Client can use when requesting access =
tokens from the Authorization Server. As scope values are service =
specific, the means of the Authorization Server enforcing this =
restriction are outside the scope of this specification.=94
>>>> =20
>>>> Couple this with the overall paragraph that says that the client is =
requesting values that the server is potentially overriding with its =
declarations, and I think that addresses everything without getting into =
confusing language that doesn't add to interoperability.=20
>>>> =20
>>>>  -- Justin
>>>> =20
>>>> On Apr 18, 2013, at 12:13 PM, Anthony Nadalin =
 wrote:
>>>>=20
>>>>=20
>>>> If I don=92t specify a scope, then the server can allocate a =
default (or default set), thus that breaks the semantics you describe
>>>> =20
>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On =
Behalf Of Tim Bray
>>>> Sent: Thursday, April 18, 2013 9:04 AM
>>>> To: Mike Jones
>>>> Cc: oauth@ietf.org
>>>> Subject: Re: [OAUTH-WG] Registration: Scope Values
>>>> =20
>>>> I=92m unconvinced, Mike.  Obviously you=92re right about the =
looseness of OAuth2 scope specification, but this is a very specific =
semantic of what happens when you register, and I don=92t think we=92re =
bound by history here.   If we can=92t safely say anything about what =
the list of scopes means, then I'm with you let's take them out.  But =
the most obvious intended semantic is (from the                          =
     client) =93I promise to ask only for these=94 and from the server =
=93These are the only ones I=92ll give you tokens for.=94  Or does =
someone have use-cases for an alternative semantic?
>>>> =20
>>>> To make this concrete, I propose the following:
>>>> =93Space-separated list of scope values (as described in OAuth 2.0 =
Section 3.3 [RFC6749]) that the client is declaring to the server that =
it will restrict itself to when requesting access tokens, and that the =
server is declaring to the client that it is registered to use when =
requesting access tokens.  Clients SHOULD assume that servers will =
refuse to grant access tokens for scopes not in the list provided by the =
server.=94
>>>> =20
>>>> =20
>>>>=20
>>>> On Thu, Apr 18, 2013 at 8:55 AM, Mike Jones =
 wrote:
>>>> I don=92t think it=92s possible to define what it means in an =
interoperable way because OAuth didn=92t specify scopes in an =
interoperable way.  No, I don=92t like that either, but I think that=92s =
where things are.  That=92s why I was advocating deleting this =
registration feature entirely.
>>>> =20
>>>> But understanding it might be useful in some contexts, I=92m OK =
keeping it, provided we be clear that the semantics of =93registered to =
use=94 are service-specific.
>>>> =20
>>>>                                                             -- Mike
>>>> =20
>>>> From: Tim Bray [mailto:twbray@google.com]=20
>>>> Sent: Thursday, April 18, 2013 8:36 AM
>>>> To: Mike Jones
>>>> Cc: Justin Richer; oauth@ietf.org
>>>>=20
>>>> Subject: Re: [OAUTH-WG] Registration: Scope Values
>>>> =20
>>>> On the server-to-client side, what does =93registered to use=94 =
mean?  Does it mean that the client should assume that any scopes not on =
the list WILL not be granted, MAY not be granted.... or what?  Is this =
already covered elsewhere? -T
>>>> =20
>>>>=20
>>>> On Thu, Apr 18, 2013 at 8:28 AM, Mike Jones =
 wrote:
>>>> Thanks, Justin.  I agree with the need for the generic two-sided =
language.  I=92d still keep this language for scope, because we want to =
capture the =93declaring=94 aspect in this case:
>>>> =20
>>>> =93Space separated list of scope values (as described in OAuth 2.0 =
Section 3.3 [RFC6749]) that the client is declaring to the server that =
it may use when requesting access tokens and that the server is =
declaring to the client that it is registered to use when requesting =
access tokens.=94.
>>>> =20
>>>> You should probably also reinforce that scope values are =
service-specific and may not consist only of a static set of string =
values, and that therefore, in some cases, an exhaustive list of =
registered scope values is not possible.
>>>> =20
>>>>                                                             -- Mike
>>>> =20
>>>> From: Justin Richer [mailto:jricher@mitre.org]=20
>>>> Sent: Monday, April 15, 2013 12:29 PM
>>>>=20
>>>> To: Mike Jones
>>>> Cc: Tim Bray; oauth@ietf.org
>>>> Subject: Re: [OAUTH-WG] Registration: Scope Values
>>>> =20
>>>> I think that because the "declaration" issue affects all parameters =
in the list, not just scope, we should adopt this in a higher level =
paragraph and leave it out of the individual parameter descriptions. =
Thus, something like this inserted as the second paragraph in section 2:
>>>>=20
>>>> The client metadata values serve two parallel purposes in the =
overall OAuth Dynamic Registration protocol:=20
>>>>=20
>>>>  - the Client requesting its desired values for each parameter to =
the Authorization Server in a [register] or [update] request,
>>>>  - the Authorization Server informing the Client of the current =
values of each parameter that the Client has been registered to use =
through a [client information response].=20
>>>>=20
>>>> An Authorization Server MAY override any value that a Client =
requests during the registration process (including any omitted values) =
and replace the requested value with a default. The normative =
indications in the following list apply to the Client's declaration of =
its desired values.=20
>>>>=20
>>>> The Authorization Server SHOULD provide documentation for any =
fields that it requires to be filled in by the client or to have =
particular values or formats. Extensions and profiles...
>>>>=20
>>>> And then remove the sidedness-language from the scope parameter and =
any other parameters where it might have crept in inadvertently.=20
>>>>=20
>>>>  -- Justin
>>>>=20
>>>> On 04/15/2013 01:29 PM, Mike Jones wrote:
>>>> We could fix the one-sided language by changing
>>>> =93Space separated list of scope values (as described in OAuth 2.0 =
Section 3.3 [RFC6749]) that the client is declaring that it may use when =
requesting access tokens.=94
>>>> to
>>>> =93Space separated list of scope values (as described in OAuth 2.0 =
Section 3.3 [RFC6749]) that the client is declaring to the server that =
it may use when requesting access tokens and that the server is =
declaring to the client that it is registered to use when requesting =
access tokens.=94.
>>>> =20
>>>> Again, I chose the =93registered to use=94 language carefully =96 =
because in the general case it=92s not a restriction on the values that =
the client can use =96 just a statement by the server to the client that =
it is registered to use those particular values.  In both cases, the =
parties are making declarations to one another.
>>>> =20
>>>> If you adopt that language (or keep the original language), then =
yes, I=92d consider this closed.
>>>> =20
>>>>                                                             -- Mike
>>>> =20
>>>> From: Justin Richer [mailto:jricher@mitre.org]=20
>>>> Sent: Monday, April 15, 2013 9:57 AM
>>>> To: Mike Jones
>>>> Cc: Tim Bray; oauth@ietf.org
>>>> Subject: Re: [OAUTH-WG] Registration: Scope Values
>>>> =20
>>>> I absolutely do not want to delete this feature, as (having =
implemented it) I think it's very useful. This is a very established =
pattern in manual registration: I know of many, many OAuth2 servers and =
clients that are set up where the client must pre-register a set of =
scopes.=20
>>>>=20
>>>> I don't like the language of "the client is declaring" because it's =
too one-sided. The client might not have declared anything, and it might =
be the server that's declaring something to the client. Deleting the "is =
declaring" bit removes that unintended restriction of the language while =
keeping the original meaning intact. I actually thought that I had fixed =
that before the last draft went in but apparently I missed this one.
>>>>=20
>>>> I will work on clarifying the intent of the whole metadata set in =
its introductory paragraph(s) so that it's clear that all of these =
fields are used in both of these situations:
>>>>=20
>>>>  1) The client declaring to the server its desire to use a =
particular value
>>>>  2) The server declaring to the client that it has been registered =
with a particular value
>>>>=20
>>>> This should hopefully clear up the issue in the editor's note that =
I currently have at the top of that section right now, too.
>>>>=20
>>>> Mike, since you were the one who originally brought up the issue, =
and you're fine with the existing text, can I take this as closed now? =
Assuming that you agree with deleting "is declaring" for reasons stated =
above, I'm fine with leaving everything else as is and staying quiet on =
what the server has to do with the scopes.
>>>>=20
>>>>  -- Justin
>>>>=20
>>>> On 04/15/2013 12:44 PM, Mike Jones wrote:
>>>> I think that the existing wording is superior to the proposed =
changed wording.  The existing wording is:
>>>> =20
>>>>    scope
>>>>       OPTIONAL.  Space separated list of scope values (as described =
in
>>>>       OAuth 2.0 Section 3.3 [RFC6749]) that the client is declaring =
that
>>>>       it may use when requesting access tokens.  If omitted, an
>>>>       Authorization Server MAY register a Client with a default set =
of
>>>>       scopes.
>>>> =20
>>>> For instance, the current =93client is declaring=94 wording will =
always be correct, whereas as the change to =93client can use=94 wording =
implies a restriction on client behavior that is not always applicable.  =
The =93client is declaring=94 wording was specific and purposefully =
chosen, and I think should be retained.  In particular, we can=92t do =
anything that implies that only the registered scopes values can be =
used.  At the OAuth spec level, this is a hint as to possible future =
client behavior =96 not a restriction on future client behavior.
>>>> =20
>>>> Also, for the reasons that Tim stated, I=92m strongly against any =
=93matching=94 or =93regex=94 language in the spec                       =
                            pertaining to scopes =96 as it=92s not =
actionable.
>>>> =20
>>>> So I=92d propose that we leave the existing scope wording in place. =
 Alternatively, I=92d also be fine with deleting this feature entirely, =
as I don=92t think it=92s useful in the general case.
>>>> =20
>>>>                                                             -- Mike
>>>> =20
>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]On =
Behalf Of Justin Richer
>>>> Sent: Monday, April 15, 2013 8:05 AM
>>>> To: Tim Bray; oauth@ietf.org
>>>> Subject: Re: [OAUTH-WG] Registration: Scope Values
>>>> =20
>>>> On 04/15/2013 10:52 AM, Tim Bray wrote:
>>>>=20
>>>>=20
>>>>=20
>>>> I=92d use the existing wording; it=92s perfectly clear.  Failing =
that, if there=92s strong demand for registration of structured scopes, =
bless the use of regexes, either PCREs or some careful subset.
>>>>=20
>>>> Thanks for the feedback -- Of these two choices, I'd rather leave =
it as-is.=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> =20
>>>> However, I=92d subtract the sentence =93If omitted, an =
Authorization Server MAY register a Client with a default set of  =
scopes.=94  It adds no value; if the client doesn=92t declare scopes, =
the client doesn=92t declare scopes, that=92s all.  -T
>>>>=20
>>>> Remember, all of these fields aren't just for the client *request*, =
they're also for the server's *response* to either a POST, PUT, or GET =
request. (I didn't realize it, but perhaps the wording as stated right =
now doesn't make that clear -- I need to fix that.) The value that it =
adds is if the client doesn't ask for any particular scopes, the server =
can still assign it scopes and the client can do something smart with =
that. Dumb clients are allowed to ignore it if it doesn't mean anything =
to them.=20
>>>>=20
>>>> This is how our server implementation actually works right now. If =
the client doesn't ask for anything specific at registration, the server =
hands it a bag of "default" scopes. Same thing happens at auth time -- =
if the client doesn't ask for any particular scopes, the server hands it =
all of its registered scopes as a default. Granted, on our server, =
scopes are just simple strings right now, so they get compared at the =
auth endpoint with an exact string-match metric and set-based logic.=20
>>>>=20
>>>>  -- Justin
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> =20
>>>>=20
>>>> On Mon, Apr 15, 2013 at 7:35 AM, Justin Richer  =
wrote:
>>>> What would you suggest for wording here, then? Keeping in mind that =
we cannot (and don't want to) prohibit expression-based scopes.=20
>>>>=20
>>>>  -- Justin
>>>> =20
>>>>=20
>>>> On 04/15/2013 10:33 AM, Tim Bray wrote:
>>>> No, I mean it=92s not interoperable at the software-developer =
level.  I can=92t register scopes at authorization time with any =
predictable effect that I can write code to support,                     =
                                      either client or server side, =
without out-of-line non-interoperable knowledge about the behavior of =
the server. =20
>>>> =20
>>>> I guess I=92m just not used to OAuth=92s culture of having no =
expectation that things will be specified tightly enough that I can =
write code to implement as specified.  -T
>>>> =20
>>>>=20
>>>> On Mon, Apr 15, 2013 at 7:15 AM, Justin Richer  =
wrote:
>>>> Scopes aren't meant to be interoperable between services since =
they're necessarily API-specific. The only interoperable bit is that =
there's *some* place to put the values and that it's expressed as a bag =
of space-separated strings. How those strings get interpreted            =
                                               and enforced (which is =
really what's at stake here) is up to the AS and PR (or a higher-level =
protocol like UMA).
>>>>=20
>>>>  -- Justin
>>>> =20
>>>>=20
>>>> On 04/15/2013 10:13 AM, Tim Bray wrote:
>>>> This, as written, has zero interoperability.  I think this feature =
can really only be made useful in the case where scopes are fixed =
strings.
>>>>=20
>>>> -T
>>>>=20
>>>> On Apr 15, 2013 6:54 AM, "Justin Richer"  wrote:
>>>> You are correct that the idea behind the "scope" parameter at =
registration is a constraint on authorization-time scopes that are made =
available. It's both a means for the client to request a set of valid =
scopes and for the server to provision (and echo back to the client) a =
set of valid scopes.
>>>>=20
>>>> I *really* don't want to try to define a matching language for =
scope expressions. For that to work, all servers would need to be able =
to process the regular expressions for all clients, even if the servers =
themselves only support simple-string scope values. Any regular =
expression syntax we pick here is guaranteed to be incompatible with =
something, and I think the                                               =
            complexity doesn't buy much. Also, I think you suddenly have =
a potential                                                           =
security issue if you have a bad regex in place on either end.=20
>>>>=20
>>>> As it stands today, the server can interpret the incoming =
registration scopes and enforce them however it wants to. The real trick =
comes not from assigning the values to a particular client but to =
enforcing them, and I                                                    =
       think that's always going to be service-specific. We're just not =
as clear on that as we could be.
>>>>=20
>>>> After looking over everyone's comments so far, I'd like to propose =
the following text for that section:
>>>>=20
>>>>=20
>>>>=20
>>>>    scope
>>>>       OPTIONAL.  Space separated list of scope values (as described =
in
>>>>       OAuth 2.0 Section 3.3 [RFC6749]) that the client can use when=20=

>>>>       requesting access tokens.  As scope values are =
service-specific,=20
>>>>       the Authorization Server MAY define its own matching rules =
when
>>>>       determining if a scope value used during an authorization =
request
>>>>       is valid according to the scope values assigned during=20
>>>>       registration. Possible matching rules include wildcard =
patterns,
>>>>       regular expressions, or exactly matching the string. If =
omitted,=20
>>>>       an Authorization Server MAY register a Client with a default=20=

>>>>       set of scopes.
>>>>=20
>>>> Comments? Improvements?
>>>>=20
>>>>  -- Justin
>>>>=20
>>>>=20
>>>>=20
>>>> On 04/14/2013 08:23 PM, Manger, James H wrote:
>>>> Presumably at app registration time any scope specification is =
really a constraint on the scope values that can be requested in an =
authorization flow.
>>>> =20
>>>> So ideally registration should accept rules for matching scopes, as =
opposed to actual scope values.
>>>> =20
>>>> You can try to use scope values as their own matching rules. That =
is fine for a small set of "static" scopes. It starts to fail when there =
are a large number of scopes, or scopes that can include parameters =
(resource paths? email addresses?). You can try to patch those failures =
by allowing services to define service-specific special "wildcard" scope =
values that can only be used during registration (eg "read:*").
>>>> =20
>>>> Alternatively, replace 'scope' in registration with 'scope_regex' =
that holds a regular expression that all scope values in an =
authorization flow must match.
>>>> =20
>>>> --
>>>> James Manger
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>> =20
>>>>=20
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>=20
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>> =20
>>>=20
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>=20


--__1366309134615181232abhmt104.oracle.com
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


"A value corresponding to =
scope as described in OAuth 2, Section 3.3 [RFC6749]. Scope is provided =
as a way to indicate the maximum features a client may access with scope =
when requesting access tokens from an OAuth 2 authorization =
server.

Hopefully someone can =
simplify further.

What I've not said, but I =
don't think it needs to be in the spec is =
that:

* The registration life-cycle management =
could define what scope a client uses out-of-band (e.g. could be policy =
driven)
* The registration with scope could also imply a =
default set of scopes.







Phil

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








On 2013-04-18, at 11:05 AM, Justin Richer wrote:


 =20
    
 =20
  

    I wholeheartedly agree that scope at registration is a useful part
    of the lifecycle (and indeed, a required part of our own
    implementation of this very functionality). But the way I read it,
    the requirement of "all scopes ... MAY use" is too restrictive and
    it's open to misinterpretation, I think. If a client registers for
    "A" but asks for "A:b?param=3Dfoo", is that OK? This is the pattern
    that we've been talking about using with Blue Button [1], but it
    seems precluded by this definition if you've got a tight definition
    of "MAY use". In the case of simple strings, it's adequate, and I
    think that's the common case, but we don't want to restrict the
    usefulness of this field to the simple case. I had tried to address
    this with enumerating string matching and other things, others have
    suggested defining a regular expression language, but at the end of
    the day I don't think any of that actually buys you much
    interoperability.

    

     -- Justin

    

    [1] http://blue-b=
utton.github.io/blue-button-plus-pull/

    

    
On 04/18/2013 01:54 PM, Phil Hunt
      wrote:

    

    

      
      Why not:
      


      

      

        
"A value corresponding to scope as described in OAuth 2,
          Section 3.3 [RFC6749]. The registered Client may use these to
          indicate all of the scopes that a client MAY use when
          requesting tokens from an Authorization Server."

      

      


      

      
In the above, I avoid re-defining scope at all. However
        describing why they are included in registration is useful.
         IMHO I think scope at registration is useful for =
life-cycle
        approval workflows.

      


      

      
In some cases you could say they are also the default list,
        but I'm not sure it helps inter-operability so its not clear it
        needs to be mentioned.

      


      

      

        
        

        

          
On 2013-04-18, at 10:47 AM, Justin Richer wrote:

          

          

            
 Thing is, there's
              nothing normative about the enforcing statement that I
              made below, so I don't think it's any more restrictive
              than RFC 6749 which lets the AS replace a client's
              requested scopes at the time of token issuance with
              whatever it pleases. But that said, I'd be just as happy
              to leave it like this with no further restrictions:

              

              Space-separated list of scope
                values (as described in OAuth 2.0 Section 3.3
                    [RFC6749]) that the Client can use when
                requesting access tokens from the Authorization =
Server.

                

              And call it a day. This
              parallels the text for grant_types ("Array of OAuth 2.0
              grant types that the Client may use [when accessing the
              Token Endpoint].") and response_types ("Array of the OAuth
              2.0 response types that the Client may use [when accessing
              the Authorization Endpoint]."), and I think this is the
              correct approach. I only started to add the restrictive
              text because I thought that people were making the
              argument that it was necessary -- I'd rather not have =
it.

              Plus, it's an optional field in the metadata, so if you've
              got structured scopes where this doesn't make sense, don't
              use it. If you don't do a per-client scope restriction,
              don't use it. 

              

              The interoperability is defined in light of the
              interoperability of scopes themselves: this is a field to
              request/grant a bag of strings that only make sense in
              light of a given API. For that to make real sense, I think
              that we need to differentiate an OAuth client as a generic
              *library* from an OAuth client as a generic accessing
              *application*. It's very useful for a generic *library*
              that handles the authorization layer for an application to
              have a slot for registering scopes and finding out what
              scopes the app's been registered for. It's up to the app
              (not the library) to figure out how to translate those
              into scopes to ask for at authorization time. Sometimes
              that means just passing the string, and sometimes it means
              the construction of a structured value like "urn:example:channel=3DHBO&urn:example:rating=3DG,PG-13".

                The library doesn't care, the application does, and we
                should focus on interoperability from the library's
                perspective. Similarly, on the server side, the
              libraries will tell you the bag of scopes that the client
              was registered for, and what bag of scopes the client
              asked for during authorization. It's up to the server
              *application* to harmonize those two in a way that makes
              sense for the API that it's protecting. Just like it's up
              to the protected resource *application* to figure out what
              a scope means in a given context.

              

              So let's just leave it unrestricted but keep the slot for
              communicating this piece of information with the same
              semantics that the communication between the client and
              server take on for every other field: client asks for a
              thing, server says that client actually gets a thing, and
              it's implicitly up to the server to do the right thing and
              enforce things in a way that makes sense for the
              application no matter what the client does. 

              

              To take Tony's example, client requests no scopes at
              registration, server grants scope "A" at registration.
              Client then requests scope "X" at authorization, server is
              free to deny the request (invalid_scope error), allow
              authorization because it knows how "A" and "X" are
              related, require user intervention, or really, whatever it
              likes. The libraries, where I argue the interoperability
              cries really matter, don't care, and shouldn't care.

              

               -- Justin

              

              
On 04/18/2013 01:04 PM, =
Mike
                Jones wrote:

              

              

                
                
                
Saying

                      anything normative about =93enforcing =
restrictions=94
                      is going beyond RFC 6749 semantics.  Indeed, =
you=92d
                      said that =93I agree that we shouldn't try =
to
                    "solve" scope in registration.=94,

                      but talking about restrictions is going down the
                      slippery =93solving it=94 =
path.
 
At

                      most we can say that the two parties are making
                      declarations to one another about scopes that they
                      may choose to use, but we can=92t assume that this
                      is an exclusive list and that other scope values
                      such as =93urn:example:channel=3DHBO&urn:example:rating=3DG,PG-13=94
                      might not be used, even if the client registers
                      saying that it intends to use the =93OATC=94 scope
                      value.  We could maybe even say that some =
services
                      may use a static set of scopes and might choose to
                      limit the scopes that a client may use to those
                      that it declared to the server or to those that
                      the server returned to the client.  That=92s =
a HINT
                      that some services might do this.  But we =
can=92t
                      say anything normative about such possible
                      behaviors, because it goes beyond RFC =
6749.
 
        &nbs=
p;            =
            &n=
bsp;           &nbs=
p;            =
 

                      -- Mike
 

                  

                    
From:
                          Richer, Justin P. [mailto:jricher@mitre.org]
                          

                          Sent: Thursday, April 18, 2013 9:26 =
AM

                          To: Anthony Nadalin

                          Cc: Tim Bray; Mike Jones; oauth@ietf.org

                          Subject: Re: [OAUTH-WG] Registration:
                          Scope Values

                    

                  
 

                  
This doesn't actually =
break the
                      semantics because the client MUST accept what the
                      server tells it over anything that it asks for in
                      the first place. The server has the final say. So
                      in this case, if your client asks for nothing, the
                      server says "A B C", the client now knows it can
                      ask for "A B C" scopes. 

                  

                  
 

                  

                  
I'm still in favor of not
                      putting the restricting language in the scope
                      definition at all, instead have it say something
                      like:

                  

                  
 

                  

                  

                    

                      

                        
=93Space-separated =
list
                              of scope values (as described in OAuth
                              2.0 Section 3.3
                                  [RFC6749]) that the Client
                              can use when requesting access tokens from
                              the Authorization Server. As scope values
                              are service specific, the means of the
                              Authorization Server enforcing this
                              restriction are outside the scope of this
                              specification.=94

                        

                      

                    
 

                  

                  
Couple this with the =
overall
                      paragraph that says that the client is requesting
                      values that the server is potentially overriding
                      with its declarations, and I think that addresses
                      everything without getting into confusing language
                      that doesn't add to =
interoperability. 

                  

                  
 

                  

                  
 -- =
Justin

                  

                  
 

                    

                      
On Apr 18, 2013, at =
12:13
                          PM, Anthony Nadalin <tonynad@microsoft.com>

                          wrote:

                      


                        

                        

                      

                        
If

                              I don=92t specify a scope, then the server
                              can allocate a default (or default set),
                              thus that breaks the semantics you
                              describe

                        

                        
                        
From: oauth-bounces@ietf.org
                              [mailto:oauth-bounces@ietf.org] On
                                Behalf Of Tim

                              Bray

                              Sent: Thursday,

                              April 18, 2013 9:04 AM

                              To: Mike

                              Jones

                              Cc: oauth@ietf.org

                              Subject: Re:

                              [OAUTH-WG] Registration: Scope =
Values

                        

                        
 

                        

                        

                          
I=92m unconvinced, =
Mike.
                               Obviously you=92re right about the
                              looseness of OAuth2 scope specification,
                              but this is a very specific semantic of
                              what happens when you register, and I
                              don=92t think we=92re bound by history =
here.  
                              If we can=92t safely say anything about =
what
                              the list of scopes means, then I'm with
                              you let's take them out.  But the =
most
                              obvious intended semantic is (from the
                              client) =93I promise to ask only for =
these=94
                              and from the server =93These are the only
                              ones I=92ll give you tokens for.=94 =
 Or does
                              someone have use-cases for an alternative
                              semantic?

                          

                          

                            
 

                            

                          

                          

                            
To make this
                                concrete, I propose the =
following:

                            

                          

                          

                            
=93Space-separated
                                  list of scope values (as described in
                                  OAuth 2.0 Section 3.3
                                      [RFC6749]) that the
                                  client is declaring to the server that
                                  it will restrict itself to when
                                  requesting access tokens, and that the
                                  server is declaring to the client that
                                  it is registered to use when
                                  requesting access tokens. =
 Clients SHOULD assume that
                                  servers will refuse to grant access
                                  tokens for scopes not in the list
                                  provided by the server.=94

                            

                            

                              
 

                              

                            

                          

                        

                        
 

                          

                            
On Thu, Apr 18, =
2013
                                at 8:55 AM, Mike Jones <Michael.Jones@microsoft.com>

                                wrote:

                            

                            

                              
I
                                    don=92t think it=92s possible to =
define
                                    what it means in an interoperable
                                    way because OAuth didn=92t specify
                                    scopes in an interoperable =
way.  No,
                                    I don=92t like that either, but I
                                    think that=92s where things =
are. 
                                    That=92s why I was advocating =
deleting
                                    this registration feature =
entirely.

                              

                              
 

                              

                              
But

                                    understanding it might be useful in
                                    some contexts, I=92m OK keeping it,
                                    provided we be clear that the
                                    semantics of =93registered to use=94 =
are
                                    =
service-specific.

                              

                              
 

                              

                              
        &nbs=
p;            =
            &n=
bsp;           &nbs=
p;            =
 

                                    -- Mike

                              

                              
 

                              

                              
From: Tim


                                    Bray [mailto:twbray@google.com] 

                                    Sent: Thursday,

                                    April 18, 2013 8:36 AM

                                    To: Mike

                                    Jones

                                    Cc: Justin

                                    Richer; oauth@ietf.org

                              

                              

                                


                                    Subject: Re:

                                    [OAUTH-WG] Registration: Scope
                                    Values

                                

                              

                              

                                
 

                                

                                

                                  
On the
                                      server-to-client side, what does
                                      =93registered to use=94 mean? =
 Does it
                                      mean that the client should assume
                                      that any scopes not on the list
                                      WILL not be granted, MAY not be
                                      granted.... or what?  Is this
                                      already covered elsewhere? =
-T

                                  

                                

                                
 

                                  

                                    
On Thu, =
Apr
                                        18, 2013 at 8:28 AM, Mike Jones
                                        <Michael.Jones@microsoft.com>

                                        wrote:

                                    

                                    

                                      
Thanks,

                                            Justin.  I agree with =
the
                                            need for the generic
                                            two-sided language.  =
I=92d
                                            still keep this language for
                                            scope, because we want to
                                            capture the =93declaring=94
                                            aspect in this =
case:

                                      

                                      

                                        
 

                                        

                                        
=93Space=

                                              separated list of scope
                                              values (as described in
                                              OAuth 2.0 Section 3.3

                                                  [RFC6749])
                                              that the client is
                                              declaring to the server
                                              that it may use when
                                              requesting access tokens
                                              and that the server is
                                              declaring to the client
                                              that it is registered to
                                              use when requesting access
                                              tokens.=94.

                                        

                                        
 

                                        

                                      

                                      
You

                                            should probably also
                                            reinforce that scope values
                                            are service-specific and may
                                            not consist only of a static
                                            set of string values, and
                                            that therefore, in some
                                            cases, an exhaustive list of
                                            registered scope values is
                                            not =
possible.

                                      

                                      
 

                                      

                                      
        &nbs=
p;            =
            &n=
bsp;           &nbs=
p;            =
 

                                            -- =
Mike

                                      

                                      
 

                                      

                                      

                                        

                                          
From: Justin


                                                Richer [mailto:jricher@mitre.org] 

                                                Sent: Monday,

                                                April 15, 2013 12:29 =
PM

                                          

                                          

                                            


                                                To: Mike

                                                Jones

                                                Cc: Tim

                                                Bray; oauth@ietf.org

                                                Subject: Re:

                                                [OAUTH-WG] Registration:
                                                Scope =
Values

                                            

                                          

                                        

                                      

                                      

                                        
 

                                        
I
                                          think that because the
                                          "declaration" issue affects
                                          all parameters in the list,
                                          not just scope, we should
                                          adopt this in a higher level
                                          paragraph and leave it out of
                                          the individual parameter
                                          descriptions. Thus, something
                                          like this inserted as the
                                          second paragraph in section =
2:

                                        
The
                                            client metadata values serve
                                            two parallel purposes in the
                                            overall OAuth Dynamic
                                            Registration protocol: 

                                            

                                             - the Client =
requesting its
                                            desired values for each
                                            parameter to the
                                            Authorization Server in a
                                            [register] or [update]
                                            request,

                                             - the Authorization =
Server
                                            informing the Client of the
                                            current values of each
                                            parameter that the Client
                                            has been registered to use
                                            through a [client
                                            information response]. 

                                            

                                            An Authorization Server MAY
                                            override any value that a
                                            Client requests during the
                                            registration process
                                            (including any omitted
                                            values) and replace the
                                            requested value with a
                                            default. The normative
                                            indications in the following
                                            list apply to the Client's
                                            declaration of its desired
                                            values. 

                                            

                                            The Authorization Server
                                            SHOULD provide documentation
                                            for any fields that it
                                            requires to be filled in by
                                            the client or to have
                                            particular values or
                                            formats. Extensions and
                                            profiles...

                                        


                                          And then remove the
                                          sidedness-language from the
                                          scope parameter and any other
                                          parameters where it might have
                                          crept in inadvertently. 

                                          

                                           -- Justin

                                        

                                          
On
                                              04/15/2013 01:29 PM, Mike
                                              Jones =
wrote:

                                          

                                        

                                        

                                          
We

                                                could fix the one-sided
                                                language by =
changing

                                          

                                          
=93Space

                                                separated list of scope
                                                values (as described in
                                                OAuth 2.0 Section 3.3


                                                    =
[RFC6749])
                                                that the client is
                                                declaring that it may
                                                use when requesting
                                                access =
tokens.=94

                                          

                                          
to

                                          

                                          
=93Space

                                                separated list of scope
                                                values (as described in
                                                OAuth 2.0 Section 3.3


                                                    =
[RFC6749])
                                                that the client is
                                                declaring to the server
                                                that it may use when
                                                requesting access tokens
                                                and that the server is
                                                declaring to the client
                                                that it is registered to
                                                use when requesting
                                                access =
tokens.=94.

                                          

                                          
 

                                          

                                          
Again,

                                                I chose the =93registered
                                                to use=94 language
                                                carefully =96 because in
                                                the general case it=92s
                                                not a restriction on the
                                                values that the client
                                                can use =96 just a
                                                statement by the server
                                                to the client that it is
                                                registered to use those
                                                particular values.  =
In
                                                both cases, the parties
                                                are making declarations
                                                to one =
another.

                                          

                                          
 

                                          

                                          
If

                                                you adopt that language
                                                (or keep the original
                                                language), then yes, I=92d=

                                                consider this =
closed.

                                          

                                          
 

                                          

                                          
        &nbs=
p;            =
            &n=
bsp;           &nbs=
p;            =
 

                                                -- =
Mike

                                          

                                          
 

                                          

                                          

                                            

                                              
From: Justin


                                                    Richer [mailto:jricher@mitre.org] 

                                                    Sent: Monday,

                                                    April 15, 2013 9:57
                                                    AM

                                                    To: Mike

                                                    Jones

                                                    Cc: Tim

                                                    Bray; oauth@ietf.org

                                                    Subject: Re: [OAUTH-WG] =
Registration: Scope
                                                    =
Values

                                              

                                            

                                          

                                          
 

                                          
I
                                            absolutely do not want to
                                            delete this feature, as
                                            (having implemented it) I
                                            think it's very useful. This
                                            is a very established
                                            pattern in manual
                                            registration: I know of
                                            many, many OAuth2 servers
                                            and clients that are set up
                                            where the client must
                                            pre-register a set of
                                            scopes. 

                                            

                                            I don't like the language of
                                            "the client is declaring"
                                            because it's too one-sided.
                                            The client might not have
                                            declared anything, and it
                                            might be the server that's
                                            declaring something to the
                                            client. Deleting the "is
                                            declaring" bit removes that
                                            unintended restriction of
                                            the language while keeping
                                            the original meaning intact.
                                            I actually thought that I
                                            had fixed that before the
                                            last draft went in but
                                            apparently I missed this
                                            one.

                                            

                                            I will work on clarifying
                                            the intent of the whole
                                            metadata set in its
                                            introductory paragraph(s) so
                                            that it's clear that all of
                                            these fields are used in
                                            both of these =
situations:

                                            

                                             1) The client =
declaring to
                                            the server its desire to use
                                            a particular value

                                             2) The server =
declaring to
                                            the client that it has been
                                            registered with a particular
                                            value

                                            

                                            This should hopefully clear
                                            up the issue in the editor's
                                            note that I currently have
                                            at the top of that section
                                            right now, too.

                                            

                                            Mike, since you were the one
                                            who originally brought up
                                            the issue, and you're fine
                                            with the existing text, can
                                            I take this as closed now?
                                            Assuming that you agree with
                                            deleting "is declaring" for
                                            reasons stated above, I'm
                                            fine with leaving everything
                                            else as is and staying quiet
                                            on what the server has to do
                                            with the scopes.

                                            

                                             -- =
Justin

                                          

                                            
On=

                                                04/15/2013 12:44 PM,
                                                Mike Jones =
wrote:

                                            

                                          

                                          

                                            
I
                                                  think that the
                                                  existing wording is
                                                  superior to the
                                                  proposed changed
                                                  wording.  The =
existing
                                                  wording =
is:

                                            

                                            
 

                                            

                                            
   =
scope

                                            

                                            
     
                                                  OPTIONAL.  Space
                                                  separated list of
                                                  scope values (as
                                                  described =
in

                                            

                                            
      OAuth
                                                  2.0 Section 3.3 =
[RFC6749]) that the client
                                                  is declaring =
that

                                            

                                            
      it may
                                                  use when requesting
                                                  access tokens.  =
If
                                                  omitted, =
an

                                            

                                            
     
                                                  Authorization Server
                                                  MAY register a Client
                                                  with a default set =
of

                                            

                                            
     
                                                  =
scopes.

                                            

                                            
 

                                            

                                            
For

                                                  instance, the current
                                                  =93client is =
declaring=94
                                                  wording will always be
                                                  correct, whereas as
                                                  the change to =93client
                                                  can use=94 wording
                                                  implies a restriction
                                                  on client behavior
                                                  that is not always
                                                  applicable.  The
                                                  =93client is =
declaring=94
                                                  wording was specific
                                                  and purposefully
                                                  chosen, and I think
                                                  should be =
retained. 
                                                  In particular, we
                                                  can=92t do anything =
that
                                                  implies that only the
                                                  registered scopes
                                                  values can be =
used. 
                                                  At the OAuth spec
                                                  level, this is a hint
                                                  as to possible future
                                                  client behavior =96 =
not
                                                  a restriction on
                                                  future client
                                                  =
behavior.

                                            

                                            
 

                                            

                                            
Also,

                                                  for the reasons that
                                                  Tim stated, I=92m
                                                  strongly against any
                                                  =93matching=94 or =
=93regex=94
                                                  language in the spec
                                                  pertaining to scopes =96=

                                                  as it=92s not
                                                  =
actionable.

                                            

                                            
 

                                            

                                            
So

                                                  I=92d propose that we
                                                  leave the existing
                                                  scope wording in
                                                  place.  =
Alternatively,
                                                  I=92d also be fine =
with
                                                  deleting this feature
                                                  entirely, as I don=92t
                                                  think it=92s useful in
                                                  the general =
case.

                                            

                                            
 

                                            

                                            
        &nbs=
p;            =
            &n=
bsp;           &nbs=
p;            =
 

                                                  -- =
Mike

                                            

                                            
 

                                            

                                            

                                              

                                                
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]On
                                                        Behalf Of Justin

                                                      Richer

                                                      Sent: Monday, April 15, 2013 8:05 =
AM

                                                      To: Tim

                                                      Bray; oauth@ietf.org

                                                      =
Subject: Re: =
[OAUTH-WG] Registration: Scope
                                                      =
Values

                                                

                                              

                                            

                                            
 

                                            
On

                                              04/15/2013 10:52 AM, Tim
                                              Bray wrote:

                                              

                                              

                                              

                                            

                                              
I=92d
                                                  use the existing
                                                  wording; it=92s
                                                  perfectly clear.
                                                   Failing that, if
                                                  there=92s strong =
demand
                                                  for registration of
                                                  structured scopes,
                                                  bless the use of
                                                  regexes, either PCREs
                                                  or some careful
                                                  subset.

                                              

                                            


                                              Thanks for the feedback --
                                              Of these two choices, I'd
                                              rather leave it =
as-is. 

                                              

                                              

                                              

                                              

                                            

                                              

                                                
 

                                                

                                              

                                              

                                                
However,

                                                    I=92d subtract the
                                                    sentence =93If
                                                    omitted, an
                                                    Authorization Server
                                                    MAY register a
                                                    Client with a
                                                    default set of
                                                     scopes.=94 =
 It adds
                                                    no value; if the
                                                    client doesn=92t
                                                    declare scopes, the
                                                    client doesn=92t
                                                    declare scopes,
                                                    that=92s all. =
 -T

                                                

                                              

                                            


                                              Remember, all of these
                                              fields aren't just for the
                                              client *request*, they're
                                              also for the server's
                                              *response* to either a
                                              POST, PUT, or GET request.
                                              (I didn't realize it, but
                                              perhaps the wording as
                                              stated right now doesn't
                                              make that clear -- I need
                                              to fix that.) The value
                                              that it adds is if the
                                              client doesn't ask for any
                                              particular scopes, the
                                              server can still assign it
                                              scopes and the client can
                                              do something smart with
                                              that. Dumb clients are
                                              allowed to ignore it if it
                                              doesn't mean anything to
                                              them. 

                                              

                                              This is how our server
                                              implementation actually
                                              works right now. If the
                                              client doesn't ask for
                                              anything specific at
                                              registration, the server
                                              hands it a bag of
                                              "default" scopes. Same
                                              thing happens at auth time
                                              -- if the client doesn't
                                              ask for any particular
                                              scopes, the server hands
                                              it all of its registered
                                              scopes as a default.
                                              Granted, on our server,
                                              scopes are just simple
                                              strings right now, so they
                                              get compared at the auth
                                              endpoint with an exact
                                              string-match metric and
                                              set-based logic. 

                                              

                                               -- Justin

                                              

                                              

                                              

                                              

                                            
 

                                              

                                                
On
                                                    Mon, Apr 15, 2013 at
                                                    7:35 AM, Justin
                                                    Richer <jricher@mitre.org>

                                                    =
wrote:

                                                

                                                

                                                  
What

                                                      would you suggest
                                                      for wording here,
                                                      then? Keeping in
                                                      mind that we
                                                      cannot (and don't
                                                      want to) prohibit
                                                      expression-based
                                                      scopes. 

                                                      

                                                         -- =
Justin

                                                  

                                                  
 

                                                    

                                                      
On

                                                          04/15/2013
                                                          10:33 AM, Tim
                                                          Bray =
wrote:

                                                      

                                                    

                                                    

                                                      

                                                        
No,

                                                          I mean it=92s
                                                          not
                                                          interoperable
                                                          at the
                                                          =
software-developer
                                                          level.  I
                                                          can=92t =
register
                                                          scopes at
                                                          authorization
                                                          time with any
                                                          predictable
                                                          effect that I
                                                          can write code
                                                          to support,
                                                          either client
                                                          or server
                                                          side, without
                                                          out-of-line
                                                          =
non-interoperable
                                                          knowledge
                                                          about the
                                                          behavior of
                                                          the server. =
 

                                                        

                                                        

                                                          
 

                                                          

                                                        

                                                        

                                                          
I
                                                          guess I=92m =
just
                                                          not used to
                                                          OAuth=92s
                                                          culture of
                                                          having no
                                                          expectation
                                                          that things
                                                          will be
                                                          specified
                                                          tightly enough
                                                          that I can
                                                          write code to
                                                          implement as
                                                          specified. =
 -T

                                                          

                                                        

                                                      

                                                      
 

                                                        

                                                          
On

                                                          Mon, Apr 15,
                                                          2013 at 7:15
                                                          AM, Justin
                                                          Richer <jricher@mitre.org> =
wrote:

                                                          

                                                          

                                                          
Scopes

                                                          aren't meant
                                                          to be
                                                          interoperable
                                                          between
                                                          services since
                                                          they're
                                                          necessarily
                                                          API-specific.
                                                          The only
                                                          interoperable
                                                          bit is that
                                                          there's *some*
                                                          place to put
                                                          the values and
                                                          that it's
                                                          expressed as a
                                                          bag of
                                                          =
space-separated
                                                          strings. How
                                                          those strings
                                                          get
                                                          interpreted
                                                          and enforced
                                                          (which is
                                                          really what's
                                                          at stake here)
                                                          is up to the
                                                          AS and PR (or
                                                          a higher-level
                                                          protocol like
                                                          UMA).

                                                          

                                                           -- =
Justin

                                                          

                                                          
 

                                                          

                                                          
On

                                                          04/15/2013
                                                          10:13 AM, Tim
                                                          Bray =
wrote:

                                                          

                                                          

                                                          
This, as
                                                          written, has
                                                          zero
                                                          =
interoperability. 
                                                          I think this
                                                          feature can
                                                          really only be
                                                          made useful in
                                                          the case where
                                                          scopes are
                                                          fixed =
strings.
-T

                                                          

                                                          
On

                                                          Apr 15, 2013
                                                          6:54 AM,
                                                          "Justin
                                                          Richer" <jricher@mitre.org> =
wrote:

                                                          

                                                          
You are correct that =
the idea behind the
                                                          "scope"
                                                          parameter at
                                                          registration
                                                          is a
                                                          constraint on
                                                          =
authorization-time

                                                          scopes that
                                                          are made
                                                          available.
                                                          It's both a
                                                          means for the
                                                          client to
                                                          request a set
                                                          of valid
                                                          scopes and for
                                                          the server to
                                                          provision (and
                                                          echo back to
                                                          the client) a
                                                          set of valid
                                                          scopes.

                                                          

                                                          I *really*
                                                          don't want to
                                                          try to define
                                                          a matching
                                                          language for
                                                          scope
                                                          expressions.
                                                          For that to
                                                          work, all
                                                          servers would
                                                          need to be
                                                          able to
                                                          process the
                                                          regular
                                                          expressions
                                                          for all
                                                          clients, even
                                                          if the servers
                                                          themselves
                                                          only support
                                                          simple-string
                                                          scope values.
                                                          Any regular
                                                          expression
                                                          syntax we pick
                                                          here is
                                                          guaranteed to
                                                          be
                                                          incompatible
                                                          with
                                                          something, and
                                                          I think the
                                                          complexity
                                                          doesn't buy
                                                          much. Also, I
                                                          think you
                                                          suddenly have
                                                          a potential
                                                          security issue
                                                          if you have a
                                                          bad regex in
                                                          place on
                                                          either =
end. 

                                                          

                                                          As it stands
                                                          today, the
                                                          server can
                                                          interpret the
                                                          incoming
                                                          registration
                                                          scopes and
                                                          enforce them
                                                          however it
                                                          wants to. The
                                                          real trick
                                                          comes not from
                                                          assigning the
                                                          values to a
                                                          particular
                                                          client but to
                                                          enforcing
                                                          them, and I
                                                          think that's
                                                          always going
                                                          to be
                                                          =
service-specific.
                                                          We're just not
                                                          as clear on
                                                          that as we
                                                          could be.

                                                          

                                                          After looking
                                                          over
                                                          everyone's
                                                          comments so
                                                          far, I'd like
                                                          to propose the
                                                          following text
                                                          for that
                                                          section:

                                                          

                                                          

                                                          =


                                                          =

   scope

                                                          =

      OPTIONAL.  Space separated list =
of scope values (as described in

                                                          =

      OAuth 2.0 Section 3.3 =
[RFC6749]) that the client can use when 

                                                          =

      requesting access tokens.  =
As scope values are service-specific, 

                                                          =

      the Authorization Server MAY =
define its own matching rules when

                                                          =

      determining if a scope value used =
during an authorization request

                                                          =

      is valid according to the scope =
values assigned during 

                                                          =

      registration. Possible matching =
rules include wildcard patterns,

                                                          =

      regular expressions, or exactly =
matching the string. If omitted, 

                                                          =

      an Authorization Server MAY =
register a Client with a default 

                                                          =

      set of =
scopes.


                                                          Comments?
                                                          =
Improvements?

                                                          

                                                           -- =
Justin

                                                          

                                                          

                                                          =


                                                          

                                                          
On

                                                          04/14/2013
                                                          08:23 PM,
                                                          Manger, James
                                                          H =
wrote:

                                                          

                                                          

                                                          

                                                          =

Presumably at app registration time any scope specification is =
really a constraint on the scope values that can be requested in an =
authorization flow.

                                                          =

 

                                                          
So =
ideally registration should accept rules for matching scopes, as opposed =
to actual scope values.

                                                          =

 

                                                          
You can =
try to use scope values as their own matching rules. That is fine for a =
small set of "static" scopes. It starts to fail when there are a large =
number of scopes, or scopes that can include parameters (resource paths? =
email addresses?). You can try to patch those failures by allowing =
services to define service-specific special "wildcard" scope values that =
can only be used during registration (eg "read:*").

                                                          =

 

                                                          =

Alternatively, replace 'scope' in registration with 'scope_regex' =
that holds a regular expression that all scope values in an =
authorization flow must match.

                                                          =

 

                                                          =

--

                                                          
James =
Manger

                                                          =

_______________________________________________

                                                          
OAuth =
mailing list

                                                          
OAuth@ietf.org

                                                          
https://www.ietf.org/mailman/listinfo/oauth<=
/a>

                                                          

                                                          
 

                                                          

                                                          


_______________________________________________

                                                          OAuth mailing
                                                          list

                                                          OAuth@ietf.org

                                                          https://www.ietf.org/mailman/listinfo/oauth<=
/a>

                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          

                                                        

                                                        
 

                                                        

                                                      

                                                    

                                                    
 

                                                    

                                                  

                                                

                                              

                                              
 

                                              

                                            

                                            
 

                                            

                                          

                                          
 

                                          

                                        

                                        
 

                                        

                                      

                                    

                                  

                                  
 

                                  

                                

                              

                            

                          

                          
 

                          

                        
_______________________________________________

                            OAuth mailing list

                            OAuth@ietf.org

                            https://www.ietf.org/mailman/listinfo/oauth<=
/a>

                      

                    
 

                  

                

              

              

            

            _______________________________________________

            OAuth mailing list

            OAuth@ietf.org

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

          

        

        

      

    

    

  




=

--__1366309134615181232abhmt104.oracle.com--

From twbray@google.com  Thu Apr 18 11:23:02 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4512121F9311 for ; Thu, 18 Apr 2013 11:23:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.977
X-Spam-Level: 
X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KniKSkWZyHLA for ; Thu, 18 Apr 2013 11:22:59 -0700 (PDT)
Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id A864D21F930E for ; Thu, 18 Apr 2013 11:22:58 -0700 (PDT)
Received: by mail-ie0-f177.google.com with SMTP id 9so3608688iec.8 for ; Thu, 18 Apr 2013 11:22:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=FnbCuyfJsQNCfV/yJE3F7afs8pXrNd6aoLXuXaSfY68=; b=ZDZhr24nqvN/FeJlPnXKZXEQLqLMNNNibeMkUNO09Zs35qbVYgFShh+uxK0ehqE5r8 EBGkxnWPdxm7uTRYtJ0ndCPd/vKzUHdUmYbjBb2rEQ0mnt6p+DZpum+upUUtQu2gueuz Gdw7tVX9pQaEuOw+2di6K2Dm1Z1I95AWAtwIWtF2aX3W2GQeSwFcTTTKVBBWVli6vIyw T8UUroDJF536KuZPRVPvdR7YbYyM3u2l7kZeujk7Ng7ILlNR8m7Tv0jqFDCuy7TJoGvk EHigHhYB50jf4MwY5rd+xRf76H5v2+qsQXNtNOVckHUZG5j4X8WOHUU/35Z+9HoPwfsl bBYA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=FnbCuyfJsQNCfV/yJE3F7afs8pXrNd6aoLXuXaSfY68=; b=j/IeX5gy59vFDM17X5Hs3k2e9HjG1lCK7GWKv/B5BCBnkjU8t0zhZW+o84nKzBxPmt cbxRMPTvF9IVNzUnSLvjtkcOTRN4vTQcL+Bj/p2EJJNZFfoJ7WwCVAlYPvmZW1mK0L2A f8WogunJnD5S0lnDNiXeBHRlnCv6tXTSYm+FTcmnIXL2vBI/67/Kaq3i1j/Dl4Zwa7kA 5iRZpnBX0pY7AmiYz6SCNPPWAOmqaUFV2epkNIIlkjUpTNGM5CsXJXA+7rJVfkNajsOd iIwd25t7smFHRcMYMYasbN0jpSHmwpoF9QhBgB8aUlrjUaqrURXHZFBjivmrdFtximxK SBkQ==
X-Received: by 10.50.72.83 with SMTP id b19mr483007igv.71.1366309378122; Thu, 18 Apr 2013 11:22:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.31.35 with HTTP; Thu, 18 Apr 2013 11:22:26 -0700 (PDT)
In-Reply-To: <5170383E.3070603@mitre.org>
References: <255B9BB34FB7D647A506DC292726F6E1150C74DADA@WSMSG3153V.srv.dir.telstra.com> <516C1714.8070503@mitre.org> <4E1F6AAD24975D4BA5B168042967394367641A87@TK5EX14MBXC283.redmond.corp.microsoft.com> <516C3152.9070603@mitre.org> <4E1F6AAD24975D4BA5B168042967394367641FAB@TK5EX14MBXC283.redmond.corp.microsoft.com> <516C54F2.8040708@mitre.org> <4E1F6AAD24975D4BA5B16804296739436766BCC4@TK5EX14MBXC284.redmond.corp.microsoft.com>  <4E1F6AAD24975D4BA5B16804296739436766C964@TK5EX14MBXC284.redmond.corp.microsoft.com>    <4E1F6AAD24975D4BA5B16804296739436766D8B9@TK5EX14MBXC284.redmond.corp.microsoft.com> <5170319A.5080903@mitre.org>  <5170383E.3070603@mitre.org>
From: Tim Bray 
Date: Thu, 18 Apr 2013 11:22:26 -0700
Message-ID: 
To: Justin Richer 
Content-Type: multipart/alternative; boundary=047d7bdc19d423078c04daa6b1e4
X-Gm-Message-State: ALoCoQnGRQBheG7iKHhoIxOuMQ/x0X3LshsxP+0cyoaHg8T5PGW4yOqXCgP+N+mNFEHekAf85GG6ATOFUaGK2x5Xo09b8EHtrJ8TDl+HiEIHyTsTYbPTcR4GxgHaiXzeRtT0+xcHo7xYUT5FsNy9Gs/mBrT9o5OsZ54VPcxwtfz/2wdx0Felv9/44M9YdBj0qEh7xKlmDoVW
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: Scope Values
X-BeenThere: oauth@ietf.org
X-Mailman-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, 18 Apr 2013 18:23:02 -0000

--047d7bdc19d423078c04daa6b1e4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Apr 18, 2013 at 11:15 AM, Justin Richer  wrote:

> clientProperties =3D oauth2.register("http://server/register",
> "My Client", "a b c d", ["http://client/return" ]);
>
> The server registers you, and clientProperties gets a client_id, a
> client_name of "My Client", and a scope field of "a b d" since the server
> said you couldn't dynamically register for "c" for whatever reason.
>
> Now let's say that you use the library to request authorization to do
> something on the API. Your app can look inside of clientProperties.scope =
to
> see what scopes you can do something with.
>

So, your implication is that when the server says =E2=80=9Ca b d=E2=80=9D t=
hat means that
you=E2=80=99d better not ask for any other scopes.  I agree.  This seems li=
ke the
only useful interpretation. So why shouldn=E2=80=99t we say that in the spe=
c?  -T



> This will have the string "a b", which means something (to the app) in th=
e
> context of the API it's registering for, and it knows it wants a token fo=
r
> "a b". Apps are going to need to know that, but the library will do what
> the app tells it to. So the app calls the library:
>
> oauth2.authorize("http://server/authorize" ,
> "code", "a b", "http://client/return" , "STATEVALUE=
@
> #$I(RJ@#")
>
> A dumb app could even pass in whatever the value of clientProperties.scop=
e
> is (or a blank value) to try to get all of its scopes. Or the app could
> know that the scopes are structured and call:
>
> oauth2.authorize("http://server/authorize" ,
> "code", "a:read b:readwrite", "http://client/return",
> "STATEVALUE@#$I(RJ@#")
>
> Eventually you get back a code, then a token:
>
> token =3D oauth2.token("http://server/token" , code,
> clientProperties)
>
> (note that clientProperties will have the client_id, client_secret,
> redirect_uri, and anything else needed here.)
>
> Now, this token will *also* have a "scope" field. Let's say that the user
> only authorized you for scope "a". If you want to be smart about it, you
> can avoid calling endpoints that require "b". Or you could just try it an=
d
> be prepared to deal with a failing token, like all OAuth clients must be
> able to do anyway.
>
> I hope this makes sense, please forgive the off-the-cuff pseudocode.
>
>  -- Justin
>
>
> On 04/18/2013 01:56 PM, Tim Bray wrote:
>
> On Thu, Apr 18, 2013 at 10:47 AM, Justin Richer  wrote=
:
>
>
>>  It's very useful for a generic *library* that handles the authorization
>> layer for an application to have a slot for registering scopes and findi=
ng
>> out what scopes the app's been registered for.
>>
>
>  I don=E2=80=99t see how it=E2=80=99s useful in the slightest if there=E2=
=80=99s no defined
> semantic for what =E2=80=9Cregistration=E2=80=9D actually means, i.e. wha=
t result is to be
> expected when sending or receiving a list of scopes.   -T
>
>
>>
>>
>>
>> On 04/18/2013 01:04 PM, Mike Jones wrote:
>>
>>  Saying anything normative about =E2=80=9Cenforcing restrictions=E2=80=
=9D is going
>> beyond RFC 6749 semantics.  Indeed, you=E2=80=99d said that =E2=80=9CI a=
gree that we
>> shouldn't try to "solve" scope in registration.=E2=80=9D, but talking ab=
out
>> restrictions is going down the slippery =E2=80=9Csolving it=E2=80=9D pat=
h.
>>
>>
>>
>> At most we can say that the two parties are making declarations to one
>> another about scopes that they may choose to use, but we can=E2=80=99t a=
ssume that
>> this is an exclusive list and that other scope values such as =E2=80=9C
>> urn:example:channel=3DHBO&urn:example:rating=3DG,PG-13=E2=80=9D might no=
t be used,
>> even if the client registers saying that it intends to use the =E2=80=9C=
OATC=E2=80=9D scope
>> value.  We could maybe even say that some services may use a static set =
of
>> scopes and might choose to limit the scopes that a client may use to tho=
se
>> that it declared to the server or to those that the server returned to t=
he
>> client.  That=E2=80=99s a HINT that some services might do this.  But we=
 can=E2=80=99t say
>> anything normative about such possible behaviors, because it goes beyond
>> RFC 6749.
>>
>>
>>
>>                                                             -- Mike
>>
>>
>>
>> *From:* Richer, Justin P. [mailto:jricher@mitre.org ]
>> *Sent:* Thursday, April 18, 2013 9:26 AM
>> *To:* Anthony Nadalin
>> *Cc:* Tim Bray; Mike Jones; oauth@ietf.org
>> *Subject:* Re: [OAUTH-WG] Registration: Scope Values
>>
>>
>>
>> This doesn't actually break the semantics because the client MUST accept
>> what the server tells it over anything that it asks for in the first pla=
ce.
>> The server has the final say. So in this case, if your client asks for
>> nothing, the server says "A B C", the client now knows it can ask for "A=
 B
>> C" scopes.
>>
>>
>>
>> I'm still in favor of not putting the restricting language in the scope
>> definition at all, instead have it say something like:
>>
>>
>>
>>  =E2=80=9CSpace-separated list of scope values (as described in OAuth 2.=
0 Section 3.3
>> [RFC6749] ) that the
>> Client can use when requesting access tokens from the Authorization Serv=
er.
>> As scope values are service specific, the means of the Authorization Ser=
ver
>> enforcing this restriction are outside the scope of this specification.=
=E2=80=9D
>>
>>
>>
>> Couple this with the overall paragraph that says that the client is
>> requesting values that the server is potentially overriding with its
>> declarations, and I think that addresses everything without getting into
>> confusing language that doesn't add to interoperability.
>>
>>
>>
>>  -- Justin
>>
>>
>>
>> On Apr 18, 2013, at 12:13 PM, Anthony Nadalin 
>> wrote:
>>
>>
>>
>>   If I don=E2=80=99t specify a scope, then the server can allocate a def=
ault (or
>> default set), thus that breaks the semantics you describe
>>
>>
>>
>> *From:* oauth-bounces@ietf.org [mailto:oauth -bounces@ietf.org] *=
On
>> Behalf Of *Tim Bray
>> *Sent:* Thursday, April 18, 2013 9:04 AM
>> *To:* Mike Jones
>> *Cc:* oauth@ietf.org
>> *Subject:* Re: [OAUTH-WG] Registration: Scope Values
>>
>>
>>
>> I=E2=80=99m unconvinced, Mike.  Obviously you=E2=80=99re right about the=
 looseness of
>> OAuth2 scope specification, but this is a very specific semantic of what
>> happens when you register, and I don=E2=80=99t think we=E2=80=99re bound=
 by history here.
>> If we can=E2=80=99t safely say anything about what the list of scopes me=
ans, then
>> I'm with you let's take them out.  But the most obvious intended semanti=
c
>> is (from the client) =E2=80=9CI promise to ask only for these=E2=80=9D a=
nd from the server
>> =E2=80=9CThese are the only ones I=E2=80=99ll give you tokens for.=E2=80=
=9D  Or does someone have
>> use-cases for an alternative semantic?
>>
>>
>>
>> To make this concrete, I propose the following:
>>
>> =E2=80=9CSpace-separated list of scope values (as described in OAuth 2.0=
 Section 3.3
>> [RFC6749] ) that the
>> client is declaring to the server that it will restrict itself to when
>> requesting access tokens, and that the server is declaring to the client
>> that it is registered to use when requesting access tokens.  Clients
>> SHOULD assume that servers will refuse to grant access tokens for scopes
>> not in the list provided by the server.=E2=80=9D
>>
>>
>>
>>
>>
>> On Thu, Apr 18, 2013 at 8:55 AM, Mike Jones 
>> wrote:
>>
>>  I don=E2=80=99t think it=E2=80=99s possible to define what it means in =
an interoperable
>> way because OAuth didn=E2=80=99t specify scopes in an interoperable way.=
  No, I
>> don=E2=80=99t like that either, but I think that=E2=80=99s where things =
are.  That=E2=80=99s why I
>> was advocating deleting this registration feature entirely.
>>
>>
>>
>> But understanding it might be useful in some contexts, I=E2=80=99m OK ke=
eping it,
>> provided we be clear that the semantics of =E2=80=9Cregistered to use=E2=
=80=9D are
>> service-specific.
>>
>>
>>
>>                                                             -- Mike
>>
>>
>>
>> *From:* Tim Bray [mailto:twbray@google.com]
>> *Sent:* Thursday, April 18, 2013 8:36 AM
>> *To:* Mike Jones
>> *Cc:* Justin Richer; oauth@ietf.org
>>
>>
>> *Subject:* Re: [OAUTH-WG] Registration: Scope Values
>>
>>
>>
>> On the server-to-client side, what does =E2=80=9Cregistered to use=E2=80=
=9D mean?  Does
>> it mean that the client should assume that any scopes not on the list WI=
LL
>> not be granted, MAY not be granted.... or what?  Is this already covered
>> elsewhere? -T
>>
>>
>>
>> On Thu, Apr 18, 2013 at 8:28 AM, Mike Jones 
>> wrote:
>>
>> Thanks, Justin.  I agree with the need for the generic two-sided
>> language.  I=E2=80=99d still keep this language for scope, because we wa=
nt to
>> capture the =E2=80=9Cdeclaring=E2=80=9D aspect in this case:
>>
>>
>>
>> =E2=80=9CSpace separated list of scope values (as described in OAuth 2.0=
 Section 3.3
>> [RFC6749] ) that the
>> client is declaring to the server that it may use when requesting access
>> tokens and that the server is declaring to the client that it is registe=
red
>> to use when requesting access tokens.=E2=80=9D.
>>
>>
>>
>> You should probably also reinforce that scope values are service-specifi=
c
>> and may not consist only of a static set of string values, and that
>> therefore, in some cases, an exhaustive list of registered scope values =
is
>> not possible.
>>
>>
>>
>>                                                             -- Mike
>>
>>
>>
>> *From:* Justin Richer [mailto:jricher@mitre.org]
>> *Sent:* Monday, April 15, 2013 12:29 PM
>>
>>
>> *To:* Mike Jones
>> *Cc:* Tim Bray; oauth@ietf.org
>> *Subject:* Re: [OAUTH-WG] Registration: Scope Values
>>
>>
>>
>> I think that because the "declaration" issue affects all parameters in
>> the list, not just scope, we should adopt this in a higher level paragra=
ph
>> and leave it out of the individual parameter descriptions. Thus, somethi=
ng
>> like this inserted as the second paragraph in section 2:
>>
>> The client metadata values serve two parallel purposes in the overall
>> OAuth Dynamic Registration protocol:
>>
>>  - the Client requesting its desired values for each parameter to the
>> Authorization Server in a [register] or [update] request,
>>  - the Authorization Server informing the Client of the current values o=
f
>> each parameter that the Client has been registered to use through a [cli=
ent
>> information response].
>>
>> An Authorization Server MAY override any value that a Client requests
>> during the registration process (including any omitted values) and repla=
ce
>> the requested value with a default. The normative indications in the
>> following list apply to the Client's declaration of its desired values.
>>
>> The Authorization Server SHOULD provide documentation for any fields tha=
t
>> it requires to be filled in by the client or to have particular values o=
r
>> formats. Extensions and profiles...
>>
>>
>> And then remove the sidedness-language from the scope parameter and any
>> other parameters where it might have crept in inadvertently.
>>
>>  -- Justin
>>
>> On 04/15/2013 01:29 PM, Mike Jones wrote:
>>
>>  We could fix the one-sided language by changing
>>
>> =E2=80=9CSpace separated list of scope values (as described in OAuth 2.0=
 Section 3.3
>> [RFC6749] ) that the
>> client is declaring that it may use when requesting access tokens.=E2=80=
=9D
>>
>> to
>>
>> =E2=80=9CSpace separated list of scope values (as described in OAuth 2.0=
 Section 3.3
>> [RFC6749] ) that the
>> client is declaring to the server that it may use when requesting access
>> tokens and that the server is declaring to the client that it is registe=
red
>> to use when requesting access tokens.=E2=80=9D.
>>
>>
>>
>> Again, I chose the =E2=80=9Cregistered to use=E2=80=9D language carefull=
y =E2=80=93 because in
>> the general case it=E2=80=99s not a restriction on the values that the c=
lient can
>> use =E2=80=93 just a statement by the server to the client that it is re=
gistered to
>> use those particular values.  In both cases, the parties are making
>> declarations to one another.
>>
>>
>>
>> If you adopt that language (or keep the original language), then yes, I=
=E2=80=99d
>> consider this closed.
>>
>>
>>
>>                                                             -- Mike
>>
>>
>>
>> *From:* Justin Richer [mailto:jricher@mitre.org ]
>> *Sent:* Monday, April 15, 2013 9:57 AM
>> *To:* Mike Jones
>> *Cc:* Tim Bray; oauth@ietf.org
>> *Subject:* Re: [OAUTH-WG] Registration: Scope Values
>>
>>
>>
>> I absolutely do not want to delete this feature, as (having implemented
>> it) I think it's very useful. This is a very established pattern in manu=
al
>> registration: I know of many, many OAuth2 servers and clients that are s=
et
>> up where the client must pre-register a set of scopes.
>>
>> I don't like the language of "the client is declaring" because it's too
>> one-sided. The client might not have declared anything, and it might be =
the
>> server that's declaring something to the client. Deleting the "is
>> declaring" bit removes that unintended restriction of the language while
>> keeping the original meaning intact. I actually thought that I had fixed
>> that before the last draft went in but apparently I missed this one.
>>
>> I will work on clarifying the intent of the whole metadata set in its
>> introductory paragraph(s) so that it's clear that all of these fields ar=
e
>> used in both of these situations:
>>
>>  1) The client declaring to the server its desire to use a particular
>> value
>>  2) The server declaring to the client that it has been registered with =
a
>> particular value
>>
>> This should hopefully clear up the issue in the editor's note that I
>> currently have at the top of that section right now, too.
>>
>> Mike, since you were the one who originally brought up the issue, and
>> you're fine with the existing text, can I take this as closed now? Assum=
ing
>> that you agree with deleting "is declaring" for reasons stated above, I'=
m
>> fine with leaving everything else as is and staying quiet on what the
>> server has to do with the scopes.
>>
>>  -- Justin
>>
>> On 04/15/2013 12:44 PM, Mike Jones wrote:
>>
>>  I think that the existing wording is superior to the proposed changed
>> wording.  The existing wording is:
>>
>>
>>
>>    scope
>>
>>       OPTIONAL.  Space separated list of scope values (as described in
>>
>>       OAuth 2.0 Section 3.3 [RFC6749])
>> that the client is declaring that
>>
>>       it may use when requesting access tokens.  If omitted, an
>>
>>       Authorization Server MAY register a Client with a default set of
>>
>>       scopes.
>>
>>
>>
>> For instance, the current =E2=80=9Cclient is declaring=E2=80=9D wording =
will always be
>> correct, whereas as the change to =E2=80=9Cclient can use=E2=80=9D wordi=
ng implies a
>> restriction on client behavior that is not always applicable.  The =E2=
=80=9Cclient
>> is declaring=E2=80=9D wording was specific and purposefully chosen, and =
I think
>> should be retained.  In particular, we can=E2=80=99t do anything that im=
plies that
>> only the registered scopes values can be used.  At the OAuth spec level,
>> this is a hint as to possible future client behavior =E2=80=93 not a res=
triction on
>> future client behavior.
>>
>>
>>
>> Also, for the reasons that Tim stated, I=E2=80=99m strongly against any
>> =E2=80=9Cmatching=E2=80=9D or =E2=80=9Cregex=E2=80=9D language in the sp=
ec pertaining to scopes =E2=80=93 as it=E2=80=99s
>> not actionable.
>>
>>
>>
>> So I=E2=80=99d propose that we leave the existing scope wording in place=
.
>> Alternatively, I=E2=80=99d also be fine with deleting this feature entir=
ely, as I
>> don=E2=80=99t think it=E2=80=99s useful in the general case.
>>
>>
>>
>>                                                             -- Mike
>>
>>
>>
>> *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org
>> ]*On Behalf Of *Justin Richer
>> *Sent:* Monday, April 15, 2013 8:05 AM
>> *To:* Tim Bray; oauth@ietf.org
>> *Subject:* Re: [OAUTH-WG] Registration: Scope Values
>>
>>
>>
>> On 04/15/2013 10:52 AM, Tim Bray wrote:
>>
>>
>>   I=E2=80=99d use the existing wording; it=E2=80=99s perfectly clear.  F=
ailing that, if
>> there=E2=80=99s strong demand for registration of structured scopes, ble=
ss the use
>> of regexes, either PCREs or some careful subset.
>>
>>
>> Thanks for the feedback -- Of these two choices, I'd rather leave it
>> as-is.
>>
>>
>>
>>
>>
>> However, I=E2=80=99d subtract the sentence =E2=80=9CIf omitted, an Autho=
rization Server
>> MAY register a Client with a default set of  scopes.=E2=80=9D  It adds n=
o value; if
>> the client doesn=E2=80=99t declare scopes, the client doesn=E2=80=99t de=
clare scopes,
>> that=E2=80=99s all.  -T
>>
>>
>> Remember, all of these fields aren't just for the client *request*,
>> they're also for the server's *response* to either a POST, PUT, or GET
>> request. (I didn't realize it, but perhaps the wording as stated right n=
ow
>> doesn't make that clear -- I need to fix that.) The value that it adds i=
s
>> if the client doesn't ask for any particular scopes, the server can stil=
l
>> assign it scopes and the client can do something smart with that. Dumb
>> clients are allowed to ignore it if it doesn't mean anything to them.
>>
>> This is how our server implementation actually works right now. If the
>> client doesn't ask for anything specific at registration, the server han=
ds
>> it a bag of "default" scopes. Same thing happens at auth time -- if the
>> client doesn't ask for any particular scopes, the server hands it all of
>> its registered scopes as a default. Granted, on our server, scopes are j=
ust
>> simple strings right now, so they get compared at the auth endpoint with=
 an
>> exact string-match metric and set-based logic.
>>
>>  -- Justin
>>
>>
>>
>>
>>
>> On Mon, Apr 15, 2013 at 7:35 AM, Justin Richer  wrote=
:
>>
>> What would you suggest for wording here, then? Keeping in mind that we
>> cannot (and don't want to) prohibit expression-based scopes.
>>
>>  -- Justin
>>
>>
>>
>> On 04/15/2013 10:33 AM, Tim Bray wrote:
>>
>>  No, I mean it=E2=80=99s not interoperable at the software-developer lev=
el.  I
>> can=E2=80=99t register scopes at authorization time with any predictable=
 effect
>> that I can write code to support, either client or server side, without
>> out-of-line non-interoperable knowledge about the behavior of the server=
.
>>
>>
>>
>> I guess I=E2=80=99m just not used to OAuth=E2=80=99s culture of having n=
o expectation
>> that things will be specified tightly enough that I can write code to
>> implement as specified.  -T
>>
>>
>>
>> On Mon, Apr 15, 2013 at 7:15 AM, Justin Richer  wrote=
:
>>
>> Scopes aren't meant to be interoperable between services since they're
>> necessarily API-specific. The only interoperable bit is that there's *so=
me*
>> place to put the values and that it's expressed as a bag of space-separa=
ted
>> strings. How those strings get interpreted and enforced (which is really
>> what's at stake here) is up to the AS and PR (or a higher-level protocol
>> like UMA).
>>
>>  -- Justin
>>
>>
>>
>> On 04/15/2013 10:13 AM, Tim Bray wrote:
>>
>> This, as written, has zero interoperability.  I think this feature can
>> really only be made useful in the case where scopes are fixed strings.
>>
>> -T
>>
>> On Apr 15, 2013 6:54 AM, "Justin Richer"  wrote:
>>
>> You are correct that the idea behind the "scope" parameter at
>> registration is a constraint on authorization-time scopes that are made
>> available. It's both a means for the client to request a set of valid
>> scopes and for the server to provision (and echo back to the client) a s=
et
>> of valid scopes.
>>
>> I *really* don't want to try to define a matching language for scope
>> expressions. For that to work, all servers would need to be able to proc=
ess
>> the regular expressions for all clients, even if the servers themselves
>> only support simple-string scope values. Any regular expression syntax w=
e
>> pick here is guaranteed to be incompatible with something, and I think t=
he
>> complexity doesn't buy much. Also, I think you suddenly have a potential
>> security issue if you have a bad regex in place on either end.
>>
>> As it stands today, the server can interpret the incoming registration
>> scopes and enforce them however it wants to. The real trick comes not fr=
om
>> assigning the values to a particular client but to enforcing them, and I
>> think that's always going to be service-specific. We're just not as clea=
r
>> on that as we could be.
>>
>> After looking over everyone's comments so far, I'd like to propose the
>> following text for that section:
>>
>>
>>     scope
>>
>>       OPTIONAL.  Space separated list of scope values (as described in
>>
>>       OAuth 2.0 Section 3.3 [RFC6749] ) that the client can use when
>>
>>       requesting access tokens.  As scope values are service-specific,
>>
>>       the Authorization Server MAY define its own matching rules when
>>
>>       determining if a scope value used during an authorization request
>>
>>       is valid according to the scope values assigned during
>>
>>       registration. Possible matching rules include wildcard patterns,
>>
>>       regular expressions, or exactly matching the string. If omitted,
>>
>>       an Authorization Server MAY register a Client with a default
>>
>>       set of scopes.
>>
>>
>> Comments? Improvements?
>>
>>  -- Justin
>>
>>
>>   On 04/14/2013 08:23 PM, Manger, James H wrote:
>>
>> Presumably at app registration time any scope specification is really a =
constraint on the scope values that can be requested in an authorization fl=
ow.
>>
>>
>>
>> So ideally registration should accept rules for matching scopes, as oppo=
sed to actual scope values.
>>
>>
>>
>> You can try to use scope values as their own matching rules. That is fin=
e for a small set of "static" scopes. It starts to fail when there are a la=
rge number of scopes, or scopes that can include parameters (resource paths=
? email addresses?). You can try to patch those failures by allowing servic=
es to define service-specific special "wildcard" scope values that can only=
 be used during registration (eg "read:*").
>>
>>
>>
>> Alternatively, replace 'scope' in registration with 'scope_regex' that h=
olds a regular expression that all scope values in an authorization flow mu=
st match.
>>
>>
>>
>> --
>>
>> James Manger
>>
>> _______________________________________________
>>
>> 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
>>
>>
>>
>>
>>
>
>

--047d7bdc19d423078c04daa6b1e4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On Thu, Apr 18, 2013 at 11:15 AM, Justin Richer <jricher@mitre.org> wrote:




 =20
   =20
 =20
  
clientProperties =3D oauth2.reg=
ister("http://server/register", "My
    Client", "a b c d", ["http://client/return"]);
    

    The server registers you, and clientProperties gets a client_id, a
    client_name of "My Client", and a scope field of "a b d&=
quot; since the
    server said you couldn't dynamically register for "c" for=
 whatever
    reason.

    

    Now let's say that you use the library to request authorization to
    do something on the API. Your app can look inside of
    clientProperties.scope to see what scopes you can do something with.

So, your implication is that when=
 the server says =E2=80=9Ca b d=E2=80=9D that means that you=E2=80=99d bett=
er not ask for any other scopes. =C2=A0I agree. =C2=A0This seems like the o=
nly useful interpretation. So why shouldn=E2=80=99t we say that in the spec=
? =C2=A0-T




=C2=A0

    This will have the string "a b", which means something (to th=
e app)
    in the context of the API it's registering for, and it knows it
    wants a token for "a b". Apps are going to need to know that,=
 but
    the library will do what the app tells it to. So the app calls the
    library:

    

    oauth2.authorize("http://server/authorize", "code",=
 "a b",
    &qu=
ot;http://client/return", "STATEVALUE@#$I(RJ@#")

    

    A dumb app could even pass in whatever the value of
    clientProperties.scope is (or a blank value) to try to get all of
    its scopes. Or the app could know that the scopes are structured and
    call:

    

    oauth2.authorize("http://server/authorize", "code",=
 "a:read
    b:readwrite", "http://client/return", "STATEVALUE@#$I(=
RJ@#")

    

    Eventually you get back a code, then a token:

    

    token =3D oauth2.token("http://server/token", code, clientPropert=
ies)

    

    (note that clientProperties will have the client_id, client_secret,
    redirect_uri, and anything else needed here.)

    

    Now, this token will *also* have a "scope" field. Let's s=
ay that the
    user only authorized you for scope "a". If you want to be sma=
rt
    about it, you can avoid calling endpoints that require "b". O=
r you
    could just try it and be prepared to deal with a failing token, like
    all OAuth clients must be able to do anyway.

    

    I hope this makes sense, please forgive the off-the-cuff pseudocode.
    

    =C2=A0-- Justin

    

    

    
On 04/18/2013 01:56 PM, Tim Bray wrote:

    

    

     =20
      
On Thu, Apr 18, 2013 at 10:47 AM, Justin Richer <jricher@mitre.org> wrote:

        

          

            
=C2=A0

            

              
 It's very usef=
ul
                for a generic *library* that handles the authorization
                layer for an application to have a slot for registering
                scopes and finding out what scopes the app's been
                registered for.

            

            


            

            
I don=E2=80=99t see how it=E2=80=99s useful in the slighte=
st if there=E2=80=99s
              no defined semantic for what =E2=80=9Cregistration=E2=80=9D a=
ctually
              means, i.e. what result is to be expected when sending or
              receiving a list of scopes. =C2=A0 -T

            
=C2=A0

            

              


                

                  


                    

                    
On 04/18/2013 01:04 PM, Mike Jones wrote:

                    

                    

                      

                        
S=
aying

                            anything normative about =E2=80=9Cenforcing
                            restrictions=E2=80=9D is going beyond RFC 6749
                            semantics.=C2=A0 Indeed, you=E2=80=99d said tha=
t =E2=80=9CI
                          agree that we shouldn't try to "solve&qu=
ot; scope
                          in registration.=E2=80=
=9D,

                            but talking about restrictions is going down
                            the slippery =E2=80=9Csolving it=E2=80=9D path.=


                        
=
=C2=A0

                        
A=
t

                            most we can say that the two parties are
                            making declarations to one another about
                            scopes that they may choose to use, but we
                            can=E2=80=99t assume that this is an exclusive =
list
                            and that other scope values such as =E2=80=9Curn:example:channel=3DHBO&urn:example:rating=3DG=
,PG-13=E2=80=9D
                            might not be used, even if the client
                            registers saying that it intends to use the
                            =E2=80=9COATC=E2=80=9D scope value.=C2=A0 We co=
uld maybe even say
                            that some services may use a static set of
                            scopes and might choose to limit the scopes
                            that a client may use to those that it
                            declared to the server or to those that the
                            server returned to the client.=C2=A0 That=E2=80=
=99s a
                            HINT that some services might do this.=C2=A0 Bu=
t
                            we can=E2=80=99t say anything normative about s=
uch
                            possible behaviors, because it goes beyond
                            RFC 6749.

                        
=
=C2=A0

                        
=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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

                        
=
=C2=A0

                        
                        
=C2=A0

                        

                          
This doesn't actually
                            break the semantics because the client MUST
                            accept what the server tells it over
                            anything that it asks for in the first
                            place. The server has the final say. So in
                            this case, if your client asks for nothing,
                            the server says "A B C", the client n=
ow
                            knows it can ask for "A B C" scopes.=
=C2=A0

                        

                        

                          
=C2=A0

                        

                        

                          
I'm still in favor of =
not
                            putting the restricting language in the
                            scope definition at all, instead have it say
                            something like:

                        

                        

                          
=C2=A0

                        

                        

                          

                            

                              

                                
=E2=80=9CSpace-separated list of
                                    scope values (as described in OAuth
                                    2.0=C2=A0Section=C2=A03.3
                                        [RFC6749]) that the
                                    Client can use when requesting
                                    access tokens from the Authorization
                                    Server. As scope values are service
                                    specific, the means of the
                                    Authorization Server enforcing this
                                    restriction are outside the scope of
                                    this specification.=E2=80=9D

                              

                            

                          

                          
=C2=A0

                        

                        

                          
Couple this with the
                            overall paragraph that says that the client
                            is requesting values that the server is
                            potentially overriding with its
                            declarations, and I think that addresses
                            everything without getting into confusing
                            language that doesn't add to
                            interoperability.=C2=A0

                        

                        

                          
=C2=A0

                        

                        

                          
=C2=A0-- Justin

                        

                        

                          
=C2=A0

                          

                            

                              
On Apr 18, 2013, at
                                12:13 PM, Anthony Nadalin <tonynad@micr=
osoft.com>

                                wrote:

                            

                            


                              

                            

                            

                              

                                
If

                                    I don=E2=80=99t specify a scope, then t=
he
                                    server can allocate a default (or
                                    default set), thus that breaks the
                                    semantics you describe

                              

                              
                              

                                
From=
:=C2=A0oauth-bou=
nces@ietf.org
                                    [mailto:oauth-bounces@ietf.org]=C2=A0=
On
                                      Behalf Of=C2=A0Tim
                                    Bray

                                    Sent:=C2=A0Thursday=
,
                                    April 18, 2013 9:04 AM

                                    To:=C2=A0Mike Jones=


                                    Cc:=C2=A0oauth@ietf.org

                                    Subject:=C2=A0Re:
                                    [OAUTH-WG] Registration: Scope
                                    Values

                              

                              

                                
=C2=A0

                              

                              

                                

                                  
I=E2=80=99m unconv=
inced,
                                    Mike. =C2=A0Obviously you=E2=80=99re ri=
ght about
                                    the looseness of OAuth2 scope
                                    specification, but this is a very
                                    specific semantic of what happens
                                    when you register, and I don=E2=80=99t =
think
                                    we=E2=80=99re bound by history here. =
=C2=A0 If we
                                    can=E2=80=99t safely say anything about=
 what
                                    the list of scopes means, then I'm
                                    with you let's take them out. =C2=
=A0But
                                    the most obvious intended semantic
                                    is (from the client) =E2=80=9CI promise=
 to
                                    ask only for these=E2=80=9D and from th=
e
                                    server =E2=80=9CThese are the only ones=
 I=E2=80=99ll
                                    give you tokens for.=E2=80=9D =C2=A0Or =
does
                                    someone have use-cases for an
                                    alternative semantic?

                                

                                

                                  

                                    
=C2=A0

                                  

                                

                                

                                  

                                    
To make this
                                      concrete, I propose the following:
                                  

                                

                                

                                  

                                    
=E2=80=9CSpace-separated list
                                        of scope values (as described in
                                        OAuth 2.0=C2=A0<=
span style=3D"color:purple">Section=C2=A03.3


                                            [RFC6749]) that
                                        the client is declaring to the
                                        server that it will restrict
                                        itself to when requesting access
                                        tokens, and that the server is
                                        declaring to the client that it
                                        is registered to use when
                                        requesting access tokens. =C2=A0Clients
                                        SHOULD assume that servers will
                                        refuse to grant access tokens
                                        for scopes not in the list
                                        provided by the server.=E2=80=9D

                                  

                                  

                                    

                                      
=C2=A0

                                    

                                  

                                

                              

                              

                                
=C2=A0

                                

                                  

                                    
On Thu, Apr 18,
                                      2013 at 8:55 AM, Mike Jones <Michael.Jones@microsoft.com>

                                      wrote:

                                  

                                  

                                    

                                      
I
                                          don=E2=80=99t think it=E2=80=99s =
possible to
                                          define what it means in an
                                          interoperable way because
                                          OAuth didn=E2=80=99t specify scop=
es in
                                          an interoperable way.=C2=A0 No, I
                                          don=E2=80=99t like that either, b=
ut I
                                          think that=E2=80=99s where things
                                          are.=C2=A0 That=E2=80=99s why I w=
as
                                          advocating deleting this
                                          registration feature entirely.

                                    

                                    

                                      
=C2=A0

                                    

                                    

                                      
But

                                          understanding it might be
                                          useful in some contexts, I=E2=80=
=99m
                                          OK keeping it, provided we be
                                          clear that the semantics of
                                          =E2=80=9Cregistered to use=E2=80=
=9D are
                                          service-specific.

                                    

                                    

                                      
=C2=A0

                                    

                                    

                                      
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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

                                    

                                    

                                      
=C2=A0

                                    

                                    

                                      
From:=C2=A0Tim


                                          Bray [mailto:twbray@google.com]=C2=A0

                                          Sent:=C2=A0Th=
ursday,

                                          April 18, 2013 8:36 AM

                                          To:=C2=A0Mike
                                          Jones

                                          Cc:=C2=A0Just=
in
                                          Richer;=C2=A0oauth@ietf.org

                                    

                                    

                                      

                                        


                                          Subject:=C2=A0Re:

                                          [OAUTH-WG] Registration: Scope
                                          Values

                                      

                                    

                                    

                                      

                                        
=C2=A0

                                      

                                      

                                        

                                          
On the
                                            server-to-client side, what
                                            does =E2=80=9Cregistered to use=
=E2=80=9D
                                            mean? =C2=A0Does it mean that t=
he
                                            client should assume that
                                            any scopes not on the list
                                            WILL not be granted, MAY not
                                            be granted.... or what? =C2=A0I=
s
                                            this already covered
                                            elsewhere? -T

                                        

                                      

                                      

                                        
=C2=A0

                                        

                                          

                                            
On Thu,
                                              Apr 18, 2013 at 8:28 AM,
                                              Mike Jones <Michael.Jones@microsoft.com>

                                              wrote:

                                          

                                          

                                            

                                              
Thanks,

                                                  Justin.=C2=A0 I agree wit=
h
                                                  the need for the
                                                  generic two-sided
                                                  language.=C2=A0 I=E2=80=
=99d still
                                                  keep this language for
                                                  scope, because we want
                                                  to capture the
                                                  =E2=80=9Cdeclaring=E2=80=
=9D aspect in
                                                  this case:

                                            

                                            

                                              

                                                
=C2=A0

                                              

                                              

                                                
=E2=80=9CSpace
                                                    separated list of
                                                    scope values (as
                                                    described in OAuth
                                                    2.0=C2=A0<=
a href=3D"http://tools.ietf.org/html/rfc6749#section-3.3" target=3D"_blank"=
 class=3D"cremed">Section=C2=A03.3 [RFC6749]) that the client
                                                    is declaring to the
                                                    server that it may
                                                    use when requesting
                                                    access tokens and
                                                    that the server is
                                                    declaring to the
                                                    client that it is
                                                    registered to use
                                                    when requesting
                                                    access tokens.=E2=80=9D.

                                              

                                              

                                                
=C2=A0

                                              

                                            

                                            

                                              
You

                                                  should probably also
                                                  reinforce that scope
                                                  values are
                                                  service-specific and
                                                  may not consist only
                                                  of a static set of
                                                  string values, and
                                                  that therefore, in
                                                  some cases, an
                                                  exhaustive list of
                                                  registered scope
                                                  values is not
                                                  possible.

                                            

                                            

                                              
=C2=A0

                                            

                                            

                                              
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=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

                                            

                                            

                                              
=C2=A0

                                            

                                            

                                              

                                                

                                                  
From:=C2=A0Justin


                                                      Richer [mailto:jricher@mitre.org]=C2=A0

                                                      Sent:=C2=
=A0Monday,

                                                      April 15, 2013
                                                      12:29 PM

                                                

                                                

                                                  

                                                    
=


                                                      To:=C2=
=A0Mike

                                                      Jones

                                                      Cc:=C2=
=A0Tim

                                                      Bray;=C2=A0oauth@ietf.org

                                                      Subject:=
=C2=A0Re:

                                                      [OAUTH-WG]
                                                      Registration:
                                                      Scope Values

                                                  

                                                

                                              

                                            

                                            

                                              

                                                
=C2=
=A0

                                              

                                              
I
                                                think that because the
                                                "declaration" iss=
ue
                                                affects all parameters
                                                in the list, not just
                                                scope, we should adopt
                                                this in a higher level
                                                paragraph and leave it
                                                out of the individual
                                                parameter descriptions.
                                                Thus, something like
                                                this inserted as the
                                                second paragraph in
                                                section 2:

                                              

                                                
The
                                                  client metadata values
                                                  serve two parallel
                                                  purposes in the
                                                  overall OAuth Dynamic
                                                  Registration protocol:=C2=A0

                                                  

                                                  =C2=A0- the Client
                                                  requesting its desired
                                                  values for each
                                                  parameter to the
                                                  Authorization Server
                                                  in a [register] or
                                                  [update] request,

                                                  =C2=A0- the Authorization
                                                  Server informing the
                                                  Client of the current
                                                  values of each
                                                  parameter that the
                                                  Client has been
                                                  registered to use
                                                  through a [client
                                                  information response].=C2=A0

                                                  

                                                  An Authorization
                                                  Server MAY override
                                                  any value that a
                                                  Client requests during
                                                  the registration
                                                  process (including any
                                                  omitted values) and
                                                  replace the requested
                                                  value with a default.
                                                  The normative
                                                  indications in the
                                                  following list apply
                                                  to the Client's
                                                  declaration of its
                                                  desired values.=C2=
=A0

                                                  

                                                  The Authorization
                                                  Server SHOULD provide
                                                  documentation for any
                                                  fields that it
                                                  requires to be filled
                                                  in by the client or to
                                                  have particular values
                                                  or formats. Extensions
                                                  and profiles...

                                              

                                              


                                                And then remove the
                                                sidedness-language from
                                                the scope parameter and
                                                any other parameters
                                                where it might have
                                                crept in inadvertently.=C2=A0

                                                

                                                =C2=A0-- Justin

                                              

                                                

                                                  
On
                                                    04/15/2013 01:29 PM,
                                                    Mike Jones wrote:

                                                

                                              

                                              

                                                

                                                  
We

                                                      could fix the
                                                      one-sided language
                                                      by changing
                                                

                                                

                                                  
=E2=80=9CSpace
                                                      separated list of
                                                      scope values (as
                                                      described in OAuth
                                                      2.0=C2=A0Section=C2=A03.3 [RFC6749]=
) that the client
                                                      is declaring that
                                                      it may use when
                                                      requesting access
                                                      tokens.=E2=80=9D

                                                

                                                

                                                  
to

                                                

                                                

                                                  
=E2=80=9CSpace
                                                      separated list of
                                                      scope values (as
                                                      described in OAuth
                                                      2.0=C2=A0Section=C2=A03.3 [RFC6749]=
) that the client
                                                      is declaring to
                                                      the server that it
                                                      may use when
                                                      requesting access
                                                      tokens and that
                                                      the server is
                                                      declaring to the
                                                      client that it is
                                                      registered to use
                                                      when requesting
                                                      access tokens.=
=E2=80=9D.

                                                

                                                

                                                  
=C2=A0

                                                

                                                

                                                  
Again,

                                                      I chose the
                                                      =E2=80=9Cregistered t=
o
                                                      use=E2=80=9D language
                                                      carefully =E2=80=93
                                                      because in the
                                                      general case it=E2=80=
=99s
                                                      not a restriction
                                                      on the values that
                                                      the client can use
                                                      =E2=80=93 just a stat=
ement
                                                      by the server to
                                                      the client that it
                                                      is registered to
                                                      use those
                                                      particular
                                                      values.=C2=A0 In both
                                                      cases, the parties
                                                      are making
                                                      declarations to
                                                      one another.
                                                

                                                

                                                  
=C2=A0

                                                

                                                

                                                  
If

                                                      you adopt that
                                                      language (or keep
                                                      the original
                                                      language), then
                                                      yes, I=E2=80=99d cons=
ider
                                                      this closed.
                                                

                                                

                                                  
=C2=A0

                                                

                                                

                                                  
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=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

                                                

                                                

                                                  
=C2=A0

                                                

                                                

                                                  

                                                    

                                                      
From:=C2=A0Justin


                                                          Richer [mailto:jricher@mitre.org]=C2=A0<=
br>
                                                          Sent:=C2=A0Monday,

                                                          April 15, 2013
                                                          9:57 AM

                                                          To:=
=C2=A0Mike

                                                          Jones

                                                          Cc:=
=C2=A0Tim

                                                          Bray;=C2=A0=
oauth@ietf.org

                                                          Subject:=C2=A0Re:

                                                          [OAUTH-WG]
                                                          Registration:
                                                          Scope Values

                                                    

                                                  

                                                

                                                

                                                  
=
=C2=A0

                                                

                                                
I
                                                  absolutely do not want
                                                  to delete this
                                                  feature, as (having
                                                  implemented it) I
                                                  think it's very
                                                  useful. This is a very
                                                  established pattern in
                                                  manual registration: I
                                                  know of many, many
                                                  OAuth2 servers and
                                                  clients that are set
                                                  up where the client
                                                  must pre-register a
                                                  set of scopes.=C2=
=A0

                                                  

                                                  I don't like the
                                                  language of "the
                                                  client is declaring"
                                                  because it's too
                                                  one-sided. The client
                                                  might not have
                                                  declared anything, and
                                                  it might be the server
                                                  that's declaring
                                                  something to the
                                                  client. Deleting the
                                                  "is declaring" =
bit
                                                  removes that
                                                  unintended restriction
                                                  of the language while
                                                  keeping the original
                                                  meaning intact. I
                                                  actually thought that
                                                  I had fixed that
                                                  before the last draft
                                                  went in but apparently
                                                  I missed this one.

                                                  

                                                  I will work on
                                                  clarifying the intent
                                                  of the whole metadata
                                                  set in its
                                                  introductory
                                                  paragraph(s) so that
                                                  it's clear that all o=
f
                                                  these fields are used
                                                  in both of these
                                                  situations:

                                                  

                                                  =C2=A01) The client
                                                  declaring to the
                                                  server its desire to
                                                  use a particular value
                                                  =C2=A02) The server
                                                  declaring to the
                                                  client that it has
                                                  been registered with a
                                                  particular value

                                                  

                                                  This should hopefully
                                                  clear up the issue in
                                                  the editor's note tha=
t
                                                  I currently have at
                                                  the top of that
                                                  section right now,
                                                  too.

                                                  

                                                  Mike, since you were
                                                  the one who originally
                                                  brought up the issue,
                                                  and you're fine with
                                                  the existing text, can
                                                  I take this as closed
                                                  now? Assuming that you
                                                  agree with deleting
                                                  "is declaring" =
for
                                                  reasons stated above,
                                                  I'm fine with leaving
                                                  everything else as is
                                                  and staying quiet on
                                                  what the server has to
                                                  do with the scopes.

                                                  

                                                  =C2=A0-- Justin

                                                

                                                  

                                                    
=
On
                                                      04/15/2013 12:44
                                                      PM, Mike Jones
                                                      wrote:

                                                  

                                                

                                                

                                                  

                                                    
=
I
                                                        think that the
                                                        existing wording
                                                        is superior to
                                                        the proposed
                                                        changed
                                                        wording.=C2=A0 The
                                                        existing wording
                                                        is:

                                                  

                                                  

                                                    
=
=C2=A0

                                                  

                                                  

                                                    
=
=C2=A0=C2=A0
                                                        scope

                                                  

                                                  

                                                    
=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                                        OPTIONAL.=C2=A0 Spa=
ce
                                                        separated list
                                                        of scope values
                                                        (as described in

                                                  

                                                  

                                                    
=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                                        OAuth 2.0=C2=
=A0Section=C2=A03.3
                                                          [RFC6749]<=
/a>)
                                                        that the client
                                                        is declaring
                                                        that

                                                  

                                                  

                                                    
=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                                        it may use when
                                                        requesting
                                                        access tokens.=C2=
=A0
                                                        If omitted, an

                                                  

                                                  

                                                    
=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                                        Authorization
                                                        Server MAY
                                                        register a
                                                        Client with a
                                                        default set of

                                                  

                                                  

                                                    
=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                                        scopes.

                                                  

                                                  

                                                    
=
=C2=A0

                                                  

                                                  

                                                    
=
For

                                                        instance, the
                                                        current =E2=80=9Ccl=
ient
                                                        is declaring=E2=80=
=9D
                                                        wording will
                                                        always be
                                                        correct, whereas
                                                        as the change to
                                                        =E2=80=9Cclient can=
 use=E2=80=9D
                                                        wording implies
                                                        a restriction on
                                                        client behavior
                                                        that is not
                                                        always
                                                        applicable.=C2=A0 T=
he
                                                        =E2=80=9Cclient is
                                                        declaring=E2=80=9D
                                                        wording was
                                                        specific and
                                                        purposefully
                                                        chosen, and I
                                                        think should be
                                                        retained.=C2=A0 In
                                                        particular, we
                                                        can=E2=80=99t do
                                                        anything that
                                                        implies that
                                                        only the
                                                        registered
                                                        scopes values
                                                        can be used.=C2=A0 =
At
                                                        the OAuth spec
                                                        level, this is a
                                                        hint as to
                                                        possible future
                                                        client behavior
                                                        =E2=80=93 not a
                                                        restriction on
                                                        future client
                                                        behavior.
                                                  

                                                  

                                                    
=
=C2=A0

                                                  

                                                  

                                                    
=
Also,

                                                        for the reasons
                                                        that Tim stated,
                                                        I=E2=80=99m strongl=
y
                                                        against any
                                                        =E2=80=9Cmatching=
=E2=80=9D or
                                                        =E2=80=9Cregex=E2=
=80=9D language
                                                        in the spec
                                                        pertaining to
                                                        scopes =E2=80=93 as=
 it=E2=80=99s
                                                        not actionable.

                                                  

                                                  

                                                    
=
=C2=A0

                                                  

                                                  

                                                    
=
So

                                                        I=E2=80=99d propose=
 that
                                                        we leave the
                                                        existing scope
                                                        wording in
                                                        place.=C2=A0
                                                        Alternatively,
                                                        I=E2=80=99d also be=
 fine
                                                        with deleting
                                                        this feature
                                                        entirely, as I
                                                        don=E2=80=99t think=
 it=E2=80=99s
                                                        useful in the
                                                        general case.

                                                  

                                                  

                                                    
=
=C2=A0

                                                  

                                                  

                                                    
=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=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

                                                  

                                                  

                                                    
=
=C2=A0

                                                  

                                                  

                                                    

                                                      

                                                        
From:=C2=A0oauth-bounces@ietf.org<=
span>=C2=A0[mailto:oauth-bounces@ietf=
.org]On
                                                          Behalf Of=
=C2=A0Justin

                                                          Richer

                                                          Sent:=C2=A0Monday,

                                                          April 15, 2013
                                                          8:05 AM

                                                          To:=
=C2=A0Tim

                                                          Bray;=C2=A0=
oauth@ietf.org

                                                          Subject:=C2=A0Re:

                                                          [OAUTH-WG]
                                                          Registration:
                                                          Scope Values

                                                      

                                                    

                                                  

                                                  

                                                    
=
=C2=A0

                                                  

                                                  
On

                                                    04/15/2013 10:52 AM,
                                                    Tim Bray wrote:

                                                    

                                                    

                                                  

                                                  

                                                    

                                                      
I=E2=80=99d
                                                        use the existing
                                                        wording; it=E2=80=
=99s
                                                        perfectly clear.
                                                        =C2=A0Failing that,
                                                        if there=E2=80=99s
                                                        strong demand
                                                        for registration
                                                        of structured
                                                        scopes, bless
                                                        the use of
                                                        regexes, either
                                                        PCREs or some
                                                        careful subset.

                                                    

                                                  

                                                  


                                                    Thanks for the
                                                    feedback -- Of these
                                                    two choices, I'd
                                                    rather leave it
                                                    as-is.=C2=A0

                                                    

                                                    

                                                    

                                                  

                                                  

                                                    

                                                      

                                                        
=C2=A0

                                                      

                                                    

                                                    

                                                      

                                                        
However,

                                                          I=E2=80=99d subtr=
act
                                                          the sentence
                                                          =E2=80=9CIf omitt=
ed,
                                                          an
                                                          Authorization
                                                          Server MAY
                                                          register a
                                                          Client with a
                                                          default set of
                                                          =C2=A0scopes.=E2=
=80=9D =C2=A0It
                                                          adds no value;
                                                          if the client
                                                          doesn=E2=80=99t
                                                          declare
                                                          scopes, the
                                                          client doesn=E2=
=80=99t
                                                          declare
                                                          scopes, that=E2=
=80=99s
                                                          all. =C2=A0-T

                                                      

                                                    

                                                  

                                                  


                                                    Remember, all of
                                                    these fields aren't
                                                    just for the client
                                                    *request*, they're
                                                    also for the
                                                    server's *response*
                                                    to either a POST,
                                                    PUT, or GET request.
                                                    (I didn't realize
                                                    it, but perhaps the
                                                    wording as stated
                                                    right now doesn't
                                                    make that clear -- I
                                                    need to fix that.)
                                                    The value that it
                                                    adds is if the
                                                    client doesn't ask
                                                    for any particular
                                                    scopes, the server
                                                    can still assign it
                                                    scopes and the
                                                    client can do
                                                    something smart with
                                                    that. Dumb clients
                                                    are allowed to
                                                    ignore it if it
                                                    doesn't mean
                                                    anything to them.=
=C2=A0

                                                    

                                                    This is how our
                                                    server
                                                    implementation
                                                    actually works right
                                                    now. If the client
                                                    doesn't ask for
                                                    anything specific at
                                                    registration, the
                                                    server hands it a
                                                    bag of "default&qu=
ot;
                                                    scopes. Same thing
                                                    happens at auth time
                                                    -- if the client
                                                    doesn't ask for any
                                                    particular scopes,
                                                    the server hands it
                                                    all of its
                                                    registered scopes as
                                                    a default. Granted,
                                                    on our server,
                                                    scopes are just
                                                    simple strings right
                                                    now, so they get
                                                    compared at the auth
                                                    endpoint with an
                                                    exact string-match
                                                    metric and set-based
                                                    logic.=C2=A0

                                                    

                                                    =C2=A0-- Justin

                                                    

                                                    

                                                    

                                                  

                                                  

                                                    
=C2=A0

                                                    

                                                      

                                                        
On
                                                          Mon, Apr 15,
                                                          2013 at 7:35
                                                          AM, Justin
                                                          Richer <jricher@mitre.org> wrote:

                                                      

                                                      

                                                        

                                                          
What

                                                          would you
                                                          suggest for
                                                          wording here,
                                                          then? Keeping
                                                          in mind that
                                                          we cannot (and
                                                          don't want to=
)
                                                          prohibit
                                                          expression-based
                                                          scopes.=C2=
=A0

                                                          

                                                          =C2=A0-- Justin

                                                        

                                                        

                                                          
=C2=A0

                                                          

                                                          

                                                          
On

                                                          04/15/2013
                                                          10:33 AM, Tim
                                                          Bray wrote:

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
No,

                                                          I mean it=E2=80=
=99s
                                                          not
                                                          interoperable
                                                          at the
                                                          software-develope=
r
                                                          level. =C2=A0I
                                                          can=E2=80=99t reg=
ister
                                                          scopes at
                                                          authorization
                                                          time with any
                                                          predictable
                                                          effect that I
                                                          can write code
                                                          to support,
                                                          either client
                                                          or server
                                                          side, without
                                                          out-of-line
                                                          non-interoperable
                                                          knowledge
                                                          about the
                                                          behavior of
                                                          the server. =C2=
=A0

                                                          

                                                          

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          

                                                          

                                                          
I
                                                          guess I=E2=80=99m=
 just
                                                          not used to
                                                          OAuth=E2=80=99s
                                                          culture of
                                                          having no
                                                          expectation
                                                          that things
                                                          will be
                                                          specified
                                                          tightly enough
                                                          that I can
                                                          write code to
                                                          implement as
                                                          specified. =C2=A0=
-T

                                                          

                                                          

                                                          

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          
On

                                                          Mon, Apr 15,
                                                          2013 at 7:15
                                                          AM, Justin
                                                          Richer <jricher@mitre.org> wrote:

                                                          

                                                          

                                                          

                                                          
Scopes

                                                          aren't meant
                                                          to be
                                                          interoperable
                                                          between
                                                          services since
                                                          they're
                                                          necessarily
                                                          API-specific.
                                                          The only
                                                          interoperable
                                                          bit is that
                                                          there's *some=
*
                                                          place to put
                                                          the values and
                                                          that it's
                                                          expressed as a
                                                          bag of
                                                          space-separated
                                                          strings. How
                                                          those strings
                                                          get
                                                          interpreted
                                                          and enforced
                                                          (which is
                                                          really what's
                                                          at stake here)
                                                          is up to the
                                                          AS and PR (or
                                                          a higher-level
                                                          protocol like
                                                          UMA).

                                                          

                                                          =C2=A0-- Justin

                                                          

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          
On

                                                          04/15/2013
                                                          10:13 AM, Tim
                                                          Bray wrote:

                                                          

                                                          

                                                          

                                                          
This, as
                                                          written, has
                                                          zero
                                                          interoperability.=
=C2=A0
                                                          I think this
                                                          feature can
                                                          really only be
                                                          made useful in
                                                          the case where
                                                          scopes are
                                                          fixed strings.
                                                          
-T

                                                          

                                                          

                                                          
On

                                                          Apr 15, 2013
                                                          6:54 AM,
                                                          "Justin
                                                          Richer" <=
jricher@mitre.org> wrote:

                                                          

                                                          

                                                          
You are correct that the idea behind t=
he
                                                          "scope"
                                                          parameter at
                                                          registration
                                                          is a
                                                          constraint on
                                                          authorization-tim=
e

                                                          scopes that
                                                          are made
                                                          available.
                                                          It's both a
                                                          means for the
                                                          client to
                                                          request a set
                                                          of valid
                                                          scopes and for
                                                          the server to
                                                          provision (and
                                                          echo back to
                                                          the client) a
                                                          set of valid
                                                          scopes.

                                                          

                                                          I *really*
                                                          don't want to
                                                          try to define
                                                          a matching
                                                          language for
                                                          scope
                                                          expressions.
                                                          For that to
                                                          work, all
                                                          servers would
                                                          need to be
                                                          able to
                                                          process the
                                                          regular
                                                          expressions
                                                          for all
                                                          clients, even
                                                          if the servers
                                                          themselves
                                                          only support
                                                          simple-string
                                                          scope values.
                                                          Any regular
                                                          expression
                                                          syntax we pick
                                                          here is
                                                          guaranteed to
                                                          be
                                                          incompatible
                                                          with
                                                          something, and
                                                          I think the
                                                          complexity
                                                          doesn't buy
                                                          much. Also, I
                                                          think you
                                                          suddenly have
                                                          a potential
                                                          security issue
                                                          if you have a
                                                          bad regex in
                                                          place on
                                                          either end.=
=C2=A0

                                                          

                                                          As it stands
                                                          today, the
                                                          server can
                                                          interpret the
                                                          incoming
                                                          registration
                                                          scopes and
                                                          enforce them
                                                          however it
                                                          wants to. The
                                                          real trick
                                                          comes not from
                                                          assigning the
                                                          values to a
                                                          particular
                                                          client but to
                                                          enforcing
                                                          them, and I
                                                          think that's
                                                          always going
                                                          to be
                                                          service-specific.
                                                          We're just no=
t
                                                          as clear on
                                                          that as we
                                                          could be.

                                                          

                                                          After looking
                                                          over
                                                          everyone's
                                                          comments so
                                                          far, I'd like
                                                          to propose the
                                                          following text
                                                          for that
                                                          section:

                                                          

                                                          

                                                          

                                                          
=C2=A0=C2=A0=
 scope

                                                          
=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 OPTIONAL.=C2=A0 Space separated list of scope values (as=
 described in

                                                          
=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 OAuth 2.0 Section=C2=A03.3 [RFC6749]) that the client can use when 


                                                          
=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0requesting access tokens.=C2=A0 As scope values are=
 service-specific, 

                                                          
=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0the Authorization Server MAY define its own matchin=
g rules when

                                                          
=C2=A0=C2=A0=
=C2=A0=C2=A0 =C2=A0determining if a scope value used during an authorizatio=
n request

                                                          
=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 is valid according to the scope values assigned during <=
/pre>
                                                          
=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0registration. Possible matching rules include wildc=
ard patterns,

                                                          
=C2=A0=C2=A0=
=C2=A0=C2=A0 =C2=A0regular expressions, or exactly matching the string. If =
omitted, 

                                                          
=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0an Authorization Server MAY register a Client with =
a default 

                                                          
=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0set of scopes.

                                                          


                                                          Comments?
                                                          Improvements?

                                                          

                                                          =C2=A0-- Justin
                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
On

                                                          04/14/2013
                                                          08:23 PM,
                                                          Manger, James
                                                          H wrote:

                                                          

                                                          

                                                          

                                                          
Presumably a=
t app registration time any scope specification is really a constraint on t=
he scope values that can be requested in an authorization flow.

                                                          
=C2=A0

                                                          
So ideally r=
egistration should accept rules for matching scopes, as opposed to actual s=
cope values.

                                                          
=C2=A0

                                                          
You can try =
to use scope values as their own matching rules. That is fine for a small s=
et of "static" scopes. It starts to fail when there are a large n=
umber of scopes, or scopes that can include parameters (resource paths? ema=
il addresses?). You can try to patch those failures by allowing services to=
 define service-specific special "wildcard" scope values that can=
 only be used during registration (eg "read:*").



                                                          
=C2=A0

                                                          
Alternativel=
y, replace 'scope' in registration with 'scope_regex' that =
holds a regular expression that all scope values in an authorization flow m=
ust match.



                                                          
=C2=A0

                                                          
--

                                                          
James Manger=


                                                          
____________=
___________________________________

                                                          
OAuth mailin=
g list

                                                          
OAuth@ietf.org

                                                          
https://www.ietf.org/mailman/listinfo/oaut=
h



                                                          

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          


_______________________________________________

                                                          OAuth mailing
                                                          list

                                                          OAuth@ietf.org

                                                          <=
span style=3D"color:purple">https://www.ietf.org/mailman/listinfo/oauth



                                                          

                                                          

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          

                                                          

                                                          
=C2=A0

                                                          

                                                        

                                                      

                                                    

                                                    

                                                      
=C2=A0

                                                    

                                                  

                                                  

                                                    
=
=C2=A0

                                                  

                                                

                                                

                                                  
=
=C2=A0

                                                

                                              

                                              

                                                
=C2=
=A0

                                              

                                            

                                          

                                        

                                        

                                          
=C2=A0

                                        

                                      

                                    

                                  

                                

                                

                                  
=C2=A0

                                

                              

                              
_______=
________________________________________

                                  OAuth mailing list

                                  OAuth@ietf.org

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

                            

                          

                          
=C2=A0

                        

                      

                    

                    

                  

                

              

            

          

          

        

      

    

    

  






--047d7bdc19d423078c04daa6b1e4--

From jricher@mitre.org  Thu Apr 18 11:47:14 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09D0E21E804A for ; Thu, 18 Apr 2013 11:47:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.827
X-Spam-Level: 
X-Spam-Status: No, score=-5.827 tagged_above=-999 required=5 tests=[AWL=-0.429, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, J_CHICKENPOX_26=0.6, 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 2RUa7-Ittuam for ; Thu, 18 Apr 2013 11:47:09 -0700 (PDT)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id E306721E8039 for ; Thu, 18 Apr 2013 11:47:08 -0700 (PDT)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A179F1F04C0; Thu, 18 Apr 2013 14:46:59 -0400 (EDT)
Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 4BFF81F0476; Thu, 18 Apr 2013 14:46:59 -0400 (EDT)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.342.3; Thu, 18 Apr 2013 14:46:58 -0400
Message-ID: <51703F97.7060103@mitre.org>
Date: Thu, 18 Apr 2013 14:46:47 -0400
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130329 Thunderbird/17.0.5
MIME-Version: 1.0
To: Tim Bray 
References: <255B9BB34FB7D647A506DC292726F6E1150C74DADA@WSMSG3153V.srv.dir.telstra.com> <516C3152.9070603@mitre.org> <4E1F6AAD24975D4BA5B168042967394367641FAB@TK5EX14MBXC283.redmond.corp.microsoft.com> <516C54F2.8040708@mitre.org> <4E1F6AAD24975D4BA5B16804296739436766BCC4@TK5EX14MBXC284.redmond.corp.microsoft.com>  <4E1F6AAD24975D4BA5B16804296739436766C964@TK5EX14MBXC284.redmond.corp.microsoft.com>    <4E1F6AAD24975D4BA5B16804296739436766D8B9@TK5EX14MBXC284.redmond.corp.microsoft.com> <5170319A.5080903@mitre.org>  <5170383E.3070603@mitre.org> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------000005010103000006040608"
X-Originating-IP: [129.83.31.58]
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: Scope Values
X-BeenThere: oauth@ietf.org
X-Mailman-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, 18 Apr 2013 18:47:14 -0000

--------------000005010103000006040608
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit


On 04/18/2013 02:22 PM, Tim Bray wrote:
> On Thu, Apr 18, 2013 at 11:15 AM, Justin Richer  > wrote:
>
>     clientProperties = oauth2.register("http://server/register"
>     , "My Client", "a b c d",
>     ["http://client/return" ]);
>
>     The server registers you, and clientProperties gets a client_id, a
>     client_name of "My Client", and a scope field of "a b d" since the
>     server said you couldn't dynamically register for "c" for whatever
>     reason.
>
>     Now let's say that you use the library to request authorization to
>     do something on the API. Your app can look inside of
>     clientProperties.scope to see what scopes you can do something with.
>
>
> So, your implication is that when the server says “a b d” that means 
> that you’d better not ask for any other scopes.  I agree.  This seems 
> like the only useful interpretation. So why shouldn’t we say that in 
> the spec?  -T

See the rest of the example below: I don't think we can usefully say 
that because it's too easy to interpret "a:read b:readwrite" as separate 
scopes from "a b", but in the context of some applications it might not 
be. What's really going on here, that I tried to demonstrate, is that 
there are several sets of scopes at play:

  A: what the client asks for at registration
  B: what the server gives the client at registration
  C: what the client asks for at authorization
  D: what the user/server give the client at authorization
  E: what the server gives the client at the token endpoint

I think that the registration spec should really only deal with A and B, 
and that's it. It can point out (mostly in the overall section) that 
these are probably useful for getting things done in steps C, D, and E, 
since this is the justification for having this as a registration-time 
parameter. Any attempts I've seen so far to have *useful* language 
around tying B to D (what's really at stake here) have been horribly 
complicated, overly restrictive, or red herrings that don't actually do 
what they say.

And the server can't depend on the client not asking for a scope it 
didn't register for and needs to be prepared for that case, so it 
doesn't really buy you anything saying that the client normatively 
*can't* ask for other scopes, because it can always try. A server might 
even give the client one of those extra scopes in certain circumstances 
(some special wildcard value, pattern matching against a policy engine, 
consultation with a guru), but all of this is API specific. The OAuth 
level of processing just knows that there's a scope there, and I'm fine 
with that.

  -- Justin

>
>     This will have the string "a b", which means something (to the
>     app) in the context of the API it's registering for, and it knows
>     it wants a token for "a b". Apps are going to need to know that,
>     but the library will do what the app tells it to. So the app calls
>     the library:
>
>     oauth2.authorize("http://server/authorize"
>     , "code", "a b", "http://client/return"
>     , "STATEVALUE@#$I(RJ@#")
>
>     A dumb app could even pass in whatever the value of
>     clientProperties.scope is (or a blank value) to try to get all of
>     its scopes. Or the app could know that the scopes are structured
>     and call:
>
>     oauth2.authorize("http://server/authorize"
>     , "code", "a:read b:readwrite",
>     "http://client/return" , "STATEVALUE@#$I(RJ@#")
>
>     Eventually you get back a code, then a token:
>
>     token = oauth2.token("http://server/token" ,
>     code, clientProperties)
>
>     (note that clientProperties will have the client_id,
>     client_secret, redirect_uri, and anything else needed here.)
>
>     Now, this token will *also* have a "scope" field. Let's say that
>     the user only authorized you for scope "a". If you want to be
>     smart about it, you can avoid calling endpoints that require "b".
>     Or you could just try it and be prepared to deal with a failing
>     token, like all OAuth clients must be able to do anyway.
>
>     I hope this makes sense, please forgive the off-the-cuff pseudocode.
>
>      -- Justin
>
>
>     On 04/18/2013 01:56 PM, Tim Bray wrote:
>>     On Thu, Apr 18, 2013 at 10:47 AM, Justin Richer
>>     > wrote:
>>
>>         It's very useful for a generic *library* that handles the
>>         authorization layer for an application to have a slot for
>>         registering scopes and finding out what scopes the app's been
>>         registered for.
>>
>>
>>     I don’t see how it’s useful in the slightest if there’s no
>>     defined semantic for what “registration” actually means, i.e.
>>     what result is to be expected when sending or receiving a list of
>>     scopes.   -T
>>
>>
>>
>>
>>         On 04/18/2013 01:04 PM, Mike Jones wrote:
>>>
>>>         Saying anything normative about “enforcing restrictions” is
>>>         going beyond RFC 6749 semantics.  Indeed, you’d said that “I
>>>         agree that we shouldn't try to "solve" scope in
>>>         registration.”, but talking about restrictions is going down
>>>         the slippery “solving it” path.
>>>
>>>         At most we can say that the two parties are making
>>>         declarations to one another about scopes that they may
>>>         choose to use, but we can’t assume that this is an exclusive
>>>         list and that other scope values such as
>>>         “urn:example:channel=HBO&urn:example:rating=G,PG-13” might
>>>         not be used, even if the client registers saying that it
>>>         intends to use the “OATC” scope value.  We could maybe even
>>>         say that some services may use a static set of scopes and
>>>         might choose to limit the scopes that a client may use to
>>>         those that it declared to the server or to those that the
>>>         server returned to the client.  That’s a HINT that some
>>>         services might do this.  But we can’t say anything normative
>>>         about such possible behaviors, because it goes beyond RFC 6749.
>>>
>>>         -- Mike
>>>
>>>         *From:*Richer, Justin P. [mailto:jricher@mitre.org]
>>>         *Sent:* Thursday, April 18, 2013 9:26 AM
>>>         *To:* Anthony Nadalin
>>>         *Cc:* Tim Bray; Mike Jones; oauth@ietf.org
>>>         
>>>         *Subject:* Re: [OAUTH-WG] Registration: Scope Values
>>>
>>>         This doesn't actually break the semantics because the client
>>>         MUST accept what the server tells it over anything that it
>>>         asks for in the first place. The server has the final say.
>>>         So in this case, if your client asks for nothing, the server
>>>         says "A B C", the client now knows it can ask for "A B C"
>>>         scopes.
>>>
>>>         I'm still in favor of not putting the restricting language
>>>         in the scope definition at all, instead have it say
>>>         something like:
>>>
>>>             “Space-separated list of scope values (as described in
>>>             OAuth 2.0 Section 3.3 [RFC6749]
>>>             ) that
>>>             the Client can use when requesting access tokens from
>>>             the Authorization Server. As scope values are service
>>>             specific, the means of the Authorization Server
>>>             enforcing this restriction are outside the scope of this
>>>             specification.”
>>>
>>>         Couple this with the overall paragraph that says that the
>>>         client is requesting values that the server is potentially
>>>         overriding with its declarations, and I think that addresses
>>>         everything without getting into confusing language that
>>>         doesn't add to interoperability.
>>>
>>>          -- Justin
>>>
>>>         On Apr 18, 2013, at 12:13 PM, Anthony Nadalin
>>>         > wrote:
>>>
>>>
>>>
>>>         If I don’t specify a scope, then the server can allocate a
>>>         default (or default set), thus that breaks the semantics you
>>>         describe
>>>
>>>         *From:*oauth-bounces@ietf.org
>>>         
>>>         [mailto:oauth-bounces@ietf.org ]*On
>>>         Behalf Of*Tim Bray
>>>         *Sent:*Thursday, April 18, 2013 9:04 AM
>>>         *To:*Mike Jones
>>>         *Cc:*oauth@ietf.org 
>>>         *Subject:*Re: [OAUTH-WG] Registration: Scope Values
>>>
>>>         I’m unconvinced, Mike.  Obviously you’re right about the
>>>         looseness of OAuth2 scope specification, but this is a very
>>>         specific semantic of what happens when you register, and I
>>>         don’t think we’re bound by history here.   If we can’t
>>>         safely say anything about what the list of scopes means,
>>>         then I'm with you let's take them out.  But the most obvious
>>>         intended semantic is (from the client) “I promise to ask
>>>         only for these” and from the server “These are the only ones
>>>         I’ll give you tokens for.”  Or does someone have use-cases
>>>         for an alternative semantic?
>>>
>>>         To make this concrete, I propose the following:
>>>
>>>         “Space-separated list of scope values (as described in OAuth
>>>         2.0 Section 3.3 [RFC6749]
>>>         ) that the
>>>         client is declaring to the server that it will restrict
>>>         itself to when requesting access tokens, and that the server
>>>         is declaring to the client that it is registered to use when
>>>         requesting access tokens. Clients SHOULD assume that servers
>>>         will refuse to grant access tokens for scopes not in the
>>>         list provided by the server.”
>>>
>>>         On Thu, Apr 18, 2013 at 8:55 AM, Mike Jones
>>>         >>         > wrote:
>>>
>>>             I don’t think it’s possible to define what it means in
>>>             an interoperable way because OAuth didn’t specify scopes
>>>             in an interoperable way.  No, I don’t like that either,
>>>             but I think that’s where things are. That’s why I was
>>>             advocating deleting this registration feature entirely.
>>>
>>>             But understanding it might be useful in some contexts,
>>>             I’m OK keeping it, provided we be clear that the
>>>             semantics of “registered to use” are service-specific.
>>>
>>>             -- Mike
>>>
>>>             *From:*Tim Bray [mailto:twbray@google.com
>>>             ]
>>>             *Sent:*Thursday, April 18, 2013 8:36 AM
>>>             *To:*Mike Jones
>>>             *Cc:*Justin Richer;oauth@ietf.org 
>>>
>>>
>>>             *Subject:*Re: [OAUTH-WG] Registration: Scope Values
>>>
>>>             On the server-to-client side, what does “registered to
>>>             use” mean?  Does it mean that the client should assume
>>>             that any scopes not on the list WILL not be granted, MAY
>>>             not be granted.... or what?  Is this already covered
>>>             elsewhere? -T
>>>
>>>             On Thu, Apr 18, 2013 at 8:28 AM, Mike Jones
>>>             >>             > wrote:
>>>
>>>             Thanks, Justin.  I agree with the need for the generic
>>>             two-sided language.  I’d still keep this language for
>>>             scope, because we want to capture the “declaring” aspect
>>>             in this case:
>>>
>>>             “Space separated list of scope values (as described in
>>>             OAuth 2.0Section 3.3 [RFC6749]
>>>             ) that
>>>             the client is declaring to the server that it may use
>>>             when requesting access tokens and that the server is
>>>             declaring to the client that it is registered to use
>>>             when requesting access tokens.”.
>>>
>>>             You should probably also reinforce that scope values are
>>>             service-specific and may not consist only of a static
>>>             set of string values, and that therefore, in some cases,
>>>             an exhaustive list of registered scope values is not
>>>             possible.
>>>
>>>             -- Mike
>>>
>>>             *From:*Justin Richer [mailto:jricher@mitre.org
>>>             ]
>>>             *Sent:*Monday, April 15, 2013 12:29 PM
>>>
>>>
>>>             *To:*Mike Jones
>>>             *Cc:*Tim Bray;oauth@ietf.org 
>>>             *Subject:*Re: [OAUTH-WG] Registration: Scope Values
>>>
>>>             I think that because the "declaration" issue affects all
>>>             parameters in the list, not just scope, we should adopt
>>>             this in a higher level paragraph and leave it out of the
>>>             individual parameter descriptions. Thus, something like
>>>             this inserted as the second paragraph in section 2:
>>>
>>>             The client metadata values serve two parallel purposes
>>>             in the overall OAuth Dynamic Registration protocol:
>>>
>>>              - the Client requesting its desired values for each
>>>             parameter to the Authorization Server in a [register] or
>>>             [update] request,
>>>              - the Authorization Server informing the Client of the
>>>             current values of each parameter that the Client has
>>>             been registered to use through a [client information
>>>             response].
>>>
>>>             An Authorization Server MAY override any value that a
>>>             Client requests during the registration process
>>>             (including any omitted values) and replace the requested
>>>             value with a default. The normative indications in the
>>>             following list apply to the Client's declaration of its
>>>             desired values.
>>>
>>>             The Authorization Server SHOULD provide documentation
>>>             for any fields that it requires to be filled in by the
>>>             client or to have particular values or formats.
>>>             Extensions and profiles...
>>>
>>>
>>>             And then remove the sidedness-language from the scope
>>>             parameter and any other parameters where it might have
>>>             crept in inadvertently.
>>>
>>>              -- Justin
>>>
>>>             On 04/15/2013 01:29 PM, Mike Jones wrote:
>>>
>>>                 We could fix the one-sided language by changing
>>>
>>>                 “Space separated list of scope values (as described
>>>                 in OAuth 2.0Section 3.3 [RFC6749]
>>>                 )
>>>                 that the client is declaring that it may use when
>>>                 requesting access tokens.”
>>>
>>>                 to
>>>
>>>                 “Space separated list of scope values (as described
>>>                 in OAuth 2.0Section 3.3 [RFC6749]
>>>                 )
>>>                 that the client is declaring to the server that it
>>>                 may use when requesting access tokens and that the
>>>                 server is declaring to the client that it is
>>>                 registered to use when requesting access tokens.”.
>>>
>>>                 Again, I chose the “registered to use” language
>>>                 carefully – because in the general case it’s not a
>>>                 restriction on the values that the client can use –
>>>                 just a statement by the server to the client that it
>>>                 is registered to use those particular values.  In
>>>                 both cases, the parties are making declarations to
>>>                 one another.
>>>
>>>                 If you adopt that language (or keep the original
>>>                 language), then yes, I’d consider this closed.
>>>
>>>                 -- Mike
>>>
>>>                 *From:*Justin Richer [mailto:jricher@mitre.org]
>>>                 *Sent:*Monday, April 15, 2013 9:57 AM
>>>                 *To:*Mike Jones
>>>                 *Cc:*Tim Bray;oauth@ietf.org 
>>>                 *Subject:*Re: [OAUTH-WG] Registration: Scope Values
>>>
>>>                 I absolutely do not want to delete this feature, as
>>>                 (having implemented it) I think it's very useful.
>>>                 This is a very established pattern in manual
>>>                 registration: I know of many, many OAuth2 servers
>>>                 and clients that are set up where the client must
>>>                 pre-register a set of scopes.
>>>
>>>                 I don't like the language of "the client is
>>>                 declaring" because it's too one-sided. The client
>>>                 might not have declared anything, and it might be
>>>                 the server that's declaring something to the client.
>>>                 Deleting the "is declaring" bit removes that
>>>                 unintended restriction of the language while keeping
>>>                 the original meaning intact. I actually thought that
>>>                 I had fixed that before the last draft went in but
>>>                 apparently I missed this one.
>>>
>>>                 I will work on clarifying the intent of the whole
>>>                 metadata set in its introductory paragraph(s) so
>>>                 that it's clear that all of these fields are used in
>>>                 both of these situations:
>>>
>>>                  1) The client declaring to the server its desire to
>>>                 use a particular value
>>>                  2) The server declaring to the client that it has
>>>                 been registered with a particular value
>>>
>>>                 This should hopefully clear up the issue in the
>>>                 editor's note that I currently have at the top of
>>>                 that section right now, too.
>>>
>>>                 Mike, since you were the one who originally brought
>>>                 up the issue, and you're fine with the existing
>>>                 text, can I take this as closed now? Assuming that
>>>                 you agree with deleting "is declaring" for reasons
>>>                 stated above, I'm fine with leaving everything else
>>>                 as is and staying quiet on what the server has to do
>>>                 with the scopes.
>>>
>>>                  -- Justin
>>>
>>>                 On 04/15/2013 12:44 PM, Mike Jones wrote:
>>>
>>>                     I think that the existing wording is superior to
>>>                     the proposed changed wording.  The existing
>>>                     wording is:
>>>
>>>                     scope
>>>
>>>                     OPTIONAL. Space separated list of scope values
>>>                     (as described in
>>>
>>>                     OAuth 2.0Section 3.3 [RFC6749]
>>>                     ) that
>>>                     the client is declaring that
>>>
>>>                     it may use when requesting access tokens.  If
>>>                     omitted, an
>>>
>>>                     Authorization Server MAY register a Client with
>>>                     a default set of
>>>
>>>                     scopes.
>>>
>>>                     For instance, the current “client is declaring”
>>>                     wording will always be correct, whereas as the
>>>                     change to “client can use” wording implies a
>>>                     restriction on client behavior that is not
>>>                     always applicable. The “client is declaring”
>>>                     wording was specific and purposefully chosen,
>>>                     and I think should be retained. In particular,
>>>                     we can’t do anything that implies that only the
>>>                     registered scopes values can be used. At the
>>>                     OAuth spec level, this is a hint as to possible
>>>                     future client behavior – not a restriction on
>>>                     future client behavior.
>>>
>>>                     Also, for the reasons that Tim stated, I’m
>>>                     strongly against any “matching” or “regex”
>>>                     language in the spec pertaining to scopes – as
>>>                     it’s not actionable.
>>>
>>>                     So I’d propose that we leave the existing scope
>>>                     wording in place. Alternatively, I’d also be
>>>                     fine with deleting this feature entirely, as I
>>>                     don’t think it’s useful in the general case.
>>>
>>>                     -- Mike
>>>
>>>                     *From:*oauth-bounces@ietf.org
>>>                     [mailto:oauth-bounces@ietf.org]*On
>>>                     Behalf Of*Justin Richer
>>>                     *Sent:*Monday, April 15, 2013 8:05 AM
>>>                     *To:*Tim Bray;oauth@ietf.org 
>>>                     *Subject:*Re: [OAUTH-WG] Registration: Scope Values
>>>
>>>                     On 04/15/2013 10:52 AM, Tim Bray wrote:
>>>
>>>
>>>                     I’d use the existing wording; it’s perfectly
>>>                     clear.  Failing that, if there’s strong demand
>>>                     for registration of structured scopes, bless the
>>>                     use of regexes, either PCREs or some careful subset.
>>>
>>>
>>>                     Thanks for the feedback -- Of these two choices,
>>>                     I'd rather leave it as-is.
>>>
>>>
>>>
>>>                     However, I’d subtract the sentence “If omitted,
>>>                     an Authorization Server MAY register a Client
>>>                     with a default set of  scopes.”  It adds no
>>>                     value; if the client doesn’t declare scopes, the
>>>                     client doesn’t declare scopes, that’s all.  -T
>>>
>>>
>>>                     Remember, all of these fields aren't just for
>>>                     the client *request*, they're also for the
>>>                     server's *response* to either a POST, PUT, or
>>>                     GET request. (I didn't realize it, but perhaps
>>>                     the wording as stated right now doesn't make
>>>                     that clear -- I need to fix that.) The value
>>>                     that it adds is if the client doesn't ask for
>>>                     any particular scopes, the server can still
>>>                     assign it scopes and the client can do something
>>>                     smart with that. Dumb clients are allowed to
>>>                     ignore it if it doesn't mean anything to them.
>>>
>>>                     This is how our server implementation actually
>>>                     works right now. If the client doesn't ask for
>>>                     anything specific at registration, the server
>>>                     hands it a bag of "default" scopes. Same thing
>>>                     happens at auth time -- if the client doesn't
>>>                     ask for any particular scopes, the server hands
>>>                     it all of its registered scopes as a default.
>>>                     Granted, on our server, scopes are just simple
>>>                     strings right now, so they get compared at the
>>>                     auth endpoint with an exact string-match metric
>>>                     and set-based logic.
>>>
>>>                      -- Justin
>>>
>>>
>>>
>>>                     On Mon, Apr 15, 2013 at 7:35 AM, Justin Richer
>>>                     >
>>>                     wrote:
>>>
>>>                     What would you suggest for wording here, then?
>>>                     Keeping in mind that we cannot (and don't want
>>>                     to) prohibit expression-based scopes.
>>>
>>>                      -- Justin
>>>
>>>                     On 04/15/2013 10:33 AM, Tim Bray wrote:
>>>
>>>                         No, I mean it’s not interoperable at the
>>>                         software-developer level.  I can’t register
>>>                         scopes at authorization time with any
>>>                         predictable effect that I can write code to
>>>                         support, either client or server side,
>>>                         without out-of-line non-interoperable
>>>                         knowledge about the behavior of the server.
>>>
>>>                         I guess I’m just not used to OAuth’s culture
>>>                         of having no expectation that things will be
>>>                         specified tightly enough that I can write
>>>                         code to implement as specified.  -T
>>>
>>>                         On Mon, Apr 15, 2013 at 7:15 AM, Justin
>>>                         Richer >>                         > wrote:
>>>
>>>                         Scopes aren't meant to be interoperable
>>>                         between services since they're necessarily
>>>                         API-specific. The only interoperable bit is
>>>                         that there's *some* place to put the values
>>>                         and that it's expressed as a bag of
>>>                         space-separated strings. How those strings
>>>                         get interpreted and enforced (which is
>>>                         really what's at stake here) is up to the AS
>>>                         and PR (or a higher-level protocol like UMA).
>>>
>>>                          -- Justin
>>>
>>>                         On 04/15/2013 10:13 AM, Tim Bray wrote:
>>>
>>>                             This, as written, has zero
>>>                             interoperability. I think this feature
>>>                             can really only be made useful in the
>>>                             case where scopes are fixed strings.
>>>
>>>                             -T
>>>
>>>                             On Apr 15, 2013 6:54 AM, "Justin Richer"
>>>                             >>                             > wrote:
>>>
>>>                             You are correct that the idea behind the
>>>                             "scope" parameter at registration is a
>>>                             constraint on authorization-time scopes
>>>                             that are made available. It's both a
>>>                             means for the client to request a set of
>>>                             valid scopes and for the server to
>>>                             provision (and echo back to the client)
>>>                             a set of valid scopes.
>>>
>>>                             I *really* don't want to try to define a
>>>                             matching language for scope expressions.
>>>                             For that to work, all servers would need
>>>                             to be able to process the regular
>>>                             expressions for all clients, even if the
>>>                             servers themselves only support
>>>                             simple-string scope values. Any regular
>>>                             expression syntax we pick here is
>>>                             guaranteed to be incompatible with
>>>                             something, and I think the complexity
>>>                             doesn't buy much. Also, I think you
>>>                             suddenly have a potential security issue
>>>                             if you have a bad regex in place on
>>>                             either end.
>>>
>>>                             As it stands today, the server can
>>>                             interpret the incoming registration
>>>                             scopes and enforce them however it wants
>>>                             to. The real trick comes not from
>>>                             assigning the values to a particular
>>>                             client but to enforcing them, and I
>>>                             think that's always going to be
>>>                             service-specific. We're just not as
>>>                             clear on that as we could be.
>>>
>>>                             After looking over everyone's comments
>>>                             so far, I'd like to propose the
>>>                             following text for that section:
>>>
>>>
>>>                                 scope
>>>
>>>                                    OPTIONAL.  Space separated list of scope values (as described in
>>>
>>>                                    OAuth 2.0Section 3.3 [RFC6749]  ) that the client can use when
>>>
>>>                                    requesting access tokens.  As scope values are service-specific,
>>>
>>>                                    the Authorization Server MAY define its own matching rules when
>>>
>>>                                    determining if a scope value used during an authorization request
>>>
>>>                                    is valid according to the scope values assigned during
>>>
>>>                                    registration. Possible matching rules include wildcard patterns,
>>>
>>>                                    regular expressions, or exactly matching the string. If omitted,
>>>
>>>                                    an Authorization Server MAY register a Client with a default
>>>
>>>                                    set of scopes.
>>>
>>>
>>>                             Comments? Improvements?
>>>
>>>                              -- Justin
>>>
>>>
>>>                             On 04/14/2013 08:23 PM, Manger, James H
>>>                             wrote:
>>>
>>>                                 Presumably at app registration time any scope specification is really a constraint on the scope values that can be requested in an authorization flow.
>>>
>>>                                   
>>>
>>>                                 So ideally registration should accept rules for matching scopes, as opposed to actual scope values.
>>>
>>>                                   
>>>
>>>                                 You can try to use scope values as their own matching rules. That is fine for a small set of "static" scopes. It starts to fail when there are a large number of scopes, or scopes that can include parameters (resource paths? email addresses?). You can try to patch those failures by allowing services to define service-specific special "wildcard" scope values that can only be used during registration (eg "read:*").
>>>
>>>                                   
>>>
>>>                                 Alternatively, replace 'scope' in registration with 'scope_regex' that holds a regular expression that all scope values in an authorization flow must match.
>>>
>>>                                   
>>>
>>>                                 --
>>>
>>>                                 James Manger
>>>
>>>                                 _______________________________________________
>>>
>>>                                 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
>>>
>>
>>
>
>


--------------000005010103000006040608
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: 8bit


  
    
  
  
    

    
On 04/18/2013 02:22 PM, Tim Bray wrote:

    

    

      
      
On Thu, Apr 18, 2013 at 11:15 AM, Justin Richer <jricher@mitre.org> wrote:

        

          

            

              
clientProperties =
                oauth2.register("http://server/register", "My
                Client", "a b c d", ["http://client/return"]);

                

                The server registers you, and clientProperties gets a
                client_id, a client_name of "My Client", and a scope
                field of "a b d" since the server said you couldn't
                dynamically register for "c" for whatever reason.

                

                Now let's say that you use the library to request
                authorization to do something on the API. Your app can
                look inside of clientProperties.scope to see what scopes
                you can do something with.

            

            


            

            
So, your implication is that when the server
              says “a b d” that means that you’d better not ask for any
              other scopes.  I agree.  This seems like the only useful
              interpretation. So why shouldn’t we say that in the spec?
               -T

          

        

      

    

    

    See the rest of the example below: I don't think we can usefully say
    that because it's too easy to interpret "a:read b:readwrite" as
    separate scopes from "a b", but in the context of some applications
    it might not be. What's really going on here, that I tried to
    demonstrate, is that there are several sets of scopes at play:

    

     A: what the client asks for at registration

     B: what the server gives the client at registration

     C: what the client asks for at authorization

     D: what the user/server give the client at authorization

     E: what the server gives the client at the token endpoint

    

    I think that the registration spec should really only deal with A
    and B, and that's it. It can point out (mostly in the overall
    section) that these are probably useful for getting things done in
    steps C, D, and E, since this is the justification for having this
    as a registration-time parameter. Any attempts I've seen so far to
    have *useful* language around tying B to D (what's really at stake
    here) have been horribly complicated, overly restrictive, or red
    herrings that don't actually do what they say.

    

    And the server can't depend on the client not asking for a scope it
    didn't register for and needs to be prepared for that case, so it
    doesn't really buy you anything saying that the client normatively
    *can't* ask for other scopes, because it can always try. A server
    might even give the client one of those extra scopes in certain
    circumstances (some special wildcard value, pattern matching against
    a policy engine, consultation with a guru), but all of this is API
    specific. The OAuth level of processing just knows that there's a
    scope there, and I'm fine with that.

    

     -- Justin

    

    

      

        

          

            


            

            
 

            

              
 This will have the
                string "a b", which means something (to the app) in the
                context of the API it's registering for, and it knows it
                wants a token for "a b". Apps are going to need to know
                that, but the library will do what the app tells it to.
                So the app calls the library:

                

                oauth2.authorize("http://server/authorize", "code",
                "a b", "http://client/return",
                "STATEVALUE@#$I(RJ@#")

                

                A dumb app could even pass in whatever the value of
                clientProperties.scope is (or a blank value) to try to
                get all of its scopes. Or the app could know that the
                scopes are structured and call:

                

                oauth2.authorize("http://server/authorize", "code",
                "a:read b:readwrite", "http://client/return",
                "STATEVALUE@#$I(RJ@#")

                

                Eventually you get back a code, then a token:

                

                token = oauth2.token("http://server/token", code,
                clientProperties)

                

                (note that clientProperties will have the client_id,
                client_secret, redirect_uri, and anything else needed
                here.)

                

                Now, this token will *also* have a "scope" field. Let's
                say that the user only authorized you for scope "a". If
                you want to be smart about it, you can avoid calling
                endpoints that require "b". Or you could just try it and
                be prepared to deal with a failing token, like all OAuth
                clients must be able to do anyway.

                

                I hope this makes sense, please forgive the off-the-cuff
                pseudocode.

                

                 -- Justin

                

                

                
On 04/18/2013 01:56 PM, Tim Bray wrote:

                

                

                  
On Thu, Apr 18, 2013 at 10:47 AM,
                    Justin Richer <jricher@mitre.org>
                    wrote:

                    

                      

                        
 

                        

                          
 It's
                            very useful for a generic *library* that
                            handles the authorization layer for an
                            application to have a slot for registering
                            scopes and finding out what scopes the app's
                            been registered for.

                        

                        


                        

                        
I don’t see how it’s useful in the
                          slightest if there’s no defined semantic for
                          what “registration” actually means, i.e. what
                          result is to be expected when sending or
                          receiving a list of scopes.   -T

                        
 

                        

                          


                            

                              


                                

                                
On 04/18/2013 01:04 PM, Mike Jones
                                  wrote:

                                

                                

                                  

                                    
Saying


                                        anything normative about
                                        “enforcing restrictions” is
                                        going beyond RFC 6749
                                        semantics.  Indeed, you’d said
                                        that “I agree that we
                                      shouldn't try to "solve" scope in
                                      registration.”,


                                        but talking about restrictions
                                        is going down the slippery
                                        “solving it” path.

                                    
 

                                    
At


                                        most we can say that the two
                                        parties are making declarations
                                        to one another about scopes that
                                        they may choose to use, but we
                                        can’t assume that this is an
                                        exclusive list and that other
                                        scope values such as “urn:example:channel=HBO&urn:example:rating=G,PG-13”
                                        might not be used, even if the
                                        client registers saying that it
                                        intends to use the “OATC” scope
                                        value.  We could maybe even say
                                        that some services may use a
                                        static set of scopes and might
                                        choose to limit the scopes that
                                        a client may use to those that
                                        it declared to the server or to
                                        those that the server returned
                                        to the client.  That’s a HINT
                                        that some services might do
                                        this.  But we can’t say anything
                                        normative about such possible
                                        behaviors, because it goes
                                        beyond RFC 6749.

                                    
 

                                    
                                                           


                                        -- Mike

                                    
 

                                    

                                      

                                        
From:
                                            Richer, Justin P. [mailto:jricher@mitre.org]
                                            

                                            Sent: Thursday, April
                                            18, 2013 9:26 AM

                                            To: Anthony Nadalin

                                            Cc: Tim Bray; Mike
                                            Jones; oauth@ietf.org

                                            Subject: Re:
                                            [OAUTH-WG] Registration:
                                            Scope Values

                                      

                                    

                                    
 

                                    

                                      
This doesn't
                                        actually break the semantics
                                        because the client MUST accept
                                        what the server tells it over
                                        anything that it asks for in the
                                        first place. The server has the
                                        final say. So in this case, if
                                        your client asks for nothing,
                                        the server says "A B C", the
                                        client now knows it can ask for
                                        "A B C" scopes. 

                                    

                                    

                                      
 

                                    

                                    

                                      
I'm still in
                                        favor of not putting the
                                        restricting language in the
                                        scope definition at all, instead
                                        have it say something like:

                                    

                                    

                                      
 

                                    

                                    

                                      

                                        

                                          

                                            
“Space-separated
                                                list of scope values (as
                                                described in OAuth 2.0 Section 3.3

                                                    [RFC6749])
                                                that the Client can use
                                                when requesting access
                                                tokens from the
                                                Authorization Server. As
                                                scope values are service
                                                specific, the means of
                                                the Authorization Server
                                                enforcing this
                                                restriction are outside
                                                the scope of this
                                                specification.”

                                          

                                        

                                      

                                      
 

                                    

                                    

                                      
Couple this
                                        with the overall paragraph that
                                        says that the client is
                                        requesting values that the
                                        server is potentially overriding
                                        with its declarations, and I
                                        think that addresses everything
                                        without getting into confusing
                                        language that doesn't add to
                                        interoperability. 

                                    

                                    

                                      
 

                                    

                                    

                                      
 -- Justin

                                    

                                    

                                      
 

                                      

                                        

                                          
On Apr
                                            18, 2013, at 12:13 PM,
                                            Anthony Nadalin <tonynad@microsoft.com>


                                            wrote:

                                        

                                        


                                          

                                        

                                        

                                          

                                            
If


                                                I don’t specify a scope,
                                                then the server can
                                                allocate a default (or
                                                default set), thus that
                                                breaks the semantics you
                                                describe

                                          

                                          
                                          

                                            
From: oauth-bounces@ietf.org
                                                [mailto:oauth-bounces@ietf.org] On

                                                  Behalf Of Tim

                                                Bray

                                                Sent: Thursday,

                                                April 18, 2013 9:04 AM

                                                To: Mike
                                                Jones

                                                Cc: oauth@ietf.org

                                                Subject: Re:

                                                [OAUTH-WG] Registration:
                                                Scope Values

                                          

                                          

                                            
 

                                          

                                          

                                            

                                              
I’m
                                                unconvinced, Mike.
                                                 Obviously you’re right
                                                about the looseness of
                                                OAuth2 scope
                                                specification, but this
                                                is a very specific
                                                semantic of what happens
                                                when you register, and I
                                                don’t think we’re bound
                                                by history here.   If we
                                                can’t safely say
                                                anything about what the
                                                list of scopes means,
                                                then I'm with you let's
                                                take them out.  But the
                                                most obvious intended
                                                semantic is (from the
                                                client) “I promise to
                                                ask only for these” and
                                                from the server “These
                                                are the only ones I’ll
                                                give you tokens for.”
                                                 Or does someone have
                                                use-cases for an
                                                alternative semantic?

                                            

                                            

                                              

                                                
 

                                              

                                            

                                            

                                              

                                                
To
                                                  make this concrete, I
                                                  propose the following:

                                              

                                            

                                            

                                              

                                                
“Space-separated
                                                    list of scope values
                                                    (as described in
                                                    OAuth 2.0 Section 3.3 [RFC6749]) that the client
                                                    is declaring to the
                                                    server that it will
                                                    restrict itself to
                                                    when requesting
                                                    access tokens, and
                                                    that the server is
                                                    declaring to the
                                                    client that it is
                                                    registered to use
                                                    when requesting
                                                    access tokens.  Clients

                                                    SHOULD assume that
                                                    servers will refuse
                                                    to grant access
                                                    tokens for scopes
                                                    not in the list
                                                    provided by the
                                                    server.”

                                              

                                              

                                                

                                                  
 

                                                

                                              

                                            

                                          

                                          

                                            
 

                                            

                                              

                                                
On
                                                  Thu, Apr 18, 2013 at
                                                  8:55 AM, Mike Jones
                                                  <Michael.Jones@microsoft.com> wrote:

                                              

                                              

                                                

                                                  
I
                                                      don’t think it’s
                                                      possible to define
                                                      what it means in
                                                      an interoperable
                                                      way because OAuth
                                                      didn’t specify
                                                      scopes in an
                                                      interoperable
                                                      way.  No, I don’t
                                                      like that either,
                                                      but I think that’s
                                                      where things are. 
                                                      That’s why I was
                                                      advocating
                                                      deleting this
                                                      registration
                                                      feature entirely.

                                                

                                                

                                                  
 

                                                

                                                

                                                  
But


                                                      understanding it
                                                      might be useful in
                                                      some contexts, I’m
                                                      OK keeping it,
                                                      provided we be
                                                      clear that the
                                                      semantics of
                                                      “registered to
                                                      use” are
                                                      service-specific.

                                                

                                                

                                                  
 

                                                

                                                

                                                  
                                                           


                                                      -- Mike

                                                

                                                

                                                  
 

                                                

                                                

                                                  
From: Tim



                                                      Bray [mailto:twbray@google.com] 

                                                      Sent: Thursday,


                                                      April 18, 2013
                                                      8:36 AM

                                                      To: Mike

                                                      Jones

                                                      Cc: Justin

                                                      Richer; oauth@ietf.org

                                                

                                                

                                                  

                                                    


                                                      Subject: Re:


                                                      [OAUTH-WG]
                                                      Registration:
                                                      Scope Values

                                                  

                                                

                                                

                                                  

                                                    
 

                                                  

                                                  

                                                    

                                                      
On
                                                        the
                                                        server-to-client
                                                        side, what does
                                                        “registered to
                                                        use” mean?  Does
                                                        it mean that the
                                                        client should
                                                        assume that any
                                                        scopes not on
                                                        the list WILL
                                                        not be granted,
                                                        MAY not be
                                                        granted.... or
                                                        what?  Is this
                                                        already covered
                                                        elsewhere? -T

                                                    

                                                  

                                                  

                                                    
 

                                                    

                                                      

                                                        
On
                                                          Thu, Apr 18,
                                                          2013 at 8:28
                                                          AM, Mike Jones
                                                          <Michael.Jones@microsoft.com> wrote:

                                                      

                                                      

                                                        

                                                          
Thanks,


                                                          Justin.  I
                                                          agree with the
                                                          need for the
                                                          generic
                                                          two-sided
                                                          language.  I’d
                                                          still keep
                                                          this language
                                                          for scope,
                                                          because we
                                                          want to
                                                          capture the
                                                          “declaring”
                                                          aspect in this
                                                          case:

                                                        

                                                        

                                                          

                                                          
 

                                                          

                                                          

                                                          
“Space

                                                          separated list
                                                          of scope
                                                          values (as
                                                          described in
                                                          OAuth 2.0 Section 3.3
                                                          [RFC6749])
                                                          that the
                                                          client is
                                                          declaring to
                                                          the server
                                                          that it may
                                                          use when
                                                          requesting
                                                          access tokens
                                                          and that the
                                                          server is
                                                          declaring to
                                                          the client
                                                          that it is
                                                          registered to
                                                          use when
                                                          requesting
                                                          access tokens.”.

                                                          

                                                          

                                                          
 

                                                          

                                                        

                                                        

                                                          
You


                                                          should
                                                          probably also
                                                          reinforce that
                                                          scope values
                                                          are
                                                          service-specific
                                                          and may not
                                                          consist only
                                                          of a static
                                                          set of string
                                                          values, and
                                                          that
                                                          therefore, in
                                                          some cases, an
                                                          exhaustive
                                                          list of
                                                          registered
                                                          scope values
                                                          is not
                                                          possible.

                                                        

                                                        

                                                          
 

                                                        

                                                        

                                                          
                                                           


                                                          -- Mike

                                                        

                                                        

                                                          
 

                                                        

                                                        

                                                          

                                                          

                                                          
From: Justin



                                                          Richer
                                                          [mailto:jricher@mitre.org] 

                                                          Sent: Monday,


                                                          April 15, 2013
                                                          12:29 PM

                                                          

                                                          

                                                          

                                                          


                                                          To: Mike


                                                          Jones

                                                          Cc: Tim


                                                          Bray; oauth@ietf.org

                                                          Subject: Re:


                                                          [OAUTH-WG]
                                                          Registration:
                                                          Scope Values

                                                          

                                                          

                                                          

                                                        

                                                        

                                                          

                                                          
 

                                                          

                                                          
I think that because the "declaration"
                                                          issue affects
                                                          all parameters
                                                          in the list,
                                                          not just
                                                          scope, we
                                                          should adopt
                                                          this in a
                                                          higher level
                                                          paragraph and
                                                          leave it out
                                                          of the
                                                          individual
                                                          parameter
                                                          descriptions.
                                                          Thus,
                                                          something like
                                                          this inserted
                                                          as the second
                                                          paragraph in
                                                          section 2:

                                                          

                                                          
The

                                                          client
                                                          metadata
                                                          values serve
                                                          two parallel
                                                          purposes in
                                                          the overall
                                                          OAuth Dynamic
                                                          Registration
                                                          protocol: 

                                                          

                                                           - the Client
                                                          requesting its
                                                          desired values
                                                          for each
                                                          parameter to
                                                          the
                                                          Authorization
                                                          Server in a
                                                          [register] or
                                                          [update]
                                                          request,

                                                           - the
                                                          Authorization
                                                          Server
                                                          informing the
                                                          Client of the
                                                          current values
                                                          of each
                                                          parameter that
                                                          the Client has
                                                          been
                                                          registered to
                                                          use through a
                                                          [client
                                                          information
                                                          response]. 

                                                          

                                                          An
                                                          Authorization
                                                          Server MAY
                                                          override any
                                                          value that a
                                                          Client
                                                          requests
                                                          during the
                                                          registration
                                                          process
                                                          (including any
                                                          omitted
                                                          values) and
                                                          replace the
                                                          requested
                                                          value with a
                                                          default. The
                                                          normative
                                                          indications in
                                                          the following
                                                          list apply to
                                                          the Client's
                                                          declaration of
                                                          its desired
                                                          values. 

                                                          

                                                          The
                                                          Authorization
                                                          Server SHOULD
                                                          provide
                                                          documentation
                                                          for any fields
                                                          that it
                                                          requires to be
                                                          filled in by
                                                          the client or
                                                          to have
                                                          particular
                                                          values or
                                                          formats.
                                                          Extensions and
                                                          profiles...

                                                          

                                                          


                                                          And then
                                                          remove the
                                                          sidedness-language
                                                          from the scope
                                                          parameter and
                                                          any other
                                                          parameters
                                                          where it might
                                                          have crept in
                                                          inadvertently. 

                                                          

                                                           -- Justin

                                                          

                                                          

                                                          
On

                                                          04/15/2013
                                                          01:29 PM, Mike
                                                          Jones wrote:

                                                          

                                                          

                                                          

                                                          

                                                          
We


                                                          could fix the
                                                          one-sided
                                                          language by
                                                          changing

                                                          

                                                          

                                                          
“Space

                                                          separated list
                                                          of scope
                                                          values (as
                                                          described in
                                                          OAuth 2.0 Section 3.3
                                                          [RFC6749])
                                                          that the
                                                          client is
                                                          declaring that
                                                          it may use
                                                          when
                                                          requesting
                                                          access tokens.”

                                                          

                                                          

                                                          
to

                                                          

                                                          

                                                          
“Space

                                                          separated list
                                                          of scope
                                                          values (as
                                                          described in
                                                          OAuth 2.0 Section 3.3
                                                          [RFC6749])
                                                          that the
                                                          client is
                                                          declaring to
                                                          the server
                                                          that it may
                                                          use when
                                                          requesting
                                                          access tokens
                                                          and that the
                                                          server is
                                                          declaring to
                                                          the client
                                                          that it is
                                                          registered to
                                                          use when
                                                          requesting
                                                          access tokens.”.

                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          
Again,


                                                          I chose the
                                                          “registered to
                                                          use” language
                                                          carefully –
                                                          because in the
                                                          general case
                                                          it’s not a
                                                          restriction on
                                                          the values
                                                          that the
                                                          client can use
                                                          – just a
                                                          statement by
                                                          the server to
                                                          the client
                                                          that it is
                                                          registered to
                                                          use those
                                                          particular
                                                          values.  In
                                                          both cases,
                                                          the parties
                                                          are making
                                                          declarations
                                                          to one
                                                          another.

                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          
If


                                                          you adopt that
                                                          language (or
                                                          keep the
                                                          original
                                                          language),
                                                          then yes, I’d
                                                          consider this
                                                          closed.

                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          
                                                           


                                                          -- Mike

                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          

                                                          

                                                          
From: Justin



                                                          Richer [mailto:jricher@mitre.org] 

                                                          Sent: Monday,


                                                          April 15, 2013
                                                          9:57 AM

                                                          To: Mike


                                                          Jones

                                                          Cc: Tim


                                                          Bray; oauth@ietf.org

                                                          Subject: Re:


                                                          [OAUTH-WG]
                                                          Registration:
                                                          Scope Values

                                                          

                                                          

                                                          

                                                          

                                                          
 

                                                          

                                                          
I absolutely do not want to delete this
                                                          feature, as
                                                          (having
                                                          implemented
                                                          it) I think
                                                          it's very
                                                          useful. This
                                                          is a very
                                                          established
                                                          pattern in
                                                          manual
                                                          registration:
                                                          I know of
                                                          many, many
                                                          OAuth2 servers
                                                          and clients
                                                          that are set
                                                          up where the
                                                          client must
                                                          pre-register a
                                                          set of scopes. 

                                                          

                                                          I don't like
                                                          the language
                                                          of "the client
                                                          is declaring"
                                                          because it's
                                                          too one-sided.
                                                          The client
                                                          might not have
                                                          declared
                                                          anything, and
                                                          it might be
                                                          the server
                                                          that's
                                                          declaring
                                                          something to
                                                          the client.
                                                          Deleting the
                                                          "is declaring"
                                                          bit removes
                                                          that
                                                          unintended
                                                          restriction of
                                                          the language
                                                          while keeping
                                                          the original
                                                          meaning
                                                          intact. I
                                                          actually
                                                          thought that I
                                                          had fixed that
                                                          before the
                                                          last draft
                                                          went in but
                                                          apparently I
                                                          missed this
                                                          one.

                                                          

                                                          I will work on
                                                          clarifying the
                                                          intent of the
                                                          whole metadata
                                                          set in its
                                                          introductory
                                                          paragraph(s)
                                                          so that it's
                                                          clear that all
                                                          of these
                                                          fields are
                                                          used in both
                                                          of these
                                                          situations:

                                                          

                                                           1) The client
                                                          declaring to
                                                          the server its
                                                          desire to use
                                                          a particular
                                                          value

                                                           2) The server
                                                          declaring to
                                                          the client
                                                          that it has
                                                          been
                                                          registered
                                                          with a
                                                          particular
                                                          value

                                                          

                                                          This should
                                                          hopefully
                                                          clear up the
                                                          issue in the
                                                          editor's note
                                                          that I
                                                          currently have
                                                          at the top of
                                                          that section
                                                          right now,
                                                          too.

                                                          

                                                          Mike, since
                                                          you were the
                                                          one who
                                                          originally
                                                          brought up the
                                                          issue, and
                                                          you're fine
                                                          with the
                                                          existing text,
                                                          can I take
                                                          this as closed
                                                          now? Assuming
                                                          that you agree
                                                          with deleting
                                                          "is declaring"
                                                          for reasons
                                                          stated above,
                                                          I'm fine with
                                                          leaving
                                                          everything
                                                          else as is and
                                                          staying quiet
                                                          on what the
                                                          server has to
                                                          do with the
                                                          scopes.

                                                          

                                                           -- Justin

                                                          

                                                          

                                                          
On

                                                          04/15/2013
                                                          12:44 PM, Mike
                                                          Jones wrote:

                                                          

                                                          

                                                          

                                                          

                                                          
I
                                                          think that the
                                                          existing
                                                          wording is
                                                          superior to
                                                          the proposed
                                                          changed
                                                          wording.  The
                                                          existing
                                                          wording is:

                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          
  
                                                          scope

                                                          

                                                          

                                                          
     

                                                          OPTIONAL. 
                                                          Space
                                                          separated list
                                                          of scope
                                                          values (as
                                                          described in

                                                          

                                                          

                                                          
     

                                                          OAuth 2.0 Section 3.3
                                                          [RFC6749])
                                                          that the
                                                          client is
                                                          declaring that

                                                          

                                                          

                                                          
     

                                                          it may use
                                                          when
                                                          requesting
                                                          access
                                                          tokens.  If
                                                          omitted, an

                                                          

                                                          

                                                          
     

                                                          Authorization
                                                          Server MAY
                                                          register a
                                                          Client with a
                                                          default set of

                                                          

                                                          

                                                          
     

                                                          scopes.

                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          
For


                                                          instance, the
                                                          current
                                                          “client is
                                                          declaring”
                                                          wording will
                                                          always be
                                                          correct,
                                                          whereas as the
                                                          change to
                                                          “client can
                                                          use” wording
                                                          implies a
                                                          restriction on
                                                          client
                                                          behavior that
                                                          is not always
                                                          applicable. 
                                                          The “client is
                                                          declaring”
                                                          wording was
                                                          specific and
                                                          purposefully
                                                          chosen, and I
                                                          think should
                                                          be retained. 
                                                          In particular,
                                                          we can’t do
                                                          anything that
                                                          implies that
                                                          only the
                                                          registered
                                                          scopes values
                                                          can be used. 
                                                          At the OAuth
                                                          spec level,
                                                          this is a hint
                                                          as to possible
                                                          future client
                                                          behavior – not
                                                          a restriction
                                                          on future
                                                          client
                                                          behavior.

                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          
Also,


                                                          for the
                                                          reasons that
                                                          Tim stated,
                                                          I’m strongly
                                                          against any
                                                          “matching” or
                                                          “regex”
                                                          language in
                                                          the spec
                                                          pertaining to
                                                          scopes – as
                                                          it’s not
                                                          actionable.

                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          
So


                                                          I’d propose
                                                          that we leave
                                                          the existing
                                                          scope wording
                                                          in place. 
                                                          Alternatively,
                                                          I’d also be
                                                          fine with
                                                          deleting this
                                                          feature
                                                          entirely, as I
                                                          don’t think
                                                          it’s useful in
                                                          the general
                                                          case.

                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          
                                                           


                                                          -- Mike

                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          

                                                          

                                                          
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]On
                                                          Behalf Of Justin


                                                          Richer

                                                          Sent: Monday,


                                                          April 15, 2013
                                                          8:05 AM

                                                          To: Tim


                                                          Bray; oauth@ietf.org

                                                          Subject: Re:


                                                          [OAUTH-WG]
                                                          Registration:
                                                          Scope Values

                                                          

                                                          

                                                          

                                                          

                                                          
 

                                                          

                                                          
On 04/15/2013 10:52 AM, Tim Bray wrote:

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
I’d

                                                          use the
                                                          existing
                                                          wording; it’s
                                                          perfectly
                                                          clear.
                                                           Failing that,
                                                          if there’s
                                                          strong demand
                                                          for
                                                          registration
                                                          of structured
                                                          scopes, bless
                                                          the use of
                                                          regexes,
                                                          either PCREs
                                                          or some
                                                          careful
                                                          subset.

                                                          

                                                          

                                                          


                                                          Thanks for the
                                                          feedback -- Of
                                                          these two
                                                          choices, I'd
                                                          rather leave
                                                          it as-is. 

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          

                                                          

                                                          
However,


                                                          I’d subtract
                                                          the sentence
                                                          “If omitted,
                                                          an
                                                          Authorization
                                                          Server MAY
                                                          register a
                                                          Client with a
                                                          default set of
                                                           scopes.”  It
                                                          adds no value;
                                                          if the client
                                                          doesn’t
                                                          declare
                                                          scopes, the
                                                          client doesn’t
                                                          declare
                                                          scopes, that’s
                                                          all.  -T

                                                          

                                                          

                                                          

                                                          


                                                          Remember, all
                                                          of these
                                                          fields aren't
                                                          just for the
                                                          client
                                                          *request*,
                                                          they're also
                                                          for the
                                                          server's
                                                          *response* to
                                                          either a POST,
                                                          PUT, or GET
                                                          request. (I
                                                          didn't realize
                                                          it, but
                                                          perhaps the
                                                          wording as
                                                          stated right
                                                          now doesn't
                                                          make that
                                                          clear -- I
                                                          need to fix
                                                          that.) The
                                                          value that it
                                                          adds is if the
                                                          client doesn't
                                                          ask for any
                                                          particular
                                                          scopes, the
                                                          server can
                                                          still assign
                                                          it scopes and
                                                          the client can
                                                          do something
                                                          smart with
                                                          that. Dumb
                                                          clients are
                                                          allowed to
                                                          ignore it if
                                                          it doesn't
                                                          mean anything
                                                          to them. 

                                                          

                                                          This is how
                                                          our server
                                                          implementation
                                                          actually works
                                                          right now. If
                                                          the client
                                                          doesn't ask
                                                          for anything
                                                          specific at
                                                          registration,
                                                          the server
                                                          hands it a bag
                                                          of "default"
                                                          scopes. Same
                                                          thing happens
                                                          at auth time
                                                          -- if the
                                                          client doesn't
                                                          ask for any
                                                          particular
                                                          scopes, the
                                                          server hands
                                                          it all of its
                                                          registered
                                                          scopes as a
                                                          default.
                                                          Granted, on
                                                          our server,
                                                          scopes are
                                                          just simple
                                                          strings right
                                                          now, so they
                                                          get compared
                                                          at the auth
                                                          endpoint with
                                                          an exact
                                                          string-match
                                                          metric and
                                                          set-based
                                                          logic. 

                                                          

                                                           -- Justin

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          
On

                                                          Mon, Apr 15,
                                                          2013 at 7:35
                                                          AM, Justin
                                                          Richer <jricher@mitre.org> wrote:

                                                          

                                                          

                                                          

                                                          
What


                                                          would you
                                                          suggest for
                                                          wording here,
                                                          then? Keeping
                                                          in mind that
                                                          we cannot (and
                                                          don't want to)
                                                          prohibit
                                                          expression-based
                                                          scopes. 

                                                          

                                                           -- Justin

                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          
On


                                                          04/15/2013
                                                          10:33 AM, Tim
                                                          Bray wrote:

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
No,


                                                          I mean it’s
                                                          not
                                                          interoperable
                                                          at the
                                                          software-developer
                                                          level.  I
                                                          can’t register
                                                          scopes at
                                                          authorization
                                                          time with any
                                                          predictable
                                                          effect that I
                                                          can write code
                                                          to support,
                                                          either client
                                                          or server
                                                          side, without
                                                          out-of-line
                                                          non-interoperable
                                                          knowledge
                                                          about the
                                                          behavior of
                                                          the server.  

                                                          

                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          

                                                          

                                                          
I
                                                          guess I’m just
                                                          not used to
                                                          OAuth’s
                                                          culture of
                                                          having no
                                                          expectation
                                                          that things
                                                          will be
                                                          specified
                                                          tightly enough
                                                          that I can
                                                          write code to
                                                          implement as
                                                          specified.  -T

                                                          

                                                          

                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          
On


                                                          Mon, Apr 15,
                                                          2013 at 7:15
                                                          AM, Justin
                                                          Richer <jricher@mitre.org> wrote:

                                                          

                                                          

                                                          

                                                          
Scopes


                                                          aren't meant
                                                          to be
                                                          interoperable
                                                          between
                                                          services since
                                                          they're
                                                          necessarily
                                                          API-specific.
                                                          The only
                                                          interoperable
                                                          bit is that
                                                          there's *some*
                                                          place to put
                                                          the values and
                                                          that it's
                                                          expressed as a
                                                          bag of
                                                          space-separated
                                                          strings. How
                                                          those strings
                                                          get
                                                          interpreted
                                                          and enforced
                                                          (which is
                                                          really what's
                                                          at stake here)
                                                          is up to the
                                                          AS and PR (or
                                                          a higher-level
                                                          protocol like
                                                          UMA).

                                                          

                                                           -- Justin

                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          
On


                                                          04/15/2013
                                                          10:13 AM, Tim
                                                          Bray wrote:

                                                          

                                                          

                                                          

                                                          
This, as
                                                          written, has
                                                          zero
                                                          interoperability. 
                                                          I think this
                                                          feature can
                                                          really only be
                                                          made useful in
                                                          the case where
                                                          scopes are
                                                          fixed strings.

                                                          
-T

                                                          

                                                          

                                                          
On


                                                          Apr 15, 2013
                                                          6:54 AM,
                                                          "Justin
                                                          Richer" <jricher@mitre.org> wrote:

                                                          

                                                          

                                                          
You are correct that the idea behind the
                                                          "scope"
                                                          parameter at
                                                          registration
                                                          is a
                                                          constraint on
                                                          authorization-time


                                                          scopes that
                                                          are made
                                                          available.
                                                          It's both a
                                                          means for the
                                                          client to
                                                          request a set
                                                          of valid
                                                          scopes and for
                                                          the server to
                                                          provision (and
                                                          echo back to
                                                          the client) a
                                                          set of valid
                                                          scopes.

                                                          

                                                          I *really*
                                                          don't want to
                                                          try to define
                                                          a matching
                                                          language for
                                                          scope
                                                          expressions.
                                                          For that to
                                                          work, all
                                                          servers would
                                                          need to be
                                                          able to
                                                          process the
                                                          regular
                                                          expressions
                                                          for all
                                                          clients, even
                                                          if the servers
                                                          themselves
                                                          only support
                                                          simple-string
                                                          scope values.
                                                          Any regular
                                                          expression
                                                          syntax we pick
                                                          here is
                                                          guaranteed to
                                                          be
                                                          incompatible
                                                          with
                                                          something, and
                                                          I think the
                                                          complexity
                                                          doesn't buy
                                                          much. Also, I
                                                          think you
                                                          suddenly have
                                                          a potential
                                                          security issue
                                                          if you have a
                                                          bad regex in
                                                          place on
                                                          either end. 

                                                          

                                                          As it stands
                                                          today, the
                                                          server can
                                                          interpret the
                                                          incoming
                                                          registration
                                                          scopes and
                                                          enforce them
                                                          however it
                                                          wants to. The
                                                          real trick
                                                          comes not from
                                                          assigning the
                                                          values to a
                                                          particular
                                                          client but to
                                                          enforcing
                                                          them, and I
                                                          think that's
                                                          always going
                                                          to be
                                                          service-specific.
                                                          We're just not
                                                          as clear on
                                                          that as we
                                                          could be.

                                                          

                                                          After looking
                                                          over
                                                          everyone's
                                                          comments so
                                                          far, I'd like
                                                          to propose the
                                                          following text
                                                          for that
                                                          section:

                                                          

                                                          

                                                          

                                                          
   scope

                                                          
      OPTIONAL.  Space separated list of scope values (as described in

                                                          
      OAuth 2.0 Section 3.3 [RFC6749]) that the client can use when 

                                                          
      requesting access tokens.  As scope values are service-specific, 

                                                          
      the Authorization Server MAY define its own matching rules when

                                                          
      determining if a scope value used during an authorization request

                                                          
      is valid according to the scope values assigned during 

                                                          
      registration. Possible matching rules include wildcard patterns,

                                                          
      regular expressions, or exactly matching the string. If omitted, 

                                                          
      an Authorization Server MAY register a Client with a default 

                                                          
      set of scopes.

                                                          


                                                          Comments?
                                                          Improvements?

                                                          

                                                           -- Justin

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
On


                                                          04/14/2013
                                                          08:23 PM,
                                                          Manger, James
                                                          H wrote:

                                                          

                                                          

                                                          

                                                          
Presumably at app registration time any scope specification is really a constraint on the scope values that can be requested in an authorization flow.

                                                          
 

                                                          
So ideally registration should accept rules for matching scopes, as opposed to actual scope values.

                                                          
 

                                                          
You can try to use scope values as their own matching rules. That is fine for a small set of "static" scopes. It starts to fail when there are a large number of scopes, or scopes that can include parameters (resource paths? email addresses?). You can try to patch those failures by allowing services to define service-specific special "wildcard" scope values that can only be used during registration (eg "read:*").

                                                          
 

                                                          
Alternatively, replace 'scope' in registration with 'scope_regex' that holds a regular expression that all scope values in an authorization flow must match.

                                                          
 

                                                          
--

                                                          
James Manger

                                                          
_______________________________________________

                                                          
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

                                        

                                      

                                      
 

                                    

                                  

                                

                                

                              

                            

                          

                        

                      

                      

                    

                  

                

                

              

            

          

          

        

      

    

    

  


--------------000005010103000006040608--

From internet-drafts@ietf.org  Fri Apr 19 07:02:25 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 242C821F9402; Fri, 19 Apr 2013 07:02:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -96.317
X-Spam-Level: 
X-Spam-Status: No, score=-96.317 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HAS_XAIMC=2.696, HELO_MISMATCH_COM=0.553, RCVD_IN_XBL=3.033, 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 VUN2NUTi0Dtp; Fri, 19 Apr 2013 07:02:24 -0700 (PDT)
Received: from jlonline.com (pip46.ptt.js.cn [61.155.13.222]) by ietfa.amsl.com (Postfix) with SMTP id 83B9121F8E51; Fri, 19 Apr 2013 07:02:22 -0700 (PDT)
Received: from jlonline.com([10.100.0.22]) by ptt.js.cn(AIMC 4.0.0.0) with SMTP id jm851715dad; Fri, 19 Apr 2013 22:08:10 +0800
Received: from mail.ietf.org([12.22.58.30]) by ptt.js.cn(AIMC 4.0.0.0) with SMTP id jm9e516ccd23; Tue, 16 Apr 2013 04:08:02 +0800
Received: from mail.ietf.org([12.22.58.30]) by ptt.js.cn(AIMC 4.0.0.0) with SMTP id AISP action; Tue, 16 Apr 2013 04:08:02 +0800
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C02721F93CA; Mon, 15 Apr 2013 13:01:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1366056092; bh=cwqvWp67BwT+j+rFVbK/CZT9ml82VMJFYs0nGvhiYgg=; h=MIME-Version:From:To:Subject:Message-ID:Date:Cc:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=IzQN70+ywpKobd0a9WbQv4Q5a5ZJXC6v5+ARxr9UQt/d/4Eqb+60dYuUn0B5A7BA0 ITmereBW2kk4oVVzf1dg6GKmRqaY+5hcP8KS46Mle1ZnZuBtXPFA+tqgB63oJ1m2zU XfzFzjl+SF1aC+qvcseOIpBMDoZr/RsVySEmnVIo=
X-Original-To: i-d-announce@ietfa.amsl.com
Delivered-To: i-d-announce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F36B021F93C4; Mon, 15 Apr 2013 13:01:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id btiIKzSxIztn; Mon, 15 Apr 2013 13:01:13 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DF8BF21F93C6; Mon, 15 Apr 2013 13:01:12 -0700 (PDT)
MIME-Version: 1.0
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.43.p4
Message-ID: <20130415200112.7840.9595.idtracker@ietfa.amsl.com>
Date: Mon, 15 Apr 2013 13:01:12 -0700
X-BeenThere: i-d-announce@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: i-d-announce-bounces@ietf.org
Errors-To: i-d-announce-bounces@ietf.org
X-AIMC-AUTH: (null)
X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org
X-AIMC-Msg-ID: VqEhp14B
X-AIMC-AUTH: (null)
X-AIMC-MAILFROM: internet-drafts@ietf.org
Cc: oauth@ietf.org
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-07.txt
X-BeenThere: oauth@ietf.org
Reply-To: internet-drafts@ietf.org
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Apr 2013 14:02:25 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Web Authorization Protocol Working Group of the IETF.

	Title           : Token Revocation
	Author(s)       : Torsten Lodderstedt
                          Stefanie Dronia
                          Marius Scurtescu
	Filename        : draft-ietf-oauth-revocation-07.txt
	Pages           : 10
	Date            : 2013-04-15

Abstract:
   This document proposes an additional endpoint for OAuth authorization
   servers, which allows clients to notify the authorization server that
   a previously obtained refresh or access token is no longer needed.
   This allows the authorization server to cleanup security credentials.
   A revocation request will invalidate the actual token and, if
   applicable, other tokens based on the same authorization grant.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-revocation

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-oauth-revocation-07

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-revocation-07


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

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

From internet-drafts@ietf.org  Tue Apr 23 17:36:16 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B2B621F93C8; Tue, 23 Apr 2013 17:36:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.496
X-Spam-Level: 
X-Spam-Status: No, score=-102.496 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQ3YGw8Mc3n3; Tue, 23 Apr 2013 17:36:15 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 91FE621F8E79; Tue, 23 Apr 2013 17:36:15 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.44.p4
Message-ID: <20130424003615.16521.11744.idtracker@ietfa.amsl.com>
Date: Tue, 23 Apr 2013 17:36:15 -0700
Cc: oauth@ietf.org
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-json-web-token-07.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Apr 2013 00:36:16 -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 Group =
of the IETF.

	Title           : JSON Web Token (JWT)
	Author(s)       : Michael B. Jones
                          John Bradley
                          Nat Sakimura
	Filename        : draft-ietf-oauth-json-web-token-07.txt
	Pages           : 25
	Date            : 2013-04-23

Abstract:
   JSON Web Token (JWT) is a compact URL-safe means of representing
   claims to be transferred between two parties.  The claims in a JWT
   are encoded as a JavaScript Object Notation (JSON) object that is
   used as the payload of a JSON Web Signature (JWS) structure or as the
   plaintext of a JSON Web Encryption (JWE) structure, enabling the
   claims to be digitally signed or MACed and/or encrypted.

   The suggested pronunciation of JWT is the same as the English word
   "jot".


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-07

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-json-web-token-07


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


From Michael.Jones@microsoft.com  Tue Apr 23 19:12:55 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82BCD21F96C8; Tue, 23 Apr 2013 19:12:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.034
X-Spam-Level: 
X-Spam-Status: No, score=-2.034 tagged_above=-999 required=5 tests=[AWL=-0.036, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=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 rp5iHiEXuukB; Tue, 23 Apr 2013 19:12:54 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0204.outbound.protection.outlook.com [207.46.163.204]) by ietfa.amsl.com (Postfix) with ESMTP id 2147A21F96C6; Tue, 23 Apr 2013 19:12:54 -0700 (PDT)
Received: from BN1AFFO11FD011.protection.gbl (10.58.52.202) by BN1AFFO11HUB015.protection.gbl (10.58.52.125) with Microsoft SMTP Server (TLS) id 15.0.675.0; Wed, 24 Apr 2013 02:07:38 +0000
Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.37) by BN1AFFO11FD011.mail.protection.outlook.com (10.58.52.71) with Microsoft SMTP Server (TLS) id 15.0.675.0 via Frontend Transport; Wed, 24 Apr 2013 02:07:38 +0000
Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.245]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0318.003; Wed, 24 Apr 2013 02:06:47 +0000
From: Mike Jones 
To: "jose@ietf.org" , "oauth@ietf.org" 
Thread-Topic: JOSE and JWT specs incorporating decisions from IETF 86
Thread-Index: Ac5AkF8GEZkzSCsYTlWpjIlvBF/zSA==
Date: Wed, 24 Apr 2013 02:06:47 +0000
Message-ID: <4E1F6AAD24975D4BA5B1680429673943676AA515@TK5EX14MBXC284.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.32]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943676AA515TK5EX14MBXC284r_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(199002)(512954001)(16406001)(20776003)(4396001)(81542001)(47976001)(54316002)(47736001)(46102001)(66066001)(76482001)(50986001)(53806001)(564824004)(47446002)(74662001)(56816002)(54356001)(15202345002)(31966008)(63696002)(77982001)(59766001)(33656001)(6806003)(69226001)(74502001)(71186001)(79102001)(56776001)(51856001)(49866001)(80022001)(81342001)(16236675002)(65816001)(55846006)(6606295001); DIR:OUT; SFP:; SCL:1; SRVR:BN1AFFO11HUB015; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 0826B2F01B
Subject: [OAUTH-WG] JOSE and JWT specs incorporating decisions from IETF 86
X-BeenThere: oauth@ietf.org
X-Mailman-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, 24 Apr 2013 02:12:55 -0000

--_000_4E1F6AAD24975D4BA5B1680429673943676AA515TK5EX14MBXC284r_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

New versions of the JSON Object Signing and Encryption (JOSE) specification=
s JSON Web Signature (JWS), JSON Web Encryption (JWE), JSON Web Key (JWK), =
and JSON Web Algorithms (JWA) and the JSON Web Token (JWT) specification ha=
ve been released that incorporate the working group decisions made during a=
nd since IETF 86.

The primary new features in these working group drafts are:

*        adding support for private and symmetric keys to JWK and JWA,

*        adding support for JSON Serializations to JWS and JWE,

*        replacing the custom JOSE CBC+HMAC algorithms with ones compatible=
 with those proposed in draft-mcgrew-aead-aes-cbc-hmac-sha2,

*        defining that the default action for header parameters and claims =
that are not understood is to ignore them, while providing a way to designa=
te that some extension header parameters must be understood.

More details on the changes made can be found in the Document History entri=
es.

The specifications are available at:

*        http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-09

*        http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-09

*        http://tools.ietf.org/html/draft-ietf-jose-json-web-key-09

*        http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-09

*        http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-07

HTML formatted versions are also available at:

*        http://self-issued.info/docs/draft-ietf-jose-json-web-signature-09=
.html

*        http://self-issued.info/docs/draft-ietf-jose-json-web-encryption-0=
9.html

*        http://self-issued.info/docs/draft-ietf-jose-json-web-key-09.html

*        http://self-issued.info/docs/draft-ietf-jose-json-web-algorithms-0=
9.html

*        http://self-issued.info/docs/draft-ietf-oauth-json-web-token-07.ht=
ml

                                                            -- Mike

P.S.  This notice has also been posted at http://self-issued.info/?p=3D1008=
.


--_000_4E1F6AAD24975D4BA5B1680429673943676AA515TK5EX14MBXC284r_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Ne=
w versions of the JSON Object Signing and Encryption (JOSE) specifications =
JSON Web Signature (JWS), JSON Web Encryption (JWE), JSON Web Key (JWK), an=
d JSON Web Algorithms (JWA) and the
 JSON Web Token (JWT) specification have been released that incorporate the=
 working group decisions made during and since
IETF 86.


 


Th=
e primary new features in these working group drafts are:



·       
adding support for private and symmetric key=
s to JWK and JWA,


·       
adding support for JSON Serializations to JW=
S and JWE,


·       
replacing the custom JOSE CBC+HMAC algor=
ithms with ones compatible with those proposed in
draft-mcgrew-aead-aes-cbc-hmac-sha2,



·       
defining that the default action for header =
parameters and claims that are not understood is to ignore them, while prov=
iding a way to designate that some extension header parameters must be unde=
rstood.


 


Mo=
re details on the changes made can be found in the Document History entries=
.


 


Th=
e specifications are available at:



·       
http://tools.ietf.org/html/draft-ietf-jose=
-json-web-signature-09


·       
http://tools.ietf.org/html/draft-ietf-jos=
e-json-web-encryption-09


·       
http://tools.ietf.org/html/draft-ietf-jose-json-=
web-key-09


·       
http://tools.ietf.org/html/draft-ietf-jos=
e-json-web-algorithms-09



·       
http://tools.ietf.org/html/draft-ietf-oauth-j=
son-web-token-07


 


HT=
ML formatted versions are also available at:



·       
http://self-issued.info/docs/draft-=
ietf-jose-json-web-signature-09.html


·       
http://self-issued.info/docs/draft=
-ietf-jose-json-web-encryption-09.html


·       
http://self-issued.info/docs/draft-ietf-j=
ose-json-web-key-09.html


·       
http://self-issued.info/docs/draft=
-ietf-jose-json-web-algorithms-09.html



·       
http://self-issued.info/docs/draft-iet=
f-oauth-json-web-token-07.html


 


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


 


P.=
S.  This notice has also been posted at
http://self-issued.info/?p=3D=
1008.


 






--_000_4E1F6AAD24975D4BA5B1680429673943676AA515TK5EX14MBXC284r_--

From markdoristyne@hotmail.com  Wed Apr 24 10:47:36 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D7B521F8E7E for ; Wed, 24 Apr 2013 10:47:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jCfRO9kF8oKX for ; Wed, 24 Apr 2013 10:47:35 -0700 (PDT)
Received: from snt0-omc1-s14.snt0.hotmail.com (snt0-omc1-s14.snt0.hotmail.com [65.55.90.25]) by ietfa.amsl.com (Postfix) with ESMTP id 33BEA21F85BF for ; Wed, 24 Apr 2013 10:47:35 -0700 (PDT)
Received: from SNT144-DS15 ([65.55.90.9]) by snt0-omc1-s14.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 24 Apr 2013 10:47:34 -0700
X-TMN: [BteNJk1WWsRrsWhsdTqakGsztBzwA/Uz]
X-Originating-Email: [markdoristyne@hotmail.com]
Message-ID: 
From: "dorismark tyne" 
To: 
References: 
Date: Wed, 24 Apr 2013 13:47:27 -0400
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_022A_01CE40F2.42E54CB0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: MSN 9
X-MimeOLE: Produced By MSN MimeOLE V10.50.0008.2100
In-Reply-To: 
Seal-Send-Time: Wed, 24 Apr 2013 13:47:28 -0400
X-OriginalArrivalTime: 24 Apr 2013 17:47:34.0843 (UTC) FILETIME=[CD8320B0:01CE4113]
Subject: Re: [OAUTH-WG] Contents of OAuth digest
X-BeenThere: oauth@ietf.org
X-Mailman-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, 24 Apr 2013 17:47:36 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_022A_01CE40F2.42E54CB0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Please explain what oauth is all about. Thanks
dmtyne
  ----- Original Message -----=20
  From: oauth-request@ietf.org=20
  To: oauth@ietf.org=20
  Sent: Friday, April 19, 2013 3:00 PM
  Subject: OAuth Digest, Vol 54, Issue 43


  If you have received this digest without all the individual message
  attachments you will need to update your digest options in your list
  subscription.  To do so, go to=20

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

  Click the 'Unsubscribe or edit options' button, log in, and set "Get
  MIME or Plain Text Digests?" to MIME.  You can set this option
  globally for all the list digests you receive at this point.



  Send OAuth mailing list submissions to
  oauth@ietf.org

  To subscribe or unsubscribe via the World Wide Web, visit
  =
https://www.ietf.org/mailman/listinfo/oauth
  or, via email, send a message with subject or body 'help' to
  oauth-request@ietf.org

  You can reach the person managing the list at
  oauth-owner@ietf.org

  When replying, please edit your Subject line so it is more specific
  than "Re: Contents of OAuth digest..."

------=_NextPart_000_022A_01CE40F2.42E54CB0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Please explain what oauth is all about. Thanks


dmtyne


  
----- Original Message ----- 

  
From: oauth-request@ietf.org =


  
  
Sent: Friday, April 19, 2013 =
3:00=20
PM

  
Subject: OAuth Digest, Vol 54, =
Issue=20
  43

  

If you have received this digest without all the =
individual=20
  message
attachments you will need to update your digest options in =
your=20
  list
subscription.  To do so, go to 

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

Click=20
  the 'Unsubscribe or edit options' button, log in, and set "Get
MIME =
or=20
  Plain Text Digests?" to MIME.  You can set this =
option
globally for=20
  all the list digests you receive at this point.



Send =
OAuth=20
  mailing list submissions to
oauth@ietf.org

To subscribe =
or=20
  unsubscribe via the World Wide Web, visit
https://www.ietf.org=
/mailman/listinfo/oauth
or,=20
  via email, send a message with subject or body 'help' to
oauth-request@ietf.org

=
You can=20
  reach the person managing the list at
oauth-owner@ietf.org

When=
=20
  replying, please edit your Subject line so it is more specific
than =
"Re:=20
  Contents of OAuth digest..."


------=_NextPart_000_022A_01CE40F2.42E54CB0--


From nichole.richardson.27@facebook.com  Wed Apr 24 13:10:49 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3C5E21F914C for ; Wed, 24 Apr 2013 13:10:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.664
X-Spam-Level: 
X-Spam-Status: No, score=-101.664 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_34=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 2SVEwx-iXqxR for ; Wed, 24 Apr 2013 13:10:48 -0700 (PDT)
Received: from smtpout.mx.facebook.com (smtpout001.ash3.facebook.com [69.171.244.64]) by ietfa.amsl.com (Postfix) with ESMTP id F094421F910E for ; Wed, 24 Apr 2013 13:10:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=facebook.com; s=s1024-2010-q3; c=relaxed/simple; q=dns/txt; i=@facebook.com; t=1366834235; h=From:Subject:X-:Date:To:MIME-Version:Content-Type; bh=J0OjXeCuM4N5uzx09l2E0YwE7/3gnaSz5UE9hh25U0w=; b=CnT8e0xFzkKIwvRmRtGSk4XhQZp8SLvaKlLVnRYZ/xExnALoUqr/HHXyDl9qGsHN rsA7siOk+TYz/n4cPUxJUVrl0eQfsqxnLy8AJNo/APce+lSTR6OfEG4LkTPXys5F /GBaDbrhnJQysISL+u67fLNOjdFrJbePLAB9BW0SHPI=;
Received: from [10.148.86.69] ([10.148.86.69:46605] helo=www.facebook.com) by 10.148.128.29 (envelope-from ) (ecelerity 2.2.2.45 r(34222M)) with ESMTP id EC/32-03944-B3C38715; Wed, 24 Apr 2013 13:10:35 -0700
Date: Wed, 24 Apr 2013 13:10:35 -0700
From: Nichole Richardson 
To: Mike Jones , "oauth@ietf.org" , "jose@ietf.org" 
Message-ID: <6ba33a1284334c0497f0d4e3cb2cf2ad-0@mail.projektitan.com>
In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943676AA515@TK5EX14MBXC284.redmond.corp.microsoft.com>
References: , <4E1F6AAD24975D4BA5B1680429673943676AA515@TK5EX14MBXC284.redmond.corp.microsoft.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_13410_1224209555.1366834235476"
Subject: Re: [OAUTH-WG] JOSE and JWT specs incorporating decisions from IETF 86
X-BeenThere: oauth@ietf.org
X-Mailman-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, 24 Apr 2013 20:10:49 -0000

------=_Part_13410_1224209555.1366834235476
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Auto-generated message: Nichole Richardson has left this conversation and will
no longer see your messages

On April 23, 2013 7:06:47 PM PDT, Mike Jones wrote:
> New versions of the JSON Object Signing and Encryption (JOSE) specifications JSON Web Signature (JWS), JSON Web Encryption (JWE), JSON Web Key (JWK), and JSON Web Algorithms (JWA) and the JSON Web Token (JWT) specification have been released that incorporate the working group decisions made during and since IETF 86.
> 
> The primary new features in these working group drafts are:
> 
> *        adding support for private and symmetric keys to JWK and JWA,
> 
> *        adding support for JSON Serializations to JWS and JWE,
> 
> *        replacing the custom JOSE CBC+HMAC algorithms with ones compatible with those proposed in draft-mcgrew-aead-aes-cbc-hmac-sha2,
> 
> *        defining that the default action for header parameters and claims that are not understood is to ignore them, while providing a way to designate that some extension header parameters must be understood.
> 
> More details on the changes made can be found in the Document History entries.
> 
> The specifications are available at:
> 
> *        http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-09
> 
> *        http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-09
> 
> *        http://tools.ietf.org/html/draft-ietf-jose-json-web-key-09
> 
> *        http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-09
> 
> *        http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-07
> 
> HTML formatted versions are also available at:
> 
> *        http://self-issued.info/docs/draft-ietf-jose-json-web-signature-09..html
> 
> *        http://self-issued.info/docs/draft-ietf-jose-json-web-encryption-09.html
> 
> *        http://self-issued.info/docs/draft-ietf-jose-json-web-key-09.html
> 
> *        http://self-issued.info/docs/draft-ietf-jose-json-web-algorithms-09.html
> 
> *        http://self-issued.info/docs/draft-ietf-oauth-json-web-token-07.html
> 
>                                                             -- Mike
> 
> P.S.  This notice has also been posted at http://self-issued.info/?p=1008..
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

------=_Part_13410_1224209555.1366834235476
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

Auto-generated message: Nichole Richardson has left this conversation and will no longer see your messages

On April 23, 2013 7:06:47 PM PDT, Mike Jones wrote:

New versions of the JSON Object Signing and Encryption (JOSE) specifications JSON Web Signature (JWS), JSON Web Encryption (JWE), JSON Web Key (JWK), and JSON Web Algorithms (JWA) and the
 JSON Web Token (JWT) specification have been released that incorporate the working group decisions made during and since
IETF 86.
 
The primary new features in these working group drafts are:
·       
adding support for private and symmetric keys to JWK and JWA,
·       
adding support for JSON Serializations to JWS and JWE,
·       
replacing the custom JOSE CBC+HMAC algorithms with ones compatible with those proposed in
draft-mcgrew-aead-aes-cbc-hmac-sha2,
·       
defining that the default action for header parameters and claims that are not understood is to ignore them, while providing a way to designate that some extension header parameters must be understood.
 
More details on the changes made can be found in the Document History entries..
 
The specifications are available at:
·       
http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-09
·       
http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-09
·       
http://tools.ietf.org/html/draft-ietf-jose-json-web-key-09
·       
http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-09
·       
http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-07
 
HTML formatted versions are also available at:
·       
http://self-issued.info/docs/draft-ietf-jose-json-web-signature-09.html
·       
http://self-issued.info/docs/draft-ietf-jose-json-web-encryption-09.html
·       
http://self-issued.info/docs/draft-ietf-jose-json-web-key-09.html
·       
http://self-issued.info/docs/draft-ietf-jose-json-web-algorithms-09.html
·       
http://self-issued.info/docs/draft-ietf-oauth-json-web-token-07.html
 
                                                            -- Mike
 
P.S.  This notice has also been posted at
http://self-issued.info/?p=1008.
 


------=_Part_13410_1224209555.1366834235476--

From phil.hunt@oracle.com  Wed Apr 24 13:17:23 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21C6A21F8F18 for ; Wed, 24 Apr 2013 13:17:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sd2p6WaCd9aP for ; Wed, 24 Apr 2013 13:17:22 -0700 (PDT)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 644CA21F8E79 for ; Wed, 24 Apr 2013 13:17:22 -0700 (PDT)
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r3OKHK84018960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 24 Apr 2013 20:17:21 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r3OKHK97021313 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 24 Apr 2013 20:17:21 GMT
Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r3OKHKfg025974 for ; Wed, 24 Apr 2013 20:17:20 GMT
Received: from [192.168.1.14] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 24 Apr 2013 13:17:20 -0700
From: Phil Hunt 
Content-Type: multipart/alternative; boundary="Apple-Mail=_30A9981E-8ABA-4B1C-BB19-41ACDEF631D4"
Date: Wed, 24 Apr 2013 13:17:18 -0700
Message-Id: <53250C00-9D1C-4E81-9AD6-E12241B875D9@oracle.com>
To: "oauth@ietf.org WG" 
Mime-Version: 1.0 (Apple Message framework v1283)
X-Mailer: Apple Mail (2.1283)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Subject: [OAUTH-WG] Questions on draft-ietf-oauth-dyn-reg-09 - token_endpoint_auth_method
X-BeenThere: oauth@ietf.org
X-Mailman-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, 24 Apr 2013 20:17:23 -0000

--Apple-Mail=_30A9981E-8ABA-4B1C-BB19-41ACDEF631D4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

For parameters to token_endpoint_auth_method, the spec has defined =
"client_secret_jwt" and "private_key_jwt". Shouldn't there be similar =
options of SAML?

Shouldn't there be an extension point for other methods?

Phil

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






--Apple-Mail=_30A9981E-8ABA-4B1C-BB19-41ACDEF631D4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii



Shouldn't there be an =
extension point for other methods?



Phil

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








=

--Apple-Mail=_30A9981E-8ABA-4B1C-BB19-41ACDEF631D4--

From ve7jtb@ve7jtb.com  Wed Apr 24 13:57:27 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA1B21F8A6B for ; Wed, 24 Apr 2013 13:57:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.167
X-Spam-Level: 
X-Spam-Status: No, score=-2.167 tagged_above=-999 required=5 tests=[AWL=0.431,  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 9G5v2Prb+C9f for ; Wed, 24 Apr 2013 13:57:26 -0700 (PDT)
Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 32DC221F8A48 for ; Wed, 24 Apr 2013 13:57:25 -0700 (PDT)
Received: by mail-ie0-f176.google.com with SMTP id x14so2673732ief.7 for ; Wed, 24 Apr 2013 13:57:25 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=4vWJxQR9W/U/YwdyY6Lm1y8z16gUyD18S1sGKhP1NqI=; b=CLXskNM3+UNU2D7qNGZuADQK9pXn9ZMSnkrZBClrF5XqdnR3zWv4NJzWtC2Vtwp9nL OCcQ6hlIcnMc07yi79+2TymtVARaFhTheLA24UBG8kJbhRLu2qlwMHZxKDZWaO8aPAvA ewB6hLZP9iB4497eVbwkF7d1y1WVcIw1uM494kGaAZFQ1Q+7cCM2b/NGh1FFeYTcGNdc wxKeC6jTcC5TJ6bQHibuiP5+mxpAlaaknamhY3lFgEoPqVAozAaNfm78lkY1GrcLXo5j TRRlhqxUMy8vCVoQYVvtBUcp6GCHrXRJknPja3F9nEAT1XA5mcSP2gGcFNLGk1yaJ7AW oeIA==
X-Received: by 10.50.110.106 with SMTP id hz10mr16470913igb.24.1366837045625;  Wed, 24 Apr 2013 13:57:25 -0700 (PDT)
Received: from [192.168.1.39] (190-20-16-122.baf.movistar.cl. [190.20.16.122]) by mx.google.com with ESMTPSA id dy5sm7759014igc.1.2013.04.24.13.57.22 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Apr 2013 13:57:24 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_5412B490-0DB4-4A39-950B-E78938241C21"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: John Bradley 
In-Reply-To: <53250C00-9D1C-4E81-9AD6-E12241B875D9@oracle.com>
Date: Wed, 24 Apr 2013 17:57:10 -0300
Message-Id: <60512D2A-3E89-4809-B1E1-BA55143B58CD@ve7jtb.com>
References: <53250C00-9D1C-4E81-9AD6-E12241B875D9@oracle.com>
To: Phil Hunt 
X-Mailer: Apple Mail (2.1503)
X-Gm-Message-State: ALoCoQlWqaND6mhrc40AmZGv3viNnCISvcqTw9YmBwm3d1bfMqbl0V5jx5aiCblpnrObKhhQVA1A
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] Questions on draft-ietf-oauth-dyn-reg-09 - token_endpoint_auth_method
X-BeenThere: oauth@ietf.org
X-Mailman-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, 24 Apr 2013 20:57:27 -0000

--Apple-Mail=_5412B490-0DB4-4A39-950B-E78938241C21
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_97795A32-DD19-4F5A-82FF-6974AC668BD4"


--Apple-Mail=_97795A32-DD19-4F5A-82FF-6974AC668BD4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Yes there should be corresponding client_secret_SAML and =
private_key_SAML.  Those parameters were taken from Connect which is =
more JWT focused so I didn't put in the SAML options for token endpoint =
authentication, though they would be valid.

There is probably some profiling that needs to be done for the =
client_secret_SAML to define how the client secret is used to hmac the =
SAML assertion.   You might want to just skip that and only do =
private_key_SAML which is more strait-forward with a asymmetric =
signature.

John B.

On 2013-04-24, at 5:17 PM, Phil Hunt  wrote:

> For parameters to token_endpoint_auth_method, the spec has defined =
"client_secret_jwt" and "private_key_jwt". Shouldn't there be similar =
options of SAML?
>=20
> Shouldn't there be an extension point for other methods?
>=20
> Phil
>=20
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>=20
>=20
>=20
>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_97795A32-DD19-4F5A-82FF-6974AC668BD4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

Yes =
there should be corresponding client_secret_SAML and private_key_SAML. =
 Those parameters were taken from Connect which is more JWT focused =
so I didn't put in the SAML options for token endpoint authentication, =
though they would be valid.

There is probably some =
profiling that needs to be done for the client_secret_SAML to =
define how the client secret is used to hmac the SAML assertion.   =
You might want to just skip that and only do private_key_SAML which =
is more strait-forward with a asymmetric =
signature.

John B.

On =
2013-04-24, at 5:17 PM, Phil Hunt <phil.hunt@oracle.com> =
wrote:

For parameters =
to 

Shouldn't there be an =
extension point for other methods?



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








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

=

--Apple-Mail=_97795A32-DD19-4F5A-82FF-6974AC668BD4--

--Apple-Mail=_5412B490-0DB4-4A39-950B-E78938241C21
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g
AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q
YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5
AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v
eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA
FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM
L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI
p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz
Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5
QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV
HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z
dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j
b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp
bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t
IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t
cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP
MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg
d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u
cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny
bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw
AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF
BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j
cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB
AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC
cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ
4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh
JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC
fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT
AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0
aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt
ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3
DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNDI0MjA1NzEwWjAjBgkqhkiG9w0BCQQxFgQU9B/FHGmI
3mntW1q8x/2LA4hISrQwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK
Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu
dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAGpO/cd+o4uT/NYLi2ZPzetL4qH3gbo72obZBPHMd
7CgMQMyIpkrQNl1Wcu9EMotftP2K7BL43Hg4CV9nmYzAqJS9/XqIVjyTq65Wwo2UvAZqJqWRgLhi
Xvr8Pi6hVMGnZhK938am6RrLju9VQKFsY5biBonTeLuU93aMUK//fHSaB/6lwhKCqUdYPTX1ZETO
2U+WH/4NSC1mUH2nKOEuUyYArbUHVems56F5fWp9EsOos12C08vYGUOdarmdHNw6Fm+om114PH6x
HE84uMHZztMnGib3gD5NDgmZgTRnH/2HAAhfdcCXGeSkfadYFWa4/A1QbbcG7dZHcmWUT7im5gAA
AAAAAA==

--Apple-Mail=_5412B490-0DB4-4A39-950B-E78938241C21--

From jricher@mitre.org  Wed Apr 24 14:07:45 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF0B921F9199 for ; Wed, 24 Apr 2013 14:07:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QgZpVgqsINFd for ; Wed, 24 Apr 2013 14:07:44 -0700 (PDT)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 24CE121F9164 for ; Wed, 24 Apr 2013 14:07:44 -0700 (PDT)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 972701F0397; Wed, 24 Apr 2013 17:07:43 -0400 (EDT)
Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 7B99F2650016; Wed, 24 Apr 2013 17:07:43 -0400 (EDT)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.342.3; Wed, 24 Apr 2013 17:07:42 -0400
Message-ID: <5178498B.3050406@mitre.org>
Date: Wed, 24 Apr 2013 17:07:23 -0400
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130329 Thunderbird/17.0.5
MIME-Version: 1.0
To: Phil Hunt 
References: <53250C00-9D1C-4E81-9AD6-E12241B875D9@oracle.com>
In-Reply-To: <53250C00-9D1C-4E81-9AD6-E12241B875D9@oracle.com>
Content-Type: multipart/alternative; boundary="------------010506070403020209010106"
X-Originating-IP: [129.83.31.58]
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] Questions on draft-ietf-oauth-dyn-reg-09 - token_endpoint_auth_method
X-BeenThere: oauth@ietf.org
X-Mailman-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, 24 Apr 2013 21:07:45 -0000

--------------010506070403020209010106
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

Seems reasonable to me, can you suggest language to add in the 
capability? Would it require an IANA registry? Right now there isn't any 
other place that enumerates the various methods that a client can use to 
access the token endpoint.

  -- Justin

On 04/24/2013 04:17 PM, Phil Hunt wrote:
> For parameters to token_endpoint_auth_method, the spec has defined 
> "client_secret_jwt" and "private_key_jwt". Shouldn't there be similar 
> options of SAML?
>
> Shouldn't there be an extension point for other methods?
>
> Phil
>
> @independentid
> www.independentid.com 
> phil.hunt@oracle.com 
>
>
>
>
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--------------010506070403020209010106
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit


  
    
  
  
    Seems reasonable to me, can you suggest language to add in the
    capability? Would it require an IANA registry? Right now there isn't
    any other place that enumerates the various methods that a client
    can use to access the token endpoint.

    

     -- Justin

    

    
On 04/24/2013 04:17 PM, Phil Hunt
      wrote:

    

    

      
      
For parameters to token_endpoint_auth_method, the spec has
        defined "client_secret_jwt" and "private_key_jwt". Shouldn't
        there be similar options of SAML?

      


      

      
Shouldn't there be an extension point for other methods?

      


      

      
      

      

      

      

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


    

    

  


--------------010506070403020209010106--

From phil.hunt@oracle.com  Wed Apr 24 15:30:31 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C681321F8D2B for ; Wed, 24 Apr 2013 15:30:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B271wfnXWPuW for ; Wed, 24 Apr 2013 15:30:31 -0700 (PDT)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 062AF21F8BE8 for ; Wed, 24 Apr 2013 15:30:30 -0700 (PDT)
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r3OMUSQx024181 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 24 Apr 2013 22:30:29 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r3OMUStO020804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 24 Apr 2013 22:30:28 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r3OMUSGZ011791; Wed, 24 Apr 2013 22:30:28 GMT
Received: from [192.168.1.14] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 24 Apr 2013 15:30:28 -0700
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: multipart/alternative; boundary="Apple-Mail=_BA70492B-D89F-4D25-871D-822D275E7BB5"
From: Phil Hunt 
In-Reply-To: <5178498B.3050406@mitre.org>
Date: Wed, 24 Apr 2013 15:30:26 -0700
Message-Id: <0E96125F-CFEC-4157-8A1E-3CFCA1C4D79F@oracle.com>
References: <53250C00-9D1C-4E81-9AD6-E12241B875D9@oracle.com> <5178498B.3050406@mitre.org>
To: Justin Richer 
X-Mailer: Apple Mail (2.1283)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] Questions on draft-ietf-oauth-dyn-reg-09 - token_endpoint_auth_method
X-BeenThere: oauth@ietf.org
X-Mailman-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, 24 Apr 2013 22:30:31 -0000

--Apple-Mail=_BA70492B-D89F-4D25-871D-822D275E7BB5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Hmmm=85 what was the objective or use case for having the client being =
able to choose in the first place?

It seems to me that the AS will make a decision based on many factors. =
As you say, there isn't any other place that enumerates the various =
[authn] methods a client can use to access the token endpoint.  So, why =
do it?

Phil

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





On 2013-04-24, at 2:07 PM, Justin Richer wrote:

> Seems reasonable to me, can you suggest language to add in the =
capability? Would it require an IANA registry? Right now there isn't any =
other place that enumerates the various methods that a client can use to =
access the token endpoint.
>=20
>  -- Justin
>=20
> On 04/24/2013 04:17 PM, Phil Hunt wrote:
>> For parameters to token_endpoint_auth_method, the spec has defined =
"client_secret_jwt" and "private_key_jwt". Shouldn't there be similar =
options of SAML?
>>=20
>> Shouldn't there be an extension point for other methods?
>>=20
>> Phil
>>=20
>> @independentid
>> www.independentid.com
>> phil.hunt@oracle.com
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=20


--Apple-Mail=_BA70492B-D89F-4D25-871D-822D275E7BB5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

Hmmm=85=
 what was the objective or use case for having the client being able to =
choose in the first place?

It seems to me that the AS =
will make a decision based on many factors. As you say, there isn't any =
other place that enumerates the various [authn] methods a client can use =
to access the token endpoint.  So, why do =
it?



Phil

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








On 2013-04-24, at 2:07 PM, Justin Richer wrote:


 =20
    
 =20
  

    Seems reasonable to me, can you suggest language to add in the
    capability? Would it require an IANA registry? Right now there isn't
    any other place that enumerates the various methods that a client
    can use to access the token endpoint.

    

     -- Justin

    

    
On 04/24/2013 04:17 PM, Phil Hunt
      wrote:

    

    

      
      
For parameters to token_endpoint_auth_method, the spec has
        defined "client_secret_jwt" and "private_key_jwt". Shouldn't
        there be similar options of SAML?

      


      

      
Shouldn't there be an extension point for other =
methods?

      


      

      
      

      

      

      

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


    

    

  




=

--Apple-Mail=_BA70492B-D89F-4D25-871D-822D275E7BB5--

From ve7jtb@ve7jtb.com  Wed Apr 24 15:41:39 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B567E21F8D61 for ; Wed, 24 Apr 2013 15:41:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.253
X-Spam-Level: 
X-Spam-Status: No, score=-2.253 tagged_above=-999 required=5 tests=[AWL=0.345,  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 XsDGKY8YDZSh for ; Wed, 24 Apr 2013 15:41:38 -0700 (PDT)
Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id B97FF21F8D29 for ; Wed, 24 Apr 2013 15:41:38 -0700 (PDT)
Received: by mail-ie0-f172.google.com with SMTP id c12so2810036ieb.17 for ; Wed, 24 Apr 2013 15:41:38 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=uK+Uav1dSTdZy6H4a2eQQnddSgBq85y+vZEQvvlx2tA=; b=KXj+Fn4k9c5RUt36OWE72JvecnLKOq4s1G4wLa9H4jnT7QY3Qr4mCV6EDn4wuokQLN 2iyNfLfSL4OIwAFilxVUD7mmQtEKzH2Oi1P/Isx91ZzavaPxzuevcALBm9b8RGWYeN0+ qghm+ZaV7IPoiEDf2IEUk+I1Bwf0oa71VhOKcA6jUvBg6T99W47XfDTW3cJ2mZBeW1DW avVYJ88/Z+ar6ijloNaaZPUMCS2ezxc5lwutnBbZUrxd75Xwei8OxazSxJYKi0HtmBKi WGhXWzuJb9hCpHP+d5W6DWIUzGzCOvhHsb5j8sTuZ8dxJuda6xg25tzxjcOfKQ6ill4y Xvag==
X-Received: by 10.50.42.165 with SMTP id p5mr29858897igl.75.1366843298041; Wed, 24 Apr 2013 15:41:38 -0700 (PDT)
Received: from [192.168.1.39] (190-20-16-122.baf.movistar.cl. [190.20.16.122]) by mx.google.com with ESMTPSA id fl5sm8282096igb.9.2013.04.24.15.41.33 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Apr 2013 15:41:36 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_4AC35BE1-10FE-4D47-8665-51D1B5E1B5E7"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: John Bradley 
In-Reply-To: <0E96125F-CFEC-4157-8A1E-3CFCA1C4D79F@oracle.com>
Date: Wed, 24 Apr 2013 19:41:26 -0300
Message-Id: <0C683171-29F6-47EA-A611-AB6394207353@ve7jtb.com>
References: <53250C00-9D1C-4E81-9AD6-E12241B875D9@oracle.com> <5178498B.3050406@mitre.org> <0E96125F-CFEC-4157-8A1E-3CFCA1C4D79F@oracle.com>
To: Phil Hunt 
X-Mailer: Apple Mail (2.1503)
X-Gm-Message-State: ALoCoQnVSu5Ud4PpvRNPGHnio1tVQU3vLR97HEAHoUTyTKxsBZbv4W6lkwGn3ac5aXX/+98ZDGg9
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] Questions on draft-ietf-oauth-dyn-reg-09 - token_endpoint_auth_method
X-BeenThere: oauth@ietf.org
X-Mailman-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, 24 Apr 2013 22:41:39 -0000

--Apple-Mail=_4AC35BE1-10FE-4D47-8665-51D1B5E1B5E7
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_A946B120-38C7-4449-8A7E-E272578F1F30"


--Apple-Mail=_A946B120-38C7-4449-8A7E-E272578F1F30
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

In Connect the AS may support a number of token endpoint authentication =
methods.   The reason to allow a client to register using a particular =
one is to prevent downgrade attacks.

If the client wants to always use an asymmetric signature you don't want =
to allow attackers to use weaker methods like http basic.

So a server may support any number of methods, but it is reasonable for =
a client to specify which one it is going to use.   In a closed system =
that may not be that useful but in a open system where the AS has a =
looser relationship to the client it is important.

John B.

On 2013-04-24, at 7:30 PM, Phil Hunt  wrote:

> Hmmm=85 what was the objective or use case for having the client being =
able to choose in the first place?
>=20
> It seems to me that the AS will make a decision based on many factors. =
As you say, there isn't any other place that enumerates the various =
[authn] methods a client can use to access the token endpoint.  So, why =
do it?
>=20
> Phil
>=20
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>=20
>=20
>=20
>=20
>=20
> On 2013-04-24, at 2:07 PM, Justin Richer wrote:
>=20
>> Seems reasonable to me, can you suggest language to add in the =
capability? Would it require an IANA registry? Right now there isn't any =
other place that enumerates the various methods that a client can use to =
access the token endpoint.
>>=20
>>  -- Justin
>>=20
>> On 04/24/2013 04:17 PM, Phil Hunt wrote:
>>> For parameters to token_endpoint_auth_method, the spec has defined =
"client_secret_jwt" and "private_key_jwt". Shouldn't there be similar =
options of SAML?
>>>=20
>>> Shouldn't there be an extension point for other methods?
>>>=20
>>> Phil
>>>=20
>>> @independentid
>>> www.independentid.com
>>> phil.hunt@oracle.com
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_A946B120-38C7-4449-8A7E-E272578F1F30
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

In =
Connect the AS may support a number of token endpoint authentication =
methods.   The reason to allow a client to register using a =
particular one is to prevent downgrade attacks.

If =
the client wants to always use an asymmetric signature you don't want to =
allow attackers to use weaker methods like http =
basic.

So a server may support any number of =
methods, but it is reasonable for a client to specify which one it is =
going to use.   In a closed system that may not be that useful but =
in a open system where the AS has a looser relationship to the client it =
is important.

John =
B.

On 2013-04-24, at 7:30 PM, Phil =
Hunt <phil.hunt@oracle.com> =
wrote:

Hmmm=85 what was the =
objective or use case for having the client being able to choose in the =
first place?

It seems to me that the AS will make a =
decision based on many factors. As you say, there isn't any other place =
that enumerates the various [authn] methods a client can use to access =
the token endpoint.  So, why do it?



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








On 2013-04-24, at 2:07 PM, Justin Richer wrote:


 =20
    
 =20
  

    Seems reasonable to me, can you suggest language to add in the
    capability? Would it require an IANA registry? Right now there isn't
    any other place that enumerates the various methods that a client
    can use to access the token endpoint.

    

     -- Justin

    

    
On 04/24/2013 04:17 PM, Phil Hunt
      wrote:

    

    

      
      
For parameters to token_endpoint_auth_method, the spec has
        defined "client_secret_jwt" and "private_key_jwt". Shouldn't
        there be similar options of SAML?

      


      

      
Shouldn't there be an extension point for other =
methods?

      


      

      
      

      

      

      

      
_______________________________________________
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=_A946B120-38C7-4449-8A7E-E272578F1F30--

--Apple-Mail=_4AC35BE1-10FE-4D47-8665-51D1B5E1B5E7
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g
AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q
YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5
AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v
eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA
FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM
L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI
p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz
Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5
QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV
HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z
dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j
b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp
bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t
IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t
cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP
MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg
d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u
cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny
bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw
AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF
BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j
cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB
AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC
cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ
4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh
JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC
fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT
AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0
aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt
ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3
DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNDI0MjI0MTI2WjAjBgkqhkiG9w0BCQQxFgQUCxk6JqSH
BHVaai/pMV5+YwvoA78wgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK
Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu
dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAVi2dN4WFz68OkXTbezIt5c98Ju99eddBEca3zIg5
ZxxBmVkClKMVRPBLyZzL10hrUfoUoioydcxe94T6uzeIP1hRFq1BmPXVR8LNa7Mk6FuK3eV9l+TB
wjosCr3zrjZPoWNTC0IYk2sRDkkujpQ9CQNl5PEm3Rw/uZOFapMFd7lFG/zp8lGej58SSYgYrl9y
6E/ZFGOdhD/xLI/73Gck4u87yxgkTVGVR6jYNxeb8rgFJEHKRAEmiZhdY2A4IiUmCfT1Zr3z7Rtt
vcM535bdtNFIFPdlVqswuCGA2RyNiyPwsc508gUccvpnLH4w/PLHMo22GMz95ti74bDnoKX7TwAA
AAAAAA==

--Apple-Mail=_4AC35BE1-10FE-4D47-8665-51D1B5E1B5E7--

From phil.hunt@oracle.com  Wed Apr 24 15:55:20 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D398A21F91CA for ; Wed, 24 Apr 2013 15:55:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 RP1-qNIbtvlO for ; Wed, 24 Apr 2013 15:55:19 -0700 (PDT)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 2680D21F91A2 for ; Wed, 24 Apr 2013 15:55:19 -0700 (PDT)
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r3OMtGpn011693 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 24 Apr 2013 22:55:17 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r3OMtFcf014838 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 24 Apr 2013 22:55:16 GMT
Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r3OMtFjK001772; Wed, 24 Apr 2013 22:55:15 GMT
Received: from dhcp-rmdc-twvpn-2-vpnpool-10-159-72-135.vpn.oracle.com (/10.159.72.135) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 24 Apr 2013 15:55:15 -0700
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: multipart/alternative; boundary="Apple-Mail=_610A970C-397C-409A-AAD4-430E0D34053C"
From: Phil Hunt 
In-Reply-To: <0C683171-29F6-47EA-A611-AB6394207353@ve7jtb.com>
Date: Wed, 24 Apr 2013 15:55:13 -0700
Message-Id: 
References: <53250C00-9D1C-4E81-9AD6-E12241B875D9@oracle.com> <5178498B.3050406@mitre.org> <0E96125F-CFEC-4157-8A1E-3CFCA1C4D79F@oracle.com> <0C683171-29F6-47EA-A611-AB6394207353@ve7jtb.com>
To: John Bradley 
X-Mailer: Apple Mail (2.1283)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] Questions on draft-ietf-oauth-dyn-reg-09 - token_endpoint_auth_method
X-BeenThere: oauth@ietf.org
X-Mailman-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, 24 Apr 2013 22:55:21 -0000

--Apple-Mail=_610A970C-397C-409A-AAD4-430E0D34053C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Right and if the client wants a method not supported then what?

Why can't the client offer up a list of methods it is able to support, =
say in order of preference?

The text appears to indicate only one value may be passed.

Given the way it is written. It seems better to just have the server say =
the client must do authn method X in the response.

Phil

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





On 2013-04-24, at 3:41 PM, John Bradley wrote:

> In Connect the AS may support a number of token endpoint =
authentication methods.   The reason to allow a client to register using =
a particular one is to prevent downgrade attacks.
>=20
> If the client wants to always use an asymmetric signature you don't =
want to allow attackers to use weaker methods like http basic.
>=20
> So a server may support any number of methods, but it is reasonable =
for a client to specify which one it is going to use.   In a closed =
system that may not be that useful but in a open system where the AS has =
a looser relationship to the client it is important.
>=20
> John B.
>=20
> On 2013-04-24, at 7:30 PM, Phil Hunt  wrote:
>=20
>> Hmmm=85 what was the objective or use case for having the client =
being able to choose in the first place?
>>=20
>> It seems to me that the AS will make a decision based on many =
factors. As you say, there isn't any other place that enumerates the =
various [authn] methods a client can use to access the token endpoint.  =
So, why do it?
>>=20
>> Phil
>>=20
>> @independentid
>> www.independentid.com
>> phil.hunt@oracle.com
>>=20
>>=20
>>=20
>>=20
>>=20
>> On 2013-04-24, at 2:07 PM, Justin Richer wrote:
>>=20
>>> Seems reasonable to me, can you suggest language to add in the =
capability? Would it require an IANA registry? Right now there isn't any =
other place that enumerates the various methods that a client can use to =
access the token endpoint.
>>>=20
>>>  -- Justin
>>>=20
>>> On 04/24/2013 04:17 PM, Phil Hunt wrote:
>>>> For parameters to token_endpoint_auth_method, the spec has defined =
"client_secret_jwt" and "private_key_jwt". Shouldn't there be similar =
options of SAML?
>>>>=20
>>>> Shouldn't there be an extension point for other methods?
>>>>=20
>>>> Phil
>>>>=20
>>>> @independentid
>>>> www.independentid.com
>>>> phil.hunt@oracle.com
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>=20
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=20


--Apple-Mail=_610A970C-397C-409A-AAD4-430E0D34053C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

Right =
and if the client wants a method not supported then =
what?

Why can't the client offer up a list of methods =
it is able to support, say in order of =
preference?

The text appears to indicate only =
one value may be passed.

Given the way it is =
written. It seems better to just have the server say the client must do =
authn method X in the response.



Phil

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








On 2013-04-24, at 3:41 PM, John Bradley wrote:

In =
Connect the AS may support a number of token endpoint authentication =
methods.   The reason to allow a client to register using a =
particular one is to prevent downgrade attacks.

If =
the client wants to always use an asymmetric signature you don't want to =
allow attackers to use weaker methods like http =
basic.

So a server may support any number of =
methods, but it is reasonable for a client to specify which one it is =
going to use.   In a closed system that may not be that useful but =
in a open system where the AS has a looser relationship to the client it =
is important.

John =
B.

On 2013-04-24, at 7:30 PM, Phil =
Hunt <phil.hunt@oracle.com> =
wrote:

Hmmm=85 what was the =
objective or use case for having the client being able to choose in the =
first place?

It seems to me that the AS will make a =
decision based on many factors. As you say, there isn't any other place =
that enumerates the various [authn] methods a client can use to access =
the token endpoint.  So, why do it?



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








On 2013-04-24, at 2:07 PM, Justin Richer wrote:


 =20
    
 =20
  

    Seems reasonable to me, can you suggest language to add in the
    capability? Would it require an IANA registry? Right now there isn't
    any other place that enumerates the various methods that a client
    can use to access the token endpoint.

    

     -- Justin

    

    
On 04/24/2013 04:17 PM, Phil Hunt
      wrote:

    

    

      
      
For parameters to token_endpoint_auth_method, the spec has
        defined "client_secret_jwt" and "private_key_jwt". Shouldn't
        there be similar options of SAML?

      


      

      
Shouldn't there be an extension point for other =
methods?

      


      

      
      

      

      

      

      
_______________________________________________
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=_610A970C-397C-409A-AAD4-430E0D34053C--

From Michael.Jones@microsoft.com  Wed Apr 24 16:18:49 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F37321F8D05 for ; Wed, 24 Apr 2013 16:18:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.329
X-Spam-Level: 
X-Spam-Status: No, score=-2.329 tagged_above=-999 required=5 tests=[AWL=0.269,  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 SqVJNNHdxrzB for ; Wed, 24 Apr 2013 16:18:46 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0238.outbound.protection.outlook.com [207.46.163.238]) by ietfa.amsl.com (Postfix) with ESMTP id A227A21F8CEC for ; Wed, 24 Apr 2013 16:18:46 -0700 (PDT)
Received: from BN1BFFO11FD008.protection.gbl (10.58.52.203) by BN1BFFO11HUB028.protection.gbl (10.58.53.138) with Microsoft SMTP Server (TLS) id 15.0.675.0; Wed, 24 Apr 2013 23:18:43 +0000
Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.37) by BN1BFFO11FD008.mail.protection.outlook.com (10.58.53.68) with Microsoft SMTP Server (TLS) id 15.0.675.0 via Frontend Transport; Wed, 24 Apr 2013 23:18:43 +0000
Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.245]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.02.0318.003; Wed, 24 Apr 2013 23:17:27 +0000
From: Mike Jones 
To: Phil Hunt , John Bradley 
Thread-Topic: [OAUTH-WG] Questions on draft-ietf-oauth-dyn-reg-09 - token_endpoint_auth_method
Thread-Index: AQHOQSjKTtcnHLxg9UuYbMHq01zj8Zjl3RyAgAAXNACAAAMTAIAAA9qAgAAE7RA=
Date: Wed, 24 Apr 2013 23:17:26 +0000
Message-ID: <4E1F6AAD24975D4BA5B1680429673943676ABC64@TK5EX14MBXC284.redmond.corp.microsoft.com>
References: <53250C00-9D1C-4E81-9AD6-E12241B875D9@oracle.com> <5178498B.3050406@mitre.org> <0E96125F-CFEC-4157-8A1E-3CFCA1C4D79F@oracle.com> <0C683171-29F6-47EA-A611-AB6394207353@ve7jtb.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: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943676ABC64TK5EX14MBXC284r_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(377424002)(479174001)(24454001)(60454002)(199002)(189002)(66066001)(51856001)(71186001)(56776001)(79102001)(65816001)(16236675002)(55846006)(6806003)(47446002)(16601075002)(31966008)(53806001)(20776003)(15202345002)(74502001)(56816002)(564824004)(54356001)(49866001)(81342001)(81542001)(63696002)(74366001)(33656001)(16406001)(59766001)(54316002)(15974865001)(4396001)(76482001)(80022001)(69226001)(47736001)(74662001)(77982001)(50986001)(512954001)(47976001)(46102001); DIR:OUT; SFP:; SCL:1; SRVR:BN1BFFO11HUB028; H:TK5EX14HUBC106.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 0826B2F01B
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] Questions on draft-ietf-oauth-dyn-reg-09 -	token_endpoint_auth_method
X-BeenThere: oauth@ietf.org
X-Mailman-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, 24 Apr 2013 23:18:49 -0000

--_000_4E1F6AAD24975D4BA5B1680429673943676ABC64TK5EX14MBXC284r_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

What you're missing is the part of the OpenID Connect flow where the client=
 first discovers the capabilities that the Server advertises.  In this case=
, it uses this discovery parameter:

token_endpoint_auth_signing_alg_values_supported
OPTIONAL. JSON array containing a list of the JWS signing algorithms (alg v=
alues) supported by the Token Endpoint for the private_key_jwt and client_s=
ecret_jwt methods to encode the JWT. Servers SHOULD support RS256.

So in this use case, the client already knows what algorithms it can choose=
 from, and it makes the choice.

Other OAuth flows could do the same thing, given either dynamic discovery o=
r a published algorithm list by the server.

                                                            -- Mike

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of P=
hil Hunt
Sent: Wednesday, April 24, 2013 3:55 PM
To: John Bradley
Cc: oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Questions on draft-ietf-oauth-dyn-reg-09 - token_en=
dpoint_auth_method

Right and if the client wants a method not supported then what?

Why can't the client offer up a list of methods it is able to support, say =
in order of preference?

The text appears to indicate only one value may be passed.

Given the way it is written. It seems better to just have the server say th=
e client must do authn method X in the response.

Phil

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




On 2013-04-24, at 3:41 PM, John Bradley wrote:


In Connect the AS may support a number of token endpoint authentication met=
hods.   The reason to allow a client to register using a particular one is =
to prevent downgrade attacks.

If the client wants to always use an asymmetric signature you don't want to=
 allow attackers to use weaker methods like http basic.

So a server may support any number of methods, but it is reasonable for a c=
lient to specify which one it is going to use.   In a closed system that ma=
y not be that useful but in a open system where the AS has a looser relatio=
nship to the client it is important.

John B.

On 2013-04-24, at 7:30 PM, Phil Hunt > wrote:


Hmmm... what was the objective or use case for having the client being able=
 to choose in the first place?

It seems to me that the AS will make a decision based on many factors. As y=
ou say, there isn't any other place that enumerates the various [authn] met=
hods a client can use to access the token endpoint.  So, why do it?

Phil

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




On 2013-04-24, at 2:07 PM, Justin Richer wrote:


Seems reasonable to me, can you suggest language to add in the capability? =
Would it require an IANA registry? Right now there isn't any other place th=
at enumerates the various methods that a client can use to access the token=
 endpoint.

 -- Justin
On 04/24/2013 04:17 PM, Phil Hunt wrote:
For parameters to token_endpoint_auth_method, the spec has defined "client_=
secret_jwt" and "private_key_jwt". Shouldn't there be similar options of SA=
ML?

Shouldn't there be an extension point for other methods?

Phil

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







_______________________________________________

OAuth mailing list

OAuth@ietf.org

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


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



--_000_4E1F6AAD24975D4BA5B1680429673943676ABC64TK5EX14MBXC284r_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











What you’re missing=
 is the part of the OpenID Connect flow where the client first discovers th=
e capabilities that the Server advertises.  In this case, it uses
 this discovery parameter:


 <=
/p>

token_endpoint_auth_signing_alg_values_supported


OPTIONAL. JSON array containing a list of the JWS signing alg=
orithms (alg=

 values) supported by the Token Endpoint for the private_key_jwt and
client_secret_jwt methods to encode the JWT. =
Servers SHOULD support
RS256.



 <=
/p>

So in this use case, the =
client already knows what algorithms it can choose from, and it makes the c=
hoice.


 <=
/p>

Other OAuth flows could d=
o the same thing, given either dynamic discovery or a published algorithm l=
ist by the server.


 <=
/p>

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


 <=
/p>





From: oauth-bo=
unces@ietf.org [mailto:oauth-bounces@ietf.org]
On Behalf Of Phil Hunt

Sent: Wednesday, April 24, 2013 3:55 PM

To: John Bradley

Cc: oauth@ietf.org WG

Subject: Re: [OAUTH-WG] Questions on draft-ietf-oauth-dyn-reg-09 - t=
oken_endpoint_auth_method






 


Right and if the client wants a method not supported=
 then what?




 






Why can't the client offer up a list of methods it i=
s able to support, say in order of preference?






 






The text appears to indicate only one value may be p=
assed.






 






Given the way it is written. It seems better to just=
 have the server say the client must do authn method X in the response.






 
















Phil






 





@independentid<=
/span>











phil.hunt@oracle.com=





 <=
/p>












 






On 2013-04-24, at 3:41 PM, John Bradley wrote:<=
/o:p>













In Connect the AS may support a number of token endp=
oint authentication methods.   The reason to allow a client to registe=
r using a particular one is to prevent downgrade attacks.




 






If the client wants to always use an asymmetric sign=
ature you don't want to allow attackers to use weaker methods like http bas=
ic.






 






So a server may support any number of methods, but i=
t is reasonable for a client to specify which one it is going to use.  =
; In a closed system that may not be that useful but in a open system where=
 the AS has a looser relationship to the
 client it is important.






 






John B.






 










On 2013-04-24, at 7:30 PM, Phil Hunt <phil.hunt@oracle.com> wrote:=














Hmmm… what was the objective or use case for h=
aving the client being able to choose in the first place?




 






It seems to me that the AS will make a decision base=
d on many factors. As you say, there isn't any other place that enumerates =
the various [authn] methods a client can use to access the token endpoint. =
 So, why do it?






 











 













 






On 2013-04-24, at 2:07 PM, Justin Richer wrote:=














Seems reasonable to m=
e, can you suggest language to add in the capability? Would it require an I=
ANA registry? Right now there isn't any other place that enumerates the var=
ious methods that a client can use to
 access the token endpoint.



 -- Justin




On 04/24/2013 04:17 PM, Phil Hunt wrote:<=
/p>







For parameters to tok=
en_endpoint_auth_method,
the spec has defined "client_secret_jwt" and "=
private_key_jwt". Shouldn't there be similar options of SAML?






 






Shouldn't there be an extension point for other meth=
ods?






 









 




 















_______________________________________________


OAuth mailing list


OAuth@ietf.org


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




 






 






_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.or=
g/mailman/listinfo/oauth




 








 








--_000_4E1F6AAD24975D4BA5B1680429673943676ABC64TK5EX14MBXC284r_--

From ve7jtb@ve7jtb.com  Wed Apr 24 16:23:26 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A9D421F8D03 for ; Wed, 24 Apr 2013 16:23:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.352
X-Spam-Level: 
X-Spam-Status: No, score=-2.352 tagged_above=-999 required=5 tests=[AWL=0.246,  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 HbWLiS+KHTST for ; Wed, 24 Apr 2013 16:23:22 -0700 (PDT)
Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 955EE21F8CEC for ; Wed, 24 Apr 2013 16:23:22 -0700 (PDT)
Received: by mail-ie0-f169.google.com with SMTP id ar20so2921840iec.28 for ; Wed, 24 Apr 2013 16:23:22 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=M3TgL6uNsenxSS0VYj7yfeX/tZM8ZtZeiqy8Ru6LdHE=; b=FqU4P2b1c/Y3t/05/ELz+H9WSFpYCDVi08KQ2qtJQNKvcfbXsmNNSOdSj2haKv502/ mLvPnyxvzhFOorVrPrLHgz/kW6JGZGBnbTw84vq9naUoJQTIzLMVJXROM6/Fp81gvDk+ jv+UBMG4Q4zsFhWVgZApXDCgn9IiurOjSNTxoj2bk1YUF+3UgteBVcWv05F8kIivyLo7 MPgKYhpdm074L1xlc6pEwHExD6u6pFy7Pf5NXkcJ21v8GPfeJTj+eBzAd9ml0RDd91O3 AQXv/libx6AdzyyoIY7sKrSHn5fuI8ACYNCrSyYYigjW/cmRdj915PmcgCqBaMtiBuuI dPrA==
X-Received: by 10.50.92.42 with SMTP id cj10mr9190670igb.60.1366845801952; Wed, 24 Apr 2013 16:23:21 -0700 (PDT)
Received: from [192.168.1.39] (190-20-16-122.baf.movistar.cl. [190.20.16.122]) by mx.google.com with ESMTPSA id in10sm30931487igc.1.2013.04.24.16.23.18 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Apr 2013 16:23:20 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_59AF0F5A-0A27-4325-8169-E7D697CAA3E2"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: John Bradley 
In-Reply-To: 
Date: Wed, 24 Apr 2013 20:23:04 -0300
Message-Id: <629E4582-16C4-4554-9591-39E6801FA0A8@ve7jtb.com>
References: <53250C00-9D1C-4E81-9AD6-E12241B875D9@oracle.com> <5178498B.3050406@mitre.org> <0E96125F-CFEC-4157-8A1E-3CFCA1C4D79F@oracle.com> <0C683171-29F6-47EA-A611-AB6394207353@ve7jtb.com> 
To: Phil Hunt 
X-Mailer: Apple Mail (2.1503)
X-Gm-Message-State: ALoCoQmdXxOWFNO+KPUksUtGkpqw7sB0cOmiAGXmpsRcSJbczfiOKGssmP+0EbttnAclWMFqGMz3
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] Questions on draft-ietf-oauth-dyn-reg-09 - token_endpoint_auth_method
X-BeenThere: oauth@ietf.org
X-Mailman-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, 24 Apr 2013 23:23:26 -0000

--Apple-Mail=_59AF0F5A-0A27-4325-8169-E7D697CAA3E2
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_CFE58024-70CF-4278-9137-332A4BDFDB1E"


--Apple-Mail=_CFE58024-70CF-4278-9137-332A4BDFDB1E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

In Connect there is a AS discovery before registration.  =20

The general pattern is the RP discovers the capabilities of the AS =
authentication methods and algorithms supported by the AS. =20
The client then picks the best options for it and registers them.

It would in theory work of the client knowing nothing about the AS =
pushed it's capabilities at the AS as you are suggesting and let the AS =
pick.

My general feeling is that discovery with the client picking the options =
works best.

In many cases the client doesn't need to register parameters as they can =
be selected at run time once it knows what a server supports. =20
The token endpoint authentication method was a bit of a special case =
where even though it could be all dynamic and work, you do want to =
register a choice to prevent backwards compatibility attacks.

I don't really want to complicate registration by trying to make it also =
cover AS discovery.

John B.

On 2013-04-24, at 7:55 PM, Phil Hunt  wrote:

> Right and if the client wants a method not supported then what?
>=20
> Why can't the client offer up a list of methods it is able to support, =
say in order of preference?
>=20
> The text appears to indicate only one value may be passed.
>=20
> Given the way it is written. It seems better to just have the server =
say the client must do authn method X in the response.
>=20
> Phil
>=20
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>=20
>=20
>=20
>=20
>=20
> On 2013-04-24, at 3:41 PM, John Bradley wrote:
>=20
>> In Connect the AS may support a number of token endpoint =
authentication methods.   The reason to allow a client to register using =
a particular one is to prevent downgrade attacks.
>>=20
>> If the client wants to always use an asymmetric signature you don't =
want to allow attackers to use weaker methods like http basic.
>>=20
>> So a server may support any number of methods, but it is reasonable =
for a client to specify which one it is going to use.   In a closed =
system that may not be that useful but in a open system where the AS has =
a looser relationship to the client it is important.
>>=20
>> John B.
>>=20
>> On 2013-04-24, at 7:30 PM, Phil Hunt  wrote:
>>=20
>>> Hmmm=85 what was the objective or use case for having the client =
being able to choose in the first place?
>>>=20
>>> It seems to me that the AS will make a decision based on many =
factors. As you say, there isn't any other place that enumerates the =
various [authn] methods a client can use to access the token endpoint.  =
So, why do it?
>>>=20
>>> Phil
>>>=20
>>> @independentid
>>> www.independentid.com
>>> phil.hunt@oracle.com
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>> On 2013-04-24, at 2:07 PM, Justin Richer wrote:
>>>=20
>>>> Seems reasonable to me, can you suggest language to add in the =
capability? Would it require an IANA registry? Right now there isn't any =
other place that enumerates the various methods that a client can use to =
access the token endpoint.
>>>>=20
>>>>  -- Justin
>>>>=20
>>>> On 04/24/2013 04:17 PM, Phil Hunt wrote:
>>>>> For parameters to token_endpoint_auth_method, the spec has defined =
"client_secret_jwt" and "private_key_jwt". Shouldn't there be similar =
options of SAML?
>>>>>=20
>>>>> Shouldn't there be an extension point for other methods?
>>>>>=20
>>>>> Phil
>>>>>=20
>>>>> @independentid
>>>>> www.independentid.com
>>>>> phil.hunt@oracle.com
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>=20
>>>=20
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>=20


--Apple-Mail=_CFE58024-70CF-4278-9137-332A4BDFDB1E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

In =
Connect there is a AS discovery before registration. =
  

The general pattern is the RP discovers =
the capabilities of the AS authentication methods and algorithms =
supported by the AS.  
The client then picks the best =
options for it and registers them.

It would in =
theory work of the client knowing nothing about the AS pushed it's =
capabilities at the AS as you are suggesting and let the AS =
pick.

My general feeling is that discovery with =
the client picking the options works best.

In =
many cases the client doesn't need to register parameters as they can be =
selected at run time once it knows what a server supports. =
 
The token endpoint authentication method was a bit of a =
special case where even though it could be all dynamic and work, you do =
want to register a choice to prevent backwards compatibility =
attacks.

I don't really want to complicate =
registration by trying to make it also cover AS =
discovery.

John B.

On =
2013-04-24, at 7:55 PM, Phil Hunt <phil.hunt@oracle.com> =
wrote:

Right and if the client =
wants a method not supported then what?

Why can't the =
client offer up a list of methods it is able to support, say in order of =
preference?

The text appears to indicate only =
one value may be passed.

Given the way it is =
written. It seems better to just have the server say the client must do =
authn method X in the response.



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








On 2013-04-24, at 3:41 PM, John Bradley wrote:

In =
Connect the AS may support a number of token endpoint authentication =
methods.   The reason to allow a client to register using a =
particular one is to prevent downgrade attacks.

If =
the client wants to always use an asymmetric signature you don't want to =
allow attackers to use weaker methods like http =
basic.

So a server may support any number of =
methods, but it is reasonable for a client to specify which one it is =
going to use.   In a closed system that may not be that useful but =
in a open system where the AS has a looser relationship to the client it =
is important.

John =
B.

On 2013-04-24, at 7:30 PM, Phil =
Hunt <phil.hunt@oracle.com> =
wrote:

Hmmm=85 what was the =
objective or use case for having the client being able to choose in the =
first place?

It seems to me that the AS will make a =
decision based on many factors. As you say, there isn't any other place =
that enumerates the various [authn] methods a client can use to access =
the token endpoint.  So, why do it?



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








On 2013-04-24, at 2:07 PM, Justin Richer wrote:


 =20
    
 =20
  

    Seems reasonable to me, can you suggest language to add in the
    capability? Would it require an IANA registry? Right now there isn't
    any other place that enumerates the various methods that a client
    can use to access the token endpoint.

    

     -- Justin

    

    
On 04/24/2013 04:17 PM, Phil Hunt
      wrote:

    

    

      
      
For parameters to token_endpoint_auth_method, the spec has
        defined "client_secret_jwt" and "private_key_jwt". Shouldn't
        there be similar options of SAML?

      


      

      
Shouldn't there be an extension point for other =
methods?

      


      

      
      

      

      

      

      
_______________________________________________
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=_CFE58024-70CF-4278-9137-332A4BDFDB1E--

--Apple-Mail=_59AF0F5A-0A27-4325-8169-E7D697CAA3E2
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g
AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q
YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5
AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v
eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA
FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM
L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI
p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz
Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5
QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV
HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z
dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j
b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp
bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t
IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t
cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP
MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg
d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u
cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny
bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw
AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF
BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j
cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB
AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC
cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ
4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh
JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC
fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT
AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0
aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt
ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3
DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNDI0MjMyMzA1WjAjBgkqhkiG9w0BCQQxFgQUID6yW63X
/FKs9hlptKq7/So1GJowgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK
Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu
dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAmsjfdv+FgZ76iaC9gqz6JPXNEy73rdfujbURSneV
0DTtBBNVmf4YP1pI+9NT5sGpEZpZUjLxQ2jy+l+9bJcA6i14daxz5GdXAPPvtGaVw955ZV9w/HfW
oMRWj5Rjg5UVYA/+Eqy1z/eRbV4bVWhqKXAlZIP0xd6cbf5GDzSG/rsfaA8RgeU0oowqWiT5L9eP
AvoaKiiKjaZx7hYGjyLVjpiV8dcAQ5eIMzICYx5rnVt/PMx2fQCNuc9Zs3MV9PEUK/yUYLkQ+fn8
pmzVeWyJ+0gEyz7fgPEvAK6KSq4pVG79ccFrIcePy+5VW8zzpNEyV1ZLJvdgOVCOUzfpCH83VQAA
AAAAAA==

--Apple-Mail=_59AF0F5A-0A27-4325-8169-E7D697CAA3E2--

From phil.hunt@oracle.com  Wed Apr 24 16:28:17 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5215021F8E9A for ; Wed, 24 Apr 2013 16:28:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.9
X-Spam-Level: 
X-Spam-Status: No, score=-5.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_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 0+0EBq7tjcUZ for ; Wed, 24 Apr 2013 16:28:16 -0700 (PDT)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 1406921F86F7 for ; Wed, 24 Apr 2013 16:28:16 -0700 (PDT)
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r3ONSEIX026129 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 24 Apr 2013 23:28:15 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r3ONSDxY013921 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 24 Apr 2013 23:28:13 GMT
Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r3ONSDrJ029540; Wed, 24 Apr 2013 23:28:13 GMT
Received: from [192.168.1.8] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 24 Apr 2013 16:28:12 -0700
References: <53250C00-9D1C-4E81-9AD6-E12241B875D9@oracle.com> <5178498B.3050406@mitre.org> <0E96125F-CFEC-4157-8A1E-3CFCA1C4D79F@oracle.com> <0C683171-29F6-47EA-A611-AB6394207353@ve7jtb.com>  <4E1F6AAD24975D4BA5B1680429673943676ABC64@TK5EX14MBXC284.redmond.corp.microsoft.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943676ABC64@TK5EX14MBXC284.redmond.corp.microsoft.com>
Content-Type: multipart/alternative; boundary=Apple-Mail-AB666FBC-C1F6-447A-BD53-4ABD085C04E7
Content-Transfer-Encoding: 7bit
Message-Id: 
X-Mailer: iPhone Mail (10B329)
From: Phil Hunt 
Date: Wed, 24 Apr 2013 16:28:12 -0700
To: Mike Jones 
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] Questions on draft-ietf-oauth-dyn-reg-09 - token_endpoint_auth_method
X-BeenThere: oauth@ietf.org
X-Mailman-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, 24 Apr 2013 23:28:17 -0000

--Apple-Mail-AB666FBC-C1F6-447A-BD53-4ABD085C04E7
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Fair enough, but that doesn't make sense in this broader forum where discove=
ry isn't assumed.  =20

Phil

On 2013-04-24, at 16:17, Mike Jones  wrote:

> What you=E2=80=99re missing is the part of the OpenID Connect flow where t=
he client first discovers the capabilities that the Server advertises.  In t=
his case, it uses this discovery parameter:
> =20
> token_endpoint_auth_signing_alg_values_supported
> OPTIONAL. JSON array containing a list of the JWS signing algorithms (alg v=
alues) supported by the Token Endpoint for the private_key_jwt and client_se=
cret_jwt methods to encode the JWT. Servers SHOULD support RS256.
> =20
> So in this use case, the client already knows what algorithms it can choos=
e from, and it makes the choice.
> =20
> Other OAuth flows could do the same thing, given either dynamic discovery o=
r a published algorithm list by the server.
> =20
>                                                             -- Mike
> =20
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of P=
hil Hunt
> Sent: Wednesday, April 24, 2013 3:55 PM
> To: John Bradley
> Cc: oauth@ietf.org WG
> Subject: Re: [OAUTH-WG] Questions on draft-ietf-oauth-dyn-reg-09 - token_e=
ndpoint_auth_method
> =20
> Right and if the client wants a method not supported then what?
> =20
> Why can't the client offer up a list of methods it is able to support, say=
 in order of preference?
> =20
> The text appears to indicate only one value may be passed.
> =20
> Given the way it is written. It seems better to just have the server say t=
he client must do authn method X in the response.
> =20
> Phil
> =20
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>=20
> =20
>=20
>=20
> =20
> On 2013-04-24, at 3:41 PM, John Bradley wrote:
>=20
>=20
> In Connect the AS may support a number of token endpoint authentication me=
thods.   The reason to allow a client to register using a particular one is t=
o prevent downgrade attacks.
> =20
> If the client wants to always use an asymmetric signature you don't want t=
o allow attackers to use weaker methods like http basic.
> =20
> So a server may support any number of methods, but it is reasonable for a c=
lient to specify which one it is going to use.   In a closed system that may=
 not be that useful but in a open system where the AS has a looser relations=
hip to the client it is important.
> =20
> John B.
> =20
> On 2013-04-24, at 7:30 PM, Phil Hunt  wrote:
>=20
>=20
> Hmmm=E2=80=A6 what was the objective or use case for having the client bei=
ng able to choose in the first place?
> =20
> It seems to me that the AS will make a decision based on many factors. As y=
ou say, there isn't any other place that enumerates the various [authn] meth=
ods a client can use to access the token endpoint.  So, why do it?
> =20
> Phil
> =20
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>=20
> =20
>=20
>=20
> =20
> On 2013-04-24, at 2:07 PM, Justin Richer wrote:
>=20
>=20
> Seems reasonable to me, can you suggest language to add in the capability?=
 Would it require an IANA registry? Right now there isn't any other place th=
at enumerates the various methods that a client can use to access the token e=
ndpoint.
>=20
>  -- Justin
>=20
> On 04/24/2013 04:17 PM, Phil Hunt wrote:
> For parameters to token_endpoint_auth_method, the spec has defined "client=
_secret_jwt" and "private_key_jwt". Shouldn't there be similar options of SA=
ML?
> =20
> Shouldn't there be an extension point for other methods?
> =20
> Phil
> =20
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>=20
> =20
> =20
>=20
>=20
>=20
>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> =20
> =20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> =20
> =20

--Apple-Mail-AB666FBC-C1F6-447A-BD53-4ABD085C04E7
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


Fair enough, but that doesn't make sen=
se in this broader forum where discovery isn't assumed.   

Phil

On 2013-04-24, at 16:17, Mike Jones <Michael.Jones@microsoft.com> wro=
te:



=








What you=E2=80=99re missing=
 is the part of the OpenID Connect flow where the client first discovers the=
 capabilities that the Server advertises.  In this case, it uses
 this discovery parameter:


 

token_endpoint_auth_signing_alg_values_supported=



OPTIONAL. JSON array containing a list of the JWS signing algorith=
ms (alg<=
span lang=3D"EN" style=3D"font-size:10.0pt;font-family:"Verdana",&=
quot;sans-serif";color:black">
 values) supported by the Token Endpoint for the private_key_jwt and
client_secret_jwt methods to encode the JWT. Ser=
vers SHOULD support
RS256.



 

So in this use case, the cl=
ient already knows what algorithms it can choose from, and it makes the choi=
ce.


 

Other OAuth flows could do t=
he same thing, given either dynamic discovery or a published algorithm list b=
y the server.


 

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


 





From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]
On Behalf Of Phil Hunt

Sent: Wednesday, April 24, 2013 3:55 PM

To: John Bradley

Cc: oauth@ietf.org WG

Subject: Re: [OAUTH-WG] Questions on draft-ietf-oauth-dyn-reg-09 - to=
ken_endpoint_auth_method






 


Right and if the client wants a method not supported t=
hen what?




 






Why can't the client offer up a list of methods it is=
 able to support, say in order of preference?






 






The text appears to indicate only one value may be pa=
ssed.






 






Given the way it is written. It seems better to just h=
ave the server say the client must do authn method X in the response.






 







 












 






On 2013-04-24, at 3:41 PM, John Bradley wrote:













In Connect the AS may support a number of token endpo=
int authentication methods.   The reason to allow a client to register u=
sing a particular one is to prevent downgrade attacks.




 






If the client wants to always use an asymmetric signa=
ture you don't want to allow attackers to use weaker methods like http basic=
.






 






So a server may support any number of methods, but it=
 is reasonable for a client to specify which one it is going to use.   I=
n a closed system that may not be that useful but in a open system where the=
 AS has a looser relationship to the
 client it is important.






 






John B.






 










On 2013-04-24, at 7:30 PM, Phil Hunt <phil.hunt@oracle.com> wrote:












Hmmm=E2=80=A6 what was the objective or use case for h=
aving the client being able to choose in the first place?




 






It seems to me that the AS will make a decision based=
 on many factors. As you say, there isn't any other place that enumerates th=
e various [authn] methods a client can use to access the token endpoint. &nb=
sp;So, why do it?






 











 













 






On 2013-04-24, at 2:07 PM, Justin Richer wrote:<=
/o:p>













Seems reasonable to me=
, can you suggest language to add in the capability? Would it require an IAN=
A registry? Right now there isn't any other place that enumerates the variou=
s methods that a client can use to
 access the token endpoint.



 -- Justin




On 04/24/2013 04:17 PM, Phil Hunt wrote:







For parameters to token=
_endpoint_auth_method,
the spec has defined "client_secret_jwt" and "private_key_jwt"=
. Shouldn't there be similar options of SAML?






 






Shouldn't there be an extension point for other metho=
ds?






 









 




 















_______________________________________________


OAuth mailing list


OAuth@ietf.org


https://www.iet=
f.org/mailman/listinfo/oauth




 






 






_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




 








 








=

--Apple-Mail-AB666FBC-C1F6-447A-BD53-4ABD085C04E7--

From sberyozkin@gmail.com  Thu Apr 25 02:13:21 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA46E21F8C08 for ; Thu, 25 Apr 2013 02:13:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tc3q7oM6W8xc for ; Thu, 25 Apr 2013 02:13:20 -0700 (PDT)
Received: from mail-ee0-f46.google.com (mail-ee0-f46.google.com [74.125.83.46]) by ietfa.amsl.com (Postfix) with ESMTP id 539D721F85F4 for ; Thu, 25 Apr 2013 02:13:20 -0700 (PDT)
Received: by mail-ee0-f46.google.com with SMTP id c13so1133015eek.5 for ; Thu, 25 Apr 2013 02:13:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=7TcF7M7XgYc5HFQjfAaWxz0UdkcKejKeFFgfmNXfYcc=; b=dC0FcIjB/oGQBnYqiFwFdWMPLqPcnlMjB8sGvGGgKcz3bBB35VwmBLUrHxlOj5nWGU jPhoGoZEk3FzBjnZlprjJQVXrugefFJQCuLraKGS4bnB5mjSikwIhvYWD71Nk+i9KrWr aZ3tKAK0hDXr6wSodEb2qavZu1PN0C9jAUirWcMDmM1bq7OFJUklgfVyQpbqucO0EGrq YfnH9+d9ex/x5y78CJO5aiV0sCTuNNHYAyTImj++VQPV+KbD0WSNPydTSeRxrDrJBmPh Kn4QEA0XLsych1Qf6eTyZaqXnfSadBabqgt9oEHwNclZrCiACSD53U2YsP3C0PP70Ueb 2a5w==
X-Received: by 10.14.173.71 with SMTP id u47mr37986213eel.24.1366881199500; Thu, 25 Apr 2013 02:13:19 -0700 (PDT)
Received: from [10.36.226.5] ([217.173.99.61]) by mx.google.com with ESMTPSA id f9sm9156479eeu.11.2013.04.25.02.13.18 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 25 Apr 2013 02:13:18 -0700 (PDT)
Message-ID: <5178F389.8030707@gmail.com>
Date: Thu, 25 Apr 2013 10:12:41 +0100
From: Sergey Beryozkin 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: oauth@ietf.org
References: <53250C00-9D1C-4E81-9AD6-E12241B875D9@oracle.com> <5178498B.3050406@mitre.org> <0E96125F-CFEC-4157-8A1E-3CFCA1C4D79F@oracle.com> <0C683171-29F6-47EA-A611-AB6394207353@ve7jtb.com>  <4E1F6AAD24975D4BA5B1680429673943676ABC64@TK5EX14MBXC284.redmond.corp.microsoft.com> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [OAUTH-WG] Questions on draft-ietf-oauth-dyn-reg-09 - token_endpoint_auth_method
X-BeenThere: oauth@ietf.org
X-Mailman-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, 25 Apr 2013 09:13:21 -0000

On 25/04/13 00:28, Phil Hunt wrote:
> Fair enough, but that doesn't make sense in this broader forum where
> discovery isn't assumed.
>
I guess it is true, I wonder, even with the discovery, would real world 
clients be able to choose from a list of the supported methods 
dynamically ? They are probably pre-configured to work with a specific 
method.

Sergey

> Phil
>
> On 2013-04-24, at 16:17, Mike Jones  > wrote:
>
>> What you’re missing is the part of the OpenID Connect flow where the
>> client first discovers the capabilities that the Server advertises. In
>> this case, it uses this discovery parameter:
>>
>> token_endpoint_auth_signing_alg_values_supported
>>
>> OPTIONAL. JSON array containing a list of the JWS signing algorithms
>> (algvalues) supported by the Token Endpoint for the private_key_jwtand
>> client_secret_jwtmethods to encode the JWT. Servers SHOULD support RS256.
>>
>> So in this use case, the client already knows what algorithms it can
>> choose from, and it makes the choice.
>>
>> Other OAuth flows could do the same thing, given either dynamic
>> discovery or a published algorithm list by the server.
>>
>> -- Mike
>>
>> *From:*oauth-bounces@ietf.org 
>> [mailto:oauth-bounces@ietf.org] *On Behalf Of *Phil Hunt
>> *Sent:* Wednesday, April 24, 2013 3:55 PM
>> *To:* John Bradley
>> *Cc:* oauth@ietf.org  WG
>> *Subject:* Re: [OAUTH-WG] Questions on draft-ietf-oauth-dyn-reg-09 -
>> token_endpoint_auth_method
>>
>> Right and if the client wants a method not supported then what?
>>
>> Why can't the client offer up a list of methods it is able to support,
>> say in order of preference?
>>
>> The text appears to indicate only one value may be passed.
>>
>> Given the way it is written. It seems better to just have the server
>> say the client must do authn method X in the response.
>>
>> Phil
>>
>> @independentid
>>
>> www.independentid.com 
>>
>> phil.hunt@oracle.com 
>>
>>
>>
>> On 2013-04-24, at 3:41 PM, John Bradley wrote:
>>
>>
>>
>> In Connect the AS may support a number of token endpoint
>> authentication methods. The reason to allow a client to register using
>> a particular one is to prevent downgrade attacks.
>>
>> If the client wants to always use an asymmetric signature you don't
>> want to allow attackers to use weaker methods like http basic.
>>
>> So a server may support any number of methods, but it is reasonable
>> for a client to specify which one it is going to use. In a closed
>> system that may not be that useful but in a open system where the AS
>> has a looser relationship to the client it is important.
>>
>> John B.
>>
>> On 2013-04-24, at 7:30 PM, Phil Hunt > > wrote:
>>
>>
>>
>> Hmmm… what was the objective or use case for having the client being
>> able to choose in the first place?
>>
>> It seems to me that the AS will make a decision based on many factors.
>> As you say, there isn't any other place that enumerates the various
>> [authn] methods a client can use to access the token endpoint. So, why
>> do it?
>>
>> Phil
>>
>> @independentid
>>
>> www.independentid.com 
>>
>> phil.hunt@oracle.com 
>>
>>
>>
>> On 2013-04-24, at 2:07 PM, Justin Richer wrote:
>>
>>
>>
>> Seems reasonable to me, can you suggest language to add in the
>> capability? Would it require an IANA registry? Right now there isn't
>> any other place that enumerates the various methods that a client can
>> use to access the token endpoint.
>>
>> -- Justin
>>
>> On 04/24/2013 04:17 PM, Phil Hunt wrote:
>>
>>     For parameters to token_endpoint_auth_method, the spec has defined
>>     "client_secret_jwt" and "private_key_jwt". Shouldn't there be
>>     similar options of SAML?
>>
>>     Shouldn't there be an extension point for other methods?
>>
>>     Phil
>>
>>     @independentid
>>
>>     www.independentid.com 
>>
>>     phil.hunt@oracle.com 
>>
>>
>>
>>
>>
>>     _______________________________________________
>>
>>     OAuth mailing list
>>
>>     OAuth@ietf.org  
>>
>>     https://www.ietf.org/mailman/listinfo/oauth
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



From ve7jtb@ve7jtb.com  Thu Apr 25 04:57:39 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B36B21F95EB for ; Thu, 25 Apr 2013 04:57:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.382
X-Spam-Level: 
X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.216,  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 3TnLF+UfJlcT for ; Thu, 25 Apr 2013 04:57:38 -0700 (PDT)
Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 2FE8121F9590 for ; Thu, 25 Apr 2013 04:57:38 -0700 (PDT)
Received: by mail-ie0-f182.google.com with SMTP id bn7so3454693ieb.27 for ; Thu, 25 Apr 2013 04:57:37 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=awKnvsH31SfS/hSTMacaQHVJTxeDSQc6UWGiFgx0NKQ=; b=PxMI/6uHCq8XfGgKg20nZO3DTRfqdVhWWES3GK2Q1+O71pbnPDmBAvY8DOCFyA+iz3 faMxzeGETYI7F1HcWIVPK4p2mcpWRd6I2f9pRZkX5OUeEFb9HmlDhfw5+KObIz7uMEIV AqHq4ifXSHSHDXHtJTaRorEURNqtYoDu7c/1q4RsHXy0fOxYm69JrrBlQzKxZHM5KZEm u/tYmJh5oXJhxmHMD1V7S7kXyUnsPwYLWVtFLfFTqmDHZiU8jhXjGmMFNnhXcVetM7fU RN+uL7dwMIUX1pHL6EhfBke8LJEK6ucdzJTrnMqCqycDIekIQIZsb6Tj64rnHU8cqV37 kmdA==
X-Received: by 10.50.130.3 with SMTP id oa3mr25496686igb.76.1366891057587; Thu, 25 Apr 2013 04:57:37 -0700 (PDT)
Received: from [192.168.1.39] (190-20-16-122.baf.movistar.cl. [190.20.16.122]) by mx.google.com with ESMTPSA id dy5sm12422852igc.1.2013.04.25.04.57.28 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 25 Apr 2013 04:57:36 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_1C25A3B5-4171-4219-AC76-82DCB14CF2F6"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: John Bradley 
In-Reply-To: 
Date: Thu, 25 Apr 2013 08:57:07 -0300
Message-Id: <8DE15911-C16A-4581-914D-3F2B5735AE59@ve7jtb.com>
References: <53250C00-9D1C-4E81-9AD6-E12241B875D9@oracle.com> <5178498B.3050406@mitre.org> <0E96125F-CFEC-4157-8A1E-3CFCA1C4D79F@oracle.com> <0C683171-29F6-47EA-A611-AB6394207353@ve7jtb.com>  <4E1F6AAD24975D4BA5B1680429673943676ABC64@TK5EX14MBXC284.redmond.corp.microsoft.com> 
To: Phil Hunt 
X-Mailer: Apple Mail (2.1503)
X-Gm-Message-State: ALoCoQkYjRQfqYwnhaEH1s8oKKy+3H/lvP2y/BpnaSU2M9ccbGoO2BLviCxll/ykxSJiN1TkGeCj
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] Questions on draft-ietf-oauth-dyn-reg-09 - token_endpoint_auth_method
X-BeenThere: oauth@ietf.org
X-Mailman-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, 25 Apr 2013 11:57:39 -0000

--Apple-Mail=_1C25A3B5-4171-4219-AC76-82DCB14CF2F6
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_C73E2134-D88C-408D-820A-ECDAD3B22BEC"


--Apple-Mail=_C73E2134-D88C-408D-820A-ECDAD3B22BEC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

I think discovery is required.  One of the things that needs to be =
discovered is the dynamic registration endpoint.

We can try and back pseudo discovery into Dynamic registration, however =
just doing discovery as a separate step will be easier.

If you start wanting to overload registration there are lots of things =
in discovery like endpoints and key information from the AS that are not =
currently included in dynamic registration.   You picked only one thing =
out of a long list of things that would need to change if you wanted to =
include discovery functionality in dynamic registration.

I think Discovery can be done a number of ways but probably deserves its =
own spec as we did with Connect.

John B.

On 2013-04-24, at 8:28 PM, Phil Hunt  wrote:

> Fair enough, but that doesn't make sense in this broader forum where =
discovery isn't assumed.  =20
>=20
> Phil
>=20
> On 2013-04-24, at 16:17, Mike Jones  =
wrote:
>=20
>> What you=92re missing is the part of the OpenID Connect flow where =
the client first discovers the capabilities that the Server advertises.  =
In this case, it uses this discovery parameter:
>> =20
>> token_endpoint_auth_signing_alg_values_supported
>> OPTIONAL. JSON array containing a list of the JWS signing algorithms =
(alg values) supported by the Token Endpoint for the private_key_jwt and =
client_secret_jwt methods to encode the JWT. Servers SHOULD support =
RS256.
>> =20
>> So in this use case, the client already knows what algorithms it can =
choose from, and it makes the choice.
>> =20
>> Other OAuth flows could do the same thing, given either dynamic =
discovery or a published algorithm list by the server.
>> =20
>>                                                             -- Mike
>> =20
>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On =
Behalf Of Phil Hunt
>> Sent: Wednesday, April 24, 2013 3:55 PM
>> To: John Bradley
>> Cc: oauth@ietf.org WG
>> Subject: Re: [OAUTH-WG] Questions on draft-ietf-oauth-dyn-reg-09 - =
token_endpoint_auth_method
>> =20
>> Right and if the client wants a method not supported then what?
>> =20
>> Why can't the client offer up a list of methods it is able to =
support, say in order of preference?
>> =20
>> The text appears to indicate only one value may be passed.
>> =20
>> Given the way it is written. It seems better to just have the server =
say the client must do authn method X in the response.
>> =20
>> Phil
>> =20
>> @independentid
>> www.independentid.com
>> phil.hunt@oracle.com
>>=20
>> =20
>>=20
>>=20
>> =20
>> On 2013-04-24, at 3:41 PM, John Bradley wrote:
>>=20
>>=20
>> In Connect the AS may support a number of token endpoint =
authentication methods.   The reason to allow a client to register using =
a particular one is to prevent downgrade attacks.
>> =20
>> If the client wants to always use an asymmetric signature you don't =
want to allow attackers to use weaker methods like http basic.
>> =20
>> So a server may support any number of methods, but it is reasonable =
for a client to specify which one it is going to use.   In a closed =
system that may not be that useful but in a open system where the AS has =
a looser relationship to the client it is important.
>> =20
>> John B.
>> =20
>> On 2013-04-24, at 7:30 PM, Phil Hunt  wrote:
>>=20
>>=20
>> Hmmm=85 what was the objective or use case for having the client =
being able to choose in the first place?
>> =20
>> It seems to me that the AS will make a decision based on many =
factors. As you say, there isn't any other place that enumerates the =
various [authn] methods a client can use to access the token endpoint.  =
So, why do it?
>> =20
>> Phil
>> =20
>> @independentid
>> www.independentid.com
>> phil.hunt@oracle.com
>>=20
>> =20
>>=20
>>=20
>> =20
>> On 2013-04-24, at 2:07 PM, Justin Richer wrote:
>>=20
>>=20
>> Seems reasonable to me, can you suggest language to add in the =
capability? Would it require an IANA registry? Right now there isn't any =
other place that enumerates the various methods that a client can use to =
access the token endpoint.
>>=20
>>  -- Justin
>>=20
>> On 04/24/2013 04:17 PM, Phil Hunt wrote:
>> For parameters to token_endpoint_auth_method, the spec has defined =
"client_secret_jwt" and "private_key_jwt". Shouldn't there be similar =
options of SAML?
>> =20
>> Shouldn't there be an extension point for other methods?
>> =20
>> Phil
>> =20
>> @independentid
>> www.independentid.com
>> phil.hunt@oracle.com
>>=20
>> =20
>> =20
>>=20
>>=20
>>=20
>>=20
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>> =20
>> =20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>> =20
>> =20


--Apple-Mail=_C73E2134-D88C-408D-820A-ECDAD3B22BEC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

I =
think discovery is required.  One of the things that needs to be =
discovered is the dynamic registration endpoint.

We =
can try and back pseudo discovery into Dynamic registration, however =
just doing discovery as a separate step will be =
easier.

If you start wanting to overload =
registration there are lots of things in discovery like endpoints and =
key information from the AS that are not currently included in dynamic =
registration.   You picked only one thing out of a long list of =
things that would need to change if you wanted to include discovery =
functionality in dynamic registration.

I think =
Discovery can be done a number of ways but probably deserves its own =
spec as we did with Connect.

John =
B.

On 2013-04-24, at 8:28 PM, Phil Hunt <phil.hunt@oracle.com> =
wrote:

Fair enough, but that doesn't =
make sense in this broader forum where discovery isn't assumed. =
  

Phil

On 2013-04-24, at 16:17, =
Mike Jones <Michael.Jones@microsoft.com> wrote:









What you=92re missing is the part of the OpenID =
Connect flow where the client first discovers the capabilities that the =
Server advertises.  In this case, it uses
 this discovery parameter:
 
OPTIONAL. =
JSON array containing a list of the JWS signing algorithms =
(alg
 values) supported by the Token Endpoint for the private_key_jwtclient_secret_jwt methods =
to encode the JWT. Servers SHOULD support
RS256.

 
So in this use case, the client already knows what =
algorithms it can choose from, and it makes the =
choice.
 
Other OAuth flows could do the same thing, given =
either dynamic discovery or a published algorithm list by the =
server.
 
        &nbs=
p;            =
            &n=
bsp;           &nbs=
p;            =
  -- Mike
 




From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]
On Behalf Of Phil Hunt

Sent: Wednesday, April 24, 2013 3:55 PM

To: John Bradley

Cc: oauth@ietf.org WG

Subject: Re: [OAUTH-WG] Questions on draft-ietf-oauth-dyn-reg-09 =
- token_endpoint_auth_method




 
Right and if the client wants a method not supported =
then what?


 




Why can't the client offer up a list of =
methods it is able to support, say in order of =
preference?




 




The text appears to indicate only one value =
may be passed.




 




Given the way it is written. It seems better =
to just have the server say the client must do authn method X in the =
response.




 






 









 




On 2013-04-24, at 3:41 PM, John Bradley =
wrote:









In Connect the AS may support a number of =
token endpoint authentication methods.   The reason to allow a =
client to register using a particular one is to prevent downgrade =
attacks.


 




If the client wants to always use an =
asymmetric signature you don't want to allow attackers to use weaker =
methods like http basic.




 




So a server may support any number of =
methods, but it is reasonable for a client to specify which one it is =
going to use.   In a closed system that may not be that useful but =
in a open system where the AS has a looser relationship to the
 client it is important.




 




John B.




 








On 2013-04-24, at 7:30 PM, Phil Hunt <phil.hunt@oracle.com> =
wrote:









Hmmm=85 what was the objective or use case =
for having the client being able to choose in the first =
place?


 




It seems to me that the AS will make a =
decision based on many factors. As you say, there isn't any other place =
that enumerates the various [authn] methods a client can use to access =
the token endpoint.  So, why do it?




 










 









 




On 2013-04-24, at 2:07 PM, Justin Richer =
wrote:









Seems =
reasonable to me, can you suggest language to add in the capability? =
Would it require an IANA registry? Right now there isn't any other place =
that enumerates the various methods that a client can use to
 access the token endpoint.



 -- Justin


On 04/24/2013 04:17 PM, Phil Hunt =
wrote:






For parameters to token_endpoint_auth_method,
the spec has defined "client_secret_jwt" and =
"private_key_jwt". Shouldn't there be similar options of =
SAML?




 




Shouldn't there be an extension point for =
other methods?




 








 


 













_______________________________________________


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=_C73E2134-D88C-408D-820A-ECDAD3B22BEC--

--Apple-Mail=_1C25A3B5-4171-4219-AC76-82DCB14CF2F6
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g
AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q
YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5
AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v
eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA
FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM
L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI
p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz
Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5
QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV
HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z
dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j
b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp
bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t
IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t
cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP
MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg
d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u
cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny
bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw
AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF
BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j
cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB
AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC
cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ
4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh
JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC
fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT
AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0
aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt
ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3
DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNDI1MTE1NzA4WjAjBgkqhkiG9w0BCQQxFgQU+3HGnu3e
0pWUwOJh6FylZb+sJ9kwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK
Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu
dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAMAcUlw7a4WYdZ0nsB4IZHUdbYIvqisXOzDQnNsxj
w22BfmOwG2myPGch+pGvoPdvq/d3nPZXYxkduRQEWOrRz3iUOVWrNmdEPyvIooap63xJaTsoJzUd
N2pP/uxkbBuZTf8iKPJIydaS8y5Xw30lfBRLyY/5Eq+tuMFwzKJt6C9TgU9YE9HncFXo7m5IfAdA
SVQ/bRsWcSMLiZQXxmM8s/BGCGTEk8Vk/xuiZjUdZRYY9GRC6Jn4iMmEQOh3C+lKQ3JrFFfvMk0k
u7nJC61oJr2immqZzAluSFSj38u5QUINGPyn0/wBhw+6FBsS2n8PvqMycQ4I01wFZr9z3BtbRQAA
AAAAAA==

--Apple-Mail=_1C25A3B5-4171-4219-AC76-82DCB14CF2F6--

From jricher@mitre.org  Thu Apr 25 06:30:21 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC5321F9606 for ; Thu, 25 Apr 2013 06:30:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fpuVWS8xRo4u for ; Thu, 25 Apr 2013 06:30:20 -0700 (PDT)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id A785821F8976 for ; Thu, 25 Apr 2013 06:30:19 -0700 (PDT)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 5D1B91F04B2; Thu, 25 Apr 2013 09:30:18 -0400 (EDT)
Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 4779F1F047A; Thu, 25 Apr 2013 09:30:18 -0400 (EDT)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.342.3; Thu, 25 Apr 2013 09:30:18 -0400
Message-ID: <51792FD5.7040605@mitre.org>
Date: Thu, 25 Apr 2013 09:29:57 -0400
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130329 Thunderbird/17.0.5
MIME-Version: 1.0
To: Phil Hunt 
References: <53250C00-9D1C-4E81-9AD6-E12241B875D9@oracle.com> <5178498B.3050406@mitre.org> <0E96125F-CFEC-4157-8A1E-3CFCA1C4D79F@oracle.com> <0C683171-29F6-47EA-A611-AB6394207353@ve7jtb.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------060407000803070909000000"
X-Originating-IP: [129.83.31.58]
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] Questions on draft-ietf-oauth-dyn-reg-09 - token_endpoint_auth_method
X-BeenThere: oauth@ietf.org
X-Mailman-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, 25 Apr 2013 13:30:21 -0000

--------------060407000803070909000000
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 8bit

The thing to remember is that all of these parameters are bi directional 
since the configuration is echoed back to the client. On the one hand 
(C->S), it's the client stating its preference. On the other direction 
(S->C) it's the server specifying the client's configuration. So the 
server *does* say that the client must do authn method X in its 
response, using the same parameter. And if the client wants a method 
that doesn't get supported, then it doesn't get to use it. But at least 
it has a chance to know about that by looking at the server's response. 
Same goes with scopes, grant types, and others.

It is a singular value. At one point I had had it in there as an array 
(space separated list of strings, I think), but the Connect working 
group didn't want to make it plural at the time.

  -- Justin


On 04/24/2013 06:55 PM, Phil Hunt wrote:
> Right and if the client wants a method not supported then what?
>
> Why can't the client offer up a list of methods it is able to support, 
> say in order of preference?
>
> The text appears to indicate only one value may be passed.
>
> Given the way it is written. It seems better to just have the server 
> say the client must do authn method X in the response.
>
> Phil
>
> @independentid
> www.independentid.com 
> phil.hunt@oracle.com 
>
>
>
>
>
> On 2013-04-24, at 3:41 PM, John Bradley wrote:
>
>> In Connect the AS may support a number of token endpoint 
>> authentication methods.   The reason to allow a client to register 
>> using a particular one is to prevent downgrade attacks.
>>
>> If the client wants to always use an asymmetric signature you don't 
>> want to allow attackers to use weaker methods like http basic.
>>
>> So a server may support any number of methods, but it is reasonable 
>> for a client to specify which one it is going to use.   In a closed 
>> system that may not be that useful but in a open system where the AS 
>> has a looser relationship to the client it is important.
>>
>> John B.
>>
>> On 2013-04-24, at 7:30 PM, Phil Hunt > > wrote:
>>
>>> Hmmm… what was the objective or use case for having the client being 
>>> able to choose in the first place?
>>>
>>> It seems to me that the AS will make a decision based on many 
>>> factors. As you say, there isn't any other place that enumerates the 
>>> various [authn] methods a client can use to access the token 
>>> endpoint.  So, why do it?
>>>
>>> Phil
>>>
>>> @independentid
>>> www.independentid.com 
>>> phil.hunt@oracle.com 
>>>
>>>
>>>
>>>
>>>
>>> On 2013-04-24, at 2:07 PM, Justin Richer wrote:
>>>
>>>> Seems reasonable to me, can you suggest language to add in the 
>>>> capability? Would it require an IANA registry? Right now there 
>>>> isn't any other place that enumerates the various methods that a 
>>>> client can use to access the token endpoint.
>>>>
>>>>  -- Justin
>>>>
>>>> On 04/24/2013 04:17 PM, Phil Hunt wrote:
>>>>> For parameters to token_endpoint_auth_method, the spec has defined 
>>>>> "client_secret_jwt" and "private_key_jwt". Shouldn't there be 
>>>>> similar options of SAML?
>>>>>
>>>>> Shouldn't there be an extension point for other methods?
>>>>>
>>>>> Phil
>>>>>
>>>>> @independentid
>>>>> www.independentid.com 
>>>>> phil.hunt@oracle.com 
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>


--------------060407000803070909000000
Content-Type: text/html; charset="windows-1252"
Content-Transfer-Encoding: 8bit


  
    
  
  
    The thing to remember is that all of these parameters are bi
    directional since the configuration is echoed back to the client. On
    the one hand (C->S), it's the client stating its preference. On
    the other direction (S->C) it's the server specifying the
    client's configuration. So the server *does* say that the client
    must do authn method X in its response, using the same parameter.
    And if the client wants a method that doesn't get supported, then it
    doesn't get to use it. But at least it has a chance to know about
    that by looking at the server's response. Same goes with scopes,
    grant types, and others. 

    

    It is a singular value. At one point I had had it in there as an
    array (space separated list of strings, I think), but the Connect
    working group didn't want to make it plural at the time. 

    

     -- Justin

    

    


      On 04/24/2013 06:55 PM, Phil Hunt wrote:

    

    

      
      Right and if the client wants a method not supported then what?
      


      

      
Why can't the client offer up a list of methods it is able to
        support, say in order of preference?

      


      

      
The text appears to indicate only one value may be passed.

      


      

      
Given the way it is written. It seems better to just have the
        server say the client must do authn method X in the response.

      


        
        

        

          
On 2013-04-24, at 3:41 PM, John Bradley wrote:

          

          

            
In Connect the AS
              may support a number of token endpoint authentication
              methods.   The reason to allow a client to register using
              a particular one is to prevent downgrade attacks.
              


              

              
If the client wants to always use an asymmetric
                signature you don't want to allow attackers to use
                weaker methods like http basic.

              


              

              
So a server may support any number of methods, but it
                is reasonable for a client to specify which one it is
                going to use.   In a closed system that may not be that
                useful but in a open system where the AS has a looser
                relationship to the client it is important.

              


              

              
John B.

              


              

              

                

                  
On 2013-04-24, at 7:30 PM, Phil Hunt <phil.hunt@oracle.com>
                    wrote:

                  

                  

                    
Hmmm… what was the objective
                      or use case for having the client being able to
                      choose in the first place?
                      


                      

                      
It seems to me that the AS will make a
                        decision based on many factors. As you say,
                        there isn't any other place that enumerates the
                        various [authn] methods a client can use to
                        access the token endpoint.  So, why do it?

                      


                      

                      

                        
                        

                        

                          
On 2013-04-24, at 2:07 PM, Justin Richer
                            wrote:

                          

                          

                            
 Seems
                              reasonable to me, can you suggest language
                              to add in the capability? Would it require
                              an IANA registry? Right now there isn't
                              any other place that enumerates the
                              various methods that a client can use to
                              access the token endpoint.

                              

                               -- Justin

                              

                              
On 04/24/2013
                                04:17 PM, Phil Hunt wrote:

                              

                              

                                
For parameters to token_endpoint_auth_method,
                                  the spec has defined
                                  "client_secret_jwt" and
                                  "private_key_jwt". Shouldn't there be
                                  similar options of SAML?

                                


                                

                                
Shouldn't there be an extension
                                  point for other methods?

                                


                                

                                
                                

                                

                                

                                

                                
_______________________________________________
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

                  

                

                

              

            

          

        

        

      

    

    

  


--------------060407000803070909000000--

From jricher@mitre.org  Thu Apr 25 06:42:05 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47A2021F961D for ; Thu, 25 Apr 2013 06:42:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jjnVnofAXoK3 for ; Thu, 25 Apr 2013 06:42:04 -0700 (PDT)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id C2C4C21F9610 for ; Thu, 25 Apr 2013 06:42:03 -0700 (PDT)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 647DC1F038A; Thu, 25 Apr 2013 09:42:03 -0400 (EDT)
Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 495A61F048F; Thu, 25 Apr 2013 09:42:03 -0400 (EDT)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.342.3; Thu, 25 Apr 2013 09:42:03 -0400
Message-ID: <51793297.4020102@mitre.org>
Date: Thu, 25 Apr 2013 09:41:43 -0400
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130329 Thunderbird/17.0.5
MIME-Version: 1.0
To: John Bradley 
References: <53250C00-9D1C-4E81-9AD6-E12241B875D9@oracle.com> <5178498B.3050406@mitre.org> <0E96125F-CFEC-4157-8A1E-3CFCA1C4D79F@oracle.com> <0C683171-29F6-47EA-A611-AB6394207353@ve7jtb.com>  <629E4582-16C4-4554-9591-39E6801FA0A8@ve7jtb.com>
In-Reply-To: <629E4582-16C4-4554-9591-39E6801FA0A8@ve7jtb.com>
Content-Type: multipart/alternative; boundary="------------070105010002050504040005"
X-Originating-IP: [129.83.31.58]
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] Questions on draft-ietf-oauth-dyn-reg-09 - token_endpoint_auth_method
X-BeenThere: oauth@ietf.org
X-Mailman-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, 25 Apr 2013 13:42:05 -0000

--------------070105010002050504040005
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 8bit

John, I don't think that anybody's actually suggesting that we add 
server discovery in here. :) But since the server does echo back the 
configuration in its response, the client is discovering a few things at 
run time about what it can and can't do with a particular server. It's 
entirely possible that the client might get back a configuration option 
that it can't use (say, it can't do client_secret_jwt assertions but it 
can do

 From what I can see from this thread though there are two open 
questions that Phil's raised:


  1: Extensibility of token_endpoint_auth_method values, and where 
potential values are listed (IANA? fully qualified URIs for things not 
in the base spec?)

  2: Plurality of token_endpoint_auth_method (could be left as a string, 
made an array, or be a JSON-style optional plural: string value if 
singular or array if plural)



I think the first one should be addressed, but we just need to pick the 
method. I'm personally in favor of the same method we used for 
grant_type, which is short values in the spec and extensions as fully 
qualified URIs. The second one could break existing implementations (and 
other dependent specs), so if we change it, it has to be for very good 
reason.

  -- Justin

On 04/24/2013 07:23 PM, John Bradley wrote:
> In Connect there is a AS discovery before registration.
>
> The general pattern is the RP discovers the capabilities of the AS 
> authentication methods and algorithms supported by the AS.
> The client then picks the best options for it and registers them.
>
> It would in theory work of the client knowing nothing about the AS 
> pushed it's capabilities at the AS as you are suggesting and let the 
> AS pick.
>
> My general feeling is that discovery with the client picking the 
> options works best.
>
> In many cases the client doesn't need to register parameters as they 
> can be selected at run time once it knows what a server supports.
> The token endpoint authentication method was a bit of a special case 
> where even though it could be all dynamic and work, you do want to 
> register a choice to prevent backwards compatibility attacks.
>
> I don't really want to complicate registration by trying to make it 
> also cover AS discovery.
>
> John B.
>
> On 2013-04-24, at 7:55 PM, Phil Hunt  > wrote:
>
>> Right and if the client wants a method not supported then what?
>>
>> Why can't the client offer up a list of methods it is able to 
>> support, say in order of preference?
>>
>> The text appears to indicate only one value may be passed.
>>
>> Given the way it is written. It seems better to just have the server 
>> say the client must do authn method X in the response.
>>
>> Phil
>>
>> @independentid
>> www.independentid.com 
>> phil.hunt@oracle.com 
>>
>>
>>
>>
>>
>> On 2013-04-24, at 3:41 PM, John Bradley wrote:
>>
>>> In Connect the AS may support a number of token endpoint 
>>> authentication methods.   The reason to allow a client to register 
>>> using a particular one is to prevent downgrade attacks.
>>>
>>> If the client wants to always use an asymmetric signature you don't 
>>> want to allow attackers to use weaker methods like http basic.
>>>
>>> So a server may support any number of methods, but it is reasonable 
>>> for a client to specify which one it is going to use.   In a closed 
>>> system that may not be that useful but in a open system where the AS 
>>> has a looser relationship to the client it is important.
>>>
>>> John B.
>>>
>>> On 2013-04-24, at 7:30 PM, Phil Hunt >> > wrote:
>>>
>>>> Hmmm… what was the objective or use case for having the client 
>>>> being able to choose in the first place?
>>>>
>>>> It seems to me that the AS will make a decision based on many 
>>>> factors. As you say, there isn't any other place that enumerates 
>>>> the various [authn] methods a client can use to access the token 
>>>> endpoint.  So, why do it?
>>>>
>>>> Phil
>>>>
>>>> @independentid
>>>> www.independentid.com 
>>>> phil.hunt@oracle.com 
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 2013-04-24, at 2:07 PM, Justin Richer wrote:
>>>>
>>>>> Seems reasonable to me, can you suggest language to add in the 
>>>>> capability? Would it require an IANA registry? Right now there 
>>>>> isn't any other place that enumerates the various methods that a 
>>>>> client can use to access the token endpoint.
>>>>>
>>>>>  -- Justin
>>>>>
>>>>> On 04/24/2013 04:17 PM, Phil Hunt wrote:
>>>>>> For parameters to token_endpoint_auth_method, the spec has 
>>>>>> defined "client_secret_jwt" and "private_key_jwt". Shouldn't 
>>>>>> there be similar options of SAML?
>>>>>>
>>>>>> Shouldn't there be an extension point for other methods?
>>>>>>
>>>>>> Phil
>>>>>>
>>>>>> @independentid
>>>>>> www.independentid.com 
>>>>>> phil.hunt@oracle.com 
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>> OAuth@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org 
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>
>


--------------070105010002050504040005
Content-Type: text/html; charset="windows-1252"
Content-Transfer-Encoding: 8bit


  
    
  
  
    John, I don't think that anybody's actually suggesting that we add
    server discovery in here. :) But since the server does echo back the
    configuration in its response, the client is discovering a few
    things at run time about what it can and can't do with a particular
    server. It's entirely possible that the client might get back a
    configuration option that it can't use (say, it can't do
    client_secret_jwt assertions but it can do 

    

    From what I can see from this thread though there are two open
    questions that Phil's raised:

    

    

     1: Extensibility of token_endpoint_auth_method values, and where
    potential values are listed (IANA? fully qualified URIs for things
    not in the base spec?)

    

     2: Plurality of token_endpoint_auth_method (could be left as a
    string, made an array, or be a JSON-style optional plural: string
    value if singular or array if plural)

    

    

    

    I think the first one should be addressed, but we just need to pick
    the method. I'm personally in favor of the same method we used for
    grant_type, which is short values in the spec and extensions as
    fully qualified URIs. The second one could break existing
    implementations (and other dependent specs), so if we change it, it
    has to be for very good reason.

    

     -- Justin

    

    
On 04/24/2013 07:23 PM, John Bradley
      wrote:

    

    

      
      In Connect there is a AS discovery before registration.   
      


      

      
The general pattern is the RP discovers the capabilities of
        the AS authentication methods and algorithms supported by the
        AS.  

      
The client then picks the best options for it and registers
        them.

      


      

      
It would in theory work of the client knowing nothing about
        the AS pushed it's capabilities at the AS as you are suggesting
        and let the AS pick.

      


      

      
My general feeling is that discovery with the client picking
        the options works best.

      


      

      
In many cases the client doesn't need to register parameters
        as they can be selected at run time once it knows what a server
        supports.  

      
The token endpoint authentication method was a bit of a
        special case where even though it could be all dynamic and work,
        you do want to register a choice to prevent backwards
        compatibility attacks.

      


      

      
I don't really want to complicate registration by trying to
        make it also cover AS discovery.

      


      

      
John B.

      


        

          
On 2013-04-24, at 7:55 PM, Phil Hunt <phil.hunt@oracle.com>
            wrote:

          

          

            
Right and if the
              client wants a method not supported then what?
              


              

              
Why can't the client offer up a list of methods it is
                able to support, say in order of preference?

              


              

              
The text appears to indicate only one value may be
                passed.

              


              

              
Given the way it is written. It seems better to just
                have the server say the client must do authn method X in
                the response.

              


                
                

                

                  
On 2013-04-24, at 3:41 PM, John Bradley wrote:

                  

                  

                    
                    
In Connect the AS may support
                      a number of token endpoint authentication methods.
                        The reason to allow a client to register using a
                      particular one is to prevent downgrade attacks.
                      


                      

                      
If the client wants to always use an
                        asymmetric signature you don't want to allow
                        attackers to use weaker methods like http basic.

                      


                      

                      
So a server may support any number of
                        methods, but it is reasonable for a client to
                        specify which one it is going to use.   In a
                        closed system that may not be that useful but in
                        a open system where the AS has a looser
                        relationship to the client it is important.

                      


                      

                      
John B.

                      


                      

                      

                        

                          
On 2013-04-24, at 7:30 PM, Phil Hunt <phil.hunt@oracle.com>
                            wrote:

                          

                          

                            
Hmmm…
                              what was the objective or use case for
                              having the client being able to choose in
                              the first place?
                              


                              

                              
It seems to me that the AS will make
                                a decision based on many factors. As you
                                say, there isn't any other place that
                                enumerates the various [authn] methods a
                                client can use to access the token
                                endpoint.  So, why do it?

                              


                              

                              

                                
                                

                                

                                  
On 2013-04-24, at 2:07 PM, Justin
                                    Richer wrote:

                                  

                                  

                                    
                                    
 Seems reasonable
                                      to me, can you suggest language to
                                      add in the capability? Would it
                                      require an IANA registry? Right
                                      now there isn't any other place
                                      that enumerates the various
                                      methods that a client can use to
                                      access the token endpoint.

                                      

                                       -- Justin

                                      

                                      
On
                                        04/24/2013 04:17 PM, Phil Hunt
                                        wrote:

                                      

                                      

                                        
                                        
For parameters to token_endpoint_auth_method,
                                          the spec has defined
                                          "client_secret_jwt" and
                                          "private_key_jwt". Shouldn't
                                          there be similar options of
                                          SAML?

                                        


                                        

                                        
Shouldn't there be an
                                          extension point for other
                                          methods?

                                        


                                        

                                        
                                        

                                        

                                        

                                        

                                        
_______________________________________________
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

                          

                        

                        

                      

                    

                  

                

                

              

            

          

        

        

      

    

    

  


--------------070105010002050504040005--

From ve7jtb@ve7jtb.com  Thu Apr 25 07:21:19 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7601A21F9497 for ; Thu, 25 Apr 2013 07:21:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.406
X-Spam-Level: 
X-Spam-Status: No, score=-2.406 tagged_above=-999 required=5 tests=[AWL=0.192,  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 n7e82kWyZ3m3 for ; Thu, 25 Apr 2013 07:21:18 -0700 (PDT)
Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id C0DD221F937B for ; Thu, 25 Apr 2013 07:21:17 -0700 (PDT)
Received: by mail-ie0-f181.google.com with SMTP id tp5so3664162ieb.12 for ; Thu, 25 Apr 2013 07:21:17 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=u+MbmoFrQ6/l3S9rY4ZB5jMchtvUQ3wXl1Ghb8x3Uys=; b=gRiIWMPNOKlpED9oZmcLpzvsk3mwIakIHDhwKaj+JOeIRKiZ7Lzu7mY17U6vyY4JIK JFu1OmmWAKDp3Us40H5qVXH2pEEvxerdoSMiEpjTxC0nBD/rrTN4AtKfYQ/fs1rvT4mR l6Qlx/OV24/eNwBqm+jFvwYprY4SdVohijc3I7ikiNihtE5uqcNHub+iW9UIrabz7G4k NZnivvnqKPA22QvC/xW5ypp0LKqiGohXm1eHOGedXBWiG2LtwWkQUTf/KqPa25Cnp5yt 17xNxYHdzt1lFWioPsW1HG1YfQcWJAjquevQvxRxfPbzIOJRZxmUBSa/74TKWjuO7TVB j4jw==
X-Received: by 10.50.237.71 with SMTP id va7mr31640107igc.88.1366899677232; Thu, 25 Apr 2013 07:21:17 -0700 (PDT)
Received: from [192.168.1.39] (190-20-16-122.baf.movistar.cl. [190.20.16.122]) by mx.google.com with ESMTPSA id m4sm35073035igd.0.2013.04.25.07.21.13 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 25 Apr 2013 07:21:15 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_40F96664-1823-47AB-A132-96D91CA90EB7"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: John Bradley 
In-Reply-To: <51793297.4020102@mitre.org>
Date: Thu, 25 Apr 2013 11:21:12 -0300
Message-Id: <870ADA58-1706-40CD-97AC-A357CE1D6094@ve7jtb.com>
References: <53250C00-9D1C-4E81-9AD6-E12241B875D9@oracle.com> <5178498B.3050406@mitre.org> <0E96125F-CFEC-4157-8A1E-3CFCA1C4D79F@oracle.com> <0C683171-29F6-47EA-A611-AB6394207353@ve7jtb.com>  <629E4582-16C4-4554-9591-39E6801FA0A8@ve7jtb.com> <51793297.4020102@mitre.org>
To: Justin Richer 
X-Mailer: Apple Mail (2.1503)
X-Gm-Message-State: ALoCoQmZNofDrOJ7+OkbzqgXhsLoQlxUptJSWiTrzZknmrhJFtq+/GqLBHPVjhH7/nkDzVtOmZYr
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] Questions on draft-ietf-oauth-dyn-reg-09 - token_endpoint_auth_method
X-BeenThere: oauth@ietf.org
X-Mailman-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, 25 Apr 2013 14:21:19 -0000

--Apple-Mail=_40F96664-1823-47AB-A132-96D91CA90EB7
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_3AEA4C66-C36E-470C-B0A7-7B0AD3ADF033"


--Apple-Mail=_3AEA4C66-C36E-470C-B0A7-7B0AD3ADF033
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

I am OK with having a registry,  Connect profiles the jwt assertions =
draft to add specifics around keying material for interoperability. =20
It may well be that people will want other methods including SAML =
assertions.

While sending a list of methods the client supports to the server and =
getting back what is supported by the server works, it is awkward.

My point is mostly that there are lots of other parameters that are set =
only by the server.  I don't know if we want to start adding them to =
registration just to allow for them to be discovered.   Using a simple =
.well-known discovery document seems simpler.

So making token_endpoint_auth_method an array is not the end of the =
world and would work, but heads us in what I think is the wrong =
direction.

John B.

On 2013-04-25, at 10:41 AM, Justin Richer  wrote:

> John, I don't think that anybody's actually suggesting that we add =
server discovery in here. :) But since the server does echo back the =
configuration in its response, the client is discovering a few things at =
run time about what it can and can't do with a particular server. It's =
entirely possible that the client might get back a configuration option =
that it can't use (say, it can't do client_secret_jwt assertions but it =
can do=20
>=20
> =46rom what I can see from this thread though there are two open =
questions that Phil's raised:
>=20
>=20
>  1: Extensibility of token_endpoint_auth_method values, and where =
potential values are listed (IANA? fully qualified URIs for things not =
in the base spec?)
>=20
>  2: Plurality of token_endpoint_auth_method (could be left as a =
string, made an array, or be a JSON-style optional plural: string value =
if singular or array if plural)
>=20
>=20
>=20
> I think the first one should be addressed, but we just need to pick =
the method. I'm personally in favor of the same method we used for =
grant_type, which is short values in the spec and extensions as fully =
qualified URIs. The second one could break existing implementations (and =
other dependent specs), so if we change it, it has to be for very good =
reason.
>=20
>  -- Justin
>=20
> On 04/24/2013 07:23 PM, John Bradley wrote:
>> In Connect there is a AS discovery before registration.  =20
>>=20
>> The general pattern is the RP discovers the capabilities of the AS =
authentication methods and algorithms supported by the AS. =20
>> The client then picks the best options for it and registers them.
>>=20
>> It would in theory work of the client knowing nothing about the AS =
pushed it's capabilities at the AS as you are suggesting and let the AS =
pick.
>>=20
>> My general feeling is that discovery with the client picking the =
options works best.
>>=20
>> In many cases the client doesn't need to register parameters as they =
can be selected at run time once it knows what a server supports. =20
>> The token endpoint authentication method was a bit of a special case =
where even though it could be all dynamic and work, you do want to =
register a choice to prevent backwards compatibility attacks.
>>=20
>> I don't really want to complicate registration by trying to make it =
also cover AS discovery.
>>=20
>> John B.
>>=20
>> On 2013-04-24, at 7:55 PM, Phil Hunt  wrote:
>>=20
>>> Right and if the client wants a method not supported then what?
>>>=20
>>> Why can't the client offer up a list of methods it is able to =
support, say in order of preference?
>>>=20
>>> The text appears to indicate only one value may be passed.
>>>=20
>>> Given the way it is written. It seems better to just have the server =
say the client must do authn method X in the response.
>>>=20
>>> Phil
>>>=20
>>> @independentid
>>> www.independentid.com
>>> phil.hunt@oracle.com
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>> On 2013-04-24, at 3:41 PM, John Bradley wrote:
>>>=20
>>>> In Connect the AS may support a number of token endpoint =
authentication methods.   The reason to allow a client to register using =
a particular one is to prevent downgrade attacks.
>>>>=20
>>>> If the client wants to always use an asymmetric signature you don't =
want to allow attackers to use weaker methods like http basic.
>>>>=20
>>>> So a server may support any number of methods, but it is reasonable =
for a client to specify which one it is going to use.   In a closed =
system that may not be that useful but in                         a open =
system where the AS has a looser relationship to the client it is =
important.
>>>>=20
>>>> John B.
>>>>=20
>>>> On 2013-04-24, at 7:30 PM, Phil Hunt  wrote:
>>>>=20
>>>>> Hmmm=85 what was the objective or use case for having the client =
being able to choose in the first place?
>>>>>=20
>>>>> It seems to me that the AS will make a decision based on many =
factors. As you say, there isn't any other place that enumerates the =
various [authn] methods a client can use to access the token endpoint.  =
So, why do it?
>>>>>=20
>>>>> Phil
>>>>>=20
>>>>> @independentid
>>>>> www.independentid.com
>>>>> phil.hunt@oracle.com
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> On 2013-04-24, at 2:07 PM, Justin Richer wrote:
>>>>>=20
>>>>>> Seems reasonable to me, can you suggest language to add in the =
capability? Would it require an IANA registry? Right now there isn't any =
other place that enumerates the various methods that a client can use to =
access the token endpoint.
>>>>>>=20
>>>>>>  -- Justin
>>>>>>=20
>>>>>> On 04/24/2013 04:17 PM, Phil Hunt wrote:
>>>>>>> For parameters to token_endpoint_auth_method,
>>>>>>>                                           the spec has defined =
"client_secret_jwt" and "private_key_jwt". Shouldn't there be similar =
options of SAML?
>>>>>>>=20
>>>>>>> Shouldn't there be an extension point for other methods?
>>>>>>>=20
>>>>>>> Phil
>>>>>>>=20
>>>>>>> @independentid
>>>>>>> www.independentid.com
>>>>>>> phil.hunt@oracle.com
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>> _______________________________________________
>>>>>>> OAuth mailing list
>>>>>>> OAuth@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>=20
>>>>>=20
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>=20
>>>=20
>>=20
>=20


--Apple-Mail=_3AEA4C66-C36E-470C-B0A7-7B0AD3ADF033
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

I am =
OK with having a registry,  Connect profiles the jwt assertions =
draft to add specifics around keying material for interoperability. =
 
It may well be that people will want other methods including =
SAML assertions.

While sending a list of =
methods the client supports to the server and getting back what is =
supported by the server works, it is =
awkward.

My point is mostly that there are lots =
of other parameters that are set only by the server.  I don't know =
if we want to start adding them to registration just to allow for them =
to be discovered.   Using a simple .well-known discovery document =
seems simpler.

So =
making token_endpoint_auth_method an array is not the end of the =
world and would work, but heads us in what I think is the wrong =
direction.

John =
B.

On 2013-04-25, at 10:41 AM, Justin =
Richer <jricher@mitre.org> =
wrote:


 =20
    
 =20
  

    John, I don't think that anybody's actually suggesting that we add
    server discovery in here. :) But since the server does echo back the
    configuration in its response, the client is discovering a few
    things at run time about what it can and can't do with a particular
    server. It's entirely possible that the client might get back a
    configuration option that it can't use (say, it can't do
    client_secret_jwt assertions but it can do 

    

    =46rom what I can see from this thread though there are two open
    questions that Phil's raised:

    

    

     1: Extensibility of token_endpoint_auth_method values, and =
where
    potential values are listed (IANA? fully qualified URIs for things
    not in the base spec?)

    

     2: Plurality of token_endpoint_auth_method (could be left as a
    string, made an array, or be a JSON-style optional plural: string
    value if singular or array if plural)

    

    

    

    I think the first one should be addressed, but we just need to pick
    the method. I'm personally in favor of the same method we used for
    grant_type, which is short values in the spec and extensions as
    fully qualified URIs. The second one could break existing
    implementations (and other dependent specs), so if we change it, it
    has to be for very good reason.

    

     -- Justin

    

    
On 04/24/2013 07:23 PM, John Bradley
      wrote:

    

    

      
      In Connect there is a AS discovery before registration. =
  
      


      

      
The general pattern is the RP discovers the capabilities of
        the AS authentication methods and algorithms supported by the
        AS.  

      
The client then picks the best options for it and registers
        them.

      


      

      
It would in theory work of the client knowing nothing about
        the AS pushed it's capabilities at the AS as you are suggesting
        and let the AS pick.

      


      

      
My general feeling is that discovery with the client picking
        the options works best.

      


      

      
In many cases the client doesn't need to register parameters
        as they can be selected at run time once it knows what a server
        supports.  

      
The token endpoint authentication method was a bit of a
        special case where even though it could be all dynamic and work,
        you do want to register a choice to prevent backwards
        compatibility attacks.

      


      

      
I don't really want to complicate registration by trying to
        make it also cover AS discovery.

      


      

      
John B.

      


        

          
On 2013-04-24, at 7:55 PM, Phil Hunt <phil.hunt@oracle.com>
            wrote:

          

          

            
Right and if the
              client wants a method not supported then what?
              


              

              
Why can't the client offer up a list of methods it is
                able to support, say in order of preference?

              


              

              
The text appears to indicate only one value may be
                passed.

              


              

              
Given the way it is written. It seems better to just
                have the server say the client must do authn method X in
                the response.

              


                

                  
                      

                          

                              
www.independentid.com

                              

                            phil.hunt@oracle.com

                            

                          

                        

                      

                    

                  

                

                

                

                  
On 2013-04-24, at 3:41 PM, John Bradley =
wrote:

                  

                  

                    
                    
In Connect the AS may support
                      a number of token endpoint authentication methods.
                        The reason to allow a client to register =
using a
                      particular one is to prevent downgrade attacks.
                      


                      

                      
If the client wants to always use an
                        asymmetric signature you don't want to allow
                        attackers to use weaker methods like http =
basic.

                      


                      

                      
So a server may support any number of
                        methods, but it is reasonable for a client to
                        specify which one it is going to use.   In =
a
                        closed system that may not be that useful but in
                        a open system where the AS has a looser
                        relationship to the client it is =
important.

                      


                      

                      
John B.

                      


                      

                      

                        

                          
On 2013-04-24, at 7:30 PM, Phil Hunt =
<phil.hunt@oracle.com>
                            wrote:

                          

                          

                            
                                

                                

                                  
On 2013-04-24, at 2:07 PM, Justin
                                    Richer wrote:

                                  
=

                                  

                                    
                                    
 Seems reasonable
                                      to me, can you suggest language to
                                      add in the capability? Would it
                                      require an IANA registry? Right
                                      now there isn't any other place
                                      that enumerates the various
                                      methods that a client can use to
                                      access the token endpoint.

                                      

                                       -- Justin

                                      

                                      
On
                                        04/24/2013 04:17 PM, Phil Hunt
                                        wrote:

                                      

                                      

                                        
                                        
For parameters =
to 
                                        


                                        

                                        
Shouldn't there be an
                                          extension point for other
                                          methods?

                                        


                                        

                                        

                                          

                                              

                                                  
www.independentid.com

                                                      

                                                    

                                                  

                                                phil.hunt@oracle.com

                                                

                                              

                                            

                                          

                                          

                                          

                                        

                                        

                                        

                                        

                                        

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


                                      

                                      

                                    

                                  

                                

                                

                              

                            

_______________________________________________

                            OAuth mailing list

                            OAuth@ietf.org

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

                          

                        

                        

                      

                    

                  
                

                

              

            

          
        

        

      

    
    

  

=

--Apple-Mail=_3AEA4C66-C36E-470C-B0A7-7B0AD3ADF033--

--Apple-Mail=_40F96664-1823-47AB-A132-96D91CA90EB7
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g
AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q
YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5
AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v
eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA
FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM
L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI
p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz
Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5
QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV
HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z
dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j
b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp
bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t
IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t
cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP
MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg
d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u
cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny
bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw
AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF
BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j
cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB
AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC
cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ
4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh
JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC
fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT
AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0
aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt
ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3
DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNDI1MTQyMTEyWjAjBgkqhkiG9w0BCQQxFgQUlLVx7nIQ
TcEts4m3fP5up1LIDkUwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK
Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu
dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAlAVy7yz+2+qVCj8yy1qmiisGVzlV3gcPGetfT0uQ
wKl17MgA2s9ZLj7ETZ9DTSwM+E3uxx12VwZIZOhLn03hBmS4ZBcW9IIzldN04zdu55G6tqtyilw4
yXjKM0IR+52q+5BEPWFoBSKSAVJSC+72A/XjvIT+KtAdswNCceSbQ6hktTJ1PsRNRCVeDROYt1ty
k3jlBM7IBWDybjButpwUwXnNtxDejU3KP0lIHUSddUr6IGMc9hhvhiuG6loUZOI3wm27hfYY4ilV
iIe9Socd8MHQbWJaqa25EBwWq8h8+Km3/ZL9Cta0aRVoQQRyn7/F+WSVYt6r6WtlXBxcoRsE+QAA
AAAAAA==

--Apple-Mail=_40F96664-1823-47AB-A132-96D91CA90EB7--

From phil.hunt@oracle.com  Thu Apr 25 09:23:27 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBCB021F873D for ; Thu, 25 Apr 2013 09:23:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.76
X-Spam-Level: 
X-Spam-Status: No, score=-5.76 tagged_above=-999 required=5 tests=[AWL=-0.558,  BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 IWF1F4V4lQeW for ; Thu, 25 Apr 2013 09:23:23 -0700 (PDT)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 1A38D21F9606 for ; Thu, 25 Apr 2013 09:23:22 -0700 (PDT)
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r3PGNFp5032104 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 25 Apr 2013 16:23:18 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r3PGNEc5010909 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 25 Apr 2013 16:23:14 GMT
Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r3PGNE4g014160; Thu, 25 Apr 2013 16:23:14 GMT
Received: from [192.168.1.8] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 25 Apr 2013 09:23:13 -0700
References: <53250C00-9D1C-4E81-9AD6-E12241B875D9@oracle.com> <5178498B.3050406@mitre.org> <0E96125F-CFEC-4157-8A1E-3CFCA1C4D79F@oracle.com> <0C683171-29F6-47EA-A611-AB6394207353@ve7jtb.com>  <629E4582-16C4-4554-9591-39E6801FA0A8@ve7jtb.com> <51793297.4020102@mitre.org> <870ADA58-1706-40CD-97AC-A357CE1D6094@ve7jtb.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <870ADA58-1706-40CD-97AC-A357CE1D6094@ve7jtb.com>
Content-Type: multipart/alternative; boundary=Apple-Mail-E916F662-2CB8-460D-91D5-C4DD06BFA056
Content-Transfer-Encoding: 7bit
Message-Id: <5B4EA19E-AA21-4EF1-962C-D2F028748CE1@oracle.com>
X-Mailer: iPhone Mail (10B329)
From: Phil Hunt 
Date: Thu, 25 Apr 2013 09:23:10 -0700
To: John Bradley 
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] Questions on draft-ietf-oauth-dyn-reg-09 - token_endpoint_auth_method
X-BeenThere: oauth@ietf.org
X-Mailman-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, 25 Apr 2013 16:23:27 -0000

--Apple-Mail-E916F662-2CB8-460D-91D5-C4DD06BFA056
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

I am not sure what to think about this.=20

1. I don't want this spec to be incomplete because there is another external=
 spec published for a specific purpose.=20

2. In general i would like to avoid negotiations. It seems to me that any de=
veloper making a client for a mutli-site deployed service would already be a=
ware of what the generic service require and implement based on that oob kno=
wledge. Thus when the server merely informs, the client should be prepared.=20=


IMHO, though i understand the motivation, negotiation of client auth creates=
 more problems then it seems to solve in this case. Downgrade attack is just=
 one of the problems.=20

Phil

On 2013-04-25, at 7:21, John Bradley  wrote:

> I am OK with having a registry,  Connect profiles the jwt assertions draft=
 to add specifics around keying material for interoperability. =20
> It may well be that people will want other methods including SAML assertio=
ns.
>=20
> While sending a list of methods the client supports to the server and gett=
ing back what is supported by the server works, it is awkward.
>=20
> My point is mostly that there are lots of other parameters that are set on=
ly by the server.  I don't know if we want to start adding them to registrat=
ion just to allow for them to be discovered.   Using a simple .well-known di=
scovery document seems simpler.
>=20
> So making token_endpoint_auth_method an array is not the end of the world a=
nd would work, but heads us in what I think is the wrong direction.
>=20
> John B.
>=20
> On 2013-04-25, at 10:41 AM, Justin Richer  wrote:
>=20
>> John, I don't think that anybody's actually suggesting that we add server=
 discovery in here. :) But since the server does echo back the configuration=
 in its response, the client is discovering a few things at run time about w=
hat it can and can't do with a particular server. It's entirely possible tha=
t the client might get back a configuration option that it can't use (say, i=
t can't do client_secret_jwt assertions but it can do=20
>>=20
>> =46rom what I can see from this thread though there are two open question=
s that Phil's raised:
>>=20
>>=20
>>  1: Extensibility of token_endpoint_auth_method values, and where potenti=
al values are listed (IANA? fully qualified URIs for things not in the base s=
pec?)
>>=20
>>  2: Plurality of token_endpoint_auth_method (could be left as a string, m=
ade an array, or be a JSON-style optional plural: string value if singular o=
r array if plural)
>>=20
>>=20
>>=20
>> I think the first one should be addressed, but we just need to pick the m=
ethod. I'm personally in favor of the same method we used for grant_type, wh=
ich is short values in the spec and extensions as fully qualified URIs. The s=
econd one could break existing implementations (and other dependent specs), s=
o if we change it, it has to be for very good reason.
>>=20
>>  -- Justin
>>=20
>> On 04/24/2013 07:23 PM, John Bradley wrote:
>>> In Connect there is a AS discovery before registration.        =20
>>>=20
>>> The general pattern is the RP discovers the capabilities of the AS authe=
ntication methods and algorithms supported by the AS. =20
>>> The client then picks the best options for it and registers         them=
.
>>>=20
>>> It would in theory work of the client knowing nothing about the AS pushe=
d it's capabilities at the AS as you are suggesting and let the AS pick.
>>>=20
>>> My general feeling is that discovery with the client picking the options=
 works best.
>>>=20
>>> In many cases the client doesn't need to register parameters as they can=
 be selected at run time once it knows what a server supports. =20
>>> The token endpoint authentication method was a bit of a         special c=
ase where even though it could be all dynamic and work, you do want to regis=
ter a choice to prevent backwards compatibility attacks.
>>>=20
>>> I don't really want to complicate registration by trying to make it also=
 cover AS discovery.
>>>=20
>>> John B.
>>>=20
>>> On 2013-04-24, at 7:55 PM, Phil Hunt  wrote:
>>>=20
>>>> Right and if the client wants a method not supported then what?
>>>>=20
>>>> Why can't the client offer up a list of methods it is able to support, s=
ay in order of preference?
>>>>=20
>>>> The text appears to indicate only one value may be passed.
>>>>=20
>>>> Given the way it is written. It seems better to just have the server sa=
y the client must do authn method X in the response.
>>>>=20
>>>> Phil
>>>>=20
>>>> @independentid
>>>> www.independentid.com
>>>> phil.hunt@oracle.com
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> On 2013-04-24, at 3:41 PM, John Bradley wrote:
>>>>=20
>>>>> In Connect the AS may support a number of token endpoint authenticatio=
n methods.   The reason to allow a client to register using a particular one=
 is to prevent downgrade attacks.
>>>>>=20
>>>>> If the client wants to always use an asymmetric signature you don't wa=
nt to allow attackers to use weaker methods like http basic.
>>>>>=20
>>>>> So a server may support any number of methods, but it is reasonable fo=
r a client to specify which one it is going to use.   In a closed system tha=
t may not be that useful but in a open system where the AS has a looser rela=
tionship to the client it is important.
>>>>>=20
>>>>> John B.
>>>>>=20
>>>>> On 2013-04-24, at 7:30 PM, Phil Hunt  wrote:
>>>>>=20
>>>>>> Hmmm=E2=80=A6 what was the objective or use case for having the clien=
t being able to choose in the first place?
>>>>>>=20
>>>>>> It seems to me that the AS will make a decision based on many factors=
. As you say, there isn't any other place that enumerates the various [authn=
] methods a client can use to access the token endpoint.  So, why do it?
>>>>>>=20
>>>>>> Phil
>>>>>>=20
>>>>>> @independentid
>>>>>> www.independentid.com
>>>>>> phil.hunt@oracle.com
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> On 2013-04-24, at 2:07 PM, Justin Richer wrote:
>>>>>>=20
>>>>>>> Seems reasonable to me, can you suggest language to add in the capab=
ility? Would it require an IANA registry? Right now there isn't any other pl=
ace that enumerates the various methods that a client can use to access the t=
oken endpoint.
>>>>>>>=20
>>>>>>>  -- Justin
>>>>>>>=20
>>>>>>> On 04/24/2013 04:17 PM, Phil Hunt wrote:
>>>>>>>> For parameters to token_endpoint_auth_method,
>>>>>>>>                                           the spec has defined "cli=
ent_secret_jwt" and "private_key_jwt". Shouldn't there be similar options of=
 SAML?
>>>>>>>>=20
>>>>>>>> Shouldn't there be an extension point for other methods?
>>>>>>>>=20
>>>>>>>> Phil
>>>>>>>>=20
>>>>>>>> @independentid
>>>>>>>> www.independentid.com
>>>>>>>> phil.hunt@oracle.com
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> _______________________________________________
>>>>>>>> OAuth mailing list
>>>>>>>> OAuth@ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>> OAuth@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>=20

--Apple-Mail-E916F662-2CB8-460D-91D5-C4DD06BFA056
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


I am not sure what to think about this=
. 

1. I don't want this spec to be incomplete b=
ecause there is another external spec published for a specific purpose. =
;

2. In general i would like to avoid negotiations.=
 It seems to me that any developer making a client for a mutli-site deployed=
 service would already be aware of what the generic service require and impl=
ement based on that oob knowledge. Thus when the server merely informs, the c=
lient should be prepared. 

IMHO, though i unde=
rstand the motivation, negotiation of client auth creates more problems then=
 it seems to solve in this case. Downgrade attack is just one of the problem=
s. 

Phil

On 2013-04-25, at 7:21, John Bradley <=
ve7jtb@ve7jtb.com> wrote:
I am OK with having a registry, &nb=
sp;Connect profiles the jwt assertions draft to add specifics around keying m=
aterial for interoperability.  
It may well be that people will wan=
t other methods including SAML assertions.

While se=
nding a list of methods the client supports to the server and getting back w=
hat is supported by the server works, it is awkward.

My point is mostly that there are lots of other parameters that are set on=
ly by the server.  I don't know if we want to start adding them to regi=
stration just to allow for them to be discovered.   Using a simple .wel=
l-known discovery document seems simpler.

So making=
 token_endpoint_auth_method an array is not the end of the world and wo=
uld work, but heads us in what I think is the wrong direction.
John B.

On 2013-04-25, at 10:=
41 AM, Justin Richer <jricher@mitre.=
org> wrote:


 =20
    
 =20
  

    John, I don't think that anybody's actually suggesting that we add
    server discovery in here. :) But since the server does echo back the
    configuration in its response, the client is discovering a few
    things at run time about what it can and can't do with a particular
    server. It's entirely possible that the client might get back a
    configuration option that it can't use (say, it can't do
    client_secret_jwt assertions but it can do 

    

    =46rom what I can see from this thread though there are two open
    questions that Phil's raised:

    

    

     1: Extensibility of token_endpoint_auth_method values, and where
    potential values are listed (IANA? fully qualified URIs for things
    not in the base spec?)

    

     2: Plurality of token_endpoint_auth_method (could be left as a
    string, made an array, or be a JSON-style optional plural: string
    value if singular or array if plural)

    

    

    

    I think the first one should be addressed, but we just need to pick
    the method. I'm personally in favor of the same method we used for
    grant_type, which is short values in the spec and extensions as
    fully qualified URIs. The second one could break existing
    implementations (and other dependent specs), so if we change it, it
    has to be for very good reason.

    

     -- Justin

    

    
On 04/24/2013 07:23 PM, John Bradley
      wrote:

    

    

      
      In Connect there is a AS discovery before registration.   
      


      

      
The general pattern is the RP discovers the capabilities of
        the AS authentication methods and algorithms supported by the
        AS.  

      
The client then picks the best options for it and registers
        them.

      


      

      
It would in theory work of the client knowing nothing about
        the AS pushed it's capabilities at the AS as you are suggesting
        and let the AS pick.

      


      

      
My general feeling is that discovery with the client picking
        the options works best.

      


      

      
In many cases the client doesn't need to register parameters
        as they can be selected at run time once it knows what a server
        supports.  

      
The token endpoint authentication method was a bit of a
        special case where even though it could be all dynamic and work,
        you do want to register a choice to prevent backwards
        compatibility attacks.

      


      

      
I don't really want to complicate registration by trying to
        make it also cover AS discovery.

      


      

      
John B.

      


        

          
On 2013-04-24, at 7:55 PM, Phil Hunt <phil.hunt@oracle.com>
            wrote:

          

          

            
Right and if the
              client wants a method not supported then what?
              


              

              
Why can't the client offer up a list of methods it is
                able to support, say in order of preference?

              


              

              
The text appears to indicate only one value may be
                passed.

              


              

              
Given the way it is written. It seems better to just
                have the server say the client must do authn method X in
                the response.

              


                
                

                

                  
On 2013-04-24, at 3:41 PM, John Bradley wrote:

                  

                  

                    
                    
In Connect the AS may support
                      a number of token endpoint authentication methods.
                        The reason to allow a client to register using a=

                      particular one is to prevent downgrade attacks.
                      


                      

                      
If the client wants to always use an
                        asymmetric signature you don't want to allow
                        attackers to use weaker methods like http basic.
                      


                      

                      
So a server may support any number of
                        methods, but it is reasonable for a client to
                        specify which one it is going to use.   In a
                        closed system that may not be that useful but in
                        a open system where the AS has a looser
                        relationship to the client it is important.

                      


                      

                      
John B.

                      


                      

                      

                        

                          
On 2013-04-24, at 7:30 PM, Phil Hunt <phil.hunt@oracl=
e.com>
                            wrote:

                          

                          

                            
Hmmm=E2=
=80=A6
                              what was the objective or use case for
                              having the client being able to choose in
                              the first place?
                              


                              

                              
It seems to me that the AS will make
                                a decision based on many factors. As you
                                say, there isn't any other place that
                                enumerates the various [authn] methods a
                                client can use to access the token
                                endpoint.  So, why do it?

                              


                              

                              

                                
                                

                                

                                  
On 2013-04-24, at 2:07 PM, Justin
                                    Richer wrote:

                                  

                                  

                                    
                                    
 Seems reasonable
                                      to me, can you suggest language to
                                      add in the capability? Would it
                                      require an IANA registry? Right
                                      now there isn't any other place
                                      that enumerates the various
                                      methods that a client can use to
                                      access the token endpoint.

                                      

                                       -- Justin

                                      

                                      
On
                                        04/24/2013 04:17 PM, Phil Hunt
                                        wrote:

                                      

                                      

                                        
                                        
For parameters to token_endpoi=
nt_auth_method,
                                          the spec has defined
                                          "client_secret_jwt" and
                                          "private_key_jwt". Shouldn't
                                          there be similar options of
                                          SAML?

                                        


                                        

                                        
Shouldn't there be an
                                          extension point for other
                                          methods?

                                        


                                        

                                        

                                          
                                        

                                        

                                        

                                        

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


                                      

                                      

                                    

                                  

                                

                                

                              

                            

_______________________________________________

                            OAuth mailing list

                            OAuth@ietf.org

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


                          

                        

                        

                      

                    

                  

                

                

              

            

          

        

        

      

    

    

  




=

--Apple-Mail-E916F662-2CB8-460D-91D5-C4DD06BFA056--

From jricher@mitre.org  Thu Apr 25 09:35:40 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A24821F93B9 for ; Thu, 25 Apr 2013 09:35:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47H4sIJcToIU for ; Thu, 25 Apr 2013 09:35:38 -0700 (PDT)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 02A6521F936D for ; Thu, 25 Apr 2013 09:35:38 -0700 (PDT)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 93C9C2260055; Thu, 25 Apr 2013 12:35:33 -0400 (EDT)
Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 8387D1F024A; Thu, 25 Apr 2013 12:35:33 -0400 (EDT)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.342.3; Thu, 25 Apr 2013 12:35:33 -0400
Message-ID: <51795B41.9010401@mitre.org>
Date: Thu, 25 Apr 2013 12:35:13 -0400
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130329 Thunderbird/17.0.5
MIME-Version: 1.0
To: Phil Hunt 
References: <53250C00-9D1C-4E81-9AD6-E12241B875D9@oracle.com> <5178498B.3050406@mitre.org> <0E96125F-CFEC-4157-8A1E-3CFCA1C4D79F@oracle.com> <0C683171-29F6-47EA-A611-AB6394207353@ve7jtb.com>  <629E4582-16C4-4554-9591-39E6801FA0A8@ve7jtb.com> <51793297.4020102@mitre.org> <870ADA58-1706-40CD-97AC-A357CE1D6094@ve7jtb.com> <5B4EA19E-AA21-4EF1-962C-D2F028748CE1@oracle.com>
In-Reply-To: <5B4EA19E-AA21-4EF1-962C-D2F028748CE1@oracle.com>
Content-Type: multipart/alternative; boundary="------------040406090000080009010204"
X-Originating-IP: [129.83.31.58]
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] Questions on draft-ietf-oauth-dyn-reg-09 - token_endpoint_auth_method
X-BeenThere: oauth@ietf.org
X-Mailman-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, 25 Apr 2013 16:35:40 -0000

--------------040406090000080009010204
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit


On 04/25/2013 12:23 PM, Phil Hunt wrote:
> I am not sure what to think about this.
>
> 1. I don't want this spec to be incomplete because there is another 
> external spec published for a specific purpose.
If we needed a registry we could define it in this spec. If we chose a 
non-registry method (like how grant_type uses URIs) then it's 
self-contained. I prefer the latter, myself.

> 2. In general i would like to avoid negotiations. It seems to me that 
> any developer making a client for a mutli-site deployed service would 
> already be aware of what the generic service require and implement 
> based on that oob knowledge. Thus when the server merely informs, the 
> client should be prepared.
The client already has to be prepared because the server will inform, 
though. But by making it bidirectional (like all the other parameters) 
it gives the client a chance to ask based on whatever information it 
wants to. The server is perfectly free to ignore what the client asks 
for and just hand it something, just as it's free to do so for all fields.

> IMHO, though i understand the motivation, negotiation of client auth 
> creates more problems then it seems to solve in this case. Downgrade 
> attack is just one of the problems.
The parameters of the negotiation are going to be application-protocol 
specific and depend on things like a Discovery layer for them to be 
fully dynamic from a cold boot. And even then servers and clients that 
care about this value are going to have to know how to enforce it (it's 
the same as it is with grant_type, response_type, scope, and others).

If nothing else, it lets servers tell clients which auth method to use 
at the token endpoint. The client can be smart and try to figure out if 
it actually supports that method before trying it, or it can be dumb and 
ignore the returned value. But with this parameter in the protocol, both 
sides at least have a *chance* of doing the right thing.

  -- Justin

>
> Phil
>
> On 2013-04-25, at 7:21, John Bradley  > wrote:
>
>> I am OK with having a registry,  Connect profiles the jwt assertions 
>> draft to add specifics around keying material for interoperability.
>> It may well be that people will want other methods including SAML 
>> assertions.
>>
>> While sending a list of methods the client supports to the server and 
>> getting back what is supported by the server works, it is awkward.
>>
>> My point is mostly that there are lots of other parameters that are 
>> set only by the server.  I don't know if we want to start adding them 
>> to registration just to allow for them to be discovered.   Using a 
>> simple .well-known discovery document seems simpler.
>>
>> So making token_endpoint_auth_method an array is not the end of the 
>> world and would work, but heads us in what I think is the wrong 
>> direction.
>>
>> John B.
>>
>> On 2013-04-25, at 10:41 AM, Justin Richer > > wrote:
>>
>>> John, I don't think that anybody's actually suggesting that we add 
>>> server discovery in here. :) But since the server does echo back the 
>>> configuration in its response, the client is discovering a few 
>>> things at run time about what it can and can't do with a particular 
>>> server. It's entirely possible that the client might get back a 
>>> configuration option that it can't use (say, it can't do 
>>> client_secret_jwt assertions but it can do
>>>
>>> From what I can see from this thread though there are two open 
>>> questions that Phil's raised:
>>>
>>>
>>>  1: Extensibility of token_endpoint_auth_method values, and where 
>>> potential values are listed (IANA? fully qualified URIs for things 
>>> not in the base spec?)
>>>
>>>  2: Plurality of token_endpoint_auth_method (could be left as a 
>>> string, made an array, or be a JSON-style optional plural: string 
>>> value if singular or array if plural)
>>>
>>>
>>>
>>> I think the first one should be addressed, but we just need to pick 
>>> the method. I'm personally in favor of the same method we used for 
>>> grant_type, which is short values in the spec and extensions as 
>>> fully qualified URIs. The second one could break existing 
>>> implementations (and other dependent specs), so if we change it, it 
>>> has to be for very good reason.
>>>
>>>  -- Justin
>>>
>>> On 04/24/2013 07:23 PM, John Bradley wrote:
>>>> In Connect there is a AS discovery before registration.
>>>>
>>>> The general pattern is the RP discovers the capabilities of the AS 
>>>> authentication methods and algorithms supported by the AS.
>>>> The client then picks the best options for it and registers them.
>>>>
>>>> It would in theory work of the client knowing nothing about the AS 
>>>> pushed it's capabilities at the AS as you are suggesting and let 
>>>> the AS pick.
>>>>
>>>> My general feeling is that discovery with the client picking the 
>>>> options works best.
>>>>
>>>> In many cases the client doesn't need to register parameters as 
>>>> they can be selected at run time once it knows what a server supports.
>>>> The token endpoint authentication method was a bit of a special 
>>>> case where even though it could be all dynamic and work, you do 
>>>> want to register a choice to prevent backwards compatibility attacks.
>>>>
>>>> I don't really want to complicate registration by trying to make it 
>>>> also cover AS discovery.
>>>>
>>>> John B.
>>>>
>>>> On 2013-04-24, at 7:55 PM, Phil Hunt >>> > wrote:
>>>>
>>>>> Right and if the client wants a method not supported then what?
>>>>>
>>>>> Why can't the client offer up a list of methods it is able to 
>>>>> support, say in order of preference?
>>>>>
>>>>> The text appears to indicate only one value may be passed.
>>>>>
>>>>> Given the way it is written. It seems better to just have the 
>>>>> server say the client must do authn method X in the response.
>>>>>
>>>>> Phil
>>>>>
>>>>> @independentid
>>>>> www.independentid.com 
>>>>> phil.hunt@oracle.com 
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 2013-04-24, at 3:41 PM, John Bradley wrote:
>>>>>
>>>>>> In Connect the AS may support a number of token endpoint 
>>>>>> authentication methods. The reason to allow a client to register 
>>>>>> using a particular one is to prevent downgrade attacks.
>>>>>>
>>>>>> If the client wants to always use an asymmetric signature you 
>>>>>> don't want to allow attackers to use weaker methods like http basic.
>>>>>>
>>>>>> So a server may support any number of methods, but it is 
>>>>>> reasonable for a client to specify which one it is going to use. 
>>>>>>   In a closed system that may not be that useful but in a open 
>>>>>> system where the AS has a looser relationship to the client it is 
>>>>>> important.
>>>>>>
>>>>>> John B.
>>>>>>
>>>>>> On 2013-04-24, at 7:30 PM, Phil Hunt >>>>> > wrote:
>>>>>>
>>>>>>> Hmmm… what was the objective or use case for having the client 
>>>>>>> being able to choose in the first place?
>>>>>>>
>>>>>>> It seems to me that the AS will make a decision based on many 
>>>>>>> factors. As you say, there isn't any other place that enumerates 
>>>>>>> the various [authn] methods a client can use to access the token 
>>>>>>> endpoint.  So, why do it?
>>>>>>>
>>>>>>> Phil
>>>>>>>
>>>>>>> @independentid
>>>>>>> www.independentid.com 
>>>>>>> phil.hunt@oracle.com 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 2013-04-24, at 2:07 PM, Justin Richer wrote:
>>>>>>>
>>>>>>>> Seems reasonable to me, can you suggest language to add in the 
>>>>>>>> capability? Would it require an IANA registry? Right now there 
>>>>>>>> isn't any other place that enumerates the various methods that 
>>>>>>>> a client can use to access the token endpoint.
>>>>>>>>
>>>>>>>>  -- Justin
>>>>>>>>
>>>>>>>> On 04/24/2013 04:17 PM, Phil Hunt wrote:
>>>>>>>>> For parameters to token_endpoint_auth_method, the spec has 
>>>>>>>>> defined "client_secret_jwt" and "private_key_jwt". Shouldn't 
>>>>>>>>> there be similar options of SAML?
>>>>>>>>>
>>>>>>>>> Shouldn't there be an extension point for other methods?
>>>>>>>>>
>>>>>>>>> Phil
>>>>>>>>>
>>>>>>>>> @independentid
>>>>>>>>> www.independentid.com 
>>>>>>>>> phil.hunt@oracle.com 
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> OAuth mailing list
>>>>>>>>> OAuth@ietf.org
>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> OAuth mailing list
>>>>>>> OAuth@ietf.org 
>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>
>>>>>
>>>>
>>>
>>


--------------040406090000080009010204
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: 8bit


  
    
  
  
    

    
On 04/25/2013 12:23 PM, Phil Hunt
      wrote:

    

    

      
      
I am not sure what to think about this. 

      


      

      
1. I don't want this spec to be incomplete because there is
        another external spec published for a specific purpose. 

      

    

    If we needed a registry we could define it in this spec. If we chose
    a non-registry method (like how grant_type uses URIs) then it's
    self-contained. I prefer the latter, myself.

    

    

      
2. In general i would like to avoid negotiations. It seems to
        me that any developer making a client for a mutli-site deployed
        service would already be aware of what the generic service
        require and implement based on that oob knowledge. Thus when the
        server merely informs, the client should be prepared. 

      

    

    The client already has to be prepared because the server will
    inform, though. But by making it bidirectional (like all the other
    parameters) it gives the client a chance to ask based on whatever
    information it wants to. The server is perfectly free to ignore what
    the client asks for and just hand it something, just as it's free to
    do so for all fields. 

    

    

      
IMHO, though i understand the motivation, negotiation of
        client auth creates more problems then it seems to solve in this
        case. Downgrade attack is just one of the problems.

      

    

    The parameters of the negotiation are going to be
    application-protocol specific and depend on things like a Discovery
    layer for them to be fully dynamic from a cold boot. And even then
    servers and clients that care about this value are going to have to
    know how to enforce it (it's the same as it is with grant_type,
    response_type, scope, and others). 

    

    If nothing else, it lets servers tell clients which auth method to
    use at the token endpoint. The client can be smart and try to figure
    out if it actually supports that method before trying it, or it can
    be dumb and ignore the returned value. But with this parameter in
    the protocol, both sides at least have a *chance* of doing the right
    thing.

    

     -- Justin

    

    

      


        Phil

      


        On 2013-04-25, at 7:21, John Bradley <ve7jtb@ve7jtb.com>
        wrote:

        

      

      

        
I am OK with having a registry,  Connect profiles the jwt
          assertions draft to add specifics around keying material for
          interoperability.  
          
It may well be that people will want other methods
            including SAML assertions.

          


          

          
While sending a list of methods the client supports to
            the server and getting back what is supported by the server
            works, it is awkward.

          


          

          
My point is mostly that there are lots of other
            parameters that are set only by the server.  I don't know if
            we want to start adding them to registration just to allow
            for them to be discovered.   Using a simple .well-known
            discovery document seems simpler.

          


          

          
So making token_endpoint_auth_method an array is not the
            end of the world and would work, but heads us in what I
            think is the wrong direction.

          


          

          
John B.

          


          

          

            

              
On 2013-04-25, at 10:41 AM, Justin Richer <jricher@mitre.org>
                wrote:

              

              

                
 John, I don't
                  think that anybody's actually suggesting that we add
                  server discovery in here. :) But since the server does
                  echo back the configuration in its response, the
                  client is discovering a few things at run time about
                  what it can and can't do with a particular server.
                  It's entirely possible that the client might get back
                  a configuration option that it can't use (say, it
                  can't do client_secret_jwt assertions but it can do 

                  

                  From what I can see from this thread though there are
                  two open questions that Phil's raised:

                  

                  

                   1: Extensibility of token_endpoint_auth_method
                  values, and where potential values are listed (IANA?
                  fully qualified URIs for things not in the base spec?)

                  

                   2: Plurality of token_endpoint_auth_method (could be
                  left as a string, made an array, or be a JSON-style
                  optional plural: string value if singular or array if
                  plural)

                  

                  

                  

                  I think the first one should be addressed, but we just
                  need to pick the method. I'm personally in favor of
                  the same method we used for grant_type, which is short
                  values in the spec and extensions as fully qualified
                  URIs. The second one could break existing
                  implementations (and other dependent specs), so if we
                  change it, it has to be for very good reason.

                  

                   -- Justin

                  

                  
On 04/24/2013 07:23 PM,
                    John Bradley wrote:

                  

                  
 In Connect there is a AS discovery
                    before registration.   
                    


                    

                    
The general pattern is the RP discovers the
                      capabilities of the AS authentication methods and
                      algorithms supported by the AS.  

                    
The client then picks the best options for it
                      and registers them.

                    


                    

                    
It would in theory work of the client knowing
                      nothing about the AS pushed it's capabilities at
                      the AS as you are suggesting and let the AS pick.

                    


                    

                    
My general feeling is that discovery with the
                      client picking the options works best.

                    


                    

                    
In many cases the client doesn't need to
                      register parameters as they can be selected at run
                      time once it knows what a server supports.  

                    
The token endpoint authentication method was a
                      bit of a special case where even though it could
                      be all dynamic and work, you do want to register a
                      choice to prevent backwards compatibility attacks.

                    


                    

                    
I don't really want to complicate registration
                      by trying to make it also cover AS discovery.

                    


                    

                    
John B.

                    


                      

                        
On 2013-04-24, at 7:55 PM, Phil Hunt <phil.hunt@oracle.com>

                          wrote:

                        

                        

                          
Right
                            and if the client wants a method not
                            supported then what?
                            


                            

                            
Why can't the client offer up a list of
                              methods it is able to support, say in
                              order of preference?

                            


                            

                            
The text appears to indicate only one
                              value may be passed.

                            


                            

                            
Given the way it is written. It seems
                              better to just have the server say the
                              client must do authn method X in the
                              response.

                            


                              
                              

                              

                                
On 2013-04-24, at 3:41 PM, John
                                  Bradley wrote:

                                

                                

                                  
In Connect the
                                    AS may support a number of token
                                    endpoint authentication methods.  
                                    The reason to allow a client to
                                    register using a particular one is
                                    to prevent downgrade attacks.
                                    


                                    

                                    
If the client wants to always
                                      use an asymmetric signature you
                                      don't want to allow attackers to
                                      use weaker methods like http
                                      basic.

                                    


                                    

                                    
So a server may support any
                                      number of methods, but it is
                                      reasonable for a client to specify
                                      which one it is going to use.   In
                                      a closed system that may not be
                                      that useful but in a open system
                                      where the AS has a looser
                                      relationship to the client it is
                                      important.

                                    


                                    

                                    
John B.

                                    


                                    

                                    

                                      

                                        
On 2013-04-24, at 7:30 PM,
                                          Phil Hunt <phil.hunt@oracle.com>

                                          wrote:

                                        

                                        

                                          
Hmmm…
                                            what was the objective or
                                            use case for having the
                                            client being able to choose
                                            in the first place?
                                            


                                            

                                            
It seems to me that the
                                              AS will make a decision
                                              based on many factors. As
                                              you say, there isn't any
                                              other place that
                                              enumerates the various
                                              [authn] methods a client
                                              can use to access the
                                              token endpoint.  So, why
                                              do it?

                                            


                                            

                                            

                                              
                                              

                                              

                                                
On 2013-04-24, at
                                                  2:07 PM, Justin Richer
                                                  wrote:

                                                

                                                

                                                  

                                                    Seems reasonable to
                                                    me, can you suggest
                                                    language to add in
                                                    the capability?
                                                    Would it require an
                                                    IANA registry? Right
                                                    now there isn't any
                                                    other place that
                                                    enumerates the
                                                    various methods that
                                                    a client can use to
                                                    access the token
                                                    endpoint.

                                                    

                                                     -- Justin

                                                    

                                                    
On

                                                      04/24/2013 04:17
                                                      PM, Phil Hunt
                                                      wrote:

                                                    

                                                    

                                                      
For
                                                        parameters to token_endpoint_auth_method,

                                                        the spec
                                                        has defined
                                                        "client_secret_jwt"
                                                        and
                                                        "private_key_jwt".
                                                        Shouldn't there
                                                        be similar
                                                        options of SAML?

                                                      


                                                      

                                                      
Shouldn't
                                                        there be an
                                                        extension point
                                                        for other
                                                        methods?

                                                      


                                                      

                                                      
                                                      

                                                      

                                                      

                                                      

                                                      
_______________________________________________
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

                                        

                                      

                                      

                                    

                                  

                                

                              

                              

                            

                          

                        

                      

                      

                    

                  

                  

                

              

            

            

          

        

      

    

    

  


--------------040406090000080009010204--

From phil.hunt@oracle.com  Thu Apr 25 10:09:59 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 536D221F9687 for ; Thu, 25 Apr 2013 10:09:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.365
X-Spam-Level: 
X-Spam-Status: No, score=-6.365 tagged_above=-999 required=5 tests=[AWL=0.233,  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 s0D1rXqWkGXw for ; Thu, 25 Apr 2013 10:09:57 -0700 (PDT)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 45D7621F967D for ; Thu, 25 Apr 2013 10:09:57 -0700 (PDT)
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r3PH9tZ4018303 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 25 Apr 2013 17:09:56 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r3PH9si5016455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 25 Apr 2013 17:09:54 GMT
Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r3PH9rfs008756; Thu, 25 Apr 2013 17:09:53 GMT
Received: from [192.168.1.14] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 25 Apr 2013 10:09:52 -0700
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: multipart/alternative; boundary="Apple-Mail=_8C540E0D-2817-4915-B3DA-6C858840CF6D"
From: Phil Hunt 
In-Reply-To: <51795B41.9010401@mitre.org>
Date: Thu, 25 Apr 2013 10:09:51 -0700
Message-Id: <13E6BE89-29CE-4A97-B0B0-FC90EF2A5045@oracle.com>
References: <53250C00-9D1C-4E81-9AD6-E12241B875D9@oracle.com> <5178498B.3050406@mitre.org> <0E96125F-CFEC-4157-8A1E-3CFCA1C4D79F@oracle.com> <0C683171-29F6-47EA-A611-AB6394207353@ve7jtb.com>  <629E4582-16C4-4554-9591-39E6801FA0A8@ve7jtb.com> <51793297.4020102@mitre.org> <870ADA58-1706-40CD-97AC-A357CE1D6094@ve7jtb.com> <5B4EA19E-AA21-4EF1-962C-D2F028748CE1@oracle.com> <51795B41.9010401@mitre.org>
To: Justin Richer 
X-Mailer: Apple Mail (2.1283)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] Questions on draft-ietf-oauth-dyn-reg-09 - token_endpoint_auth_method
X-BeenThere: oauth@ietf.org
X-Mailman-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, 25 Apr 2013 17:09:59 -0000

--Apple-Mail=_8C540E0D-2817-4915-B3DA-6C858840CF6D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

If the server is free to ignore, doesn't that mean the client ends up =
having to implement *ALL* methods anyway? In the case of Connect, the =
client has to implement all methods supported by Connect because it =
*could* be forced by any particular deployer to use a particular method.

The dynamic draft + unspecified discovery doesn't (as described) doesn't =
make clients or servers actually easier to implement.  Any client not =
implementing all methods runs the risk of sooner or later not being =
compatible.

I agree there is a need for registration to convey to the client what =
authentication method and client credential it has been issued.

Phil

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





On 2013-04-25, at 9:35 AM, Justin Richer wrote:

>=20
> On 04/25/2013 12:23 PM, Phil Hunt wrote:
>> I am not sure what to think about this.=20
>>=20
>> 1. I don't want this spec to be incomplete because there is another =
external spec published for a specific purpose.=20
> If we needed a registry we could define it in this spec. If we chose a =
non-registry method (like how grant_type uses URIs) then it's =
self-contained. I prefer the latter, myself.
>=20
>> 2. In general i would like to avoid negotiations. It seems to me that =
any developer making a client for a mutli-site deployed service would =
already be aware of what the generic service require and implement based =
on that oob knowledge. Thus when the server merely informs, the client =
should be prepared.=20
> The client already has to be prepared because the server will inform, =
though. But by making it bidirectional (like all the other parameters) =
it gives the client a chance to ask based on whatever information it =
wants to. The server is perfectly free to ignore what the client asks =
for and just hand it something, just as it's free to     do so for all =
fields.=20

>=20
>> IMHO, though i understand the motivation, negotiation of client auth =
creates more problems then it seems to solve in this case. Downgrade =
attack is just one of the problems.
> The parameters of the negotiation are going to be application-protocol =
specific and depend on things like a Discovery layer for them to be =
fully dynamic from a cold boot. And even then servers and clients that =
care about this value are going to have to know how to enforce it (it's =
the same as it is with grant_type, response_type, scope, and others).=20
>=20
> If nothing else, it lets servers tell clients which auth method to use =
at the token endpoint. The client can be smart and try to figure out if =
it actually supports that method before trying it, or it can be dumb and =
ignore the returned value. But with this parameter in the protocol, both =
sides at least have a *chance* of doing the right thing.
>=20
>  -- Justin
>=20
>>=20
>> Phil
>>=20
>> On 2013-04-25, at 7:21, John Bradley  wrote:
>>=20
>>> I am OK with having a registry,  Connect profiles the jwt assertions =
draft to add specifics around keying material for interoperability. =20
>>> It may well be that people will want other methods including SAML =
assertions.
>>>=20
>>> While sending a list of methods the client supports to the server =
and getting back what is supported by the server works, it is awkward.
>>>=20
>>> My point is mostly that there are lots of other parameters that are =
set only by the server.  I don't know if we want to start adding them to =
registration just to allow for them to be discovered.   Using a simple =
.well-known discovery document seems simpler.
>>>=20
>>> So making token_endpoint_auth_method an array is not the end of the =
world and would work, but heads us in what I think is the wrong =
direction.
>>>=20
>>> John B.
>>>=20
>>> On 2013-04-25, at 10:41 AM, Justin Richer  wrote:
>>>=20
>>>> John, I don't think that anybody's actually suggesting that we add =
server discovery in here. :) But since the server does echo back the =
configuration in its response, the client is discovering a few things at =
run time about what it can and can't do with a particular server. It's =
entirely possible that the client might get back a configuration option =
that it can't use (say, it can't do client_secret_jwt assertions but it =
can do=20
>>>>=20
>>>> =46rom what I can see from this thread though there are two open =
questions that Phil's raised:
>>>>=20
>>>>=20
>>>>  1: Extensibility of token_endpoint_auth_method values, and where =
potential values are listed (IANA? fully qualified URIs for things not =
in the base spec?)
>>>>=20
>>>>  2: Plurality of token_endpoint_auth_method (could be left as a =
string, made an array, or be a JSON-style optional plural: string value =
if singular or array if plural)
>>>>=20
>>>>=20
>>>>=20
>>>> I think the first one should be addressed, but we just need to pick =
the method. I'm personally in favor of the same method we used for =
grant_type, which is short values in the spec and extensions as fully =
qualified URIs. The second one could break existing implementations (and =
other dependent specs), so if we                   change it, it has to =
be for very good reason.
>>>>=20
>>>>  -- Justin
>>>>=20
>>>> On 04/24/2013 07:23 PM, John Bradley wrote:
>>>>> In Connect there is a AS discovery before registration.  =20
>>>>>=20
>>>>> The general pattern is the RP discovers the capabilities of the AS =
authentication methods and algorithms supported by the AS. =20
>>>>> The client then picks the best options for it and registers them.
>>>>>=20
>>>>> It would in theory work of the client knowing nothing about the AS =
pushed it's capabilities at the AS as you are suggesting and let the AS =
pick.
>>>>>=20
>>>>> My general feeling is that discovery with the client picking the =
options works best.
>>>>>=20
>>>>> In many cases the client doesn't need to register parameters as =
they can be selected at run time once it knows what a server supports. =20=

>>>>> The token endpoint authentication method was a bit of a special =
case where even though it could be all dynamic and work, you do want to =
register a choice to prevent backwards compatibility attacks.
>>>>>=20
>>>>> I don't really want to complicate registration by trying to make =
it also cover AS discovery.
>>>>>=20
>>>>> John B.
>>>>>=20
>>>>> On 2013-04-24, at 7:55 PM, Phil Hunt  wrote:
>>>>>=20
>>>>>> Right and if the client wants a method not supported then what?
>>>>>>=20
>>>>>> Why can't the client offer up a list of methods it is able to =
support, say in order of preference?
>>>>>>=20
>>>>>> The text appears to indicate only one value may be passed.
>>>>>>=20
>>>>>> Given the way it is written. It seems better to just have the =
server say the client must do authn method X in the response.
>>>>>>=20
>>>>>> Phil
>>>>>>=20
>>>>>> @independentid
>>>>>> www.independentid.com
>>>>>> phil.hunt@oracle.com
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> On 2013-04-24, at 3:41 PM, John Bradley wrote:
>>>>>>=20
>>>>>>> In Connect the AS may support a number of token endpoint =
authentication methods.   The reason to allow a client to register using =
a particular one is to prevent downgrade attacks.
>>>>>>>=20
>>>>>>> If the client wants to always use an asymmetric signature you =
don't want to allow attackers to use weaker methods like http basic.
>>>>>>>=20
>>>>>>> So a server may support any number of methods, but it is =
reasonable for a client to specify which one it is going to use.   In a =
closed system that may not be that useful but in a open system where the =
AS has a looser relationship to the client it is important.
>>>>>>>=20
>>>>>>> John B.
>>>>>>>=20
>>>>>>> On 2013-04-24, at 7:30 PM, Phil Hunt  =
wrote:
>>>>>>>=20
>>>>>>>> Hmmm=85 what was the objective or use case for having the =
client being able to choose in the first place?
>>>>>>>>=20
>>>>>>>> It seems to me that the AS will make a decision based on many =
factors. As you say, there isn't any other place that enumerates the =
various [authn] methods a client can use to access the token endpoint.  =
So, why do it?
>>>>>>>>=20
>>>>>>>> Phil
>>>>>>>>=20
>>>>>>>> @independentid
>>>>>>>> www.independentid.com
>>>>>>>> phil.hunt@oracle.com
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> On 2013-04-24, at 2:07 PM, Justin Richer wrote:
>>>>>>>>=20
>>>>>>>>> Seems reasonable to me, can you suggest language to add in the =
capability? Would it require an IANA registry? Right now there isn't any =
other place that enumerates the various methods that a client can use to =
access the token endpoint.
>>>>>>>>>=20
>>>>>>>>>  -- Justin
>>>>>>>>>=20
>>>>>>>>> On 04/24/2013 04:17 PM, Phil Hunt wrote:
>>>>>>>>>> For parameters to token_endpoint_auth_method,
>>>>>>>>>>=20
>>>>>>>>>>                                                         the =
spec has defined "client_secret_jwt" and "private_key_jwt". Shouldn't =
there be similar options of SAML?
>>>>>>>>>>=20
>>>>>>>>>> Shouldn't there be an extension point for other methods?
>>>>>>>>>>=20
>>>>>>>>>> Phil
>>>>>>>>>>=20
>>>>>>>>>> @independentid
>>>>>>>>>> www.independentid.com
>>>>>>>>>> phil.hunt@oracle.com
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>> _______________________________________________
>>>>>>>>>> OAuth mailing list
>>>>>>>>>> OAuth@ietf.org
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> _______________________________________________
>>>>>>>> OAuth mailing list
>>>>>>>> OAuth@ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>=20
>>>>>>=20
>>>>>=20
>>>>=20
>>>=20
>=20


--Apple-Mail=_8C540E0D-2817-4915-B3DA-6C858840CF6D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252




On 2013-04-25, at 9:35 AM, Justin Richer wrote:


 =20
    
 =20
  

    

    
On 04/25/2013 12:23 PM, Phil Hunt
      wrote:

    

    

      
      
I am not sure what to think about this. 

      


      

      
1. I don't want this spec to be incomplete because there is
        another external spec published for a specific purpose. 

      

    

    If we needed a registry we could define it in this spec. If we chose
    a non-registry method (like how grant_type uses URIs) then it's
    self-contained. I prefer the latter, myself.

    

    

      
2. In general i would like to avoid negotiations. It seems to
        me that any developer making a client for a mutli-site deployed
        service would already be aware of what the generic service
        require and implement based on that oob knowledge. Thus when the
        server merely informs, the client should be prepared. 

      

    

    The client already has to be prepared because the server will
    inform, though. But by making it bidirectional (like all the other
    parameters) it gives the client a chance to ask based on whatever
    information it wants to. The server is perfectly free to ignore what
    the client asks for and just hand it something, just as it's free to
    do so for all fields. 


    

      
IMHO, though i understand the motivation, negotiation of
        client auth creates more problems then it seems to solve in this
        case. Downgrade attack is just one of the problems.

      

    

    The parameters of the negotiation are going to be
    application-protocol specific and depend on things like a Discovery
    layer for them to be fully dynamic from a cold boot. And even then
    servers and clients that care about this value are going to have to
    know how to enforce it (it's the same as it is with grant_type,
    response_type, scope, and others). 

    

    If nothing else, it lets servers tell clients which auth method to
    use at the token endpoint. The client can be smart and try to figure
    out if it actually supports that method before trying it, or it can
    be dumb and ignore the returned value. But with this parameter in
    the protocol, both sides at least have a *chance* of doing the right
    thing.

    

     -- Justin

    

    

      


        Phil

      


        On 2013-04-25, at 7:21, John Bradley <ve7jtb@ve7jtb.com>
        wrote:

        

      

      

        
I am OK with having a registry,  Connect profiles the =
jwt
          assertions draft to add specifics around keying material for
          interoperability.  
          
It may well be that people will want other methods
            including SAML assertions.

          


          

          
While sending a list of methods the client supports to
            the server and getting back what is supported by the server
            works, it is awkward.

          


          

          
My point is mostly that there are lots of other
            parameters that are set only by the server.  I don't =
know if
            we want to start adding them to registration just to allow
            for them to be discovered.   Using a simple .well-known
            discovery document seems simpler.

          


          

          
So making token_endpoint_auth_method an array is not =
the
            end of the world and would work, but heads us in what I
            think is the wrong direction.

          


          

          
John B.

          


          

          

            

              
On 2013-04-25, at 10:41 AM, Justin Richer <jricher@mitre.org>
                wrote:

              

              

                
 John, I don't
                  think that anybody's actually suggesting that we add
                  server discovery in here. :) But since the server does
                  echo back the configuration in its response, the
                  client is discovering a few things at run time about
                  what it can and can't do with a particular server.
                  It's entirely possible that the client might get back
                  a configuration option that it can't use (say, it
                  can't do client_secret_jwt assertions but it can do =


                  

                  =46rom what I can see from this thread though there =
are
                  two open questions that Phil's raised:

                  

                  

                   1: Extensibility of token_endpoint_auth_method
                  values, and where potential values are listed (IANA?
                  fully qualified URIs for things not in the base =
spec?)

                  

                   2: Plurality of token_endpoint_auth_method =
(could be
                  left as a string, made an array, or be a JSON-style
                  optional plural: string value if singular or array if
                  plural)

                  

                  

                  

                  I think the first one should be addressed, but we just
                  need to pick the method. I'm personally in favor of
                  the same method we used for grant_type, which is short
                  values in the spec and extensions as fully qualified
                  URIs. The second one could break existing
                  implementations (and other dependent specs), so if we
                  change it, it has to be for very good reason.

                  

                   -- Justin

                  

                  
On 04/24/2013 07:23 PM,
                    John Bradley wrote:

                  

                  
 In Connect there is a AS discovery
                    before registration.   
                    


                    

                    
The general pattern is the RP discovers the
                      capabilities of the AS authentication methods and
                      algorithms supported by the AS.  

                    
The client then picks the best options for it
                      and registers them.

                    


                    

                    
It would in theory work of the client knowing
                      nothing about the AS pushed it's capabilities at
                      the AS as you are suggesting and let the AS =
pick.

                    


                    

                    
My general feeling is that discovery with the
                      client picking the options works best.

                    


                    

                    
In many cases the client doesn't need to
                      register parameters as they can be selected at run
                      time once it knows what a server supports. =
 

                    
The token endpoint authentication method was a
                      bit of a special case where even though it could
                      be all dynamic and work, you do want to register a
                      choice to prevent backwards compatibility =
attacks.

                    


                    

                    
I don't really want to complicate registration
                      by trying to make it also cover AS =
discovery.

                    


                    

                    
John B.

                    


                      

                        
On 2013-04-24, at 7:55 PM, Phil Hunt <phil.hunt@oracle.com>

                          wrote:

                        

                        

                          
                              

                              

                                
On 2013-04-24, at 3:41 PM, John
                                  Bradley wrote:

                                

                                

                                  
In Connect the
                                    AS may support a number of token
                                    endpoint authentication methods. =
 
                                    The reason to allow a client to
                                    register using a particular one is
                                    to prevent downgrade attacks.
                                    


                                    

                                    
If the client wants to always
                                      use an asymmetric signature you
                                      don't want to allow attackers to
                                      use weaker methods like http
                                      basic.

                                    


                                    

                                    
So a server may support any
                                      number of methods, but it is
                                      reasonable for a client to specify
                                      which one it is going to use. =
  In
                                      a closed system that may not be
                                      that useful but in a open system
                                      where the AS has a looser
                                      relationship to the client it is
                                      important.

                                    


                                    

                                    
John B.

                                    


                                    

                                    

                                      

                                        
On 2013-04-24, at 7:30 PM,
                                          Phil Hunt <phil.hunt@oracle.com>

                                          wrote:

                                        

                                        

                                          
Hmmm=85
                                            what was the objective or
                                            use case for having the
                                            client being able to choose
                                            in the first place?
                                            


                                            

                                            
It seems to me that the
                                              AS will make a decision
                                              based on many factors. As
                                              you say, there isn't any
                                              other place that
                                              enumerates the various
                                              [authn] methods a client
                                              can use to access the
                                              token endpoint.  So, =
why
                                              do it?

                                            


                                            

                                            

                                              
                                              

                                              

                                                
On 2013-04-24, at
                                                  2:07 PM, Justin Richer
                                                  wrote:

                                                

                                                
=

                                                  

                                                    Seems reasonable to
                                                    me, can you suggest
                                                    language to add in
                                                    the capability?
                                                    Would it require an
                                                    IANA registry? Right
                                                    now there isn't any
                                                    other place that
                                                    enumerates the
                                                    various methods that
                                                    a client can use to
                                                    access the token
                                                    endpoint.

                                                    

                                                     -- Justin

                                                    

                                                    
On

                                                      04/24/2013 04:17
                                                      PM, Phil Hunt
                                                      wrote:

                                                    

                                                    

                                                      
For
                                                        parameters =
to 
                                                      


                                                      

                                                      
Shouldn't
                                                        there be an
                                                        extension point
                                                        for other
                                                        methods?

                                                      


                                                      

                                                      
                                                      

                                                      

                                                      

                                                      

                                                      
_______________________________________________
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=_8C540E0D-2817-4915-B3DA-6C858840CF6D--

From jricher@mitre.org  Thu Apr 25 10:21:47 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AEA521F9633 for ; Thu, 25 Apr 2013 10:21:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qyQIxSpJL0jj for ; Thu, 25 Apr 2013 10:21:45 -0700 (PDT)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 720C021F9619 for ; Thu, 25 Apr 2013 10:21:44 -0700 (PDT)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 0D58B1F0259; Thu, 25 Apr 2013 13:21:44 -0400 (EDT)
Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id E88F322600AB; Thu, 25 Apr 2013 13:21:43 -0400 (EDT)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.2.342.3; Thu, 25 Apr 2013 13:21:43 -0400
Message-ID: <51796613.7000700@mitre.org>
Date: Thu, 25 Apr 2013 13:21:23 -0400
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130329 Thunderbird/17.0.5
MIME-Version: 1.0
To: Phil Hunt 
References: <53250C00-9D1C-4E81-9AD6-E12241B875D9@oracle.com> <5178498B.3050406@mitre.org> <0E96125F-CFEC-4157-8A1E-3CFCA1C4D79F@oracle.com> <0C683171-29F6-47EA-A611-AB6394207353@ve7jtb.com>  <629E4582-16C4-4554-9591-39E6801FA0A8@ve7jtb.com> <51793297.4020102@mitre.org> <870ADA58-1706-40CD-97AC-A357CE1D6094@ve7jtb.com> <5B4EA19E-AA21-4EF1-962C-D2F028748CE1@oracle.com> <51795B41.9010401@mitre.org> <13E6BE89-29CE-4A97-B0B0-FC90EF2A5045@oracle.com>
In-Reply-To: <13E6BE89-29CE-4A97-B0B0-FC90EF2A5045@oracle.com>
Content-Type: multipart/alternative; boundary="------------050709010303080103060706"
X-Originating-IP: [129.83.31.58]
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] Questions on draft-ietf-oauth-dyn-reg-09 - token_endpoint_auth_method
X-BeenThere: oauth@ietf.org
X-Mailman-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, 25 Apr 2013 17:21:47 -0000

--------------050709010303080103060706
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 8bit

If you want your client app to be able to speak to all servers, yes, 
you'll have to implement all methods. But even this is a problem because 
servers can come up with a new method -- that's the whole point of 
making this field extensible, isn't it? And again, you could make the 
same argument about grant_type and several other fields. Say you've got 
a client that only does authorization_code, but the server sends back 
"implicit" to the client. Will they be able to speak? No, and if the 
client application or library wants to be able to speak to this server 
it's going to have to implement the implicit flow to do so.

So I think that your concern here, while definitely valid, is a bit 
misleading. I don't think it's OAuth Dyn Reg's goal to solve the 
complete cold-boot problem across all possible combinations of clients 
and servers, since a client application is going to need to be able to 
speak whatever protocol OAuth is protecting anyway in order to do 
anything past the authorization step. However, I do think it makes 
perfect sense for a client library to be able to say "here's the value 
that I want" and have the server say "here's the value that you get" in 
a means that's parallel across all of these fields.

  -- Justin

On 04/25/2013 01:09 PM, Phil Hunt wrote:
> If the server is free to ignore, doesn't that mean the client ends up 
> having to implement *ALL* methods anyway? In the case of Connect, the 
> client has to implement all methods supported by Connect because it 
> *could* be forced by any particular deployer to use a particular method.
>
> The dynamic draft + unspecified discovery doesn't (as described) 
> doesn't make clients or servers actually easier to implement.  Any 
> client not implementing all methods runs the risk of sooner or later 
> not being compatible.
>
> I agree there is a need for registration to convey to the client what 
> authentication method and client credential it has been issued.
>
> Phil
>
> @independentid
> www.independentid.com 
> phil.hunt@oracle.com 
>
>
>
>
>
> On 2013-04-25, at 9:35 AM, Justin Richer wrote:
>
>>
>> On 04/25/2013 12:23 PM, Phil Hunt wrote:
>>> I am not sure what to think about this.
>>>
>>> 1. I don't want this spec to be incomplete because there is another 
>>> external spec published for a specific purpose.
>> If we needed a registry we could define it in this spec. If we chose 
>> a non-registry method (like how grant_type uses URIs) then it's 
>> self-contained. I prefer the latter, myself.
>>
>>> 2. In general i would like to avoid negotiations. It seems to me 
>>> that any developer making a client for a mutli-site deployed service 
>>> would already be aware of what the generic service require and 
>>> implement based on that oob knowledge. Thus when the server merely 
>>> informs, the client should be prepared.
>> The client already has to be prepared because the server will inform, 
>> though. But by making it bidirectional (like all the other 
>> parameters) it gives the client a chance to ask based on whatever 
>> information it wants to. The server is perfectly free to ignore what 
>> the client asks for and just hand it something, just as it's free to 
>> do so for all fields.
>>
>>> IMHO, though i understand the motivation, negotiation of client auth 
>>> creates more problems then it seems to solve in this case. Downgrade 
>>> attack is just one of the problems.
>> The parameters of the negotiation are going to be 
>> application-protocol specific and depend on things like a Discovery 
>> layer for them to be fully dynamic from a cold boot. And even then 
>> servers and clients that care about this value are going to have to 
>> know how to enforce it (it's the same as it is with grant_type, 
>> response_type, scope, and others).
>>
>> If nothing else, it lets servers tell clients which auth method to 
>> use at the token endpoint. The client can be smart and try to figure 
>> out if it actually supports that method before trying it, or it can 
>> be dumb and ignore the returned value. But with this parameter in the 
>> protocol, both sides at least have a *chance* of doing the right thing.
>>
>>  -- Justin
>>
>>>
>>> Phil
>>>
>>> On 2013-04-25, at 7:21, John Bradley >> > wrote:
>>>
>>>> I am OK with having a registry,  Connect profiles the jwt 
>>>> assertions draft to add specifics around keying material for 
>>>> interoperability.
>>>> It may well be that people will want other methods including SAML 
>>>> assertions.
>>>>
>>>> While sending a list of methods the client supports to the server 
>>>> and getting back what is supported by the server works, it is awkward.
>>>>
>>>> My point is mostly that there are lots of other parameters that are 
>>>> set only by the server.  I don't know if we want to start adding 
>>>> them to registration just to allow for them to be discovered.   
>>>> Using a simple .well-known discovery document seems simpler.
>>>>
>>>> So making token_endpoint_auth_method an array is not the end of the 
>>>> world and would work, but heads us in what I think is the wrong 
>>>> direction.
>>>>
>>>> John B.
>>>>
>>>> On 2013-04-25, at 10:41 AM, Justin Richer >>> > wrote:
>>>>
>>>>> John, I don't think that anybody's actually suggesting that we add 
>>>>> server discovery in here. :) But since the server does echo back 
>>>>> the configuration in its response, the client is discovering a few 
>>>>> things at run time about what it can and can't do with a 
>>>>> particular server. It's entirely possible that the client might 
>>>>> get back a configuration option that it can't use (say, it can't 
>>>>> do client_secret_jwt assertions but it can do
>>>>>
>>>>> From what I can see from this thread though there are two open 
>>>>> questions that Phil's raised:
>>>>>
>>>>>
>>>>>  1: Extensibility of token_endpoint_auth_method values, and where 
>>>>> potential values are listed (IANA? fully qualified URIs for things 
>>>>> not in the base spec?)
>>>>>
>>>>>  2: Plurality of token_endpoint_auth_method (could be left as a 
>>>>> string, made an array, or be a JSON-style optional plural: string 
>>>>> value if singular or array if plural)
>>>>>
>>>>>
>>>>>
>>>>> I think the first one should be addressed, but we just need to 
>>>>> pick the method. I'm personally in favor of the same method we 
>>>>> used for grant_type, which is short values in the spec and 
>>>>> extensions as fully qualified URIs. The second one could break 
>>>>> existing implementations (and other dependent specs), so if we 
>>>>> change it, it has to be for very good reason.
>>>>>
>>>>>  -- Justin
>>>>>
>>>>> On 04/24/2013 07:23 PM, John Bradley wrote:
>>>>>> In Connect there is a AS discovery before registration.
>>>>>>
>>>>>> The general pattern is the RP discovers the capabilities of the 
>>>>>> AS authentication methods and algorithms supported by the AS.
>>>>>> The client then picks the best options for it and registers them.
>>>>>>
>>>>>> It would in theory work of the client knowing nothing about the 
>>>>>> AS pushed it's capabilities at the AS as you are suggesting and 
>>>>>> let the AS pick.
>>>>>>
>>>>>> My general feeling is that discovery with the client picking the 
>>>>>> options works best.
>>>>>>
>>>>>> In many cases the client doesn't need to register parameters as 
>>>>>> they can be selected at run time once it knows what a server 
>>>>>> supports.
>>>>>> The token endpoint authentication method was a bit of a special 
>>>>>> case where even though it could be all dynamic and work, you do 
>>>>>> want to register a choice to prevent backwards compatibility attacks.
>>>>>>
>>>>>> I don't really want to complicate registration by trying to make 
>>>>>> it also cover AS discovery.
>>>>>>
>>>>>> John B.
>>>>>>
>>>>>> On 2013-04-24, at 7:55 PM, Phil Hunt >>>>> > wrote:
>>>>>>
>>>>>>> Right and if the client wants a method not supported then what?
>>>>>>>
>>>>>>> Why can't the client offer up a list of methods it is able to 
>>>>>>> support, say in order of preference?
>>>>>>>
>>>>>>> The text appears to indicate only one value may be passed.
>>>>>>>
>>>>>>> Given the way it is written. It seems better to just have the 
>>>>>>> server say the client must do authn method X in the response.
>>>>>>>
>>>>>>> Phil
>>>>>>>
>>>>>>> @independentid
>>>>>>> www.independentid.com 
>>>>>>> phil.hunt@oracle.com 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 2013-04-24, at 3:41 PM, John Bradley wrote:
>>>>>>>
>>>>>>>> In Connect the AS may support a number of token endpoint 
>>>>>>>> authentication methods. The reason to allow a client to 
>>>>>>>> register using a particular one is to prevent downgrade attacks.
>>>>>>>>
>>>>>>>> If the client wants to always use an asymmetric signature you 
>>>>>>>> don't want to allow attackers to use weaker methods like http 
>>>>>>>> basic.
>>>>>>>>
>>>>>>>> So a server may support any number of methods, but it is 
>>>>>>>> reasonable for a client to specify which one it is going to 
>>>>>>>> use. In a closed system that may not be that useful but in a 
>>>>>>>> open system where the AS has a looser relationship to the 
>>>>>>>> client it is important.
>>>>>>>>
>>>>>>>> John B.
>>>>>>>>
>>>>>>>> On 2013-04-24, at 7:30 PM, Phil Hunt >>>>>>> > wrote:
>>>>>>>>
>>>>>>>>> Hmmm… what was the objective or use case for having the client 
>>>>>>>>> being able to choose in the first place?
>>>>>>>>>
>>>>>>>>> It seems to me that the AS will make a decision based on many 
>>>>>>>>> factors. As you say, there isn't any other place that 
>>>>>>>>> enumerates the various [authn] methods a client can use to 
>>>>>>>>> access the token endpoint.  So, why do it?
>>>>>>>>>
>>>>>>>>> Phil
>>>>>>>>>
>>>>>>>>> @independentid
>>>>>>>>> www.independentid.com 
>>>>>>>>> phil.hunt@oracle.com 
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 2013-04-24, at 2:07 PM, Justin Richer wrote:
>>>>>>>>>
>>>>>>>>>> Seems reasonable to me, can you suggest language to add in 
>>>>>>>>>> the capability? Would it require an IANA registry? Right now 
>>>>>>>>>> there isn't any other place that enumerates the various 
>>>>>>>>>> methods that a client can use to access the token endpoint.
>>>>>>>>>>
>>>>>>>>>>  -- Justin
>>>>>>>>>>
>>>>>>>>>> On 04/24/2013 04:17 PM, Phil Hunt wrote:
>>>>>>>>>>> For parameters to token_endpoint_auth_method, the spec has 
>>>>>>>>>>> defined "client_secret_jwt" and "private_key_jwt". Shouldn't 
>>>>>>>>>>> there be similar options of SAML?
>>>>>>>>>>>
>>>>>>>>>>> Shouldn't there be an extension point for other methods?
>>>>>>>>>>>
>>>>>>>>>>> Phil
>>>>>>>>>>>
>>>>>>>>>>> @independentid
>>>>>>>>>>> www.independentid.com 
>>>>>>>>>>> phil.hunt@oracle.com 
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> OAuth mailing list
>>>>>>>>>>> OAuth@ietf.org
>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> OAuth mailing list
>>>>>>>>> OAuth@ietf.org 
>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>
>


--------------050709010303080103060706
Content-Type: text/html; charset="windows-1252"
Content-Transfer-Encoding: 8bit


  
    
  
  
    If you want your client app to be able to speak to all servers, yes,
    you'll have to implement all methods. But even this is a problem
    because servers can come up with a new method -- that's the whole
    point of making this field extensible, isn't it? And again, you
    could make the same argument about grant_type and several other
    fields. Say you've got a client that only does authorization_code,
    but the server sends back "implicit" to the client. Will they be
    able to speak? No, and if the client application or library wants to
    be able to speak to this server it's going to have to implement the
    implicit flow to do so. 

    

    So I think that your concern here, while definitely valid, is a bit
    misleading. I don't think it's OAuth Dyn Reg's goal to solve the
    complete cold-boot problem across all possible combinations of
    clients and servers, since a client application is going to need to
    be able to speak whatever protocol OAuth is protecting anyway in
    order to do anything past the authorization step. However, I do
    think it makes perfect sense for a client library to be able to say
    "here's the value that I want" and have the server say "here's the
    value that you get" in a means that's parallel across all of these
    fields.

    

     -- Justin

    

    
On 04/25/2013 01:09 PM, Phil Hunt
      wrote:

    

    

      
      
If the server is free to ignore, doesn't that mean the client
        ends up having to implement *ALL* methods anyway? In the case of
        Connect, the client has to implement all methods supported by
        Connect because it *could* be forced by any particular deployer
        to use a particular method.

      


      

      
The dynamic draft + unspecified discovery doesn't (as
        described) doesn't make clients or servers actually easier to
        implement.  Any client not implementing all methods runs the
        risk of sooner or later not being compatible.

      


      

      
I agree there is a need for registration to convey to the
        client what authentication method and client credential it has
        been issued.

      


      

      
Phil

      
      

      

        
On 2013-04-25, at 9:35 AM, Justin Richer wrote:

        

        

          
 

            
On 04/25/2013 12:23 PM, Phil
              Hunt wrote:

            

            

              
I am not sure what to think about this. 

              


              

              
1. I don't want this spec to be incomplete because
                there is another external spec published for a specific
                purpose. 

              

            

            If we needed a registry we could define it in this spec. If
            we chose a non-registry method (like how grant_type uses
            URIs) then it's self-contained. I prefer the latter, myself.

            

            

              
2. In general i would like to avoid negotiations. It
                seems to me that any developer making a client for a
                mutli-site deployed service would already be aware of
                what the generic service require and implement based on
                that oob knowledge. Thus when the server merely informs,
                the client should be prepared. 

              

            

            The client already has to be prepared because the server
            will inform, though. But by making it bidirectional (like
            all the other parameters) it gives the client a chance to
            ask based on whatever information it wants to. The server is
            perfectly free to ignore what the client asks for and just
            hand it something, just as it's free to do so for all
            fields. 

        

      

      

        

          


            

              
IMHO, though i understand the motivation, negotiation
                of client auth creates more problems then it seems to
                solve in this case. Downgrade attack is just one of the
                problems.

              

            

            The parameters of the negotiation are going to be
            application-protocol specific and depend on things like a
            Discovery layer for them to be fully dynamic from a cold
            boot. And even then servers and clients that care about this
            value are going to have to know how to enforce it (it's the
            same as it is with grant_type, response_type, scope, and
            others). 

            

            If nothing else, it lets servers tell clients which auth
            method to use at the token endpoint. The client can be smart
            and try to figure out if it actually supports that method
            before trying it, or it can be dumb and ignore the returned
            value. But with this parameter in the protocol, both sides
            at least have a *chance* of doing the right thing.

            

             -- Justin

            

            

              


                Phil

              


                On 2013-04-25, at 7:21, John Bradley <ve7jtb@ve7jtb.com>

                wrote:

                

              

              

                
I am OK with having a registry,  Connect profiles
                  the jwt assertions draft to add specifics around
                  keying material for interoperability.  
                  
It may well be that people will want other
                    methods including SAML assertions.

                  


                  

                  
While sending a list of methods the client
                    supports to the server and getting back what is
                    supported by the server works, it is awkward.

                  


                  

                  
My point is mostly that there are lots of other
                    parameters that are set only by the server.  I don't
                    know if we want to start adding them to registration
                    just to allow for them to be discovered.   Using a
                    simple .well-known discovery document seems simpler.

                  


                  

                  
So making token_endpoint_auth_method an array is
                    not the end of the world and would work, but heads
                    us in what I think is the wrong direction.

                  


                  

                  
John B.

                  


                  

                  

                    

                      
On 2013-04-25, at 10:41 AM, Justin Richer
                        <jricher@mitre.org>

                        wrote:

                      

                      

                        
 John, I
                          don't think that anybody's actually suggesting
                          that we add server discovery in here. :) But
                          since the server does echo back the
                          configuration in its response, the client is
                          discovering a few things at run time about
                          what it can and can't do with a particular
                          server. It's entirely possible that the client
                          might get back a configuration option that it
                          can't use (say, it can't do client_secret_jwt
                          assertions but it can do 

                          

                          From what I can see from this thread though
                          there are two open questions that Phil's
                          raised:

                          

                          

                           1: Extensibility of
                          token_endpoint_auth_method values, and where
                          potential values are listed (IANA? fully
                          qualified URIs for things not in the base
                          spec?)

                          

                           2: Plurality of token_endpoint_auth_method
                          (could be left as a string, made an array, or
                          be a JSON-style optional plural: string value
                          if singular or array if plural)

                          

                          

                          

                          I think the first one should be addressed, but
                          we just need to pick the method. I'm
                          personally in favor of the same method we used
                          for grant_type, which is short values in the
                          spec and extensions as fully qualified URIs.
                          The second one could break existing
                          implementations (and other dependent specs),
                          so if we change it, it has to be for very good
                          reason.

                          

                           -- Justin

                          

                          
On 04/24/2013
                            07:23 PM, John Bradley wrote:

                          

                          
 In Connect there is a AS
                            discovery before registration.   
                            


                            

                            
The general pattern is the RP discovers
                              the capabilities of the AS authentication
                              methods and algorithms supported by the
                              AS.  

                            
The client then picks the best options
                              for it and registers them.

                            


                            

                            
It would in theory work of the client
                              knowing nothing about the AS pushed it's
                              capabilities at the AS as you are
                              suggesting and let the AS pick.

                            


                            

                            
My general feeling is that discovery
                              with the client picking the options works
                              best.

                            


                            

                            
In many cases the client doesn't need
                              to register parameters as they can be
                              selected at run time once it knows what a
                              server supports.  

                            
The token endpoint authentication
                              method was a bit of a special case where
                              even though it could be all dynamic and
                              work, you do want to register a choice to
                              prevent backwards compatibility attacks.

                            


                            

                            
I don't really want to complicate
                              registration by trying to make it also
                              cover AS discovery.

                            


                            

                            
John B.

                            


                              

                                
On 2013-04-24, at 7:55 PM, Phil
                                  Hunt <phil.hunt@oracle.com>


                                  wrote:

                                

                                

                                  
Right and if
                                    the client wants a method not
                                    supported then what?
                                    


                                    

                                    
Why can't the client offer up a
                                      list of methods it is able to
                                      support, say in order of
                                      preference?

                                    


                                    

                                    
The text appears to indicate
                                      only one value may be passed.

                                    


                                    

                                    
Given the way it is written. It
                                      seems better to just have the
                                      server say the client must do
                                      authn method X in the response.

                                    


                                      
                                      

                                      

                                        
On 2013-04-24, at 3:41 PM,
                                          John Bradley wrote:

                                        

                                        

                                          
In
                                            Connect the AS may support a
                                            number of token endpoint
                                            authentication methods.  
                                            The reason to allow a client
                                            to register using a
                                            particular one is to prevent
                                            downgrade attacks.
                                            


                                            

                                            
If the client wants to
                                              always use an asymmetric
                                              signature you don't want
                                              to allow attackers to use
                                              weaker methods like http
                                              basic.

                                            


                                            

                                            
So a server may support
                                              any number of methods, but
                                              it is reasonable for a
                                              client to specify which
                                              one it is going to use.  
                                              In a closed system that
                                              may not be that useful but
                                              in a open system where the
                                              AS has a looser
                                              relationship to the client
                                              it is important.

                                            


                                            

                                            
John B.

                                            


                                            

                                            

                                              

                                                
On 2013-04-24, at
                                                  7:30 PM, Phil Hunt
                                                  <phil.hunt@oracle.com> wrote:

                                                

                                                

                                                  
Hmmm…

                                                    what was the
                                                    objective or use
                                                    case for having the
                                                    client being able to
                                                    choose in the first
                                                    place?
                                                    


                                                    

                                                    
It seems to me
                                                      that the AS will
                                                      make a decision
                                                      based on many
                                                      factors. As you
                                                      say, there isn't
                                                      any other place
                                                      that enumerates
                                                      the various
                                                      [authn] methods a
                                                      client can use to
                                                      access the token
                                                      endpoint.  So, why
                                                      do it?

                                                    


                                                    

                                                    

                                                      
                                                      

                                                      

                                                        
On
                                                          2013-04-24, at
                                                          2:07 PM,
                                                          Justin Richer
                                                          wrote:

                                                        

                                                        

                                                          

                                                          Seems
                                                          reasonable to
                                                          me, can you
                                                          suggest
                                                          language to
                                                          add in the
                                                          capability?
                                                          Would it
                                                          require an
                                                          IANA registry?
                                                          Right now
                                                          there isn't
                                                          any other
                                                          place that
                                                          enumerates the
                                                          various
                                                          methods that a
                                                          client can use
                                                          to access the
                                                          token
                                                          endpoint.

                                                          

                                                           -- Justin

                                                          

                                                          
On


                                                          04/24/2013
                                                          04:17 PM, Phil
                                                          Hunt wrote:

                                                          

                                                          

                                                          
For
                                                          parameters to token_endpoint_auth_method,


                                                          the
                                                          spec has
                                                          defined
                                                          "client_secret_jwt"
                                                          and
                                                          "private_key_jwt".
                                                          Shouldn't
                                                          there be
                                                          similar
                                                          options of
                                                          SAML?

                                                          


                                                          

                                                          
Shouldn't
                                                          there be an
                                                          extension
                                                          point for
                                                          other methods?

                                                          


                                                          

                                                          
                                                          

                                                          

                                                          

                                                          

                                                          
_______________________________________________
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

                                                

                                              

                                              

                                            

                                          

                                        

                                      

                                      

                                    

                                  

                                

                              

                              

                            

                          

                          

                        

                      

                    

                    

                  

                

              

            

            

          

        

      

      

    

    

  


--------------050709010303080103060706--

From johnsonhammond1@hushmail.com  Sat Apr 27 16:39:48 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4A4A21F99D5 for ; Sat, 27 Apr 2013 16:39:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.475
X-Spam-Level: 
X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124,  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 p0Ouh5bqBbna for ; Sat, 27 Apr 2013 16:39:48 -0700 (PDT)
Received: from smtp10.hushmail.com (smtp10a.hushmail.com [65.39.178.239]) by ietfa.amsl.com (Postfix) with ESMTP id 83D0D21F99AE for ; Sat, 27 Apr 2013 16:39:48 -0700 (PDT)
Received: from smtp10.hushmail.com (smtp10a.hushmail.com [65.39.178.239]) by smtp10.hushmail.com (Postfix) with SMTP id C46751B532F for ; Sat, 27 Apr 2013 17:33:21 +0000 (UTC)
X-hush-relay-time: 213
X-hush-relay-id: b1bd903faba185ee07e5a0ed3a1fde37
Received: from smtp.hushmail.com (w5.hushmail.com [65.39.178.80]) by smtp10.hushmail.com (Postfix) with ESMTP for ; Sat, 27 Apr 2013 17:33:21 +0000 (UTC)
Received: by smtp.hushmail.com (Postfix, from userid 99) id 94E9DE673F; Sat, 27 Apr 2013 17:33:21 +0000 (UTC)
MIME-Version: 1.0
Date: Sat, 27 Apr 2013 13:33:21 -0400
To: oauth@ietf.org
From: johnsonhammond1@hushmail.com
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20130427173321.94E9DE673F@smtp.hushmail.com>
Subject: [OAUTH-WG] Biggest Fake Conference in Computer Science
X-BeenThere: oauth@ietf.org
X-Mailman-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, 27 Apr 2013 23:39:48 -0000

Biggest Fake Conference in Computer Science


We are researchers from different parts of the world and conducted a study on  
the world’s biggest bogus computer science conference WORLDCOMP 
( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia 
from University of Georgia, USA.


We submitted a fake paper to WORLDCOMP 2011 and again (the same paper 
with a modified title) to WORLDCOMP 2012. This paper had numerous 
fundamental mistakes. Sample statements from that paper include: 

(1). Binary logic is fuzzy logic and vice versa
(2). Pascal developed fuzzy logic
(3). Object oriented languages do not exhibit any polymorphism or inheritance
(4). TCP and IP are synonyms and are part of OSI model 
(5). Distributed systems deal with only one computer
(6). Laptop is an example for a super computer
(7). Operating system is an example for computer hardware


Also, our paper did not express any conceptual meaning.  However, it 
was accepted both the times without any modifications (and without 
any reviews) and we were invited to submit the final paper and a 
payment of $500+ fee to present the paper. We decided to use the 
fee for better purposes than making Prof. Hamid Arabnia (Chairman 
of WORLDCOMP) rich. After that, we received few reminders from 
WORLDCOMP to pay the fee but we never responded. 


We MUST say that you should look at the above website if you have any thoughts 
to submit a paper to WORLDCOMP.  DBLP and other indexing agencies have stopped 
indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See 
http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the 
conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of
http://sites.google.com/site/dumpconf for comments from well-known researchers 
about WORLDCOMP. 


The status of your WORLDCOMP papers can be changed from scientific
to other (i.e., junk or non-technical) at any time. Better not to have a paper than 
having it in WORLDCOMP and spoil the resume and peace of mind forever!


Our study revealed that WORLDCOMP is a money making business, 
using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing 
out a small chunk of that money (around 20 dollars per paper published 
in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) 
who publicizes WORLDCOMP and also defends it at various forums, using 
fake/anonymous names. The puppet uses fake names and defames other conferences
to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to 
threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). 
That is, the puppet does all his best to get a maximum number of papers published 
at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. 


Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has 
refused to provide the venue for WORLDCOMP’13 because of the fears of their image 
being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 
is taking place at a different resort. WORLDCOMP will not be held after 2013. 


The draft paper submission deadline is over but still there are no committee 
members, no reviewers, and there is no conference Chairman. The only contact 
details available on WORLDCOMP’s website is just an email address! 

Let us make a direct request to Prof. Hamid arabnia: publish all reviews for 
all the papers (after blocking identifiable details) since 2000 conference. Reveal 
the names and affiliations of all the reviewers (for each year) and how many 
papers each reviewer had reviewed on average. We also request him to look at 
the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 


Sorry for posting to multiple lists. Spreading the word is the only way to stop 
this bogus conference. Please forward this message to other mailing lists and people. 


We are shocked with Prof. Hamid Arabnia and his puppet’s activities 
http://worldcomp-fake-bogus.blogspot.com   Search Google using the 
keyword worldcomp fake for additional links.


From bojanz@gmail.com  Sun Apr 28 08:22:51 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54D4021F9C5A for ; Sun, 28 Apr 2013 08:22:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level: 
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 ycC8AtO37jVt for ; Sun, 28 Apr 2013 08:22:50 -0700 (PDT)
Received: from mail-ia0-x22c.google.com (mail-ia0-x22c.google.com [IPv6:2607:f8b0:4001:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 8B95B21F9A38 for ; Sun, 28 Apr 2013 08:22:46 -0700 (PDT)
Received: by mail-ia0-f172.google.com with SMTP id i20so4988017ian.31 for ; Sun, 28 Apr 2013 08:22:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=+mXSyfjDS32t0q//X4mVuVbvW3/Qr7Nw7Fl5GFF/oBw=; b=lZyJ5Dh5ijlRo5+DxW+P0ABdH3QFfyQjVgO8X0VTfvZHY3JXioruI9gtKDygN9taNc ymIoFmTkz5JcU+BjygDz149b39uj5D5iqB2HEeDCXQYqO6O4mRc502LfKdc7+DxEH5/T E97tP6tEDAANp7/IEoVTNxbUI7lG+S0/gU0fq8u+RPynu90hgjNxgXXWfYqCDJvfA6ax XXsJ24YCt7KB6bXWkFV6w53bG2pj3En51jVt9LS2nWuOcQw7Mt0PTJyi7oIPBFrOFglx IUSB6MJnbWwQGn/7uBU3LOgFcnxc8hxFB8Hs6LzeRw3fEB0j4mwr1Eewa6EB69zDA10z vZaQ==
MIME-Version: 1.0
X-Received: by 10.50.212.3 with SMTP id ng3mr5949598igc.43.1367162566159; Sun, 28 Apr 2013 08:22:46 -0700 (PDT)
Received: by 10.64.231.37 with HTTP; Sun, 28 Apr 2013 08:22:46 -0700 (PDT)
Date: Sun, 28 Apr 2013 17:22:46 +0200
Message-ID: 
From: =?UTF-8?B?Qm9qYW4gxb1pdmFub3ZpxIc=?= 
To: oauth@ietf.org
Content-Type: multipart/alternative; boundary=14dae93409f71b365c04db6d5719
Subject: [OAUTH-WG] Implicit flow, scopes, and url length limit
X-BeenThere: oauth@ietf.org
X-Mailman-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, 28 Apr 2013 15:24:00 -0000

--14dae93409f71b365c04db6d5719
Content-Type: text/plain; charset=UTF-8

Hi everyone,
I've written an oauth2 server for Drupal (
http://drupal.org/project/oauth2_server) based on the
https://github.com/bshaffer/oauth2-server-php PHP library.
My company is preparing a fairly large OAuth 2.0 deployment based on that
code.

On the library level we recently discussed the problem of scopes in the
redirect urls during implicit flow.

The URL limit is 2083 characters (imposed by Internet Explorer).
During the implicit flow, scope is passed in the URL.
If the server uses long scope names, and the client gets granted several of
those, it is possible to breach that limit (especially since the domain
name and the rest of the redirect url path is also a part of that 2083
limit).
Has this problem been discussed previously, and what were the conclusions?

My idea was to introduce a setting that would cause scope to not be passed
through the redirect_url in this case, so that it is later fetched through
a separate resource (we have a "tokens" resource just like GitHub, Facebook
and Google do, for getting all information about the passed token. Calling
this resource from the server side after an implicit flow allows us to
avoid the
http://homakov.blogspot.com/2012/08/oauth2-one-accesstoken-to-rule-them-all.htmlattack
).

Thoughts?

Thanks,
Bojan

--14dae93409f71b365c04db6d5719
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi everyone,

My company is preparing a fairly large OAuth 2.0 deployment base=
d on that code.

On the library level w=
e recently discussed the problem of scopes in the redirect urls during impl=
icit flow.



The URL limit is 2083=
 characters (imposed by Internet Explorer).


During the implicit flow, scope is passed =
in the URL.

If the server uses long scope names, and the client g=
ets granted several of those, it is possible to breach that limit (especial=
ly since the domain name and the rest of the redirect url path is also a pa=
rt of that 2083 limit).


Has this problem been=
 discussed previously, and what were the conclusions?

=





Thoughts?


Thanks,
Bojan















--14dae93409f71b365c04db6d5719--

From sakimura@gmail.com  Mon Apr 29 02:19:53 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E239021F9D3C for ; Mon, 29 Apr 2013 02:19:52 -0700 (PDT)
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 HvmTrT1WmilM for ; Mon, 29 Apr 2013 02:19:52 -0700 (PDT)
Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) by ietfa.amsl.com (Postfix) with ESMTP id 76E7A21F9D45 for ; Mon, 29 Apr 2013 02:19:51 -0700 (PDT)
Received: by mail-lb0-f178.google.com with SMTP id w10so5459639lbi.9 for ; Mon, 29 Apr 2013 02:19:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=73SbX9HawfI55awqE1k9LblsBT5QyXtRuHPxr6BzDYc=; b=dsV2IaLsGa5rg4G61K9yYwmkr1/eQPbw80uoi21JpgkwgTZzRllsO+WQzDmkBzZ3OH kwWJVNwQSWg2CE/unfE8csTwj3VrW0lbS99fYS7xp0UbWJEP7YoZQGHCnD+ZekjJDDrV wMf7Dr4IX3VBWt6+U4zowjIquVQipVYepngaFwqC10+55YhIRHP+Fdao6jwGKBHzbv4H sH2veHPQ/a00HOKi1JImjmsyLINH+1jCuSaJHIF+Onww2xeSmfsLlDIsEZk9t4aCY0zm Jy/nxuIrUyJE4v6b31A0S6nRQjsea3rugJ9y2wMrFAdAvZeW1z4/+EVi5L0joXpxtruj Xdvg==
MIME-Version: 1.0
X-Received: by 10.112.199.230 with SMTP id jn6mr26434517lbc.131.1367227190078;  Mon, 29 Apr 2013 02:19:50 -0700 (PDT)
Received: by 10.112.129.165 with HTTP; Mon, 29 Apr 2013 02:19:50 -0700 (PDT)
In-Reply-To: 
References: 
Date: Mon, 29 Apr 2013 11:19:50 +0200
Message-ID: 
From: Nat Sakimura 
To: =?ISO-8859-2?Q?Bojan_=AEivanovi=E6?= 
Content-Type: multipart/alternative; boundary=001a11c38516fe028e04db7c62a1
Cc: oauth 
Subject: Re: [OAUTH-WG] Implicit flow, scopes, and url length limit
X-BeenThere: oauth@ietf.org
X-Mailman-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, 29 Apr 2013 09:19:53 -0000

--001a11c38516fe028e04db7c62a1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Essentially, that is what OpenID Connect does with request_uri or request
object.

In OpenID Connect, a client can register the request parameters to the
server before hand and get the reference to it called request_uri. Then, it
can be passed to the authorization server by an extensiion parameter called
request_uri. In this case, scope includes only "openid" effectively saying
"look at the registered request file for the details".

Best,

Nat


2013/4/28 Bojan =C5=BDivanovi=C4=87 

> Hi everyone,
> I've written an oauth2 server for Drupal (
> http://drupal.org/project/oauth2_server) based on the
> https://github.com/bshaffer/oauth2-server-php PHP library.
> My company is preparing a fairly large OAuth 2.0 deployment based on that
> code.
>
> On the library level we recently discussed the problem of scopes in the
> redirect urls during implicit flow.
>
> The URL limit is 2083 characters (imposed by Internet Explorer).
> During the implicit flow, scope is passed in the URL.
> If the server uses long scope names, and the client gets granted several
> of those, it is possible to breach that limit (especially since the domai=
n
> name and the rest of the redirect url path is also a part of that 2083
> limit).
> Has this problem been discussed previously, and what were the conclusions=
?
>
> My idea was to introduce a setting that would cause scope to not be passe=
d
> through the redirect_url in this case, so that it is later fetched throug=
h
> a separate resource (we have a "tokens" resource just like GitHub, Facebo=
ok
> and Google do, for getting all information about the passed token. Callin=
g
> this resource from the server side after an implicit flow allows us to
> avoid the
> http://homakov.blogspot.com/2012/08/oauth2-one-accesstoken-to-rule-them-a=
ll.htmlattack
> ).
>
> Thoughts?
>
> Thanks,
> Bojan
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>


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

--001a11c38516fe028e04db7c62a1
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable


Essentially, that is what OpenID Connect does with request=
_uri or request object.=A0

In OpenID Connect, a cl=
ient can register the request parameters to the server before hand and get =
the reference to it called request_uri. Then, it can be passed to the autho=
rization server by an extensiion parameter called request_uri. In this case=
, scope includes only "openid" effectively saying "look at t=
he=A0registered=A0request file for the details".=A0



Best,=A0

Nat


2013/4/28 Bojan =AEivanovi=E6 <bojanz@gmail.com>


Hi everyone,
I've w=
ritten an oauth2 server for Drupal (http://drupal.org/project/oauth2_server)=
 based on the https://github.com/bshaffer/oauth2-server-php=A0PHP libr=
ary.



My company is preparing a fairly large OAuth 2.0 deployment based on t=
hat code.

On the library level we recently discuss=
ed the problem of scopes in the redirect urls during implicit flow.




The URL limit is 2083 characters =
(imposed by Internet Explorer).



During the implicit flow, scope is passed in the=
 URL.


If the server uses long scope names, and the client g=
ets granted several of those, it is possible to breach that limit (especial=
ly since the domain name and the rest of the redirect url path is also a pa=
rt of that 2083 limit).



Has this problem been discu=
ssed previously, and what were the conclusions?



My idea was to introduce a settin=
g that would cause scope to not be passed through the redirect_url in this =
case, so that it is later fetched through a separate resource (we have a &q=
uot;tokens" resource just like GitHub, Facebook and Google do, for get=
ting all information about the passed token. Calling this resource from the=
 server side after an implicit flow allows us to avoid the=A0=
http://homakov.blogspot.com/2012/08/oau=
th2-one-accesstoken-to-rule-them-all.html attack).




Thoughts?



Thanks,
Bojan















_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth





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




--001a11c38516fe028e04db7c62a1--

From sberyozkin@gmail.com  Mon Apr 29 04:36:37 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09DCC21F8640 for ; Mon, 29 Apr 2013 04:36:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rwDhdh6Q79Id for ; Mon, 29 Apr 2013 04:36:36 -0700 (PDT)
Received: from mail-ea0-x235.google.com (mail-ea0-x235.google.com [IPv6:2a00:1450:4013:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id CC20121F979B for ; Mon, 29 Apr 2013 04:36:34 -0700 (PDT)
Received: by mail-ea0-f181.google.com with SMTP id a11so2475730eae.26 for ; Mon, 29 Apr 2013 04:36:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=qdozAUrdIuDG24v9KOeqcp6Xuz79bFgScNcsrW28nlI=; b=iHCLiKeeGIT4usXMaUZSUNiNqEVZp5f3zvuE1RX6lTB1XfoWp2plQKHpi48DnGsDck lNG+bKDXy6NT5CO1aSUCEClF8butl7IR6xxp5blC4cRRHJmmFLmmWhQPBnS5eFDeUMKM jhPq4uYC8i3DrxEiVDwvXHqGc0pzYt9qP3PwXrnqcUN51Ew/Z5qZjkHu9FtPoHRbv2vM wxKy4UICLPnjwbg0sOofVF7YsPoAJBaUioC+U7tTW+lrKsIPJ2Zr8vf2pRsrQRb7KmxO VO4Ersqjl8mF+mtSsccy1EtlDNJBy2UlDkToIlPhPJBuZLoNF6tQMg7VwvSOW1sckROr VqNg==
X-Received: by 10.15.36.135 with SMTP id i7mr90519179eev.34.1367235387796; Mon, 29 Apr 2013 04:36:27 -0700 (PDT)
Received: from [10.36.226.5] ([217.173.99.61]) by mx.google.com with ESMTPSA id cd3sm32308483eeb.6.2013.04.29.04.36.26 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 29 Apr 2013 04:36:26 -0700 (PDT)
Message-ID: <517E5B15.1010106@gmail.com>
Date: Mon, 29 Apr 2013 12:35:49 +0100
From: Sergey Beryozkin 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: oauth@ietf.org
References:  
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [OAUTH-WG] Implicit flow, scopes, and url length limit
X-BeenThere: oauth@ietf.org
X-Mailman-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, 29 Apr 2013 11:36:37 -0000

On 29/04/13 10:19, Nat Sakimura wrote:
> Essentially, that is what OpenID Connect does with request_uri or
> request object.
>
> In OpenID Connect, a client can register the request parameters to the
> server before hand and get the reference to it called request_uri. Then,
> it can be passed to the authorization server by an extensiion parameter
> called request_uri. In this case, scope includes only "openid"
> effectively saying "look at the registered request file for the details".
>
Should it be done in the next OAuth2 revision spec ? Seems like it's an 
OAuth2-level feature, except that a scope name would be more neutral, 
"client_registration" or similar...

Cheers, Sergey

> Best,
>
> Nat
>
>
> 2013/4/28 Bojan Živanović >
>
>     Hi everyone,
>     I've written an oauth2 server for Drupal
>     (http://drupal.org/project/oauth2_server) based on the
>     https://github.com/bshaffer/oauth2-server-php PHP library.
>     My company is preparing a fairly large OAuth 2.0 deployment based on
>     that code.
>
>     On the library level we recently discussed the problem of scopes in
>     the redirect urls during implicit flow.
>
>     The URL limit is 2083 characters (imposed by Internet Explorer).
>     During the implicit flow, scope is passed in the URL.
>     If the server uses long scope names, and the client gets granted
>     several of those, it is possible to breach that limit (especially
>     since the domain name and the rest of the redirect url path is also
>     a part of that 2083 limit).
>     Has this problem been discussed previously, and what were the
>     conclusions?
>
>     My idea was to introduce a setting that would cause scope to not be
>     passed through the redirect_url in this case, so that it is later
>     fetched through a separate resource (we have a "tokens" resource
>     just like GitHub, Facebook and Google do, for getting all
>     information about the passed token. Calling this resource from the
>     server side after an implicit flow allows us to avoid the
>     http://homakov.blogspot.com/2012/08/oauth2-one-accesstoken-to-rule-them-all.html
>     attack).
>
>     Thoughts?
>
>     Thanks,
>     Bojan
>
>
>
>     _______________________________________________
>     OAuth mailing list
>     OAuth@ietf.org 
>     https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> --
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth