From sberyozkin@gmail.com Fri Mar 1 03:51: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 E86ED21F87E0 for ; Fri, 1 Mar 2013 03:51:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.409 X-Spam-Level: X-Spam-Status: No, score=-3.409 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SYUxxr5ndZVt for ; Fri, 1 Mar 2013 03:51:14 -0800 (PST) Received: from mail-ee0-f45.google.com (mail-ee0-f45.google.com [74.125.83.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2ED9E21F8574 for ; Fri, 1 Mar 2013 03:51:12 -0800 (PST) Received: by mail-ee0-f45.google.com with SMTP id b57so2255749eek.18 for ; Fri, 01 Mar 2013 03:51:11 -0800 (PST) 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=Y2QikbGkJHWbPs1jXpYfZqZj09eD/senidW8aoFaQ1A=; b=Z0pbww6PpyGW5EU8hk8AyLGL50jxcdEzVwvlbWoH6ZhCxVYljb2Ty5PxV18kIME4vC oXCfI11BF18cqVoorZp2faQppSCwiOIcEy0n7ptlslLMtB3Oa0MR3+RL80x/I6fKkvc4 OAeO8hpH5wSFAmo+4jg45O5djfqCBRTpCIsguaWEB4hqKRpZCqLLOD+ruIdiNCvJcSp9 GeEq1JjwiGlGPgQ/3PxFBXkw8X92oGMIFYbssbqE1G/QG25CToba+4XiL9TbJgq8aobM 1p4Urg0yrpW2ukxlHHFMLAH3WUhfakRXLPG2lFlvh8e6gRiPwqN7ixzcTfdwI+4RF6ez lVaQ== X-Received: by 10.14.219.7 with SMTP id l7mr27396746eep.12.1362138671202; Fri, 01 Mar 2013 03:51:11 -0800 (PST) Received: from [10.36.226.5] ([217.173.99.61]) by mx.google.com with ESMTPS id f47sm16779646eep.13.2013.03.01.03.51.09 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 Mar 2013 03:51:10 -0800 (PST) Message-ID: <5130962C.9090408@gmail.com> Date: Fri, 01 Mar 2013 11:51:08 +0000 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: William Mills References: <20130225124642.7425.65145.idtracker@ietfa.amsl.com> <1361956373.9883.YahooMailNeo@web31807.mail.mud.yahoo.com> <21030204-8EA7-4FB0-9DD3-2B6C8CA57E02@gmx.net> <1362057295.36069.YahooMailNeo@web31809.mail.mud.yahoo.com> <512F8E1D.2060408@gmail.com> <1362073743.15800.YahooMailNeo@web31802.mail.mud.yahoo.com> <512F9BB3.2010201@gmail.com> <1362074764.35520.YahooMailNeo@web31806.mail.mud.yahoo.com> In-Reply-To: <1362074764.35520.YahooMailNeo@web31806.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 11:51:18 -0000 I'm looking at [1] and I honestly don't follow what would adding JSON structure bring to the table, the text there is quite straight-forward, and the 'sorting' variable is not even there, may be, only if headers are *optionally* included when calculating 'mac'. Are you indirectly referring to the idea of OAuth2 servers supporting an OAuth1-style tokens which was proposed in the other thread by any chance, as you mention "oath_..." parameters ? In that context, using JWT extension may work, not really sure, but in context of [1] - I don't understand where it would fit in Thanks, Sergey [1] http://datatracker.ietf.org/doc/draft-ietf-oauth-v2-http-mac/?include_text=1 On 28/02/13 18:06, William Mills wrote: > I certainly hope so. > > ------------------------------------------------------------------------ > *From:* Sergey Beryozkin > *To:* William Mills > *Cc:* "oauth@ietf.org" > *Sent:* Thursday, February 28, 2013 10:02 AM > *Subject:* Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt > > On 28/02/13 17:49, William Mills wrote: > > The JWT replaces the oauth_token data element in the old MAC stuff. I > > just want to take all the other oauth_* variables and stuff them in a > > separate JSON object and completely kill the "fun with sorting > > variables" when the oauth_* things can be carried in the query string or > > header or post body. > As far as the client accessing RS is concerned, should it be limited to > using a header, same as for other OAuth2 tokens ? > > Cheers, Sergey > > > > > ------------------------------------------------------------------------ > > *From:* Sergey Beryozkin > > > *To:* oauth@ietf.org > > *Sent:* Thursday, February 28, 2013 9:04 AM > > *Subject:* Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt > > > > Hi > > On 28/02/13 13:14, William Mills wrote: > > > I'm actually advocating that we change MAC to be a JWT extension. > > IMHO, having a simpler option, plus, going forward, a possible JWT > > profile (client to RS path) would work better - > > > > Why would JWT completely take over ? May be it should be possible indeed > > to have it as a JWT extension - should it be part of the relevant JWT > > assertion spec, where JWT is used as a possible grant ? > > > > Thanks, Sergey > > > > > > > ------------------------------------------------------------------------ > > > *From:* Hannes Tschofenig > > >> > > > *To:* William Mills > > >> > > > *Cc:* Hannes Tschofenig > > >>; "oauth@ietf.org > > > >" > > > >> > > > *Sent:* Thursday, February 28, 2013 2:28 AM > > > *Subject:* Re: [OAUTH-WG] I-D Action: > draft-ietf-oauth-v2-http-mac-03.txt > > > > > > Hi Bill, > > > > > > I believe you are misreading the document. In > > > draft-ietf-oauth-v2-http-mac the client still uses the MAC when it > > > accesses a protected resource. > > > The only place where the JWT comes into the picture is with the > > > description of the access token. This matters from a key distribution > > > point of view. The session key for the MAC is included in the encrypted > > > JWT. The JWT is encrypted by the authorization server and decrypted by > > > the resource server. > > > > > > Information about how header fields get included in the MAC is > described > > > in Section 5. > > > > > > The nonce isn't killed it is just called differently: seq-nr. The stuff > > > in the original MAC specification actually wasn't a nonce (from the > > > semantic point of view). > > > The extension parameter is there implicitly by allowing additional > > > header fields to be included in the MAC computation. > > > > > > I need to look at the port number field again. > > > > > > Ciao > > > Hannes > > > > > > On Feb 27, 2013, at 11:12 AM, William Mills wrote: > > > > > > > Just read the draft quickly. > > > > > > > > Since we're now leaning on JWT do we need to include the token in > > > this? Why not just make an additional "Envelope MAC" thing and have the > > > signature include the 3 JWT parts in the signature base string? That > > > object then just becomes a JSON container for the kid, timestamp, > > > signature method, signature etc. That thing then is a 4th base64 > encoded > > > JSON thing in the auth header. > > > > > > > > How header fields get included in the signature needs definition. > > > > > > > > Why did you kill the port number, nonce, and extension parameter out > > > of the signature base string? > > > > > > > > The BNF appears to have no separators between values. > > > > > > > > -bill > > > > > > > > > > > > From: "internet-drafts@ietf.org > > > > > >>" > > > > > > > > >>> > > > > To: i-d-announce@ietf.org > > > > > >> > > > > Cc: oauth@ietf.org > > > >> > > > > Sent: Monday, February 25, 2013 4:46 AM > > > > Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt > > > > > > > > > > > > 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 Message Authentication Code (MAC) Tokens > > > > Author(s) : Justin Richer > > > > William Mills > > > > Hannes Tschofenig > > > > Filename : draft-ietf-oauth-v2-http-mac-03.txt > > > > Pages : 26 > > > > Date : 2013-02-25 > > > > > > > > Abstract: > > > > This specification describes how to use MAC Tokens in HTTP requests > > > > to access OAuth 2.0 protected resources. An OAuth client willing to > > > > access a protected resource needs to demonstrate possession of a > > > > crytographic key by using it with a keyed message digest function to > > > > the request. > > > > > > > > The document also defines a key distribution protocol for obtaining a > > > > fresh session key. > > > > > > > > > > > > The IETF datatracker status page for this draft is: > > > > https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-http-mac > > > > > > > > There's also a htmlized version available at: > > > > http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-03 > > > > > > > > A diff from the previous version is available at: > > > > http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-v2-http-mac-03 > > > > > > > > > > > > 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 > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > From sberyozkin@gmail.com Fri Mar 1 04:23: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 AFD4C21F8AE6 for ; Fri, 1 Mar 2013 04:23:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.422 X-Spam-Level: X-Spam-Status: No, score=-3.422 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ui53k53coKF for ; Fri, 1 Mar 2013 04:23:19 -0800 (PST) Received: from mail-ee0-f47.google.com (mail-ee0-f47.google.com [74.125.83.47]) by ietfa.amsl.com (Postfix) with ESMTP id D46C821F8AD8 for ; Fri, 1 Mar 2013 04:23:18 -0800 (PST) Received: by mail-ee0-f47.google.com with SMTP id e52so2292537eek.20 for ; Fri, 01 Mar 2013 04:23:18 -0800 (PST) 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=9pW6QCPOQLmBoYasyGnKepvtxC/WHBWyoMdmTztZsOs=; b=o5fPYNMF1yJ1kcmeCXe7mXpQl3/k0E9TszHDWQAsi+i0HzsYaMef2gvfpjT1nJXih8 fDX7z+PzsaXgK6VuVSiyUdY4ByVcKd61OLe+8Yp/kp9/1j4ZSTFudtzbZq5JXYSv7nSi GOvc5iEz+GmLJHN3nwE3LvGp1N/IhnB9/Ve6q+KHQYAsx/Fwz8mCIMlxj0KvF05cUogx Sis9DcUkdE7UpBN3QJL4zhnphReb6skV4gKihj5dxcFeA/qhXwwm+rk8yYsrPMCXQ4FN 83tD9rDMj0AijLHVFSKQWp9hZVRzyXzxP545xUoOg9ZjAWmx9H92+H/j1LQ/E+tJuhkz I4EQ== X-Received: by 10.14.207.200 with SMTP id n48mr27720196eeo.4.1362140597930; Fri, 01 Mar 2013 04:23:17 -0800 (PST) Received: from [10.36.226.5] ([217.173.99.61]) by mx.google.com with ESMTPS id 44sm16934142eek.5.2013.03.01.04.23.16 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 Mar 2013 04:23:16 -0800 (PST) Message-ID: <51309DB3.8000907@gmail.com> Date: Fri, 01 Mar 2013 12:23:15 +0000 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=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [OAUTH-WG] Using access token in draft-ietf-oauth-v2-http-mac X-BeenThere: oauth@ietf.org X-Mailman-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, 01 Mar 2013 12:23:19 -0000 Hi Hannes, the proposed Authenticator text says: "access_token CONDITIONAL. The access_token MUST be included in the first request from the client to the server but MUST NOT be included in a subsequent response and in a further protocol exchange. " Why MUST is there ? And how the server can determine it is the first request from a given client ? Next, the example showing a client getting an access token + session key from AS shows a long base64 encoded value - I don't mind, just wonder does that simply provides for transporting tokens like JWT token (fine as long as one can provide a simple token) ? Thanks, Sergey On 25/02/13 12:46, Hannes Tschofenig wrote: > Hi all, > > I just submitted an updated version of the draft-ietf-oauth-v2-http-mac-03.txt. > > I would like to point out that this is **discussion input** -- not agreed content. Anything in the document is subject to change! > You also may notice that there are a few questions in the writeup. > > I was trying to more specific about some of the design aspects that folks had proposed during the last few months. > I have also re-submitted the draft-tschofenig-oauth-hotk, which includes a TLS and a JSON-based solution approach. > > In general, the open questions still seem to be related to > * Key distribution: What should be described in a document? What is mandatory to implement? > * Selective header field protection: This is something that was brought forward in discussions and I have included a proposal of how this could look like. > * Channel Binding: Functionality is also included to deal with man-in-the-middle attacks against TLS. There are, however, two types of channel bindings defined in RFC 5929. Are both needed? If not, which one should be selected? > * Integrity protection and data origin authentication in both directions: The current writeup allows the protection to be extended to messages beyond the initial request. This also offers key confirmation by the server and protection of any responses. > > Writing the text I also noticed that I do not quite understand how nested JWT documents are supposed to look like. For example, how do I encrypt the mac_key carried inside the JWT plus add a signature of all other fields? Currently, I have just encrypted the entire payload. > > I hope to have some discussions prior to the IETF meeting so that we have a more fruitful discussion at the face-to-face meeting. > > Ciao > Hannes > From wmills_92105@yahoo.com Fri Mar 1 06:56: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 76F7E1F0D0B for ; Fri, 1 Mar 2013 06:56:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.369 X-Spam-Level: X-Spam-Status: No, score=-2.369 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E-j44cZnFWp1 for ; Fri, 1 Mar 2013 06:56:21 -0800 (PST) Received: from nm33-vm2.bullet.mail.bf1.yahoo.com (nm33-vm2.bullet.mail.bf1.yahoo.com [72.30.239.202]) by ietfa.amsl.com (Postfix) with ESMTP id A86E71F0D08 for ; Fri, 1 Mar 2013 06:56:20 -0800 (PST) Received: from [98.139.212.146] by nm33.bullet.mail.bf1.yahoo.com with NNFMP; 01 Mar 2013 14:56:20 -0000 Received: from [98.139.212.240] by tm3.bullet.mail.bf1.yahoo.com with NNFMP; 01 Mar 2013 14:56:20 -0000 Received: from [127.0.0.1] by omp1049.mail.bf1.yahoo.com with NNFMP; 01 Mar 2013 14:56:20 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 138001.40055.bm@omp1049.mail.bf1.yahoo.com Received: (qmail 3760 invoked by uid 60001); 1 Mar 2013 14:56:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1362149779; bh=EbyZauqMYjrVWHipiYYf5DbthP1P1c6QTLOIUPFLgmE=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=GwCz5bcms6bZCOQqlNokvBTfZ70/LdglTwAnRNMEBdx7o3Cc7YCu0eHutNXfk2ZKT+4nGLVkWgG89yZz6Ap2b4J4Uk0mt1ijlELsAIF/agAevOyGdqWJYJI8fhRYJLcByS3IjWhRiOjKaJw23qtiHgRvD6E5RU2rdZEzmjXxMgY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=JbgvsNNau+nvKe7t4RHBo1goH0H2ORkdNZ5HU+f0oDe0yiJln2gaCbZ18GUq2mkSA5ctjzLq3XOTIFwz6NxRWAbtiY8FDli0Ohpbn3Zu0Bfdq/oG+QUOGavxTs9aeZ17EJANJyA7aTszp6T9UG70oad+Utp4lXuh0LY4Gdyxd5U=; X-YMail-OSG: qqkRUVoVM1k7xUkrPzT7zPoI96x9sA17y7CaWdWJQ3osI35 1Nm34iZ.tSPft18XP48nZ6jEcNO6d4cyJdumBmIwsE0OBURm7mzoxNeooviP 7meNjdm0l3KsPFfQbpxyGSe8MN7_KEcHnJSKHEdPsvSZqq.MaC7R_FAMpZeL WFCaNnYd27def_QbW.kJbepR9mxVX.BXttx_aPJEZx7.CI4HO9d2x2QEOXub 8y2cFbj49Cfzfabl0s09ueGMeqrr7VFy0WuNVJBOCL8FURtdESq0FCaYh9ZC eYnVZODEH7fRLAhCY.PgrIb5iM.TrVmFz_zbgGNrmQa3AXUeOXRT2Rlt5wWY pYt7H_Pxw_UmK2lvghA74hDLkHcp.p9ORZDTbtL2nAAv_M4AqaHNKCRhOvw_ o_31TidDN2ftES0EUiRyzGuAbE2j3A6G25J.8EgQBzI_zoSv9aNZpTpR4A99 Xrg5_YHvfEpDc4Vu2EyanqSn9LjAPVxyQuuHyciWYreDtMLj3qJB0wQkpP7I pfRR55mxfDRzS8MsE.xDOqAcn1uaH4OSLaXdMgO83UcEuhE9I9LUXi5uBLb4 h Received: from [209.131.62.115] by web31807.mail.mud.yahoo.com via HTTP; Fri, 01 Mar 2013 06:56:19 PST X-Rocket-MIMEInfo: 001.001, VGhlIG5ldyBzaWduYXR1cmUgYmFzZSBzdHJpbmcgc3R1ZmYgc3RpbGwgbmVlZHMgd29yaywgSSB3YW50ZWQgdG8gdGFja2xlIG1vcmUgbWFqb3IgcmVzdHJ1Y3R1cmluZyBmaXJzdC4gwqBJIHdhbnQgdG8gcHVsbCBhbGwgb2YgdGhvc2UgdGhpbmdzIG91dCBvZiB0aGUgcXVlcnkgc3RyaW5nLiDCoAoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCiBGcm9tOiBTZXJnZXkgQmVyeW96a2luIDxzYmVyeW96a2luQGdtYWlsLmNvbT4KVG86IFdpbGxpYW0gTWlsbHMgPHdtaWxsc185MjEwNUB5YWhvby4BMAEBAQE- X-Mailer: YahooMailWebService/0.8.135.514 References: <20130225124642.7425.65145.idtracker@ietfa.amsl.com> <1361956373.9883.YahooMailNeo@web31807.mail.mud.yahoo.com> <21030204-8EA7-4FB0-9DD3-2B6C8CA57E02@gmx.net> <1362057295.36069.YahooMailNeo@web31809.mail.mud.yahoo.com> <512F8E1D.2060408@gmail.com> <1362073743.15800.YahooMailNeo@web31802.mail.mud.yahoo.com> <512F9BB3.2010201@gmail.com> <1362074764.35520.YahooMailNeo@web31806.mail.mud.yahoo.com> <5130962C.9090408@gmail.com> Message-ID: <1362149779.70391.YahooMailNeo@web31807.mail.mud.yahoo.com> Date: Fri, 1 Mar 2013 06:56:19 -0800 (PST) From: William Mills To: Sergey Beryozkin In-Reply-To: <5130962C.9090408@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-125733401-1451799642-1362149779=:70391" Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 14:56:22 -0000 ---125733401-1451799642-1362149779=:70391 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable The new signature base string stuff still needs work, I wanted to tackle mo= re major restructuring first. =A0I want to pull all of those things out of = the query string. =A0=0A=0A=0A________________________________=0A From: Ser= gey Beryozkin =0ATo: William Mills =0ACc: "oauth@ietf.org" =0ASent: Friday, March 1, 2= 013 3:51 AM=0ASubject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-= mac-03.txt=0A =0AI'm looking at [1]=0A=0Aand I honestly don't follow what w= ould adding JSON structure bring to the table, the text there is quite stra= ight-forward, and the 'sorting' variable is not even there, may be, only if= headers are *optionally* included when calculating 'mac'.=0A=0AAre you ind= irectly referring to the idea of OAuth2 servers supporting an OAuth1-style = tokens which was proposed in the other thread by any chance, as you mention= "oath_..." parameters ? In that context, using JWT extension may work, not= really sure, but in context of [1] - I don't understand where it would fit= in=0A=0AThanks, Sergey=0A=0A[1] http://datatracker.ietf.org/doc/draft-ietf= -oauth-v2-http-mac/?include_text=3D1=0A=0A=0AOn 28/02/13 18:06, William Mil= ls wrote:=0A> I certainly hope so.=0A> =0A> -------------------------------= -----------------------------------------=0A> *From:* Sergey Beryozkin =0A> *To:* William Mills =0A> *Cc= :* "oauth@ietf.org" =0A> *Sent:* Thursday, February 28, 201= 3 10:02 AM=0A> *Subject:* Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-ht= tp-mac-03.txt=0A> =0A> On 28/02/13 17:49, William Mills wrote:=0A>=A0 > The= JWT replaces the oauth_token data element in the old MAC stuff. I=0A>=A0 >= just want to take all the other oauth_* variables and stuff them in a=0A>= =A0 > separate JSON object and completely kill the "fun with sorting=0A>=A0= > variables" when the oauth_* things can be carried in the query string or= =0A>=A0 > header or post body.=0A> As far as the client accessing RS is con= cerned, should it be limited to=0A> using a header, same as for other OAuth= 2 tokens ?=0A> =0A> Cheers, Sergey=0A> =0A>=A0 >=0A>=A0 > -----------------= -------------------------------------------------------=0A>=A0 > *From:* Se= rgey Beryozkin >=0A>= =A0 > *To:* oauth@ietf.org =0A>=A0 > *Sent:* Thursda= y, February 28, 2013 9:04 AM=0A>=A0 > *Subject:* Re: [OAUTH-WG] I-D Action:= draft-ietf-oauth-v2-http-mac-03.txt=0A>=A0 >=0A>=A0 > Hi=0A>=A0 > On 28/02= /13 13:14, William Mills wrote:=0A>=A0 > > I'm actually advocating that we = change MAC to be a JWT extension.=0A>=A0 > IMHO, having a simpler option, p= lus, going forward, a possible JWT=0A>=A0 > profile (client to RS path) wou= ld work better -=0A>=A0 >=0A>=A0 > Why would JWT completely take over ? May= be it should be possible indeed=0A>=A0 > to have it as a JWT extension - s= hould it be part of the relevant JWT=0A>=A0 > assertion spec, where JWT is = used as a possible grant ?=0A>=A0 >=0A>=A0 > Thanks, Sergey=0A>=A0 > >=0A>= =A0 > >=0A> ---------------------------------------------------------------= ---------=0A>=A0 > > *From:* Hannes Tschofenig =0A>=A0 > >>=0A>=A0 > > *To:* William Mills= =0A>=A0 > >>=0A>=A0 > > *Cc:= * Hannes Tschofenig =0A>=A0 > >>; "oauth@ietf.org=0A> =0A>=A0 > <= mailto:oauth@ietf.org >"=0A>=A0 > > >= >=0A>=A0 > > *Sent:* Thursday, February 28, 2013 2:28 AM=0A>=A0 > > *Subjec= t:* Re: [OAUTH-WG] I-D Action:=0A> draft-ietf-oauth-v2-http-mac-03.txt=0A>= =A0 > >=0A>=A0 > > Hi Bill,=0A>=A0 > >=0A>=A0 > > I believe you are misread= ing the document. In=0A>=A0 > > draft-ietf-oauth-v2-http-mac the client sti= ll uses the MAC when it=0A>=A0 > > accesses a protected resource.=0A>=A0 > = > The only place where the JWT comes into the picture is with the=0A>=A0 > = > description of the access token. This matters from a key distribution=0A>= =A0 > > point of view. The session key for the MAC is included in the encry= pted=0A>=A0 > > JWT. The JWT is encrypted by the authorization server and d= ecrypted by=0A>=A0 > > the resource server.=0A>=A0 > >=0A>=A0 > > Informati= on about how header fields get included in the MAC is=0A> described=0A>=A0 = > > in Section 5.=0A>=A0 > >=0A>=A0 > > The nonce isn't killed it is just c= alled differently: seq-nr. The stuff=0A>=A0 > > in the original MAC specifi= cation actually wasn't a nonce (from the=0A>=A0 > > semantic point of view)= .=0A>=A0 > > The extension parameter is there implicitly by allowing additi= onal=0A>=A0 > > header fields to be included in the MAC computation.=0A>=A0= > >=0A>=A0 > > I need to look at the port number field again.=0A>=A0 > >= =0A>=A0 > > Ciao=0A>=A0 > > Hannes=0A>=A0 > >=0A>=A0 > > On Feb 27, 2013, a= t 11:12 AM, William Mills wrote:=0A>=A0 > >=0A>=A0 > > > Just read the draf= t quickly.=0A>=A0 > > >=0A>=A0 > > > Since we're now leaning on JWT do we n= eed to include the token in=0A>=A0 > > this? Why not just make an additiona= l "Envelope MAC" thing and have the=0A>=A0 > > signature include the 3 JWT = parts in the signature base string? That=0A>=A0 > > object then just become= s a JSON container for the kid, timestamp,=0A>=A0 > > signature method, sig= nature etc. That thing then is a 4th base64=0A> encoded=0A>=A0 > > JSON thi= ng in the auth header.=0A>=A0 > > >=0A>=A0 > > > How header fields get incl= uded in the signature needs definition.=0A>=A0 > > >=0A>=A0 > > > Why did y= ou kill the port number, nonce, and extension parameter out=0A>=A0 > > of t= he signature base string?=0A>=A0 > > >=0A>=A0 > > > The BNF appears to have= no separators between values.=0A>=A0 > > >=0A>=A0 > > > -bill=0A>=A0 > > >= =0A>=A0 > > >=0A>=A0 > > > From: "internet-drafts@ietf.org =0A> >=0A>=A0 > =0A> >>"=0A>=A0 > > =0A> >=0A>=A0 > =0A> >>>=0A>=A0 > > > To: i-d-announce@ietf.org =0A> >=0A>=A0= > =0A> >>=0A>=A0 > > > Cc: oa= uth@ietf.org > =0A>=A0 > >>=0A>=A0 > > > Sent: Monday, Febr= uary 25, 2013 4:46 AM=0A>=A0 > > > Subject: [OAUTH-WG] I-D Action: draft-ie= tf-oauth-v2-http-mac-03.txt=0A>=A0 > > >=0A>=A0 > > >=0A>=A0 > > > A New In= ternet-Draft is available from the on-line Internet-Drafts=0A>=A0 > > direc= tories.=0A>=A0 > > > This draft is a work item of the Web Authorization Pro= tocol Working=0A>=A0 > > Group of the IETF.=0A>=A0 > > >=0A>=A0 > > > Title= : OAuth 2.0 Message Authentication Code (MAC) Tokens=0A>=A0 > > > Author(s= ) : Justin Richer=0A>=A0 > > > William Mills=0A>=A0 > > > Hannes Tschofenig= =0A>=A0 > > > Filename : draft-ietf-oauth-v2-http-mac-03.txt=0A>=A0 > > > P= ages : 26=0A>=A0 > > > Date : 2013-02-25=0A>=A0 > > >=0A>=A0 > > > Abstract= :=0A>=A0 > > > This specification describes how to use MAC Tokens in HTTP r= equests=0A>=A0 > > > to access OAuth 2.0 protected resources. An OAuth clie= nt willing to=0A>=A0 > > > access a protected resource needs to demonstrate= possession of a=0A>=A0 > > > crytographic key by using it with a keyed mes= sage digest function to=0A>=A0 > > > the request.=0A>=A0 > > >=0A>=A0 > > >= The document also defines a key distribution protocol for obtaining a=0A>= =A0 > > > fresh session key.=0A>=A0 > > >=0A>=A0 > > >=0A>=A0 > > > The IET= F datatracker status page for this draft is:=0A>=A0 > > > https://datatrack= er.ietf.org/doc/draft-ietf-oauth-v2-http-mac=0A>=A0 > > >=0A>=A0 > > > Ther= e's also a htmlized version available at:=0A>=A0 > > > http://tools.ietf.or= g/html/draft-ietf-oauth-v2-http-mac-03=0A>=A0 > > >=0A>=A0 > > > A diff fro= m the previous version is available at:=0A>=A0 > > > http://www.ietf.org/rf= cdiff?url2=3Ddraft-ietf-oauth-v2-http-mac-03=0A>=A0 > > >=0A>=A0 > > >=0A>= =A0 > > > Internet-Drafts are also available by anonymous FTP at:=0A>=A0 > = > > ftp://ftp.ietf.org/internet-drafts/=0A>=A0 > > >=0A>=A0 > > > _________= ______________________________________=0A>=A0 > > > OAuth mailing list=0A>= =A0 > > > OAuth@ietf.org = > =0A= >=A0 > >>=0A>=A0 > > > https:= //www.ietf.org/mailman/listinfo/oauth=0A>=A0 > > >=0A>=A0 > > >=0A>=A0 > >= =0A>=A0 > >=0A>=A0 > >=0A>=A0 > >=0A>=A0 > >=0A>=A0 > > ___________________= ____________________________=0A>=A0 > > OAuth mailing list=0A>=A0 > > OAuth= @ietf.org >=0A>=A0 > > https://www.ietf.org/mailman/listinfo/oauth=0A>=A0 >= =0A>=A0 >=0A>=A0 > _______________________________________________=0A>=A0 >= OAuth mailing list=0A>=A0 > OAuth@ietf.org >=0A>=A0 > https://www.ietf.org/= mailman/listinfo/oauth=0A>=A0 >=0A>=A0 >=0A> =0A> ---125733401-1451799642-1362149779=:70391 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
The = new signature base string stuff still needs work, I wanted to tackle more m= ajor restructuring first.  I want to pull all of those things out of t= he query string.  

From: Sergey Beryozki= n <sberyozkin@gmail.com>
To= : William Mills <wmills_92105@yahoo.com>
Cc: "oauth@ietf.org" <oauth@ietf.org= >
Sent: Friday, Ma= rch 1, 2013 3:51 AM
Subject: Re: = [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt
I'm looking at [1]

and I honestly don't follow what would add= ing JSON structure bring to the table, the text there is quite straight-for= ward, and the 'sorting' variable is not even there, may be, only if headers= are *optionally* included when calculating 'mac'.

Are you indirectl= y referring to the idea of OAuth2 servers supporting an OAuth1-style tokens= which was proposed in the other thread by any chance, as you mention "oath= _..." parameters ? In that context, using JWT extension may work, not reall= y sure, but in context of [1] - I don't understand where it would fit in
Thanks, Sergey

[1] http://datatracker.ietf.org/doc/draft-ietf-oauth-v2-http= -mac/?include_text=3D1


On 28/02/13 18:06, William Mills wrot= e:
> I certainly hope so.
>
> --------------------------= ----------------------------------------------
> *From:* Sergey Beryo= zkin <sberyozkin@gmail.com>
> *To:* William Mills <= wmills_92105@yahoo.com>
> *Cc:* "oauth@ietf.org" <oauth@ietf= .org>
> *Sent:* Thursday, February 28, 2013 10:02 AM
> *= Subject:* Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt>
> On 28/02/13 17:49, William Mills wrote:
>  > T= he JWT replaces the oauth_token data element in the old MAC stuff. I
> = ; > just want to take all the other oauth_* variables and stuff them in = a
>  > separate JSON object and completely kill the "fun with= sorting
>  > variables" when the oauth_* things can be carri= ed in the query string or
>  > header or post body.
> A= s far as the client accessing RS is concerned, should it be limited to
&= gt; using a header, same as for other OAuth2 tokens ?
>
> Chee= rs, Sergey
>
>  >
>  > -----------------= -------------------------------------------------------
>  > = *From:* Sergey Beryozkin <sberyozkin@gmail.com
> <mail= to:sberyozkin@gmail.com>>
>  > *To:* oauth@iet= f.org <mailto:oauth@ietf.org>
>  > *Sent:* Thursday, F= ebruary 28, 2013 9:04 AM
>  > *Subject:* Re: [OAUTH-WG] I-D A= ction: draft-ietf-oauth-v2-http-mac-03.txt
>  >
> = > Hi
>  > On 28/02/13 13:14, William Mills wrote:
>=   > > I'm actually advocating that we change MAC to be a JWT ext= ension.
>  > IMHO, having a simpler option, plus, going forwa= rd, a possible JWT
>  > profile (client to RS path) would wor= k better -
>  >
>  > Why would JWT completely t= ake over ? May be it should be possible indeed
>  > to have i= t as a JWT extension - should it be part of the relevant JWT
>  = > assertion spec, where JWT is used as a possible grant ?
>  >
>  > Thanks, Sergey
>  > >
>&nbs= p; > >
> ------------------------------------------------------= ------------------
>  > > *From:* Hannes Tschofenig <hannes.tschofenig@gmx.net
> <mailto:hannes.tschofenig@gmx.net>
>  > <mailto:hannes.tschofenig@gmx.net <mailto:hannes.tschof= enig@gmx.net>>>
>  > > *To:* William Mills &l= t;wmills_92105@yahoo.com
> <mailto:wmills_92105@yahoo.com>
>  > <mailto:wmills_92105@yahoo.com <mailto:wmills_92105@yahoo.com= >>>
>  > > *Cc:* Hannes Tschofenig <hannes.tschofenig@gmx.net
> <mailto:hannes= .tschofenig@gmx.net>
>  > <mailto:ha= nnes.tschofenig@gmx.net
> <mailto:hannes.tschofenig@gmx.net>= ;>>; "oauth@ietf.org
> <mailto:oauth@ietf.org>
>  &g= t; <mailto:oauth@ietf.org <mailto:oauth@ietf.org>>"
>  >= ; > <oauth@ietf.org <mailto:oauth@ietf.org> <mailto:oauth@ietf.org> <mailto:oauth@ietf.org>>>
>  > > *Sent:* Th= ursday, February 28, 2013 2:28 AM
>  > > *Subject:* Re: [OAUTH-WG] I-D Action:
&= gt; draft-ietf-oauth-v2-http-mac-03.txt
>  > >
>&nbs= p; > > Hi Bill,
>  > >
>  > > I bel= ieve you are misreading the document. In
>  > > draft-ietf= -oauth-v2-http-mac the client still uses the MAC when it
>  >= > accesses a protected resource.
>  > > The only place= where the JWT comes into the picture is with the
>  > > d= escription of the access token. This matters from a key distribution
>= ;  > > point of view. The session key for the MAC is included in= the encrypted
>  > > JWT. The JWT is encrypted by the aut= horization server and decrypted by
>  > > the resource ser= ver.
>  > >
>  > > Information about how = header fields get included in the MAC is
> described
>  > > in Section 5.
>  > >>  > > The nonce isn't killed it is just called differently:= seq-nr. The stuff
>  > > in the original MAC specificatio= n actually wasn't a nonce (from the
>  > > semantic point = of view).
>  > > The extension parameter is there implicit= ly by allowing additional
>  > > header fields to be inclu= ded in the MAC computation.
>  > >
>  > >= I need to look at the port number field again.
>  > >
= >  > > Ciao
>  > > Hannes
>  >= >
>  > > On Feb 27, 2013, at 11:12 AM, William Mills w= rote:
>  > >
>  > > > Just read the dr= aft quickly.
>  > > >
>  > > > Sinc= e we're now leaning on JWT do we need to include the token in
>  > > this? Why not just make an additional "Envelope= MAC" thing and have the
>  > > signature include the 3 JW= T parts in the signature base string? That
>  > > object t= hen just becomes a JSON container for the kid, timestamp,
>  >= ; > signature method, signature etc. That thing then is a 4th base64
= > encoded
>  > > JSON thing in the auth header.
>=   > > >
>  > > > How header fields get in= cluded in the signature needs definition.
>  > > >
&= gt;  > > > Why did you kill the port number, nonce, and exten= sion parameter out
>  > > of the signature base string?>  > > >
>  > > > The BNF appears to = have no separators between values.
>  > > >
>&nbs= p; > > > -bill
>  > > >
>  > > >
>  > > > From: "internet-d= rafts@ietf.org <mailto:internet-drafts@ietf.org>=
> <mailto:internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>>
>  > <mail= to:internet-drafts@ietf.org <mailto:intern= et-drafts@ietf.org>
> <mailto:internet-drafts@= ietf.org <mailto:internet-drafts@ietf.org>>>"
>&= nbsp; > > <internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>
> <mailto:internet-drafts@ietf.org <mailto:internet-drafts@iet= f.org>>
>  > <mailto:internet-draft= s@ietf.org <mailto:internet-drafts@ietf.org>
= > <mailto:internet-drafts@ietf.org <mailto:internet-dr= afts@ietf.org>>>>
>  > > > To: i= -d-announce@ietf.org <mailto:i-d-announce@ietf.org>> <mailto:i-d-announce@ietf.org <mailto:i-d-ann= ounce@ietf.org>>
>  > <mailto:i-d-announc= e@ietf.org <mailto:i-d-announce@ietf.org>
>= ; <mailto:i-d-announce@ietf.org <mailto:i-d-announc= e@ietf.org>>>
>  > > > Cc: oauth@ietf.org <= ;mailto:oauth@ietf.org> <mailto:oauth@ietf.org
> <mailto:oauth@ietf.org>> <mailto:oauth@ietf.org <mailto:oauth@ietf.org>
>  = > <mailto:oauth@iet= f.org <mailto:oauth@ietf.org>>>
>  > > > S= ent: Monday, February 25, 2013 4:46 AM
>  > > > Subject= : [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt
>  = > > >
>  > > >
>  > > > A = New Internet-Draft is available from the on-line Internet-Drafts
>&nb= sp; > > directories.
>  > > > This draft is a wor= k item of the Web Authorization Protocol Working
>  > > Gr= oup of the IETF.
>  > > >
>  > > > = Title : OAuth 2.0 Message Authentication Code (MAC) Tokens
>  &g= t; > > Author(s) : Justin Richer
>  > > > William= Mills
>  > > > Hannes Tschofenig
>  > > > Filename : draft-ietf-oauth-v2-http-mac-03.txt
>  >= ; > > Pages : 26
>  > > > Date : 2013-02-25
&g= t;  > > >
>  > > > Abstract:
> = ; > > > This specification describes how to use MAC Tokens in HTTP= requests
>  > > > to access OAuth 2.0 protected resour= ces. An OAuth client willing to
>  > > > access a prote= cted resource needs to demonstrate possession of a
>  > > = > crytographic key by using it with a keyed message digest function to>  > > > the request.
>  > > >
&g= t;  > > > The document also defines a key distribution protoc= ol for obtaining a
>  > > > fresh session key.
>&= nbsp; > > >
>  > > >
>  > > &= gt; The IETF datatracker status page for this draft is:
>  > > > https://datatracker.ietf= .org/doc/draft-ietf-oauth-v2-http-mac
>  > > >
&= gt;  > > > There's also a htmlized version available at:
&= gt;  > > > http://tools.ietf.org/html/draft-iet= f-oauth-v2-http-mac-03
>  > > >
>  > = > > A diff from the previous version is available at:
>  &= gt; > > http://www.ietf.org/rfcdiff?url2=3Ddraf= t-ietf-oauth-v2-http-mac-03
>  > > >
>  = > > >
>  > > > Internet-Drafts are also availa= ble by anonymous FTP at:
>  > > > ftp://ftp.i= etf.org/internet-drafts/
>  > > >
>  >= ; > > _______________________________________________
>  &= gt; > > OAuth mailing list
>  > > > OAuth@ietf.org &= lt;mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org
> <mailto:OAuth@ietf.org= >> <mailto:OAuth@ietf.org <mailto:OAuth@ietf.org>
> = ; > <mailto:OAuth@ietf.org <mailto:OAuth@ietf.org&g= t;>>
>  > > > https://www.ietf.org/mailman/listinf= o/oauth
>  > > >
>  > > >
&g= t;  > >
>  > >
>  > >
>&= nbsp; > >
>  > >
>  > > ___________= ____________________________________
>  > > OAuth mailing = list
>  > > OAuth@ietf.org <mailto:OAuth@ietf.org> <mai= lto:OAu= th@ietf.org
> <mailto:OAuth@ietf.org>>
>  &g= t; > https://www.ietf.org/mailman/listinfo/oauth
>  >>  >
>  > ______________________________________= _________
>  > OAuth mailing list
>  > OAuth@ietf.org<= /a> <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org
> <mailto:OAuth@iet= f.org>>
>  > https://www.ietf.org/mailman/listinfo/o= auth
>  >
>  >
>
>

=20
---125733401-1451799642-1362149779=:70391-- From prateek.mishra@oracle.com Fri Mar 1 07:00: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 463B911E80A2 for ; Fri, 1 Mar 2013 07:00:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.573 X-Spam-Level: X-Spam-Status: No, score=-6.573 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id phbQP0ZeKOUd for ; Fri, 1 Mar 2013 07:00:45 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 93AA021F92F8 for ; Fri, 1 Mar 2013 07:00:44 -0800 (PST) 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 r21F0hDn007112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 1 Mar 2013 15:00:44 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r21F0gjk017233 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Mar 2013 15:00:43 GMT Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r21F0gOR016655; Fri, 1 Mar 2013 09:00:42 -0600 Received: from [192.168.1.2] (/71.184.95.145) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 01 Mar 2013 07:00:42 -0800 Message-ID: <5130C2A0.2010100@oracle.com> Date: Fri, 01 Mar 2013 10:00:48 -0500 From: prateek mishra Organization: Oracle Corporation User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: John Bradley References: <1361830944.13340.YahooMailNeo@web31812.mail.mud.yahoo.com> <1361831644.50183.YahooMailNeo@web31801.mail.mud.yahoo.com> <1361832133.97884.YahooMailNeo@web31816.mail.mud.yahoo.com> <140EEABC-2787-4D9A-A1C5-6C973FED5BC8@adobe.com> <512FE091.9030508@oracle.com> <9C445AAF-BEE8-44F5-8FE6-43CA843906CC@ve7jtb.com> In-Reply-To: <9C445AAF-BEE8-44F5-8FE6-43CA843906CC@ve7jtb.com> Content-Type: multipart/alternative; boundary="------------060502090704010903030102" X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth2 attack surface.... X-BeenThere: oauth@ietf.org X-Mailman-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, 01 Mar 2013 15:00:46 -0000 This is a multi-part message in MIME format. --------------060502090704010903030102 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Yup, use of confidential clients and full checking of redirect URIs would mitigate these attacks. I think there is an issue of providing guidance to developers/deployers, about making secure choices, that needs to be addressed someplace. A test suite would also be a good complement to a document. One challenge is that OAuth addresses such a broad class of clients - from angry birds all the way to transactional apps. I am a mostly interested in the latter, it would be good to have a resource that i can point people to (and, yes, the TM document is good but I dont see it as something most developers/deployers would benefit from). - prateek > While implicit is what they are attacking, this is in principal also > possible to do with a code flow if the client is public. > It is only confidential clients using the code flow that have > reasonable protection from open redirectors. > > In openID Connect we made registered redirect_uri and full comparison > of the URI including query parameters a requirement. > > Allowing path or query parameters outside of the redirect comparison > leaves too large of an uncontrolled attack surface. > > Implementation mistakes are almost inevitable. > > John B. > On 2013-02-28, at 2:56 PM, prateek mishra > wrote: > >> Characteristics of both these attacks - >> >> 1) Use of implicit flow (access token passed on the URL) >> 2) changes to redirect uri (specification does allow some flexibility >> here) >> 3) applications with long-lived access tokens with broad scope (in >> one case only) >> >> - prateek >>> And a different one (still exploiting redirection and still >>> implementation mistake) >>> http://www.nirgoldshlager.com/2013/02/how-i-hacked-facebook-oauth-to-get-full.html >>> >>> >>> Regards >>> >>> Antonio >>> >>> On Feb 25, 2013, at 11:42 PM, William Mills wrote: >>> >>>> >>>> >>>> DOH!!! >>>> http://homakov.blogspot.co.uk/2013/02/hacking-facebook-with-oauth2-and-chrome.html >>>> >>>> ------------------------------------------------------------------------ >>>> *From:* Phil Hunt > >>>> *To:* William Mills >>> > >>>> *Sent:* Monday, February 25, 2013 2:28 PM >>>> *Subject:* Re: [OAUTH-WG] OAuth2 attack surface.... >>>> >>>> Whats the link? >>>> >>>> Phil >>>> >>>> Sent from my phone. >>>> >>>> On 2013-02-25, at 14:22, William Mills >>> > wrote: >>>> >>>>> I think this is worth a read, I don't have time to dive into this :( >>>>> _______________________________________________ >>>>> OAuth mailing 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 > --------------060502090704010903030102 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Yup, use of confidential clients and full checking of redirect URIs would mitigate these attacks.

I think there is an issue of providing guidance to developers/deployers, about making secure choices, that needs to be addressed someplace. A test suite
would also be a good complement to a document.

One challenge is that OAuth addresses such a broad class of clients - from angry birds all the way to transactional apps. I am a mostly interested
in the latter, it would be good to have a resource that i can point people to (and, yes, the TM document is good but I dont see it as something most developers/deployers would
 benefit from).

- prateek

While implicit is what they are attacking, this is in principal also possible to do with a code flow if the client is public.
It is only confidential clients using the code flow that have reasonable protection from open redirectors.

In openID Connect we made registered redirect_uri and full comparison of the URI including query parameters a requirement.

Allowing path or query parameters outside of the redirect comparison leaves too large of an uncontrolled attack surface.

Implementation mistakes are almost inevitable. 

John B.
On 2013-02-28, at 2:56 PM, prateek mishra <prateek.mishra@oracle.com> wrote:

Characteristics of both these attacks -

1) Use of implicit flow (access token passed on the URL)
2) changes to redirect uri (specification does allow some flexibility here)
3) applications with long-lived access tokens with broad scope (in one case only)

- prateek
And a different one (still exploiting redirection and still implementation mistake) http://www.nirgoldshlager.com/2013/02/how-i-hacked-facebook-oauth-to-get-full.html

Regards

Antonio

On Feb 25, 2013, at 11:42 PM, William Mills wrote:




From: Phil Hunt <phil.hunt@oracle.com>
To: William Mills <wmills_92105@yahoo.com>
Sent: Monday, February 25, 2013 2:28 PM
Subject: Re: [OAUTH-WG] OAuth2 attack surface....

Whats the link?

Phil

Sent from my phone.

On 2013-02-25, at 14:22, William Mills <wmills_92105@yahoo.com> wrote:

I think this is worth a read, I don't have time to dive into this :(
_______________________________________________
OAuth mailing 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


--------------060502090704010903030102-- From sberyozkin@gmail.com Fri Mar 1 07:43: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 D401F21E8051 for ; Fri, 1 Mar 2013 07:43:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.434 X-Spam-Level: X-Spam-Status: No, score=-3.434 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ruXFLWSPb39r for ; Fri, 1 Mar 2013 07:43:02 -0800 (PST) Received: from mail-ee0-f50.google.com (mail-ee0-f50.google.com [74.125.83.50]) by ietfa.amsl.com (Postfix) with ESMTP id B1EE521F935A for ; Fri, 1 Mar 2013 07:43:01 -0800 (PST) Received: by mail-ee0-f50.google.com with SMTP id e51so2543068eek.23 for ; Fri, 01 Mar 2013 07:43:01 -0800 (PST) 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=5gGvVE+ox/SUNkU0toa4nzASyRKgkO9B1CEUZZkab5E=; b=xruj9ukdkX4p6jtluDkn2JQ1A2vi/xsBMogghWOWMdIfwqYTIiMyC5fkIP5vxj4laT RJ0huBknL/jZ/IHmBT3u7ig1foCNOfsTy2SgHVX+2KEE1x8eIlqCwHUVurT6PQwyiRUf Mw2prnbZFpDFniBYap4SgTRSOptP7puIQcxfPFQL6Qb5WtzZZ7PdfSHeaPAIM0fEq46a BEKER5f3PnPzscuMSr8O4jMDv9iWMsxjCFltj3PPr2wRgM83Za66cRQsJNhWMNohqxL2 T9XUTQv/omuOvqAAJtaxzFd/SzMpL9mWLkLnDBaaSC1fYrQpAD+U3g3Bz8H4MtqECVhy G2jg== X-Received: by 10.14.219.129 with SMTP id m1mr28989661eep.16.1362152580833; Fri, 01 Mar 2013 07:43:00 -0800 (PST) Received: from [10.36.226.5] ([217.173.99.61]) by mx.google.com with ESMTPS id l8sm17752002een.10.2013.03.01.07.42.58 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 Mar 2013 07:42:58 -0800 (PST) Message-ID: <5130CC80.6060608@gmail.com> Date: Fri, 01 Mar 2013 15:42:56 +0000 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: William Mills References: <20130225124642.7425.65145.idtracker@ietfa.amsl.com> <1361956373.9883.YahooMailNeo@web31807.mail.mud.yahoo.com> <21030204-8EA7-4FB0-9DD3-2B6C8CA57E02@gmx.net> <1362057295.36069.YahooMailNeo@web31809.mail.mud.yahoo.com> <512F8E1D.2060408@gmail.com> <1362073743.15800.YahooMailNeo@web31802.mail.mud.yahoo.com> <512F9BB3.2010201@gmail.com> <1362074764.35520.YahooMailNeo@web31806.mail.mud.yahoo.com> <5130962C.9090408@gmail.com> <1362149779.70391.YahooMailNeo@web31807.mail.mud.yahoo.com> In-Reply-To: <1362149779.70391.YahooMailNeo@web31807.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 15:43:04 -0000 On 01/03/13 14:56, William Mills wrote: > The new signature base string stuff still needs work, I wanted to tackle > more major restructuring first. I want to pull all of those things out > of the query string. Well, thanks for keeping replying, but I'm not closer to connecting the above response to the latest MAC draft than I was earlier - guess I'm not seeing a bigger picture. Cheers, Sergey > > ------------------------------------------------------------------------ > *From:* Sergey Beryozkin > *To:* William Mills > *Cc:* "oauth@ietf.org" > *Sent:* Friday, March 1, 2013 3:51 AM > *Subject:* Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt > > I'm looking at [1] > > and I honestly don't follow what would adding JSON structure bring to > the table, the text there is quite straight-forward, and the 'sorting' > variable is not even there, may be, only if headers are *optionally* > included when calculating 'mac'. > > Are you indirectly referring to the idea of OAuth2 servers supporting an > OAuth1-style tokens which was proposed in the other thread by any > chance, as you mention "oath_..." parameters ? In that context, using > JWT extension may work, not really sure, but in context of [1] - I don't > understand where it would fit in > > Thanks, Sergey > > [1] > http://datatracker.ietf.org/doc/draft-ietf-oauth-v2-http-mac/?include_text=1 > > > On 28/02/13 18:06, William Mills wrote: > > I certainly hope so. > > > > ------------------------------------------------------------------------ > > *From:* Sergey Beryozkin > > > *To:* William Mills > > > *Cc:* "oauth@ietf.org " > > > *Sent:* Thursday, February 28, 2013 10:02 AM > > *Subject:* Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt > > > > On 28/02/13 17:49, William Mills wrote: > > > The JWT replaces the oauth_token data element in the old MAC stuff. I > > > just want to take all the other oauth_* variables and stuff them in a > > > separate JSON object and completely kill the "fun with sorting > > > variables" when the oauth_* things can be carried in the query > string or > > > header or post body. > > As far as the client accessing RS is concerned, should it be limited to > > using a header, same as for other OAuth2 tokens ? > > > > Cheers, Sergey > > > > > > > > > ------------------------------------------------------------------------ > > > *From:* Sergey Beryozkin > > >> > > > *To:* oauth@ietf.org > > > > *Sent:* Thursday, February 28, 2013 9:04 AM > > > *Subject:* Re: [OAUTH-WG] I-D Action: > draft-ietf-oauth-v2-http-mac-03.txt > > > > > > Hi > > > On 28/02/13 13:14, William Mills wrote: > > > > I'm actually advocating that we change MAC to be a JWT extension. > > > IMHO, having a simpler option, plus, going forward, a possible JWT > > > profile (client to RS path) would work better - > > > > > > Why would JWT completely take over ? May be it should be possible > indeed > > > to have it as a JWT extension - should it be part of the relevant JWT > > > assertion spec, where JWT is used as a possible grant ? > > > > > > Thanks, Sergey > > > > > > > > > > ------------------------------------------------------------------------ > > > > *From:* Hannes Tschofenig > > > > > > >>> > > > > *To:* William Mills > > > > > > > >>> > > > > *Cc:* Hannes Tschofenig > > > > > > > > >>>; "oauth@ietf.org > > > > > > > > >>" > > > > > > > >>> > > > > *Sent:* Thursday, February 28, 2013 2:28 AM > > > > *Subject:* Re: [OAUTH-WG] I-D Action: > > draft-ietf-oauth-v2-http-mac-03.txt > > > > > > > > Hi Bill, > > > > > > > > I believe you are misreading the document. In > > > > draft-ietf-oauth-v2-http-mac the client still uses the MAC when it > > > > accesses a protected resource. > > > > The only place where the JWT comes into the picture is with the > > > > description of the access token. This matters from a key distribution > > > > point of view. The session key for the MAC is included in the > encrypted > > > > JWT. The JWT is encrypted by the authorization server and > decrypted by > > > > the resource server. > > > > > > > > Information about how header fields get included in the MAC is > > described > > > > in Section 5. > > > > > > > > The nonce isn't killed it is just called differently: seq-nr. The > stuff > > > > in the original MAC specification actually wasn't a nonce (from the > > > > semantic point of view). > > > > The extension parameter is there implicitly by allowing additional > > > > header fields to be included in the MAC computation. > > > > > > > > I need to look at the port number field again. > > > > > > > > Ciao > > > > Hannes > > > > > > > > On Feb 27, 2013, at 11:12 AM, William Mills wrote: > > > > > > > > > Just read the draft quickly. > > > > > > > > > > Since we're now leaning on JWT do we need to include the token in > > > > this? Why not just make an additional "Envelope MAC" thing and > have the > > > > signature include the 3 JWT parts in the signature base string? That > > > > object then just becomes a JSON container for the kid, timestamp, > > > > signature method, signature etc. That thing then is a 4th base64 > > encoded > > > > JSON thing in the auth header. > > > > > > > > > > How header fields get included in the signature needs definition. > > > > > > > > > > Why did you kill the port number, nonce, and extension > parameter out > > > > of the signature base string? > > > > > > > > > > The BNF appears to have no separators between values. > > > > > > > > > > -bill > > > > > > > > > > > > > > > From: "internet-drafts@ietf.org > > > > > >> > > > > > > > > >>>" > > > > > > > > > >> > > > > > > > > >>>> > > > > > To: i-d-announce@ietf.org > > > > > >> > > > > > > > > >>> > > > > > Cc: oauth@ietf.org > > > > >> > > > > > > >>> > > > > > Sent: Monday, February 25, 2013 4:46 AM > > > > > Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt > > > > > > > > > > > > > > > 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 Message Authentication Code (MAC) Tokens > > > > > Author(s) : Justin Richer > > > > > William Mills > > > > > Hannes Tschofenig > > > > > Filename : draft-ietf-oauth-v2-http-mac-03.txt > > > > > Pages : 26 > > > > > Date : 2013-02-25 > > > > > > > > > > Abstract: > > > > > This specification describes how to use MAC Tokens in HTTP requests > > > > > to access OAuth 2.0 protected resources. An OAuth client willing to > > > > > access a protected resource needs to demonstrate possession of a > > > > > crytographic key by using it with a keyed message digest > function to > > > > > the request. > > > > > > > > > > The document also defines a key distribution protocol for > obtaining a > > > > > fresh session key. > > > > > > > > > > > > > > > The IETF datatracker status page for this draft is: > > > > > https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-http-mac > > > > > > > > > > There's also a htmlized version available at: > > > > > http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-03 > > > > > > > > > > A diff from the previous version is available at: > > > > > http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-v2-http-mac-03 > > > > > > > > > > > > > > > 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 > > > > > > > > > _______________________________________________ > > > OAuth mailing list > > > OAuth@ietf.org > > > >> > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > > > > From asanso@adobe.com Fri Mar 1 07:44: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 0BD2F21E8051 for ; Fri, 1 Mar 2013 07:44:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.099 X-Spam-Level: X-Spam-Status: No, score=-105.099 tagged_above=-999 required=5 tests=[AWL=1.499, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4dKwWkStZyOh for ; Fri, 1 Mar 2013 07:44:16 -0800 (PST) Received: from exprod6og113.obsmtp.com (exprod6og113.obsmtp.com [64.18.1.31]) by ietfa.amsl.com (Postfix) with ESMTP id 45AF321F935C for ; Fri, 1 Mar 2013 07:44:14 -0800 (PST) Received: from outbound-smtp-1.corp.adobe.com ([192.150.11.134]) by exprod6ob113.postini.com ([64.18.5.12]) with SMTP ID DSNKUTDMzY2B3Cx5r7BHEwKpN9svnFwwYlrB@postini.com; Fri, 01 Mar 2013 07:44:15 PST Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r21Ff71v024749; Fri, 1 Mar 2013 07:41:07 -0800 (PST) Received: from nahub02.corp.adobe.com (nahub02.corp.adobe.com [10.8.189.98]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r21FiDAV014553; Fri, 1 Mar 2013 07:44:13 -0800 (PST) Received: from eurcas01.eur.adobe.com (10.128.4.27) by nahub02.corp.adobe.com (10.8.189.98) with Microsoft SMTP Server (TLS) id 8.3.298.1; Fri, 1 Mar 2013 07:44:13 -0800 Received: from eurmbx01.eur.adobe.com ([10.128.4.32]) by eurcas01.eur.adobe.com ([10.128.4.27]) with mapi; Fri, 1 Mar 2013 15:44:11 +0000 From: Antonio Sanso To: prateek mishra Date: Fri, 1 Mar 2013 15:44:09 +0000 Thread-Topic: [OAUTH-WG] OAuth2 attack surface.... Thread-Index: Ac4Wk53t8ZrZ1qwCTQqPZiXz6kZmaA== Message-ID: <0F011ABB-B431-47A4-8EE8-F24BBB6B6549@adobe.com> References: <1361830944.13340.YahooMailNeo@web31812.mail.mud.yahoo.com> <1361831644.50183.YahooMailNeo@web31801.mail.mud.yahoo.com> <1361832133.97884.YahooMailNeo@web31816.mail.mud.yahoo.com> <140EEABC-2787-4D9A-A1C5-6C973FED5BC8@adobe.com> <512FE091.9030508@oracle.com> <9C445AAF-BEE8-44F5-8FE6-43CA843906CC@ve7jtb.com> <5130C2A0.2010100@oracle.com> In-Reply-To: <5130C2A0.2010100@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_0F011ABBB43147A48EE8F24BBB6B6549adobecom_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth2 attack surface.... X-BeenThere: oauth@ietf.org X-Mailman-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, 01 Mar 2013 15:44:17 -0000 --_000_0F011ABBB43147A48EE8F24BBB6B6549adobecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Mar 1, 2013, at 4:00 PM, prateek mishra wrote: Yup, use of confidential clients and full checking of redirect URIs would m= itigate these attacks. I think there is an issue of providing guidance to developers/deployers, ab= out making secure choices, that needs to be addressed someplace. A test sui= te would also be a good complement to a document. do you mean having a TCK for OAuth 2.0? One challenge is that OAuth addresses such a broad class of clients - from = angry birds all the way to transactional apps. I am a mostly interested in the latter, it would be good to have a resource that i can point people = to (and, yes, the TM document is good but I dont see it as something most d= evelopers/deployers would benefit from). - prateek While implicit is what they are attacking, this is in principal also possib= le to do with a code flow if the client is public. It is only confidential clients using the code flow that have reasonable pr= otection from open redirectors. In openID Connect we made registered redirect_uri and full comparison of th= e URI including query parameters a requirement. Allowing path or query parameters outside of the redirect comparison leaves= too large of an uncontrolled attack surface. Implementation mistakes are almost inevitable. John B. On 2013-02-28, at 2:56 PM, prateek mishra > wrote: Characteristics of both these attacks - 1) Use of implicit flow (access token passed on the URL) 2) changes to redirect uri (specification does allow some flexibility here) 3) applications with long-lived access tokens with broad scope (in one case= only) - prateek And a different one (still exploiting redirection and still implementation = mistake) http://www.nirgoldshlager.com/2013/02/how-i-hacked-facebook-oauth-= to-get-full.html Regards Antonio On Feb 25, 2013, at 11:42 PM, William Mills wrote: DOH!!! http://homakov.blogspot.co.uk/2013/02/hacking-facebook-with-oauth2-= and-chrome.html ________________________________ From: Phil Hunt > To: William Mills > Sent: Monday, February 25, 2013 2:28 PM Subject: Re: [OAUTH-WG] OAuth2 attack surface.... Whats the link? Phil Sent from my phone. On 2013-02-25, at 14:22, William Mills > wrote: I think this is worth a read, I don't have time to dive into this :( _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_0F011ABBB43147A48EE8F24BBB6B6549adobecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
On Mar 1, 20= 13, at 4:00 PM, prateek mishra wrote:

Yup, use of confidential clients and full checking of redirect URIs would mitigate these attacks.

I think there is an issue of providing guidance to developers/deployers, about making secure choices, that needs to be addressed someplace. A test suite
would also be a good complement to a document.

do you mean having a TCK for OAuth 2.0?



One challenge is that OAuth addresses such a broad class of clients - from angry birds all the way to transactional apps. I am a mostly interested
in the latter, it would be good to have a resource that i can point people to (and, yes, the TM document is good but I dont see it as something most developers/deployers would
 benefit from).

- prateek

=20 While implicit is what they are attacking, this is in principal also possible to do with a code flow if the client is public.
It is only confidential clients using the code flow that have reasonable protection from open redirectors.

In openID Connect we made registered redirect_uri and full comparison of the URI including query parameters a requirement.

Allowing path or query parameters outside of the redirect comparison leaves too large of an uncontrolled attack surface.

Implementation mistakes are almost inevitable. 

John B.
On 2013-02-28, at 2:56 PM, prateek mishra <prateek.mishra@orac= le.com> wrote:

=20
Characteristics of both these attacks -

1) Use of implicit flow (access token passed on the URL)
2) changes to redirect uri (specification does allow some flexibility here)
3) applications with long-lived access tokens with broad scope (in one case only)

- prateek
And a different one (still exploiting redirection and still implementation mistake) http://www.nirgoldshlager.com/2013/02/= how-i-hacked-facebook-oauth-to-get-full.html

Regards

Antonio

On Feb 25, 2013, at 11:42 PM, William Mills wrote:




From: Phil Hunt <phil.hunt@oracle.com>= ;
To: William Mills <wmills_92105@yahoo.co= m>
Sent: Monday, February 25, 2013 2:28 PM
Subject: Re: [OAUTH-WG] OAuth2 attack surface....

Whats the link?

Phil

Sent from my phone.

On 2013-02-25, at 14:22, William Mills <wmills_92105@yaho= o.com> wrote:

I think this is worth a read, I don't have time to dive into this :(
__________________= _____________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth<= br>




_______________________________________________
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

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


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

= --_000_0F011ABBB43147A48EE8F24BBB6B6549adobecom_-- From Michael.Jones@microsoft.com Fri Mar 1 09:34: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 6F96E21F92B3 for ; Fri, 1 Mar 2013 09:34:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JS+jlVVlSEtr for ; Fri, 1 Mar 2013 09:34:21 -0800 (PST) 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 63F5F21F92B8 for ; Fri, 1 Mar 2013 09:34:21 -0800 (PST) Received: from BY2FFO11FD023.protection.gbl (10.1.15.204) by BY2FFO11HUB010.protection.gbl (10.1.14.80) with Microsoft SMTP Server (TLS) id 15.0.620.12; Fri, 1 Mar 2013 17:29:41 +0000 Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD023.mail.protection.outlook.com (10.1.15.212) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Fri, 1 Mar 2013 17:29:41 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.132]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.02.0318.003; Fri, 1 Mar 2013 17:25:29 +0000 From: Mike Jones To: Justin Richer Thread-Topic: [OAUTH-WG] Registration: grant_types and response_types Thread-Index: AQHOFQO5d+0IWPQvz0CRM0gUCtYnPJiOSukwgAEfRwCAAa6IMA== Date: Fri, 1 Mar 2013 17:25:28 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943674CF79B@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <512E2D7F.6060903@mitre.org> <4E1F6AAD24975D4BA5B1680429673943674BC644@TK5EX14MBXC283.redmond.corp.microsoft.com> <512F7AB8.7080109@mitre.org> In-Reply-To: <512F7AB8.7080109@mitre.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.34] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943674CF79BTK5EX14MBXC283r_" 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)(57704001)(479174001)(50854002)(199002)(55885001)(189002)(24454001)(56816002)(47736001)(55846006)(54316002)(15395725002)(74502001)(44976002)(80022001)(33656001)(46102001)(66066001)(59766001)(76482001)(65816001)(512954001)(77982001)(4396001)(53806001)(15202345001)(16297215001)(79102001)(49866001)(63696002)(31966008)(56776001)(51856001)(5343645001)(20776003)(50986001)(47976001)(16406001)(47446002)(551544001)(74662001)(16236675001)(54356001)(5343635001)(5343655001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB010; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0772E5DAD5 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Registration: grant_types and response_types X-BeenThere: oauth@ietf.org X-Mailman-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, 01 Mar 2013 17:34:25 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943674CF79BTK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Agreed, servers could enforce that combinations that don't make sense resul= t in errors. BTW, OpenID Connect decided to keep both parameters for registration, since= they're not actually orthogonal. While verbose, at least then the registr= ation information about what grant types and response types the client is c= hoosing to limit itself to using can be accurate. We also decided that if these parameters are omitted, the default values ar= e "code" and "authorization_code". Best wishes, -- Mike From: Justin Richer [mailto:jricher@mitre.org] Sent: Thursday, February 28, 2013 7:42 AM To: Mike Jones Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Registration: grant_types and response_types The good thing about having two fields is that they map to the two differen= t parameter names directly. The trouble is that you could get in a situatio= n where a client can't actually do anything, say if you register response t= ype "token" and grant type "authorization_code". With a table like the one = below, we can help developers see what the right mappings should be and hel= p servers to enforce this. Thoughts? -- Justin On 02/27/2013 05:52 PM, Mike Jones wrote: John Bradley and I just talked about this during a side meeting at RSA. We= think that this is the mapping of grant types and defined response types. = (The additional response_type values are registered with IANA and defined = in http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html.) response_type value grant_types code authorization_code token implicit id_token implicit token id_token implicit code token authorization_code implicit code id_token authorization_code implicit code token id_token authorization_code implicit none none If people agree that this is the mapping, and that it conveys sufficient in= formation, then conceivably OpenID Connect could drop the response_types re= gistration parameter and instead just use the OAuth Registration "grant_typ= es" parameter. What do others think? -- Mike P.S. There's a typo in the OAuth Registration spec section quoted below. = The name "grant_type" should have been "grant_types", since the value is a = list. We should correct that in the next version of the spec. From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Justin Richer Sent: Wednesday, February 27, 2013 8:00 AM To: oauth@ietf.org Subject: [OAUTH-WG] Registration: grant_types and response_types There has been some press lately about clients being able to use an implici= t flow to get tokens when they really ought to only use a code flow, since = the security considerations and protections for both are very different. Wi= th this in mind, it makes sense that a dynamically registered client should= be limited to use only certain flows, if at all possible. The dynamic registration document currently handles this using the grant_ty= pe parameter (introduced in draft -03), which is defined in section 2 as fo= llows: grant_type OPTIONAL. Array of grant types that a client may use. These grant types are defined as follows: * "authorization_code": The Authorization Code Grant described in OAuth2 Section 4.1. * "implicit": The Implicit Grant described in OAuth2 Section 4.2. * "password": The Resource Owner Password Credentials Grant described in OAuth2 Section 4.3 * "client_credentials": The Client Credentials Grant described in OAuth2 Section 4.4 * "refresh_token": The Refresh Token Grant described in OAuth2 Section 6. Authorization Servers MAY allow for other values as defined in grant type extensions to OAuth2. The extension process is described in OAuth2 Section 2.5, and the value of this parameter MUST be the same as the value of the "grant_type" parameter defined in the extension. This allows the client to specify which flows it wants to be able to use (i= ncluding any extensions), and allows the server to to tell the client in th= e client configuration response what flows it can expect to work. OpenID Connect's registration has recently introduced the use of a differen= t parameter, response_type, for a similar but slightly different purpose. T= he parameter is defined in the latest draft in source control as: response_types OPTIONAL. JSON array containing a list of the OAuth 2.0 response_type values that this Client uses. If omitted, the default is that the Client uses only the code response type. OIDC makes use of response_types beyond just "code" and "token", defining s= everal new ones including combinations like "code idtoken". So my question to the group is this: Should we incorporate the OIDC respons= e_types parameter? Do we need both parameters specified in the registration= or is one sufficient? They're defined separately in the OAuth2 protocol (o= ne is on the Auth endpoint and one is on the Token endpoint), but can only = be used legally in particular combinations so there would have to be normat= ive text around particular values. In my opinion, I don't think we can get rid of grant_type, since that's the= only way to specify things like client_credentials flows and most extensio= ns. There might be value in also specifying response_type, but I don't want= to add extra fields unless there's a clearly defined need for it. -- Justin --_000_4E1F6AAD24975D4BA5B1680429673943674CF79BTK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Agreed, servers could enf= orce that combinations that don’t make sense result in errors.

 <= /p>

BTW, OpenID Connect decid= ed to keep both parameters for registration, since they’re not actual= ly orthogonal.  While verbose, at least then the registration information about what grant types and response types the client is choosi= ng to limit itself to using can be accurate.

 <= /p>

We also decided that if t= hese parameters are omitted, the default values are “code” and = “authorization_code”.

 <= /p>

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;     Best wishes,

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

 <= /p>

From: Justin Richer [mailto:jricher@mitre.org]
Sent: Thursday, February 28, 2013 7:42 AM
To: Mike Jones
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Registration: grant_types and response_types=

 

The good thing about = having two fields is that they map to the two different parameter names dir= ectly. The trouble is that you could get in a situation where a client can'= t actually do anything, say if you register response type "token" and grant type "authorization_code&qu= ot;. With a table like the one below, we can help developers see what the r= ight mappings should be and help servers to enforce this.

Thoughts?

 -- Justin

On 02/27/2013 05:52 PM, Mike Jones wrote:=

John Bradley and I just t= alked about this during a side meeting at RSA.  We think that this is = the mapping of grant types and defined response types.  (The additional response_type values are registered with IANA and defined in http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html.)

 <= /p>

response_type value

grant_types=

code

authorization_code=

token

implicit

id_token

implicit

token id_token

implicit

code token

authorization_code implic= it

code id_token=

authorization_code implic= it

code token id_token

authorization_code implic= it

none

none

 <= /p>

If people agree that this= is the mapping, and that it conveys sufficient information, then conceivab= ly OpenID Connect could drop the response_types registration parameter and instead just use the OAuth Registration “grant_types&#= 8221; parameter.

 <= /p>

What do others think?

 <= /p>

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

 <= /p>

P.S.  There’s = a typo in the OAuth Registration spec section quoted below.  The name = “grant_type” should have been “grant_types”, since = the value is a list.  We should correct that in the next version of the spec.<= /p>

 <= /p>

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Justin Richer
Sent: Wednesday, February 27, 2013 8:00 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Registration: grant_types and response_types

 

There has been some p= ress lately about clients being able to use an implicit flow to get tokens = when they really ought to only use a code flow, since the security consider= ations and protections for both are very different. With this in mind, it makes sense that a dynamically regis= tered client should be limited to use only certain flows, if at all possibl= e.

The dynamic registration document currently handles this using the grant_ty= pe parameter (introduced in draft -03), which is defined in section 2 as fo= llows:

   grant_type
      OPTIONAL.  Array of grant types th=
at a client may use.  These
      grant types are defined as follows:
 
      *  "authorization_code":=
 The Authorization Code Grant described in
         OAuth2 Section 4.=
1.
 
      *  "implicit": The Impli=
cit Grant described in OAuth2 Section 4.2.
 
      *  "password": The Resou=
rce Owner Password Credentials Grant
         described in OAuth2 <=
a href=3D"http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-07#section-4.=
3">Section 4.3
 
      *  "client_credentials":=
 The Client Credentials Grant described in
         OAuth2 Section 4.=
4
 
      *  "refresh_token": The =
Refresh Token Grant described in OAuth2
         Section 6.=

 
      Authorization Servers MAY allow for oth=
er values as defined in
      grant type extensions to OAuth2.  =
The extension process is
      described in OAuth2 Section 2.5=
, and the value of this parameter
      MUST be the same as the value of the &q=
uot;grant_type" parameter
      defined in the extension.



This allows the client to specify which flows it wants to be able to use (i=
ncluding any extensions), and allows the server to to tell the client in th=
e client configuration response what flows it can expect to work.




OpenID Connect's registration has recently introduced the use of a differen=
t parameter, response_type, for a similar but slightly different purpose. T=
he parameter is defined in the latest draft in source control as:


response_types<=
/span>


OPTIONAL. JSON array containing a list of the OAuth 2.0 respons=
e_type



values that this Client uses. If omitted, the default is that t=
he Client



uses only the code response type.





OIDC makes use of response_types beyond just "code" and "tok=
en", defining several new ones including combinations like "code =
idtoken".



So my question to the group is this: Should we incor=
porate the OIDC response_types parameter? Do we need both parameters specif=
ied in the registration or is one sufficient? They're defined separately in=
 the OAuth2 protocol (one is on the
 Auth endpoint and one is on the Token endpoint), but can only be used lega=
lly in particular combinations so there would have to be normative text aro=
und particular values.



In my opinion, I don't think we can get rid of grant_type, since that's the=
 only way to specify things like client_credentials flows and most extensio=
ns. There might be value in also specifying response_type, but I don't want=
 to add extra fields unless there's
 a clearly defined need for it.



 -- Justin

 

--_000_4E1F6AAD24975D4BA5B1680429673943674CF79BTK5EX14MBXC283r_-- From prateek.mishra@oracle.com Fri Mar 1 10:50: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 DF65821E809E for ; Fri, 1 Mar 2013 10:50:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.576 X-Spam-Level: X-Spam-Status: No, score=-6.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yD6KKUgOo3o4 for ; Fri, 1 Mar 2013 10:50:34 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 0A2AB21E803F for ; Fri, 1 Mar 2013 10:50:33 -0800 (PST) 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 r21IoSe0019216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 1 Mar 2013 18:50:29 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r21IoR0W021505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Mar 2013 18:50:28 GMT Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r21IoRXF009091; Fri, 1 Mar 2013 12:50:27 -0600 Received: from [10.152.55.88] (/10.152.55.88) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 01 Mar 2013 10:50:27 -0800 Message-ID: <5130F872.8060907@oracle.com> Date: Fri, 01 Mar 2013 13:50:26 -0500 From: prateek mishra Organization: Oracle Corporation User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Antonio Sanso References: <1361830944.13340.YahooMailNeo@web31812.mail.mud.yahoo.com> <1361831644.50183.YahooMailNeo@web31801.mail.mud.yahoo.com> <1361832133.97884.YahooMailNeo@web31816.mail.mud.yahoo.com> <140EEABC-2787-4D9A-A1C5-6C973FED5BC8@adobe.com> <512FE091.9030508@oracle.com> <9C445AAF-BEE8-44F5-8FE6-43CA843906CC@ve7jtb.com> <5130C2A0.2010100@oracle.com> <0F011ABB-B431-47A4-8EE8-F24BBB6B6549@adobe.com> In-Reply-To: <0F011ABB-B431-47A4-8EE8-F24BBB6B6549@adobe.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth2 attack surface.... X-BeenThere: oauth@ietf.org X-Mailman-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, 01 Mar 2013 18:50:35 -0000 > > On Mar 1, 2013, at 4:00 PM, prateek mishra wrote: > >> Yup, use of confidential clients and full checking of redirect URIs >> would mitigate these attacks. >> >> I think there is an issue of providing guidance to >> developers/deployers, about making secure choices, that needs to be >> addressed someplace. A test suite >> would also be a good complement to a document. > > do you mean having a TCK for OAuth 2.0? > > Yes, that is the general direction I was thinking of but in a language independent format. An example is the XACML 2.0 conformance suite: https://www.oasis-open.org/committees/download.php/14846/xacml2.0-ct-v.0.4.zip Of course, testing AS and RS would involve network exchanges, so it would be a bit more involved... From ve7jtb@ve7jtb.com Sat Mar 2 09:13: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 57AEA21F84C9 for ; Sat, 2 Mar 2013 09:13:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.475 X-Spam-Level: X-Spam-Status: No, score=-3.475 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jGqVoFdy1SBl for ; Sat, 2 Mar 2013 09:13:26 -0800 (PST) Received: from mail-pb0-f42.google.com (mail-pb0-f42.google.com [209.85.160.42]) by ietfa.amsl.com (Postfix) with ESMTP id 36EF421F855A for ; Sat, 2 Mar 2013 09:13:25 -0800 (PST) Received: by mail-pb0-f42.google.com with SMTP id xb4so2319957pbc.15 for ; Sat, 02 Mar 2013 09:13:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:from:content-type:subject:message-id:date:to :mime-version:x-mailer:x-gm-message-state; bh=ZJYDDnqQFusDxFPkRKgelqWBV5a2i9IXF78wLiyLmLM=; b=apKCfHGgWux64+QVtkZ23aYZd0spygqH3leHlPxe2l4bqmzF4oIKbpSR8xL82mX+Ot WAsHg5xaLVMSXJdS4u4oPtmKPapvgKFivtGL/Ssr38pSpCWica+XaMGyAxeKig5+EaR2 ZcLcZ03uyebA4DTjsrrB3uyJCCr9JBECrsSSAsu8NFYMOUexOjU0fiPK+nzQjKr+Vrzf CSCdxqVY1XnqnXJ0Fenm3CzuNDqCqkUQ2UifoGXXeGwj3NspnTlpl+FLFGzBV65PheIr T5rzhmllNrl+ya0bGjbctwvDk2vj1lAZnGLfdfOdXQw/VoskSVyBzY7SFEbV7nfTZV72 gJYQ== X-Received: by 10.68.197.106 with SMTP id it10mr7411950pbc.22.1362244404926; Sat, 02 Mar 2013 09:13:24 -0800 (PST) Received: from [192.168.10.62] (ip-64-134-234-74.public.wayport.net. [64.134.234.74]) by mx.google.com with ESMTPS id ax3sm16067265pbd.42.2013.03.02.09.13.21 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 02 Mar 2013 09:13:22 -0800 (PST) From: John Bradley Content-Type: multipart/signed; boundary="Apple-Mail=_FD8933B5-7B61-49D4-8909-3E97D5F94CB4"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: <84036CCA-8C25-48CD-9699-700078670780@ve7jtb.com> Date: Sat, 2 Mar 2013 09:13:20 -0800 To: Group Group , "openid-connect-interop@googlegroups.com" , "oauth@ietf.org WG" , "" , "webfinger@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQmVxRzXvyySLeHeWAJZCZh53C5HQiDyDeyYruxcf3JSFSuyO6TXFi9WZ0S3+2SMG7aF+3z+ Subject: [OAUTH-WG] Meeting for people interested in OpenID Connect at IETF#86 in Sun Mar 10 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 17:13:27 -0000 --Apple-Mail=_FD8933B5-7B61-49D4-8909-3E97D5F94CB4 Content-Type: multipart/alternative; boundary="Apple-Mail=_8920E6B0-A5E9-4B2B-99C8-5E528DBD184E" --Apple-Mail=_8920E6B0-A5E9-4B2B-99C8-5E528DBD184E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The eventbrite page for people wanting to attend the openID Connect = session prior to IETF86 is now available at: http://openid-ietf-86.eventbrite.com/ Please register if you are planning on coming. We will add the room = once we know it. Regards John Bradley= --Apple-Mail=_8920E6B0-A5E9-4B2B-99C8-5E528DBD184E Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii The eventbrite page for people wanting to attend the openID Connect session prior to IETF86 is now available at:

Please register if you are planning on coming.  We will add the room once we know it.

Regards
John Bradley
--Apple-Mail=_8920E6B0-A5E9-4B2B-99C8-5E528DBD184E-- --Apple-Mail=_FD8933B5-7B61-49D4-8909-3E97D5F94CB4 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 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMzAyMTcxMzIxWjAjBgkqhkiG9w0BCQQxFgQUNoGZ2ZF5 43lTgpmapQmFYpwMg2EwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAIW2CiOGThcHh69152zdqtxx1RKIZBrWHR86vbKhN xXpJREwnOvnCatyLPsX/HR/4TqWhkzYcPe7Hx42+FhSh1PHpXFUU4oO4dwIYum2p5CgEH4xXellC atLaKwzMuoDwS6AN15dZuUljT6Tmg+0vZdHZJ6vvxjSBkdWqlJeLWXZ/PWiyUBjFQW+xw/SunlYR QwqsDSLgdNIaAx06hwVQ8StZj9zWjQdR0HV7AESKnM/KNcaEPOcdEiA1GYvhPVMvwwz2Chp6Cemd CkBs4AtDi3WG6vSqV/1K3+yEe2w6nSzBd+dyvkDawafNG3nNUvGIKYuLu5qa4guKioLalZCzuwAA AAAAAA== --Apple-Mail=_FD8933B5-7B61-49D4-8909-3E97D5F94CB4-- From barryleiba.mailing.lists@gmail.com Sat Mar 2 11:57:41 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 91A3121F85A2; Sat, 2 Mar 2013 11:57:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.992 X-Spam-Level: X-Spam-Status: No, score=-102.992 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 464b7KErV3PC; Sat, 2 Mar 2013 11:57:40 -0800 (PST) Received: from mail-ve0-f177.google.com (mail-ve0-f177.google.com [209.85.128.177]) by ietfa.amsl.com (Postfix) with ESMTP id 7535821F849A; Sat, 2 Mar 2013 11:57:40 -0800 (PST) Received: by mail-ve0-f177.google.com with SMTP id m1so3764575ves.8 for ; Sat, 02 Mar 2013 11:57:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Lr0I1q4lLE88WKKSdKsegfB0+tVEdC0TJlVnrmC/d9c=; b=014WEoi13u7+0jvm0BE4CUhUM8jBidcDWCIl6d+SL3bqTneJb/BRp5Ba/+Y9Qbbga/ x6180K5SjH9TLsV8X9sXzVjNkht2L5/WteHE/S5RM2JlSBcPhaHYpDPs5FfxgpyC5XlF PvOrnT/iCX32i8pWHChE5kcECdbJwQpz7ERJpc1sUrLsfMZ7z4x/792QX5RERmH/yZWY SI9r1B1nw7pqCU38fWDWPTOYVP2okJyWLOC/VryVUaMdYW+zYoFuA5iRJRe7yBQmJg7F Y5XvhDmLINllqxNSTCSCw4L0HcOmpNgpdtJ92uezXSwevUC5+cjqKisPNiWTRtBuAu4c RWCQ== MIME-Version: 1.0 X-Received: by 10.220.151.5 with SMTP id a5mr5713630vcw.22.1362254259904; Sat, 02 Mar 2013 11:57:39 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.59.3.41 with HTTP; Sat, 2 Mar 2013 11:57:39 -0800 (PST) In-Reply-To: <84036CCA-8C25-48CD-9699-700078670780@ve7jtb.com> References: <84036CCA-8C25-48CD-9699-700078670780@ve7jtb.com> Date: Sat, 2 Mar 2013 14:57:39 -0500 X-Google-Sender-Auth: pIhd1ejxGyjlivjoBjTUS8778as Message-ID: From: Barry Leiba To: John Bradley Content-Type: text/plain; charset=ISO-8859-1 Cc: "openid-connect-interop@googlegroups.com" , Group Group , "oauth@ietf.org WG" , "" , "webfinger@ietf.org" Subject: Re: [OAUTH-WG] Meeting for people interested in OpenID Connect at IETF#86 in Sun Mar 10 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 19:57:41 -0000 > The eventbrite page for people wanting to attend the openID Connect session > prior to IETF86 is now available at: > http://openid-ietf-86.eventbrite.com/ That page says this: OpenID Meeting at IETF 86 The OpenID Foundation Thursday, April 11, 2013 from 1:00 PM to 4:00 PM (EDT) Orlando, FL I do hope it means Thursday, 7 March. 11 April is about a month *after* the IETF meeting. Barry From tonynad@microsoft.com Sat Mar 2 16:13:00 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 15AD521F85BF; Sat, 2 Mar 2013 16:13:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.533 X-Spam-Level: X-Spam-Status: No, score=0.533 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GnaaFHd1K8gw; Sat, 2 Mar 2013 16:12:59 -0800 (PST) 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 368F521F84B9; Sat, 2 Mar 2013 16:12:59 -0800 (PST) Received: from BL2FFO11FD008.protection.gbl (10.173.161.203) by BL2FFO11HUB010.protection.gbl (10.173.161.112) with Microsoft SMTP Server (TLS) id 15.0.620.12; Sun, 3 Mar 2013 00:12:57 +0000 Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD008.mail.protection.outlook.com (10.173.161.4) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Sun, 3 Mar 2013 00:12:57 +0000 Received: from am1outboundpool.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; Sun, 3 Mar 2013 00:12:55 +0000 Received: from mail16-am1-R.bigfish.com (10.3.201.228) by AM1EHSOBE022.bigfish.com (10.3.207.144) with Microsoft SMTP Server id 14.1.225.23; Sun, 3 Mar 2013 00:12:50 +0000 Received: from mail16-am1 (localhost [127.0.0.1]) by mail16-am1-R.bigfish.com (Postfix) with ESMTP id 055AF4402C4; Sun, 3 Mar 2013 00:12:50 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT003.namprd03.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -17 X-BigFish: PS-17(zz9371I542Izz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ah1082kzz1033IL17326ah8275bh8275dhz31h2a8h668h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h9a9j1155h) Received-SPF: softfail (mail16-am1: 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=BL2PRD0310HT003.namprd03.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BY2PR03MB042; H:BY2PR03MB041.namprd03.prod.outlook.com; LANG:en; Received: from mail16-am1 (localhost.localdomain [127.0.0.1]) by mail16-am1 (MessageSwitch) id 1362269563418841_14662; Sun, 3 Mar 2013 00:12:43 +0000 (UTC) Received: from AM1EHSMHS010.bigfish.com (unknown [10.3.201.238]) by mail16-am1.bigfish.com (Postfix) with ESMTP id 625233600E5; Sun, 3 Mar 2013 00:12:43 +0000 (UTC) Received: from BL2PRD0310HT003.namprd03.prod.outlook.com (157.56.240.21) by AM1EHSMHS010.bigfish.com (10.3.207.110) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sun, 3 Mar 2013 00:12:43 +0000 Received: from BY2PR03MB042.namprd03.prod.outlook.com (10.255.241.146) by BL2PRD0310HT003.namprd03.prod.outlook.com (10.255.97.38) with Microsoft SMTP Server (TLS) id 14.16.275.5; Sun, 3 Mar 2013 00:12:42 +0000 Received: from BY2PR03MB041.namprd03.prod.outlook.com (10.255.241.145) by BY2PR03MB042.namprd03.prod.outlook.com (10.255.241.146) with Microsoft SMTP Server (TLS) id 15.0.620.20; Sun, 3 Mar 2013 00:12:40 +0000 Received: from BY2PR03MB041.namprd03.prod.outlook.com ([169.254.7.143]) by BY2PR03MB041.namprd03.prod.outlook.com ([169.254.7.231]) with mapi id 15.00.0620.020; Sun, 3 Mar 2013 00:12:40 +0000 From: Anthony Nadalin To: Barry Leiba , John Bradley Thread-Topic: [jose] [OAUTH-WG] Meeting for people interested in OpenID Connect at IETF#86 in Sun Mar 10 Thread-Index: AQHOF4A8v0OPDTa670Gnsm2UmNnS0piTGJXA Date: Sun, 3 Mar 2013 00:12:39 +0000 Message-ID: <0dedf955ad704d53ae5cc31cbc4c6052@BY2PR03MB041.namprd03.prod.outlook.com> References: <84036CCA-8C25-48CD-9699-700078670780@ve7jtb.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.46.126.7] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: BY2PR03MB042.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%LISTS.OPENID.NET$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%COMPUTER.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%VE7JTB.COM$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%GOOGLEGROUPS.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:(377454001)(189002)(199002)(13464002)(23726001)(16676001)(46406002)(5343635001)(6806001)(76482001)(5343655001)(53806001)(63696002)(74662001)(44976002)(77982001)(50986001)(47976001)(56776001)(66066001)(20776003)(59766001)(15202345001)(46102001)(74502001)(47446002)(47776003)(54316002)(31966008)(51856001)(4396001)(47736001)(56816002)(80022001)(79102001)(65816001)(49866001)(50466001)(33646001)(54356001)(42262001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB010; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 07749F8C42 Cc: "openid-connect-interop@googlegroups.com" , Group Group , "oauth@ietf.org WG" , "" , "webfinger@ietf.org" Subject: Re: [OAUTH-WG] [jose] Meeting for people interested in OpenID Connect at IETF#86 in Sun Mar 10 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2013 00:13:00 -0000 I thought it was Sunday -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Bar= ry Leiba Sent: Saturday, March 2, 2013 11:58 AM To: John Bradley Cc: openid-connect-interop@googlegroups.com; Group Group; oauth@ietf.org WG= ; ; webfinger@ietf.org Subject: Re: [jose] [OAUTH-WG] Meeting for people interested in OpenID Conn= ect at IETF#86 in Sun Mar 10 > The eventbrite page for people wanting to attend the openID Connect=20 > session prior to IETF86 is now available at: > http://openid-ietf-86.eventbrite.com/ That page says this: OpenID Meeting at IETF 86 The OpenID Foundation Thursday, April 11, 2013 from 1:00 PM to 4:00 PM (EDT) Orlando, FL I do hope it means Thursday, 7 March. 11 April is about a month *after* the IETF meeting. Barry _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From phil.hunt@oracle.com Sat Mar 2 16:20: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 DFF1721F84D6; Sat, 2 Mar 2013 16:20:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGQS7N-7Fl+9; Sat, 2 Mar 2013 16:20:04 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 0E3C821F84D1; Sat, 2 Mar 2013 16:20:03 -0800 (PST) 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 r230JwkD021597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 3 Mar 2013 00:19:59 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r230Jwxt010425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 3 Mar 2013 00:19:58 GMT Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r230JvdO030315; Sat, 2 Mar 2013 18:19:57 -0600 Received: from [25.73.5.188] (/74.198.150.188) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 02 Mar 2013 16:19:57 -0800 References: <84036CCA-8C25-48CD-9699-700078670780@ve7jtb.com> <0dedf955ad704d53ae5cc31cbc4c6052@BY2PR03MB041.namprd03.prod.outlook.com> Mime-Version: 1.0 (1.0) In-Reply-To: <0dedf955ad704d53ae5cc31cbc4c6052@BY2PR03MB041.namprd03.prod.outlook.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <3AE8D8EF-714C-4F6A-9B50-433AA2500C06@oracle.com> X-Mailer: iPhone Mail (10B146) From: Phil Hunt Date: Sat, 2 Mar 2013 16:19:51 -0800 To: Anthony Nadalin X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: Barry Leiba , "openid-connect-interop@googlegroups.com" , "" , "webfinger@ietf.org" , Group Group , "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] [jose] Meeting for people interested in OpenID Connect at IETF#86 in Sun Mar 10 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2013 00:20:05 -0000 I should be in orlando at 7:30ish if anything is happening in the evening.=20= Phil Sent from my phone. On 2013-03-02, at 16:12, Anthony Nadalin wrote: > I thought it was Sunday >=20 > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Ba= rry Leiba > Sent: Saturday, March 2, 2013 11:58 AM > To: John Bradley > Cc: openid-connect-interop@googlegroups.com; Group Group; oauth@ietf.org W= G; ; webfinger@ietf.org > Subject: Re: [jose] [OAUTH-WG] Meeting for people interested in OpenID Con= nect at IETF#86 in Sun Mar 10 >=20 >> The eventbrite page for people wanting to attend the openID Connect=20 >> session prior to IETF86 is now available at: >> http://openid-ietf-86.eventbrite.com/ >=20 > That page says this: > OpenID Meeting at IETF 86 > The OpenID Foundation > Thursday, April 11, 2013 from 1:00 PM to 4:00 PM (EDT) > Orlando, FL >=20 > I do hope it means Thursday, 7 March. 11 April is about a month > *after* the IETF meeting. >=20 > Barry > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From ve7jtb@ve7jtb.com Sun Mar 3 14:58: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 DF25D21F88C1 for ; Sun, 3 Mar 2013 14:58:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U1V1YrBJgsZ3 for ; Sun, 3 Mar 2013 14:58:54 -0800 (PST) Received: from mail-pa0-f53.google.com (mail-pa0-f53.google.com [209.85.220.53]) by ietfa.amsl.com (Postfix) with ESMTP id 387E021F88C4 for ; Sun, 3 Mar 2013 14:58:54 -0800 (PST) Received: by mail-pa0-f53.google.com with SMTP id bg4so2758997pad.40 for ; Sun, 03 Mar 2013 14:58:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to:x-gm-message-state; bh=T8Kr+HzmtrVVdvBY4TuFNjgiCxYAhUg3qffVr0bw1yk=; b=JIXwZoREASI3/jWqB56opkWkHo8KgJi/Y7FxgmTZyQmAY9guF8EdrukH/4EqmCPqLK UApa/asxZ3lk8J60Aln2KDzeJkiroiyhTk/EsivCt6CDP4pSWg4XlW12PH4ICGyteFus Lh+aKDP0NjpdIKR0XyvPn32m9tZQ1lQR9+hL2VZ4gGb4FBmYPo065C9QkPB2iF3EeaZy iWoQdu9Dns56n008rVA6wvuSpRhyNHoRsXhuj7asmXd9iC/RGC4uIvfzR+H4bX9XxGmi yxTQYO02zf0rPEYUThq4lLHhnbiAmNACP+bPEpJ7d6vaAn1/W4bjGqDY4racU+e2mpEO +ktQ== X-Received: by 10.66.87.8 with SMTP id t8mr29074421paz.28.1362351533904; Sun, 03 Mar 2013 14:58:53 -0800 (PST) Received: from [10.186.239.43] ([61.213.4.2]) by mx.google.com with ESMTPS id hu2sm19966287pbc.38.2013.03.03.14.58.50 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 03 Mar 2013 14:58:52 -0800 (PST) References: <84036CCA-8C25-48CD-9699-700078670780@ve7jtb.com> <0dedf955ad704d53ae5cc31cbc4c6052@BY2PR03MB041.namprd03.prod.outlook.com> Mime-Version: 1.0 (1.0) In-Reply-To: <0dedf955ad704d53ae5cc31cbc4c6052@BY2PR03MB041.namprd03.prod.outlook.com> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-53EDFDD5-BA90-4CA7-AA11-847A3F4AA553; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit Message-Id: <8FCA9E2B-78C5-4C60-BEC2-0DF10600A7BE@ve7jtb.com> X-Mailer: iPhone Mail (10B146) From: John Bradley Date: Mon, 4 Mar 2013 07:58:50 +0900 To: Anthony Nadalin X-Gm-Message-State: ALoCoQkTvejZxfL+JezbLpiSDwyxq0KgWOnyfPZc6GsAfXI7tZ9JbgROaCxbticX83iLzWUhJJI1 Cc: Barry Leiba , "openid-connect-interop@googlegroups.com" , "" , "webfinger@ietf.org" , Group Group , "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] [jose] Meeting for people interested in OpenID Connect at IETF#86 in Sun Mar 10 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2013 22:58:55 -0000 --Apple-Mail-53EDFDD5-BA90-4CA7-AA11-847A3F4AA553 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable The title Sunday Mar 10 is the correct date. I will update the event.=20 Sorry don't know why the date is wrong.=20 Sent from my iPhone On 2013-03-03, at 9:12 AM, Anthony Nadalin wrote: > I thought it was Sunday >=20 > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Ba= rry Leiba > Sent: Saturday, March 2, 2013 11:58 AM > To: John Bradley > Cc: openid-connect-interop@googlegroups.com; Group Group; oauth@ietf.org W= G; ; webfinger@ietf.org > Subject: Re: [jose] [OAUTH-WG] Meeting for people interested in OpenID Con= nect at IETF#86 in Sun Mar 10 >=20 >> The eventbrite page for people wanting to attend the openID Connect=20 >> session prior to IETF86 is now available at: >> http://openid-ietf-86.eventbrite.com/ >=20 > That page says this: > OpenID Meeting at IETF 86 > The OpenID Foundation > Thursday, April 11, 2013 from 1:00 PM to 4:00 PM (EDT) > Orlando, FL >=20 > I do hope it means Thursday, 7 March. 11 April is about a month > *after* the IETF meeting. >=20 > Barry > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose >=20 >=20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail-53EDFDD5-BA90-4CA7-AA11-847A3F4AA553 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHuTCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDGCA2wwggNoAgEBMIGTMIGMMQswCQYD VQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwg Q2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IElu dGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsOAwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDMwMzIyNTg1MlowIwYJKoZIhvcNAQkEMRYEFHoU Un2mvlAgj6PGvrOK7kAGVdeUMIGkBgkrBgEEAYI3EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAILMYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQG A1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBD bGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIBACPvAuSNf7VayrPjy8fhaGuQMESoT/GIvHsu 9XyHXwNcfPPxdWWIABHujKei0X/i6dG+VHkKs+P2nZPYB6f9m3QqdxUzUd180SWMXLvxzLMoFPQO X9lh50LmyVNeVOlrBZEQiAiN/c7c9ew5NNJRyk/pGEj53secKFMsW/vMvg10GBhuVuKuS3xlsyE1 Wu0MYrb7RkqqhRvrXxTxP3nwH0KKreUrh0v0LmyEOd8Y7ZTNqP/mtnGGLo6o0Jkm+y+p/UZaqIRs RtJYp3ukn24bPyxFXodrZR+MWoqrKL0L79SCtsPB4o17OK3vr6D3FFUv6zxQdXxklL35aTRHXvc2 ZyYAAAAAAAA= --Apple-Mail-53EDFDD5-BA90-4CA7-AA11-847A3F4AA553-- From bcampbell@pingidentity.com Tue Mar 5 09:02: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 43C521F0D08 for ; Tue, 5 Mar 2013 09:02:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hrFv0tJhHtuQ for ; Tue, 5 Mar 2013 09:02:29 -0800 (PST) Received: from na3sys009aog132.obsmtp.com (na3sys009aog132.obsmtp.com [74.125.149.250]) by ietfa.amsl.com (Postfix) with ESMTP id B86E51F0D0F for ; Tue, 5 Mar 2013 09:02:28 -0800 (PST) Received: from mail-oa0-f71.google.com ([209.85.219.71]) (using TLSv1) by na3sys009aob132.postini.com ([74.125.148.12]) with SMTP ID DSNKUTYlJOTWcx3t6+VRdpDs1qZ8uxc9c9lY@postini.com; Tue, 05 Mar 2013 09:02:28 PST Received: by mail-oa0-f71.google.com with SMTP id o6so43028261oag.10 for ; Tue, 05 Mar 2013 09:02:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=Gn2hM53Y85+VGdUd7Rb7RHuSy1F7fbAdmdQ3V4bx4IA=; b=HM6qBo7AiroBMVtk7wyqq0unG4gn3DlXG/hdtfdgNcX4uuBbt0idDXNhz36EJaSTJE nV1MXqA6RD+jhKewM5VfDEHc4n8VZRSQW3EiNWgbE9TNXwb2uB7U8jTyvGnG/rZYgCjD HIt8afUiSmNFb0XFT31mbvBBVIA4kWWCK4UWia+HX6FPPcJjsZSJS8CDrwf725LEG8Rn la7Epiw2WoraaikFR5inyBmkknHPfO0CJOYL5iKte0pXTm7uVF1bHuFihyfkwr6du+r5 hoRNKVHKjD13q82ZT6kfhL86xy8ZrXh3oQ7OTS/PA6zJ7KrfTFPCOvrceZ3dFiNs7odR GRhw== X-Received: by 10.50.37.236 with SMTP id b12mr6840784igk.42.1362502948003; Tue, 05 Mar 2013 09:02:28 -0800 (PST) X-Received: by 10.50.37.236 with SMTP id b12mr6840776igk.42.1362502947880; Tue, 05 Mar 2013 09:02:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.32.106 with HTTP; Tue, 5 Mar 2013 09:01:57 -0800 (PST) In-Reply-To: <3AE8D8EF-714C-4F6A-9B50-433AA2500C06@oracle.com> References: <84036CCA-8C25-48CD-9699-700078670780@ve7jtb.com> <0dedf955ad704d53ae5cc31cbc4c6052@BY2PR03MB041.namprd03.prod.outlook.com> <3AE8D8EF-714C-4F6A-9B50-433AA2500C06@oracle.com> From: Brian Campbell Date: Tue, 5 Mar 2013 10:01:57 -0700 Message-ID: To: Phil Hunt Content-Type: multipart/alternative; boundary=f46d044788d936dc7804d7307037 X-Gm-Message-State: ALoCoQm2TOoNmLxODCszwqxBjK6+9FR9dmg0TisLbJTldvWH77eq3zF+6BZe+qBhkeO/Al1MA9CrrBb2XxWya3T4OJHEjAuH7Qx8+Vvsva1swWXmp047uzan/FtYlC7KTDavlaxLk/JJ Cc: Group Group , "openid-connect-interop@googlegroups.com" , "" , "webfinger@ietf.org" , Barry Leiba , "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] [jose] Meeting for people interested in OpenID Connect at IETF#86 in Sun Mar 10 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 17:02:30 -0000 --f46d044788d936dc7804d7307037 Content-Type: text/plain; charset=ISO-8859-1 Likewise, I'll be arriving in Orlando ~3:30pm, if there's anything happening later in the afternoon/evening? On Sat, Mar 2, 2013 at 5:19 PM, Phil Hunt wrote: > I should be in orlando at 7:30ish if anything is happening in the evening. > > Phil > > Sent from my phone. > > On 2013-03-02, at 16:12, Anthony Nadalin wrote: > > > I thought it was Sunday > > > > -----Original Message----- > > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of > Barry Leiba > > Sent: Saturday, March 2, 2013 11:58 AM > > To: John Bradley > > Cc: openid-connect-interop@googlegroups.com; Group Group; oauth@ietf.orgWG; < > jose@ietf.org>; webfinger@ietf.org > > Subject: Re: [jose] [OAUTH-WG] Meeting for people interested in OpenID > Connect at IETF#86 in Sun Mar 10 > > > >> The eventbrite page for people wanting to attend the openID Connect > >> session prior to IETF86 is now available at: > >> http://openid-ietf-86.eventbrite.com/ > > > > That page says this: > > OpenID Meeting at IETF 86 > > The OpenID Foundation > > Thursday, April 11, 2013 from 1:00 PM to 4:00 PM (EDT) > > Orlando, FL > > > > I do hope it means Thursday, 7 March. 11 April is about a month > > *after* the IETF meeting. > > > > Barry > > _______________________________________________ > > jose mailing list > > jose@ietf.org > > https://www.ietf.org/mailman/listinfo/jose > > > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > --f46d044788d936dc7804d7307037 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Likewise, I'll be arriving in Orlando ~3:30pm, if ther= e's anything happening later in the afternoon/evening?


On Sat, Mar 2, 2013 = at 5:19 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
I should be in orlando at 7:30ish if anythin= g is happening in the evening.

Phil

Sent from my phone.

On 2013-03-02, at 16:12, Anthony Nadalin <tonynad@microsoft.com> wrote:

> I thought it was Sunday
>
> -----Original Message-----
> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Barry Leiba
> Sent: Saturday, March 2, 2013 11:58 AM
> To: John Bradley
> Cc: openid-= connect-interop@googlegroups.com; Group Group; oauth@ietf.org WG; <jose@= ietf.org>; webfinger@ietf.org<= /a>
> Subject: Re: [jose] [OAUTH-WG] Meeting for people interested in OpenID= Connect at IETF#86 in Sun Mar 10
>
>> The eventbrite page for people wanting to attend the openID Connec= t
>> session prior to IETF86 is now available at:
>> http://openid-ietf-86.eventbrite.com/
>
> That page says this:
> =A0 OpenID Meeting at IETF 86
> =A0 The OpenID Foundation
> =A0 Thursday, April 11, 2013 from 1:00 PM to 4:00 PM (EDT)
> =A0 Orlando, FL
>
> I do hope it means Thursday, 7 March. =A011 April is about a month
> *after* the IETF meeting.
>
> Barry
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
_____________________________= __________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

--f46d044788d936dc7804d7307037-- From lainhart@us.ibm.com Thu Mar 7 07:16:11 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 CA27421F88BE for ; Thu, 7 Mar 2013 07:16:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NNKKEocSXQmG for ; Thu, 7 Mar 2013 07:16:11 -0800 (PST) Received: from e39.co.us.ibm.com (e39.co.us.ibm.com [32.97.110.160]) by ietfa.amsl.com (Postfix) with ESMTP id EA4C021F88F7 for ; Thu, 7 Mar 2013 07:15:52 -0800 (PST) Received: from /spool/local by e39.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 7 Mar 2013 08:15:52 -0700 Received: from d01dlp01.pok.ibm.com (9.56.250.166) by e39.co.us.ibm.com (192.168.1.139) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 7 Mar 2013 08:15:49 -0700 Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 0575C38C805F for ; Thu, 7 Mar 2013 10:15:49 -0500 (EST) Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r27FFmPe239992 for ; Thu, 7 Mar 2013 10:15:48 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r27FFlDa017610 for ; Thu, 7 Mar 2013 10:15:47 -0500 Received: from d01ml255.pok.ibm.com (d01ml255.pok.ibm.com [9.63.10.54]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id r27FFlTA017594 for ; Thu, 7 Mar 2013 10:15:47 -0500 To: "IETF oauth WG" MIME-Version: 1.0 X-KeepSent: C1B41846:6225D658-85257B27:005331D1; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3FP2 SHF22 July 19, 2012 Message-ID: From: Todd W Lainhart Date: Thu, 7 Mar 2013 10:15:46 -0500 X-MIMETrack: Serialize by Router on D01ML255/01/M/IBM(Release 8.5.3FP2 ZX853FP2HF5|February, 2013) at 03/07/2013 10:15:47, Serialize complete at 03/07/2013 10:15:47 Content-Type: multipart/alternative; boundary="=_alternative 0053D75585257B27_=" X-TM-AS-MML: No X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13030715-3620-0000-0000-0000018655F4 Subject: [OAUTH-WG] draft-richer-oauth-introspection-03 X-BeenThere: oauth@ietf.org X-Mailman-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, 07 Mar 2013 15:16:12 -0000 This is a multipart message in MIME format. --=_alternative 0053D75585257B27_= Content-Type: text/plain; charset="US-ASCII" Hi Justin - I'm comparing: http://tools.ietf.org/html/draft-richer-oauth-introspection-03 ...with: http://tools.ietf.org/html/draft-ietf-oauth-revocation-05 for symmetry. If that's appropriate, and if I use revocation as the baseline, I'm wondering why introspection supports GET in addition to POST, and doesn't require TLS (i.e. revocation only supports POST, and requires TLS). Todd Lainhart Rational software IBM Corporation 550 King Street, Littleton, MA 01460-1250 1-978-899-4705 2-276-4705 (T/L) lainhart@us.ibm.com --=_alternative 0053D75585257B27_= Content-Type: text/html; charset="US-ASCII" Hi Justin -

I'm comparing:

http://tools.ietf.org/html/draft-richer-oauth-introspection-03

...with:

http://tools.ietf.org/html/draft-ietf-oauth-revocation-05

for symmetry.

If that's appropriate, and if I use revocation as the baseline, I'm wondering why introspection supports GET in addition to POST, and doesn't require TLS (i.e. revocation only supports POST, and requires TLS).



Todd Lainhart
Rational software
IBM Corporation
550 King Street, Littleton, MA 01460-1250
1-978-899-4705
2-276-4705 (T/L)
lainhart@us.ibm.com

--=_alternative 0053D75585257B27_=-- From lainhart@us.ibm.com Thu Mar 7 07:23:42 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 74EC421F8D2D for ; Thu, 7 Mar 2013 07:23:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id paTyzjXbva4J for ; Thu, 7 Mar 2013 07:23:38 -0800 (PST) Received: from e7.ny.us.ibm.com (e7.ny.us.ibm.com [32.97.182.137]) by ietfa.amsl.com (Postfix) with ESMTP id 6A5C721F8D64 for ; Thu, 7 Mar 2013 07:23:35 -0800 (PST) Received: from /spool/local by e7.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 7 Mar 2013 10:23:35 -0500 Received: from d01dlp01.pok.ibm.com (9.56.250.166) by e7.ny.us.ibm.com (192.168.1.107) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 7 Mar 2013 10:23:32 -0500 Received: from d01relay06.pok.ibm.com (d01relay06.pok.ibm.com [9.56.227.116]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id BDBD438C801B; Thu, 7 Mar 2013 10:23:31 -0500 (EST) Received: from d01av05.pok.ibm.com (d01av05.pok.ibm.com [9.56.224.195]) by d01relay06.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r27FNV4G31064150; Thu, 7 Mar 2013 10:23:31 -0500 Received: from d01av05.pok.ibm.com (loopback [127.0.0.1]) by d01av05.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r27FNV3S023085; Thu, 7 Mar 2013 10:23:31 -0500 Received: from d01ml255.pok.ibm.com (d01ml255.pok.ibm.com [9.63.10.54]) by d01av05.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id r27FNVsw023078; Thu, 7 Mar 2013 10:23:31 -0500 In-Reply-To: References: To: "IETF oauth WG" , oauth-bounces@ietf.org MIME-Version: 1.0 X-KeepSent: 77C00A3C:61810FDE-85257B27:00547172; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3FP2 SHF22 July 19, 2012 Message-ID: From: Todd W Lainhart Date: Thu, 7 Mar 2013 10:23:29 -0500 X-MIMETrack: Serialize by Router on D01ML255/01/M/IBM(Release 8.5.3FP2 ZX853FP2HF5|February, 2013) at 03/07/2013 10:23:31, Serialize complete at 03/07/2013 10:23:31 Content-Type: multipart/alternative; boundary="=_alternative 00548C0D85257B27_=" X-TM-AS-MML: No X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13030715-5806-0000-0000-0000203CE366 Subject: Re: [OAUTH-WG] draft-richer-oauth-introspection-03 X-BeenThere: oauth@ietf.org X-Mailman-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, 07 Mar 2013 15:23:42 -0000 This is a multipart message in MIME format. --=_alternative 00548C0D85257B27_= Content-Type: text/plain; charset="US-ASCII" I forgot to include the "token_type_hint" parameter in the baseline compare (i.e. revocation includes it as optional, introspection does not). Todd Lainhart Rational software IBM Corporation 550 King Street, Littleton, MA 01460-1250 1-978-899-4705 2-276-4705 (T/L) lainhart@us.ibm.com From: Todd W Lainhart/Lexington/IBM@IBMUS To: "IETF oauth WG" , Date: 03/07/2013 10:17 AM Subject: [OAUTH-WG] draft-richer-oauth-introspection-03 Sent by: oauth-bounces@ietf.org Hi Justin - I'm comparing: http://tools.ietf.org/html/draft-richer-oauth-introspection-03 ...with: http://tools.ietf.org/html/draft-ietf-oauth-revocation-05 for symmetry. If that's appropriate, and if I use revocation as the baseline, I'm wondering why introspection supports GET in addition to POST, and doesn't require TLS (i.e. revocation only supports POST, and requires TLS). Todd Lainhart Rational software IBM Corporation 550 King Street, Littleton, MA 01460-1250 1-978-899-4705 2-276-4705 (T/L) lainhart@us.ibm.com _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --=_alternative 00548C0D85257B27_= Content-Type: text/html; charset="US-ASCII" I forgot to include the "token_type_hint" parameter in the baseline compare (i.e. revocation includes it as optional, introspection does not).



Todd Lainhart
Rational software
IBM Corporation
550 King Street, Littleton, MA 01460-1250
1-978-899-4705
2-276-4705 (T/L)
lainhart@us.ibm.com





From:        Todd W Lainhart/Lexington/IBM@IBMUS
To:        "IETF oauth WG" <oauth@ietf.org>,
Date:        03/07/2013 10:17 AM
Subject:        [OAUTH-WG] draft-richer-oauth-introspection-03
Sent by:        oauth-bounces@ietf.org



Hi Justin -

I'm comparing:

http://tools.ietf.org/html/draft-richer-oauth-introspection-03

...with:

http://tools.ietf.org/html/draft-ietf-oauth-revocation-05

for symmetry.

If that's appropriate, and if I use revocation as the baseline, I'm wondering why introspection supports GET in addition to POST, and doesn't require TLS (i.e. revocation only supports POST, and requires TLS).



Todd Lainhart
Rational software
IBM Corporation
550 King Street, Littleton, MA 01460-1250
1-978-899-4705
2-276-4705 (T/L)
lainhart@us.ibm.com

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--=_alternative 00548C0D85257B27_=-- From jricher@mitre.org Thu Mar 7 08:23: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 B9B9A21F8D41 for ; Thu, 7 Mar 2013 08:23:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8LeA+OoxoHL for ; Thu, 7 Mar 2013 08:23:05 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id B4A2C21F8D59 for ; Thu, 7 Mar 2013 08:22:50 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 0647B4390051; Thu, 7 Mar 2013 11:22:50 -0500 (EST) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id DCC501F0A7F; Thu, 7 Mar 2013 11:22:49 -0500 (EST) 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.318.4; Thu, 7 Mar 2013 11:22:49 -0500 Message-ID: <5138BE93.3010401@mitre.org> Date: Thu, 7 Mar 2013 11:21:39 -0500 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: Todd W Lainhart References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------060002050808030305040009" X-Originating-IP: [129.83.31.58] Cc: IETF oauth WG Subject: Re: [OAUTH-WG] draft-richer-oauth-introspection-03 X-BeenThere: oauth@ietf.org X-Mailman-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, 07 Mar 2013 16:23:06 -0000 --------------060002050808030305040009 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit I hadn't set out to make the introspection draft parallel to the revocation draft, but I see no reason that these two items couldn't be incorporated with the same language and semantics. -- Justin On 03/07/2013 10:23 AM, Todd W Lainhart wrote: > I forgot to include the "token_type_hint" parameter in the baseline > compare (i.e. revocation includes it as optional, introspection does not). > > * > > > Todd Lainhart > Rational software > IBM Corporation > 550 King Street, Littleton, MA 01460-1250** > 1-978-899-4705 > 2-276-4705 (T/L) > lainhart@us.ibm.com* > > > > > > > From: Todd W Lainhart/Lexington/IBM@IBMUS > To: "IETF oauth WG" , > Date: 03/07/2013 10:17 AM > Subject: [OAUTH-WG] draft-richer-oauth-introspection-03 > Sent by: oauth-bounces@ietf.org > ------------------------------------------------------------------------ > > > > Hi Justin - > > I'm comparing: > _ > __http://tools.ietf.org/html/draft-richer-oauth-introspection-03_ > > ...with: > _ > __http://tools.ietf.org/html/draft-ietf-oauth-revocation-05_ > > for symmetry. > > If that's appropriate, and if I use revocation as the baseline, I'm > wondering why introspection supports GET in addition to POST, and > doesn't require TLS (i.e. revocation only supports POST, and requires > TLS). > * > > > Todd Lainhart > Rational software > IBM Corporation > 550 King Street, Littleton, MA 01460-1250** > 1-978-899-4705 > 2-276-4705 (T/L) > lainhart@us.ibm.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 --------------060002050808030305040009 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit I hadn't set out to make the introspection draft parallel to the revocation draft, but I see no reason that these two items couldn't be incorporated with the same language and semantics.

 -- Justin


On 03/07/2013 10:23 AM, Todd W Lainhart wrote:
I forgot to include the "token_type_hint" parameter in the baseline compare (i.e. revocation includes it as optional, introspection does not).



Todd Lainhart
Rational software
IBM Corporation
550 King Street, Littleton, MA 01460-1250
1-978-899-4705
2-276-4705 (T/L)
lainhart@us.ibm.com





From:        Todd W Lainhart/Lexington/IBM@IBMUS
To:        "IETF oauth WG" <oauth@ietf.org>,
Date:        03/07/2013 10:17 AM
Subject:        [OAUTH-WG] draft-richer-oauth-introspection-03
Sent by:        oauth-bounces@ietf.org



Hi Justin -

I'm comparing:

http://tools.ietf.org/html/draft-richer-oauth-introspection-03

...with:

http://tools.ietf.org/html/draft-ietf-oauth-revocation-05

for symmetry.

If that's appropriate, and if I use revocation as the baseline, I'm wondering why introspection supports GET in addition to POST, and doesn't require TLS (i.e. revocation only supports POST, and requires TLS).



Todd Lainhart
Rational software
IBM Corporation
550 King Street, Littleton, MA 01460-1250
1-978-899-4705
2-276-4705 (T/L)
lainhart@us.ibm.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

--------------060002050808030305040009-- From lainhart@us.ibm.com Thu Mar 7 10:38:41 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 15C4821F8A9B for ; Thu, 7 Mar 2013 10:38:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jh2XnXsWBfRl for ; Thu, 7 Mar 2013 10:38:40 -0800 (PST) Received: from e7.ny.us.ibm.com (e7.ny.us.ibm.com [32.97.182.137]) by ietfa.amsl.com (Postfix) with ESMTP id 9868321F88A2 for ; Thu, 7 Mar 2013 10:38:39 -0800 (PST) Received: from /spool/local by e7.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 7 Mar 2013 13:38:38 -0500 Received: from d01dlp02.pok.ibm.com (9.56.250.167) by e7.ny.us.ibm.com (192.168.1.107) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 7 Mar 2013 13:38:37 -0500 Received: from d01relay07.pok.ibm.com (d01relay07.pok.ibm.com [9.56.227.147]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 061F26E8040 for ; Thu, 7 Mar 2013 13:38:35 -0500 (EST) Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay07.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r27IcaRu56164572 for ; Thu, 7 Mar 2013 13:38:36 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r27Ica7w009826 for ; Thu, 7 Mar 2013 13:38:36 -0500 Received: from d01ml255.pok.ibm.com (d01ml255.pok.ibm.com [9.63.10.54]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id r27IcaGl009820; Thu, 7 Mar 2013 13:38:36 -0500 In-Reply-To: <5138BE93.3010401@mitre.org> References: <5138BE93.3010401@mitre.org> To: Justin Richer MIME-Version: 1.0 X-KeepSent: 4864DEC5:54D84402-85257B27:006646E3; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3FP2 SHF22 July 19, 2012 Message-ID: From: Todd W Lainhart Date: Thu, 7 Mar 2013 13:38:34 -0500 X-MIMETrack: Serialize by Router on D01ML255/01/M/IBM(Release 8.5.3FP2 ZX853FP2HF5|February, 2013) at 03/07/2013 13:38:36, Serialize complete at 03/07/2013 13:38:36 Content-Type: multipart/alternative; boundary="=_alternative 0066686E85257B27_=" X-TM-AS-MML: No X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13030718-5806-0000-0000-0000203E4E84 Cc: IETF oauth WG Subject: Re: [OAUTH-WG] draft-richer-oauth-introspection-03 X-BeenThere: oauth@ietf.org X-Mailman-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, 07 Mar 2013 18:38:41 -0000 This is a multipart message in MIME format. --=_alternative 0066686E85257B27_= Content-Type: text/plain; charset="US-ASCII" > ...but I see no reason that these two items couldn't be incorporated with the same language and semantics. That's great. "token_type_hint" is something that could be helpful to implementations. Todd Lainhart Rational software IBM Corporation 550 King Street, Littleton, MA 01460-1250 1-978-899-4705 2-276-4705 (T/L) lainhart@us.ibm.com From: Justin Richer To: Todd W Lainhart/Lexington/IBM@IBMUS, Cc: IETF oauth WG Date: 03/07/2013 11:28 AM Subject: Re: [OAUTH-WG] draft-richer-oauth-introspection-03 I hadn't set out to make the introspection draft parallel to the revocation draft, but I see no reason that these two items couldn't be incorporated with the same language and semantics. -- Justin On 03/07/2013 10:23 AM, Todd W Lainhart wrote: I forgot to include the "token_type_hint" parameter in the baseline compare (i.e. revocation includes it as optional, introspection does not). Todd Lainhart Rational software IBM Corporation 550 King Street, Littleton, MA 01460-1250 1-978-899-4705 2-276-4705 (T/L) lainhart@us.ibm.com From: Todd W Lainhart/Lexington/IBM@IBMUS To: "IETF oauth WG" , Date: 03/07/2013 10:17 AM Subject: [OAUTH-WG] draft-richer-oauth-introspection-03 Sent by: oauth-bounces@ietf.org Hi Justin - I'm comparing: http://tools.ietf.org/html/draft-richer-oauth-introspection-03 ...with: http://tools.ietf.org/html/draft-ietf-oauth-revocation-05 for symmetry. If that's appropriate, and if I use revocation as the baseline, I'm wondering why introspection supports GET in addition to POST, and doesn't require TLS (i.e. revocation only supports POST, and requires TLS). Todd Lainhart Rational software IBM Corporation 550 King Street, Littleton, MA 01460-1250 1-978-899-4705 2-276-4705 (T/L) lainhart@us.ibm.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 --=_alternative 0066686E85257B27_= Content-Type: text/html; charset="US-ASCII" > ...but I see no reason that these two items couldn't be incorporated with the same language and semantics.

That's great.  "token_type_hint" is something that could be helpful to implementations.



Todd Lainhart
Rational software
IBM Corporation
550 King Street, Littleton, MA 01460-1250
1-978-899-4705
2-276-4705 (T/L)
lainhart@us.ibm.com





From:        Justin Richer <jricher@mitre.org>
To:        Todd W Lainhart/Lexington/IBM@IBMUS,
Cc:        IETF oauth WG <oauth@ietf.org>
Date:        03/07/2013 11:28 AM
Subject:        Re: [OAUTH-WG] draft-richer-oauth-introspection-03



I hadn't set out to make the introspection draft parallel to the revocation draft, but I see no reason that these two items couldn't be incorporated with the same language and semantics.

-- Justin
On 03/07/2013 10:23 AM, Todd W Lainhart wrote:
I forgot to include the "token_type_hint" parameter in the baseline compare (i.e. revocation includes it as optional, introspection does not).



Todd Lainhart
Rational software
IBM Corporation
550 King Street, Littleton, MA 01460-1250
1-978-899-4705
2-276-4705 (T/L)
lainhart@us.ibm.com






From:        Todd W Lainhart/Lexington/IBM@IBMUS
To:        "IETF oauth WG" <oauth@ietf.org>,
Date:        03/07/2013 10:17 AM
Subject:        [OAUTH-WG] draft-richer-oauth-introspection-03
Sent by:        oauth-bounces@ietf.org



Hi Justin -

I'm comparing:

http://tools.ietf.org/html/draft-richer-oauth-introspection-03

...with:

http://tools.ietf.org/html/draft-ietf-oauth-revocation-05

for symmetry.

If that's appropriate, and if I use revocation as the baseline, I'm wondering why introspection supports GET in addition to POST, and doesn't require TLS (i.e. revocation only supports POST, and requires TLS).



Todd Lainhart
Rational software
IBM Corporation
550 King Street, Littleton, MA 01460-1250
1-978-899-4705
2-276-4705 (T/L)
lainhart@us.ibm.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

--=_alternative 0066686E85257B27_=-- From scott@adligo.com Thu Mar 7 13:07:50 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 55B0321F8A8F for ; Thu, 7 Mar 2013 13:07:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zzHvkDe5CF2N for ; Thu, 7 Mar 2013 13:07:49 -0800 (PST) Received: from mail-ve0-f175.google.com (mail-ve0-f175.google.com [209.85.128.175]) by ietfa.amsl.com (Postfix) with ESMTP id 86C6021F8A06 for ; Thu, 7 Mar 2013 13:07:49 -0800 (PST) Received: by mail-ve0-f175.google.com with SMTP id cy12so751169veb.20 for ; Thu, 07 Mar 2013 13:07:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=iHFsLLEYzinNQgR4gCKbZIDaR1aRyjf96uonnOCArfw=; b=EMVL6P3ow1jjUBvWBXmvEwFE2kvJSy395BgW0od2G/mjKLK80OH1PR/5SXdfJu+mnV KpOnr4P1RjtHwOLiy/fz14yaHth7VofbrQU41kM+rUW0DaVL4zDleA5RHbLz1xgjMVwy QEmRtgMFwzY/I8WpWekSHr8PWmKjSBXtxzu+fGQuSTgYyg8nEHIi6TyfSLITxa0VPwRq 8DjYkAS2wlTs8SCfjdkYwOoW0K23UXzaBrItLoWzTdDBEexJQrn0M0cTcpL0UZWxyocY faAhSYjnEFnAcO4LDeye7YV3M9bxdoFj+dKy0QnSMqCKvu2P3fXOBmsMblJKosB+xMOK 8cng== MIME-Version: 1.0 X-Received: by 10.52.175.130 with SMTP id ca2mr11965139vdc.109.1362690468884; Thu, 07 Mar 2013 13:07:48 -0800 (PST) Received: by 10.58.19.5 with HTTP; Thu, 7 Mar 2013 13:07:48 -0800 (PST) Date: Thu, 7 Mar 2013 15:07:48 -0600 Message-ID: From: Scott Morgan To: oauth@ietf.org Content-Type: multipart/alternative; boundary=bcaec5014c1d5678f604d75c193d X-Gm-Message-State: ALoCoQkv1D0VACRNKMWt7oBtVOTOUPLkrCPSAVNfP0HjOhIcoJ+cXfwwQHidRtJTg5dvIuf9qCh8 Subject: [OAUTH-WG] RFC 6455 max Fame Size to big? X-BeenThere: oauth@ietf.org X-Mailman-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, 07 Mar 2013 21:08:21 -0000 --bcaec5014c1d5678f604d75c193d Content-Type: text/plain; charset=ISO-8859-1 Hi All, I am not sure I am posting this to the right place, as this is the first comment I have ever made on a RFC paper please correct me if it is NOT the correct place. My comment is as follows; The RFC 6455 http://tools.ietf.org/html/rfc6455 seems to allow excessive frame sizes which could be used as a DOS attack vs a server, and so the maximum frame size should be reduced. As I understand the protocol it provides a way to send more than one frame to continue a data set anyway, so uber large data could be sent via multiple frames so limiting frame size to something reasonably small will not impact the ability to send massive data sets. http://tools.ietf.org/html/rfc6455#section-5.2 Extended payload length If 127, the following 8 bytes interpreted as a 64-bit unsigned integer (the most significant bit MUST be 0) are the payload length. So 2^64 = 18,446,744,073,709,600,000 bytes 1Gb is 1,073,741,824 bytes So a frame allows 18,446,744,073,709,600,000/ 1,073,741,824 or 17,179,869,184 Gb? This seems excessive, I suggest dropping the 64 bit extended payload data and doing one of the following; suggestion one; only including the 16 bit extended payload data in the specification which allows frames with 65,536 bytes, which is quite large enough for most text messages. suggestion two; adding a comment in the extended payload section that states a maximum frame size is something (ie 10 Mb is as large as I would suggest, in a 32 bit bock for the 127 payload length) Cheers, Scott PS I pay about $100/month for a 3 Mb/sec upload ISP connection so even a 10 Mb frame would take 3.3 seconds, send a few of those and I'm DOSed. --bcaec5014c1d5678f604d75c193d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi All,

=A0 =A0I am not sure I am= posting this to the right place, as this is the first comment I have ever = made on a RFC paper please correct me if it is NOT the correct place.
=

My comment is as follows;
seems to allow excessive frame sizes which co= uld be used as a DOS attack vs a server,
and so the maximum frame size should be reduced. =A0 As I unders= tand the protocol it provides a way to send more=A0
than on= e frame to continue a data set anyway, so uber large data could be sent via= multiple frames
so limiting frame size to something reasonably small will not im= pact the ability to send massive data sets.

Extended payload length
If=
 127, the
      following 8 bytes interpreted as a 64-bit unsigned integer (the
      most significant bit MUST be 0) are the payload length.

So 2^64 =3D 18,446,744,073,709,600,=
000 bytes
1Gb is 1,073,741,824 bytes 
So a frame allows  18,446,744,073,709,600,000/ 1,073,741=
,824 or  17,179,869,184 Gb?
This seems excessive, I suggest dropping the 64 bit extend=
ed payload data and doing one of the following;
sugge=
stion one;
       only including the 16 bit=A0=
suggestion two;
=A0 =A0 =A0 =A0adding a comment in = the extended payload section that states a maximum frame size is something = (ie 10 Mb is as large as I would suggest, in a 32 bit bock for the 127 payl= oad length)


Cheers,
Scott=A0

PS I pay about $100= /month for a 3 Mb/sec upload ISP connection so even a 10 Mb frame would tak= e 3.3 seconds, send a few of those and I'm DOSed.
--bcaec5014c1d5678f604d75c193d-- From scott@adligo.com Thu Mar 7 21: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 128A921F866F for ; Thu, 7 Mar 2013 21:59:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 2MNiL0tsDeEc for ; Thu, 7 Mar 2013 21:59:52 -0800 (PST) Received: from mail-vb0-x232.google.com (mail-vb0-x232.google.com [IPv6:2607:f8b0:400c:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 3EE3021F8648 for ; Thu, 7 Mar 2013 21:59:52 -0800 (PST) Received: by mail-vb0-f50.google.com with SMTP id ft2so502025vbb.37 for ; Thu, 07 Mar 2013 21:59:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=mwiFaZqPM5IwqNLAAS8GIgHgJym12fYlh4mxrHAs3vk=; b=V9s1LwBVJvSZxB5U/UZjuIOHfthzdF1CW7tffpDW1OEkF4VSxT08PRX2qaz81uS1hK VY5LK1IwZfj1S99bqL5f/CFkhQ88CKvy5ErUcEwUF7gM1C40crua1bBWRWvt43EcB8iJ D2WGx/dgt5FkSDqkAWSROTdE4mZRMzdVk/RqnebSeBXb0BpYOUdvdJQuFtM2vewvdUGo 3O3OHAFFqwwwnhRQ4B6rYxrXCZ8OSFdXMiIDBVXpMPfxrGTnHONmotcQGpsnISqjP6zn ffyMmzy3XxkZHnsrfi3FtUUPwRlK2qjKhDbMcXm0glLjln4AB5Q+uKskwWEpWtCXWWhu UU4w== MIME-Version: 1.0 X-Received: by 10.220.221.143 with SMTP id ic15mr456962vcb.32.1362722389797; Thu, 07 Mar 2013 21:59:49 -0800 (PST) Received: by 10.58.19.5 with HTTP; Thu, 7 Mar 2013 21:59:49 -0800 (PST) Date: Thu, 7 Mar 2013 23:59:49 -0600 Message-ID: From: Scott Morgan To: oauth@ietf.org Content-Type: multipart/alternative; boundary=14dae9cdc33bf8f1e404d7638788 X-Gm-Message-State: ALoCoQkWX/77fRvTat3UVxTc5m8/i3lhI1ZYe0I/B2XWseBOgGkZQlSQ7HBES9j4P+Y92gQbQvc+ Subject: [OAUTH-WG] RFC 6455 Frame to Message Reassembly, Mux X-BeenThere: oauth@ietf.org X-Mailman-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, 08 Mar 2013 05:59:53 -0000 --14dae9cdc33bf8f1e404d7638788 Content-Type: text/plain; charset=ISO-8859-1 Hi Again, Again I am sorry if these comments are in the wrong place (email list). I have been reading; http://webtide.intalio.com/2012/10/jetty-9-updated-websocket-api/ I have been wondering how multiple multiple frame messages would share a connection and get reassembled. The specification doen't seem to mention this; Ie Fancy multithreaded Client Sends 2 messages over a single socket; Frame A, part One of 20,000 leagues under the sea Frame B, part One of The Hobbit Frame C, part Two of 20,000 leagues under the sea Frame D, part Two of the Hobbit yea How should the frames be identified as belonging to the Hobbit? I suggest we use the masking key as a id, however I am not sure if it would be unique enough. Cheers, Scott --14dae9cdc33bf8f1e404d7638788 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Again,

=A0 =A0Again I am sorry= if these comments are in the wrong place (email list).
I have been reading;

I have been wondering how multiple mu= ltiple frame messages would share a connection and get reassembled. =A0 The= specification doen't seem to mention this;
Ie=A0
Fancy multithreaded Client Sends 2 messages over a single socket= ;
=A0 =A0 Frame A, part One of 20,000 leagues under the sea=
=A0 =A0 Frame B, part One of The Hobbit
= =A0 =A0 Frame C, part Two of=A020,000 leagues under the sea
=A0 =A0 Frame D, part Two of the Hobbit yea=A0
<= br>
How should the frames be identified as belonging to the= Hobbit?
I suggest we use the masking key as a id, however = I am not sure if it would be unique enough. =A0=A0


Cheers,
Scott
--14dae9cdc33bf8f1e404d7638788-- From ppatterson@salesforce.com Thu Mar 7 22:58: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 0DD7E21F8532 for ; Thu, 7 Mar 2013 22:58:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[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 WsLkWU8J5gyr for ; Thu, 7 Mar 2013 22:58:44 -0800 (PST) Received: from exprod8og119.obsmtp.com (exprod8og119.obsmtp.com [64.18.3.38]) by ietfa.amsl.com (Postfix) with SMTP id 431BE21F8530 for ; Thu, 7 Mar 2013 22:58:44 -0800 (PST) Received: from exsfm-hub3.internal.salesforce.com ([204.14.239.238]) by exprod8ob119.postini.com ([64.18.7.12]) with SMTP ID DSNKUTmMI5cBSJuIX0MpeugQ00cQQCqW8eyR@postini.com; Thu, 07 Mar 2013 22:58:44 PST Received: from EXSFM-MB03.internal.salesforce.com ([10.1.127.57]) by exsfm-hub3.internal.salesforce.com ([10.1.127.7]) with mapi; Thu, 7 Mar 2013 22:58:44 -0800 From: Pat Patterson To: Scott Morgan Date: Thu, 7 Mar 2013 22:58:42 -0800 Thread-Topic: [OAUTH-WG] RFC 6455 Frame to Message Reassembly, Mux Thread-Index: Ac4byl7z705+SAbqS3eth5Xyq0944A== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_BCBAA109A51442ED92B05519AEFAF52Csalesforcecom_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] RFC 6455 Frame to Message Reassembly, Mux X-BeenThere: oauth@ietf.org X-Mailman-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, 08 Mar 2013 06:58:45 -0000 --_000_BCBAA109A51442ED92B05519AEFAF52Csalesforcecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Scott, You are indeed in the wrong place. This is the OAuth (RFC 6749/50) mailing = list. I think you want to be on this one: https://www.ietf.org/mailman/list= info/hybi Cheers, Pat -- Pat Patterson | Principal Developer Evangelist | 408-849-4681 | http://abou= t.me/patpatterson On Mar 7, 2013, at 9:59 PM, Scott Morgan wrote: Hi Again, Again I am sorry if these comments are in the wrong place (email list). I have been reading; http://webtide.intalio.com/2012/10/jetty-9-updated-websocket-api/ I have been wondering how multiple multiple frame messages would share a co= nnection and get reassembled. The specification doen't seem to mention th= is; Ie Fancy multithreaded Client Sends 2 messages over a single socket; Frame A, part One of 20,000 leagues under the sea Frame B, part One of The Hobbit Frame C, part Two of 20,000 leagues under the sea Frame D, part Two of the Hobbit yea How should the frames be identified as belonging to the Hobbit? I suggest we use the masking key as a id, however I am not sure if it would= be unique enough. Cheers, Scott _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_BCBAA109A51442ED92B05519AEFAF52Csalesforcecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Scott,

You are indeed in the wrong place. This is the OAuth (RFC 6749/50) maili= ng list. I think you want to be on this one: https://www.ietf.org/mailman/listinfo/hybi
On Mar 7, 2013, at 9:59 PM, Scott Morgan wrote:

= Hi Again,

   Again I am sorry if th= ese comments are in the wrong place (email list).

=
I have been reading;

I have been wondering how m= ultiple multiple frame messages would share a connection and get reassemble= d.   The specification doen't seem to mention this;
Ie 
Fancy multithreaded Client Sends 2 messages over a single s= ocket;
    Frame A, part One of 20,000 leagu= es under the sea
    Frame B, part One of Th= e Hobbit
    Frame C, part Two of 20,00= 0 leagues under the sea
    Frame D, part Two of the Hobbit yea 

How should the frames be identi= fied as belonging to the Hobbit?
I suggest we use the = masking key as a id, however I am not sure if it would be unique enough. &n= bsp; 


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

= --_000_BCBAA109A51442ED92B05519AEFAF52Csalesforcecom_-- From sakimura@gmail.com Sun Mar 10 21:17:42 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 4136721F892D for ; Sun, 10 Mar 2013 21:17:42 -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, HTML_MESSAGE=0.001, 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 pnhAxdI8N9l2 for ; Sun, 10 Mar 2013 21:17:39 -0700 (PDT) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 077F221F8988 for ; Sun, 10 Mar 2013 21:17:37 -0700 (PDT) Received: by mail-la0-f52.google.com with SMTP id fs12so3453584lab.11 for ; Sun, 10 Mar 2013 21:17:36 -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=GLDRrPdi7FFGgX0mBUU7vIG02egTOM0TTUzuQSnSBMQ=; b=otMfKwg9m68UBMCxsu6Mr1WnSxvea1e02QBOweNnvTD9WgaflIaPp48+ptQ36pdUM7 s50Ci7qLzKjiqVfruYyv5AS4ukxZxPuA0isgH+OYR9zmYIPY5RrEPPcy2aPemhR296eP 19XEerqE7jDs9v2O6vgdVxfRWoNXMoD2kvdT7iLE9opgYN0is4Pg6rElE0UWuYwMECSQ ysxbQwvxDIjX/JixAUsWt1hx6dekx9kZEgPeY7/6TJTLDqq8Zg/2wlUodMsJhBqKvabC tlGnRupfGGW6miPFqYfwVPHbdil5Fyc0ngyN7fmWe+XAa+Fp98A7oXvdl3UhFT78QDT7 +Xkw== MIME-Version: 1.0 X-Received: by 10.112.41.101 with SMTP id e5mr3834675lbl.120.1362975456748; Sun, 10 Mar 2013 21:17:36 -0700 (PDT) Received: by 10.112.14.44 with HTTP; Sun, 10 Mar 2013 21:17:36 -0700 (PDT) In-Reply-To: <59E470B10C4630419ED717AC79FCF9A948D58DC0@BY2PRD0411MB441.namprd04.prod.outlook.com> References: <0EC2404F-E3C5-4AD1-88B4-E74AA0394DD9@gmx.net> <48FD87D1-4DF4-4289-99B7-40A515F31890@oracle.com> <3E472720-31A4-40A0-AAA4-402CF850831A@ve7jtb.com> <7127843B-D7B0-4AB6-87F1-1604D1EFFA79@oracle.com> <50DA292F-32F0-4266-8401-006AD837B775@ve7jtb.com> <59E470B10C4630419ED717AC79FCF9A948D58BEE@BY2PRD0411MB441.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A948D58DC0@BY2PRD0411MB441.namprd04.prod.outlook.com> Date: Mon, 11 Mar 2013 13:17:36 +0900 Message-ID: From: Nat Sakimura To: Lewis Adam-CAL022 Content-Type: multipart/alternative; boundary=e0cb4efe2f9cefed7904d79e73a3 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] JWT - scope claim missing X-BeenThere: oauth@ietf.org X-Mailman-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, 11 Mar 2013 04:17:42 -0000 --e0cb4efe2f9cefed7904d79e73a3 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable So, it is soooo late in the game: I have been completely underwater to even read the OAuth mails for about a month and slowly catching up now. Here is an I-D that I have created partly in response to the RS-AS interaction piece that was talked about at IETF 85. It does not have 'scope' and has 'claims' instead as it was based on OpenID Connect, but it is easy to add, provided that the scopes are to be understood as that of the 'aud'. http://tools.ietf.org/id/draft-sakimura-oidc-structured-token-01.txt Best, Nat 2013/3/1 Lewis Adam-CAL022 > Hmmm, I=92m not so sure. It depends where we all think OAuth is on its > trajectory. On one hand, OAuth has already seen an insanely massive amou= nt > of deployment. On the other hand, RESTful APIs see no sign of slowing > down. Now I=92m not going to go so far as Craig B. and say that everyth= ing > and everyone will be API enabled in the future, but it sure is going to b= e > a lot. That being said, one could argue that even with all the OAuth > implementation we=92ve seen, that this is just the infancy of it. Obviou= sly > a WG profile of a JWT-structured AT could not deprecate other forms > (unstructured, SAML, etc.) but going forward new developers may choose to > embrace this, and in fact this could even be the guidance. I agree with > previous comments that Justin=92s introspection draft might be a good pla= ce > to explore this.**** > > ** ** > > adam**** > > ** ** > > *From:* Brian Campbell [mailto:bcampbell@pingidentity.com] > *Sent:* Thursday, February 28, 2013 1:36 PM > *To:* Lewis Adam-CAL022 > *Cc:* John Bradley; oauth@ietf.org WG > > *Subject:* Re: [OAUTH-WG] JWT - scope claim missing**** > > ** ** > > I do agree that a WG profile of a JWT-structured access token could lend > itself to interoperability and ultimately be a useful thing. But you are > right that there already are many implementations out there in the wild > (heck, I've written one myself) and that might make it difficult to > standardize on something.**** > > Because of that, and many other reasons, I don't want to try and add that > to existing assertion drafts.**** > > ** ** > > On Thu, Feb 28, 2013 at 12:13 PM, Lewis Adam-CAL022 < > Adam.Lewis@motorolasolutions.com> wrote:**** > > Hi Brian, a few thoughts from somebody outside of the WG =85 **** > > **** > > As a newcomer to OAuth last year, I was initially confused by the titles. > It was confusing because we have SAML bearer **assertions** and JWT > bearer **tokens** =85 and as John just (begrudgingly) stated in this > thread, the JWT is being used as an assertion in this profile (and in > OIDC). I think it will be difficult to find a good name for these profil= es > since they do two entirely different things (e.g. define a new grant type > and define a new method of client authentication). One could argue that = as > long as the WG is at it, then why not add a third section to the JWT > profile, which talks about usage of JWT-structured bearer access tokens: = it > would not be any less related than the other two focuses of the doc. The= n > the document could be called something simple like =93profiles of JWT usa= ge > in OAuth=94 or something like that. **** > > **** > > On one hand, it is probably na=EFve to think that an access token can be > standardized in a profile given how many have already been released into > the wild, but on the other hand, a WG profile of a JWT-structured access > token could lend itself to interoperability, where AS implementations can > advertise conformance to the profile and who knows =85 maybe the RS=92s o= f the > future will be good with this. **** > > **** > > adam**** > > **** > > *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf > Of *Brian Campbell > *Sent:* Thursday, February 28, 2013 1:03 PM > *To:* John Bradley > *Cc:* oauth@ietf.org WG**** > > > *Subject:* Re: [OAUTH-WG] JWT - scope claim missing**** > > **** > > I'm not sure anyone really "picked" the titles for the bearer token > profiles. They just kind of evolved. And evolved in funny ways especially > when client authn to the AS was added. **** > > You won't hear me argue that the titles are "good" and this is not the > first time there's been confusion about what they actually do. They defin= e > new grant types and new client authentication methods. They *do not* defi= ne > an access token format or anything else about access tokens. JWT and SAML > could be used for that but that's not what these drafts do. **** > > Suggestions for better title(s) would be more than welcome.**** > > **** > > Here's what they are now:**** > > > SAML 2.0 Bearer Assertion Profiles for OAuth 2.0 > draft-ietf-oauth-saml2-bearer > > JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0 > draft-ietf-oauth-jwt-bearer > > Assertion Framework for OAuth 2.0 > draft-ietf-oauth-assertions**** > > **** > > On Thu, Feb 28, 2013 at 11:36 AM, John Bradley wrote:= * > *** > > Yes the title likely adds to the confusion given that the bearer tokens > are not access tokens.**** > > **** > > Things as separate from OAuth as the Firefox browerID spec use JWS signed > JWTs. **** > > **** > > The bearer token profiles for OAuth 2 are for OAuth2.**** > > **** > > The JSON Web Token (JWT) spec > did not start in OAuth and is not OAuth specific.**** > > **** > > A JWT is:**** > > JSON Web Token (JWT) A string representing a set of claims as a JSON**** > > object that is encoded in a JWS or JWE, enabling the claims to be**= ** > > digitally signed or MACed and/or encrypted.**** > > **** > > So OAuth or other profiles may define claims to go in a JWT, but the JWT > needs to itself only define the claims necessary for security processing. > **** > > **** > > John B.**** > > PS that was a soft ball If you hadn't responded I would have been > disappointed. I din't pick the title for the bearer token profiles.**** > > **** > > **** > > On 2013-02-28, at 10:12 AM, Phil Hunt wrote:**** > > ** ** > JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0**** > > > Note the title says "for OAuth2"**** > > **** > > Sorry. Couldn't resist. **** > > **** > > Phil**** > > **** > > Sent from my phone.**** > > > On 2013-02-28, at 9:40, John Bradley wrote:**** > > JWT is an assertion( I am probably going to regret using that word).**** > > **** > > It is used in openID connect for id_tokens, it is used in OAuth for > Assertion grant types and authentication of the client to the token > endpoint.**** > > http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-04**** > > **** > > **** > > **** > > JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0**** > > **** > > Dosen't define JWT's use for access tokens for the RS. **** > > **** > > Bottom line JWT is for more than access tokens.**** > > **** > > John B.**** > > **** > > On 2013-02-28, at 9:28 AM, Phil Hunt wrote:**** > > ** ** > > Are you saying jwt is not an access token type? > > Phil**** > > **** > > Sent from my phone.**** > > > On 2013-02-28, at 8:58, John Bradley wrote:**** > > Yes, defining scope in JWT is the wrong place. JWT needs to stick to th= e > security claims needed to process JWT.**** > > **** > > I also don't know how far you get requiring a specific authorization > format for JWT, some AS will wan to use a opaque reference, some might wa= nt > to use a user claim or role claim, others may use scopes, combining scop= es > and claims is also possible.**** > > **** > > Right now it is up to a AS RS pair to agree on how to communicate > authorization. I don't want MAC to be more restrictive than bearer when > it comes to authorization between AS and RS.**** > > **** > > Hannes wanted to know why JWT didn't define scope. The simple answer is > that it is out of scope for JWT itself. It might be defined in a OAuth > access token profile for JWT but it should not be specific to MAC.**** > > **** > > John B.**** > > On 2013-02-28, at 8:44 AM, Brian Campbell > wrote:**** > > ** ** > > I think John's point was more that scope is something rather specific to > an OAuth access token and, while JWT is can be used to represent an acces= s > token, it's not the only application of JWT. The 'standard' claims in JWT > are those that are believed (right or wrong) to be widely applicable acro= ss > different applications of JWT. One could argue about it but scope is > probably not one of those.**** > > It would probably make sense to try and build a profile of JWT > specifically for OAuth access tokens (though I suspect there are some > turtles and dragons in there), which might be the appropriate place to > define/register a scope claim.**** > > **** > > On Thu, Feb 28, 2013 at 9:24 AM, Phil Hunt wrote:*= * > ** > > Are you advocating TWO systems? That seems like a bad choice. > > I would rather fix scope than go to a two system approach. > > Phil > > Sent from my phone. > > On 2013-02-28, at 8:17, John Bradley wrote: > > > While scope is one method that a AS could communicate authorization to = a > RS, it is not the only or perhaps even the most likely one. > > Using scope requires a relatively tight binding between the RS and AS, > UMA uses a different mechanism that describes finer grained operations. > > The AS may include roles, user, or other more abstract claims that the > the client may (god help them) pass on to EXCML for processing. > > > > While having a scopes claim is possible, like any other claim it is not > part of the JWT core security processing claims, and needs to be defined = by > extension. > > > > John B. > > On 2013-02-28, at 2:29 AM, Hannes Tschofenig > wrote: > > > >> Hi Mike, > >> > >> when I worked on the MAC specification I noticed that the JWT does not > have a claim for the scope. I believe that this would be needed to allow > the resource server to verify whether the scope the authorization server > authorized is indeed what the client is asking for. > >> > >> Ciao > >> Hannes > >> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth**** > > **** > > **** > > **** > > **** > > **** > > ** ** > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --=20 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --e0cb4efe2f9cefed7904d79e73a3 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable So, it is soooo late in the game: I have been completely underwater to even= read the OAuth mails for about a month and slowly catching up now.=A0
=
Here is an I-D that I have created partly in response to the= RS-AS interaction piece that was talked about at IETF 85.=A0
It does not have 'scope' and has 'claims' instead as i= t was based on OpenID Connect, but it is easy to add, provided that the sco= pes are to be understood as that of the 'aud'.=A0


Best,=A0

Nat
2013/3/1 Lewis Adam-CAL022 <= Adam.Lewis@motorolasolutions.com>

Hmmm, I=92m not so sure.=A0= It depends where we all think OAuth is on its trajectory.=A0 On one hand, = OAuth has already seen an insanely massive amount of deployment.=A0 On the other hand, RESTful APIs see no sign of slowing down.=A0=A0 Now I= =92m not going to go so far as Craig B. and say that everything and everyon= e will be API enabled in the future, but it sure is going to be a lot.=A0 T= hat being said, one could argue that even with all the OAuth implementation we=92ve seen, that this is just the infa= ncy of it.=A0 Obviously a WG profile of a JWT-structured AT could not depre= cate other forms (unstructured, SAML, etc.) but going forward new developer= s may choose to embrace this, and in fact this could even be the guidance. =A0=A0I agree with previous comments= that Justin=92s introspection draft might be a good place to explore this.=

=A0

adam

=A0

From: Brian Ca= mpbell [mailto:bcampbell@pingidentity.com]
Sent: Thursday, February 28, 2013 1:36 PM
To: Lewis Adam-CAL022
Cc: John Bradley; oauth@ietf.org WG


Subject: Re: [OAUTH-WG] JWT - scope claim missing

=A0

I do agree that a WG = profile of a JWT-structured access token could lend itself to interoperabil= ity and ultimately be a useful thing. But you are right that there already = are many implementations out there in the wild (heck, I've written one myself) and that might make it diffic= ult to standardize on something.

Because of that, and many other reasons, I don't= want to try and add that to existing assertion drafts.

=A0

On Thu, Feb 28, 2013 at 12:13 PM, Lewis Adam-CAL022 = <A= dam.Lewis@motorolasolutions.com> wrote:

Hi Brian, a few thoughts fr= om somebody outside of the WG =85

=A0

As a newcomer to OAuth last= year, I was initially confused by the titles.=A0 It was confusing because we have SAML bearer *assertions* and JWT bearer *tokens* =85= and as John just (begrudgingly) stated in this thread, the JWT is being us= ed as an assertion in this profile (and in OIDC).=A0 I think it will be dif= ficult to find a good name for these profiles since they do two entirely different things (e.g. define a new gr= ant type and define a new method of client authentication).=A0 One could ar= gue that as long as the WG is at it, then why not add a third section to th= e JWT profile, which talks about usage of JWT-structured bearer access tokens: it would not be any less related t= han the other two focuses of the doc.=A0 Then the document could be called = something simple like =93profiles of JWT usage in OAuth=94 or something lik= e that.=A0

=A0

On one hand, it is probably= na=EFve to think that an access token can be standardized in a profile giv= en how many have already been released into the wild, but on the other hand, = a WG profile of a JWT-structured access token could lend itself to interope= rability, where AS implementations can advertise conformance to the profile= and who knows =85 maybe the RS=92s of the future will be good with this.=A0

=A0

adam

=A0

From: oauth-bounces@i= etf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Brian Campbell
Sent: Thursday, February 28, 2013 1:03 PM
To: John Bradley
Cc: oauth@ietf.o= rg WG


Subject: Re: [OAUTH-WG] JWT - scope claim missing

=A0

I'm not sure anyo= ne really "picked" the titles for the bearer token profiles. They= just kind of evolved. And evolved in funny ways especially when client aut= hn to the AS was added.

You won't hear me= argue that the titles are "good" and this is not the first time = there's been confusion about what they actually do. They define new gra= nt types and new client authentication methods. They *do not* define an access token format or anything else abou= t access tokens. JWT and SAML could be used for that but that's not wha= t these drafts do.

Suggestions for better title(s) would be more than w= elcome.

=A0

Here's what they are now:


SAML 2.0 Bearer Assertion Profiles for OAuth 2.0
draft-ietf-oauth-saml2-bearer

JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0
draft-ietf-oauth-jwt-bearer

Assertion Framework for OAuth 2.0
draft-ietf-oauth-assertions

=A0

On Thu, Feb 28, 2013 at 11:36 AM, John Bradley <<= a href=3D"mailto:ve7jtb@ve7jtb.com" target=3D"_blank">ve7jtb@ve7jtb.com= > wrote:

Yes the title likely adds to the confusion given tha= t the bearer tokens are not access tokens.

=A0

Things as separate from OAuth as the Firefox browerI= D spec use JWS signed JWTs. =A0

=A0

The bearer token profiles for OAuth 2 are for OAuth2= .

=A0

The=A0JSON Web Token (JWT)=A0sp= ec did not start in OAuth and is not OAuth specific.

=A0

A JWT is:

JSON Web Token (JWT)=A0 A string repr=
esenting a set of claims as a JSON
=A0=A0=A0=A0=A0 object that is encode=
d in a JWS or JWE, enabling the claims to be
=A0=A0=A0=A0=A0 digitally signed or M=
ACed and/or encrypted.

=A0

So OAuth or other profiles may define claims to go i= n a JWT, but the JWT needs to itself only define the claims necessary for s= ecurity processing. =A0

=A0

John B.

PS that was a soft ball If you hadn't responded = I would have been disappointed. =A0I din't pick the title for the beare= r token profiles.

=A0

=A0

On 2013-02-28, at 10:12 AM, Phil Hunt <phil.hunt@oracle.com>= ; wrote:

=A0

JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0=


Note the title says "for OAuth2"

=A0

Sorry. Couldn't resist.=A0

=A0

Phil

=A0

Sent from my phone.


On 2013-02-28, at 9:40, John Bradley <ve7jtb@ve7jtb.com> wrote:

JWT is an assertion( I am probably going to regret u= sing that word).

=A0

It is used in openID connect for id_tokens, it is us= ed in OAuth for Assertion grant types and authentication of the client to t= he token endpoint.

=A0

=A0
=A0

JS= ON Web Token (JWT) Bearer Token Profiles for OAuth 2.0=

=A0

Dosen't define JWT's use for access tokens f= or the RS. =A0=A0

=A0

Bottom line JWT is for more than access tokens.

=A0

John B.

=A0

On 2013-02-28, at 9:28 AM, Phil Hunt <phil.hunt@oracle.com>= wrote:

=A0

Are you saying jwt is not an access token type?

Phil

=A0

Sent from my phone.


On 2013-02-28, at 8:58, John Bradley <ve7jtb@ve7jtb.com> wrote:

Yes, defining scope in JWT is the wrong place. =A0 J= WT needs to stick to the security claims needed to process JWT.

=A0

I also don't know how far you get requiring a sp= ecific authorization format for JWT, some AS will wan to use a opaque refer= ence, some might want to use a user claim or role claim, others may use scopes, =A0combining scopes and claims is also possible.=

=A0

Right now it is up to a AS RS pair to agree on how t= o communicate authorization. =A0 I don't want MAC to be more restrictiv= e than bearer when it comes to authorization between AS and RS.

=A0

Hannes wanted to know why JWT didn't define scop= e. =A0The simple answer is that it is out of scope for JWT itself. =A0 It m= ight be defined in a OAuth access token profile for JWT but it should not be specific to MAC.

=A0

John B.

On 2013-02-28, at 8:44 AM, Brian Campbell <bcampbell@pingide= ntity.com> wrote:

=A0

I think John's po= int was more that scope is something rather specific to an OAuth access tok= en and, while JWT is can be used to represent an access token, it's not= the only application of JWT. The 'standard' claims in JWT are those that are believed (= right or wrong) to be widely applicable across different applications of JW= T. One could argue about it but scope is probably not one of those.<= u>

It would probably make sense to try and build a prof= ile of JWT specifically for OAuth access tokens (though I suspect there are= some turtles and dragons in there), which might be the appropriate place to define/register a scope claim.

=A0

On Thu, Feb 28, 2013 at 9:24 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

Are you advocating TWO systems? That seems like a ba= d choice.

I would rather fix scope than go to a two system approach.

Phil

Sent from my phone.

On 2013-02-28, at 8:17, John Bradley <ve7jtb@ve7jtb.com> wrote:

> While scope is one method that a AS could communicate authorization to= a RS, it is not the only or perhaps even the most likely one.
> Using scope requires a relatively tight binding between the RS and AS,= =A0UMA uses a different mechanism that describes finer grained operations.=
> The AS may include roles, user, or other more abstract claims that the= the client may (god help them) pass on to EXCML for processing.
>
> While having a scopes claim is possible, like any other claim it is no= t part of the JWT core security processing claims, and needs to be defined = by extension.
>
> John B.
> On 2013-02-28, at 2:29 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net>= wrote:
>
>> Hi Mike,
>>
>> when I worked on the MAC specification I noticed that the JWT does= not have a claim for the scope. I believe that this would be needed to all= ow the resource server to verify whether the scope the authorization server= authorized is indeed what the client is asking for.
>>
>> Ciao
>> Hannes
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org=
>> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

=A0

=A0

=A0

=A0

=A0

=A0


_______________________________________________
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
--e0cb4efe2f9cefed7904d79e73a3-- From phil.hunt@oracle.com Mon Mar 11 07:25: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 8E44D21F8923 for ; Mon, 11 Mar 2013 07:25: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.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 ak02+bLUbnYq for ; Mon, 11 Mar 2013 07:25:01 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 3BCF021F8A3E for ; Mon, 11 Mar 2013 07:25:01 -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 r2BEOua4031469 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 11 Mar 2013 14:24:57 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r2BEOuAX025940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Mar 2013 14:24:56 GMT Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r2BEOuj7010590; Mon, 11 Mar 2013 09:24:56 -0500 Received: from dhcp-16e2.meeting.ietf.org (/130.129.22.226) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 11 Mar 2013 07:24:55 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_BD9CBC16-41F4-41D7-B772-E98C8B53B26D" From: Phil Hunt In-Reply-To: Date: Mon, 11 Mar 2013 07:24:56 -0700 Message-Id: References: <0EC2404F-E3C5-4AD1-88B4-E74AA0394DD9@gmx.net> <48FD87D1-4DF4-4289-99B7-40A515F31890@oracle.com> <3E472720-31A4-40A0-AAA4-402CF850831A@ve7jtb.com> <7127843B-D7B0-4AB6-87F1-1604D1EFFA79@oracle.com> <50DA292F-32F0-4266-8401-006AD837B775@ve7jtb.com> <59E470B10C4630419ED717AC79FCF9A948D58BEE@BY2PRD0411MB441.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A948D58DC0@BY2PRD0411MB441.namprd04.prod.outlook.com> To: Nat Sakimura 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] JWT - scope claim missing X-BeenThere: oauth@ietf.org X-Mailman-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, 11 Mar 2013 14:25:03 -0000 --Apple-Mail=_BD9CBC16-41F4-41D7-B772-E98C8B53B26D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 One thing that concerns me is that scope is very different from a claim. = An claim is an assertion provided that may have some level of = dispute/quality etc. A scope defines what is request or what has been authorized. It's an = absolute thing. Therefore it is not a claim. Audience...maybe.=20 This is why I think scope deserves special attention/discussion in = authorization assertions and in access tokens. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-03-10, at 9:17 PM, Nat Sakimura wrote: > So, it is soooo late in the game: I have been completely underwater to = even read the OAuth mails for about a month and slowly catching up now.=20= >=20 > Here is an I-D that I have created partly in response to the RS-AS = interaction piece that was talked about at IETF 85.=20 > It does not have 'scope' and has 'claims' instead as it was based on = OpenID Connect, but it is easy to add, provided that the scopes are to = be understood as that of the 'aud'.=20 >=20 > http://tools.ietf.org/id/draft-sakimura-oidc-structured-token-01.txt >=20 > Best,=20 >=20 > Nat >=20 > 2013/3/1 Lewis Adam-CAL022 > Hmmm, I=92m not so sure. It depends where we all think OAuth is on = its trajectory. On one hand, OAuth has already seen an insanely massive = amount of deployment. On the other hand, RESTful APIs see no sign of = slowing down. Now I=92m not going to go so far as Craig B. and say = that everything and everyone will be API enabled in the future, but it = sure is going to be a lot. That being said, one could argue that even = with all the OAuth implementation we=92ve seen, that this is just the = infancy of it. Obviously a WG profile of a JWT-structured AT could not = deprecate other forms (unstructured, SAML, etc.) but going forward new = developers may choose to embrace this, and in fact this could even be = the guidance. I agree with previous comments that Justin=92s = introspection draft might be a good place to explore this. >=20 > =20 >=20 > adam >=20 > =20 >=20 > From: Brian Campbell [mailto:bcampbell@pingidentity.com]=20 > Sent: Thursday, February 28, 2013 1:36 PM > To: Lewis Adam-CAL022 > Cc: John Bradley; oauth@ietf.org WG >=20 >=20 > Subject: Re: [OAUTH-WG] JWT - scope claim missing >=20 > =20 >=20 > I do agree that a WG profile of a JWT-structured access token could = lend itself to interoperability and ultimately be a useful thing. But = you are right that there already are many implementations out there in = the wild (heck, I've written one myself) and that might make it = difficult to standardize on something. >=20 > Because of that, and many other reasons, I don't want to try and add = that to existing assertion drafts. >=20 > =20 >=20 > On Thu, Feb 28, 2013 at 12:13 PM, Lewis Adam-CAL022 = wrote: >=20 > Hi Brian, a few thoughts from somebody outside of the WG =85 >=20 > =20 >=20 > As a newcomer to OAuth last year, I was initially confused by the = titles. It was confusing because we have SAML bearer *assertions* and = JWT bearer *tokens* =85 and as John just (begrudgingly) stated in this = thread, the JWT is being used as an assertion in this profile (and in = OIDC). I think it will be difficult to find a good name for these = profiles since they do two entirely different things (e.g. define a new = grant type and define a new method of client authentication). One could = argue that as long as the WG is at it, then why not add a third section = to the JWT profile, which talks about usage of JWT-structured bearer = access tokens: it would not be any less related than the other two = focuses of the doc. Then the document could be called something simple = like =93profiles of JWT usage in OAuth=94 or something like that.=20 >=20 > =20 >=20 > On one hand, it is probably na=EFve to think that an access token can = be standardized in a profile given how many have already been released = into the wild, but on the other hand, a WG profile of a JWT-structured = access token could lend itself to interoperability, where AS = implementations can advertise conformance to the profile and who knows =85= maybe the RS=92s of the future will be good with this.=20 >=20 > =20 >=20 > adam >=20 > =20 >=20 > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf = Of Brian Campbell > Sent: Thursday, February 28, 2013 1:03 PM > To: John Bradley > Cc: oauth@ietf.org WG >=20 >=20 > Subject: Re: [OAUTH-WG] JWT - scope claim missing >=20 > =20 >=20 > I'm not sure anyone really "picked" the titles for the bearer token = profiles. They just kind of evolved. And evolved in funny ways = especially when client authn to the AS was added. >=20 > You won't hear me argue that the titles are "good" and this is not the = first time there's been confusion about what they actually do. They = define new grant types and new client authentication methods. They *do = not* define an access token format or anything else about access tokens. = JWT and SAML could be used for that but that's not what these drafts do. >=20 > Suggestions for better title(s) would be more than welcome. >=20 > =20 >=20 > Here's what they are now: >=20 >=20 > SAML 2.0 Bearer Assertion Profiles for OAuth 2.0 > draft-ietf-oauth-saml2-bearer >=20 > JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0 > draft-ietf-oauth-jwt-bearer >=20 > Assertion Framework for OAuth 2.0 > draft-ietf-oauth-assertions >=20 > =20 >=20 > On Thu, Feb 28, 2013 at 11:36 AM, John Bradley = wrote: >=20 > Yes the title likely adds to the confusion given that the bearer = tokens are not access tokens. >=20 > =20 >=20 > Things as separate from OAuth as the Firefox browerID spec use JWS = signed JWTs. =20 >=20 > =20 >=20 > The bearer token profiles for OAuth 2 are for OAuth2. >=20 > =20 >=20 > The JSON Web Token (JWT) spec did not start in OAuth and is not OAuth = specific. >=20 > =20 >=20 > A JWT is: >=20 > JSON Web Token (JWT) A string representing a set of claims as a JSON > object that is encoded in a JWS or JWE, enabling the claims to = be > digitally signed or MACed and/or encrypted. > =20 >=20 > So OAuth or other profiles may define claims to go in a JWT, but the = JWT needs to itself only define the claims necessary for security = processing. =20 >=20 > =20 >=20 > John B. >=20 > PS that was a soft ball If you hadn't responded I would have been = disappointed. I din't pick the title for the bearer token profiles. >=20 > =20 >=20 > =20 >=20 > On 2013-02-28, at 10:12 AM, Phil Hunt wrote: >=20 > =20 >=20 > JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0 >=20 >=20 > Note the title says "for OAuth2" >=20 > =20 >=20 > Sorry. Couldn't resist.=20 >=20 > =20 >=20 > Phil >=20 > =20 >=20 > Sent from my phone. >=20 >=20 > On 2013-02-28, at 9:40, John Bradley wrote: >=20 > JWT is an assertion( I am probably going to regret using that word). >=20 > =20 >=20 > It is used in openID connect for id_tokens, it is used in OAuth for = Assertion grant types and authentication of the client to the token = endpoint. >=20 > http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-04 >=20 > =20 >=20 > =20 > =20 > JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0 >=20 > =20 >=20 > Dosen't define JWT's use for access tokens for the RS. =20 >=20 > =20 >=20 > Bottom line JWT is for more than access tokens. >=20 > =20 >=20 > John B. >=20 > =20 >=20 > On 2013-02-28, at 9:28 AM, Phil Hunt wrote: >=20 > =20 >=20 > Are you saying jwt is not an access token type? >=20 > Phil >=20 > =20 >=20 > Sent from my phone. >=20 >=20 > On 2013-02-28, at 8:58, John Bradley wrote: >=20 > Yes, defining scope in JWT is the wrong place. JWT needs to stick to = the security claims needed to process JWT. >=20 > =20 >=20 > I also don't know how far you get requiring a specific authorization = format for JWT, some AS will wan to use a opaque reference, some might = want to use a user claim or role claim, others may use scopes, = combining scopes and claims is also possible. >=20 > =20 >=20 > Right now it is up to a AS RS pair to agree on how to communicate = authorization. I don't want MAC to be more restrictive than bearer = when it comes to authorization between AS and RS. >=20 > =20 >=20 > Hannes wanted to know why JWT didn't define scope. The simple answer = is that it is out of scope for JWT itself. It might be defined in a = OAuth access token profile for JWT but it should not be specific to MAC. >=20 > =20 >=20 > John B. >=20 > On 2013-02-28, at 8:44 AM, Brian Campbell = wrote: >=20 > =20 >=20 > I think John's point was more that scope is something rather specific = to an OAuth access token and, while JWT is can be used to represent an = access token, it's not the only application of JWT. The 'standard' = claims in JWT are those that are believed (right or wrong) to be widely = applicable across different applications of JWT. One could argue about = it but scope is probably not one of those. >=20 > It would probably make sense to try and build a profile of JWT = specifically for OAuth access tokens (though I suspect there are some = turtles and dragons in there), which might be the appropriate place to = define/register a scope claim. >=20 > =20 >=20 > On Thu, Feb 28, 2013 at 9:24 AM, Phil Hunt = wrote: >=20 > Are you advocating TWO systems? That seems like a bad choice. >=20 > I would rather fix scope than go to a two system approach. >=20 > Phil >=20 > Sent from my phone. >=20 > On 2013-02-28, at 8:17, John Bradley wrote: >=20 > > While scope is one method that a AS could communicate authorization = to a RS, it is not the only or perhaps even the most likely one. > > Using scope requires a relatively tight binding between the RS and = AS, UMA uses a different mechanism that describes finer grained = operations. > > The AS may include roles, user, or other more abstract claims that = the the client may (god help them) pass on to EXCML for processing. > > > > While having a scopes claim is possible, like any other claim it is = not part of the JWT core security processing claims, and needs to be = defined by extension. > > > > John B. > > On 2013-02-28, at 2:29 AM, Hannes Tschofenig = wrote: > > > >> Hi Mike, > >> > >> when I worked on the MAC specification I noticed that the JWT does = not have a claim for the scope. I believe that this would be needed to = allow the resource server to verify whether the scope the authorization = server authorized is indeed what the client is asking for. > >> > >> Ciao > >> Hannes > >> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 > =20 >=20 > =20 >=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 >=20 >=20 > --=20 > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_BD9CBC16-41F4-41D7-B772-E98C8B53B26D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 One = thing that concerns me is that scope is very different from a claim. An = claim is an assertion provided that may have some level of = dispute/quality etc.

A scope defines what is request = or what has been authorized.  It's an absolute thing. Therefore it = is not a claim. Audience...maybe. 

This is = why I think scope deserves special attention/discussion in authorization = assertions and in access tokens.

Phil

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





On 2013-03-10, at 9:17 PM, Nat Sakimura wrote:

So, it is = soooo late in the game: I have been completely underwater to even read = the OAuth mails for about a month and slowly catching up = now. 

Here is an I-D that I have created partly = in response to the RS-AS interaction piece that was talked about at IETF = 85. 
It does not have 'scope' and has 'claims' instead as it was based = on OpenID Connect, but it is easy to add, provided that the scopes are = to be understood as that of the 'aud'. 



=
2013/3/1 Lewis Adam-CAL022 <Adam.Lewis@motorolasolutions.com>

Hmmm, I=92m not so = sure.  It depends where we all think OAuth is on its = trajectory.  On one hand, OAuth has already seen an insanely = massive amount of deployment.  On the other hand, RESTful APIs see no sign of slowing = down.   Now I=92m not going to go so far as Craig B. and say = that everything and everyone will be API enabled in the future, but it = sure is going to be a lot.  That being said, one could argue that = even with all the OAuth implementation we=92ve seen, that this is just the = infancy of it.  Obviously a WG profile of a JWT-structured AT could = not deprecate other forms (unstructured, SAML, etc.) but going forward = new developers may choose to embrace this, and in fact this could even be the guidance.   I agree with previous = comments that Justin=92s introspection draft might be a good place to = explore this.

 

adam

=

 

From: Brian Campbell [mailto:bcampbell@pingidentity.com]
Sent: Thursday, February 28, 2013 1:36 PM
To: Lewis Adam-CAL022
Cc: John Bradley; oauth@ietf.org WG


Subject: Re: [OAUTH-WG] JWT - scope claim = missing

 

I do agree = that a WG profile of a JWT-structured access token could lend itself to = interoperability and ultimately be a useful thing. But you are right = that there already are many implementations out there in the wild (heck, I've written one myself) and that might make it = difficult to standardize on something.

Because of that, and many other reasons, I = don't want to try and add that to existing assertion = drafts.

 

On Thu, Feb 28, 2013 at 12:13 PM, Lewis = Adam-CAL022 <Adam.Lewis@motorolasolutions.com> = wrote:

Hi Brian, a few thoughts = from somebody outside of the WG =85

 

As a newcomer to OAuth last = year, I was initially confused by the titles.  It was confusing = because we have SAML bearer *assertions* and JWT bearer *tokens* = =85 and as John just (begrudgingly) stated in this thread, the JWT is = being used as an assertion in this profile (and in OIDC).  I think = it will be difficult to find a good name for these profiles since they do two entirely different things (e.g. define a new = grant type and define a new method of client authentication).  One = could argue that as long as the WG is at it, then why not add a third = section to the JWT profile, which talks about usage of JWT-structured bearer access tokens: it would not be any less = related than the other two focuses of the doc.  Then the document = could be called something simple like =93profiles of JWT usage in OAuth=94= or something like that. 

 

On one hand, it is probably = na=EFve to think that an access token can be standardized in a profile = given how many have already been released into the wild, but on the other = hand, a WG profile of a JWT-structured access token could lend itself to = interoperability, where AS implementations can advertise conformance to = the profile and who knows =85 maybe the RS=92s of the future will be good with this. 

 

adam

=

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Brian Campbell
Sent: Thursday, February 28, 2013 1:03 PM
To: John Bradley
Cc: oauth@ietf.org WG


Subject: Re: [OAUTH-WG] JWT - scope claim = missing

 

I'm not sure = anyone really "picked" the titles for the bearer token profiles. They = just kind of evolved. And evolved in funny ways especially when client = authn to the AS was added.

You won't = hear me argue that the titles are "good" and this is not the first time = there's been confusion about what they actually do. They define new = grant types and new client authentication methods. They *do not* define an access token format or anything else = about access tokens. JWT and SAML could be used for that but that's not = what these drafts do.

Suggestions for better title(s) would be = more than welcome.

 

Here's what they are now:


SAML 2.0 Bearer Assertion Profiles for OAuth 2.0
draft-ietf-oauth-saml2-bearer

JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0
draft-ietf-oauth-jwt-bearer

Assertion Framework for OAuth 2.0
draft-ietf-oauth-assertions

 

On Thu, Feb 28, 2013 at 11:36 AM, John = Bradley <ve7jtb@ve7jtb.com> wrote:

Yes the title likely adds to the confusion = given that the bearer tokens are not access tokens.

 

Things as separate from OAuth as the Firefox = browerID spec use JWS signed JWTs.  

 

The bearer token profiles for OAuth 2 are = for OAuth2.

 

The JSON Web Token (JWT) spec did not start in = OAuth and is not OAuth specific.

 

A JWT is:

JSON Web Token (JWT)  A =
string representing a set of claims as a JSON
      =
object that is encoded in a JWS or JWE, enabling the claims to =
be
      =
digitally signed or MACed and/or encrypted.

 

So OAuth or other profiles may define claims = to go in a JWT, but the JWT needs to itself only define the claims = necessary for security processing.  

 

John B.

PS that was a soft ball If you hadn't = responded I would have been disappointed.  I din't pick the title = for the bearer token profiles.

 

 

On 2013-02-28, at 10:12 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

 

JSON = Web Token (JWT) Bearer Token Profiles for OAuth = 2.0


Note the title says "for OAuth2"

 

Sorry. Couldn't = resist. 

 

Phil

 

Sent from my phone.


On 2013-02-28, at 9:40, John Bradley <ve7jtb@ve7jtb.com> wrote:

JWT is an assertion( I am probably going to regret = using that word).

 

It is used in openID connect for id_tokens, = it is used in OAuth for Assertion grant types and authentication of the = client to the token endpoint.

 

 
 

JSON Web Token (JWT) Bearer Token Profiles for OAuth = 2.0

 

Dosen't define JWT's use for access tokens = for the RS.   

 

Bottom line JWT is for more than access = tokens.

 

John B.

 

On 2013-02-28, at 9:28 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

 

Are you saying jwt is not an access token = type?

Phil

 

Sent from my phone.


On 2013-02-28, at 8:58, John Bradley <ve7jtb@ve7jtb.com> wrote:

Yes, defining scope in JWT is the wrong place. =   JWT needs to stick to the security claims needed to process = JWT.

 

I also don't know how far you get requiring = a specific authorization format for JWT, some AS will wan to use a = opaque reference, some might want to use a user claim or role claim, others may use scopes,  combining scopes and claims is also = possible.

 

Right now it is up to a AS RS pair to agree = on how to communicate authorization.   I don't want MAC to be more = restrictive than bearer when it comes to authorization between AS and RS.

 

Hannes wanted to know why JWT didn't define = scope.  The simple answer is that it is out of scope for JWT = itself.   It might be defined in a OAuth access token profile for = JWT but it should not be specific to MAC.

 

John B.

On 2013-02-28, at 8:44 AM, Brian Campbell = <bcampbell@pingidentity.com> = wrote:

 

I think = John's point was more that scope is something rather specific to an = OAuth access token and, while JWT is can be used to represent an access = token, it's not the only application of JWT. The 'standard' claims in JWT are those that are believed (right = or wrong) to be widely applicable across different applications of JWT. = One could argue about it but scope is probably not one of = those.

It would probably make sense to try and = build a profile of JWT specifically for OAuth access tokens (though I = suspect there are some turtles and dragons in there), which might be the appropriate place to define/register a scope = claim.

 

On Thu, Feb 28, 2013 at 9:24 AM, Phil Hunt = <phil.hunt@oracle.com> = wrote:

Are you advocating TWO = systems? That seems like a bad choice.

I would rather fix scope than go to a two system approach.

Phil

Sent from my phone.

On 2013-02-28, at 8:17, John Bradley <ve7jtb@ve7jtb.com> wrote:

> While scope is one method that a AS could communicate authorization = to a RS, it is not the only or perhaps even the most likely one.
> Using scope requires a relatively tight binding between the RS and = AS,  UMA uses a different mechanism that describes finer grained = operations.
> The AS may include roles, user, or other more abstract claims that = the the client may (god help them) pass on to EXCML for processing.
>
> While having a scopes claim is possible, like any other claim it is = not part of the JWT core security processing claims, and needs to be = defined by extension.
>
> John B.
> On 2013-02-28, at 2:29 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
>
>> Hi Mike,
>>
>> when I worked on the MAC specification I noticed that the JWT = does not have a claim for the scope. I believe that this would be needed = to allow the resource server to verify whether the scope the = authorization server authorized is indeed what the client is asking for.
>>
>> Ciao
>> Hannes
>>
>> _______________________________________________
>> OAuth mailing 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




--
Nat = Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
_______________________________________________
OAuth mailing = list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth

= --Apple-Mail=_BD9CBC16-41F4-41D7-B772-E98C8B53B26D-- From hannes.tschofenig@gmx.net Mon Mar 11 07:25: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 B8AE521F8B0B for ; Mon, 11 Mar 2013 07:25:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.456 X-Spam-Level: X-Spam-Status: No, score=-102.456 tagged_above=-999 required=5 tests=[AWL=0.143, 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 mYwwfKASN9Gd for ; Mon, 11 Mar 2013 07:25:25 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 845EB21F8B97 for ; Mon, 11 Mar 2013 07:25:24 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.33]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0M0euW-1V2tfJ1d9C-00urbQ for ; Mon, 11 Mar 2013 15:25:23 +0100 Received: (qmail invoked by alias); 11 Mar 2013 14:25:23 -0000 Received: from dhcp-1077.meeting.ietf.org (EHLO dhcp-1077.meeting.ietf.org) [130.129.16.119] by mail.gmx.net (mp033) with SMTP; 11 Mar 2013 15:25:23 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+qiFRajhOq/PR/yCZxjxNL5jOR3La7fLWbG+7iRA zpIwpGiydx0u4X Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1085) From: Hannes Tschofenig Date: Mon, 11 Mar 2013 10:23:24 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "oauth@ietf.org WG" X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] Fwd: Alternative PKI Models Side Meeting X-BeenThere: oauth@ietf.org X-Mailman-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, 11 Mar 2013 14:25:25 -0000 FYI: in case you are interested in that conversation. The topic about = the value of TLS and the problems with the PKI have surfaced in the past = on this list.=20 Begin forwarded message: > From: Hannes Tschofenig > Date: March 5, 2013 9:19:51 AM EST > To: 86attendees@ietf.org > Cc: Hannes Tschofenig > Subject: Alternative PKI Models Side Meeting >=20 > Hi all, >=20 > When our security ADs scheduled the BOF on Certificate Transparency = (CT) [0] in Atlanta (IETF-85), some expressed interest in continuing the = discussions regarding improvements to the Web PKI. In the IAB, we have = been brainstorming about holding a workshop to progress the topic, but = with the announcement of the NIST workshop on Improving Trust in the = Online Marketplace [1] we decided to postpone our workshop. >=20 > The upcoming IETF-86 meeting is, however, a good opportunity to = discuss whether there is a need for additional investigations. In = particular, we have been wondering whether the IETF community has the = same level of understanding regarding the requirements, goals, and the = design assumptions. The emerging evolutionary alterations to the Web PKI = model -- i.e., DANE, CT, TACK, etc. -- superficially fit the model, but = they alter it in subtle and interesting ways. >=20 > If you are interested in a discussion you are welcome to join our side = meeting on Thursday evening (at 8pm*) in room Boca 4 (the IAB Office). >=20 > Ciao > Hannes & JeffH >=20 > References:=20 > [0] https://www.ietf.org/mailman/listinfo/therightkey > [1] http://www.nist.gov/itl/csd/ct/ca_workshop.cfm >=20 > PS: We picked 8pm since some of you may want to stop by at the = Bits-N-Bites event. From Adam.Lewis@motorolasolutions.com Mon Mar 11 07:36: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 B6CD821F8C3E for ; Mon, 11 Mar 2013 07:36:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.466 X-Spam-Level: X-Spam-Status: No, score=-0.466 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 16gyc8nny2-t for ; Mon, 11 Mar 2013 07:36:52 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) by ietfa.amsl.com (Postfix) with ESMTP id B633221F8B6C for ; Mon, 11 Mar 2013 07:36:51 -0700 (PDT) Received: from mail150-va3-R.bigfish.com (10.7.14.250) by VA3EHSOBE013.bigfish.com (10.7.40.63) with Microsoft SMTP Server id 14.1.225.23; Mon, 11 Mar 2013 14:36:51 +0000 Received: from mail150-va3 (localhost [127.0.0.1]) by mail150-va3-R.bigfish.com (Postfix) with ESMTP id E01C54E0176 for ; Mon, 11 Mar 2013 14:36:50 +0000 (UTC) X-Forefront-Antispam-Report: CIP:192.160.210.20; KIP:(null); UIP:(null); IPV:NLI; H:ct11msg01.am.mot-solutions.com; RD:ct11msg01.mot-solutions.com; EFVD:NLI X-SpamScore: -32 X-BigFish: VPS-32(zzbb2dI98dI9371Ic89bh936eIc85dh1432I179cI179dNzz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz8275ch1033IL17326ah8275dh18c673h1954cbh18602eh8275bhz2fh2a8h683h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1b0ah1155h) Received-SPF: pass (mail150-va3: domain of motorolasolutions.com designates 192.160.210.20 as permitted sender) client-ip=192.160.210.20; envelope-from=Adam.Lewis@motorolasolutions.com; helo=ct11msg01.am.mot-solutions.com ; olutions.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.237.133; KIP:(null); UIP:(null); (null); H:BY2PRD0411HT005.namprd04.prod.outlook.com; R:internal; EFV:INT Received: from mail150-va3 (localhost.localdomain [127.0.0.1]) by mail150-va3 (MessageSwitch) id 1363012608612624_3128; Mon, 11 Mar 2013 14:36:48 +0000 (UTC) Received: from VA3EHSMHS031.bigfish.com (unknown [10.7.14.249]) by mail150-va3.bigfish.com (Postfix) with ESMTP id 78CBA100052 for ; Mon, 11 Mar 2013 14:36:48 +0000 (UTC) Received: from ct11msg01.am.mot-solutions.com (192.160.210.20) by VA3EHSMHS031.bigfish.com (10.7.99.41) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 11 Mar 2013 14:36:45 +0000 Received: from ct11msg01.am.mot-solutions.com (ct11vts03.am.mot.com [10.177.16.162]) by ct11msg01.am.mot-solutions.com (8.14.3/8.14.3) with ESMTP id r2BEaOxl013867 for ; Mon, 11 Mar 2013 09:36:24 -0500 (CDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe006.messaging.microsoft.com [213.199.154.144]) by ct11msg01.am.mot-solutions.com (8.14.3/8.14.3) with ESMTP id r2BEaM2u013859 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 11 Mar 2013 09:36:23 -0500 (CDT) Received: from mail1-db3-R.bigfish.com (10.3.81.239) by DB3EHSOBE003.bigfish.com (10.3.84.23) with Microsoft SMTP Server id 14.1.225.23; Mon, 11 Mar 2013 14:36:43 +0000 Received: from mail1-db3 (localhost [127.0.0.1]) by mail1-db3-R.bigfish.com (Postfix) with ESMTP id 5C885220163 for ; Mon, 11 Mar 2013 14:36:43 +0000 (UTC) Received: from mail1-db3 (localhost.localdomain [127.0.0.1]) by mail1-db3 (MessageSwitch) id 1363012599616827_3177; Mon, 11 Mar 2013 14:36:39 +0000 (UTC) Received: from DB3EHSMHS006.bigfish.com (unknown [10.3.81.228]) by mail1-db3.bigfish.com (Postfix) with ESMTP id 8F980800C5; Mon, 11 Mar 2013 14:36:39 +0000 (UTC) Received: from BY2PRD0411HT005.namprd04.prod.outlook.com (157.56.237.133) by DB3EHSMHS006.bigfish.com (10.3.87.106) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 11 Mar 2013 14:36:37 +0000 Received: from BY2PRD0411MB441.namprd04.prod.outlook.com ([169.254.5.10]) by BY2PRD0411HT005.namprd04.prod.outlook.com ([10.255.128.40]) with mapi id 14.16.0275.006; Mon, 11 Mar 2013 14:36:30 +0000 From: Lewis Adam-CAL022 To: Phil Hunt , Nat Sakimura Thread-Topic: [OAUTH-WG] JWT - scope claim missing Thread-Index: AQHOFZ6Qe5ExGqoPnkOeJlU0r70rz5iPcwoAgAAB5gCAAAWJgIAABAMAgAAIM4CAAAN2AIAACPeAgAAGkICAAAeWAIAAAR2AgAAILoCAACqKMIAQyEHEgAACRiA= Date: Mon, 11 Mar 2013 14:36:29 +0000 Message-ID: <59E470B10C4630419ED717AC79FCF9A956893F49@BY2PRD0411MB441.namprd04.prod.outlook.com> References: <0EC2404F-E3C5-4AD1-88B4-E74AA0394DD9@gmx.net> <48FD87D1-4DF4-4289-99B7-40A515F31890@oracle.com> <3E472720-31A4-40A0-AAA4-402CF850831A@ve7jtb.com> <7127843B-D7B0-4AB6-87F1-1604D1EFFA79@oracle.com> <50DA292F-32F0-4266-8401-006AD837B775@ve7jtb.com> <59E470B10C4630419ED717AC79FCF9A948D58BEE@BY2PRD0411MB441.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A948D58DC0@BY2PRD0411MB441.namprd04.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [150.130.164.106] Content-Type: multipart/alternative; boundary="_000_59E470B10C4630419ED717AC79FCF9A956893F49BY2PRD0411MB441_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%1294$Dn%ORACLE.COM$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn% X-FOPE-CONNECTOR: Id%1294$Dn%GMAIL.COM$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn% X-FOPE-CONNECTOR: Id%1294$Dn%IETF.ORG$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn% X-CFilter-Loop: Reflected X-OriginatorOrg: motorolasolutions.com Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] JWT - scope claim missing X-BeenThere: oauth@ietf.org X-Mailman-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, 11 Mar 2013 14:36:58 -0000 --_000_59E470B10C4630419ED717AC79FCF9A956893F49BY2PRD0411MB441_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I would not even want to confuse audience with scope. Maybe in the simples= t of cases, where there is a one-to-one mapping between scope and audience,= but in reality the RS could expose multiple APIs at the same endpoint. Gr= anted the RS could extract the audience field based on a fully qualified sc= ope, but it just seems that claims, scopes, and audiences are each unique a= nd should be kept that way. adam From: Phil Hunt [mailto:phil.hunt@oracle.com] Sent: Monday, March 11, 2013 9:25 AM To: Nat Sakimura Cc: Lewis Adam-CAL022; oauth@ietf.org WG Subject: Re: [OAUTH-WG] JWT - scope claim missing One thing that concerns me is that scope is very different from a claim. An= claim is an assertion provided that may have some level of dispute/quality= etc. A scope defines what is request or what has been authorized. It's an absol= ute thing. Therefore it is not a claim. Audience...maybe. This is why I think scope deserves special attention/discussion in authoriz= ation assertions and in access tokens. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-03-10, at 9:17 PM, Nat Sakimura wrote: So, it is soooo late in the game: I have been completely underwater to even= read the OAuth mails for about a month and slowly catching up now. Here is an I-D that I have created partly in response to the RS-AS interact= ion piece that was talked about at IETF 85. It does not have 'scope' and has 'claims' instead as it was based on OpenID= Connect, but it is easy to add, provided that the scopes are to be underst= ood as that of the 'aud'. http://tools.ietf.org/id/draft-sakimura-oidc-structured-token-01.txt Best, Nat 2013/3/1 Lewis Adam-CAL022 > Hmmm, I'm not so sure. It depends where we all think OAuth is on its traje= ctory. On one hand, OAuth has already seen an insanely massive amount of d= eployment. On the other hand, RESTful APIs see no sign of slowing down. = Now I'm not going to go so far as Craig B. and say that everything and ever= yone will be API enabled in the future, but it sure is going to be a lot. = That being said, one could argue that even with all the OAuth implementatio= n we've seen, that this is just the infancy of it. Obviously a WG profile = of a JWT-structured AT could not deprecate other forms (unstructured, SAML,= etc.) but going forward new developers may choose to embrace this, and in = fact this could even be the guidance. I agree with previous comments that= Justin's introspection draft might be a good place to explore this. adam From: Brian Campbell [mailto:bcampbell@pingidentity.com] Sent: Thursday, February 28, 2013 1:36 PM To: Lewis Adam-CAL022 Cc: John Bradley; oauth@ietf.org WG Subject: Re: [OAUTH-WG] JWT - scope claim missing I do agree that a WG profile of a JWT-structured access token could lend it= self to interoperability and ultimately be a useful thing. But you are righ= t that there already are many implementations out there in the wild (heck, = I've written one myself) and that might make it difficult to standardize on= something. Because of that, and many other reasons, I don't want to try and add that t= o existing assertion drafts. On Thu, Feb 28, 2013 at 12:13 PM, Lewis Adam-CAL022 > wrote: Hi Brian, a few thoughts from somebody outside of the WG ... As a newcomer to OAuth last year, I was initially confused by the titles. = It was confusing because we have SAML bearer *assertions* and JWT bearer *t= okens* ... and as John just (begrudgingly) stated in this thread, the JWT i= s being used as an assertion in this profile (and in OIDC). I think it wil= l be difficult to find a good name for these profiles since they do two ent= irely different things (e.g. define a new grant type and define a new metho= d of client authentication). One could argue that as long as the WG is at = it, then why not add a third section to the JWT profile, which talks about = usage of JWT-structured bearer access tokens: it would not be any less rela= ted than the other two focuses of the doc. Then the document could be call= ed something simple like "profiles of JWT usage in OAuth" or something like= that. On one hand, it is probably na=EFve to think that an access token can be st= andardized in a profile given how many have already been released into the = wild, but on the other hand, a WG profile of a JWT-structured access token = could lend itself to interoperability, where AS implementations can adverti= se conformance to the profile and who knows ... maybe the RS's of the futur= e will be good with this. adam From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Brian Campbell Sent: Thursday, February 28, 2013 1:03 PM To: John Bradley Cc: oauth@ietf.org WG Subject: Re: [OAUTH-WG] JWT - scope claim missing I'm not sure anyone really "picked" the titles for the bearer token profile= s. They just kind of evolved. And evolved in funny ways especially when cli= ent authn to the AS was added. You won't hear me argue that the titles are "good" and this is not the firs= t time there's been confusion about what they actually do. They define new = grant types and new client authentication methods. They *do not* define an = access token format or anything else about access tokens. JWT and SAML coul= d be used for that but that's not what these drafts do. Suggestions for better title(s) would be more than welcome. Here's what they are now: SAML 2.0 Bearer Assertion Profiles for OAuth 2.0 draft-ietf-oauth-saml2-bearer JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0 draft-ietf-oauth-jwt-bearer Assertion Framework for OAuth 2.0 draft-ietf-oauth-assertions On Thu, Feb 28, 2013 at 11:36 AM, John Bradley > wrote: Yes the title likely adds to the confusion given that the bearer tokens are= not access tokens. Things as separate from OAuth as the Firefox browerID spec use JWS signed J= WTs. The bearer token profiles for OAuth 2 are for OAuth2. The JSON Web Token (JWT) spec did not start in OAuth and is not OAuth specific. A JWT is: JSON Web Token (JWT) A string representing a set of claims as a JSON object that is encoded in a JWS or JWE, enabling the claims to be digitally signed or MACed and/or encrypted. So OAuth or other profiles may define claims to go in a JWT, but the JWT ne= eds to itself only define the claims necessary for security processing. John B. PS that was a soft ball If you hadn't responded I would have been disappoin= ted. I din't pick the title for the bearer token profiles. On 2013-02-28, at 10:12 AM, Phil Hunt > wrote: JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0 Note the title says "for OAuth2" Sorry. Couldn't resist. Phil Sent from my phone. On 2013-02-28, at 9:40, John Bradley > wrote: JWT is an assertion( I am probably going to regret using that word). It is used in openID connect for id_tokens, it is used in OAuth for Asserti= on grant types and authentication of the client to the token endpoint. http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-04 JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0 Dosen't define JWT's use for access tokens for the RS. Bottom line JWT is for more than access tokens. John B. On 2013-02-28, at 9:28 AM, Phil Hunt > wrote: Are you saying jwt is not an access token type? Phil Sent from my phone. On 2013-02-28, at 8:58, John Bradley > wrote: Yes, defining scope in JWT is the wrong place. JWT needs to stick to the = security claims needed to process JWT. I also don't know how far you get requiring a specific authorization format= for JWT, some AS will wan to use a opaque reference, some might want to us= e a user claim or role claim, others may use scopes, combining scopes and = claims is also possible. Right now it is up to a AS RS pair to agree on how to communicate authoriza= tion. I don't want MAC to be more restrictive than bearer when it comes t= o authorization between AS and RS. Hannes wanted to know why JWT didn't define scope. The simple answer is th= at it is out of scope for JWT itself. It might be defined in a OAuth acce= ss token profile for JWT but it should not be specific to MAC. John B. On 2013-02-28, at 8:44 AM, Brian Campbell > wrote: I think John's point was more that scope is something rather specific to an= OAuth access token and, while JWT is can be used to represent an access to= ken, it's not the only application of JWT. The 'standard' claims in JWT are= those that are believed (right or wrong) to be widely applicable across di= fferent applications of JWT. One could argue about it but scope is probably= not one of those. It would probably make sense to try and build a profile of JWT specifically= for OAuth access tokens (though I suspect there are some turtles and drago= ns in there), which might be the appropriate place to define/register a sco= pe claim. On Thu, Feb 28, 2013 at 9:24 AM, Phil Hunt > wrote: Are you advocating TWO systems? That seems like a bad choice. I would rather fix scope than go to a two system approach. Phil Sent from my phone. On 2013-02-28, at 8:17, John Bradley > wrote: > While scope is one method that a AS could communicate authorization to a = RS, it is not the only or perhaps even the most likely one. > Using scope requires a relatively tight binding between the RS and AS, U= MA uses a different mechanism that describes finer grained operations. > The AS may include roles, user, or other more abstract claims that the th= e client may (god help them) pass on to EXCML for processing. > > While having a scopes claim is possible, like any other claim it is not p= art of the JWT core security processing claims, and needs to be defined by = extension. > > John B. > On 2013-02-28, at 2:29 AM, Hannes Tschofenig > wrote: > >> Hi Mike, >> >> when I worked on the MAC specification I noticed that the JWT does not h= ave a claim for the scope. I believe that this would be needed to allow the= resource server to verify whether the scope the authorization server autho= rized is indeed what the client is asking for. >> >> Ciao >> Hannes >> >> _______________________________________________ >> OAuth mailing 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 -- Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_59E470B10C4630419ED717AC79FCF9A956893F49BY2PRD0411MB441_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I would not even want to = confuse audience with scope.  Maybe in the simplest of cases, where th= ere is a one-to-one mapping between scope and audience, but in reality the RS could expose multiple APIs at the same endpoint.  Gran= ted the RS could extract the audience field based on a fully qualified scop= e, but it just seems that claims, scopes, and audiences are each unique and= should be kept that way.

 <= /p>

adam

 <= /p>

From: Phil Hun= t [mailto:phil.hunt@oracle.com]
Sent: Monday, March 11, 2013 9:25 AM
To: Nat Sakimura
Cc: Lewis Adam-CAL022; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] JWT - scope claim missing<= /p>

 

One thing that concerns me is that scope is very dif= ferent from a claim. An claim is an assertion provided that may have some l= evel of dispute/quality etc.

 

A scope defines what is request or what has been aut= horized.  It's an absolute thing. Therefore it is not a claim. Audienc= e...maybe. 

 

This is why I think scope deserves special attention= /discussion in authorization assertions and in access tokens.

 

Phil

 

@independentid<= /span>

phil.hunt@oracle.com=

 <= /p>



 

On 2013-03-10, at 9:17 PM, Nat Sakimura wrote:<= /o:p>



So, it is soooo late in the game: I have been comple= tely underwater to even read the OAuth mails for about a month and slowly c= atching up now. 

 

Here is an I-D that I have created partly in respons= e to the RS-AS interaction piece that was talked about at IETF 85. 

It does not have 'scope' and has 'claims' instead as= it was based on OpenID Connect, but it is easy to add, provided that the s= copes are to be understood as that of the 'aud'. 

 

 

Best, 

 

Nat

 

2013/3/1 Lewis Adam-CAL022 <Adam.Lewis@motorolasolutio= ns.com>

Hmmm, I’m not so sure.  It dep= ends where we all think OAuth is on its trajectory.  On one hand, OAut= h has already seen an insanely massive amount of deployment.  On the ot= her hand, RESTful APIs see no sign of slowing down.   Now I’= ;m not going to go so far as Craig B. and say that everything and everyone = will be API enabled in the future, but it sure is going to be a lot.  That being said, one could argue that even with all the= OAuth implementation we’ve seen, that this is just the infancy of it= .  Obviously a WG profile of a JWT-structured AT could not deprecate o= ther forms (unstructured, SAML, etc.) but going forward new developers may choose to embrace this, and in fact this could = even be the guidance.   I agree with previous comments that Justi= n’s introspection draft might be a good place to explore this.=

 

adam

 

From: Brian Campbell [mailto= :bcampbell@= pingidentity.com]
Sent: Thursday, February 28, 2013 1:36 PM
To: Lewis Adam-CAL022
Cc: John Bradley; oauth@ietf.org WG


Subject: Re: [OAUTH-WG] JWT - scope claim missing

 

 

I do agree that a WG profile of a JWT-structured access token could lend= itself to interoperability and ultimately be a useful thing. But you are r= ight that there already are many implementations out there in the wild (heck, I've written one myself) and that might make = it difficult to standardize on something.

Because of that, and many other reasons, I don't want to try and a= dd that to existing assertion drafts.

 

On Thu, Feb 28, 2013 at 12:13 PM, Lewis Adam-CAL022 <Adam.Lewis@moto= rolasolutions.com> wrote:

Hi Brian, a few thoughts from somebody ou= tside of the WG …

 

As a newcomer to OAuth last year, I was i= nitially confused by the titles.  It was confusing because we have SAML bearer *assertions* and JWT bearer *tokens* = 230; and as John just (begrudgingly) stated in this thread, the JWT is bein= g used as an assertion in this profile (and in OIDC).  I think it will= be difficult to find a good name for these profiles since they do two entirely different things (e.g. define a new gr= ant type and define a new method of client authentication).  One could= argue that as long as the WG is at it, then why not add a third section to= the JWT profile, which talks about usage of JWT-structured bearer access tokens: it would not be any less related t= han the other two focuses of the doc.  Then the document could be call= ed something simple like “profiles of JWT usage in OAuth” or so= mething like that. 

 

On one hand, it is probably na=EFve to th= ink that an access token can be standardized in a profile given how many have already been released into the wild, but on the other hand, = a WG profile of a JWT-structured access token could lend itself to interope= rability, where AS implementations can advertise conformance to the profile= and who knows … maybe the RS’s of the future will be good with this. 

 

adam

 

From: oauth-bounces@i= etf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Brian Campbell
Sent: Thursday, February 28, 2013 1:03 PM
To: John Bradley
Cc: oauth@ietf.o= rg WG


Subject: Re: [OAUTH-WG] JWT - scope claim missing

 

I'm not sure anyone really "picked" the titles for the bearer = token profiles. They just kind of evolved. And evolved in funny ways especi= ally when client authn to the AS was added.

You won't hear me argue that the titles are "good" and this is= not the first time there's been confusion about what they actually do. The= y define new grant types and new client authentication methods. They *do not* define an access token format or anything else abou= t access tokens. JWT and SAML could be used for that but that's not what th= ese drafts do.

Suggestions for better title(s) would be more than welcome.

 

Here's what they are now:


SAML 2.0 Bearer Assertion Profiles for OAuth 2.0
draft-ietf-oauth-saml2-bearer

JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0
draft-ietf-oauth-jwt-bearer

Assertion Framework for OAuth 2.0
draft-ietf-oauth-assertions

 

On Thu, Feb 28, 2013 at 11:36 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:

Yes the title likely adds to the confusion given that the bearer t= okens are not access tokens.

 

Things as separate from OAuth as the Firefox browerID spec use JWS= signed JWTs.  

 

The bearer token profiles for OAuth 2 are for OAuth2.

 

The JSON Web Token (JWT) spec did n= ot start in OAuth and is not OAuth specific.

 

A JWT is:

JSON Web Token (JWT)  A string r=
epresenting a set of claims as a JSON
      object=
 that is encoded in a JWS or JWE, enabling the claims to be
      digita=
lly signed or MACed and/or encrypted.

 

So OAuth or other profiles may define claims to go in a JWT, but t= he JWT needs to itself only define the claims necessary for security proces= sing.  

 

John B.

PS that was a soft ball If you hadn't responded I would have been = disappointed.  I din't pick the title for the bearer token profiles.

 

 

On 2013-02-28, at 10:12 AM, Phil Hunt <phil.hunt@oracle.com> wrote:<= /o:p>

 

JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0


Note the title says "for OAuth2"

 

Sorry. Couldn't resist. 

 

Phil

 

Sent from my phone.


On 2013-02-28, at 9:40, John Bradley <ve7jtb@ve7jtb.com> wrote:

JWT is an assertion( I am probably going to regret using that word= ).

 

It is used in openID connect for id_tokens, it is used in OAuth fo= r Assertion grant types and authentication of the client to the token endpo= int.

 

 
 

JS= ON Web Token (JWT) Bearer Token Profiles for OAuth 2.0

 

Dosen't define JWT's use for access tokens for the RS.   = ;

 

Bottom line JWT is for more than access tokens.

 

John B.

 

On 2013-02-28, at 9:28 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

 

Are you saying jwt is not an access token type?

Phil

 

Sent from my phone.


On 2013-02-28, at 8:58, John Bradley <ve7jtb@ve7jtb.com> wrote:

Yes, defining scope in JWT is the wrong place.   JWT needs to= stick to the security claims needed to process JWT.

 

I also don't know how far you get requiring a specific authorizati= on format for JWT, some AS will wan to use a opaque reference, some might w= ant to use a user claim or role claim, others may use scopes,  combining scopes and claims is also possible.=

 

Right now it is up to a AS RS pair to agree on how to communicate = authorization.   I don't want MAC to be more restrictive than bearer w= hen it comes to authorization between AS and RS.

 

Hannes wanted to know why JWT didn't define scope.  The simpl= e answer is that it is out of scope for JWT itself.   It might be defi= ned in a OAuth access token profile for JWT but it should not be specific to MAC.

 

John B.

On 2013-02-28, at 8:44 AM, Brian Campbell <bcampbell@pingidentity.com&= gt; wrote:

 

I think John's point was more that scope is something rather specific to= an OAuth access token and, while JWT is can be used to represent an access= token, it's not the only application of JWT. The 'standard' claims in JWT are those that are believed (right or= wrong) to be widely applicable across different applications of JWT. One c= ould argue about it but scope is probably not one of those.

It would probably make sense to try and build a profile of JWT spe= cifically for OAuth access tokens (though I suspect there are some turtles = and dragons in there), which might be the appropriate place to define/register a scope claim.

 

On Thu, Feb 28, 2013 at 9:24 AM, Phil Hunt <phil.hunt@oracle.com> wrote:<= o:p>

Are you advocating TWO systems? That seems like a bad choice.

I would rather fix scope than go to a two system approach.

Phil

Sent from my phone.

On 2013-02-28, at 8:17, John Bradley <ve7jtb@ve7jtb.com> wrote:

> While scope is one method that a AS could communicate authorization to= a RS, it is not the only or perhaps even the most likely one.
> Using scope requires a relatively tight binding between the RS and AS,=  UMA uses a different mechanism that describes finer grained operatio= ns.
> The AS may include roles, user, or other more abstract claims that the= the client may (god help them) pass on to EXCML for processing.
>
> While having a scopes claim is possible, like any other claim it is no= t part of the JWT core security processing claims, and needs to be defined = by extension.
>
> John B.
> On 2013-02-28, at 2:29 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net>= wrote:
>
>> Hi Mike,
>>
>> when I worked on the MAC specification I noticed that the JWT does= not have a claim for the scope. I believe that this would be needed to all= ow the resource server to verify whether the scope the authorization server= authorized is indeed what the client is asking for.
>>
>> Ciao
>> Hannes
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org=
>> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

 

 

 

 

 

 


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



 

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.= org/
@_nat_en

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

 

--_000_59E470B10C4630419ED717AC79FCF9A956893F49BY2PRD0411MB441_-- From phil.hunt@oracle.com Mon Mar 11 07:47:24 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 9530321F8B0E for ; Mon, 11 Mar 2013 07:47:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.597 X-Spam-Level: X-Spam-Status: No, score=-6.597 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 Nrcu8rmVf5Ik for ; Mon, 11 Mar 2013 07:47:22 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 2172021F8B07 for ; Mon, 11 Mar 2013 07:47:22 -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 r2BElJnp025204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 11 Mar 2013 14:47:20 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r2BElIRu023545 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Mar 2013 14:47:19 GMT Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r2BElIJC009391; Mon, 11 Mar 2013 09:47:18 -0500 Received: from dhcp-16e2.meeting.ietf.org (/130.129.22.226) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 11 Mar 2013 07:47:18 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_ACD1671D-D824-4693-9FF8-B1452426FFC3" From: Phil Hunt In-Reply-To: <59E470B10C4630419ED717AC79FCF9A956893F49@BY2PRD0411MB441.namprd04.prod.outlook.com> Date: Mon, 11 Mar 2013 10:47:17 -0400 Message-Id: <3C571C43-C53A-4385-8ADF-FB2A7E788B29@oracle.com> References: <0EC2404F-E3C5-4AD1-88B4-E74AA0394DD9@gmx.net> <48FD87D1-4DF4-4289-99B7-40A515F31890@oracle.com> <3E472720-31A4-40A0-AAA4-402CF850831A@ve7jtb.com> <7127843B-D7B0-4AB6-87F1-1604D1EFFA79@oracle.com> <50DA292F-32F0-4266-8401-006AD837B775@ve7jtb.com> <59E470B10C4630419ED717AC79FCF9A948D58BEE@BY2PRD0411MB441.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A948D58DC0@BY2PRD0411MB441.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A956893F49@BY2PRD0411MB441.namprd04.prod.outlook.com> To: Lewis Adam-CAL022 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] JWT - scope claim missing X-BeenThere: oauth@ietf.org X-Mailman-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, 11 Mar 2013 14:47:24 -0000 --Apple-Mail=_ACD1671D-D824-4693-9FF8-B1452426FFC3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I agree. Many have been suggesting audience. But my gut feeling matches = yours. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-03-11, at 10:36 AM, Lewis Adam-CAL022 wrote: > I would not even want to confuse audience with scope. Maybe in the = simplest of cases, where there is a one-to-one mapping between scope and = audience, but in reality the RS could expose multiple APIs at the same = endpoint. Granted the RS could extract the audience field based on a = fully qualified scope, but it just seems that claims, scopes, and = audiences are each unique and should be kept that way. > =20 > adam > =20 > From: Phil Hunt [mailto:phil.hunt@oracle.com]=20 > Sent: Monday, March 11, 2013 9:25 AM > To: Nat Sakimura > Cc: Lewis Adam-CAL022; oauth@ietf.org WG > Subject: Re: [OAUTH-WG] JWT - scope claim missing > =20 > One thing that concerns me is that scope is very different from a = claim. An claim is an assertion provided that may have some level of = dispute/quality etc. > =20 > A scope defines what is request or what has been authorized. It's an = absolute thing. Therefore it is not a claim. Audience...maybe.=20 > =20 > This is why I think scope deserves special attention/discussion in = authorization assertions and in access tokens. > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 > =20 >=20 >=20 > =20 > On 2013-03-10, at 9:17 PM, Nat Sakimura wrote: >=20 >=20 > So, it is soooo late in the game: I have been completely underwater to = even read the OAuth mails for about a month and slowly catching up now.=20= > =20 > Here is an I-D that I have created partly in response to the RS-AS = interaction piece that was talked about at IETF 85.=20 > It does not have 'scope' and has 'claims' instead as it was based on = OpenID Connect, but it is easy to add, provided that the scopes are to = be understood as that of the 'aud'.=20 > =20 > http://tools.ietf.org/id/draft-sakimura-oidc-structured-token-01.txt > =20 > Best,=20 > =20 > Nat > =20 > 2013/3/1 Lewis Adam-CAL022 > Hmmm, I=92m not so sure. It depends where we all think OAuth is on = its trajectory. On one hand, OAuth has already seen an insanely massive = amount of deployment. On the other hand, RESTful APIs see no sign of = slowing down. Now I=92m not going to go so far as Craig B. and say = that everything and everyone will be API enabled in the future, but it = sure is going to be a lot. That being said, one could argue that even = with all the OAuth implementation we=92ve seen, that this is just the = infancy of it. Obviously a WG profile of a JWT-structured AT could not = deprecate other forms (unstructured, SAML, etc.) but going forward new = developers may choose to embrace this, and in fact this could even be = the guidance. I agree with previous comments that Justin=92s = introspection draft might be a good place to explore this. > =20 > adam > =20 > From: Brian Campbell [mailto:bcampbell@pingidentity.com]=20 > Sent: Thursday, February 28, 2013 1:36 PM > To: Lewis Adam-CAL022 > Cc: John Bradley; oauth@ietf.org WG >=20 > Subject: Re: [OAUTH-WG] JWT - scope claim missing > =20 > =20 > I do agree that a WG profile of a JWT-structured access token could = lend itself to interoperability and ultimately be a useful thing. But = you are right that there already are many implementations out there in = the wild (heck, I've written one myself) and that might make it = difficult to standardize on something. >=20 > Because of that, and many other reasons, I don't want to try and add = that to existing assertion drafts. > =20 >=20 > On Thu, Feb 28, 2013 at 12:13 PM, Lewis Adam-CAL022 = wrote: > Hi Brian, a few thoughts from somebody outside of the WG =85 > =20 > As a newcomer to OAuth last year, I was initially confused by the = titles. It was confusing because we have SAML bearer *assertions* and = JWT bearer *tokens* =85 and as John just (begrudgingly) stated in this = thread, the JWT is being used as an assertion in this profile (and in = OIDC). I think it will be difficult to find a good name for these = profiles since they do two entirely different things (e.g. define a new = grant type and define a new method of client authentication). One could = argue that as long as the WG is at it, then why not add a third section = to the JWT profile, which talks about usage of JWT-structured bearer = access tokens: it would not be any less related than the other two = focuses of the doc. Then the document could be called something simple = like =93profiles of JWT usage in OAuth=94 or something like that.=20 > =20 > On one hand, it is probably na=EFve to think that an access token can = be standardized in a profile given how many have already been released = into the wild, but on the other hand, a WG profile of a JWT-structured = access token could lend itself to interoperability, where AS = implementations can advertise conformance to the profile and who knows =85= maybe the RS=92s of the future will be good with this.=20 > =20 > adam > =20 > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf = Of Brian Campbell > Sent: Thursday, February 28, 2013 1:03 PM > To: John Bradley > Cc: oauth@ietf.org WG >=20 > Subject: Re: [OAUTH-WG] JWT - scope claim missing > =20 > I'm not sure anyone really "picked" the titles for the bearer token = profiles. They just kind of evolved. And evolved in funny ways = especially when client authn to the AS was added. >=20 > You won't hear me argue that the titles are "good" and this is not the = first time there's been confusion about what they actually do. They = define new grant types and new client authentication methods. They *do = not* define an access token format or anything else about access tokens. = JWT and SAML could be used for that but that's not what these drafts do. >=20 > Suggestions for better title(s) would be more than welcome. > =20 > Here's what they are now: >=20 > SAML 2.0 Bearer Assertion Profiles for OAuth 2.0 > draft-ietf-oauth-saml2-bearer >=20 > JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0 > draft-ietf-oauth-jwt-bearer >=20 > Assertion Framework for OAuth 2.0 > draft-ietf-oauth-assertions > =20 > On Thu, Feb 28, 2013 at 11:36 AM, John Bradley = wrote: > Yes the title likely adds to the confusion given that the bearer = tokens are not access tokens. > =20 > Things as separate from OAuth as the Firefox browerID spec use JWS = signed JWTs. =20 > =20 > The bearer token profiles for OAuth 2 are for OAuth2. > =20 > The JSON Web Token (JWT) spec did not start in OAuth and is not OAuth = specific. > =20 > A JWT is: > JSON Web Token (JWT) A string representing a set of claims as a JSON > object that is encoded in a JWS or JWE, enabling the claims to = be > digitally signed or MACed and/or encrypted. > =20 > So OAuth or other profiles may define claims to go in a JWT, but the = JWT needs to itself only define the claims necessary for security = processing. =20 > =20 > John B. > PS that was a soft ball If you hadn't responded I would have been = disappointed. I din't pick the title for the bearer token profiles. > =20 > =20 > On 2013-02-28, at 10:12 AM, Phil Hunt wrote: > =20 >=20 > JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0 >=20 >=20 > Note the title says "for OAuth2" > =20 > Sorry. Couldn't resist.=20 > =20 > Phil > =20 > Sent from my phone. >=20 > On 2013-02-28, at 9:40, John Bradley wrote: >=20 > JWT is an assertion( I am probably going to regret using that word). > =20 > It is used in openID connect for id_tokens, it is used in OAuth for = Assertion grant types and authentication of the client to the token = endpoint. > http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-04 > =20 > =20 > =20 > JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0 >=20 > =20 > Dosen't define JWT's use for access tokens for the RS. =20 > =20 > Bottom line JWT is for more than access tokens. > =20 > John B. > =20 > On 2013-02-28, at 9:28 AM, Phil Hunt wrote: > =20 >=20 > Are you saying jwt is not an access token type? >=20 > Phil > =20 > Sent from my phone. >=20 > On 2013-02-28, at 8:58, John Bradley wrote: >=20 > Yes, defining scope in JWT is the wrong place. JWT needs to stick to = the security claims needed to process JWT. > =20 > I also don't know how far you get requiring a specific authorization = format for JWT, some AS will wan to use a opaque reference, some might = want to use a user claim or role claim, others may use scopes, = combining scopes and claims is also possible. > =20 > Right now it is up to a AS RS pair to agree on how to communicate = authorization. I don't want MAC to be more restrictive than bearer = when it comes to authorization between AS and RS. > =20 > Hannes wanted to know why JWT didn't define scope. The simple answer = is that it is out of scope for JWT itself. It might be defined in a = OAuth access token profile for JWT but it should not be specific to MAC. > =20 > John B. > On 2013-02-28, at 8:44 AM, Brian Campbell = wrote: > =20 >=20 > I think John's point was more that scope is something rather specific = to an OAuth access token and, while JWT is can be used to represent an = access token, it's not the only application of JWT. The 'standard' = claims in JWT are those that are believed (right or wrong) to be widely = applicable across different applications of JWT. One could argue about = it but scope is probably not one of those. >=20 > It would probably make sense to try and build a profile of JWT = specifically for OAuth access tokens (though I suspect there are some = turtles and dragons in there), which might be the appropriate place to = define/register a scope claim. > =20 >=20 > On Thu, Feb 28, 2013 at 9:24 AM, Phil Hunt = wrote: > Are you advocating TWO systems? That seems like a bad choice. >=20 > I would rather fix scope than go to a two system approach. >=20 > Phil >=20 > Sent from my phone. >=20 > On 2013-02-28, at 8:17, John Bradley wrote: >=20 > > While scope is one method that a AS could communicate authorization = to a RS, it is not the only or perhaps even the most likely one. > > Using scope requires a relatively tight binding between the RS and = AS, UMA uses a different mechanism that describes finer grained = operations. > > The AS may include roles, user, or other more abstract claims that = the the client may (god help them) pass on to EXCML for processing. > > > > While having a scopes claim is possible, like any other claim it is = not part of the JWT core security processing claims, and needs to be = defined by extension. > > > > John B. > > On 2013-02-28, at 2:29 AM, Hannes Tschofenig = wrote: > > > >> Hi Mike, > >> > >> when I worked on the MAC specification I noticed that the JWT does = not have a claim for the scope. I believe that this would be needed to = allow the resource server to verify whether the scope the authorization = server authorized is indeed what the client is asking for. > >> > >> Ciao > >> Hannes > >> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > =20 > =20 > =20 > =20 > =20 > =20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 > =20 > --=20 > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_ACD1671D-D824-4693-9FF8-B1452426FFC3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I = agree. Many have been suggesting audience. But my gut feeling matches = yours.

Phil

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





On 2013-03-11, at 10:36 AM, Lewis Adam-CAL022 = wrote:

I would not even want to = confuse audience with scope.  Maybe in the simplest of cases, where = there is a one-to-one mapping between scope and audience, but in reality = the RS could expose multiple APIs at the same endpoint.  Granted = the RS could extract the audience field based on a fully qualified = scope, but it just seems that claims, scopes, and audiences are each = unique and should be kept that way.
From: Phil Hunt = [mailto:phil.hunt@oracle.com] 
Sent: Monday, March 11, 2013 9:25 = AM
To: Nat = Sakimura
Cc: Lewis Adam-CAL022; oauth@ietf.org = WG
Subject: Re: [OAUTH-WG] JWT - scope = claim missing
One thing that concerns me is = that scope is very different from a claim. An claim is an assertion = provided that may have some level of dispute/quality = etc.
A scope defines what is = request or what has been authorized.  It's an absolute thing. = Therefore it is not a claim. = Audience...maybe. 
 
This is why I think scope deserves special = attention/discussion in authorization assertions and in access = tokens.
Phil
@independentid
2013/3/1 Lewis = Adam-CAL022 <Hmmm, I=92m not so sure.  It = depends where we all think OAuth is on its trajectory.  On one = hand, OAuth has already seen an insanely massive amount of = deployment.  On the other hand, RESTful APIs see no sign of slowing = down.   Now I=92m not going to go so far as Craig B. and say = that everything and everyone will be API enabled in the future, but it = sure is going to be a lot.  That being said, one could argue that = even with all the OAuth implementation we=92ve seen, that this is just = the infancy of it.  Obviously a WG profile of a JWT-structured AT = could not deprecate other forms (unstructured, SAML, etc.) but = going  forward new = developers may choose to embrace this, and in fact this could even be = the guidance.   I agree with previous comments that Justin=92s = introspection draft might be a good place to explore = this.
I do agree that a WG profile of a JWT-structured access token = could lend itself to interoperability and ultimately be a useful thing. = But you are right that there already are many implementations out there = in the wild (heck, I've written one myself) and that might make it = difficult to standardize on something.

Because of that, and many other reasons, I don't want = to try and add that to existing assertion = drafts.

On Thu, Feb 28, 2013 at 12:13 = PM, Lewis Adam-CAL022 <Hi Brian, a = few thoughts from somebody outside of the WG = =85

As a = newcomer to OAuth last year, I was initially confused by the = titles.  It was confusing because we have SAML bearer = *assertions* and JWT bearer *tokens* =85 and as John just = (begrudgingly) stated in this thread, the JWT is being used as an = assertion in this profile (and in OIDC).  I think it will be = difficult to find a good name for these profiles since they do two = entirely different things (e.g. define a new grant type and define a new = method of client authentication).  One could argue that as long as = the WG is at it, then why not add a third section to the JWT profile, = which talks about usage of JWT-structured bearer access tokens: it would = not be any less related than the other two focuses of the doc.  = Then the document could be called something simple like =93profiles of = JWT usage in OAuth=94 or something like = that. 
 oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Brian = Campbell
Sent: Thursday, February 28, 2013 = 1:03 PM
To: John = Bradley
Cc: oauth@ietf.org WG

Subject: Re: [OAUTH-WG] JWT - scope = claim missing
I'm not sure anyone really "picked" the titles for the bearer = token profiles. They just kind of evolved. And evolved in funny ways = especially when client authn to the AS was = added.

You won't hear me argue that the titles are "good" and this is = not the first time there's been confusion about what they actually do. = They define new grant types and new client authentication methods. They = *do not* define an access token format or anything else about access = tokens. JWT and SAML could be used for that but that's not what these = drafts do.

Suggestions for better = title(s) would be more than = welcome.
Here's what they are = now:

SAML 2.0 Bearer = Assertion Profiles for OAuth = 2.0
draft-ietf-oauth-saml2-bearer

JSON Web Token (JWT) Bearer = Token Profiles for OAuth = 2.0
draft-ietf-oauth-jwt-bearer

Assertion Framework for OAuth = 2.0
draft-ietf-oauth-assertions
 
On Thu, Feb = 28, 2013 at 11:36 AM, John Bradley <ve7jtb@ve7jtb.com> = wrote:
Yes the title likely adds to = the confusion given that the bearer tokens are not access = tokens.
Things as separate from = OAuth as the Firefox browerID spec use JWS signed JWTs. =  
The bearer token profiles = for OAuth 2 are for OAuth2.
 
      digitally signed or MACed and/or =
encrypted.
On 2013-02-28, at 10:12 = AM, Phil Hunt < 

JSON Web Token (JWT) Bearer Token Profiles for = OAuth 2.0


Note the title says = "for OAuth2"
Sorry. Couldn't = resist. 
Sent from my = phone.
JWT is an assertion( I am probably going to = regret using that word).
It is used in openID = connect for id_tokens, it is used in OAuth for Assertion grant types and = authentication of the client to the token = endpoint.


On 2013-02-28, at 8:58, John Bradley = <ve7jtb@ve7jtb.com> = wrote:

Yes, defining scope in JWT is the wrong = place.   JWT needs to stick to the security claims needed to = process JWT.
I also don't know how far = you get requiring a specific authorization format for JWT, some AS will = wan to use a opaque reference, some might want to use a user claim or = role claim, others may use scopes,  combining scopes and claims is = also possible.
Right now it is up to a = AS RS pair to agree on how to communicate authorization.   I don't = want MAC to be more restrictive than bearer when it comes to = authorization between AS  and = RS.
Hannes wanted to know why = JWT didn't define scope.  The simple answer is that it is out of = scope for JWT itself.   It might be defined in a OAuth access token = profile for JWT but it should not be specific to = MAC.
John = B.
On 2013-02-28, at 8:44 = AM, Brian Campbell < 

I think John's point was more that scope is = something rather specific to an OAuth access token and, while JWT is can = be used to represent an access token, it's not the only application of = JWT. The 'standard' claims in JWT are those that are believed (right or = wrong) to be widely applicable across different applications of JWT. One = could argue about it but scope is probably not one of = those.

It would probably make sense to = try and build a profile of JWT specifically for OAuth access tokens = (though I suspect there are some turtles and dragons in there), which = might be the appropriate place to define/register a scope = claim.

In-Reply-To: <3C571C43-C53A-4385-8ADF-FB2A7E788B29@oracle.com> Date: Mon, 11 Mar 2013 10:08:31 -0500 Message-Id: References: <0EC2404F-E3C5-4AD1-88B4-E74AA0394DD9@gmx.net> <48FD87D1-4DF4-4289-99B7-40A515F31890@oracle.com> <3E472720-31A4-40A0-AAA4-402CF850831A@ve7jtb.com> <7127843B-D7B0-4AB6-87F1-1604D1EFFA79@oracle.com> <50DA292F-32F0-4266-8401-006AD837B775@ve7jtb.com> <59E470B10C4630419ED717AC79FCF9A948D58BEE@BY2PRD0411MB441.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A948D58DC0@BY2PRD0411MB441.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A956893F49@BY2PRD0411MB441.namprd04.prod.outlook.com> <3C571C43-C53A-4385-8ADF-FB2A7E788B29@oracle.com> To: Phil Hunt X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQnUlFjY4CMYg4sSxi5vvo3KX1CBy9GuP8KsgShKgetJlUpI1ksGx5Fy4uSiA8oiCnvy6cdm Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] JWT - scope claim missing X-BeenThere: oauth@ietf.org X-Mailman-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, 11 Mar 2013 15:08:47 -0000 --Apple-Mail=_A060059C-B640-4D42-930A-B0DC8FBE3CD5 Content-Type: multipart/alternative; boundary="Apple-Mail=_4ABBEB76-638D-477F-9C45-50B9F28C6EBE" --Apple-Mail=_4ABBEB76-638D-477F-9C45-50B9F28C6EBE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Some thing that scopes are a stupidly vague bucket of stuff inferring = something about a permission for an action against a resource. If people want to send the scopes that were sent from the the client to = the authorization server to the RS that is fine. Scopes are intended for Client to AS communication and the scopes = granted are returned outside the token and a client should never be = snooping into the access token. I would object to requiring that Scopes be the only or even preferred = mechanism for communicating authorization for resources to the RS. Audience principal and other members of the JWT provide much richer = opportunities to communicate permissions to the RS. Al top level members of the JWT are called claims so if you add a scopes = claim with a string containing the space separated scope strings if you = like but it is a claim like the others. JWT is extensible and you can add that, It doesn't need to be in the = core set of JWT claims. Other than that I have no opinion:) John B. On 2013-03-11, at 9:47 AM, Phil Hunt wrote: > I agree. Many have been suggesting audience. But my gut feeling = matches yours. >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >=20 >=20 > On 2013-03-11, at 10:36 AM, Lewis Adam-CAL022 wrote: >=20 >> I would not even want to confuse audience with scope. Maybe in the = simplest of cases, where there is a one-to-one mapping between scope and = audience, but in reality the RS could expose multiple APIs at the same = endpoint. Granted the RS could extract the audience field based on a = fully qualified scope, but it just seems that claims, scopes, and = audiences are each unique and should be kept that way. >> =20 >> adam >> =20 >> From: Phil Hunt [mailto:phil.hunt@oracle.com]=20 >> Sent: Monday, March 11, 2013 9:25 AM >> To: Nat Sakimura >> Cc: Lewis Adam-CAL022; oauth@ietf.org WG >> Subject: Re: [OAUTH-WG] JWT - scope claim missing >> =20 >> One thing that concerns me is that scope is very different from a = claim. An claim is an assertion provided that may have some level of = dispute/quality etc. >> =20 >> A scope defines what is request or what has been authorized. It's an = absolute thing. Therefore it is not a claim. Audience...maybe.=20 >> =20 >> This is why I think scope deserves special attention/discussion in = authorization assertions and in access tokens. >> =20 >> Phil >> =20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >> =20 >>=20 >>=20 >> =20 >> On 2013-03-10, at 9:17 PM, Nat Sakimura wrote: >>=20 >>=20 >> So, it is soooo late in the game: I have been completely underwater = to even read the OAuth mails for about a month and slowly catching up = now.=20 >> =20 >> Here is an I-D that I have created partly in response to the RS-AS = interaction piece that was talked about at IETF 85.=20 >> It does not have 'scope' and has 'claims' instead as it was based on = OpenID Connect, but it is easy to add, provided that the scopes are to = be understood as that of the 'aud'.=20 >> =20 >> http://tools.ietf.org/id/draft-sakimura-oidc-structured-token-01.txt >> =20 >> Best,=20 >> =20 >> Nat >> =20 >> 2013/3/1 Lewis Adam-CAL022 >> Hmmm, I=92m not so sure. It depends where we all think OAuth is on = its trajectory. On one hand, OAuth has already seen an insanely massive = amount of deployment. On the other hand, RESTful APIs see no sign of = slowing down. Now I=92m not going to go so far as Craig B. and say = that everything and everyone will be API enabled in the future, but it = sure is going to be a lot. That being said, one could argue that even = with all the OAuth implementation we=92ve seen, that this is just the = infancy of it. Obviously a WG profile of a JWT-structured AT could not = deprecate other forms (unstructured, SAML, etc.) but going forward new = developers may choose to embrace this, and in fact this could even be = the guidance. I agree with previous comments that Justin=92s = introspection draft might be a good place to explore this. >> =20 >> adam >> =20 >> From: Brian Campbell [mailto:bcampbell@pingidentity.com]=20 >> Sent: Thursday, February 28, 2013 1:36 PM >> To: Lewis Adam-CAL022 >> Cc: John Bradley; oauth@ietf.org WG >>=20 >> Subject: Re: [OAUTH-WG] JWT - scope claim missing >> =20 >> =20 >> I do agree that a WG profile of a JWT-structured access token could = lend itself to interoperability and ultimately be a useful thing. But = you are right that there already are many implementations out there in = the wild (heck, I've written one myself) and that might make it = difficult to standardize on something. >>=20 >> Because of that, and many other reasons, I don't want to try and add = that to existing assertion drafts. >> =20 >>=20 >> On Thu, Feb 28, 2013 at 12:13 PM, Lewis Adam-CAL022 = wrote: >> Hi Brian, a few thoughts from somebody outside of the WG =85 >> =20 >> As a newcomer to OAuth last year, I was initially confused by the = titles. It was confusing because we have SAML bearer *assertions* and = JWT bearer *tokens* =85 and as John just (begrudgingly) stated in this = thread, the JWT is being used as an assertion in this profile (and in = OIDC). I think it will be difficult to find a good name for these = profiles since they do two entirely different things (e.g. define a new = grant type and define a new method of client authentication). One could = argue that as long as the WG is at it, then why not add a third section = to the JWT profile, which talks about usage of JWT-structured bearer = access tokens: it would not be any less related than the other two = focuses of the doc. Then the document could be called something simple = like =93profiles of JWT usage in OAuth=94 or something like that.=20 >> =20 >> On one hand, it is probably na=EFve to think that an access token can = be standardized in a profile given how many have already been released = into the wild, but on the other hand, a WG profile of a JWT-structured = access token could lend itself to interoperability, where AS = implementations can advertise conformance to the profile and who knows =85= maybe the RS=92s of the future will be good with this.=20 >> =20 >> adam >> =20 >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf Of Brian Campbell >> Sent: Thursday, February 28, 2013 1:03 PM >> To: John Bradley >> Cc: oauth@ietf.org WG >>=20 >> Subject: Re: [OAUTH-WG] JWT - scope claim missing >> =20 >> I'm not sure anyone really "picked" the titles for the bearer token = profiles. They just kind of evolved. And evolved in funny ways = especially when client authn to the AS was added. >>=20 >> You won't hear me argue that the titles are "good" and this is not = the first time there's been confusion about what they actually do. They = define new grant types and new client authentication methods. They *do = not* define an access token format or anything else about access tokens. = JWT and SAML could be used for that but that's not what these drafts do. >>=20 >> Suggestions for better title(s) would be more than welcome. >> =20 >> Here's what they are now: >>=20 >> SAML 2.0 Bearer Assertion Profiles for OAuth 2.0 >> draft-ietf-oauth-saml2-bearer >>=20 >> JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0 >> draft-ietf-oauth-jwt-bearer >>=20 >> Assertion Framework for OAuth 2.0 >> draft-ietf-oauth-assertions >> =20 >> On Thu, Feb 28, 2013 at 11:36 AM, John Bradley = wrote: >> Yes the title likely adds to the confusion given that the bearer = tokens are not access tokens. >> =20 >> Things as separate from OAuth as the Firefox browerID spec use JWS = signed JWTs. =20 >> =20 >> The bearer token profiles for OAuth 2 are for OAuth2. >> =20 >> The JSON Web Token (JWT) spec did not start in OAuth and is not OAuth = specific. >> =20 >> A JWT is: >> JSON Web Token (JWT) A string representing a set of claims as a JSON >> object that is encoded in a JWS or JWE, enabling the claims to = be >> digitally signed or MACed and/or encrypted. >> =20 >> So OAuth or other profiles may define claims to go in a JWT, but the = JWT needs to itself only define the claims necessary for security = processing. =20 >> =20 >> John B. >> PS that was a soft ball If you hadn't responded I would have been = disappointed. I din't pick the title for the bearer token profiles. >> =20 >> =20 >> On 2013-02-28, at 10:12 AM, Phil Hunt wrote: >> =20 >>=20 >> JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0 >>=20 >>=20 >> Note the title says "for OAuth2" >> =20 >> Sorry. Couldn't resist.=20 >> =20 >> Phil >> =20 >> Sent from my phone. >>=20 >> On 2013-02-28, at 9:40, John Bradley wrote: >>=20 >> JWT is an assertion( I am probably going to regret using that word). >> =20 >> It is used in openID connect for id_tokens, it is used in OAuth for = Assertion grant types and authentication of the client to the token = endpoint. >> http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-04 >> =20 >> =20 >> =20 >> JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0 >>=20 >> =20 >> Dosen't define JWT's use for access tokens for the RS. =20 >> =20 >> Bottom line JWT is for more than access tokens. >> =20 >> John B. >> =20 >> On 2013-02-28, at 9:28 AM, Phil Hunt wrote: >> =20 >>=20 >> Are you saying jwt is not an access token type? >>=20 >> Phil >> =20 >> Sent from my phone. >>=20 >> On 2013-02-28, at 8:58, John Bradley wrote: >>=20 >> Yes, defining scope in JWT is the wrong place. JWT needs to stick = to the security claims needed to process JWT. >> =20 >> I also don't know how far you get requiring a specific authorization = format for JWT, some AS will wan to use a opaque reference, some might = want to use a user claim or role claim, others may use scopes, = combining scopes and claims is also possible. >> =20 >> Right now it is up to a AS RS pair to agree on how to communicate = authorization. I don't want MAC to be more restrictive than bearer = when it comes to authorization between AS and RS. >> =20 >> Hannes wanted to know why JWT didn't define scope. The simple answer = is that it is out of scope for JWT itself. It might be defined in a = OAuth access token profile for JWT but it should not be specific to MAC. >> =20 >> John B. >> On 2013-02-28, at 8:44 AM, Brian Campbell = wrote: >> =20 >>=20 >> I think John's point was more that scope is something rather specific = to an OAuth access token and, while JWT is can be used to represent an = access token, it's not the only application of JWT. The 'standard' = claims in JWT are those that are believed (right or wrong) to be widely = applicable across different applications of JWT. One could argue about = it but scope is probably not one of those. >>=20 >> It would probably make sense to try and build a profile of JWT = specifically for OAuth access tokens (though I suspect there are some = turtles and dragons in there), which might be the appropriate place to = define/register a scope claim. >> =20 >>=20 >> On Thu, Feb 28, 2013 at 9:24 AM, Phil Hunt = wrote: >> Are you advocating TWO systems? That seems like a bad choice. >>=20 >> I would rather fix scope than go to a two system approach. >>=20 >> Phil >>=20 >> Sent from my phone. >>=20 >> On 2013-02-28, at 8:17, John Bradley wrote: >>=20 >> > While scope is one method that a AS could communicate authorization = to a RS, it is not the only or perhaps even the most likely one. >> > Using scope requires a relatively tight binding between the RS and = AS, UMA uses a different mechanism that describes finer grained = operations. >> > The AS may include roles, user, or other more abstract claims that = the the client may (god help them) pass on to EXCML for processing. >> > >> > While having a scopes claim is possible, like any other claim it is = not part of the JWT core security processing claims, and needs to be = defined by extension. >> > >> > John B. >> > On 2013-02-28, at 2:29 AM, Hannes Tschofenig = wrote: >> > >> >> Hi Mike, >> >> >> >> when I worked on the MAC specification I noticed that the JWT does = not have a claim for the scope. I believe that this would be needed to = allow the resource server to verify whether the scope the authorization = server authorized is indeed what the client is asking for. >> >> >> >> Ciao >> >> Hannes >> >> >> >> _______________________________________________ >> >> OAuth mailing list >> >> OAuth@ietf.org >> >> https://www.ietf.org/mailman/listinfo/oauth >> > >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/oauth >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> =20 >> =20 >> =20 >> =20 >> =20 >> =20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >>=20 >> =20 >> --=20 >> Nat Sakimura (=3Dnat) >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_4ABBEB76-638D-477F-9C45-50B9F28C6EBE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Some = thing that scopes are a  stupidly vague bucket of stuff inferring = something about a permission for an action against a = resource.


If people want to send the scopes = that were sent from the the client to the authorization server to the RS = that is fine.

Scopes are intended for Client to = AS communication and the scopes granted are returned outside the token = and a client should never be snooping into the access = token.

I would object to requiring that Scopes = be the only or even preferred mechanism for communicating authorization = for resources to the RS.

Audience principal and = other members of the JWT provide much richer opportunities to = communicate permissions to the RS.

Al top level = members of the JWT are called claims so if you add a scopes claim with a = string containing the space separated scope strings if you like but it = is a claim like the others.

JWT is extensible = and you can add that,  It doesn't need to be in the core set of JWT = claims.

Other than that I have no = opinion:)

John B.

On = 2013-03-11, at 9:47 AM, Phil Hunt <phil.hunt@oracle.com> = wrote:

I agree. Many have been = suggesting audience. But my gut feeling matches yours.

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





On 2013-03-11, at 10:36 AM, Lewis Adam-CAL022 = wrote:

I would not even want to = confuse audience with scope.  Maybe in the simplest of cases, where = there is a one-to-one mapping between scope and audience, but in reality = the RS could expose multiple APIs at the same endpoint.  Granted = the RS could extract the audience field based on a fully qualified = scope, but it just seems that claims, scopes, and audiences are each = unique and should be kept that way.
 
adam
 
 Phil = Hunt [mailto:phil.hunt@oracle.com] 
Sent: Monday, March 11, 2013 9:25 = AM
To: Nat = Sakimura
Cc: Lewis Adam-CAL022; oauth@ietf.org = WG
Subject: Re: [OAUTH-WG] JWT - scope = claim missing
One thing that concerns me is = that scope is very different from a claim. An claim is an assertion = provided that may have some level of dispute/quality = etc.
A scope defines what is = request or what has been authorized.  It's an absolute thing. = Therefore it is not a claim. = Audience...maybe. 
 
This is why I think scope deserves special = attention/discussion in authorization assertions and in access = tokens.
Phil
 


2013/3/1 Lewis = Adam-CAL022 <Hmmm, I=92m not so sure.  It = depends where we all think OAuth is on its trajectory.  On one = hand, OAuth has already seen an insanely massive amount of = deployment.  On the other hand, RESTful APIs see no sign of slowing = down.   Now I=92m not going to go so far as Craig B. and say = that everything and everyone will be API enabled in the future, but it = sure is going to be a lot.  That being said, one could argue that = even with all the OAuth implementation we=92ve seen, that this is just = the infancy of it.  Obviously a WG profile of a JWT-structured AT = could not deprecate other forms (unstructured, SAML, etc.) but = going  forward new = developers may choose to embrace this, and in fact this could even be = the guidance.   I agree with previous comments that Justin=92s = introspection draft might be a good place to explore = this.
I do agree that a WG profile of a JWT-structured access token = could lend itself to interoperability and ultimately be a useful thing. = But you are right that there already are many implementations out there = in the wild (heck, I've written one myself) and that might make it = difficult to standardize on something.

Because of that, and many other reasons, I don't want = to try and add that to existing assertion = drafts.

On Thu, Feb 28, 2013 at 12:13 = PM, Lewis Adam-CAL022 <Hi Brian, a = few thoughts from somebody outside of the WG = =85

As a = newcomer to OAuth last year, I was initially confused by the = titles.  It was confusing because we have SAML bearer = *assertions* and JWT bearer *tokens* =85 and as John just = (begrudgingly) stated in this thread, the JWT is being used as an = assertion in this profile (and in OIDC).  I think it will be = difficult to find a good name for these profiles since they do two = entirely different things (e.g. define a new grant type and define a new = method of client authentication).  One could argue that as long as = the WG is at it, then why not add a third section to the JWT profile, = which talks about usage of JWT-structured bearer access tokens: it would = not be any less related than the other two focuses of the doc.  = Then the document could be called something simple like =93profiles of = JWT usage in OAuth=94 or something like = that. 
 oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Brian = Campbell
Sent: Thursday, February 28, 2013 = 1:03 PM
To: John = Bradley
Cc: oauth@ietf.org WG

Subject: Re: [OAUTH-WG] JWT - scope = claim missing
I'm not sure anyone really "picked" the titles for the bearer = token profiles. They just kind of evolved. And evolved in funny ways = especially when client authn to the AS was = added.

You won't hear me argue that the titles are "good" and this is = not the first time there's been confusion about what they actually do. = They define new grant types and new client authentication methods. They = *do not* define an access token format or anything else about access = tokens. JWT and SAML could be used for that but that's not what these = drafts do.

Suggestions for better = title(s) would be more than = welcome.
Here's what they are = now:

SAML 2.0 Bearer = Assertion Profiles for OAuth = 2.0
draft-ietf-oauth-saml2-bearer

JSON Web Token (JWT) Bearer = Token Profiles for OAuth = 2.0
draft-ietf-oauth-jwt-bearer

Assertion Framework for OAuth = 2.0
draft-ietf-oauth-assertions
 
On Thu, Feb = 28, 2013 at 11:36 AM, John Bradley <ve7jtb@ve7jtb.com> = wrote:
Yes the title likely adds to = the confusion given that the bearer tokens are not access = tokens.
Things as separate from = OAuth as the Firefox browerID spec use JWS signed JWTs. =  
The bearer token profiles = for OAuth 2 are for OAuth2.
 
      digitally signed or MACed and/or =
encrypted.
On 2013-02-28, at 10:12 = AM, Phil Hunt < 

JSON Web Token (JWT) Bearer Token Profiles for = OAuth 2.0


Note the title says = "for OAuth2"
Sorry. Couldn't = resist. 
Sent from my = phone.
JWT is an assertion( I am probably going to = regret using that word).
It is used in openID = connect for id_tokens, it is used in OAuth for Assertion grant types and = authentication of the client to the token = endpoint.


On 2013-02-28, at 8:58, John Bradley = <ve7jtb@ve7jtb.com> = wrote:

Yes, defining scope in JWT is the wrong = place.   JWT needs to stick to the security claims needed to = process JWT.
I also don't know how far = you get requiring a specific authorization format for JWT, some AS will = wan to use a opaque reference, some might want to use a user claim or = role claim, others may use scopes,  combining scopes and claims is = also possible.
Right now it is up to a = AS RS pair to agree on how to communicate authorization.   I don't = want MAC to be more restrictive than bearer when it comes to = authorization between AS  and = RS.
Hannes wanted to know why = JWT didn't define scope.  The simple answer is that it is out of = scope for JWT itself.   It might be defined in a OAuth access token = profile for JWT but it should not be specific to = MAC.
John = B.
On 2013-02-28, at 8:44 = AM, Brian Campbell < 

I think John's point was more that scope is = something rather specific to an OAuth access token and, while JWT is can = be used to represent an access token, it's not the only application of = JWT. The 'standard' claims in JWT are those that are believed (right or = wrong) to be widely applicable across different applications of JWT. One = could argue about it but scope is probably not one of = those.

It would probably make sense to = try and build a profile of JWT specifically for OAuth access tokens = (though I suspect there are some turtles and dragons in there), which = might be the appropriate place to define/register a scope = claim.

OAuth@ietf.org


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


= --Apple-Mail=_4ABBEB76-638D-477F-9C45-50B9F28C6EBE-- --Apple-Mail=_A060059C-B640-4D42-930A-B0DC8FBE3CD5 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 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMzExMTUwODMyWjAjBgkqhkiG9w0BCQQxFgQUzd5Y6tG+ 3OXFuxOqp8MlHRAEa+cwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAW0dZ7bWATn7VPYW6T6HIRjHEjAfuUTaVNAjhQHwB kx9UzNDpvf6D7Lgk3Di9MOA54JfeYpj6CLzInO1pHMeE6qPDHvwUiW1ID7e+kf/2OBzz47xo6aK5 J7O4BRKlwfErmIyOJ7KhL/lQ1nYWhHexjKfb7JdmWRwPuHoa+9FT25wkl4SBVETuc+LXhUtSrw8Z 6VQ6vfOxb5kRG0/9yR9j0Ye3ol6eSYqYqbcrf18o7fp2+KSknc3CmgsfKlhSNBav63um6FyclzT7 zByZNjlvnEVj6mwj5a/GnG7n4//2UAxMldYWUHo0P3d/OdKTWCmx4MyySvvLQddcUT7CGE2aZwAA AAAAAA== --Apple-Mail=_A060059C-B640-4D42-930A-B0DC8FBE3CD5-- From Adam.Lewis@motorolasolutions.com Mon Mar 11 09:11:11 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 6C37E11E80FF for ; Mon, 11 Mar 2013 09:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[AWL=1.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_82=0.6, RCVD_IN_DNSWL_MED=-4, 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 re7gUwbrDLSm for ; Mon, 11 Mar 2013 09:11:02 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe004.messaging.microsoft.com [207.46.163.27]) by ietfa.amsl.com (Postfix) with ESMTP id 516DD11E80EF for ; Mon, 11 Mar 2013 09:11:02 -0700 (PDT) Received: from mail1-co9-R.bigfish.com (10.236.132.243) by CO9EHSOBE005.bigfish.com (10.236.130.68) with Microsoft SMTP Server id 14.1.225.23; Mon, 11 Mar 2013 16:11:01 +0000 Received: from mail1-co9 (localhost [127.0.0.1]) by mail1-co9-R.bigfish.com (Postfix) with ESMTP id 7B8864C02F2 for ; Mon, 11 Mar 2013 16:11:01 +0000 (UTC) X-Forefront-Antispam-Report: CIP:192.160.210.14; KIP:(null); UIP:(null); IPV:NLI; H:ct11msg02.am.mot-solutions.com; RD:ct11msg02.mot-solutions.com; EFVD:NLI X-SpamScore: -32 X-BigFish: VPS-32(zzbb2dI98dI9371Ic89bh936eIc85dh1432I179cI179dNzz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz8275ch1033IL177df4h17326ah8275dh18c673h1954cbh18602eh8275bhz2fh2a8h683h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1b0ah1155h) Received-SPF: pass (mail1-co9: domain of motorolasolutions.com designates 192.160.210.14 as permitted sender) client-ip=192.160.210.14; envelope-from=Adam.Lewis@motorolasolutions.com; helo=ct11msg02.am.mot-solutions.com ; olutions.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.237.133; KIP:(null); UIP:(null); (null); H:BY2PRD0411HT004.namprd04.prod.outlook.com; R:internal; EFV:INT Received: from mail1-co9 (localhost.localdomain [127.0.0.1]) by mail1-co9 (MessageSwitch) id 1363018258163454_31048; Mon, 11 Mar 2013 16:10:58 +0000 (UTC) Received: from CO9EHSMHS017.bigfish.com (unknown [10.236.132.243]) by mail1-co9.bigfish.com (Postfix) with ESMTP id 17B0526008D for ; Mon, 11 Mar 2013 16:10:58 +0000 (UTC) Received: from ct11msg02.am.mot-solutions.com (192.160.210.14) by CO9EHSMHS017.bigfish.com (10.236.130.27) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 11 Mar 2013 16:10:54 +0000 Received: from ct11msg02.am.mot-solutions.com (ct11vts01.am.mot.com [10.177.16.159]) by ct11msg02.am.mot-solutions.com (8.14.3/8.14.3) with ESMTP id r2BGB6xL002355 for ; Mon, 11 Mar 2013 12:11:06 -0400 (EDT) Received: from CO9EHSOBE035.bigfish.com (co9ehsobe005.messaging.microsoft.com [207.46.163.28]) by ct11msg02.am.mot-solutions.com (8.14.3/8.14.3) with ESMTP id r2BGB4ja002346 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 11 Mar 2013 12:11:05 -0400 (EDT) Received: from mail116-co9-R.bigfish.com (10.236.132.237) by CO9EHSOBE035.bigfish.com (10.236.130.98) with Microsoft SMTP Server id 14.1.225.23; Mon, 11 Mar 2013 16:10:52 +0000 Received: from mail116-co9 (localhost [127.0.0.1]) by mail116-co9-R.bigfish.com (Postfix) with ESMTP id EDDD6240207 for ; Mon, 11 Mar 2013 16:10:51 +0000 (UTC) Received: from mail116-co9 (localhost.localdomain [127.0.0.1]) by mail116-co9 (MessageSwitch) id 1363018248815087_2365; Mon, 11 Mar 2013 16:10:48 +0000 (UTC) Received: from CO9EHSMHS032.bigfish.com (unknown [10.236.132.245]) by mail116-co9.bigfish.com (Postfix) with ESMTP id B904D540076; Mon, 11 Mar 2013 16:10:48 +0000 (UTC) Received: from BY2PRD0411HT004.namprd04.prod.outlook.com (157.56.237.133) by CO9EHSMHS032.bigfish.com (10.236.130.42) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 11 Mar 2013 16:10:46 +0000 Received: from BY2PRD0411MB441.namprd04.prod.outlook.com ([169.254.5.10]) by BY2PRD0411HT004.namprd04.prod.outlook.com ([10.255.128.39]) with mapi id 14.16.0275.006; Mon, 11 Mar 2013 16:10:46 +0000 From: Lewis Adam-CAL022 To: Phil Hunt , John Bradley Thread-Topic: [OAUTH-WG] JWT - scope claim missing Thread-Index: AQHOFZ6Qe5ExGqoPnkOeJlU0r70rz5iPcwoAgAAB5gCAAAWJgIAABAMAgAAIM4CAAAN2AIAACPeAgAAGkICAAAeWAIAAAR2AgAAILoCAACqKMIAQ3nqvgAAE2hA= Date: Mon, 11 Mar 2013 16:10:46 +0000 Message-ID: <59E470B10C4630419ED717AC79FCF9A956897044@BY2PRD0411MB441.namprd04.prod.outlook.com> References: <0EC2404F-E3C5-4AD1-88B4-E74AA0394DD9@gmx.net> <48FD87D1-4DF4-4289-99B7-40A515F31890@oracle.com> <3E472720-31A4-40A0-AAA4-402CF850831A@ve7jtb.com> <7127843B-D7B0-4AB6-87F1-1604D1EFFA79@oracle.com> <50DA292F-32F0-4266-8401-006AD837B775@ve7jtb.com> <59E470B10C4630419ED717AC79FCF9A948D58BEE@BY2PRD0411MB441.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A948D58DC0@BY2PRD0411MB441.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A956893F49@BY2PRD0411MB441.namprd04.prod.outlook.com>! ! <3C571C43-C53A-4385-8ADF-FB2A7E788B29@oracle.com> <32C1936C-0922-4F1E-AF5F-C6E1C550602A@oracle.com> In-Reply-To: <32C1936C-0922-4F1E-AF5F-C6E1C550602A@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [150.130.164.106] Content-Type: multipart/alternative; boundary="_000_59E470B10C4630419ED717AC79FCF9A956897044BY2PRD0411MB441_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%1294$Dn%ORACLE.COM$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn% X-FOPE-CONNECTOR: Id%1294$Dn%VE7JTB.COM$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn% X-FOPE-CONNECTOR: Id%1294$Dn%IETF.ORG$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn% X-CFilter-Loop: Reflected X-OriginatorOrg: motorolasolutions.com Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] JWT - scope claim missing X-BeenThere: oauth@ietf.org X-Mailman-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, 11 Mar 2013 16:11:11 -0000 --_000_59E470B10C4630419ED717AC79FCF9A956897044BY2PRD0411MB441_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable "Many people don't want a separate RS to AS communication channel. So the t= oken should give the RS everything it needs. So if scope was intended to b= e defined in terms of what the RS understands, then of course, the RS needs= to know what was authorized." This is my scenario, to be exact. Development teams have given me pretty u= nequivocal feedback that the token they receive, they must be able to valid= ate and process autonomously without having to reach back to the AS. This = is why I am looking to profile (for my use cases) the AT to be a structured= JWT since this meets the demands of my developers. This was actually proving to be difficult (utilizing the standard) since JW= T was initially meant to audience restrict the token to the client; but wit= h the new changes it seems I'll be able to use the standard as-is, and incl= ude an audience=3DRS claim. adam From: Phil Hunt [mailto:phil.hunt@oracle.com] Sent: Monday, March 11, 2013 10:45 AM To: John Bradley Cc: Lewis Adam-CAL022; "WG "@il06exr01.mot.com Subject: Re: [OAUTH-WG] JWT - scope claim missing I think we have a different view on what the AS and RS should be doing... s= ee below. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-03-11, at 11:08 AM, John Bradley wrote: Some thing that scopes are a stupidly vague bucket of stuff inferring some= thing about a permission for an action against a resource. Sure. I think intent of the WG was that scopes be undefined but that that t= hey would be highly localized to specific resource services. If people want to send the scopes that were sent from the the client to the= authorization server to the RS that is fine. Scopes are intended for Client to AS communication and the scopes granted a= re returned outside the token and a client should never be snooping into th= e access token. I don't agree. Scope was always intended to be a set of rights understanda= ble to specific narrow scope of resource/apps. Many people don't want a s= eparate RS to AS communication channel. So the token should give the RS eve= rything it needs. So if scope was intended to be defined in terms of what = the RS understands, then of course, the RS needs to know what was authorize= d. That still doesn't preclude an AS taking a complex bearer authorization and= enabling the richness you mention. I would object to requiring that Scopes be the only or even preferred mecha= nism for communicating authorization for resources to the RS. I believe that the access token should have authorization information (incl= uding scope) and identity claims about authorizing user, client, if useful = to the resource. The most important is what the AS has authorized --- incl= uding scope. Audience principal and other members of the JWT provide much richer opportu= nities to communicate permissions to the RS. I don't think richness is the objective. The AS has the richness, but its j= ob is to narrow down richness (complexity) and simplify for the resource se= rver. Al top level members of the JWT are called claims so if you add a scopes cl= aim with a string containing the space separated scope strings if you like = but it is a claim like the others. JWT is extensible and you can add that, It doesn't need to be in the core = set of JWT claims. Other than that I have no opinion:) John B. On 2013-03-11, at 9:47 AM, Phil Hunt > wrote: I agree. Many have been suggesting audience. But my gut feeling matches you= rs. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-03-11, at 10:36 AM, Lewis Adam-CAL022 wrote: I would not even want to confuse audience with scope. Maybe in the simples= t of cases, where there is a one-to-one mapping between scope and audience,= but in reality the RS could expose multiple APIs at the same endpoint. Gr= anted the RS could extract the audience field based on a fully qualified sc= ope, but it just seems that claims, scopes, and audiences are each unique a= nd should be kept that way. adam From: Phil Hunt [mailto:phil.hunt@oracle.com] Sent: Monday, March 11, 2013 9:25 AM To: Nat Sakimura Cc: Lewis Adam-CAL022; oauth@ietf.org WG Subject: Re: [OAUTH-WG] JWT - scope claim missing One thing that concerns me is that scope is very different from a claim. An= claim is an assertion provided that may have some level of dispute/quality= etc. A scope defines what is request or what has been authorized. It's an absol= ute thing. Therefore it is not a claim. Audience...maybe. This is why I think scope deserves special attention/discussion in authoriz= ation assertions and in access tokens. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-03-10, at 9:17 PM, Nat Sakimura wrote: So, it is soooo late in the game: I have been completely underwater to even= read the OAuth mails for about a month and slowly catching up now. Here is an I-D that I have created partly in response to the RS-AS interact= ion piece that was talked about at IETF 85. It does not have 'scope' and has 'claims' instead as it was based on OpenID= Connect, but it is easy to add, provided that the scopes are to be underst= ood as that of the 'aud'. http://tools.ietf.org/id/draft-sakimura-oidc-structured-token-01.txt Best, Nat 2013/3/1 Lewis Adam-CAL022 > Hmmm, I'm not so sure. It depends where we all think OAuth is on its traje= ctory. On one hand, OAuth has already seen an insanely massive amount of d= eployment. On the other hand, RESTful APIs see no sign of slowing down. = Now I'm not going to go so far as Craig B. and say that everything and ever= yone will be API enabled in the future, but it sure is going to be a lot. = That being said, one could argue that even with all the OAuth implementatio= n we've seen, that this is just the infancy of it. Obviously a WG profile = of a JWT-structured AT could not deprecate other forms (unstructured, SAML,= etc.) but going forward new developers may choose to embrace this, and in= fact this could even be the guidance. I agree with previous comments tha= t Justin's introspection draft might be a good place to explore this. adam From: Brian Campbell [mailto:bcampbell@pingidentity.com] Sent: Thursday, February 28, 2013 1:36 PM To: Lewis Adam-CAL022 Cc: John Bradley; oauth@ietf.org WG Subject: Re: [OAUTH-WG] JWT - scope claim missing I do agree that a WG profile of a JWT-structured access token could lend it= self to interoperability and ultimately be a useful thing. But you are righ= t that there already are many implementations out there in the wild (heck, = I've written one myself) and that might make it difficult to standardize on= something. Because of that, and many other reasons, I don't want to try and add that t= o existing assertion drafts. On Thu, Feb 28, 2013 at 12:13 PM, Lewis Adam-CAL022 > wrote: Hi Brian, a few thoughts from somebody outside of the WG ... As a newcomer to OAuth last year, I was initially confused by the titles. = It was confusing because we have SAML bearer *assertions* and JWT bearer *t= okens* ... and as John just (begrudgingly) stated in this thread, the JWT i= s being used as an assertion in this profile (and in OIDC). I think it wil= l be difficult to find a good name for these profiles since they do two ent= irely different things (e.g. define a new grant type and define a new metho= d of client authentication). One could argue that as long as the WG is at = it, then why not add a third section to the JWT profile, which talks about = usage of JWT-structured bearer access tokens: it would not be any less rela= ted than the other two focuses of the doc. Then the document could be call= ed something simple like "profiles of JWT usage in OAuth" or something like= that. On one hand, it is probably na=EFve to think that an access token can be st= andardized in a profile given how many have already been released into the = wild, but on the other hand, a WG profile of a JWT-structured access token = could lend itself to interoperability, where AS implementations can adverti= se conformance to the profile and who knows ... maybe the RS's of the futur= e will be good with this. adam From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Brian Campbell Sent: Thursday, February 28, 2013 1:03 PM To: John Bradley Cc: oauth@ietf.org WG Subject: Re: [OAUTH-WG] JWT - scope claim missing I'm not sure anyone really "picked" the titles for the bearer token profile= s. They just kind of evolved. And evolved in funny ways especially when cli= ent authn to the AS was added. You won't hear me argue that the titles are "good" and this is not the firs= t time there's been confusion about what they actually do. They define new = grant types and new client authentication methods. They *do not* define an = access token format or anything else about access tokens. JWT and SAML coul= d be used for that but that's not what these drafts do. Suggestions for better title(s) would be more than welcome. Here's what they are now: SAML 2.0 Bearer Assertion Profiles for OAuth 2.0 draft-ietf-oauth-saml2-bearer JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0 draft-ietf-oauth-jwt-bearer Assertion Framework for OAuth 2.0 draft-ietf-oauth-assertions On Thu, Feb 28, 2013 at 11:36 AM, John Bradley > wrote: Yes the title likely adds to the confusion given that the bearer tokens are= not access tokens. Things as separate from OAuth as the Firefox browerID spec use JWS signed J= WTs. The bearer token profiles for OAuth 2 are for OAuth2. The JSON Web Token (JWT) spec did not start in OAuth and is not OAuth specific. A JWT is: JSON Web Token (JWT) A string representing a set of claims as a JSON object that is encoded in a JWS or JWE, enabling the claims to be digitally signed or MACed and/or encrypted. So OAuth or other profiles may define claims to go in a JWT, but the JWT ne= eds to itself only define the claims necessary for security processing. John B. PS that was a soft ball If you hadn't responded I would have been disappoin= ted. I din't pick the title for the bearer token profiles. On 2013-02-28, at 10:12 AM, Phil Hunt > wrote: JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0 Note the title says "for OAuth2" Sorry. Couldn't resist. Phil Sent from my phone. On 2013-02-28, at 9:40, John Bradley > wrote: JWT is an assertion( I am probably going to regret using that word). It is used in openID connect for id_tokens, it is used in OAuth for Asserti= on grant types and authentication of the client to the token endpoint. http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-04 JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0 Dosen't define JWT's use for access tokens for the RS. Bottom line JWT is for more than access tokens. John B. On 2013-02-28, at 9:28 AM, Phil Hunt > wrote: Are you saying jwt is not an access token type? Phil Sent from my phone. On 2013-02-28, at 8:58, John Bradley > wrote: Yes, defining scope in JWT is the wrong place. JWT needs to stick to the = security claims needed to process JWT. I also don't know how far you get requiring a specific authorization format= for JWT, some AS will wan to use a opaque reference, some might want to us= e a user claim or role claim, others may use scopes, combining scopes and = claims is also possible. Right now it is up to a AS RS pair to agree on how to communicate authoriza= tion. I don't want MAC to be more restrictive than bearer when it comes t= o authorization between AS and RS. Hannes wanted to know why JWT didn't define scope. The simple answer is th= at it is out of scope for JWT itself. It might be defined in a OAuth acce= ss token profile for JWT but it should not be specific to MAC. John B. On 2013-02-28, at 8:44 AM, Brian Campbell > wrote: I think John's point was more that scope is something rather specific to an= OAuth access token and, while JWT is can be used to represent an access to= ken, it's not the only application of JWT. The 'standard' claims in JWT are= those that are believed (right or wrong) to be widely applicable across di= fferent applications of JWT. One could argue about it but scope is probably= not one of those. It would probably make sense to try and build a profile of JWT specifically= for OAuth access tokens (though I suspect there are some turtles and drago= ns in there), which might be the appropriate place to define/register a sco= pe claim. On Thu, Feb 28, 2013 at 9:24 AM, Phil Hunt > wrote: Are you advocating TWO systems? That seems like a bad choice. I would rather fix scope than go to a two system approach. Phil Sent from my phone. On 2013-02-28, at 8:17, John Bradley > wrote: > While scope is one method that a AS could communicate authorization to a = RS, it is not the only or perhaps even the most likely one. > Using scope requires a relatively tight binding between the RS and AS, U= MA uses a different mechanism that describes finer grained operations. > The AS may include roles, user, or other more abstract claims that the th= e client may (god help them) pass on to EXCML for processing. > > While having a scopes claim is possible, like any other claim it is not p= art of the JWT core security processing claims, and needs to be defined by = extension. > > John B. > On 2013-02-28, at 2:29 AM, Hannes Tschofenig > wrote: > >> Hi Mike, >> >> when I worked on the MAC specification I noticed that the JWT does not h= ave a claim for the scope. I believe that this would be needed to allow the= resource server to verify whether the scope the authorization server autho= rized is indeed what the client is asking for. >> >> Ciao >> Hannes >> >> _______________________________________________ >> OAuth mailing 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 -- Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_59E470B10C4630419ED717AC79FCF9A956897044BY2PRD0411MB441_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

“Many people don't want a separate RS to AS= communication channel. So the token should give the RS everything it needs= .  So if scope was intended to be defined in terms of what the RS unde= rstands, then of course, the RS needs to know what was authorized.”

 

This is my scenario, to b= e exact.  Development teams have given me pretty unequivocal feedback = that the token they receive, they must be able to validate and process autonomously without having to reach back to the AS.  This is= why I am looking to profile (for my use cases) the AT to be a structured J= WT since this meets the demands of my developers. 

 <= /p>

This was actually proving= to be difficult (utilizing the standard) since JWT was initially meant to = audience restrict the token to the client; but with the new changes it seems I’ll be able to use the standard as-is, and inc= lude an audience=3DRS claim.

 

adam

 <= /p>

From: Phil Hun= t [mailto:phil.hunt@oracle.com]
Sent: Monday, March 11, 2013 10:45 AM
To: John Bradley
Cc: Lewis Adam-CAL022; "WG <oauth@ietf.org>"@il06exr= 01.mot.com
Subject: Re: [OAUTH-WG] JWT - scope claim missing<= /p>

 

I think we have a different view on what the AS and = RS should be doing... see below.

 

 

Phil

 

@independentid<= /span>

phil.hunt@oracle.com=

 <= /p>



 

On 2013-03-11, at 11:08 AM, John Bradley wrote:=



Some thing that scopes are a  stupidly vague bu= cket of stuff inferring something about a permission for an action against = a resource.

 

Sure. I think intent of the WG was that scopes be un= defined but that that they would be highly localized to specific resource s= ervices. 

 

If people want to send the scopes that were sent fro= m the the client to the authorization server to the RS that is fine.

 

Scopes are intended for Client to AS communication a= nd the scopes granted are returned outside the token and a client should ne= ver be snooping into the access token.

 

I don't agree.  Scope was always intended to be= a set of rights understandable to  specific narrow scope of resource/= apps.  Many people don't want a separate RS to AS communication channe= l. So the token should give the RS everything it needs.  So if scope was intended to be defined in terms of what the R= S understands, then of course, the RS needs to know what was authorized. &n= bsp;

 

That still doesn't preclude an AS taking a complex b= earer authorization and enabling the richness you mention.

 

I would object to requiring that Scopes be the only = or even preferred mechanism for communicating authorization for resources t= o the RS.

 

I believe that the access token should have authoriz= ation information (including scope) and identity claims about authorizing u= ser, client, if useful to the resource.  The most important is what th= e AS has authorized --- including scope.



Audience principal and other members of the JWT prov= ide much richer opportunities to communicate permissions to the RS.

 

I don't think richness is the objective. The AS has = the richness, but its job is to narrow down richness (complexity) and simpl= ify for the resource server.

 

Al top level members of the JWT are called claims so= if you add a scopes claim with a string containing the space separated sco= pe strings if you like but it is a claim like the others.

 

JWT is extensible and you can add that,  It doe= sn't need to be in the core set of JWT claims.

 

Other than that I have no opinion:)

 

John B.

 

On 2013-03-11, at 9:47 AM, Phil Hunt <phil.hunt@oracle.com> wrote:=



I agree. Many have been suggesting audience. But my = gut feeling matches yours.

 

 



 

On 2013-03-11, at 10:36 AM, Lewis Adam-CAL022 wrote:=



I would not even want to = confuse audience with scope.  Maybe in the simplest of cases, where th= ere is a one-to-one mapping between scope and audience, but in reality the RS could expose multiple APIs at the same endpoint.  Gran= ted the RS could extract the audience field based on a fully qualified scop= e, but it just seems that claims, scopes, and audiences are each unique and= should be kept that way.

 <= /p>

adam

 <= /p>

From: Phil Hunt [mailto:phil.hunt@oracle.com] 
Sent: Monday, Marc= h 11, 2013 9:25 AM
To: Nat Sakimura Cc: Lewis Adam-CAL= 022; oauth@ietf.org WG
Subject: Re: [OAUT= H-WG] JWT - scope claim missing

 

One thing that concerns me is that scope is very dif= ferent from a claim. An claim is an assertion provided that may have some l= evel of dispute/quality etc.

 

A scope defines what is request or what has been aut= horized.  It's an absolute thing. Therefore it is not a claim. Audienc= e...maybe. 

 

This is why I think scope deserves special attention= /discussion in authorization assertions and in access tokens.

 

 




 

On 2013-03-10, at 9:17 PM, Nat Sakimura wrote:<= /o:p>




So, it is soooo late in the game: I have been comple= tely underwater to even read the OAuth mails for about a month and slowly c= atching up now. 

 

Here is an I-D that I have created partly in respons= e to the RS-AS interaction piece that was talked about at IETF 85. 

It does not have 'scope' and has 'claims' instead as= it was based on OpenID Connect, but it is easy to add, provided that the s= copes are to be understood as that of the 'aud'. 

 

 

Best, 

 

Nat

 

2013/3/1 Lewis Adam-CAL022 <Adam.Lewis@motorolasolutio= ns.com>

Hmmm, I’m not so sure= .  It depends where we all think OAuth is on its trajectory.  On = one hand, OAuth has already seen an insanely massive amount of deployment.&= nbsp; On the other hand, RESTful APIs see no sign of slowing down.   N= ow I’m not going to go so far as Craig B. and say that everything and= everyone will be API enabled in the future, but it sure is going to be a l= ot.  That being said, one could argue that even with all the OAuth implementation we’ve seen, that this is just the = infancy of it.  Obviously a WG profile of a JWT-structured AT could no= t deprecate other forms (unstructured, SAML, etc.) but going  forward new developers may choose to embrace this, and in fact this could even be the guidance. &= nbsp; I agree with previous comments that Justin’s introspection= draft might be a good place to explore this.

 

adam

 

From: Brian Campbell [mailto:bcampbell@pingidentity.com] 
Sent: Thursday, Fe= bruary 28, 2013 1:36 PM
To: Lewis Adam-CAL= 022
Cc: John Bradley;<= span class=3D"apple-converted-space"> oauth@ietf.org WG


Subject: Re: [OAUT= H-WG] JWT - scope claim missing

 

 

I do agree that a WG = profile of a JWT-structured access token could lend itself to interoperabil= ity and ultimately be a useful thing. But you are right that there already = are many implementations out there in the wild (heck, I've written one myself) and that might make it difficult = to standardize on something.

Because of that, and many other reasons, I don't wan= t to try and add that to existing assertion drafts.

 

On Thu, Feb 28, 2013 at 12:13 PM, Lewis Adam-CAL022 = <A= dam.Lewis@motorolasolutions.com> wrote:

Hi Brian, a few thoughts fr= om somebody outside of the WG …

 

As a newcomer to OAuth last= year, I was initially confused by the titles.  It was confusing becau= se we have SAML bearer *assertions* and JWT bearer *tokens* … and as John just (begrudgingly) stated in this thread, the JWT is = being used as an assertion in this profile (and in OIDC).  I think it = will be difficult to find a good name for these profiles since they do two = entirely different things (e.g. define a new grant type and define a new method of client authentication).  One co= uld argue that as long as the WG is at it, then why not add a third section= to the JWT profile, which talks about usage of JWT-structured bearer acces= s tokens: it would not be any less related than the other two focuses of the doc.  Then the document could be ca= lled something simple like “profiles of JWT usage in OAuth” or = something like that. 

 

On one hand, it is probably= na=EFve to think that an access token can be standardized in a profile giv= en how many have already been released into the wild, but on the other hand, a WG profile of a JWT-structured access token could len= d itself to interoperability, where AS implementations can advertise confor= mance to the profile and who knows … maybe the RS’s of the futu= re will be good with this. 

 

adam

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Brian Camp= bell
Sent: Thursday, Fe= bruary 28, 2013 1:03 PM
To: John Bradley Cc: oauth@ietf.org WG


Subject: Re: [OAUT= H-WG] JWT - scope claim missing

 

I'm not sure anyone r= eally "picked" the titles for the bearer token profiles. They jus= t kind of evolved. And evolved in funny ways especially when client authn t= o the AS was added.

You won't hear me arg= ue that the titles are "good" and this is not the first time ther= e's been confusion about what they actually do. They define new grant types= and new client authentication methods. They *do not* define an access token format or anything else about access tokens. J= WT and SAML could be used for that but that's not what these drafts do.

Suggestions for better title(s) would be more than w= elcome.

 

Here's what they are now:


SAML 2.0 Bearer Assertion Profiles for OAuth 2.0
draft-ietf-oauth-saml2-bearer

JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0
draft-ietf-oauth-jwt-bearer

Assertion Framework for OAuth 2.0
draft-ietf-oauth-assertions

 

On Thu, Feb 28, 2013 at 11:36 AM, John Bradley <<= a href=3D"mailto:ve7jtb@ve7jtb.com" target=3D"_blank">ve7jtb@ve7jtb.com= > wrote:

Yes the title likely adds to the confusion given tha= t the bearer tokens are not access tokens.

 

Things as separate from OAuth as the Firefox browerI= D spec use JWS signed JWTs.  

 

The bearer token profiles for OAuth 2 are for OAuth2= .

 

The JSON Web Token (JWT)&n= bsp;spec did not start in OAuth and is not OAuth specific.

 

A JWT is:

JSON Web Token (JWT)  A string r=
epresenting a set of claims as a JSON
      object=
 that is encoded in a JWS or JWE, enabling the claims to be
      digita=
lly signed or MACed and/or encrypted.

 

So OAuth or other profiles may define claims to go i= n a JWT, but the JWT needs to itself only define the claims necessary for s= ecurity processing.  

 

John B.

PS that was a soft ball If you hadn't responded I wo= uld have been disappointed.  I din't pick the title for the bearer tok= en profiles.

 

 

On 2013-02-28, at 10:12 AM, Phil Hunt <phil.hunt@oracle.com>= ; wrote:

 

JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0


Note the title says "for OAuth2"

 

Sorry. Couldn't resist. 

 

Phil

 

Sent from my phone.


On 2013-02-28, at 9:40, John Bradley <ve7jtb@ve7jtb.com> wrote:

JWT is an assertion( I am probably going to regret u= sing that word).

 

It is used in openID connect for id_tokens, it is us= ed in OAuth for Assertion grant types and authentication of the client to t= he token endpoint.

 

 
 

JS= ON Web Token (JWT) Bearer Token Profiles for OAuth 2.0

 

Dosen't define JWT's use for access tokens for the R= S.   

 

Bottom line JWT is for more than access tokens.=

 

John B.

 

On 2013-02-28, at 9:28 AM, Phil Hunt <phil.hunt@oracle.com>= wrote:

 

Are you saying jwt is not an access token type?

Phil

 

Sent from my phone.


On 2013-02-28, at 8:58, John Bradley <ve7jtb@ve7jtb.com> wrote:

Yes, defining scope in JWT is the wrong place.  = ; JWT needs to stick to the security claims needed to process JWT.

 

I also don't know how far you get requiring a specif= ic authorization format for JWT, some AS will wan to use a opaque reference= , some might want to use a user claim or role claim, others may use scopes,=  combining scopes and claims is also possible.

 

Right now it is up to a AS RS pair to agree on how t= o communicate authorization.   I don't want MAC to be more restrictive= than bearer when it comes to authorization between AS  and RS.

 

Hannes wanted to know why JWT didn't define scope. &= nbsp;The simple answer is that it is out of scope for JWT itself.   It= might be defined in a OAuth access token profile for JWT but it should not= be specific to MAC.

 

John B.

On 2013-02-28, at 8:44 AM, Brian Campbell <bcampbell@pingide= ntity.com> wrote:

 

I think John's point = was more that scope is something rather specific to an OAuth access token a= nd, while JWT is can be used to represent an access token, it's not the onl= y application of JWT. The 'standard' claims in JWT are those that are believed (right or wrong) to be widely ap= plicable across different applications of JWT. One could argue about it but= scope is probably not one of those.

It would probably make sense to try and build a prof= ile of JWT specifically for OAuth access tokens (though I suspect there are= some turtles and dragons in there), which might be the appropriate place t= o define/register a scope claim.

 

On Thu, Feb 28, 2013 at 9:24 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

Are you advocating TWO systems? That seems like a ba= d choice.

I would rather fix scope than go to a two system approach.

Phil

Sent from my phone.

On 2013-02-28, at 8:17, John Bradley <ve7jtb@ve7jtb.com> wrote:

> While scope is one method that a AS could communicate authorization to= a RS, it is not the only or perhaps even the most likely one.
> Using scope requires a relatively tight binding between the RS and AS,=  UMA uses a different mechanism that describes finer grained operatio= ns.
> The AS may include roles, user, or other more abstract claims that the= the client may (god help them) pass on to EXCML for processing.
>
> While having a scopes claim is possible, like any other claim it is no= t part of the JWT core security processing claims, and needs to be defined = by extension.
>
> John B.
> On 2013-02-28, at 2:29 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net>= wrote:
>
>> Hi Mike,
>>
>> when I worked on the MAC specification I noticed that the JWT does= not have a claim for the scope. I believe that this would be needed to all= ow the resource server to verify whether the scope the authorization server= authorized is indeed what the client is asking for.
>>
>> Ciao
>> Hannes
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.= org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/= mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

 

 

 

 

 

 


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



 

-- 
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.= org/
@_nat_en

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

 

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

 

 

--_000_59E470B10C4630419ED717AC79FCF9A956897044BY2PRD0411MB441_-- From sakimura@gmail.com Mon Mar 11 09:42: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 9557811E8172 for ; Mon, 11 Mar 2013 09:42:13 -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, HTML_MESSAGE=0.001, 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 zJ9FzoU6v7Kw for ; Mon, 11 Mar 2013 09:42:11 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 9E4E011E816F for ; Mon, 11 Mar 2013 09:42:10 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id ek20so4164856lab.16 for ; Mon, 11 Mar 2013 09:42:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:references:from:in-reply-to:mime-version:date:message-id :subject:to:content-type; bh=88OG5HU9fEKTF4Rz9ANvq1k9tzyLzwqn9gCFtJtfTkk=; b=AyVun6Q6ePhjByAJR4plEiJrcmKSPsngTRPfYMiIFuJJyo03oRkcgFciYhIKuBF2mw hWVcZoRjvL7CEaauAtGqCH/KBr/3R/c5HmX0xhdR1htHLub6Hu6SQYn26hhIKqSyMuxo xD3Q9RLPGn7WteMBxbOW6u1Ch5rdNQy1MpubzUmzCQ8Nn3L3kxF+hg8Gd+pr1b6+rFZC n0094TbHfyRJPb/9jA8jyRDIF+QmDCrliXz/+ETWrP6riwd+b8eYe/jOzPU98le74q/t MgglrLzFt+dw4WJ0SZDKzChPvA4mSj5uO2+rKG24YYU7m/FoT0pB8WglFxnI2amggV51 3V/g== X-Received: by 10.152.105.38 with SMTP id gj6mr10746198lab.25.1363020129372; Mon, 11 Mar 2013 09:42:09 -0700 (PDT) References: <0EC2404F-E3C5-4AD1-88B4-E74AA0394DD9@gmx.net> <48FD87D1-4DF4-4289-99B7-40A515F31890@oracle.com> <3E472720-31A4-40A0-AAA4-402CF850831A@ve7jtb.com> <7127843B-D7B0-4AB6-87F1-1604D1EFFA79@oracle.com> <50DA292F-32F0-4266-8401-006AD837B775@ve7jtb.com> <59E470B10C4630419ED717AC79FCF9A948D58BEE@BY2PRD0411MB441.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A948D58DC0@BY2PRD0411MB441.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A956893F49@BY2PRD0411MB441.namprd04.prod.outlook.com> From: Nat Sakimura In-Reply-To: <59E470B10C4630419ED717AC79FCF9A956893F49@BY2PRD0411MB441.namprd04.prod.outlook.com> Mime-Version: 1.0 (1.0) Date: Mon, 11 Mar 2013 12:42:05 -0400 Message-ID: <6618804564592604619@unknownmsgid> To: "oauth@ietf.org WG" Content-Type: multipart/alternative; boundary=f46d0408d3f7a2151604d7a8da55 Subject: Re: [OAUTH-WG] JWT - scope claim missing X-BeenThere: oauth@ietf.org X-Mailman-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, 11 Mar 2013 16:42:13 -0000 --f46d0408d3f7a2151604d7a8da55 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable No. I am not confusing scope with audience. There is no standard scope. So, the scope has to be either defined by the resource or the authorization server. Just stating scope is too vague that you will not able to find out whose scope it is. That is why I wrote that the scope has to be understood in the context of aud. Audience is the resource. So what I wrote amounts to be that the scope expressed in the token is what was defined by the resource and not the authorization server. It could be authorization server's scope, but then there would be a complication that the resource has to be able to resolve that to its own scope. Expressing the scope as the audience's scope will free us from this problem. Nat =3Dnat via iPhone Mar 11, 2013 10:38=E3=80=81Lewis Adam-CAL022 =E3=81=AE=E3=83=A1=E3=83=83=E3=82=BB=E3=83=BC=E3=82=B8: I would not even want to confuse audience with scope. Maybe in the simplest of cases, where there is a one-to-one mapping between scope and audience, but in reality the RS could expose multiple APIs at the same endpoint. Granted the RS could extract the audience field based on a fully qualified scope, but it just seems that claims, scopes, and audiences are each unique and should be kept that way. adam *From:* Phil Hunt [mailto:phil.hunt@oracle.com ] *Sent:* Monday, March 11, 2013 9:25 AM *To:* Nat Sakimura *Cc:* Lewis Adam-CAL022; oauth@ietf.org WG *Subject:* Re: [OAUTH-WG] JWT - scope claim missing One thing that concerns me is that scope is very different from a claim. An claim is an assertion provided that may have some level of dispute/quality etc. A scope defines what is request or what has been authorized. It's an absolute thing. Therefore it is not a claim. Audience...maybe. This is why I think scope deserves special attention/discussion in authorization assertions and in access tokens. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-03-10, at 9:17 PM, Nat Sakimura wrote: So, it is soooo late in the game: I have been completely underwater to even read the OAuth mails for about a month and slowly catching up now. Here is an I-D that I have created partly in response to the RS-AS interaction piece that was talked about at IETF 85. It does not have 'scope' and has 'claims' instead as it was based on OpenID Connect, but it is easy to add, provided that the scopes are to be understood as that of the 'aud'. http://tools.ietf.org/id/draft-sakimura-oidc-structured-token-01.txt Best, Nat 2013/3/1 Lewis Adam-CAL022 Hmmm, I=E2=80=99m not so sure. It depends where we all think OAuth is on i= ts trajectory. On one hand, OAuth has already seen an insanely massive amount of deployment. On the other hand, RESTful APIs see no sign of slowing down. Now I=E2=80=99m not going to go so far as Craig B. and say that eve= rything and everyone will be API enabled in the future, but it sure is going to be a lot. That being said, one could argue that even with all the OAuth implementation we=E2=80=99ve seen, that this is just the infancy of it. Ob= viously a WG profile of a JWT-structured AT could not deprecate other forms (unstructured, SAML, etc.) but going forward new developers may choose to embrace this, and in fact this could even be the guidance. I agree with previous comments that Justin=E2=80=99s introspection draft might be a good= place to explore this. adam *From:* Brian Campbell [mailto:bcampbell@pingidentity.com] *Sent:* Thursday, February 28, 2013 1:36 PM *To:* Lewis Adam-CAL022 *Cc:* John Bradley; oauth@ietf.org WG *Subject:* Re: [OAUTH-WG] JWT - scope claim missing I do agree that a WG profile of a JWT-structured access token could lend itself to interoperability and ultimately be a useful thing. But you are right that there already are many implementations out there in the wild (heck, I've written one myself) and that might make it difficult to standardize on something. Because of that, and many other reasons, I don't want to try and add that to existing assertion drafts. On Thu, Feb 28, 2013 at 12:13 PM, Lewis Adam-CAL022 < Adam.Lewis@motorolasolutions.com> wrote: Hi Brian, a few thoughts from somebody outside of the WG =E2=80=A6 As a newcomer to OAuth last year, I was initially confused by the titles. It was confusing because we have SAML bearer **assertions** and JWT bearer = * *tokens** =E2=80=A6 and as John just (begrudgingly) stated in this thread, = the JWT is being used as an assertion in this profile (and in OIDC). I think it will be difficult to find a good name for these profiles since they do two entirely different things (e.g. define a new grant type and define a new method of client authentication). One could argue that as long as the WG is at it, then why not add a third section to the JWT profile, which talks about usage of JWT-structured bearer access tokens: it would not be any less related than the other two focuses of the doc. Then the document could be called something simple like =E2=80=9Cprofiles of JWT usage in OAu= th=E2=80=9D or something like that. On one hand, it is probably na=C3=AFve to think that an access token can be standardized in a profile given how many have already been released into the wild, but on the other hand, a WG profile of a JWT-structured access token could lend itself to interoperability, where AS implementations can advertise conformance to the profile and who knows =E2=80=A6 maybe the RS= =E2=80=99s of the future will be good with this. adam *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf Of *Brian Campbell *Sent:* Thursday, February 28, 2013 1:03 PM *To:* John Bradley *Cc:* oauth@ietf.org WG *Subject:* Re: [OAUTH-WG] JWT - scope claim missing I'm not sure anyone really "picked" the titles for the bearer token profiles. They just kind of evolved. And evolved in funny ways especially when client authn to the AS was added. You won't hear me argue that the titles are "good" and this is not the first time there's been confusion about what they actually do. They define new grant types and new client authentication methods. They *do not* define an access token format or anything else about access tokens. JWT and SAML could be used for that but that's not what these drafts do. Suggestions for better title(s) would be more than welcome. Here's what they are now: SAML 2.0 Bearer Assertion Profiles for OAuth 2.0 draft-ietf-oauth-saml2-bearer JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0 draft-ietf-oauth-jwt-bearer Assertion Framework for OAuth 2.0 draft-ietf-oauth-assertions On Thu, Feb 28, 2013 at 11:36 AM, John Bradley wrote: Yes the title likely adds to the confusion given that the bearer tokens are not access tokens. Things as separate from OAuth as the Firefox browerID spec use JWS signed JWTs. The bearer token profiles for OAuth 2 are for OAuth2. The JSON Web Token (JWT) spec did not start in OAuth and is not OAuth specific. A JWT is: JSON Web Token (JWT) A string representing a set of claims as a JSON object that is encoded in a JWS or JWE, enabling the claims to be digitally signed or MACed and/or encrypted. So OAuth or other profiles may define claims to go in a JWT, but the JWT needs to itself only define the claims necessary for security processing. John B. PS that was a soft ball If you hadn't responded I would have been disappointed. I din't pick the title for the bearer token profiles. On 2013-02-28, at 10:12 AM, Phil Hunt wrote: JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0 Note the title says "for OAuth2" Sorry. Couldn't resist. Phil Sent from my phone. On 2013-02-28, at 9:40, John Bradley wrote: JWT is an assertion( I am probably going to regret using that word). It is used in openID connect for id_tokens, it is used in OAuth for Assertion grant types and authentication of the client to the token endpoint. http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-04 JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0 Dosen't define JWT's use for access tokens for the RS. Bottom line JWT is for more than access tokens. John B. On 2013-02-28, at 9:28 AM, Phil Hunt wrote: Are you saying jwt is not an access token type? Phil Sent from my phone. On 2013-02-28, at 8:58, John Bradley wrote: Yes, defining scope in JWT is the wrong place. JWT needs to stick to the security claims needed to process JWT. I also don't know how far you get requiring a specific authorization format for JWT, some AS will wan to use a opaque reference, some might want to use a user claim or role claim, others may use scopes, combining scopes and claims is also possible. Right now it is up to a AS RS pair to agree on how to communicate authorization. I don't want MAC to be more restrictive than bearer when it comes to authorization between AS and RS. Hannes wanted to know why JWT didn't define scope. The simple answer is that it is out of scope for JWT itself. It might be defined in a OAuth access token profile for JWT but it should not be specific to MAC. John B. On 2013-02-28, at 8:44 AM, Brian Campbell wrote: I think John's point was more that scope is something rather specific to an OAuth access token and, while JWT is can be used to represent an access token, it's not the only application of JWT. The 'standard' claims in JWT are those that are believed (right or wrong) to be widely applicable across different applications of JWT. One could argue about it but scope is probably not one of those. It would probably make sense to try and build a profile of JWT specifically for OAuth access tokens (though I suspect there are some turtles and dragons in there), which might be the appropriate place to define/register a scope claim. On Thu, Feb 28, 2013 at 9:24 AM, Phil Hunt wrote: Are you advocating TWO systems? That seems like a bad choice. I would rather fix scope than go to a two system approach. Phil Sent from my phone. On 2013-02-28, at 8:17, John Bradley wrote: > While scope is one method that a AS could communicate authorization to a RS, it is not the only or perhaps even the most likely one. > Using scope requires a relatively tight binding between the RS and AS, UMA uses a different mechanism that describes finer grained operations. > The AS may include roles, user, or other more abstract claims that the the client may (god help them) pass on to EXCML for processing. > > While having a scopes claim is possible, like any other claim it is not part of the JWT core security processing claims, and needs to be defined by extension. > > John B. > On 2013-02-28, at 2:29 AM, Hannes Tschofenig wrote: > >> Hi Mike, >> >> when I worked on the MAC specification I noticed that the JWT does not have a claim for the scope. I believe that this would be needed to allow the resource server to verify whether the scope the authorization server authorized is indeed what the client is asking for. >> >> Ciao >> Hannes >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --=20 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --f46d0408d3f7a2151604d7a8da55 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
No. I am not confusing scope with audience.=C2=A0=

There is n= o standard scope. So, the scope has to be either defined by the resource or= the authorization server.=C2=A0
Just stating scope is too vague that you will n= ot able to find out whose scope it is.=C2=A0

=
That is why I wro= te that the scope has to be understood in the context of aud.=C2=A0<= /div>
Audience is the r= esource. So what I wrote amounts to be that the scope expressed in the toke= n is what was defined by the resource and not the authorization server.=C2= =A0

=
It could be autho= rization server's scope, but then there would be a complication that th= e resource has to be able to resolve that to its own scope. Expressing the = scope as the audience's scope will free us from this problem.=C2=A0

=
Nat
<= /div>
=3Dnat via iPhone

Mar 11, 2= 013 10:38=E3=80=81Lewis Adam-CAL022 <Adam.Lewis@motorolasolutions.com> =E3=81=AE=E3=83= =A1=E3=83=83=E3=82=BB=E3=83=BC=E3=82=B8:

I would not even want to = confuse audience with scope.=C2=A0 Maybe in the simplest of cases, where th= ere is a one-to-one mapping between scope and audience, but in reality the RS could expose multiple APIs at the same endpoint.=C2=A0 Gran= ted the RS could extract the audience field based on a fully qualified scop= e, but it just seems that claims, scopes, and audiences are each unique and= should be kept that way.

=C2=A0

adam

=C2=A0

From: Phil Hun= t [mailto:phil.hunt@oracle.com]
Sent: Monday, March 11, 2013 9:25 AM
To: Nat Sakimura
Cc: Lewis Adam-CAL022; oauth@ietf.= org WG
Subject: Re: [OAUTH-WG] JWT - scope claim missing

=C2=A0

One thing that concerns me is that scope is very dif= ferent from a claim. An claim is an assertion provided that may have some l= evel of dispute/quality etc.

=C2=A0

A scope defines what is request or what has been aut= horized. =C2=A0It's an absolute thing. Therefore it is not a claim. Aud= ience...maybe.=C2=A0

=C2=A0

This is why I think scope deserves special attention= /discussion in authorization assertions and in access tokens.

=C2=A0

Phil

=C2=A0

@independentid

phil.hunt@oracle.com

=C2=A0



=C2=A0

On 2013-03-10, at 9:17 PM, Nat Sakimura wrote:



So, it is soooo late in the game: I have been comple= tely underwater to even read the OAuth mails for about a month and slowly c= atching up now.=C2=A0

=C2=A0

Here is an I-D that I have created partly in respons= e to the RS-AS interaction piece that was talked about at IETF 85.=C2=A0

It does not have 'scope' and has 'claims= ' instead as it was based on OpenID Connect, but it is easy to add, pro= vided that the scopes are to be understood as that of the 'aud'.=C2= =A0

=C2=A0

=C2=A0

Best,=C2=A0

=C2=A0

Nat

=C2=A0

2013/3/1 Lewis Adam-CAL022 <Adam.Lewis@motorolasolutio= ns.com>

Hmmm, I=E2=80=99m not= so sure.=C2=A0 It depends where we all think OAuth is on its trajectory.= =C2=A0 On one hand, OAuth has already seen an insanely massive amount of deployment.=C2=A0 On the ot= her hand, RESTful APIs see no sign of slowing down.=C2=A0=C2=A0 Now I=E2=80= =99m not going to go so far as Craig B. and say that everything and everyon= e will be API enabled in the future, but it sure is going to be a lot.=C2=A0 That being said, one could argue that even with all the= OAuth implementation we=E2=80=99ve seen, that this is just the infancy of = it.=C2=A0 Obviously a WG profile of a JWT-structured AT could not deprecate= other forms (unstructured, SAML, etc.) but going forward new developers may choose to embrace this, and in fact this could = even be the guidance. =C2=A0=C2=A0I agree with previous comments that Justi= n=E2=80=99s introspection draft might be a good place to explore this.

=C2=A0

adam

=C2=A0

From: Br= ian Campbell [mailto:bcampbell@pingidentity.com]
Sent: Thursday, February 28, 2013 1:36 PM
To: Lewis Adam-CAL022
Cc: John Bradley; oauth@ietf.org WG


Subject: Re: [OAUTH-WG] JWT - scope claim missing

=C2=A0

=C2=A0

I do agree that a WG = profile of a JWT-structured access token could lend itself to interoperabil= ity and ultimately be a useful thing. But you are right that there already = are many implementations out there in the wild (heck, I've written one myself) and that might m= ake it difficult to standardize on something.

Because of that, and many other reasons, I don= 't want to try and add that to existing assertion drafts.

=C2=A0

On Thu, Feb 28, 2013 at 12:13 PM, Lewis Adam-C= AL022 <Adam.Lewis@motorolasolutions.com> wrote:

Hi Brian, a few thoug= hts from somebody outside of the WG =E2=80=A6

=C2=A0

As a newcomer to OAut= h last year, I was initially confused by the titles.=C2=A0 It was confusing= because we have SAML bearer *assertions* and JWT bearer *tokens* =E2= =80=A6 and as John just (begrudgingly) stated in this thread, the JWT is be= ing used as an assertion in this profile (and in OIDC).=C2=A0 I think it wi= ll be difficult to find a good name for these profiles since they do two entirely different things (e.g. define a new gr= ant type and define a new method of client authentication).=C2=A0 One could= argue that as long as the WG is at it, then why not add a third section to= the JWT profile, which talks about usage of JWT-structured bearer access tokens: it would not be any less related t= han the other two focuses of the doc.=C2=A0 Then the document could be call= ed something simple like =E2=80=9Cprofiles of JWT usage in OAuth=E2=80=9D o= r something like that.=C2=A0

=C2=A0

On one hand, it is pr= obably na=C3=AFve to think that an access token can be standardized in a pr= ofile given how many have already been released into the wild, but on the other hand, = a WG profile of a JWT-structured access token could lend itself to interope= rability, where AS implementations can advertise conformance to the profile= and who knows =E2=80=A6 maybe the RS=E2=80=99s of the future will be good with this.=C2=A0

=C2=A0

adam

=C2=A0

From: oauth-bounces@i= etf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Brian Campbell
Sent: Thursday, February 28, 2013 1:03 PM
To: John Bradley
Cc: oauth@ietf.o= rg WG


Subject: Re: [OAUTH-WG] JWT - scope claim missing

=C2=A0

I'm not sure anyo= ne really "picked" the titles for the bearer token profiles. They= just kind of evolved. And evolved in funny ways especially when client aut= hn to the AS was added.

You won't hear me= argue that the titles are "good" and this is not the first time = there's been confusion about what they actually do. They define new gra= nt types and new client authentication methods. They *do not* define an access token format or anything else abou= t access tokens. JWT and SAML could be used for that but that's not wha= t these drafts do.

Suggestions for better title(s) would be more = than welcome.

=C2=A0

Here's what they are now:


SAML 2.0 Bearer Assertion Profiles for OAuth 2.0
draft-ietf-oauth-saml2-bearer

JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0
draft-ietf-oauth-jwt-bearer

Assertion Framework for OAuth 2.0
draft-ietf-oauth-assertions

=C2=A0

On Thu, Feb 28, 2013 at 11:36 AM, John Bradley= <ve7jtb@ve7jtb.c= om> wrote:

Yes the title likely adds to the confusion giv= en that the bearer tokens are not access tokens.

=C2=A0

Things as separate from OAuth as the Firefox b= rowerID spec use JWS signed JWTs. =C2=A0

=C2=A0

The bearer token profiles for OAuth 2 are for = OAuth2.

=C2=A0

The=C2=A0JSON Web Token (JWT)= =C2=A0spec did not start in OAuth and is not OAuth specific.

=C2=A0

A JWT is:

JSON Web Token (JWT)=C2=A0 A string r=
epresenting a set of claims as a JSON
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 object=
 that is encoded in a JWS or JWE, enabling the claims to be
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 digita=
lly signed or MACed and/or encrypted.

=C2=A0

So OAuth or other profiles may define claims t= o go in a JWT, but the JWT needs to itself only define the claims necessary= for security processing. =C2=A0

=C2=A0

John B.

PS that was a soft ball If you hadn't resp= onded I would have been disappointed. =C2=A0I din't pick the title for = the bearer token profiles.

=C2=A0

=C2=A0

On 2013-02-28, at 10:12 AM, Phil Hunt <phil.hunt@oracle.com<= /a>> wrote:

=C2=A0

JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0


Note the title says "for OAuth2"

=C2=A0

Sorry. Couldn't resist.=C2=A0

=C2=A0

Phil

=C2=A0

Sent from my phone.

JWT is an assertion( I am probably going to re= gret using that word).

=C2=A0

It is used in openID connect for id_tokens, it= is used in OAuth for Assertion grant types and authentication of the clien= t to the token endpoint.

=C2=A0

=C2=A0
=C2=A0

JS= ON Web Token (JWT) Bearer Token Profiles for OAuth 2.0

=C2=A0

Dosen't define JWT's use for access to= kens for the RS. =C2=A0=C2=A0

=C2=A0

Bottom line JWT is for more than access tokens= .

=C2=A0

John B.

=C2=A0

On 2013-02-28, at 9:28 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

=C2=A0

Are you saying jwt is not an access token type= ?

Phil

=C2=A0

Sent from my phone.

Yes, defining scope in JWT is the wrong place.= =C2=A0 JWT needs to stick to the security claims needed to process JWT.

=C2=A0

I also don't know how far you get requirin= g a specific authorization format for JWT, some AS will wan to use a opaque= reference, some might want to use a user claim or role claim, others may use scopes, =C2=A0combining scopes and claims is also possible.=

=C2=A0

Right now it is up to a AS RS pair to agree on= how to communicate authorization. =C2=A0 I don't want MAC to be more r= estrictive than bearer when it comes to authorization between AS and RS.

=C2=A0

Hannes wanted to know why JWT didn't defin= e scope. =C2=A0The simple answer is that it is out of scope for JWT itself.= =C2=A0 It might be defined in a OAuth access token profile for JWT but it should not be specific to MAC.

=C2=A0

John B.

On 2013-02-28, at 8:44 AM, Brian Campbell <= bcampbell@p= ingidentity.com> wrote:

=C2=A0

I think John's po= int was more that scope is something rather specific to an OAuth access tok= en and, while JWT is can be used to represent an access token, it's not= the only application of JWT. The 'standard' claims in JWT are those that are believed (= right or wrong) to be widely applicable across different applications of JW= T. One could argue about it but scope is probably not one of those.

It would probably make sense to try and build = a profile of JWT specifically for OAuth access tokens (though I suspect the= re are some turtles and dragons in there), which might be the appropriate place to define/register a scope claim.

=C2=A0

On Thu, Feb 28, 2013 at 9:24 AM, Phil Hunt <= ;phil.hunt@oracle= .com> wrote:

Are you advocating TWO systems? That seems lik= e a bad choice.

I would rather fix scope than go to a two system approach.

Phil

Sent from my phone.

On 2013-02-28, at 8:17, John Bradley <ve7jtb@ve7jtb.com> wrote:

> While scope is one method that a AS could communicate authorization to= a RS, it is not the only or perhaps even the most likely one.
> Using scope requires a relatively tight binding between the RS and AS,= =C2=A0UMA uses a different mechanism that describes finer grained operatio= ns.
> The AS may include roles, user, or other more abstract claims that the= the client may (god help them) pass on to EXCML for processing.
>
> While having a scopes claim is possible, like any other claim it is no= t part of the JWT core security processing claims, and needs to be defined = by extension.
>
> John B.
> On 2013-02-28, at 2:29 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net>= wrote:
>
>> Hi Mike,
>>
>> when I worked on the MAC specification I noticed that the JWT does= not have a claim for the scope. I believe that this would be needed to all= ow the resource server to verify whether the scope the authorization server= authorized is indeed what the client is asking for.
>>
>> Ciao
>> Hannes
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org=
>> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0


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



=C2=A0

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.= org/
@_nat_en

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

=C2=A0

--f46d0408d3f7a2151604d7a8da55-- From phil.hunt@oracle.com Mon Mar 11 10:18: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 1943E11E815A for ; Mon, 11 Mar 2013 10:18:39 -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 3Qaxl1Efy2YU for ; Mon, 11 Mar 2013 10:18:37 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id BA9FF11E811E for ; Mon, 11 Mar 2013 10:18:36 -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 r2BHIXBs010675 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 11 Mar 2013 17:18:34 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r2BHIW4X006993 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Mar 2013 17:18:33 GMT Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r2BHIW8l023048; Mon, 11 Mar 2013 12:18:32 -0500 Received: from [25.70.197.206] (/24.114.27.5) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 11 Mar 2013 10:18:29 -0700 References: <0EC2404F-E3C5-4AD1-88B4-E74AA0394DD9@gmx.net> <48FD87D1-4DF4-4289-99B7-40A515F31890@oracle.com> <3E472720-31A4-40A0-AAA4-402CF850831A@ve7jtb.com> <7127843B-D7B0-4AB6-87F1-1604D1EFFA79@oracle.com> <50DA292F-32F0-4266-8401-006AD837B775@ve7jtb.com> <59E470B10C4630419ED717AC79FCF9A948D58BEE@BY2PRD0411MB441.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A948D58DC0@BY2PRD0411MB441.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A956893F49@BY2PRD0411MB441.namprd04.prod.outlook.com>! <6618804564592604619@unknownmsgid> Mime-Version: 1.0 (1.0) In-Reply-To: <6618804564592604619@unknownmsgid> Content-Type: multipart/alternative; boundary=Apple-Mail-B02764AA-8B1C-4988-B9D0-40C9B94579B8 Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (10B146) From: Phil Hunt Date: Mon, 11 Mar 2013 13:18:07 -0400 To: Nat Sakimura X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] JWT - scope claim missing X-BeenThere: oauth@ietf.org X-Mailman-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, 11 Mar 2013 17:18:39 -0000 --Apple-Mail-B02764AA-8B1C-4988-B9D0-40C9B94579B8 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable +1. I think that is correct characterization.=20 Phil Sent from my phone. On 2013-03-11, at 12:42, Nat Sakimura wrote: > No. I am not confusing scope with audience.=20 >=20 > There is no standard scope. So, the scope has to be either defined by the r= esource or the authorization server.=20 > Just stating scope is too vague that you will not able to find out whose s= cope it is.=20 >=20 > That is why I wrote that the scope has to be understood in the context of a= ud.=20 > Audience is the resource. So what I wrote amounts to be that the scope exp= ressed in the token is what was defined by the resource and not the authoriz= ation server.=20 >=20 > It could be authorization server's scope, but then there would be a compli= cation that the resource has to be able to resolve that to its own scope. Ex= pressing the scope as the audience's scope will free us from this problem.=20= >=20 > Nat >=20 > =3Dnat via iPhone >=20 > Mar 11, 2013 10:38=E3=80=81Lewis Adam-CAL022 =E3=81=AE=E3=83=A1=E3=83=83=E3=82=BB=E3=83=BC=E3=82=B8: >=20 >> I would not even want to confuse audience with scope. Maybe in the simpl= est of cases, where there is a one-to-one mapping between scope and audience= , but in reality the RS could expose multiple APIs at the same endpoint. Gr= anted the RS could extract the audience field based on a fully qualified sco= pe, but it just seems that claims, scopes, and audiences are each unique and= should be kept that way. >> =20 >> adam >> =20 >> From: Phil Hunt [mailto:phil.hunt@oracle.com]=20 >> Sent: Monday, March 11, 2013 9:25 AM >> To: Nat Sakimura >> Cc: Lewis Adam-CAL022; oauth@ietf.org WG >> Subject: Re: [OAUTH-WG] JWT - scope claim missing >> =20 >> One thing that concerns me is that scope is very different from a claim. A= n claim is an assertion provided that may have some level of dispute/quality= etc. >> =20 >> A scope defines what is request or what has been authorized. It's an abs= olute thing. Therefore it is not a claim. Audience...maybe.=20 >> =20 >> This is why I think scope deserves special attention/discussion in author= ization assertions and in access tokens. >> =20 >> Phil >> =20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >> =20 >>=20 >>=20 >> =20 >> On 2013-03-10, at 9:17 PM, Nat Sakimura wrote: >>=20 >>=20 >> So, it is soooo late in the game: I have been completely underwater to ev= en read the OAuth mails for about a month and slowly catching up now.=20 >> =20 >> Here is an I-D that I have created partly in response to the RS-AS intera= ction piece that was talked about at IETF 85.=20 >> It does not have 'scope' and has 'claims' instead as it was based on Open= ID Connect, but it is easy to add, provided that the scopes are to be unders= tood as that of the 'aud'.=20 >> =20 >> http://tools.ietf.org/id/draft-sakimura-oidc-structured-token-01.txt >> =20 >> Best,=20 >> =20 >> Nat >> =20 >> 2013/3/1 Lewis Adam-CAL022 >> Hmmm, I=E2=80=99m not so sure. It depends where we all think OAuth is on= its trajectory. On one hand, OAuth has already seen an insanely massive am= ount of deployment. On the other hand, RESTful APIs see no sign of slowing d= own. Now I=E2=80=99m not going to go so far as Craig B. and say that every= thing and everyone will be API enabled in the future, but it sure is going t= o be a lot. That being said, one could argue that even with all the OAuth i= mplementation we=E2=80=99ve seen, that this is just the infancy of it. Obvi= ously a WG profile of a JWT-structured AT could not deprecate other forms (u= nstructured, SAML, etc.) but going forward new developers may choose to embr= ace this, and in fact this could even be the guidance. I agree with previo= us comments that Justin=E2=80=99s introspection draft might be a good place t= o explore this. >> =20 >> adam >> =20 >> From: Brian Campbell [mailto:bcampbell@pingidentity.com]=20 >> Sent: Thursday, February 28, 2013 1:36 PM >> To: Lewis Adam-CAL022 >> Cc: John Bradley; oauth@ietf.org WG >>=20 >> Subject: Re: [OAUTH-WG] JWT - scope claim missing >> =20 >> =20 >> I do agree that a WG profile of a JWT-structured access token could lend i= tself to interoperability and ultimately be a useful thing. But you are righ= t that there already are many implementations out there in the wild (heck, I= 've written one myself) and that might make it difficult to standardize on s= omething. >>=20 >> Because of that, and many other reasons, I don't want to try and add that= to existing assertion drafts. >> =20 >>=20 >> On Thu, Feb 28, 2013 at 12:13 PM, Lewis Adam-CAL022 wrote: >> Hi Brian, a few thoughts from somebody outside of the WG =E2=80=A6 >> =20 >> As a newcomer to OAuth last year, I was initially confused by the titles.= It was confusing because we have SAML bearer *assertions* and JWT bearer *= tokens* =E2=80=A6 and as John just (begrudgingly) stated in this thread, the= JWT is being used as an assertion in this profile (and in OIDC). I think i= t will be difficult to find a good name for these profiles since they do two= entirely different things (e.g. define a new grant type and define a new me= thod of client authentication). One could argue that as long as the WG is a= t it, then why not add a third section to the JWT profile, which talks about= usage of JWT-structured bearer access tokens: it would not be any less rela= ted than the other two focuses of the doc. Then the document could be calle= d something simple like =E2=80=9Cprofiles of JWT usage in OAuth=E2=80=9D or s= omething like that.=20 >> =20 >> On one hand, it is probably na=C3=AFve to think that an access token can b= e standardized in a profile given how many have already been released into t= he wild, but on the other hand, a WG profile of a JWT-structured access toke= n could lend itself to interoperability, where AS implementations can advert= ise conformance to the profile and who knows =E2=80=A6 maybe the RS=E2=80=99= s of the future will be good with this.=20 >> =20 >> adam >> =20 >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of= Brian Campbell >> Sent: Thursday, February 28, 2013 1:03 PM >> To: John Bradley >> Cc: oauth@ietf.org WG >>=20 >> Subject: Re: [OAUTH-WG] JWT - scope claim missing >> =20 >> I'm not sure anyone really "picked" the titles for the bearer token profi= les. They just kind of evolved. And evolved in funny ways especially when cl= ient authn to the AS was added. >>=20 >> You won't hear me argue that the titles are "good" and this is not the fi= rst time there's been confusion about what they actually do. They define new= grant types and new client authentication methods. They *do not* define an a= ccess token format or anything else about access tokens. JWT and SAML could b= e used for that but that's not what these drafts do. >>=20 >> Suggestions for better title(s) would be more than welcome. >> =20 >> Here's what they are now: >>=20 >> SAML 2.0 Bearer Assertion Profiles for OAuth 2.0 >> draft-ietf-oauth-saml2-bearer >>=20 >> JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0 >> draft-ietf-oauth-jwt-bearer >>=20 >> Assertion Framework for OAuth 2.0 >> draft-ietf-oauth-assertions >> =20 >> On Thu, Feb 28, 2013 at 11:36 AM, John Bradley wrote:= >> Yes the title likely adds to the confusion given that the bearer tokens a= re not access tokens. >> =20 >> Things as separate from OAuth as the Firefox browerID spec use JWS signed= JWTs. =20 >> =20 >> The bearer token profiles for OAuth 2 are for OAuth2. >> =20 >> The JSON Web Token (JWT) spec did not start in OAuth and is not OAuth spe= cific. >> =20 >> A JWT is: >> JSON Web Token (JWT) A string representing a set of claims as a JSON >> object that is encoded in a JWS or JWE, enabling the claims to be >> digitally signed or MACed and/or encrypted. >> =20 >> So OAuth or other profiles may define claims to go in a JWT, but the JWT n= eeds to itself only define the claims necessary for security processing. =20= >> =20 >> John B. >> PS that was a soft ball If you hadn't responded I would have been disappo= inted. I din't pick the title for the bearer token profiles. >> =20 >> =20 >> On 2013-02-28, at 10:12 AM, Phil Hunt wrote: >> =20 >>=20 >> JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0 >>=20 >>=20 >> Note the title says "for OAuth2" >> =20 >> Sorry. Couldn't resist.=20 >> =20 >> Phil >> =20 >> Sent from my phone. >>=20 >> On 2013-02-28, at 9:40, John Bradley wrote: >>=20 >> JWT is an assertion( I am probably going to regret using that word). >> =20 >> It is used in openID connect for id_tokens, it is used in OAuth for Asser= tion grant types and authentication of the client to the token endpoint. >> http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-04 >> =20 >> =20 >> =20 >> JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0 >>=20 >> =20 >> Dosen't define JWT's use for access tokens for the RS. =20 >> =20 >> Bottom line JWT is for more than access tokens. >> =20 >> John B. >> =20 >> On 2013-02-28, at 9:28 AM, Phil Hunt wrote: >> =20 >>=20 >> Are you saying jwt is not an access token type? >>=20 >> Phil >> =20 >> Sent from my phone. >>=20 >> On 2013-02-28, at 8:58, John Bradley wrote: >>=20 >> Yes, defining scope in JWT is the wrong place. JWT needs to stick to th= e security claims needed to process JWT. >> =20 >> I also don't know how far you get requiring a specific authorization form= at for JWT, some AS will wan to use a opaque reference, some might want to u= se a user claim or role claim, others may use scopes, combining scopes and c= laims is also possible. >> =20 >> Right now it is up to a AS RS pair to agree on how to communicate authori= zation. I don't want MAC to be more restrictive than bearer when it comes t= o authorization between AS and RS. >> =20 >> Hannes wanted to know why JWT didn't define scope. The simple answer is t= hat it is out of scope for JWT itself. It might be defined in a OAuth acce= ss token profile for JWT but it should not be specific to MAC. >> =20 >> John B. >> On 2013-02-28, at 8:44 AM, Brian Campbell wr= ote: >> =20 >>=20 >> I think John's point was more that scope is something rather specific to a= n OAuth access token and, while JWT is can be used to represent an access to= ken, it's not the only application of JWT. The 'standard' claims in JWT are t= hose that are believed (right or wrong) to be widely applicable across diffe= rent applications of JWT. One could argue about it but scope is probably not= one of those. >>=20 >> It would probably make sense to try and build a profile of JWT specifical= ly for OAuth access tokens (though I suspect there are some turtles and drag= ons in there), which might be the appropriate place to define/register a sco= pe claim. >> =20 >>=20 >> On Thu, Feb 28, 2013 at 9:24 AM, Phil Hunt wrote: >> Are you advocating TWO systems? That seems like a bad choice. >>=20 >> I would rather fix scope than go to a two system approach. >>=20 >> Phil >>=20 >> Sent from my phone. >>=20 >> On 2013-02-28, at 8:17, John Bradley wrote: >>=20 >> > While scope is one method that a AS could communicate authorization to a= RS, it is not the only or perhaps even the most likely one. >> > Using scope requires a relatively tight binding between the RS and AS, = UMA uses a different mechanism that describes finer grained operations. >> > The AS may include roles, user, or other more abstract claims that the t= he client may (god help them) pass on to EXCML for processing. >> > >> > While having a scopes claim is possible, like any other claim it is not= part of the JWT core security processing claims, and needs to be defined by= extension. >> > >> > John B. >> > On 2013-02-28, at 2:29 AM, Hannes Tschofenig wrote: >> > >> >> Hi Mike, >> >> >> >> when I worked on the MAC specification I noticed that the JWT does not= have a claim for the scope. I believe that this would be needed to allow th= e resource server to verify whether the scope the authorization server autho= rized is indeed what the client is asking for. >> >> >> >> Ciao >> >> Hannes >> >> >> >> _______________________________________________ >> >> OAuth mailing list >> >> OAuth@ietf.org >> >> https://www.ietf.org/mailman/listinfo/oauth >> > >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/oauth >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> =20 >> =20 >> =20 >> =20 >> =20 >> =20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >>=20 >> =20 >> --=20 >> Nat Sakimura (=3Dnat) >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-B02764AA-8B1C-4988-B9D0-40C9B94579B8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
+1. I think that is correct characteri= zation. 

Phil

Sent from my phone.

On 2013-03-11, at 12:42, Nat Sakimura <sakimura@gmail.com> wrote:

No. I am not confusing scope with audience. 

There is no= standard scope. So, the scope has to be either defined by the resource or t= he authorization server. 
Just stating scope is too vague that you will not a= ble to find out whose scope it is. 

<= div>That is why I wrote= that the scope has to be understood in the context of aud. 
Audience is the re= source. So what I wrote amounts to be that the scope expressed in the token i= s what was defined by the resource and not the authorization server. 

<= div>It could be authori= zation server's scope, but then there would be a complication that the resou= rce has to be able to resolve that to its own scope. Expressing the scope as= the audience's scope will free us from this problem. 

<= div>Nat

=3Dnat via iPhone

Ma= r 11, 2013 10:38=E3=80=81Lewis Adam-CAL022 <Adam.Lewis@motorolasolutions.com> =E3=81=AE=E3= =83=A1=E3=83=83=E3=82=BB=E3=83=BC=E3=82=B8:

I would not even want to co= nfuse audience with scope.  Maybe in the simplest of cases, where there= is a one-to-one mapping between scope and audience, but in reality the RS could expose multiple APIs at the same endpoint.  Grant= ed the RS could extract the audience field based on a fully qualified scope,= but it just seems that claims, scopes, and audiences are each unique and sh= ould be kept that way.

 

adam

 

From: Phil Hunt [= mailto:phil.hunt@oracle.com]
Sent: Monday, March 11, 2013 9:25 AM
To: Nat Sakimura
Cc: Lewis Adam-CAL022; oauth@ietf.o= rg WG
Subject: Re: [OAUTH-WG] JWT - scope claim missing

 

One thing that concerns me is that scope is very diff= erent from a claim. An claim is an assertion provided that may have some lev= el of dispute/quality etc.

 

A scope defines what is request or what has been auth= orized.  It's an absolute thing. Therefore it is not a claim. Audience.= ..maybe. 

 

This is why I think scope deserves special attention/= discussion in authorization assertions and in access tokens.

 

Phil

 

@independentid

phil.hunt@oracle.com<= /p>

 



 

On 2013-03-10, at 9:17 PM, Nat Sakimura wrote:



So, it is soooo late in the game: I have been complet= ely underwater to even read the OAuth mails for about a month and slowly cat= ching up now. 

 

Here is an I-D that I have created partly in response= to the RS-AS interaction piece that was talked about at IETF 85. 

It does not have 'scope' and has 'claims' instead as i= t was based on OpenID Connect, but it is easy to add, provided that the scop= es are to be understood as that of the 'aud'. 

 

 

Best, 

 

Nat

 

2013/3/1 Lewis Adam-CAL022 <Adam.Lewis@motorolasolutions= .com>

Hmmm, I=E2=80=99m n= ot so sure.  It depends where we all think OAuth is on its trajectory.&= nbsp; On one hand, OAuth has already seen an insanely massive amount of deployment.  On the oth= er hand, RESTful APIs see no sign of slowing down.   Now I=E2=80=99= m not going to go so far as Craig B. and say that everything and everyone wi= ll be API enabled in the future, but it sure is going to be a lot.  That being said, one could argue that even with all the O= Auth implementation we=E2=80=99ve seen, that this is just the infancy of it.=   Obviously a WG profile of a JWT-structured AT could not deprecate oth= er forms (unstructured, SAML, etc.) but going forward new developers may choose to embrace this, and in fact this could e= ven be the guidance.   I agree with previous comments that Justin=E2= =80=99s introspection draft might be a good place to explore this.

 

adam

 

From: Br= ian Campbell [mailto:bcampbell@pingidentity.com]
Sent: Thursday, February 28, 2013 1:36 PM
To: Lewis Adam-CAL022
Cc: John Bradley; oauth@ietf.org WG


Subject: Re: [OAUTH-WG] JWT - scope claim missing

 

 

I do agree that a WG p= rofile of a JWT-structured access token could lend itself to interoperabilit= y and ultimately be a useful thing. But you are right that there already are= many implementations out there in the wild (heck, I've written one myself) and that might make i= t difficult to standardize on something.

Because of that, and many other reasons, I= don't want to try and add that to existing assertion drafts.

 

On Thu, Feb 28, 2013 at 12:13 PM, Lewis Ad= am-CAL022 <Adam.Lewis@motorolasolutions.com> wrote:

Hi Brian, a few th= oughts from somebody outside of the WG =E2=80=A6

 

As a newcomer to O= Auth last year, I was initially confused by the titles.  It was confusi= ng because we have SAML bearer *assertions* and JWT bearer *tokens* =E2=80= =A6 and as John just (begrudgingly) stated in this thread, the JWT is being u= sed as an assertion in this profile (and in OIDC).  I think it will be d= ifficult to find a good name for these profiles since they do two entirely different things (e.g. define a new gra= nt type and define a new method of client authentication).  One could a= rgue that as long as the WG is at it, then why not add a third section to th= e JWT profile, which talks about usage of JWT-structured bearer access tokens: it would not be any less related th= an the other two focuses of the doc.  Then the document could be called= something simple like =E2=80=9Cprofiles of JWT usage in OAuth=E2=80=9D or s= omething like that. 

 

On one hand, it is= probably na=C3=AFve to think that an access token can be standardized in a p= rofile given how many have already been released into the wild, but on the other hand, a= WG profile of a JWT-structured access token could lend itself to interopera= bility, where AS implementations can advertise conformance to the profile an= d who knows =E2=80=A6 maybe the RS=E2=80=99s of the future will be good with this. 

 

adam

 

From: oauth-bounces@ie= tf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Brian Campbell
Sent: Thursday, February 28, 2013 1:03 PM
To: John Bradley
Cc: oauth@ietf.or= g WG


Subject: Re: [OAUTH-WG] JWT - scope claim missing

 

I'm not sure anyone re= ally "picked" the titles for the bearer token profiles. They just kind of ev= olved. And evolved in funny ways especially when client authn to the AS was a= dded.

You won't hear me argu= e that the titles are "good" and this is not the first time there's been con= fusion about what they actually do. They define new grant types and new clie= nt authentication methods. They *do not* define an access token format or anything else about= access tokens. JWT and SAML could be used for that but that's not what thes= e drafts do.

Suggestions for better title(s) would be m= ore than welcome.

 

Here's what they are now:


SAML 2.0 Bearer Assertion Profiles for OAuth 2.0
draft-ietf-oauth-saml2-bearer

JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0
draft-ietf-oauth-jwt-bearer

Assertion Framework for OAuth 2.0
draft-ietf-oauth-assertions

 

On Thu, Feb 28, 2013 at 11:36 AM, John Bra= dley <ve7jtb@ve7jt= b.com> wrote:

Yes the title likely adds to the confusion= given that the bearer tokens are not access tokens.

 

Things as separate from OAuth as the Firef= ox browerID spec use JWS signed JWTs.  

 

The bearer token profiles for OAuth 2 are f= or OAuth2.

 

The JSON Web Token (J= WT) spec did not start in OAuth and is not OAuth specific.

 

A JWT is:

JSON Web Token (JWT)  A string re=
presenting a set of claims as a JSON
      object t=
hat is encoded in a JWS or JWE, enabling the claims to be
      digital=
ly signed or MACed and/or encrypted.

 

So OAuth or other profiles may define clai= ms to go in a JWT, but the JWT needs to itself only define the claims necess= ary for security processing.  

 

John B.

PS that was a soft ball If you hadn't resp= onded I would have been disappointed.  I din't pick the title for the b= earer token profiles.

 

 

On 2013-02-28, at 10:12 AM, Phil Hunt <= phil.hunt@oracle.c= om> wrote:

 

JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0


Note the title says "for OAuth2"

 

Sorry. Couldn't resist. 

 

Phil

 

Sent from my phone.


On 2013-02-28, at 9:40, John Bradley <ve7jtb@ve7jtb.com> wrote:

JWT is an assertion( I am probably going t= o regret using that word).

 

It is used in openID connect for id_tokens= , it is used in OAuth for Assertion grant types and authentication of the cl= ient to the token endpoint.

 

 
 

JSO= N Web Token (JWT) Bearer Token Profiles for OAuth 2.0

 

Dosen't define JWT's use for access tokens= for the RS.   

 

Bottom line JWT is for more than access to= kens.

 

John B.

 

On 2013-02-28, at 9:28 AM, Phil Hunt <<= a href=3D"mailto:phil.hunt@oracle.com" target=3D"_blank">phil.hunt@oracle.co= m> wrote:

 

Are you saying jwt is not an access token t= ype?

Phil

 

Sent from my phone.


On 2013-02-28, at 8:58, John Bradley <ve7jtb@ve7jtb.com> wrote:

Yes, defining scope in JWT is the wrong pl= ace.   JWT needs to stick to the security claims needed to process JWT.=

 

I also don't know how far you get requirin= g a specific authorization format for JWT, some AS will wan to use a opaque r= eference, some might want to use a user claim or role claim, others may use scopes,  combining scopes and claims is also possible.<= /p>

 

Right now it is up to a AS RS pair to agre= e on how to communicate authorization.   I don't want MAC to be more re= strictive than bearer when it comes to authorization between AS and RS.

 

Hannes wanted to know why JWT didn't defin= e scope.  The simple answer is that it is out of scope for JWT itself. &= nbsp; It might be defined in a OAuth access token profile for JWT but it should not be specific to MAC.

 

John B.

On 2013-02-28, at 8:44 AM, Brian Campbell &= lt;bcampbell= @pingidentity.com> wrote:

 

I think John's point w= as more that scope is something rather specific to an OAuth access token and= , while JWT is can be used to represent an access token, it's not the only a= pplication of JWT. The 'standard' claims in JWT are those that are believed (right or w= rong) to be widely applicable across different applications of JWT. One coul= d argue about it but scope is probably not one of those.

It would probably make sense to try and bu= ild a profile of JWT specifically for OAuth access tokens (though I suspect t= here are some turtles and dragons in there), which might be the appropriate place to define/register a scope claim.

 

On Thu, Feb 28, 2013 at 9:24 AM, Phil Hunt= <phil.hunt@ora= cle.com> wrote:

Are you advocating TWO systems? That seems= like a bad choice.

I would rather fix scope than go to a two system approach.

Phil

Sent from my phone.

On 2013-02-28, at 8:17, John Bradley <ve7jtb@ve7jtb.com> wrote:

> While scope is one method that a AS could communicate authorization to a= RS, it is not the only or perhaps even the most likely one.
> Using scope requires a relatively tight binding between the RS and AS, &= nbsp;UMA uses a different mechanism that describes finer grained operations.=
> The AS may include roles, user, or other more abstract claims that the t= he client may (god help them) pass on to EXCML for processing.
>
> While having a scopes claim is possible, like any other claim it is not= part of the JWT core security processing claims, and needs to be defined by= extension.
>
> John B.
> On 2013-02-28, at 2:29 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> w= rote:
>
>> Hi Mike,
>>
>> when I worked on the MAC specification I noticed that the JWT does n= ot have a claim for the scope. I believe that this would be needed to allow t= he resource server to verify whether the scope the authorization server auth= orized is indeed what the client is asking for.
>>
>> Ciao
>> Hannes
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org<= /a>
>> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org<= br> > 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
ht= tps://www.ietf.org/mailman/listinfo/oauth



 

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.o= rg/
@_nat_en

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

 

____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth
= --Apple-Mail-B02764AA-8B1C-4988-B9D0-40C9B94579B8-- From eve@xmlgrrl.com Mon Mar 11 10:23: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 91B7F11E8169 for ; Mon, 11 Mar 2013 10:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.292 X-Spam-Level: X-Spam-Status: No, score=-1.292 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_DOMAIN_NOVOWEL=0.5, HTML_MESSAGE=0.001, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MBbW5mwTfF-8 for ; Mon, 11 Mar 2013 10:23:03 -0700 (PDT) Received: from mail.promanage-inc.com (eliasisrael.com [50.47.36.5]) by ietfa.amsl.com (Postfix) with ESMTP id 152441F0C52 for ; Mon, 11 Mar 2013 10:23:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.promanage-inc.com (Postfix) with ESMTP id 1BC3CD3C997; Mon, 11 Mar 2013 10:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at promanage-inc.com Received: from mail.promanage-inc.com ([127.0.0.1]) by localhost (greendome.promanage-inc.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jREY3v6AAka9; Mon, 11 Mar 2013 10:22:57 -0700 (PDT) Received: from [192.168.168.111] (unknown [192.168.168.111]) by mail.promanage-inc.com (Postfix) with ESMTPSA id 7EB44D3C97A; Mon, 11 Mar 2013 10:22:57 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_966021A6-3A5C-480F-9810-884BC608C229" From: Eve Maler In-Reply-To: <6618804564592604619@unknownmsgid> Date: Mon, 11 Mar 2013 10:22:57 -0700 Message-Id: References: <0EC2404F-E3C5-4AD1-88B4-E74AA0394DD9@gmx.net> <48FD87D1-4DF4-4289-99B7-40A515F31890@oracle.com> <3E472720-31A4-40A0-AAA4-402CF850831A@ve7jtb.com> <7127843B-D7B0-4AB6-87F1-1604D1EFFA79@oracle.com> <50DA292F-32F0-4266-8401-006AD837B775@ve7jtb.com> <59E470B10C4630419ED717AC79FCF9A948D58BEE@BY2PRD0411MB441.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A948D58DC0@BY2PRD0411MB441.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A956893F49@BY2PRD0411MB441.namprd04.prod.outlook.com> <6618804 564592604619@unknownmsgid> To: Nat Sakimura X-Mailer: Apple Mail (2.1499) Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] JWT - scope claim missing X-BeenThere: oauth@ietf.org X-Mailman-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, 11 Mar 2013 17:23:06 -0000 --Apple-Mail=_966021A6-3A5C-480F-9810-884BC608C229 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Just a (perennial) reminder from me that scopes are proprietary strings = in core OAuth, but the UMA folks have proposed a way to standardize them = because we needed to: http://tools.ietf.org/html/draft-hardjono-oauth-resource-reg-00 (pretty-printed, slightly updated version here: = http://docs.kantarainitiative.org/uma/draft-oauth-resource-reg.html ) It's possible to treat the data associated with a token as orthogonal to = the way it is delivered to the RS. UMA's default token profile chooses = to require the RS to ask the AS at run time for that data ("artifact" = pattern using Justin's introspection spec), and defines a format that is = not JWT-based, but rather conveys permissions/entitlements to the RS. = But all kinds of choices are possible: - Format: JWT attribute-type claims. Conveyance: signed and locally = verifiable by RS. - Format: JWT attribute-type claims. Conveyance: artifact/introspection = pattern. - Format: XACML-type authorization decision. Conveyance: signed and = locally verifiable by RS. etc. This separation is UMA's preference since it already has a non-JWT-style = set of JSON-based authorization data, which has scopes in it but of the = interoperable UMA sort, not the hot-mess OAuth sort. :-) The UMA spec = even has an extensibility point for defining new token profiles in an = interoperable manner. Eve On 11 Mar 2013, at 9:42 AM, Nat Sakimura wrote: > No. I am not confusing scope with audience.=20 >=20 > There is no standard scope. So, the scope has to be either defined by = the resource or the authorization server.=20 > Just stating scope is too vague that you will not able to find out = whose scope it is.=20 >=20 > That is why I wrote that the scope has to be understood in the context = of aud.=20 > Audience is the resource. So what I wrote amounts to be that the scope = expressed in the token is what was defined by the resource and not the = authorization server.=20 >=20 > It could be authorization server's scope, but then there would be a = complication that the resource has to be able to resolve that to its own = scope. Expressing the scope as the audience's scope will free us from = this problem.=20 >=20 > Nat >=20 > =3Dnat via iPhone >=20 > Mar 11, 2013 10:38=E3=80=81Lewis Adam-CAL022 = =E3=81=AE=E3=83=A1=E3=83=83=E3=82=BB=E3= =83=BC=E3=82=B8: >=20 >> I would not even want to confuse audience with scope. Maybe in the = simplest of cases, where there is a one-to-one mapping between scope and = audience, but in reality the RS could expose multiple APIs at the same = endpoint. Granted the RS could extract the audience field based on a = fully qualified scope, but it just seems that claims, scopes, and = audiences are each unique and should be kept that way. >> =20 >> adam >> =20 >> From: Phil Hunt [mailto:phil.hunt@oracle.com]=20 >> Sent: Monday, March 11, 2013 9:25 AM >> To: Nat Sakimura >> Cc: Lewis Adam-CAL022; oauth@ietf.org WG >> Subject: Re: [OAUTH-WG] JWT - scope claim missing >> =20 >> One thing that concerns me is that scope is very different from a = claim. An claim is an assertion provided that may have some level of = dispute/quality etc. >> =20 >> A scope defines what is request or what has been authorized. It's an = absolute thing. Therefore it is not a claim. Audience...maybe.=20 >> =20 >> This is why I think scope deserves special attention/discussion in = authorization assertions and in access tokens. >> =20 >> Phil >> =20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >> =20 >>=20 >>=20 >> =20 >> On 2013-03-10, at 9:17 PM, Nat Sakimura wrote: >>=20 >>=20 >> So, it is soooo late in the game: I have been completely underwater = to even read the OAuth mails for about a month and slowly catching up = now.=20 >> =20 >> Here is an I-D that I have created partly in response to the RS-AS = interaction piece that was talked about at IETF 85.=20 >> It does not have 'scope' and has 'claims' instead as it was based on = OpenID Connect, but it is easy to add, provided that the scopes are to = be understood as that of the 'aud'.=20 >> =20 >> http://tools.ietf.org/id/draft-sakimura-oidc-structured-token-01.txt >> =20 >> Best,=20 >> =20 >> Nat >> =20 >> 2013/3/1 Lewis Adam-CAL022 >> Hmmm, I=E2=80=99m not so sure. It depends where we all think OAuth = is on its trajectory. On one hand, OAuth has already seen an insanely = massive amount of deployment. On the other hand, RESTful APIs see no = sign of slowing down. Now I=E2=80=99m not going to go so far as Craig = B. and say that everything and everyone will be API enabled in the = future, but it sure is going to be a lot. That being said, one could = argue that even with all the OAuth implementation we=E2=80=99ve seen, = that this is just the infancy of it. Obviously a WG profile of a = JWT-structured AT could not deprecate other forms (unstructured, SAML, = etc.) but going forward new developers may choose to embrace this, and = in fact this could even be the guidance. I agree with previous = comments that Justin=E2=80=99s introspection draft might be a good place = to explore this. >> =20 >> adam >> =20 >> From: Brian Campbell [mailto:bcampbell@pingidentity.com]=20 >> Sent: Thursday, February 28, 2013 1:36 PM >> To: Lewis Adam-CAL022 >> Cc: John Bradley; oauth@ietf.org WG >>=20 >> Subject: Re: [OAUTH-WG] JWT - scope claim missing >> =20 >> =20 >> I do agree that a WG profile of a JWT-structured access token could = lend itself to interoperability and ultimately be a useful thing. But = you are right that there already are many implementations out there in = the wild (heck, I've written one myself) and that might make it = difficult to standardize on something. >>=20 >> Because of that, and many other reasons, I don't want to try and add = that to existing assertion drafts. >> =20 >> On Thu, Feb 28, 2013 at 12:13 PM, Lewis Adam-CAL022 = wrote: >> Hi Brian, a few thoughts from somebody outside of the WG =E2=80=A6 >> =20 >> As a newcomer to OAuth last year, I was initially confused by the = titles. It was confusing because we have SAML bearer *assertions* and = JWT bearer *tokens* =E2=80=A6 and as John just (begrudgingly) stated in = this thread, the JWT is being used as an assertion in this profile (and = in OIDC). I think it will be difficult to find a good name for these = profiles since they do two entirely different things (e.g. define a new = grant type and define a new method of client authentication). One could = argue that as long as the WG is at it, then why not add a third section = to the JWT profile, which talks about usage of JWT-structured bearer = access tokens: it would not be any less related than the other two = focuses of the doc. Then the document could be called something simple = like =E2=80=9Cprofiles of JWT usage in OAuth=E2=80=9D or something like = that.=20 >> =20 >> On one hand, it is probably na=C3=AFve to think that an access token = can be standardized in a profile given how many have already been = released into the wild, but on the other hand, a WG profile of a = JWT-structured access token could lend itself to interoperability, where = AS implementations can advertise conformance to the profile and who = knows =E2=80=A6 maybe the RS=E2=80=99s of the future will be good with = this.=20 >> =20 >> adam >> =20 >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf Of Brian Campbell >> Sent: Thursday, February 28, 2013 1:03 PM >> To: John Bradley >> Cc: oauth@ietf.org WG >>=20 >> Subject: Re: [OAUTH-WG] JWT - scope claim missing >> =20 >> I'm not sure anyone really "picked" the titles for the bearer token = profiles. They just kind of evolved. And evolved in funny ways = especially when client authn to the AS was added. >>=20 >> You won't hear me argue that the titles are "good" and this is not = the first time there's been confusion about what they actually do. They = define new grant types and new client authentication methods. They *do = not* define an access token format or anything else about access tokens. = JWT and SAML could be used for that but that's not what these drafts do. >>=20 >> Suggestions for better title(s) would be more than welcome. >> =20 >> Here's what they are now: >>=20 >> SAML 2.0 Bearer Assertion Profiles for OAuth 2.0 >> draft-ietf-oauth-saml2-bearer >>=20 >> JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0 >> draft-ietf-oauth-jwt-bearer >>=20 >> Assertion Framework for OAuth 2.0 >> draft-ietf-oauth-assertions >> =20 >> On Thu, Feb 28, 2013 at 11:36 AM, John Bradley = wrote: >> Yes the title likely adds to the confusion given that the bearer = tokens are not access tokens. >> =20 >> Things as separate from OAuth as the Firefox browerID spec use JWS = signed JWTs. =20 >> =20 >> The bearer token profiles for OAuth 2 are for OAuth2. >> =20 >> The JSON Web Token (JWT) spec did not start in OAuth and is not OAuth = specific. >> =20 >> A JWT is: >> JSON Web Token (JWT) A string representing a set of claims as a JSON >> object that is encoded in a JWS or JWE, enabling the claims to = be >> digitally signed or MACed and/or encrypted. >> =20 >> So OAuth or other profiles may define claims to go in a JWT, but the = JWT needs to itself only define the claims necessary for security = processing. =20 >> =20 >> John B. >> PS that was a soft ball If you hadn't responded I would have been = disappointed. I din't pick the title for the bearer token profiles. >> =20 >> =20 >> On 2013-02-28, at 10:12 AM, Phil Hunt wrote: >> =20 >> JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0 >>=20 >>=20 >> Note the title says "for OAuth2" >> =20 >> Sorry. Couldn't resist.=20 >> =20 >> Phil >> =20 >> Sent from my phone. >>=20 >> On 2013-02-28, at 9:40, John Bradley wrote: >>=20 >> JWT is an assertion( I am probably going to regret using that word). >> =20 >> It is used in openID connect for id_tokens, it is used in OAuth for = Assertion grant types and authentication of the client to the token = endpoint. >> http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-04 >> =20 >> =20 >> =20 >> JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0 >>=20 >> =20 >> Dosen't define JWT's use for access tokens for the RS. =20 >> =20 >> Bottom line JWT is for more than access tokens. >> =20 >> John B. >> =20 >> On 2013-02-28, at 9:28 AM, Phil Hunt wrote: >> =20 >> Are you saying jwt is not an access token type? >>=20 >> Phil >> =20 >> Sent from my phone. >>=20 >> On 2013-02-28, at 8:58, John Bradley wrote: >>=20 >> Yes, defining scope in JWT is the wrong place. JWT needs to stick = to the security claims needed to process JWT. >> =20 >> I also don't know how far you get requiring a specific authorization = format for JWT, some AS will wan to use a opaque reference, some might = want to use a user claim or role claim, others may use scopes, = combining scopes and claims is also possible. >> =20 >> Right now it is up to a AS RS pair to agree on how to communicate = authorization. I don't want MAC to be more restrictive than bearer = when it comes to authorization between AS and RS. >> =20 >> Hannes wanted to know why JWT didn't define scope. The simple answer = is that it is out of scope for JWT itself. It might be defined in a = OAuth access token profile for JWT but it should not be specific to MAC. >> =20 >> John B. >> On 2013-02-28, at 8:44 AM, Brian Campbell = wrote: >> =20 >> I think John's point was more that scope is something rather specific = to an OAuth access token and, while JWT is can be used to represent an = access token, it's not the only application of JWT. The 'standard' = claims in JWT are those that are believed (right or wrong) to be widely = applicable across different applications of JWT. One could argue about = it but scope is probably not one of those. >>=20 >> It would probably make sense to try and build a profile of JWT = specifically for OAuth access tokens (though I suspect there are some = turtles and dragons in there), which might be the appropriate place to = define/register a scope claim. >> =20 >> On Thu, Feb 28, 2013 at 9:24 AM, Phil Hunt = wrote: >> Are you advocating TWO systems? That seems like a bad choice. >>=20 >> I would rather fix scope than go to a two system approach. >>=20 >> Phil >>=20 >> Sent from my phone. >>=20 >> On 2013-02-28, at 8:17, John Bradley wrote: >>=20 >> > While scope is one method that a AS could communicate authorization = to a RS, it is not the only or perhaps even the most likely one. >> > Using scope requires a relatively tight binding between the RS and = AS, UMA uses a different mechanism that describes finer grained = operations. >> > The AS may include roles, user, or other more abstract claims that = the the client may (god help them) pass on to EXCML for processing. >> > >> > While having a scopes claim is possible, like any other claim it is = not part of the JWT core security processing claims, and needs to be = defined by extension. >> > >> > John B. >> > On 2013-02-28, at 2:29 AM, Hannes Tschofenig = wrote: >> > >> >> Hi Mike, >> >> >> >> when I worked on the MAC specification I noticed that the JWT does = not have a claim for the scope. I believe that this would be needed to = allow the resource server to verify whether the scope the authorization = server authorized is indeed what the client is asking for. >> >> >> >> Ciao >> >> Hannes >> >> >> >> _______________________________________________ >> >> OAuth mailing list >> >> OAuth@ietf.org >> >> https://www.ietf.org/mailman/listinfo/oauth >> > >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/oauth >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> =20 >> =20 >> =20 >> =20 >> =20 >> =20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >>=20 >> =20 >> --=20 >> Nat Sakimura (=3Dnat) >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl --Apple-Mail=_966021A6-3A5C-480F-9810-884BC608C229 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 h= ttp://tools.ietf.org/html/draft-hardjono-oauth-resource-reg-00
(pretty-printed, slightly updated version here: http://docs.kantarainitiative.org/uma/draft-oauth-resource-reg.html= )

It's possible to treat the data associated = with a token as orthogonal to the way it is delivered to the RS. UMA's = default token profile chooses to require the RS to ask the AS at run = time for that data ("artifact" pattern using Justin's introspection = spec), and defines a format that is not JWT-based, but rather conveys = permissions/entitlements to the RS. But all kinds of choices are = possible:

- Format: JWT attribute-type claims. = Conveyance: signed and locally verifiable by RS.
- Format: JWT = attribute-type claims. Conveyance: artifact/introspection = pattern.
- Format: XACML-type authorization decision. = Conveyance: signed and locally verifiable by = RS.
etc.

This separation is UMA's = preference since it already has a non-JWT-style set of JSON-based = authorization data, which has scopes in it but of the interoperable UMA = sort, not the hot-mess OAuth sort. :-) The UMA spec even has an = extensibility point for defining new token profiles in an interoperable = manner.

Eve

On 11 Mar = 2013, at 9:42 AM, Nat Sakimura <sakimura@gmail.com> = wrote:

No. I am not confusing = scope with audience. 

There = is no standard scope. So, the scope has to be either defined by the = resource or the authorization server. 
Just stating scope is too = vague that you will not able to find out whose scope it = is. 

That is why I wrote that = the scope has to be understood in the context of aud. 
Audience is = the resource. So what I wrote amounts to be that the scope expressed in = the token is what was defined by the resource and not the authorization = server. 

It could be = authorization server's scope, but then there would be a complication = that the resource has to be able to resolve that to its own scope. = Expressing the scope as the audience's scope will free us from this = problem. 

Nat

<= span style=3D"">=3Dnat via iPhone

Mar = 11, 2013 10:38=E3=80=81Lewis Adam-CAL022 <Adam.Lewis@motorolasoluti= ons.com> =E3=81=AE=E3=83=A1=E3=83=83=E3=82=BB=E3=83=BC=E3=82=B8:

I would not even want to confuse audience with = scope.  Maybe in the simplest of cases, where there is a one-to-one = mapping between scope and audience, but in reality the RS could expose multiple APIs at the same endpoint.  = Granted the RS could extract the audience field based on a fully = qualified scope, but it just seems that claims, scopes, and audiences = are each unique and should be kept that way.

 

adam

 

From: Phil Hunt [mailto:phil.hunt@oracle.com]
Sent: Monday, March 11, 2013 9:25 AM
To: Nat Sakimura
Cc: Lewis Adam-CAL022; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] JWT - scope claim missing

 

One thing that concerns me is that scope is very = different from a claim. An claim is an assertion provided that may have = some level of dispute/quality etc.

 

A scope defines what is request or what has = been authorized.  It's an absolute thing. Therefore it is not a = claim. Audience...maybe. 

 

This is why I think scope deserves special = attention/discussion in authorization assertions and in access = tokens.

 
 



 

On 2013-03-10, at 9:17 PM, Nat Sakimura = wrote:



So, it is soooo late in the game: I have been = completely underwater to even read the OAuth mails for about a month and = slowly catching up now. 

 

Here is an I-D that I have created partly in = response to the RS-AS interaction piece that was talked about at IETF = 85. 

It does not have 'scope' and has 'claims' = instead as it was based on OpenID Connect, but it is easy to add, = provided that the scopes are to be understood as that of the = 'aud'. 

 
 

Best, 

 

Nat

 

2013/3/1 Lewis Adam-CAL022 <Adam.Lewis@motorolasolutions.com>

Hmmm, I=E2=80=99m not so = sure.  It depends where we all think OAuth is on its = trajectory.  On one hand, OAuth has already seen an insanely massive amount of deployment.  On the = other hand, RESTful APIs see no sign of slowing down.   Now = I=E2=80=99m not going to go so far as Craig B. and say that everything = and everyone will be API enabled in the future, but it sure is going to be a lot.  That being said, one could argue that even with all = the OAuth implementation we=E2=80=99ve seen, that this is just the = infancy of it.  Obviously a WG profile of a JWT-structured AT could = not deprecate other forms (unstructured, SAML, etc.) but going forward new developers may choose to embrace this, and in fact this = could even be the guidance.   I agree with previous comments = that Justin=E2=80=99s introspection draft might be a good place to = explore this.

 

adam

 

From: Brian Campbell [mailto:bcampbell@pingidentity.com]
Sent: Thursday, February 28, 2013 1:36 PM
To: Lewis Adam-CAL022
Cc: John Bradley; oauth@ietf.org WG


Subject: Re: [OAUTH-WG] JWT - scope claim missing

 
 

I do agree = that a WG profile of a JWT-structured access token could lend itself to = interoperability and ultimately be a useful thing. But you are right = that there already are many implementations out there in the wild (heck, I've written one myself) and that might = make it difficult to standardize on something.

Because of that, and many other = reasons, I don't want to try and add that to existing assertion = drafts.

 

On Thu, Feb 28, 2013 at 12:13 PM, = Lewis Adam-CAL022 <Adam.Lewis@motorolasolutions.com> wrote:

Hi Brian, a few thoughts = from somebody outside of the WG =E2=80=A6

 

As a newcomer to OAuth last = year, I was initially confused by the titles.  It was confusing = because we have SAML bearer *assertions* and JWT bearer *tokens* = =E2=80=A6 and as John just (begrudgingly) stated in this thread, the JWT = is being used as an assertion in this profile (and in OIDC).  I = think it will be difficult to find a good name for these profiles since they do two entirely different things (e.g. define a new = grant type and define a new method of client authentication).  One = could argue that as long as the WG is at it, then why not add a third = section to the JWT profile, which talks about usage of JWT-structured bearer access tokens: it would not be any less = related than the other two focuses of the doc.  Then the document = could be called something simple like =E2=80=9Cprofiles of JWT usage in = OAuth=E2=80=9D or something like that. 

 

On one hand, it is probably = na=C3=AFve to think that an access token can be standardized in a = profile given how many have already been released into the wild, but on the other = hand, a WG profile of a JWT-structured access token could lend itself to = interoperability, where AS implementations can advertise conformance to = the profile and who knows =E2=80=A6 maybe the RS=E2=80=99s of the future will be good with this. 

 

adam

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Brian Campbell
Sent: Thursday, February 28, 2013 1:03 PM
To: John Bradley
Cc: oauth@ietf.org WG


Subject: Re: [OAUTH-WG] JWT - scope claim missing

 

I'm not sure = anyone really "picked" the titles for the bearer token profiles. They = just kind of evolved. And evolved in funny ways especially when client = authn to the AS was added.

You won't = hear me argue that the titles are "good" and this is not the first time = there's been confusion about what they actually do. They define new = grant types and new client authentication methods. They *do not* define an access token format or anything else = about access tokens. JWT and SAML could be used for that but that's not = what these drafts do.

Suggestions for better title(s) = would be more than welcome.

 

Here's what they are now:


SAML 2.0 Bearer Assertion Profiles for OAuth 2.0
draft-ietf-oauth-saml2-bearer

JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0
draft-ietf-oauth-jwt-bearer

Assertion Framework for OAuth 2.0
draft-ietf-oauth-assertions

 

On Thu, Feb 28, 2013 at 11:36 AM, = John Bradley <ve7jtb@ve7jtb.com> wrote:

Yes the title likely adds to the = confusion given that the bearer tokens are not access tokens.

 

Things as separate from OAuth as = the Firefox browerID spec use JWS signed JWTs.  

 

The bearer token profiles for = OAuth 2 are for OAuth2.

 

The JSON Web Token (JWT) spec did not start in = OAuth and is not OAuth specific.

 

A JWT is:

JSON Web Token (JWT)  A =
string representing a set of claims as a JSON
      =
object that is encoded in a JWS or JWE, enabling the claims to =
be
      =
digitally signed or MACed and/or encrypted.
 

So OAuth or other profiles may = define claims to go in a JWT, but the JWT needs to itself only define = the claims necessary for security processing.  

 

John B.

PS that was a soft ball If you = hadn't responded I would have been disappointed.  I din't pick the = title for the bearer token profiles.

 
 

On 2013-02-28, at 10:12 AM, Phil = Hunt <phil.hunt@oracle.com> wrote:

 

JSON = Web Token (JWT) Bearer Token Profiles for OAuth 2.0


Note the title says "for OAuth2"

 

Sorry. Couldn't resist. 

 

Phil

 

Sent from my phone.


On 2013-02-28, at 9:40, John Bradley <ve7jtb@ve7jtb.com> wrote:

JWT is an assertion( I am probably going = to regret using that word).

 

It is used in openID connect for = id_tokens, it is used in OAuth for Assertion grant types and = authentication of the client to the token endpoint.

 
 
 

JSON Web Token (JWT) Bearer Token Profiles for OAuth = 2.0

 

Dosen't define JWT's use for = access tokens for the RS.   

 

Bottom line JWT is for more than = access tokens.

 

John B.

 

On 2013-02-28, at 9:28 AM, Phil = Hunt <phil.hunt@oracle.com> wrote:

 

Are you saying jwt is not an = access token type?

Phil

 

Sent from my phone.


On 2013-02-28, at 8:58, John Bradley <ve7jtb@ve7jtb.com> wrote:

Yes, defining scope in JWT is the wrong = place.   JWT needs to stick to the security claims needed to = process JWT.

 

I also don't know how far you get = requiring a specific authorization format for JWT, some AS will wan to = use a opaque reference, some might want to use a user claim or role = claim, others may use scopes,  combining scopes and claims is also = possible.

 

Right now it is up to a AS RS = pair to agree on how to communicate authorization.   I don't want = MAC to be more restrictive than bearer when it comes to authorization = between AS and RS.

 

Hannes wanted to know why JWT = didn't define scope.  The simple answer is that it is out of scope = for JWT itself.   It might be defined in a OAuth access token = profile for JWT but it should not be specific to MAC.

 

John B.

On 2013-02-28, at 8:44 AM, Brian = Campbell <bcampbell@pingidentity.com> wrote:

 

I think = John's point was more that scope is something rather specific to an = OAuth access token and, while JWT is can be used to represent an access = token, it's not the only application of JWT. The 'standard' claims in JWT are those that are believed (right = or wrong) to be widely applicable across different applications of JWT. = One could argue about it but scope is probably not one of those.

It would probably make sense to = try and build a profile of JWT specifically for OAuth access tokens = (though I suspect there are some turtles and dragons in there), which = might be the appropriate place to define/register a scope claim.

 

On Thu, Feb 28, 2013 at 9:24 AM, = Phil Hunt <phil.hunt@oracle.com> wrote:

Are you advocating TWO systems? That = seems like a bad choice.

I would rather fix scope than go to a two system approach.

Phil

Sent from my phone.

On 2013-02-28, at 8:17, John Bradley <ve7jtb@ve7jtb.com> wrote:

> While scope is one method that a AS could communicate authorization = to a RS, it is not the only or perhaps even the most likely one.
> Using scope requires a relatively tight binding between the RS and = AS,  UMA uses a different mechanism that describes finer grained = operations.
> The AS may include roles, user, or other more abstract claims that = the the client may (god help them) pass on to EXCML for processing.
>
> While having a scopes claim is possible, like any other claim it is = not part of the JWT core security processing claims, and needs to be = defined by extension.
>
> John B.
> On 2013-02-28, at 2:29 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
>
>> Hi Mike,
>>
>> when I worked on the MAC specification I noticed that the JWT = does not have a claim for the scope. I believe that this would be needed = to allow the resource server to verify whether the scope the = authorization server authorized is indeed what the client is asking for.
>>
>> Ciao
>> Hannes
>>
>> _______________________________________________
>> OAuth mailing 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



 

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

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

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


Eve Maler       =                     =        http://www.xmlgrrl.com/blog
+1= 425 345 6756                 =         http://www.twitter.com/xmlgrrl=

= --Apple-Mail=_966021A6-3A5C-480F-9810-884BC608C229-- From jricher@mitre.org Mon Mar 11 11:22: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 581E021F8CDE for ; Mon, 11 Mar 2013 11:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.195 X-Spam-Level: X-Spam-Status: No, score=-6.195 tagged_above=-999 required=5 tests=[AWL=-0.403, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82MHN7aLdfb8 for ; Mon, 11 Mar 2013 11:22:49 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 5158921F8CD2 for ; Mon, 11 Mar 2013 11:22:43 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 2A1196250191; Mon, 11 Mar 2013 14:22:42 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 06361425000C; Mon, 11 Mar 2013 14:22:42 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.59]) by IMCCAS02.MITRE.ORG ([129.83.29.69]) with mapi id 14.02.0318.004; Mon, 11 Mar 2013 14:22:41 -0400 From: "Richer, Justin P." To: Eve Maler Thread-Topic: [OAUTH-WG] JWT - scope claim missing Thread-Index: AQHOHoVqkA4BzmuY20WbPDCqvTEHKg== Date: Mon, 11 Mar 2013 18:22:41 +0000 Message-ID: References: <0EC2404F-E3C5-4AD1-88B4-E74AA0394DD9@gmx.net> <48FD87D1-4DF4-4289-99B7-40A515F31890@oracle.com> <3E472720-31A4-40A0-AAA4-402CF850831A@ve7jtb.com> <7127843B-D7B0-4AB6-87F1-1604D1EFFA79@oracle.com> <50DA292F-32F0-4266-8401-006AD837B775@ve7jtb.com> <59E470B10C4630419ED717AC79FCF9A948D58BEE@BY2PRD0411MB441.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A948D58DC0@BY2PRD0411MB441.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A956893F49@BY2PRD0411MB441.namprd04.prod.outlook.com> <6618804 564592604619@unknownmsgid> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.32.187] Content-Type: multipart/alternative; boundary="_000_B33BFB58CCC8BE4998958016839DE27E08F3EB54IMCMBX01MITREOR_" MIME-Version: 1.0 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] JWT - scope claim missing X-BeenThere: oauth@ietf.org X-Mailman-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, 11 Mar 2013 18:22:53 -0000 --_000_B33BFB58CCC8BE4998958016839DE27E08F3EB54IMCMBX01MITREOR_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSB3aXRoIEV2ZSB0aGF0IHRoZSBzdHJ1Y3R1cmUgb2YgdGhlIGRhdGEgc3Vycm91bmRp bmcgYSB0b2tlbiBzaG91bGQgcmVhbGx5IGJlIHRoZSBzYW0gYmV0d2VlbiB0aGUgYXJ0aWZhY3Qv aW50cm9zcGVjdGlvbiBhcHByb2FjaCBhbmQgdGhlIHBhY2tlZC1pbi10aGUtdG9rZW4gYXBwcm9h Y2guIFRoaXMgaXMgd2h5IGluIHRoZSBsYXRlc3QgZWRpdGlvbiBvZiBpbnRyb3NwZWN0aW9uIFsx XSBzdGFydHMgZG93biB0aGUgcm9hZCB0byBhZG9wdGluZyB0aGUgSldUIGNsYWltIG5hbWVzIHdo ZXJlIHRoZXkgb3ZlcmxhcCwgd2hpY2ggd2FzIHN1Z2dlc3RlZCBieSBUb3JzdGVuIGFuZCBvdGhl cnMuDQoNClRoZXJlIGlzIGhlc2l0YXRpb24gaW4gYWRkaW5nIG1vcmUgY2xhaW1zIHRvIGJhc2Ug SldULCB3aGljaCBtYWtlcyBzb21lIHNlbnNlLiBCdXQgdGhlcmUncyBhbHNvIGFuIGV4cHJlc3Nl ZCBkZXNpcmUgYW5kIG5lZWQgdG8gZXh0ZW5kIHRoZSBKV1QgY2xhaW0gc2V0LCBzdWNoIGFzIGlu IE5hdCdzIGRyYWZ0IGFuZCBpbiBVTUEsIHdpdGggdXNlZnVsIGluZm9ybWF0aW9uLg0KDQpJIHBy b3Bvc2UgdGhhdCB3ZSBhZG9wdCB0aGUgVU1BIGFwcHJvYWNoIChhbmQgYXQgbGVhc3Qgc29tZSBv ZiBpdHMgc3RydWN0dXJlKSBhbmQgZGVmaW5lIGEgInRva2VuIGRhdGEiIGtpbmQgb2YgY29uc3Ry dWN0LCBhbmQgZGVmaW5lIG11bHRpcGxlIHdheXMgdG8gY29tbXVuaWNhdGUgdGhhdCBpbmZvcm1h dGlvbiwgZWl0aGVyIGluc2lkZSB0aGUgdG9rZW4gaXRzZWxmICh1c2luZyBKV1QvSldTL0pXRSkg b3IgYnkgY2FsbGluZyBhbiBJbnRyb3NwZWN0aW9uIEVuZHBvaW50LiBUaGUgaW50ZXJlc3Rpbmcg dGhpbmcgd291bGQgYmUgdGhhdCB5b3UgY291bGQgZ2V0IHRoZSBzYW1lIHN0cnVjdHVyZWQgaW5m b3JtYXRpb24gaW4gZWl0aGVyIG1lYW5zLiBUaGlzIHdvdWxkIGxldCB5b3Uga2VlcCBzY29wZXMg YXMgYSBiYWctb2Ytc3RyaW5ncyAod2hpY2ggSSBkbyBmaW5kIHRvIGJlIHZlcnkgdXNlZnVsLCBz dGlsbCksIGJ1dCBzdGlsbCBoYXZlIGEgbWVhbnMgb2YgY29tbXVuaWNhdGluZyB0aG9zZSBzY29w ZXMgYmV0d2VlbiBjb21wb25lbnRzLg0KDQpBbmQgSSB0aGluayB0aGF0IHdlIGNhbiBkbyB0aGlz IGluIHN1Y2ggYSB3YXkgdGhhdCBoaWdoZXItbGV2ZWwgKGFuZCBhcmd1YWJseSBoaWdoZXItcHVy cG9zZSA7KSApIGFwcGxpY2F0aW9ucyBsaWtlIFVNQSBjYW4gZWFzaWx5IGV4dGVuZCBhIHJldXNh YmxlIGNvcmUgc2V0LiBUaGV5J3ZlIGFscmVhZHkgc3RhcnRlZCB0byBkbyB0aGlzIHdpdGggdGhl IEludHJvc3BlY3Rpb24gZHJhZnQgYXMgaXQgc3RhbmRzIG5vdyAod2hpY2ggaXNuJ3Qgc3VycHJp c2luZywgY29uc2lkZXJpbmcgdGhhdCBJIHN0b2xlIG11Y2ggb2YgdGhlIGlkZWEgZnJvbSBVTUEg dG8gYmVnaW4gd2l0aCkuDQoNCkZyb20gYSBwcmFjdGljYWwgc3RhbmRwb2ludCwgdGhpcyB3b3Vs ZCBtZWFuIGNvbWJpbmluZyBOYXQncyBhbmQgbXkgZHJhZnRzIGludG8gYSBzaW5nbGUgZG9jdW1l bnQsIHN0ZWFsaW5nIG1hbnkgd29uZGVyZnVsIHRoaW5ncyBmcm9tIFVNQSBhbG9uZyB0aGUgd2F5 LiBXZSdyZSBhbHJlYWR5IHVzaW5nIHRva2VuIGludHJvc3BlY3Rpb24gaW4gYSBmZXcgcGxhY2Vz LCBhbmQgSSBrbm93IHRoZXJlIGFyZSBzZXZlcmFsIHZlbmRvcnMgd2hvIGhhdmUgc2hpcHBlZCBh IHZlcnNpb24gb2YgdGhpcyBjb25jZXB0Lg0KDQogLS0gSnVzdGluDQoNCk9uIE1hciAxMSwgMjAx MywgYXQgMToyMiBQTSwgRXZlIE1hbGVyIDxldmVAeG1sZ3JybC5jb208bWFpbHRvOmV2ZUB4bWxn cnJsLmNvbT4+IHdyb3RlOg0KDQpKdXN0IGEgKHBlcmVubmlhbCkgcmVtaW5kZXIgZnJvbSBtZSB0 aGF0IHNjb3BlcyBhcmUgcHJvcHJpZXRhcnkgc3RyaW5ncyBpbiBjb3JlIE9BdXRoLCBidXQgdGhl IFVNQSBmb2xrcyBoYXZlIHByb3Bvc2VkIGEgd2F5IHRvIHN0YW5kYXJkaXplIHRoZW0gYmVjYXVz ZSB3ZSBuZWVkZWQgdG86DQoNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWhhcmRq b25vLW9hdXRoLXJlc291cmNlLXJlZy0wMA0KKHByZXR0eS1wcmludGVkLCBzbGlnaHRseSB1cGRh dGVkIHZlcnNpb24gaGVyZTogaHR0cDovL2RvY3Mua2FudGFyYWluaXRpYXRpdmUub3JnL3VtYS9k cmFmdC1vYXV0aC1yZXNvdXJjZS1yZWcuaHRtbCApDQoNCkl0J3MgcG9zc2libGUgdG8gdHJlYXQg dGhlIGRhdGEgYXNzb2NpYXRlZCB3aXRoIGEgdG9rZW4gYXMgb3J0aG9nb25hbCB0byB0aGUgd2F5 IGl0IGlzIGRlbGl2ZXJlZCB0byB0aGUgUlMuIFVNQSdzIGRlZmF1bHQgdG9rZW4gcHJvZmlsZSBj aG9vc2VzIHRvIHJlcXVpcmUgdGhlIFJTIHRvIGFzayB0aGUgQVMgYXQgcnVuIHRpbWUgZm9yIHRo YXQgZGF0YSAoImFydGlmYWN0IiBwYXR0ZXJuIHVzaW5nIEp1c3RpbidzIGludHJvc3BlY3Rpb24g c3BlYyksIGFuZCBkZWZpbmVzIGEgZm9ybWF0IHRoYXQgaXMgbm90IEpXVC1iYXNlZCwgYnV0IHJh dGhlciBjb252ZXlzIHBlcm1pc3Npb25zL2VudGl0bGVtZW50cyB0byB0aGUgUlMuIEJ1dCBhbGwg a2luZHMgb2YgY2hvaWNlcyBhcmUgcG9zc2libGU6DQoNCi0gRm9ybWF0OiBKV1QgYXR0cmlidXRl LXR5cGUgY2xhaW1zLiBDb252ZXlhbmNlOiBzaWduZWQgYW5kIGxvY2FsbHkgdmVyaWZpYWJsZSBi eSBSUy4NCi0gRm9ybWF0OiBKV1QgYXR0cmlidXRlLXR5cGUgY2xhaW1zLiBDb252ZXlhbmNlOiBh cnRpZmFjdC9pbnRyb3NwZWN0aW9uIHBhdHRlcm4uDQotIEZvcm1hdDogWEFDTUwtdHlwZSBhdXRo b3JpemF0aW9uIGRlY2lzaW9uLiBDb252ZXlhbmNlOiBzaWduZWQgYW5kIGxvY2FsbHkgdmVyaWZp YWJsZSBieSBSUy4NCmV0Yy4NCg0KVGhpcyBzZXBhcmF0aW9uIGlzIFVNQSdzIHByZWZlcmVuY2Ug c2luY2UgaXQgYWxyZWFkeSBoYXMgYSBub24tSldULXN0eWxlIHNldCBvZiBKU09OLWJhc2VkIGF1 dGhvcml6YXRpb24gZGF0YSwgd2hpY2ggaGFzIHNjb3BlcyBpbiBpdCBidXQgb2YgdGhlIGludGVy b3BlcmFibGUgVU1BIHNvcnQsIG5vdCB0aGUgaG90LW1lc3MgT0F1dGggc29ydC4gOi0pIFRoZSBV TUEgc3BlYyBldmVuIGhhcyBhbiBleHRlbnNpYmlsaXR5IHBvaW50IGZvciBkZWZpbmluZyBuZXcg dG9rZW4gcHJvZmlsZXMgaW4gYW4gaW50ZXJvcGVyYWJsZSBtYW5uZXIuDQoNCkV2ZQ0KDQpPbiAx MSBNYXIgMjAxMywgYXQgOTo0MiBBTSwgTmF0IFNha2ltdXJhIDxzYWtpbXVyYUBnbWFpbC5jb208 bWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbT4+IHdyb3RlOg0KDQpOby4gSSBhbSBub3QgY29uZnVz aW5nIHNjb3BlIHdpdGggYXVkaWVuY2UuDQoNClRoZXJlIGlzIG5vIHN0YW5kYXJkIHNjb3BlLiBT bywgdGhlIHNjb3BlIGhhcyB0byBiZSBlaXRoZXIgZGVmaW5lZCBieSB0aGUgcmVzb3VyY2Ugb3Ig dGhlIGF1dGhvcml6YXRpb24gc2VydmVyLg0KSnVzdCBzdGF0aW5nIHNjb3BlIGlzIHRvbyB2YWd1 ZSB0aGF0IHlvdSB3aWxsIG5vdCBhYmxlIHRvIGZpbmQgb3V0IHdob3NlIHNjb3BlIGl0IGlzLg0K DQpUaGF0IGlzIHdoeSBJIHdyb3RlIHRoYXQgdGhlIHNjb3BlIGhhcyB0byBiZSB1bmRlcnN0b29k IGluIHRoZSBjb250ZXh0IG9mIGF1ZC4NCkF1ZGllbmNlIGlzIHRoZSByZXNvdXJjZS4gU28gd2hh dCBJIHdyb3RlIGFtb3VudHMgdG8gYmUgdGhhdCB0aGUgc2NvcGUgZXhwcmVzc2VkIGluIHRoZSB0 b2tlbiBpcyB3aGF0IHdhcyBkZWZpbmVkIGJ5IHRoZSByZXNvdXJjZSBhbmQgbm90IHRoZSBhdXRo b3JpemF0aW9uIHNlcnZlci4NCg0KSXQgY291bGQgYmUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIncyBz Y29wZSwgYnV0IHRoZW4gdGhlcmUgd291bGQgYmUgYSBjb21wbGljYXRpb24gdGhhdCB0aGUgcmVz b3VyY2UgaGFzIHRvIGJlIGFibGUgdG8gcmVzb2x2ZSB0aGF0IHRvIGl0cyBvd24gc2NvcGUuIEV4 cHJlc3NpbmcgdGhlIHNjb3BlIGFzIHRoZSBhdWRpZW5jZSdzIHNjb3BlIHdpbGwgZnJlZSB1cyBm cm9tIHRoaXMgcHJvYmxlbS4NCg0KTmF0DQoNCj1uYXQgdmlhIGlQaG9uZQ0KDQpNYXIgMTEsIDIw MTMgMTA6MzjjgIFMZXdpcyBBZGFtLUNBTDAyMiA8QWRhbS5MZXdpc0Btb3Rvcm9sYXNvbHV0aW9u cy5jb208bWFpbHRvOkFkYW0uTGV3aXNAbW90b3JvbGFzb2x1dGlvbnMuY29tPj4g44Gu44Oh44OD 44K744O844K4Og0KDQpJIHdvdWxkIG5vdCBldmVuIHdhbnQgdG8gY29uZnVzZSBhdWRpZW5jZSB3 aXRoIHNjb3BlLiAgTWF5YmUgaW4gdGhlIHNpbXBsZXN0IG9mIGNhc2VzLCB3aGVyZSB0aGVyZSBp cyBhIG9uZS10by1vbmUgbWFwcGluZyBiZXR3ZWVuIHNjb3BlIGFuZCBhdWRpZW5jZSwgYnV0IGlu IHJlYWxpdHkgdGhlIFJTIGNvdWxkIGV4cG9zZSBtdWx0aXBsZSBBUElzIGF0IHRoZSBzYW1lIGVu ZHBvaW50LiAgR3JhbnRlZCB0aGUgUlMgY291bGQgZXh0cmFjdCB0aGUgYXVkaWVuY2UgZmllbGQg YmFzZWQgb24gYSBmdWxseSBxdWFsaWZpZWQgc2NvcGUsIGJ1dCBpdCBqdXN0IHNlZW1zIHRoYXQg Y2xhaW1zLCBzY29wZXMsIGFuZCBhdWRpZW5jZXMgYXJlIGVhY2ggdW5pcXVlIGFuZCBzaG91bGQg YmUga2VwdCB0aGF0IHdheS4NCg0KYWRhbQ0KDQpGcm9tOiBQaGlsIEh1bnQgW21haWx0bzpwaGls Lmh1bnRAb3JhY2xlLmNvbV0NClNlbnQ6IE1vbmRheSwgTWFyY2ggMTEsIDIwMTMgOToyNSBBTQ0K VG86IE5hdCBTYWtpbXVyYQ0KQ2M6IExld2lzIEFkYW0tQ0FMMDIyOyBvYXV0aEBpZXRmLm9yZzxt YWlsdG86b2F1dGhAaWV0Zi5vcmc+IFdHDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBKV1QgLSBz Y29wZSBjbGFpbSBtaXNzaW5nDQoNCk9uZSB0aGluZyB0aGF0IGNvbmNlcm5zIG1lIGlzIHRoYXQg c2NvcGUgaXMgdmVyeSBkaWZmZXJlbnQgZnJvbSBhIGNsYWltLiBBbiBjbGFpbSBpcyBhbiBhc3Nl cnRpb24gcHJvdmlkZWQgdGhhdCBtYXkgaGF2ZSBzb21lIGxldmVsIG9mIGRpc3B1dGUvcXVhbGl0 eSBldGMuDQoNCkEgc2NvcGUgZGVmaW5lcyB3aGF0IGlzIHJlcXVlc3Qgb3Igd2hhdCBoYXMgYmVl biBhdXRob3JpemVkLiAgSXQncyBhbiBhYnNvbHV0ZSB0aGluZy4gVGhlcmVmb3JlIGl0IGlzIG5v dCBhIGNsYWltLiBBdWRpZW5jZS4uLm1heWJlLg0KDQpUaGlzIGlzIHdoeSBJIHRoaW5rIHNjb3Bl IGRlc2VydmVzIHNwZWNpYWwgYXR0ZW50aW9uL2Rpc2N1c3Npb24gaW4gYXV0aG9yaXphdGlvbiBh c3NlcnRpb25zIGFuZCBpbiBhY2Nlc3MgdG9rZW5zLg0KDQpQaGlsDQoNCkBpbmRlcGVuZGVudGlk DQp3d3cuaW5kZXBlbmRlbnRpZC5jb208aHR0cDovL3d3dy5pbmRlcGVuZGVudGlkLmNvbS8+DQpw aGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+DQoNCg0KDQoN Ck9uIDIwMTMtMDMtMTAsIGF0IDk6MTcgUE0sIE5hdCBTYWtpbXVyYSB3cm90ZToNCg0KDQpTbywg aXQgaXMgc29vb28gbGF0ZSBpbiB0aGUgZ2FtZTogSSBoYXZlIGJlZW4gY29tcGxldGVseSB1bmRl cndhdGVyIHRvIGV2ZW4gcmVhZCB0aGUgT0F1dGggbWFpbHMgZm9yIGFib3V0IGEgbW9udGggYW5k IHNsb3dseSBjYXRjaGluZyB1cCBub3cuDQoNCkhlcmUgaXMgYW4gSS1EIHRoYXQgSSBoYXZlIGNy ZWF0ZWQgcGFydGx5IGluIHJlc3BvbnNlIHRvIHRoZSBSUy1BUyBpbnRlcmFjdGlvbiBwaWVjZSB0 aGF0IHdhcyB0YWxrZWQgYWJvdXQgYXQgSUVURiA4NS4NCkl0IGRvZXMgbm90IGhhdmUgJ3Njb3Bl JyBhbmQgaGFzICdjbGFpbXMnIGluc3RlYWQgYXMgaXQgd2FzIGJhc2VkIG9uIE9wZW5JRCBDb25u ZWN0LCBidXQgaXQgaXMgZWFzeSB0byBhZGQsIHByb3ZpZGVkIHRoYXQgdGhlIHNjb3BlcyBhcmUg dG8gYmUgdW5kZXJzdG9vZCBhcyB0aGF0IG9mIHRoZSAnYXVkJy4NCg0KaHR0cDovL3Rvb2xzLmll dGYub3JnL2lkL2RyYWZ0LXNha2ltdXJhLW9pZGMtc3RydWN0dXJlZC10b2tlbi0wMS50eHQNCg0K QmVzdCwNCg0KTmF0DQoNCjIwMTMvMy8xIExld2lzIEFkYW0tQ0FMMDIyIDxBZGFtLkxld2lzQG1v dG9yb2xhc29sdXRpb25zLmNvbTxtYWlsdG86QWRhbS5MZXdpc0Btb3Rvcm9sYXNvbHV0aW9ucy5j b20+Pg0KSG1tbSwgSeKAmW0gbm90IHNvIHN1cmUuICBJdCBkZXBlbmRzIHdoZXJlIHdlIGFsbCB0 aGluayBPQXV0aCBpcyBvbiBpdHMgdHJhamVjdG9yeS4gIE9uIG9uZSBoYW5kLCBPQXV0aCBoYXMg YWxyZWFkeSBzZWVuIGFuIGluc2FuZWx5IG1hc3NpdmUgYW1vdW50IG9mIGRlcGxveW1lbnQuICBP biB0aGUgb3RoZXIgaGFuZCwgUkVTVGZ1bCBBUElzIHNlZSBubyBzaWduIG9mIHNsb3dpbmcgZG93 bi4gICBOb3cgSeKAmW0gbm90IGdvaW5nIHRvIGdvIHNvIGZhciBhcyBDcmFpZyBCLiBhbmQgc2F5 IHRoYXQgZXZlcnl0aGluZyBhbmQgZXZlcnlvbmUgd2lsbCBiZSBBUEkgZW5hYmxlZCBpbiB0aGUg ZnV0dXJlLCBidXQgaXQgc3VyZSBpcyBnb2luZyB0byBiZSBhIGxvdC4gIFRoYXQgYmVpbmcgc2Fp ZCwgb25lIGNvdWxkIGFyZ3VlIHRoYXQgZXZlbiB3aXRoIGFsbCB0aGUgT0F1dGggaW1wbGVtZW50 YXRpb24gd2XigJl2ZSBzZWVuLCB0aGF0IHRoaXMgaXMganVzdCB0aGUgaW5mYW5jeSBvZiBpdC4g IE9idmlvdXNseSBhIFdHIHByb2ZpbGUgb2YgYSBKV1Qtc3RydWN0dXJlZCBBVCBjb3VsZCBub3Qg ZGVwcmVjYXRlIG90aGVyIGZvcm1zICh1bnN0cnVjdHVyZWQsIFNBTUwsIGV0Yy4pIGJ1dCBnb2lu ZyBmb3J3YXJkIG5ldyBkZXZlbG9wZXJzIG1heSBjaG9vc2UgdG8gZW1icmFjZSB0aGlzLCBhbmQg aW4gZmFjdCB0aGlzIGNvdWxkIGV2ZW4gYmUgdGhlIGd1aWRhbmNlLiAgIEkgYWdyZWUgd2l0aCBw cmV2aW91cyBjb21tZW50cyB0aGF0IEp1c3RpbuKAmXMgaW50cm9zcGVjdGlvbiBkcmFmdCBtaWdo dCBiZSBhIGdvb2QgcGxhY2UgdG8gZXhwbG9yZSB0aGlzLg0KDQphZGFtDQoNCkZyb206IEJyaWFu IENhbXBiZWxsIFttYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208bWFpbHRvOmJjYW1w YmVsbEBwaW5naWRlbnRpdHkuY29tPl0NClNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAyOCwgMjAx MyAxOjM2IFBNDQpUbzogTGV3aXMgQWRhbS1DQUwwMjINCkNjOiBKb2huIEJyYWRsZXk7IG9hdXRo QGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4gV0cNCg0KU3ViamVjdDogUmU6IFtPQVVU SC1XR10gSldUIC0gc2NvcGUgY2xhaW0gbWlzc2luZw0KDQoNCkkgZG8gYWdyZWUgdGhhdCBhIFdH IHByb2ZpbGUgb2YgYSBKV1Qtc3RydWN0dXJlZCBhY2Nlc3MgdG9rZW4gY291bGQgbGVuZCBpdHNl bGYgdG8gaW50ZXJvcGVyYWJpbGl0eSBhbmQgdWx0aW1hdGVseSBiZSBhIHVzZWZ1bCB0aGluZy4g QnV0IHlvdSBhcmUgcmlnaHQgdGhhdCB0aGVyZSBhbHJlYWR5IGFyZSBtYW55IGltcGxlbWVudGF0 aW9ucyBvdXQgdGhlcmUgaW4gdGhlIHdpbGQgKGhlY2ssIEkndmUgd3JpdHRlbiBvbmUgbXlzZWxm KSBhbmQgdGhhdCBtaWdodCBtYWtlIGl0IGRpZmZpY3VsdCB0byBzdGFuZGFyZGl6ZSBvbiBzb21l dGhpbmcuDQpCZWNhdXNlIG9mIHRoYXQsIGFuZCBtYW55IG90aGVyIHJlYXNvbnMsIEkgZG9uJ3Qg d2FudCB0byB0cnkgYW5kIGFkZCB0aGF0IHRvIGV4aXN0aW5nIGFzc2VydGlvbiBkcmFmdHMuDQoN Ck9uIFRodSwgRmViIDI4LCAyMDEzIGF0IDEyOjEzIFBNLCBMZXdpcyBBZGFtLUNBTDAyMiA8QWRh bS5MZXdpc0Btb3Rvcm9sYXNvbHV0aW9ucy5jb208bWFpbHRvOkFkYW0uTGV3aXNAbW90b3JvbGFz b2x1dGlvbnMuY29tPj4gd3JvdGU6DQpIaSBCcmlhbiwgYSBmZXcgdGhvdWdodHMgZnJvbSBzb21l Ym9keSBvdXRzaWRlIG9mIHRoZSBXRyDigKYNCg0KQXMgYSBuZXdjb21lciB0byBPQXV0aCBsYXN0 IHllYXIsIEkgd2FzIGluaXRpYWxseSBjb25mdXNlZCBieSB0aGUgdGl0bGVzLiAgSXQgd2FzIGNv bmZ1c2luZyBiZWNhdXNlIHdlIGhhdmUgU0FNTCBiZWFyZXIgKmFzc2VydGlvbnMqIGFuZCBKV1Qg YmVhcmVyICp0b2tlbnMqIOKApiBhbmQgYXMgSm9obiBqdXN0IChiZWdydWRnaW5nbHkpIHN0YXRl ZCBpbiB0aGlzIHRocmVhZCwgdGhlIEpXVCBpcyBiZWluZyB1c2VkIGFzIGFuIGFzc2VydGlvbiBp biB0aGlzIHByb2ZpbGUgKGFuZCBpbiBPSURDKS4gIEkgdGhpbmsgaXQgd2lsbCBiZSBkaWZmaWN1 bHQgdG8gZmluZCBhIGdvb2QgbmFtZSBmb3IgdGhlc2UgcHJvZmlsZXMgc2luY2UgdGhleSBkbyB0 d28gZW50aXJlbHkgZGlmZmVyZW50IHRoaW5ncyAoZS5nLiBkZWZpbmUgYSBuZXcgZ3JhbnQgdHlw ZSBhbmQgZGVmaW5lIGEgbmV3IG1ldGhvZCBvZiBjbGllbnQgYXV0aGVudGljYXRpb24pLiAgT25l IGNvdWxkIGFyZ3VlIHRoYXQgYXMgbG9uZyBhcyB0aGUgV0cgaXMgYXQgaXQsIHRoZW4gd2h5IG5v dCBhZGQgYSB0aGlyZCBzZWN0aW9uIHRvIHRoZSBKV1QgcHJvZmlsZSwgd2hpY2ggdGFsa3MgYWJv dXQgdXNhZ2Ugb2YgSldULXN0cnVjdHVyZWQgYmVhcmVyIGFjY2VzcyB0b2tlbnM6IGl0IHdvdWxk IG5vdCBiZSBhbnkgbGVzcyByZWxhdGVkIHRoYW4gdGhlIG90aGVyIHR3byBmb2N1c2VzIG9mIHRo ZSBkb2MuICBUaGVuIHRoZSBkb2N1bWVudCBjb3VsZCBiZSBjYWxsZWQgc29tZXRoaW5nIHNpbXBs ZSBsaWtlIOKAnHByb2ZpbGVzIG9mIEpXVCB1c2FnZSBpbiBPQXV0aOKAnSBvciBzb21ldGhpbmcg bGlrZSB0aGF0Lg0KDQpPbiBvbmUgaGFuZCwgaXQgaXMgcHJvYmFibHkgbmHDr3ZlIHRvIHRoaW5r IHRoYXQgYW4gYWNjZXNzIHRva2VuIGNhbiBiZSBzdGFuZGFyZGl6ZWQgaW4gYSBwcm9maWxlIGdp dmVuIGhvdyBtYW55IGhhdmUgYWxyZWFkeSBiZWVuIHJlbGVhc2VkIGludG8gdGhlIHdpbGQsIGJ1 dCBvbiB0aGUgb3RoZXIgaGFuZCwgYSBXRyBwcm9maWxlIG9mIGEgSldULXN0cnVjdHVyZWQgYWNj ZXNzIHRva2VuIGNvdWxkIGxlbmQgaXRzZWxmIHRvIGludGVyb3BlcmFiaWxpdHksIHdoZXJlIEFT IGltcGxlbWVudGF0aW9ucyBjYW4gYWR2ZXJ0aXNlIGNvbmZvcm1hbmNlIHRvIHRoZSBwcm9maWxl IGFuZCB3aG8ga25vd3Mg4oCmIG1heWJlIHRoZSBSU+KAmXMgb2YgdGhlIGZ1dHVyZSB3aWxsIGJl IGdvb2Qgd2l0aCB0aGlzLg0KDQphZGFtDQoNCkZyb206IG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8 bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRm Lm9yZzxtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBCcmlhbiBD YW1wYmVsbA0KU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDI4LCAyMDEzIDE6MDMgUE0NClRvOiBK b2huIEJyYWRsZXkNCkNjOiBvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+IFdH DQoNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIEpXVCAtIHNjb3BlIGNsYWltIG1pc3NpbmcNCg0K SSdtIG5vdCBzdXJlIGFueW9uZSByZWFsbHkgInBpY2tlZCIgdGhlIHRpdGxlcyBmb3IgdGhlIGJl YXJlciB0b2tlbiBwcm9maWxlcy4gVGhleSBqdXN0IGtpbmQgb2YgZXZvbHZlZC4gQW5kIGV2b2x2 ZWQgaW4gZnVubnkgd2F5cyBlc3BlY2lhbGx5IHdoZW4gY2xpZW50IGF1dGhuIHRvIHRoZSBBUyB3 YXMgYWRkZWQuDQpZb3Ugd29uJ3QgaGVhciBtZSBhcmd1ZSB0aGF0IHRoZSB0aXRsZXMgYXJlICJn b29kIiBhbmQgdGhpcyBpcyBub3QgdGhlIGZpcnN0IHRpbWUgdGhlcmUncyBiZWVuIGNvbmZ1c2lv biBhYm91dCB3aGF0IHRoZXkgYWN0dWFsbHkgZG8uIFRoZXkgZGVmaW5lIG5ldyBncmFudCB0eXBl cyBhbmQgbmV3IGNsaWVudCBhdXRoZW50aWNhdGlvbiBtZXRob2RzLiBUaGV5ICpkbyBub3QqIGRl ZmluZSBhbiBhY2Nlc3MgdG9rZW4gZm9ybWF0IG9yIGFueXRoaW5nIGVsc2UgYWJvdXQgYWNjZXNz IHRva2Vucy4gSldUIGFuZCBTQU1MIGNvdWxkIGJlIHVzZWQgZm9yIHRoYXQgYnV0IHRoYXQncyBu b3Qgd2hhdCB0aGVzZSBkcmFmdHMgZG8uDQpTdWdnZXN0aW9ucyBmb3IgYmV0dGVyIHRpdGxlKHMp IHdvdWxkIGJlIG1vcmUgdGhhbiB3ZWxjb21lLg0KDQpIZXJlJ3Mgd2hhdCB0aGV5IGFyZSBub3c6 DQoNClNBTUwgMi4wIEJlYXJlciBBc3NlcnRpb24gUHJvZmlsZXMgZm9yIE9BdXRoIDIuMA0KZHJh ZnQtaWV0Zi1vYXV0aC1zYW1sMi1iZWFyZXINCg0KSlNPTiBXZWIgVG9rZW4gKEpXVCkgQmVhcmVy IFRva2VuIFByb2ZpbGVzIGZvciBPQXV0aCAyLjANCmRyYWZ0LWlldGYtb2F1dGgtand0LWJlYXJl cg0KDQpBc3NlcnRpb24gRnJhbWV3b3JrIGZvciBPQXV0aCAyLjANCmRyYWZ0LWlldGYtb2F1dGgt YXNzZXJ0aW9ucw0KDQpPbiBUaHUsIEZlYiAyOCwgMjAxMyBhdCAxMTozNiBBTSwgSm9obiBCcmFk bGV5IDx2ZTdqdGJAdmU3anRiLmNvbTxtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20+PiB3cm90ZToN ClllcyB0aGUgdGl0bGUgbGlrZWx5IGFkZHMgdG8gdGhlIGNvbmZ1c2lvbiBnaXZlbiB0aGF0IHRo ZSBiZWFyZXIgdG9rZW5zIGFyZSBub3QgYWNjZXNzIHRva2Vucy4NCg0KVGhpbmdzIGFzIHNlcGFy YXRlIGZyb20gT0F1dGggYXMgdGhlIEZpcmVmb3ggYnJvd2VySUQgc3BlYyB1c2UgSldTIHNpZ25l ZCBKV1RzLg0KDQpUaGUgYmVhcmVyIHRva2VuIHByb2ZpbGVzIGZvciBPQXV0aCAyIGFyZSBmb3Ig T0F1dGgyLg0KDQpUaGUgSlNPTiBXZWIgVG9rZW4gKEpXVCk8aHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1qc29uLXdlYi10b2tlbi0wNj4gc3BlYyBkaWQgbm90IHN0 YXJ0IGluIE9BdXRoIGFuZCBpcyBub3QgT0F1dGggc3BlY2lmaWMuDQoNCkEgSldUIGlzOg0KDQpK U09OIFdlYiBUb2tlbiAoSldUKSAgQSBzdHJpbmcgcmVwcmVzZW50aW5nIGEgc2V0IG9mIGNsYWlt cyBhcyBhIEpTT04NCg0KICAgICAgb2JqZWN0IHRoYXQgaXMgZW5jb2RlZCBpbiBhIEpXUyBvciBK V0UsIGVuYWJsaW5nIHRoZSBjbGFpbXMgdG8gYmUNCg0KICAgICAgZGlnaXRhbGx5IHNpZ25lZCBv ciBNQUNlZCBhbmQvb3IgZW5jcnlwdGVkLg0KDQoNClNvIE9BdXRoIG9yIG90aGVyIHByb2ZpbGVz IG1heSBkZWZpbmUgY2xhaW1zIHRvIGdvIGluIGEgSldULCBidXQgdGhlIEpXVCBuZWVkcyB0byBp dHNlbGYgb25seSBkZWZpbmUgdGhlIGNsYWltcyBuZWNlc3NhcnkgZm9yIHNlY3VyaXR5IHByb2Nl c3NpbmcuDQoNCkpvaG4gQi4NClBTIHRoYXQgd2FzIGEgc29mdCBiYWxsIElmIHlvdSBoYWRuJ3Qg cmVzcG9uZGVkIEkgd291bGQgaGF2ZSBiZWVuIGRpc2FwcG9pbnRlZC4gIEkgZGluJ3QgcGljayB0 aGUgdGl0bGUgZm9yIHRoZSBiZWFyZXIgdG9rZW4gcHJvZmlsZXMuDQoNCg0KT24gMjAxMy0wMi0y OCwgYXQgMTA6MTIgQU0sIFBoaWwgSHVudCA8cGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBo aWwuaHVudEBvcmFjbGUuY29tPj4gd3JvdGU6DQoNCkpTT04gV2ViIFRva2VuIChKV1QpIEJlYXJl ciBUb2tlbiBQcm9maWxlcyBmb3IgT0F1dGggMi4wDQoNCk5vdGUgdGhlIHRpdGxlIHNheXMgImZv ciBPQXV0aDIiDQoNClNvcnJ5LiBDb3VsZG4ndCByZXNpc3QuDQoNClBoaWwNCg0KU2VudCBmcm9t IG15IHBob25lLg0KDQpPbiAyMDEzLTAyLTI4LCBhdCA5OjQwLCBKb2huIEJyYWRsZXkgPHZlN2p0 YkB2ZTdqdGIuY29tPG1haWx0bzp2ZTdqdGJAdmU3anRiLmNvbT4+IHdyb3RlOg0KSldUIGlzIGFu IGFzc2VydGlvbiggSSBhbSBwcm9iYWJseSBnb2luZyB0byByZWdyZXQgdXNpbmcgdGhhdCB3b3Jk KS4NCg0KSXQgaXMgdXNlZCBpbiBvcGVuSUQgY29ubmVjdCBmb3IgaWRfdG9rZW5zLCBpdCBpcyB1 c2VkIGluIE9BdXRoIGZvciBBc3NlcnRpb24gZ3JhbnQgdHlwZXMgYW5kIGF1dGhlbnRpY2F0aW9u IG9mIHRoZSBjbGllbnQgdG8gdGhlIHRva2VuIGVuZHBvaW50Lg0KaHR0cDovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1qd3QtYmVhcmVyLTA0DQoNCg0KDQoNCg0KDQpKU09O IFdlYiBUb2tlbiAoSldUKSBCZWFyZXIgVG9rZW4gUHJvZmlsZXMgZm9yIE9BdXRoIDIuMA0KDQpE b3Nlbid0IGRlZmluZSBKV1QncyB1c2UgZm9yIGFjY2VzcyB0b2tlbnMgZm9yIHRoZSBSUy4NCg0K Qm90dG9tIGxpbmUgSldUIGlzIGZvciBtb3JlIHRoYW4gYWNjZXNzIHRva2Vucy4NCg0KSm9obiBC Lg0KDQpPbiAyMDEzLTAyLTI4LCBhdCA5OjI4IEFNLCBQaGlsIEh1bnQgPHBoaWwuaHVudEBvcmFj bGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+IHdyb3RlOg0KDQpBcmUgeW91IHNh eWluZyBqd3QgaXMgbm90IGFuIGFjY2VzcyB0b2tlbiB0eXBlPw0KDQpQaGlsDQoNClNlbnQgZnJv bSBteSBwaG9uZS4NCg0KT24gMjAxMy0wMi0yOCwgYXQgODo1OCwgSm9obiBCcmFkbGV5IDx2ZTdq dGJAdmU3anRiLmNvbTxtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20+PiB3cm90ZToNClllcywgZGVm aW5pbmcgc2NvcGUgaW4gSldUIGlzIHRoZSB3cm9uZyBwbGFjZS4gICBKV1QgbmVlZHMgdG8gc3Rp Y2sgdG8gdGhlIHNlY3VyaXR5IGNsYWltcyBuZWVkZWQgdG8gcHJvY2VzcyBKV1QuDQoNCkkgYWxz byBkb24ndCBrbm93IGhvdyBmYXIgeW91IGdldCByZXF1aXJpbmcgYSBzcGVjaWZpYyBhdXRob3Jp emF0aW9uIGZvcm1hdCBmb3IgSldULCBzb21lIEFTIHdpbGwgd2FuIHRvIHVzZSBhIG9wYXF1ZSBy ZWZlcmVuY2UsIHNvbWUgbWlnaHQgd2FudCB0byB1c2UgYSB1c2VyIGNsYWltIG9yIHJvbGUgY2xh aW0sIG90aGVycyBtYXkgdXNlIHNjb3BlcywgIGNvbWJpbmluZyBzY29wZXMgYW5kIGNsYWltcyBp cyBhbHNvIHBvc3NpYmxlLg0KDQpSaWdodCBub3cgaXQgaXMgdXAgdG8gYSBBUyBSUyBwYWlyIHRv IGFncmVlIG9uIGhvdyB0byBjb21tdW5pY2F0ZSBhdXRob3JpemF0aW9uLiAgIEkgZG9uJ3Qgd2Fu dCBNQUMgdG8gYmUgbW9yZSByZXN0cmljdGl2ZSB0aGFuIGJlYXJlciB3aGVuIGl0IGNvbWVzIHRv IGF1dGhvcml6YXRpb24gYmV0d2VlbiBBUyBhbmQgUlMuDQoNCkhhbm5lcyB3YW50ZWQgdG8ga25v dyB3aHkgSldUIGRpZG4ndCBkZWZpbmUgc2NvcGUuICBUaGUgc2ltcGxlIGFuc3dlciBpcyB0aGF0 IGl0IGlzIG91dCBvZiBzY29wZSBmb3IgSldUIGl0c2VsZi4gICBJdCBtaWdodCBiZSBkZWZpbmVk IGluIGEgT0F1dGggYWNjZXNzIHRva2VuIHByb2ZpbGUgZm9yIEpXVCBidXQgaXQgc2hvdWxkIG5v dCBiZSBzcGVjaWZpYyB0byBNQUMuDQoNCkpvaG4gQi4NCk9uIDIwMTMtMDItMjgsIGF0IDg6NDQg QU0sIEJyaWFuIENhbXBiZWxsIDxiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTxtYWlsdG86YmNh bXBiZWxsQHBpbmdpZGVudGl0eS5jb20+PiB3cm90ZToNCg0KSSB0aGluayBKb2huJ3MgcG9pbnQg d2FzIG1vcmUgdGhhdCBzY29wZSBpcyBzb21ldGhpbmcgcmF0aGVyIHNwZWNpZmljIHRvIGFuIE9B dXRoIGFjY2VzcyB0b2tlbiBhbmQsIHdoaWxlIEpXVCBpcyBjYW4gYmUgdXNlZCB0byByZXByZXNl bnQgYW4gYWNjZXNzIHRva2VuLCBpdCdzIG5vdCB0aGUgb25seSBhcHBsaWNhdGlvbiBvZiBKV1Qu IFRoZSAnc3RhbmRhcmQnIGNsYWltcyBpbiBKV1QgYXJlIHRob3NlIHRoYXQgYXJlIGJlbGlldmVk IChyaWdodCBvciB3cm9uZykgdG8gYmUgd2lkZWx5IGFwcGxpY2FibGUgYWNyb3NzIGRpZmZlcmVu dCBhcHBsaWNhdGlvbnMgb2YgSldULiBPbmUgY291bGQgYXJndWUgYWJvdXQgaXQgYnV0IHNjb3Bl IGlzIHByb2JhYmx5IG5vdCBvbmUgb2YgdGhvc2UuDQpJdCB3b3VsZCBwcm9iYWJseSBtYWtlIHNl bnNlIHRvIHRyeSBhbmQgYnVpbGQgYSBwcm9maWxlIG9mIEpXVCBzcGVjaWZpY2FsbHkgZm9yIE9B dXRoIGFjY2VzcyB0b2tlbnMgKHRob3VnaCBJIHN1c3BlY3QgdGhlcmUgYXJlIHNvbWUgdHVydGxl cyBhbmQgZHJhZ29ucyBpbiB0aGVyZSksIHdoaWNoIG1pZ2h0IGJlIHRoZSBhcHByb3ByaWF0ZSBw bGFjZSB0byBkZWZpbmUvcmVnaXN0ZXIgYSBzY29wZSBjbGFpbS4NCg0KT24gVGh1LCBGZWIgMjgs IDIwMTMgYXQgOToyNCBBTSwgUGhpbCBIdW50IDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86 cGhpbC5odW50QG9yYWNsZS5jb20+PiB3cm90ZToNCkFyZSB5b3UgYWR2b2NhdGluZyBUV08gc3lz dGVtcz8gVGhhdCBzZWVtcyBsaWtlIGEgYmFkIGNob2ljZS4NCg0KSSB3b3VsZCByYXRoZXIgZml4 IHNjb3BlIHRoYW4gZ28gdG8gYSB0d28gc3lzdGVtIGFwcHJvYWNoLg0KDQpQaGlsDQoNClNlbnQg ZnJvbSBteSBwaG9uZS4NCg0KT24gMjAxMy0wMi0yOCwgYXQgODoxNywgSm9obiBCcmFkbGV5IDx2 ZTdqdGJAdmU3anRiLmNvbTxtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20+PiB3cm90ZToNCg0KPiBX aGlsZSBzY29wZSBpcyBvbmUgbWV0aG9kIHRoYXQgYSBBUyBjb3VsZCBjb21tdW5pY2F0ZSBhdXRo b3JpemF0aW9uIHRvIGEgUlMsIGl0IGlzIG5vdCB0aGUgb25seSBvciBwZXJoYXBzIGV2ZW4gdGhl IG1vc3QgbGlrZWx5IG9uZS4NCj4gVXNpbmcgc2NvcGUgcmVxdWlyZXMgYSByZWxhdGl2ZWx5IHRp Z2h0IGJpbmRpbmcgYmV0d2VlbiB0aGUgUlMgYW5kIEFTLCAgVU1BIHVzZXMgYSBkaWZmZXJlbnQg bWVjaGFuaXNtIHRoYXQgZGVzY3JpYmVzIGZpbmVyIGdyYWluZWQgb3BlcmF0aW9ucy4NCj4gVGhl IEFTIG1heSBpbmNsdWRlIHJvbGVzLCB1c2VyLCBvciBvdGhlciBtb3JlIGFic3RyYWN0IGNsYWlt cyB0aGF0IHRoZSB0aGUgY2xpZW50IG1heSAoZ29kIGhlbHAgdGhlbSkgcGFzcyBvbiB0byBFWENN TCBmb3IgcHJvY2Vzc2luZy4NCj4NCj4gV2hpbGUgaGF2aW5nIGEgc2NvcGVzIGNsYWltIGlzIHBv c3NpYmxlLCBsaWtlIGFueSBvdGhlciBjbGFpbSBpdCBpcyBub3QgcGFydCBvZiB0aGUgSldUIGNv cmUgc2VjdXJpdHkgcHJvY2Vzc2luZyBjbGFpbXMsIGFuZCBuZWVkcyB0byBiZSBkZWZpbmVkIGJ5 IGV4dGVuc2lvbi4NCj4NCj4gSm9obiBCLg0KPiBPbiAyMDEzLTAyLTI4LCBhdCAyOjI5IEFNLCBI YW5uZXMgVHNjaG9mZW5pZyA8aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldDxtYWlsdG86aGFubmVz LnRzY2hvZmVuaWdAZ214Lm5ldD4+IHdyb3RlOg0KPg0KPj4gSGkgTWlrZSwNCj4+DQo+PiB3aGVu IEkgd29ya2VkIG9uIHRoZSBNQUMgc3BlY2lmaWNhdGlvbiBJIG5vdGljZWQgdGhhdCB0aGUgSldU IGRvZXMgbm90IGhhdmUgYSBjbGFpbSBmb3IgdGhlIHNjb3BlLiBJIGJlbGlldmUgdGhhdCB0aGlz IHdvdWxkIGJlIG5lZWRlZCB0byBhbGxvdyB0aGUgcmVzb3VyY2Ugc2VydmVyIHRvIHZlcmlmeSB3 aGV0aGVyIHRoZSBzY29wZSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYXV0aG9yaXplZCBpcyBp bmRlZWQgd2hhdCB0aGUgY2xpZW50IGlzIGFza2luZyBmb3IuDQo+Pg0KPj4gQ2lhbw0KPj4gSGFu bmVzDQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4+IE9BdXRoIG1haWxpbmcgbGlzdA0KPj4gT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRo QGlldGYub3JnPg0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0 aA0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4gT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYu b3JnPg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGlu ZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg0KDQoNCg0KDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxp c3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KDQoNCi0tDQpOYXQgU2FraW11cmEgKD1u YXQpDQpDaGFpcm1hbiwgT3BlbklEIEZvdW5kYXRpb24NCmh0dHA6Ly9uYXQuc2FraW11cmEub3Jn Lw0KQF9uYXRfZW4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRm Lm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxp bmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQoNCkV2ZSBNYWxlciAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBodHRwOi8vd3d3LnhtbGdycmwuY29tL2Jsb2cNCisx IDQyNSAzNDUgNjc1NiAgICAgICAgICAgICAgICAgICAgICAgICBodHRwOi8vd3d3LnR3aXR0ZXIu Y29tL3htbGdycmwNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGll dGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQo= --_000_B33BFB58CCC8BE4998958016839DE27E08F3EB54IMCMBX01MITREOR_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgIj4NCkkgYWdyZWUgd2l0aCBFdmUgdGhhdCB0aGUgc3Ry dWN0dXJlIG9mIHRoZSBkYXRhIHN1cnJvdW5kaW5nIGEgdG9rZW4gc2hvdWxkIHJlYWxseSBiZSB0 aGUgc2FtIGJldHdlZW4gdGhlIGFydGlmYWN0L2ludHJvc3BlY3Rpb24gYXBwcm9hY2ggYW5kIHRo ZSBwYWNrZWQtaW4tdGhlLXRva2VuIGFwcHJvYWNoLiBUaGlzIGlzIHdoeSBpbiB0aGUgbGF0ZXN0 IGVkaXRpb24gb2YgaW50cm9zcGVjdGlvbiBbMV0gc3RhcnRzIGRvd24gdGhlIHJvYWQgdG8gYWRv cHRpbmcNCiB0aGUgSldUIGNsYWltIG5hbWVzIHdoZXJlIHRoZXkgb3ZlcmxhcCwgd2hpY2ggd2Fz IHN1Z2dlc3RlZCBieSBUb3JzdGVuIGFuZCBvdGhlcnMuDQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRp dj5UaGVyZSBpcyBoZXNpdGF0aW9uIGluIGFkZGluZyBtb3JlIGNsYWltcyB0byBiYXNlIEpXVCwg d2hpY2ggbWFrZXMgc29tZSBzZW5zZS4gQnV0IHRoZXJlJ3MgYWxzbyBhbiBleHByZXNzZWQgZGVz aXJlIGFuZCBuZWVkIHRvIGV4dGVuZCB0aGUgSldUIGNsYWltIHNldCwgc3VjaCBhcyBpbiBOYXQn cyBkcmFmdCBhbmQgaW4gVU1BLCB3aXRoIHVzZWZ1bCBpbmZvcm1hdGlvbi48L2Rpdj4NCjxkaXY+ PGJyPg0KPC9kaXY+DQo8ZGl2PkkgcHJvcG9zZSB0aGF0IHdlIGFkb3B0IHRoZSBVTUEgYXBwcm9h Y2ggKGFuZCBhdCBsZWFzdCBzb21lIG9mIGl0cyBzdHJ1Y3R1cmUpIGFuZCBkZWZpbmUgYSAmcXVv dDt0b2tlbiBkYXRhJnF1b3Q7IGtpbmQgb2YgY29uc3RydWN0LCBhbmQgZGVmaW5lIG11bHRpcGxl IHdheXMgdG8gY29tbXVuaWNhdGUgdGhhdCBpbmZvcm1hdGlvbiwgZWl0aGVyIGluc2lkZSB0aGUg dG9rZW4gaXRzZWxmICh1c2luZyBKV1QvSldTL0pXRSkgb3IgYnkgY2FsbGluZyBhbiBJbnRyb3Nw ZWN0aW9uDQogRW5kcG9pbnQuIFRoZSBpbnRlcmVzdGluZyB0aGluZyB3b3VsZCBiZSB0aGF0IHlv dSBjb3VsZCBnZXQgdGhlIHNhbWUgc3RydWN0dXJlZCBpbmZvcm1hdGlvbiBpbiBlaXRoZXIgbWVh bnMuIFRoaXMgd291bGQgbGV0IHlvdSBrZWVwIHNjb3BlcyBhcyBhIGJhZy1vZi1zdHJpbmdzICh3 aGljaCBJIGRvIGZpbmQgdG8gYmUgdmVyeSB1c2VmdWwsIHN0aWxsKSwgYnV0IHN0aWxsIGhhdmUg YSBtZWFucyBvZiBjb21tdW5pY2F0aW5nIHRob3NlIHNjb3Blcw0KIGJldHdlZW4gY29tcG9uZW50 cy4mbmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkFuZCBJIHRoaW5rIHRoYXQg d2UgY2FuIGRvIHRoaXMgaW4gc3VjaCBhIHdheSB0aGF0IGhpZ2hlci1sZXZlbCAoYW5kIGFyZ3Vh Ymx5IGhpZ2hlci1wdXJwb3NlIDspICkgYXBwbGljYXRpb25zIGxpa2UgVU1BIGNhbiBlYXNpbHkg ZXh0ZW5kIGEgcmV1c2FibGUgY29yZSBzZXQuIFRoZXkndmUgYWxyZWFkeSBzdGFydGVkIHRvIGRv IHRoaXMgd2l0aCB0aGUgSW50cm9zcGVjdGlvbiBkcmFmdCBhcyBpdCBzdGFuZHMgbm93ICh3aGlj aCBpc24ndA0KIHN1cnByaXNpbmcsIGNvbnNpZGVyaW5nIHRoYXQgSSBzdG9sZSBtdWNoIG9mIHRo ZSBpZGVhIGZyb20gVU1BIHRvIGJlZ2luIHdpdGgpLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N CjxkaXY+RnJvbSBhIHByYWN0aWNhbCBzdGFuZHBvaW50LCB0aGlzIHdvdWxkIG1lYW4gY29tYmlu aW5nIE5hdCdzIGFuZCBteSBkcmFmdHMgaW50byBhIHNpbmdsZSBkb2N1bWVudCwgc3RlYWxpbmcg bWFueSB3b25kZXJmdWwgdGhpbmdzIGZyb20gVU1BIGFsb25nIHRoZSB3YXkuIFdlJ3JlIGFscmVh ZHkgdXNpbmcgdG9rZW4gaW50cm9zcGVjdGlvbiBpbiBhIGZldyBwbGFjZXMsIGFuZCBJIGtub3cg dGhlcmUgYXJlIHNldmVyYWwgdmVuZG9ycyB3aG8NCiBoYXZlIHNoaXBwZWQgYSB2ZXJzaW9uIG9m IHRoaXMgY29uY2VwdC4mbmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PiZuYnNw Oy0tIEp1c3RpbjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj5P biBNYXIgMTEsIDIwMTMsIGF0IDE6MjIgUE0sIEV2ZSBNYWxlciAmbHQ7PGEgaHJlZj0ibWFpbHRv OmV2ZUB4bWxncnJsLmNvbSI+ZXZlQHhtbGdycmwuY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8 YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1t b2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgIj4NCjxk aXY+SnVzdCBhIChwZXJlbm5pYWwpIHJlbWluZGVyIGZyb20gbWUgdGhhdCBzY29wZXMgYXJlIHBy b3ByaWV0YXJ5IHN0cmluZ3MgaW4gY29yZSBPQXV0aCwgYnV0IHRoZSBVTUEgZm9sa3MgaGF2ZSBw cm9wb3NlZCBhIHdheSB0byBzdGFuZGFyZGl6ZSB0aGVtIGJlY2F1c2Ugd2UgbmVlZGVkIHRvOjwv ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaGFyZGpvbm8tb2F1dGgtcmVzb3VyY2UtcmVnLTAwIj5odHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1oYXJkam9uby1vYXV0aC1yZXNvdXJjZS1yZWctMDA8L2E+ PC9kaXY+DQo8ZGl2PihwcmV0dHktcHJpbnRlZCwgc2xpZ2h0bHkgdXBkYXRlZCB2ZXJzaW9uIGhl cmU6IDxhIGhyZWY9Imh0dHA6Ly9kb2NzLmthbnRhcmFpbml0aWF0aXZlLm9yZy91bWEvZHJhZnQt b2F1dGgtcmVzb3VyY2UtcmVnLmh0bWwiPg0KaHR0cDovL2RvY3Mua2FudGFyYWluaXRpYXRpdmUu b3JnL3VtYS9kcmFmdC1vYXV0aC1yZXNvdXJjZS1yZWcuaHRtbDwvYT4gKTwvZGl2Pg0KPGRpdj48 YnI+DQo8L2Rpdj4NCjxkaXY+SXQncyBwb3NzaWJsZSB0byB0cmVhdCB0aGUgZGF0YSBhc3NvY2lh dGVkIHdpdGggYSB0b2tlbiBhcyBvcnRob2dvbmFsIHRvIHRoZSB3YXkgaXQgaXMgZGVsaXZlcmVk IHRvIHRoZSBSUy4gVU1BJ3MgZGVmYXVsdCB0b2tlbiBwcm9maWxlIGNob29zZXMgdG8gcmVxdWly ZSB0aGUgUlMgdG8gYXNrIHRoZSBBUyBhdCBydW4gdGltZSBmb3IgdGhhdCBkYXRhICgmcXVvdDth cnRpZmFjdCZxdW90OyBwYXR0ZXJuIHVzaW5nIEp1c3RpbidzIGludHJvc3BlY3Rpb24gc3BlYyks DQogYW5kIGRlZmluZXMgYSBmb3JtYXQgdGhhdCBpcyBub3QgSldULWJhc2VkLCBidXQgcmF0aGVy IGNvbnZleXMgcGVybWlzc2lvbnMvZW50aXRsZW1lbnRzIHRvIHRoZSBSUy4gQnV0IGFsbCBraW5k cyBvZiBjaG9pY2VzIGFyZSBwb3NzaWJsZTo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2 Pi0gRm9ybWF0OiBKV1QgYXR0cmlidXRlLXR5cGUgY2xhaW1zLiBDb252ZXlhbmNlOiBzaWduZWQg YW5kIGxvY2FsbHkgdmVyaWZpYWJsZSBieSBSUy48L2Rpdj4NCjxkaXY+LSBGb3JtYXQ6IEpXVCBh dHRyaWJ1dGUtdHlwZSBjbGFpbXMuIENvbnZleWFuY2U6IGFydGlmYWN0L2ludHJvc3BlY3Rpb24g cGF0dGVybi48L2Rpdj4NCjxkaXY+LSBGb3JtYXQ6IFhBQ01MLXR5cGUgYXV0aG9yaXphdGlvbiBk ZWNpc2lvbi4gQ29udmV5YW5jZTogc2lnbmVkIGFuZCBsb2NhbGx5IHZlcmlmaWFibGUgYnkgUlMu PC9kaXY+DQo8ZGl2PmV0Yy48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoaXMgc2Vw YXJhdGlvbiBpcyBVTUEncyBwcmVmZXJlbmNlIHNpbmNlIGl0IGFscmVhZHkgaGFzIGEgbm9uLUpX VC1zdHlsZSBzZXQgb2YgSlNPTi1iYXNlZCBhdXRob3JpemF0aW9uIGRhdGEsIHdoaWNoIGhhcyBz Y29wZXMgaW4gaXQgYnV0IG9mIHRoZSBpbnRlcm9wZXJhYmxlIFVNQSBzb3J0LCBub3QgdGhlIGhv dC1tZXNzIE9BdXRoIHNvcnQuIDotKSBUaGUgVU1BIHNwZWMgZXZlbiBoYXMgYW4gZXh0ZW5zaWJp bGl0eSBwb2ludCBmb3IgZGVmaW5pbmcNCiBuZXcgdG9rZW4gcHJvZmlsZXMgaW4gYW4gaW50ZXJv cGVyYWJsZSBtYW5uZXIuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48c3BhbiBjbGFz cz0iQXBwbGUtdGFiLXNwYW4iIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUiPjwvc3Bhbj5FdmU8L2Rp dj4NCjxicj4NCjxkaXY+DQo8ZGl2Pk9uIDExIE1hciAyMDEzLCBhdCA5OjQyIEFNLCBOYXQgU2Fr aW11cmEgJmx0OzxhIGhyZWY9Im1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20iPnNha2ltdXJhQGdt YWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5n ZS1uZXdsaW5lIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdiBkaXI9ImF1dG8iPg0K PGRpdj48c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjpyZ2JhKDI1NSwyNTUsMjU1LDApIj5O by4gSSBhbSBub3QgY29uZnVzaW5nIHNjb3BlIHdpdGggYXVkaWVuY2UuJm5ic3A7PC9zcGFuPg0K PGRpdj48c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjpyZ2JhKDI1NSwyNTUsMjU1LDApIj48 YnI+DQo8L3NwYW4+DQo8ZGl2PjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOnJnYmEoMjU1 LDI1NSwyNTUsMCkiPlRoZXJlIGlzIG5vIHN0YW5kYXJkIHNjb3BlLiBTbywgdGhlIHNjb3BlIGhh cyB0byBiZSBlaXRoZXIgZGVmaW5lZCBieSB0aGUgcmVzb3VyY2Ugb3IgdGhlIGF1dGhvcml6YXRp b24gc2VydmVyLiZuYnNwOzwvc3Bhbj48L2Rpdj4NCjxkaXY+PHNwYW4gc3R5bGU9ImJhY2tncm91 bmQtY29sb3I6cmdiYSgyNTUsMjU1LDI1NSwwKSI+SnVzdCBzdGF0aW5nIHNjb3BlIGlzIHRvbyB2 YWd1ZSB0aGF0IHlvdSB3aWxsIG5vdCBhYmxlIHRvIGZpbmQgb3V0IHdob3NlIHNjb3BlIGl0IGlz LiZuYnNwOzwvc3Bhbj48L2Rpdj4NCjxkaXY+PHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6 cmdiYSgyNTUsMjU1LDI1NSwwKSI+PGJyPg0KPC9zcGFuPjwvZGl2Pg0KPGRpdj48c3BhbiBzdHls ZT0iYmFja2dyb3VuZC1jb2xvcjpyZ2JhKDI1NSwyNTUsMjU1LDApIj5UaGF0IGlzIHdoeSBJIHdy b3RlIHRoYXQgdGhlIHNjb3BlIGhhcyB0byBiZSB1bmRlcnN0b29kIGluIHRoZSBjb250ZXh0IG9m IGF1ZC4mbmJzcDs8L3NwYW4+PC9kaXY+DQo8ZGl2PjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNv bG9yOnJnYmEoMjU1LDI1NSwyNTUsMCkiPkF1ZGllbmNlIGlzIHRoZSByZXNvdXJjZS4gU28gd2hh dCBJIHdyb3RlIGFtb3VudHMgdG8gYmUgdGhhdCB0aGUgc2NvcGUgZXhwcmVzc2VkIGluIHRoZSB0 b2tlbiBpcyB3aGF0IHdhcyBkZWZpbmVkIGJ5IHRoZSByZXNvdXJjZSBhbmQgbm90IHRoZSBhdXRo b3JpemF0aW9uIHNlcnZlci4mbmJzcDs8L3NwYW4+PC9kaXY+DQo8ZGl2PjxzcGFuIHN0eWxlPSJi YWNrZ3JvdW5kLWNvbG9yOnJnYmEoMjU1LDI1NSwyNTUsMCkiPjxicj4NCjwvc3Bhbj48L2Rpdj4N CjxkaXY+PHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6cmdiYSgyNTUsMjU1LDI1NSwwKSI+ SXQgY291bGQgYmUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIncyBzY29wZSwgYnV0IHRoZW4gdGhlcmUg d291bGQgYmUgYSBjb21wbGljYXRpb24gdGhhdCB0aGUgcmVzb3VyY2UgaGFzIHRvIGJlIGFibGUg dG8gcmVzb2x2ZSB0aGF0IHRvIGl0cyBvd24gc2NvcGUuIEV4cHJlc3NpbmcgdGhlIHNjb3BlIGFz IHRoZSBhdWRpZW5jZSdzIHNjb3BlIHdpbGwgZnJlZQ0KIHVzIGZyb20gdGhpcyBwcm9ibGVtLiZu YnNwOzwvc3Bhbj48L2Rpdj4NCjxkaXY+PHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6cmdi YSgyNTUsMjU1LDI1NSwwKSI+PGJyPg0KPC9zcGFuPjwvZGl2Pg0KPGRpdj48c3BhbiBzdHlsZT0i YmFja2dyb3VuZC1jb2xvcjpyZ2JhKDI1NSwyNTUsMjU1LDApIj5OYXQ8L3NwYW4+PC9kaXY+DQo8 L2Rpdj4NCjxicj4NCjxzcGFuIHN0eWxlPSIiPj1uYXQgdmlhIGlQaG9uZTwvc3Bhbj48L2Rpdj4N CjxkaXYgc3R5bGU9IiI+PGJyPg0KTWFyIDExLCAyMDEzIDEwOjM444CBTGV3aXMgQWRhbS1DQUww MjIgJmx0OzxhIGhyZWY9Im1haWx0bzpBZGFtLkxld2lzQG1vdG9yb2xhc29sdXRpb25zLmNvbSI+ QWRhbS5MZXdpc0Btb3Rvcm9sYXNvbHV0aW9ucy5jb208L2E+Jmd0OyDjga7jg6Hjg4Pjgrvjg7zj grg6PGJyPg0KPGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBzdHlsZT0iIj4N CjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRl cmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAy IDIgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFu b3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNh bGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIg NCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJCb29rIEFudGlxdWEiOw0KCXBh bm9zZS0xOjIgNCA2IDIgNSAzIDUgMyAzIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAu TXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmgxDQoJe21zby1zdHlsZS1wcmlvcml0eTo5Ow0K CW1zby1zdHlsZS1saW5rOiJIZWFkaW5nIDEgQ2hhciI7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCglt YXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjI0LjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJl Zm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLmFw cGxlLXN0eWxlLXNwYW4NCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtc3R5bGUtc3Bhbjt9DQpzcGFu LkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRl ZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg UHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkhlYWRpbmcxQ2hh cg0KCXttc28tc3R5bGUtbmFtZToiSGVhZGluZyAxIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0 eTo5Ow0KCW1zby1zdHlsZS1saW5rOiJIZWFkaW5nIDEiOw0KCWZvbnQtZmFtaWx5OiJDYW1icmlh Iiwic2VyaWYiOw0KCWNvbG9yOiMzNjVGOTE7DQoJZm9udC13ZWlnaHQ6Ym9sZDt9DQpzcGFuLkVt YWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEu MGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLS0+PC9zdHlsZT4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFmNDk3ZCI+SSB3b3Vs ZCBub3QgZXZlbiB3YW50IHRvIGNvbmZ1c2UgYXVkaWVuY2Ugd2l0aCBzY29wZS4mbmJzcDsgTWF5 YmUgaW4gdGhlIHNpbXBsZXN0IG9mIGNhc2VzLCB3aGVyZSB0aGVyZSBpcyBhIG9uZS10by1vbmUg bWFwcGluZyBiZXR3ZWVuIHNjb3BlIGFuZCBhdWRpZW5jZSwgYnV0IGluDQogcmVhbGl0eSB0aGUg UlMgY291bGQgZXhwb3NlIG11bHRpcGxlIEFQSXMgYXQgdGhlIHNhbWUgZW5kcG9pbnQuJm5ic3A7 IEdyYW50ZWQgdGhlIFJTIGNvdWxkIGV4dHJhY3QgdGhlIGF1ZGllbmNlIGZpZWxkIGJhc2VkIG9u IGEgZnVsbHkgcXVhbGlmaWVkIHNjb3BlLCBidXQgaXQganVzdCBzZWVtcyB0aGF0IGNsYWltcywg c2NvcGVzLCBhbmQgYXVkaWVuY2VzIGFyZSBlYWNoIHVuaXF1ZSBhbmQgc2hvdWxkIGJlIGtlcHQg dGhhdCB3YXkuPC9zcGFuPjwvcD4NCjxkaXY+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxZjQ5N2QiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9IndlYmtpdC1ibG9jay1wbGFjZWhv bGRlciI+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMWY0OTdkIj5hZGFtPC9zcGFuPjwvcD4NCjxkaXY+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxZjQ5N2QiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9Indl YmtpdC1ibG9jay1wbGFjZWhvbGRlciI+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNiNWM0ZGYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g MGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gUGhpbCBI dW50IFs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iPm1haWx0bzpwaGlsLmh1 bnRAb3JhY2xlLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBNYXJjaCAxMSwg MjAxMyA5OjI1IEFNPGJyPg0KPGI+VG86PC9iPiBOYXQgU2FraW11cmE8YnI+DQo8Yj5DYzo8L2I+ IExld2lzIEFkYW0tQ0FMMDIyOyA8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9hdXRo QGlldGYub3JnPC9hPiBXRzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBKV1Qg LSBzY29wZSBjbGFpbSBtaXNzaW5nPC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2PiZu YnNwOzxiciBjbGFzcz0id2Via2l0LWJsb2NrLXBsYWNlaG9sZGVyIj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T25lIHRoaW5nIHRoYXQgY29uY2VybnMgbWUgaXMgdGhhdCBzY29wZSBp cyB2ZXJ5IGRpZmZlcmVudCBmcm9tIGEgY2xhaW0uIEFuIGNsYWltIGlzIGFuIGFzc2VydGlvbiBw cm92aWRlZCB0aGF0IG1heSBoYXZlIHNvbWUgbGV2ZWwgb2YgZGlzcHV0ZS9xdWFsaXR5IGV0Yy48 L3A+DQo8ZGl2Pg0KPGRpdj4mbmJzcDs8YnIgY2xhc3M9IndlYmtpdC1ibG9jay1wbGFjZWhvbGRl ciI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkEgc2NvcGUg ZGVmaW5lcyB3aGF0IGlzIHJlcXVlc3Qgb3Igd2hhdCBoYXMgYmVlbiBhdXRob3JpemVkLiAmbmJz cDtJdCdzIGFuIGFic29sdXRlIHRoaW5nLiBUaGVyZWZvcmUgaXQgaXMgbm90IGEgY2xhaW0uIEF1 ZGllbmNlLi4ubWF5YmUuJm5ic3A7PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4mbmJzcDs8YnIg Y2xhc3M9IndlYmtpdC1ibG9jay1wbGFjZWhvbGRlciI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgaXMgd2h5IEkgdGhpbmsgc2NvcGUgZGVzZXJ2ZXMg c3BlY2lhbCBhdHRlbnRpb24vZGlzY3Vzc2lvbiBpbiBhdXRob3JpemF0aW9uIGFzc2VydGlvbnMg YW5kIGluIGFjY2VzcyB0b2tlbnMuPC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4mbmJzcDs8YnIg Y2xhc3M9IndlYmtpdC1ibG9jay1wbGFjZWhvbGRlciI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5cHQ7IGZvbnQtZmFtaWx5OiBI ZWx2ZXRpY2EsIHNhbnMtc2VyaWY7ICI+UGhpbDwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2PjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDlwdDsgZm9udC1mYW1pbHk6IEhlbHZldGljYSwg c2Fucy1zZXJpZjsgIj4mbmJzcDs8L3NwYW4+PGJyIGNsYXNzPSJ3ZWJraXQtYmxvY2stcGxhY2Vo b2xkZXIiPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOiA5cHQ7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2EsIHNhbnMtc2Vy aWY7ICI+QGluZGVwZW5kZW50aWQ8L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOXB0OyBmb250LWZhbWlseTogSGVs dmV0aWNhLCBzYW5zLXNlcmlmOyAiPjxhIGhyZWY9Imh0dHA6Ly93d3cuaW5kZXBlbmRlbnRpZC5j b20vIj53d3cuaW5kZXBlbmRlbnRpZC5jb208L2E+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTMuNXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMy41cHQ7IGZvbnQtZmFtaWx5OiBI ZWx2ZXRpY2EsIHNhbnMtc2VyaWY7ICI+PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUu Y29tIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pjxz cGFuIHN0eWxlPSJmb250LXNpemU6IDEzLjVwdDsgZm9udC1mYW1pbHk6IEhlbHZldGljYSwgc2Fu cy1zZXJpZjsgIj4mbmJzcDs8L3NwYW4+PGJyIGNsYXNzPSJ3ZWJraXQtYmxvY2stcGxhY2Vob2xk ZXIiPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6IDEzLjVwdDsgZm9udC1mYW1pbHk6IEhlbHZldGljYSwgc2Fucy1zZXJpZjsgIj48 YnI+DQo8YnI+DQo8L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2PiZuYnNwOzxiciBjbGFzcz0id2Vi a2l0LWJsb2NrLXBsYWNlaG9sZGVyIj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5PbiAyMDEzLTAzLTEwLCBhdCA5OjE3IFBNLCBOYXQgU2FraW11cmEgd3JvdGU6 PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5TbywgaXQgaXMgc29vb28gbGF0ZSBpbiB0aGUgZ2FtZTogSSBoYXZl IGJlZW4gY29tcGxldGVseSB1bmRlcndhdGVyIHRvIGV2ZW4gcmVhZCB0aGUgT0F1dGggbWFpbHMg Zm9yIGFib3V0IGEgbW9udGggYW5kIHNsb3dseSBjYXRjaGluZyB1cCBub3cuJm5ic3A7PC9wPg0K PGRpdj4NCjxkaXY+Jm5ic3A7PGJyIGNsYXNzPSJ3ZWJraXQtYmxvY2stcGxhY2Vob2xkZXIiPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IZXJlIGlzIGFuIEkt RCB0aGF0IEkgaGF2ZSBjcmVhdGVkIHBhcnRseSBpbiByZXNwb25zZSB0byB0aGUgUlMtQVMgaW50 ZXJhY3Rpb24gcGllY2UgdGhhdCB3YXMgdGFsa2VkIGFib3V0IGF0IElFVEYgODUuJm5ic3A7PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQgZG9lcyBub3QgaGF2ZSAn c2NvcGUnIGFuZCBoYXMgJ2NsYWltcycgaW5zdGVhZCBhcyBpdCB3YXMgYmFzZWQgb24gT3BlbklE IENvbm5lY3QsIGJ1dCBpdCBpcyBlYXN5IHRvIGFkZCwgcHJvdmlkZWQgdGhhdCB0aGUgc2NvcGVz IGFyZSB0byBiZSB1bmRlcnN0b29kIGFzIHRoYXQgb2YgdGhlICdhdWQnLiZuYnNwOzwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+Jm5ic3A7PGJyIGNsYXNzPSJ3ZWJraXQtYmxvY2stcGxhY2Vob2xk ZXIiPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVm PSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtc2FraW11cmEtb2lkYy1zdHJ1Y3R1cmVk LXRva2VuLTAxLnR4dCI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LXNha2ltdXJhLW9p ZGMtc3RydWN0dXJlZC10b2tlbi0wMS50eHQ8L2E+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4m bmJzcDs8YnIgY2xhc3M9IndlYmtpdC1ibG9jay1wbGFjZWhvbGRlciI+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJlc3QsJm5ic3A7PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4mbmJzcDs8YnIgY2xhc3M9IndlYmtpdC1ibG9jay1wbGFjZWhvbGRlciI+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5hdDwvcD4NCjwvZGl2 Pg0KPGRpdj4mbmJzcDs8YnIgY2xhc3M9IndlYmtpdC1ibG9jay1wbGFjZWhvbGRlciI+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yMDEzLzMvMSBMZXdpcyBBZGFtLUNBTDAy MiAmbHQ7PGEgaHJlZj0ibWFpbHRvOkFkYW0uTGV3aXNAbW90b3JvbGFzb2x1dGlvbnMuY29tIiB0 YXJnZXQ9Il9ibGFuayI+QWRhbS5MZXdpc0Btb3Rvcm9sYXNvbHV0aW9ucy5jb208L2E+Jmd0Ozwv cD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IiI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Qm9vayBBbnRpcXVhJnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOm9saXZlIj5IbW1tLCBJ4oCZbSBub3Qgc28gc3VyZS4m bmJzcDsgSXQgZGVwZW5kcyB3aGVyZSB3ZSBhbGwgdGhpbmsgT0F1dGggaXMgb24gaXRzIHRyYWpl Y3RvcnkuJm5ic3A7IE9uIG9uZSBoYW5kLCBPQXV0aCBoYXMgYWxyZWFkeSBzZWVuIGFuIGluc2Fu ZWx5IG1hc3NpdmUgYW1vdW50IG9mDQogZGVwbG95bWVudC4mbmJzcDsgT24gdGhlIG90aGVyIGhh bmQsIFJFU1RmdWwgQVBJcyBzZWUgbm8gc2lnbiBvZiBzbG93aW5nIGRvd24uJm5ic3A7Jm5ic3A7 IE5vdyBJ4oCZbSBub3QgZ29pbmcgdG8gZ28gc28gZmFyIGFzIENyYWlnIEIuIGFuZCBzYXkgdGhh dCBldmVyeXRoaW5nIGFuZCBldmVyeW9uZSB3aWxsIGJlIEFQSSBlbmFibGVkIGluIHRoZSBmdXR1 cmUsIGJ1dCBpdCBzdXJlIGlzIGdvaW5nIHRvIGJlIGEgbG90LiZuYnNwOyBUaGF0IGJlaW5nIHNh aWQsIG9uZSBjb3VsZCBhcmd1ZQ0KIHRoYXQgZXZlbiB3aXRoIGFsbCB0aGUgT0F1dGggaW1wbGVt ZW50YXRpb24gd2XigJl2ZSBzZWVuLCB0aGF0IHRoaXMgaXMganVzdCB0aGUgaW5mYW5jeSBvZiBp dC4mbmJzcDsgT2J2aW91c2x5IGEgV0cgcHJvZmlsZSBvZiBhIEpXVC1zdHJ1Y3R1cmVkIEFUIGNv dWxkIG5vdCBkZXByZWNhdGUgb3RoZXIgZm9ybXMgKHVuc3RydWN0dXJlZCwgU0FNTCwgZXRjLikg YnV0IGdvaW5nIGZvcndhcmQgbmV3IGRldmVsb3BlcnMgbWF5IGNob29zZSB0byBlbWJyYWNlIHRo aXMsDQogYW5kIGluIGZhY3QgdGhpcyBjb3VsZCBldmVuIGJlIHRoZSBndWlkYW5jZS4gJm5ic3A7 Jm5ic3A7SSBhZ3JlZSB3aXRoIHByZXZpb3VzIGNvbW1lbnRzIHRoYXQgSnVzdGlu4oCZcyBpbnRy b3NwZWN0aW9uIGRyYWZ0IG1pZ2h0IGJlIGEgZ29vZCBwbGFjZSB0byBleHBsb3JlIHRoaXMuPC9z cGFuPjwvcD4NCjxkaXYgc3R5bGU9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Qm9vayBBbnRpcXVhJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9y Om9saXZlIj4mbmJzcDs8L3NwYW4+PGJyIGNsYXNzPSJ3ZWJraXQtYmxvY2stcGxhY2Vob2xkZXIi Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtCb29rIEFudGlxdWEmcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDs7Y29sb3I6b2xpdmUiPmFkYW08L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtCb29rIEFudGlx dWEmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6b2xpdmUiPiZuYnNwOzwvc3Bhbj48YnIg Y2xhc3M9IndlYmtpdC1ibG9jay1wbGFjZWhvbGRlciI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI2I1YzRkZiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBp biAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSIiPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPiBCcmlhbiBDYW1wYmVsbCBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpiY2FtcGJlbGxAcGlu Z2lkZW50aXR5LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29t PC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgRmVicnVhcnkgMjgsIDIwMTMgMToz NiBQTTxicj4NCjxiPlRvOjwvYj4gTGV3aXMgQWRhbS1DQUwwMjI8YnI+DQo8Yj5DYzo8L2I+IEpv aG4gQnJhZGxleTsgPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+b2F1dGhAaWV0Zi5vcmc8L2E+IFdHPC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIEpXVCAt IHNjb3BlIGNsYWltIG1pc3Npbmc8L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+Jm5i c3A7PGJyIGNsYXNzPSJ3ZWJraXQtYmxvY2stcGxhY2Vob2xkZXIiPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSIiPiZuYnNwOzxiciBjbGFzcz0id2Vi a2l0LWJsb2NrLXBsYWNlaG9sZGVyIj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkkgZG8gYWdyZWUgdGhhdCBh IFdHIHByb2ZpbGUgb2YgYSBKV1Qtc3RydWN0dXJlZCBhY2Nlc3MgdG9rZW4gY291bGQgbGVuZCBp dHNlbGYgdG8gaW50ZXJvcGVyYWJpbGl0eSBhbmQgdWx0aW1hdGVseSBiZSBhIHVzZWZ1bCB0aGlu Zy4gQnV0IHlvdSBhcmUgcmlnaHQgdGhhdCB0aGVyZSBhbHJlYWR5IGFyZSBtYW55IGltcGxlbWVu dGF0aW9ucyBvdXQgdGhlcmUgaW4NCiB0aGUgd2lsZCAoaGVjaywgSSd2ZSB3cml0dGVuIG9uZSBt eXNlbGYpIGFuZCB0aGF0IG1pZ2h0IG1ha2UgaXQgZGlmZmljdWx0IHRvIHN0YW5kYXJkaXplIG9u IHNvbWV0aGluZy48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSIiPkJl Y2F1c2Ugb2YgdGhhdCwgYW5kIG1hbnkgb3RoZXIgcmVhc29ucywgSSBkb24ndCB3YW50IHRvIHRy eSBhbmQgYWRkIHRoYXQgdG8gZXhpc3RpbmcgYXNzZXJ0aW9uIGRyYWZ0cy48L3A+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0ibWFyZ2luLWJvdHRvbTogMTJwdDsgIj4mbmJzcDs8YnIgY2xhc3M9IndlYmtp dC1ibG9jay1wbGFjZWhvbGRlciI+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iIj5PbiBUaHUsIEZlYiAyOCwgMjAxMyBhdCAxMjoxMyBQTSwgTGV3aXMgQWRhbS1D QUwwMjIgJmx0OzxhIGhyZWY9Im1haWx0bzpBZGFtLkxld2lzQG1vdG9yb2xhc29sdXRpb25zLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPkFkYW0uTGV3aXNAbW90b3JvbGFzb2x1dGlvbnMuY29tPC9hPiZn dDsgd3JvdGU6PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtCb29rIEFu dGlxdWEmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6b2xpdmUiPkhpIEJyaWFuLCBhIGZl dyB0aG91Z2h0cyBmcm9tIHNvbWVib2R5IG91dHNpZGUgb2YgdGhlIFdHIOKApg0KPC9zcGFuPjwv cD4NCjxkaXYgc3R5bGU9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Qm9vayBBbnRpcXVhJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOm9saXZl Ij4mbmJzcDs8L3NwYW4+PGJyIGNsYXNzPSJ3ZWJraXQtYmxvY2stcGxhY2Vob2xkZXIiPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtCb29rIEFudGlxdWEmcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDs7Y29sb3I6b2xpdmUiPkFzIGEgbmV3Y29tZXIgdG8gT0F1dGggbGFzdCB5ZWFyLCBJIHdh cyBpbml0aWFsbHkgY29uZnVzZWQgYnkgdGhlIHRpdGxlcy4mbmJzcDsgSXQgd2FzIGNvbmZ1c2lu ZyBiZWNhdXNlIHdlIGhhdmUgU0FNTCBiZWFyZXIgKjxiPmFzc2VydGlvbnM8L2I+KiBhbmQgSldU IGJlYXJlcg0KICo8Yj50b2tlbnM8L2I+KiDigKYgYW5kIGFzIEpvaG4ganVzdCAoYmVncnVkZ2lu Z2x5KSBzdGF0ZWQgaW4gdGhpcyB0aHJlYWQsIHRoZSBKV1QgaXMgYmVpbmcgdXNlZCBhcyBhbiBh c3NlcnRpb24gaW4gdGhpcyBwcm9maWxlIChhbmQgaW4gT0lEQykuJm5ic3A7IEkgdGhpbmsgaXQg d2lsbCBiZSBkaWZmaWN1bHQgdG8gZmluZCBhIGdvb2QgbmFtZSBmb3IgdGhlc2UgcHJvZmlsZXMg c2luY2UgdGhleSBkbyB0d28gZW50aXJlbHkgZGlmZmVyZW50IHRoaW5ncyAoZS5nLg0KIGRlZmlu ZSBhIG5ldyBncmFudCB0eXBlIGFuZCBkZWZpbmUgYSBuZXcgbWV0aG9kIG9mIGNsaWVudCBhdXRo ZW50aWNhdGlvbikuJm5ic3A7IE9uZSBjb3VsZCBhcmd1ZSB0aGF0IGFzIGxvbmcgYXMgdGhlIFdH IGlzIGF0IGl0LCB0aGVuIHdoeSBub3QgYWRkIGEgdGhpcmQgc2VjdGlvbiB0byB0aGUgSldUIHBy b2ZpbGUsIHdoaWNoIHRhbGtzIGFib3V0IHVzYWdlIG9mIEpXVC1zdHJ1Y3R1cmVkIGJlYXJlciBh Y2Nlc3MgdG9rZW5zOiBpdCB3b3VsZCBub3QgYmUNCiBhbnkgbGVzcyByZWxhdGVkIHRoYW4gdGhl IG90aGVyIHR3byBmb2N1c2VzIG9mIHRoZSBkb2MuJm5ic3A7IFRoZW4gdGhlIGRvY3VtZW50IGNv dWxkIGJlIGNhbGxlZCBzb21ldGhpbmcgc2ltcGxlIGxpa2Ug4oCccHJvZmlsZXMgb2YgSldUIHVz YWdlIGluIE9BdXRo4oCdIG9yIHNvbWV0aGluZyBsaWtlIHRoYXQuJm5ic3A7DQo8L3NwYW4+PC9w Pg0KPGRpdiBzdHlsZT0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtCb29rIEFudGlxdWEmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6b2xpdmUi PiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9IndlYmtpdC1ibG9jay1wbGFjZWhvbGRlciI+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Jvb2sgQW50aXF1YSZxdW90OywmcXVvdDtzZXJpZiZx dW90Oztjb2xvcjpvbGl2ZSI+T24gb25lIGhhbmQsIGl0IGlzIHByb2JhYmx5IG5hw692ZSB0byB0 aGluayB0aGF0IGFuIGFjY2VzcyB0b2tlbiBjYW4gYmUgc3RhbmRhcmRpemVkIGluIGEgcHJvZmls ZSBnaXZlbiBob3cgbWFueSBoYXZlIGFscmVhZHkgYmVlbiByZWxlYXNlZCBpbnRvIHRoZSB3aWxk LA0KIGJ1dCBvbiB0aGUgb3RoZXIgaGFuZCwgYSBXRyBwcm9maWxlIG9mIGEgSldULXN0cnVjdHVy ZWQgYWNjZXNzIHRva2VuIGNvdWxkIGxlbmQgaXRzZWxmIHRvIGludGVyb3BlcmFiaWxpdHksIHdo ZXJlIEFTIGltcGxlbWVudGF0aW9ucyBjYW4gYWR2ZXJ0aXNlIGNvbmZvcm1hbmNlIHRvIHRoZSBw cm9maWxlIGFuZCB3aG8ga25vd3Mg4oCmIG1heWJlIHRoZSBSU+KAmXMgb2YgdGhlIGZ1dHVyZSB3 aWxsIGJlIGdvb2Qgd2l0aCB0aGlzLiZuYnNwOw0KPC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9IiI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Qm9vayBBbnRp cXVhJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOm9saXZlIj4mbmJzcDs8L3NwYW4+PGJy IGNsYXNzPSJ3ZWJraXQtYmxvY2stcGxhY2Vob2xkZXIiPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtCb29rIEFudGlxdWEmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6b2xpdmUi PmFkYW08L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtCb29rIEFudGlxdWEmcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDs7Y29sb3I6b2xpdmUiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9IndlYmtpdC1ibG9jay1wbGFj ZWhvbGRlciI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI2I1YzRkZiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSIiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPg0KPGEgaHJlZj0ibWFpbHRvOm9h dXRoLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aC1ib3VuY2VzQGlldGYu b3JnPC9hPiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYg T2YgPC9iPkJyaWFuIENhbXBiZWxsPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBGZWJydWFy eSAyOCwgMjAxMyAxOjAzIFBNPGJyPg0KPGI+VG86PC9iPiBKb2huIEJyYWRsZXk8YnI+DQo8Yj5D Yzo8L2I+IDxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9h dXRoQGlldGYub3JnPC9hPiBXRzwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9IiI+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIEpXVCAtIHNj b3BlIGNsYWltIG1pc3Npbmc8L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iIj4mbmJz cDs8YnIgY2xhc3M9IndlYmtpdC1ibG9jay1wbGFjZWhvbGRlciI+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5J J20gbm90IHN1cmUgYW55b25lIHJlYWxseSAmcXVvdDtwaWNrZWQmcXVvdDsgdGhlIHRpdGxlcyBm b3IgdGhlIGJlYXJlciB0b2tlbiBwcm9maWxlcy4gVGhleSBqdXN0IGtpbmQgb2YgZXZvbHZlZC4g QW5kIGV2b2x2ZWQgaW4gZnVubnkgd2F5cyBlc3BlY2lhbGx5IHdoZW4gY2xpZW50IGF1dGhuIHRv IHRoZSBBUyB3YXMgYWRkZWQuDQo8L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+WW91IHdvbid0 IGhlYXIgbWUgYXJndWUgdGhhdCB0aGUgdGl0bGVzIGFyZSAmcXVvdDtnb29kJnF1b3Q7IGFuZCB0 aGlzIGlzIG5vdCB0aGUgZmlyc3QgdGltZSB0aGVyZSdzIGJlZW4gY29uZnVzaW9uIGFib3V0IHdo YXQgdGhleSBhY3R1YWxseSBkby4gVGhleSBkZWZpbmUgbmV3IGdyYW50IHR5cGVzIGFuZCBuZXcg Y2xpZW50IGF1dGhlbnRpY2F0aW9uIG1ldGhvZHMuIFRoZXkgKmRvDQogbm90KiBkZWZpbmUgYW4g YWNjZXNzIHRva2VuIGZvcm1hdCBvciBhbnl0aGluZyBlbHNlIGFib3V0IGFjY2VzcyB0b2tlbnMu IEpXVCBhbmQgU0FNTCBjb3VsZCBiZSB1c2VkIGZvciB0aGF0IGJ1dCB0aGF0J3Mgbm90IHdoYXQg dGhlc2UgZHJhZnRzIGRvLg0KPC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9IiI+U3VnZ2VzdGlvbnMgZm9yIGJldHRlciB0aXRsZShzKSB3b3VsZCBiZSBtb3Jl IHRoYW4gd2VsY29tZS48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iIj4m bmJzcDs8YnIgY2xhc3M9IndlYmtpdC1ibG9jay1wbGFjZWhvbGRlciI+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSIiPkhlcmUncyB3aGF0IHRoZXkg YXJlIG5vdzo8L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i Ij48YnI+DQpTQU1MIDIuMCBCZWFyZXIgQXNzZXJ0aW9uIFByb2ZpbGVzIGZvciBPQXV0aCAyLjA8 YnI+DQpkcmFmdC1pZXRmLW9hdXRoLXNhbWwyLWJlYXJlcjxicj4NCjxicj4NCkpTT04gV2ViIFRv a2VuIChKV1QpIEJlYXJlciBUb2tlbiBQcm9maWxlcyBmb3IgT0F1dGggMi4wPGJyPg0KZHJhZnQt aWV0Zi1vYXV0aC1qd3QtYmVhcmVyPGJyPg0KPGJyPg0KQXNzZXJ0aW9uIEZyYW1ld29yayBmb3Ig T0F1dGggMi4wPGJyPg0KZHJhZnQtaWV0Zi1vYXV0aC1hc3NlcnRpb25zPC9wPg0KPGRpdj4NCjxk aXYgc3R5bGU9IiI+Jm5ic3A7PGJyIGNsYXNzPSJ3ZWJraXQtYmxvY2stcGxhY2Vob2xkZXIiPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IiI+T24gVGh1LCBGZWIg MjgsIDIwMTMgYXQgMTE6MzYgQU0sIEpvaG4gQnJhZGxleSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZl N2p0YkB2ZTdqdGIuY29tIiB0YXJnZXQ9Il9ibGFuayI+dmU3anRiQHZlN2p0Yi5jb208L2E+Jmd0 OyB3cm90ZTo8L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IiI+WWVzIHRo ZSB0aXRsZSBsaWtlbHkgYWRkcyB0byB0aGUgY29uZnVzaW9uIGdpdmVuIHRoYXQgdGhlIGJlYXJl ciB0b2tlbnMgYXJlIG5vdCBhY2Nlc3MgdG9rZW5zLjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSIi PiZuYnNwOzxiciBjbGFzcz0id2Via2l0LWJsb2NrLXBsYWNlaG9sZGVyIj4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IiI+VGhpbmdzIGFzIHNlcGFy YXRlIGZyb20gT0F1dGggYXMgdGhlIEZpcmVmb3ggYnJvd2VySUQgc3BlYyB1c2UgSldTIHNpZ25l ZCBKV1RzLiAmbmJzcDs8L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSIiPiZuYnNwOzxi ciBjbGFzcz0id2Via2l0LWJsb2NrLXBsYWNlaG9sZGVyIj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IiI+VGhlIGJlYXJlciB0b2tlbiBwcm9maWxl cyBmb3IgT0F1dGggMiBhcmUgZm9yIE9BdXRoMi48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSIiPiZuYnNwOzxiciBjbGFzcz0id2Via2l0LWJsb2NrLXBsYWNlaG9sZGVyIj4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IiI+VGhlJm5ic3A7 PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1qc29u LXdlYi10b2tlbi0wNiIgdGFyZ2V0PSJfYmxhbmsiPkpTT04gV2ViIFRva2VuIChKV1QpPC9hPiZu YnNwO3NwZWMgZGlkIG5vdCBzdGFydCBpbiBPQXV0aCBhbmQgaXMgbm90IE9BdXRoIHNwZWNpZmlj LjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9IiI+Jm5ic3A7PGJyIGNsYXNzPSJ3ZWJr aXQtYmxvY2stcGxhY2Vob2xkZXIiPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iIj5BIEpXVCBpczo8L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5KU09OIFdlYiBUb2tlbiAoSldUKSZuYnNwOyBB IHN0cmluZyByZXByZXNlbnRpbmcgYSBzZXQgb2YgY2xhaW1zIGFzIGEgSlNPTjwvc3Bhbj48L3By ZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBvYmplY3QgdGhhdCBpcyBlbmNvZGVkIGluIGEgSldTIG9yIEpXRSwgZW5h YmxpbmcgdGhlIGNsYWltcyB0byBiZTwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkaWdpdGFsbHkg c2lnbmVkIG9yIE1BQ2VkIGFuZC9vciBlbmNyeXB0ZWQuPC9zcGFuPjwvcHJlPg0KPGRpdj4NCjxk aXYgc3R5bGU9IiI+Jm5ic3A7PGJyIGNsYXNzPSJ3ZWJraXQtYmxvY2stcGxhY2Vob2xkZXIiPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iIj5TbyBP QXV0aCBvciBvdGhlciBwcm9maWxlcyBtYXkgZGVmaW5lIGNsYWltcyB0byBnbyBpbiBhIEpXVCwg YnV0IHRoZSBKV1QgbmVlZHMgdG8gaXRzZWxmIG9ubHkgZGVmaW5lIHRoZSBjbGFpbXMgbmVjZXNz YXJ5IGZvciBzZWN1cml0eSBwcm9jZXNzaW5nLiAmbmJzcDs8L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSIiPiZuYnNwOzxiciBjbGFzcz0id2Via2l0LWJsb2NrLXBsYWNlaG9sZGVyIj4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IiI+Sm9o biBCLjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSIiPlBT IHRoYXQgd2FzIGEgc29mdCBiYWxsIElmIHlvdSBoYWRuJ3QgcmVzcG9uZGVkIEkgd291bGQgaGF2 ZSBiZWVuIGRpc2FwcG9pbnRlZC4gJm5ic3A7SSBkaW4ndCBwaWNrIHRoZSB0aXRsZSBmb3IgdGhl IGJlYXJlciB0b2tlbiBwcm9maWxlcy48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXYgc3R5bGU9IiI+Jm5ic3A7PGJyIGNsYXNzPSJ3ZWJraXQtYmxvY2stcGxhY2Vob2xkZXIi Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSIiPiZuYnNwOzxiciBjbGFzcz0i d2Via2l0LWJsb2NrLXBsYWNlaG9sZGVyIj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSIiPk9uIDIwMTMtMDItMjgsIGF0IDEwOjEyIEFN LCBQaGlsIEh1bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPiZndDsgd3JvdGU6PC9wPg0KPC9k aXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tYm90dG9tOiAxMnB0OyAiPiZuYnNwOzxiciBjbGFzcz0i d2Via2l0LWJsb2NrLXBsYWNlaG9sZGVyIj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8aDE+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5KU09OIFdlYiBUb2tlbiAoSldUKSBCZWFyZXIgVG9rZW4gUHJvZmlsZXMgZm9y IE9BdXRoIDIuMDwvc3Bhbj48L2gxPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IiI+PGJy Pg0KTm90ZSB0aGUgdGl0bGUgc2F5cyAmcXVvdDtmb3IgT0F1dGgyJnF1b3Q7PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iIj4mbmJzcDs8YnIgY2xhc3M9IndlYmtpdC1ibG9jay1wbGFj ZWhvbGRlciI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSIiPlNvcnJ5LiBDb3VsZG4ndCByZXNpc3QuJm5ic3A7PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0iIj4mbmJzcDs8YnIgY2xhc3M9IndlYmtpdC1ibG9jay1wbGFjZWhvbGRlciI+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSIiPlBo aWw8L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iIj4mbmJzcDs8YnIgY2xhc3M9IndlYmtpdC1ibG9j ay1wbGFjZWhvbGRlciI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSIiPlNlbnQgZnJvbSBteSBwaG9uZS48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJy Pg0KT24gMjAxMy0wMi0yOCwgYXQgOTo0MCwgSm9obiBCcmFkbGV5ICZsdDs8YSBocmVmPSJtYWls dG86dmU3anRiQHZlN2p0Yi5jb20iIHRhcmdldD0iX2JsYW5rIj52ZTdqdGJAdmU3anRiLmNvbTwv YT4mZ3Q7IHdyb3RlOjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i Ij5KV1QgaXMgYW4gYXNzZXJ0aW9uKCBJIGFtIHByb2JhYmx5IGdvaW5nIHRvIHJlZ3JldCB1c2lu ZyB0aGF0IHdvcmQpLjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSIiPiZuYnNwOzxiciBjbGFzcz0i d2Via2l0LWJsb2NrLXBsYWNlaG9sZGVyIj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9IiI+SXQgaXMgdXNlZCBpbiBvcGVuSUQgY29ubmVjdCBmb3Ig aWRfdG9rZW5zLCBpdCBpcyB1c2VkIGluIE9BdXRoIGZvciBBc3NlcnRpb24gZ3JhbnQgdHlwZXMg YW5kIGF1dGhlbnRpY2F0aW9uIG9mIHRoZSBjbGllbnQgdG8gdGhlIHRva2VuIGVuZHBvaW50Ljwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSIiPjxhIGhyZWY9 Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtand0LWJlYXJlci0w NCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt b2F1dGgtand0LWJlYXJlci0wNDwvYT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSIi PiZuYnNwOzxiciBjbGFzcz0id2Via2l0LWJsb2NrLXBsYWNlaG9sZGVyIj4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7PC9z cGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7PC9z cGFuPjwvcHJlPg0KPGgxPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5KU09OIFdlYiBUb2tlbiAoSldUKSBCZWFyZXIgVG9r ZW4gUHJvZmlsZXMgZm9yIE9BdXRoIDIuMDwvc3Bhbj48L2gxPg0KPGRpdj4NCjxkaXYgc3R5bGU9 IiI+Jm5ic3A7PGJyIGNsYXNzPSJ3ZWJraXQtYmxvY2stcGxhY2Vob2xkZXIiPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iIj5Eb3Nlbid0IGRlZmlu ZSBKV1QncyB1c2UgZm9yIGFjY2VzcyB0b2tlbnMgZm9yIHRoZSBSUy4gJm5ic3A7Jm5ic3A7PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iIj4mbmJzcDs8YnIgY2xhc3M9IndlYmtpdC1i bG9jay1wbGFjZWhvbGRlciI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSIiPkJvdHRvbSBsaW5lIEpXVCBpcyBmb3IgbW9yZSB0aGFuIGFjY2VzcyB0 b2tlbnMuPC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iIj4mbmJzcDs8YnIgY2xhc3M9 IndlYmtpdC1ibG9jay1wbGFjZWhvbGRlciI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSIiPkpvaG4gQi48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSIiPiZuYnNwOzxiciBjbGFzcz0id2Via2l0LWJsb2NrLXBsYWNlaG9sZGVyIj4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSIi Pk9uIDIwMTMtMDItMjgsIGF0IDk6MjggQU0sIFBoaWwgSHVudCAmbHQ7PGEgaHJlZj0ibWFpbHRv OnBoaWwuaHVudEBvcmFjbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+cGhpbC5odW50QG9yYWNsZS5j b208L2E+Jmd0OyB3cm90ZTo8L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1ib3R0b206 IDEycHQ7ICI+Jm5ic3A7PGJyIGNsYXNzPSJ3ZWJraXQtYmxvY2stcGxhY2Vob2xkZXIiPg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSIiPkFyZSB5b3Ug c2F5aW5nIGp3dCBpcyBub3QgYW4gYWNjZXNzIHRva2VuIHR5cGU/PGJyPg0KPGJyPg0KUGhpbDwv cD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSIiPiZuYnNwOzxiciBjbGFzcz0id2Via2l0LWJsb2NrLXBs YWNlaG9sZGVyIj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9IiI+U2VudCBmcm9tIG15IHBob25lLjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpP biAyMDEzLTAyLTI4LCBhdCA4OjU4LCBKb2huIEJyYWRsZXkgJmx0OzxhIGhyZWY9Im1haWx0bzp2 ZTdqdGJAdmU3anRiLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnZlN2p0YkB2ZTdqdGIuY29tPC9hPiZn dDsgd3JvdGU6PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSIiPlll cywgZGVmaW5pbmcgc2NvcGUgaW4gSldUIGlzIHRoZSB3cm9uZyBwbGFjZS4gJm5ic3A7IEpXVCBu ZWVkcyB0byBzdGljayB0byB0aGUgc2VjdXJpdHkgY2xhaW1zIG5lZWRlZCB0byBwcm9jZXNzIEpX VC48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iIj4mbmJzcDs8YnIgY2xhc3M9IndlYmtpdC1ibG9j ay1wbGFjZWhvbGRlciI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSIiPkkgYWxzbyBkb24ndCBrbm93IGhvdyBmYXIgeW91IGdldCByZXF1aXJpbmcg YSBzcGVjaWZpYyBhdXRob3JpemF0aW9uIGZvcm1hdCBmb3IgSldULCBzb21lIEFTIHdpbGwgd2Fu IHRvIHVzZSBhIG9wYXF1ZSByZWZlcmVuY2UsIHNvbWUgbWlnaHQgd2FudCB0byB1c2UgYSB1c2Vy IGNsYWltIG9yIHJvbGUgY2xhaW0sIG90aGVycyBtYXkgdXNlIHNjb3BlcywgJm5ic3A7Y29tYmlu aW5nIHNjb3BlcyBhbmQgY2xhaW1zDQogaXMgYWxzbyBwb3NzaWJsZS48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2IHN0eWxlPSIiPiZuYnNwOzxiciBjbGFzcz0id2Via2l0LWJsb2NrLXBsYWNlaG9s ZGVyIj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 IiI+UmlnaHQgbm93IGl0IGlzIHVwIHRvIGEgQVMgUlMgcGFpciB0byBhZ3JlZSBvbiBob3cgdG8g Y29tbXVuaWNhdGUgYXV0aG9yaXphdGlvbi4gJm5ic3A7IEkgZG9uJ3Qgd2FudCBNQUMgdG8gYmUg bW9yZSByZXN0cmljdGl2ZSB0aGFuIGJlYXJlciB3aGVuIGl0IGNvbWVzIHRvIGF1dGhvcml6YXRp b24gYmV0d2VlbiBBUyBhbmQgUlMuPC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9IiI+Jm5ic3A7PGJy IGNsYXNzPSJ3ZWJraXQtYmxvY2stcGxhY2Vob2xkZXIiPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iIj5IYW5uZXMgd2FudGVkIHRvIGtub3cgd2h5 IEpXVCBkaWRuJ3QgZGVmaW5lIHNjb3BlLiAmbmJzcDtUaGUgc2ltcGxlIGFuc3dlciBpcyB0aGF0 IGl0IGlzIG91dCBvZiBzY29wZSBmb3IgSldUIGl0c2VsZi4gJm5ic3A7IEl0IG1pZ2h0IGJlIGRl ZmluZWQgaW4gYSBPQXV0aCBhY2Nlc3MgdG9rZW4gcHJvZmlsZSBmb3IgSldUIGJ1dCBpdCBzaG91 bGQgbm90IGJlIHNwZWNpZmljIHRvIE1BQy48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxl PSIiPiZuYnNwOzxiciBjbGFzcz0id2Via2l0LWJsb2NrLXBsYWNlaG9sZGVyIj4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IiI+Sm9obiBCLjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 IiI+T24gMjAxMy0wMi0yOCwgYXQgODo0NCBBTSwgQnJpYW4gQ2FtcGJlbGwgJmx0OzxhIGhyZWY9 Im1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmJjYW1w YmVsbEBwaW5naWRlbnRpdHkuY29tPC9hPiZndDsgd3JvdGU6PC9wPg0KPC9kaXY+DQo8ZGl2IHN0 eWxlPSJtYXJnaW4tYm90dG9tOiAxMnB0OyAiPiZuYnNwOzxiciBjbGFzcz0id2Via2l0LWJsb2Nr LXBsYWNlaG9sZGVyIj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkkgdGhpbmsgSm9obidzIHBvaW50IHdhcyBt b3JlIHRoYXQgc2NvcGUgaXMgc29tZXRoaW5nIHJhdGhlciBzcGVjaWZpYyB0byBhbiBPQXV0aCBh Y2Nlc3MgdG9rZW4gYW5kLCB3aGlsZSBKV1QgaXMgY2FuIGJlIHVzZWQgdG8gcmVwcmVzZW50IGFu IGFjY2VzcyB0b2tlbiwgaXQncyBub3QgdGhlIG9ubHkgYXBwbGljYXRpb24gb2YgSldULiBUaGUg J3N0YW5kYXJkJw0KIGNsYWltcyBpbiBKV1QgYXJlIHRob3NlIHRoYXQgYXJlIGJlbGlldmVkIChy aWdodCBvciB3cm9uZykgdG8gYmUgd2lkZWx5IGFwcGxpY2FibGUgYWNyb3NzIGRpZmZlcmVudCBh cHBsaWNhdGlvbnMgb2YgSldULiBPbmUgY291bGQgYXJndWUgYWJvdXQgaXQgYnV0IHNjb3BlIGlz IHByb2JhYmx5IG5vdCBvbmUgb2YgdGhvc2UuPC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iIj5JdCB3b3VsZCBwcm9iYWJseSBtYWtlIHNlbnNlIHRvIHRyeSBhbmQgYnVp bGQgYSBwcm9maWxlIG9mIEpXVCBzcGVjaWZpY2FsbHkgZm9yIE9BdXRoIGFjY2VzcyB0b2tlbnMg KHRob3VnaCBJIHN1c3BlY3QgdGhlcmUgYXJlIHNvbWUgdHVydGxlcyBhbmQgZHJhZ29ucyBpbiB0 aGVyZSksIHdoaWNoIG1pZ2h0IGJlIHRoZSBhcHByb3ByaWF0ZSBwbGFjZSB0byBkZWZpbmUvcmVn aXN0ZXIgYSBzY29wZQ0KIGNsYWltLjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1h cmdpbi1ib3R0b206IDEycHQ7ICI+Jm5ic3A7PGJyIGNsYXNzPSJ3ZWJraXQtYmxvY2stcGxhY2Vo b2xkZXIiPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IiI+T24g VGh1LCBGZWIgMjgsIDIwMTMgYXQgOToyNCBBTSwgUGhpbCBIdW50ICZsdDs8YSBocmVmPSJtYWls dG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5waGlsLmh1bnRAb3JhY2xl LmNvbTwvYT4mZ3Q7IHdyb3RlOjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSIiPkFy ZSB5b3UgYWR2b2NhdGluZyBUV08gc3lzdGVtcz8gVGhhdCBzZWVtcyBsaWtlIGEgYmFkIGNob2lj ZS48YnI+DQo8YnI+DQpJIHdvdWxkIHJhdGhlciBmaXggc2NvcGUgdGhhbiBnbyB0byBhIHR3byBz eXN0ZW0gYXBwcm9hY2guPGJyPg0KPGJyPg0KUGhpbDxicj4NCjxicj4NClNlbnQgZnJvbSBteSBw aG9uZS48YnI+DQo8YnI+DQpPbiAyMDEzLTAyLTI4LCBhdCA4OjE3LCBKb2huIEJyYWRsZXkgJmx0 OzxhIGhyZWY9Im1haWx0bzp2ZTdqdGJAdmU3anRiLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnZlN2p0 YkB2ZTdqdGIuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KPGJyPg0KJmd0OyBXaGlsZSBzY29wZSBp cyBvbmUgbWV0aG9kIHRoYXQgYSBBUyBjb3VsZCBjb21tdW5pY2F0ZSBhdXRob3JpemF0aW9uIHRv IGEgUlMsIGl0IGlzIG5vdCB0aGUgb25seSBvciBwZXJoYXBzIGV2ZW4gdGhlIG1vc3QgbGlrZWx5 IG9uZS48YnI+DQomZ3Q7IFVzaW5nIHNjb3BlIHJlcXVpcmVzIGEgcmVsYXRpdmVseSB0aWdodCBi aW5kaW5nIGJldHdlZW4gdGhlIFJTIGFuZCBBUywgJm5ic3A7VU1BIHVzZXMgYSBkaWZmZXJlbnQg bWVjaGFuaXNtIHRoYXQgZGVzY3JpYmVzIGZpbmVyIGdyYWluZWQgb3BlcmF0aW9ucy48YnI+DQom Z3Q7IFRoZSBBUyBtYXkgaW5jbHVkZSByb2xlcywgdXNlciwgb3Igb3RoZXIgbW9yZSBhYnN0cmFj dCBjbGFpbXMgdGhhdCB0aGUgdGhlIGNsaWVudCBtYXkgKGdvZCBoZWxwIHRoZW0pIHBhc3Mgb24g dG8gRVhDTUwgZm9yIHByb2Nlc3NpbmcuPGJyPg0KJmd0Ozxicj4NCiZndDsgV2hpbGUgaGF2aW5n IGEgc2NvcGVzIGNsYWltIGlzIHBvc3NpYmxlLCBsaWtlIGFueSBvdGhlciBjbGFpbSBpdCBpcyBu b3QgcGFydCBvZiB0aGUgSldUIGNvcmUgc2VjdXJpdHkgcHJvY2Vzc2luZyBjbGFpbXMsIGFuZCBu ZWVkcyB0byBiZSBkZWZpbmVkIGJ5IGV4dGVuc2lvbi48YnI+DQomZ3Q7PGJyPg0KJmd0OyBKb2hu IEIuPGJyPg0KJmd0OyBPbiAyMDEzLTAyLTI4LCBhdCAyOjI5IEFNLCBIYW5uZXMgVHNjaG9mZW5p ZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQiIHRhcmdldD0i X2JsYW5rIj5oYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0PC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0 Ozxicj4NCiZndDsmZ3Q7IEhpIE1pa2UsPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyB3aGVu IEkgd29ya2VkIG9uIHRoZSBNQUMgc3BlY2lmaWNhdGlvbiBJIG5vdGljZWQgdGhhdCB0aGUgSldU IGRvZXMgbm90IGhhdmUgYSBjbGFpbSBmb3IgdGhlIHNjb3BlLiBJIGJlbGlldmUgdGhhdCB0aGlz IHdvdWxkIGJlIG5lZWRlZCB0byBhbGxvdyB0aGUgcmVzb3VyY2Ugc2VydmVyIHRvIHZlcmlmeSB3 aGV0aGVyIHRoZSBzY29wZSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYXV0aG9yaXplZCBpcyBp bmRlZWQgd2hhdCB0aGUgY2xpZW50DQogaXMgYXNraW5nIGZvci48YnI+DQomZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7IENpYW88YnI+DQomZ3Q7Jmd0OyBIYW5uZXM8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0KJmd0OyZndDsgT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KJmd0OyZndDsgPGEgaHJlZj0ibWFp bHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJy Pg0KJmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vb2F1dGg8L2E+PGJyPg0KJmd0Ozxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxi cj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48YnI+DQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4N CjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGll dGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL29hdXRoPC9hPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iIj4mbmJzcDs8YnIg Y2xhc3M9IndlYmtpdC1ibG9jay1wbGFjZWhvbGRlciI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2IHN0eWxlPSIiPiZuYnNwOzxiciBjbGFzcz0id2Via2l0LWJsb2NrLXBsYWNlaG9sZGVy Ij4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2IHN0eWxlPSIiPiZuYnNwOzxiciBjbGFzcz0id2Via2l0LWJsb2NrLXBsYWNlaG9sZGVy Ij4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBz dHlsZT0iIj4mbmJzcDs8YnIgY2xhc3M9IndlYmtpdC1ibG9jay1wbGFjZWhvbGRlciI+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSIi PiZuYnNwOzxiciBjbGFzcz0id2Via2l0LWJsb2NrLXBsYWNlaG9sZGVyIj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iIj4mbmJzcDs8YnIgY2xhc3M9IndlYmtpdC1ibG9jay1w bGFjZWhvbGRlciI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0 Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPC9wPg0KPGRpdj4NCjxkaXY+Jm5i c3A7PGJyIGNsYXNzPSJ3ZWJraXQtYmxvY2stcGxhY2Vob2xkZXIiPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tIDxicj4NCk5hdCBTYWtpbXVyYSAoPW5hdCk8L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9uPGJy Pg0KPGEgaHJlZj0iaHR0cDovL25hdC5zYWtpbXVyYS5vcmcvIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cDovL25hdC5zYWtpbXVyYS5vcmcvPC9hPjxicj4NCkBfbmF0X2VuPC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0 aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9vYXV0aDwvYT48L3A+DQo8L2Rpdj4NCjxkaXY+Jm5ic3A7PGJyIGNsYXNz PSJ3ZWJraXQtYmxvY2stcGxhY2Vob2xkZXIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpP QXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxi cj4NCjxkaXYgYXBwbGUtY29udGVudC1lZGl0ZWQ9InRydWUiPg0KPGRpdiBzdHlsZT0iZm9udC1m YW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiBtZWRpdW07IGZvbnQtc3R5bGU6IG5vcm1hbDsg Zm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5n OiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IDI7IHRleHQtYWxpZ246IC13 ZWJraXQtYXV0bzsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRl LXNwYWNlOiBub3JtYWw7IHdpZG93czogMjsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4 dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB3b3Jk LXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5l LWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgIj4NCjxzcGFuIGNsYXNzPSJBcHBsZS1zdHlsZS1z cGFuIiBzdHlsZT0iYm9yZGVyLWNvbGxhcHNlOiBzZXBhcmF0ZTsgYm9yZGVyLXNwYWNpbmc6IDBw eDsgIj48c3BhbiBjbGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIgc3R5bGU9ImZvbnQtZmFtaWx5OiBD b3VyaWVyOyAiPjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQpFdmUgTWFs ZXIgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOzxhIGhyZWY9Imh0dHA6Ly93d3cueG1sZ3JybC5jb20vYmxvZyI+aHR0cDovL3d3dy54 bWxncnJsLmNvbS9ibG9nPC9hPjxicj4NCiYjNDM7MSA0MjUgMzQ1IDY3NTYgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsmbmJzcDs8YSBocmVmPSJodHRwOi8vd3d3LnR3aXR0ZXIuY29tL3htbGdy cmwiPmh0dHA6Ly93d3cudHdpdHRlci5jb20veG1sZ3JybDwvYT48L3NwYW4+PC9zcGFuPjwvZGl2 Pg0KPC9kaXY+DQo8YnI+DQo8L2Rpdj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFp bHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8YnI+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_B33BFB58CCC8BE4998958016839DE27E08F3EB54IMCMBX01MITREOR_-- From prateek.mishra@oracle.com Mon Mar 11 13:27: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 6FF5421F900F for ; Mon, 11 Mar 2013 13:27:57 -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 J5dA9GGLDaX2 for ; Mon, 11 Mar 2013 13:27:51 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 9C99321F8E67 for ; Mon, 11 Mar 2013 13:27: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 r2BKRnkY012676 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 11 Mar 2013 20:27:49 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r2BKRmrE010258 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Mar 2013 20:27:48 GMT Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r2BKRmEP003290; Mon, 11 Mar 2013 15:27:48 -0500 Received: from [130.129.23.121] (/130.129.23.121) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 11 Mar 2013 13:27:47 -0700 Message-ID: <513E3E5D.4020006@oracle.com> Date: Mon, 11 Mar 2013 16:28:13 -0400 From: prateek mishra Organization: Oracle Corporation User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: oauth@ietf.org, sakimura@gmail.com References: <0EC2404F-E3C5-4AD1-88B4-E74AA0394DD9@gmx.net> <48FD87D1-4DF4-4289-99B7-40A515F31890@oracle.com> <3E472720-31A4-40A0-AAA4-402CF850831A@ve7jtb.com> <7127843B-D7B0-4AB6-87F1-1604D1EFFA79@oracle.com> <50DA292F-32F0-4266-8401-006AD837B775@ve7jtb.com> <59E470B10C4630419ED717AC79FCF9A948D58BEE@BY2PRD0411MB441.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A948D58DC0@BY2PRD0411MB441.namprd04.prod.outlook.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050409000600020808010004" X-Source-IP: acsinet21.oracle.com [141.146.126.237] Subject: Re: [OAUTH-WG] JWT - scope claim missing X-BeenThere: oauth@ietf.org X-Mailman-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, 11 Mar 2013 20:27:57 -0000 This is a multi-part message in MIME format. --------------050409000600020808010004 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Nat - I think this kind of document ("JWT profile of the OAuth access token") would be very helpful to the community (+1 to Adam's comment). IMO there may be value in keeping it separate from the introspection draft which is a kind of API for validating/querying assertion contents. My guess is that developers/deployers will use one of these two approaches, not both. - prateek > So, it is soooo late in the game: I have been completely underwater to > even read the OAuth mails for about a month and slowly catching up now. > > Here is an I-D that I have created partly in response to the RS-AS > interaction piece that was talked about at IETF 85. > It does not have 'scope' and has 'claims' instead as it was based on > OpenID Connect, but it is easy to add, provided that the scopes are to > be understood as that of the 'aud'. > > http://tools.ietf.org/id/draft-sakimura-oidc-structured-token-01.txt > > Best, > > Nat > > 2013/3/1 Lewis Adam-CAL022 > > > Hmmm, I'm not so sure. It depends where we all think OAuth is on > its trajectory. On one hand, OAuth has already seen an insanely > massive amount of deployment. On the other hand, RESTful APIs see > no sign of slowing down. Now I'm not going to go so far as Craig > B. and say that everything and everyone will be API enabled in the > future, but it sure is going to be a lot. That being said, one > could argue that even with all the OAuth implementation we've > seen, that this is just the infancy of it. Obviously a WG profile > of a JWT-structured AT could not deprecate other forms > (unstructured, SAML, etc.) but going forward new developers may > choose to embrace this, and in fact this could even be the > guidance. I agree with previous comments that Justin's > introspection draft might be a good place to explore this. > > adam > > *From:*Brian Campbell [mailto:bcampbell@pingidentity.com > ] > *Sent:* Thursday, February 28, 2013 1:36 PM > *To:* Lewis Adam-CAL022 > *Cc:* John Bradley; oauth@ietf.org WG > > > *Subject:* Re: [OAUTH-WG] JWT - scope claim missing > > I do agree that a WG profile of a JWT-structured access token > could lend itself to interoperability and ultimately be a useful > thing. But you are right that there already are many > implementations out there in the wild (heck, I've written one > myself) and that might make it difficult to standardize on something. > > Because of that, and many other reasons, I don't want to try and > add that to existing assertion drafts. > > On Thu, Feb 28, 2013 at 12:13 PM, Lewis Adam-CAL022 > > wrote: > > Hi Brian, a few thoughts from somebody outside of the WG ... > > As a newcomer to OAuth last year, I was initially confused by the > titles. It was confusing because we have SAML bearer > **assertions** and JWT bearer **tokens** ... and as John just > (begrudgingly) stated in this thread, the JWT is being used as an > assertion in this profile (and in OIDC). I think it will be > difficult to find a good name for these profiles since they do two > entirely different things (e.g. define a new grant type and define > a new method of client authentication). One could argue that as > long as the WG is at it, then why not add a third section to the > JWT profile, which talks about usage of JWT-structured bearer > access tokens: it would not be any less related than the other two > focuses of the doc. Then the document could be called something > simple like "profiles of JWT usage in OAuth" or something like that. > > On one hand, it is probably naïve to think that an access token > can be standardized in a profile given how many have already been > released into the wild, but on the other hand, a WG profile of a > JWT-structured access token could lend itself to interoperability, > where AS implementations can advertise conformance to the profile > and who knows ... maybe the RS's of the future will be good with > this. > > adam > > *From:*oauth-bounces@ietf.org > [mailto:oauth-bounces@ietf.org ] > *On Behalf Of *Brian Campbell > *Sent:* Thursday, February 28, 2013 1:03 PM > *To:* John Bradley > *Cc:* oauth@ietf.org WG > > > *Subject:* Re: [OAUTH-WG] JWT - scope claim missing > > I'm not sure anyone really "picked" the titles for the bearer > token profiles. They just kind of evolved. And evolved in funny > ways especially when client authn to the AS was added. > > You won't hear me argue that the titles are "good" and this is not > the first time there's been confusion about what they actually do. > They define new grant types and new client authentication methods. > They *do not* define an access token format or anything else about > access tokens. JWT and SAML could be used for that but that's not > what these drafts do. > > Suggestions for better title(s) would be more than welcome. > > Here's what they are now: > > > SAML 2.0 Bearer Assertion Profiles for OAuth 2.0 > draft-ietf-oauth-saml2-bearer > > JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0 > draft-ietf-oauth-jwt-bearer > > Assertion Framework for OAuth 2.0 > draft-ietf-oauth-assertions > > On Thu, Feb 28, 2013 at 11:36 AM, John Bradley > wrote: > > Yes the title likely adds to the confusion given that the bearer > tokens are not access tokens. > > Things as separate from OAuth as the Firefox browerID spec use JWS > signed JWTs. > > The bearer token profiles for OAuth 2 are for OAuth2. > > The JSON Web Token (JWT) > spec > did not start in OAuth and is not OAuth specific. > > A JWT is: > > JSON Web Token (JWT) A string representing a set of claims as a JSON > > object that is encoded in a JWS or JWE, enabling the claims to be > > digitally signed or MACed and/or encrypted. > > So OAuth or other profiles may define claims to go in a JWT, but > the JWT needs to itself only define the claims necessary for > security processing. > > John B. > > PS that was a soft ball If you hadn't responded I would have been > disappointed. I din't pick the title for the bearer token profiles. > > On 2013-02-28, at 10:12 AM, Phil Hunt > wrote: > > > JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0 > > > Note the title says "for OAuth2" > > Sorry. Couldn't resist. > > Phil > > Sent from my phone. > > > On 2013-02-28, at 9:40, John Bradley > wrote: > > JWT is an assertion( I am probably going to regret using that > word). > > It is used in openID connect for id_tokens, it is used in > OAuth for Assertion grant types and authentication of the > client to the token endpoint. > > http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-04 > > > > > > > JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0 > > Dosen't define JWT's use for access tokens for the RS. > > Bottom line JWT is for more than access tokens. > > John B. > > On 2013-02-28, at 9:28 AM, Phil Hunt > wrote: > > Are you saying jwt is not an access token type? > > Phil > > Sent from my phone. > > > On 2013-02-28, at 8:58, John Bradley > wrote: > > Yes, defining scope in JWT is the wrong place. JWT needs > to stick to the security claims needed to process JWT. > > I also don't know how far you get requiring a specific > authorization format for JWT, some AS will wan to use a > opaque reference, some might want to use a user claim or > role claim, others may use scopes, combining scopes and > claims is also possible. > > Right now it is up to a AS RS pair to agree on how to > communicate authorization. I don't want MAC to be more > restrictive than bearer when it comes to authorization > between AS and RS. > > Hannes wanted to know why JWT didn't define scope. The > simple answer is that it is out of scope for JWT itself. > It might be defined in a OAuth access token profile for > JWT but it should not be specific to MAC. > > John B. > > On 2013-02-28, at 8:44 AM, Brian Campbell > > wrote: > > I think John's point was more that scope is something > rather specific to an OAuth access token and, while JWT is > can be used to represent an access token, it's not the > only application of JWT. The 'standard' claims in JWT are > those that are believed (right or wrong) to be widely > applicable across different applications of JWT. One could > argue about it but scope is probably not one of those. > > It would probably make sense to try and build a profile of > JWT specifically for OAuth access tokens (though I suspect > there are some turtles and dragons in there), which might > be the appropriate place to define/register a scope claim. > > On Thu, Feb 28, 2013 at 9:24 AM, Phil Hunt > > wrote: > > Are you advocating TWO systems? That seems like a bad choice. > > I would rather fix scope than go to a two system approach. > > Phil > > Sent from my phone. > > On 2013-02-28, at 8:17, John Bradley > wrote: > > > While scope is one method that a AS could communicate > authorization to a RS, it is not the only or perhaps even > the most likely one. > > Using scope requires a relatively tight binding between > the RS and AS, UMA uses a different mechanism that > describes finer grained operations. > > The AS may include roles, user, or other more abstract > claims that the the client may (god help them) pass on to > EXCML for processing. > > > > While having a scopes claim is possible, like any other > claim it is not part of the JWT core security processing > claims, and needs to be defined by extension. > > > > John B. > > On 2013-02-28, at 2:29 AM, Hannes Tschofenig > > wrote: > > > >> Hi Mike, > >> > >> when I worked on the MAC specification I noticed that > the JWT does not have a claim for the scope. I believe > that this would be needed to allow the resource server to > verify whether the scope the authorization server > authorized is indeed what the client is asking for. > >> > >> Ciao > >> Hannes > >> > >> _______________________________________________ > >> OAuth mailing 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 > > > > > -- > 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 --------------050409000600020808010004 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Nat -

I think this kind of document ("JWT profile of the OAuth access token") would be very helpful to the community (+1 to Adam's comment).

IMO there may be value in keeping it separate from the introspection draft which is a kind of API for validating/querying assertion contents.

My guess is that developers/deployers will use one of these two approaches, not both.

- prateek

So, it is soooo late in the game: I have been completely underwater to even read the OAuth mails for about a month and slowly catching up now. 

Here is an I-D that I have created partly in response to the RS-AS interaction piece that was talked about at IETF 85. 
It does not have 'scope' and has 'claims' instead as it was based on OpenID Connect, but it is easy to add, provided that the scopes are to be understood as that of the 'aud'. 


Best, 

Nat

2013/3/1 Lewis Adam-CAL022 <Adam.Lewis@motorolasolutions.com>

Hmmm, I’m not so sure.  It depends where we all think OAuth is on its trajectory.  On one hand, OAuth has already seen an insanely massive amount of deployment.  On the other hand, RESTful APIs see no sign of slowing down.   Now I’m not going to go so far as Craig B. and say that everything and everyone will be API enabled in the future, but it sure is going to be a lot.  That being said, one could argue that even with all the OAuth implementation we’ve seen, that this is just the infancy of it.  Obviously a WG profile of a JWT-structured AT could not deprecate other forms (unstructured, SAML, etc.) but going forward new developers may choose to embrace this, and in fact this could even be the guidance.   I agree with previous comments that Justin’s introspection draft might be a good place to explore this.

 

adam

 

From: Brian Campbell [mailto:bcampbell@pingidentity.com]
Sent: Thursday, February 28, 2013 1:36 PM
To: Lewis Adam-CAL022
Cc: John Bradley; oauth@ietf.org WG


Subject: Re: [OAUTH-WG] JWT - scope claim missing

 

I do agree that a WG profile of a JWT-structured access token could lend itself to interoperability and ultimately be a useful thing. But you are right that there already are many implementations out there in the wild (heck, I've written one myself) and that might make it difficult to standardize on something.

Because of that, and many other reasons, I don't want to try and add that to existing assertion drafts.

 

On Thu, Feb 28, 2013 at 12:13 PM, Lewis Adam-CAL022 <Adam.Lewis@motorolasolutions.com> wrote:

Hi Brian, a few thoughts from somebody outside of the WG …

 

As a newcomer to OAuth last year, I was initially confused by the titles.  It was confusing because we have SAML bearer *assertions* and JWT bearer *tokens* … and as John just (begrudgingly) stated in this thread, the JWT is being used as an assertion in this profile (and in OIDC).  I think it will be difficult to find a good name for these profiles since they do two entirely different things (e.g. define a new grant type and define a new method of client authentication).  One could argue that as long as the WG is at it, then why not add a third section to the JWT profile, which talks about usage of JWT-structured bearer access tokens: it would not be any less related than the other two focuses of the doc.  Then the document could be called something simple like “profiles of JWT usage in OAuth” or something like that. 

 

On one hand, it is probably naïve to think that an access token can be standardized in a profile given how many have already been released into the wild, but on the other hand, a WG profile of a JWT-structured access token could lend itself to interoperability, where AS implementations can advertise conformance to the profile and who knows … maybe the RS’s of the future will be good with this. 

 

adam

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Brian Campbell
Sent: Thursday, February 28, 2013 1:03 PM
To: John Bradley
Cc: oauth@ietf.org WG


Subject: Re: [OAUTH-WG] JWT - scope claim missing

 

I'm not sure anyone really "picked" the titles for the bearer token profiles. They just kind of evolved. And evolved in funny ways especially when client authn to the AS was added.

You won't hear me argue that the titles are "good" and this is not the first time there's been confusion about what they actually do. They define new grant types and new client authentication methods. They *do not* define an access token format or anything else about access tokens. JWT and SAML could be used for that but that's not what these drafts do.

Suggestions for better title(s) would be more than welcome.

 

Here's what they are now:


SAML 2.0 Bearer Assertion Profiles for OAuth 2.0
draft-ietf-oauth-saml2-bearer

JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0
draft-ietf-oauth-jwt-bearer

Assertion Framework for OAuth 2.0
draft-ietf-oauth-assertions

 

On Thu, Feb 28, 2013 at 11:36 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:

Yes the title likely adds to the confusion given that the bearer tokens are not access tokens.

 

Things as separate from OAuth as the Firefox browerID spec use JWS signed JWTs.  

 

The bearer token profiles for OAuth 2 are for OAuth2.

 

The JSON Web Token (JWT) spec did not start in OAuth and is not OAuth specific.

 

A JWT is:

JSON Web Token (JWT)  A string representing a set of claims as a JSON
      object that is encoded in a JWS or JWE, enabling the claims to be
      digitally signed or MACed and/or encrypted.

 

So OAuth or other profiles may define claims to go in a JWT, but the JWT needs to itself only define the claims necessary for security processing.  

 

John B.

PS that was a soft ball If you hadn't responded I would have been disappointed.  I din't pick the title for the bearer token profiles.

 

 

On 2013-02-28, at 10:12 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

 

JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0


Note the title says "for OAuth2"

 

Sorry. Couldn't resist. 

 

Phil

 

Sent from my phone.


On 2013-02-28, at 9:40, John Bradley <ve7jtb@ve7jtb.com> wrote:

JWT is an assertion( I am probably going to regret using that word).

 

It is used in openID connect for id_tokens, it is used in OAuth for Assertion grant types and authentication of the client to the token endpoint.

 

 
 

JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0

 

Dosen't define JWT's use for access tokens for the RS.   

 

Bottom line JWT is for more than access tokens.

 

John B.

 

On 2013-02-28, at 9:28 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

 

Are you saying jwt is not an access token type?

Phil

 

Sent from my phone.


On 2013-02-28, at 8:58, John Bradley <ve7jtb@ve7jtb.com> wrote:

Yes, defining scope in JWT is the wrong place.   JWT needs to stick to the security claims needed to process JWT.

 

I also don't know how far you get requiring a specific authorization format for JWT, some AS will wan to use a opaque reference, some might want to use a user claim or role claim, others may use scopes,  combining scopes and claims is also possible.

 

Right now it is up to a AS RS pair to agree on how to communicate authorization.   I don't want MAC to be more restrictive than bearer when it comes to authorization between AS and RS.

 

Hannes wanted to know why JWT didn't define scope.  The simple answer is that it is out of scope for JWT itself.   It might be defined in a OAuth access token profile for JWT but it should not be specific to MAC.

 

John B.

On 2013-02-28, at 8:44 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:

 

I think John's point was more that scope is something rather specific to an OAuth access token and, while JWT is can be used to represent an access token, it's not the only application of JWT. The 'standard' claims in JWT are those that are believed (right or wrong) to be widely applicable across different applications of JWT. One could argue about it but scope is probably not one of those.

It would probably make sense to try and build a profile of JWT specifically for OAuth access tokens (though I suspect there are some turtles and dragons in there), which might be the appropriate place to define/register a scope claim.

 

On Thu, Feb 28, 2013 at 9:24 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

Are you advocating TWO systems? That seems like a bad choice.

I would rather fix scope than go to a two system approach.

Phil

Sent from my phone.

On 2013-02-28, at 8:17, John Bradley <ve7jtb@ve7jtb.com> wrote:

> While scope is one method that a AS could communicate authorization to a RS, it is not the only or perhaps even the most likely one.
> Using scope requires a relatively tight binding between the RS and AS,  UMA uses a different mechanism that describes finer grained operations.
> The AS may include roles, user, or other more abstract claims that the the client may (god help them) pass on to EXCML for processing.
>
> While having a scopes claim is possible, like any other claim it is not part of the JWT core security processing claims, and needs to be defined by extension.
>
> John B.
> On 2013-02-28, at 2:29 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
>
>> Hi Mike,
>>
>> when I worked on the MAC specification I noticed that the JWT does not have a claim for the scope. I believe that this would be needed to allow the resource server to verify whether the scope the authorization server authorized is indeed what the client is asking for.
>>
>> Ciao
>> Hannes
>>
>> _______________________________________________
>> OAuth mailing 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




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

--------------050409000600020808010004-- From jricher@mitre.org Mon Mar 11 14:15: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 6E0D921F8F0A for ; Mon, 11 Mar 2013 14:15:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.464 X-Spam-Level: X-Spam-Status: No, score=-6.464 tagged_above=-999 required=5 tests=[AWL=0.135, 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 rmhCpRgcCDhs for ; Mon, 11 Mar 2013 14:15:17 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id D3E0B21F8F4A for ; Mon, 11 Mar 2013 14:15:11 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 0D4521F051E for ; Mon, 11 Mar 2013 17:15:11 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 01AB61F04F7 for ; Mon, 11 Mar 2013 17:15:11 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.59]) by IMCCAS01.MITRE.ORG ([129.83.29.68]) with mapi id 14.02.0318.004; Mon, 11 Mar 2013 17:15:10 -0400 From: "Richer, Justin P." To: "oauth@ietf.org WG" Thread-Topic: Registration: Internationalization of Human-Readable names Thread-Index: AQHOHp2D44pYbE8oI0KylL+zHw2NHA== Date: Mon, 11 Mar 2013 21:15:09 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.33.35] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OAUTH-WG] Registration: Internationalization of Human-Readable names X-BeenThere: oauth@ietf.org X-Mailman-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, 11 Mar 2013 21:15:17 -0000 It was brought up at the in-person meeting today that we'll want to conside= r issues around internationalization and localization of human-readable fie= lds like client_name in the client registration. Which is to say: if a clie= nt supports ten languages and wants to present itself in ten languages, sho= uld it have to register itself ten times with an AS? At the moment, I'm of the opinion a client with ten languages could registe= r itself ten times, or do something with the context in which it runs to de= termine which human-facing language to use. Keep in mind that in some cases= (such as native clients), you'll be dynamically registering a client for e= ach user, in effect. In other words, I personally think that this is a rath= ole that will cause more harm than good. -- Justin= From bcampbell@pingidentity.com Mon Mar 11 14:50: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 ADDE521F8FA3 for ; Mon, 11 Mar 2013 14:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[AWL=-0.877, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sMEKDpTG5Lda for ; Mon, 11 Mar 2013 14:50:11 -0700 (PDT) Received: from na3sys009aog130.obsmtp.com (na3sys009aog130.obsmtp.com [74.125.149.143]) by ietfa.amsl.com (Postfix) with ESMTP id E401721F8FAA for ; Mon, 11 Mar 2013 14:50:07 -0700 (PDT) Received: from mail-oa0-f70.google.com ([209.85.219.70]) (using TLSv1) by na3sys009aob130.postini.com ([74.125.148.12]) with SMTP ID DSNKUT5RjlcdNBpAQtJEBK01sPxyprPx4BcY@postini.com; Mon, 11 Mar 2013 14:50:07 PDT Received: by mail-oa0-f70.google.com with SMTP id h2so25832581oag.1 for ; Mon, 11 Mar 2013 14:50:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=uv7oCv/t10E40YaISuCkqLmnGm12FrHLvmu7w70bOtY=; b=NJfC4gPKUXZnFuVCLjThcFUaVVsHzC8ZrImCqyGmFb+/dGzIqOv94w+geTabGLwH8A XhUusXa2oHiAdlz2B5I5h7fTtqeWEAFApbGsFGUz/TjkrVGcxvUFruMmnq+FBU+UQ2p+ IMZKX2kMVioiqwCQ8HidBV0N4rQAS27RgwJP71rlCPQApDfqr/tHt+mnSUyl2rCFfrv1 4CsMJRUKA2KRYOc81zP+h5/czBv7THOFTMa3cPdDBPnqMCpFJCzf1O7u3PfN24136HWO GEoP/P+3iqowLBREvmogyHAf2LyOhHsuDg2/D91rggOKVyokHADFJn1HrBqmFGyZD7s4 ARsQ== X-Received: by 10.50.213.41 with SMTP id np9mr8988664igc.79.1363038606175; Mon, 11 Mar 2013 14:50:06 -0700 (PDT) X-Received: by 10.50.213.41 with SMTP id np9mr8988653igc.79.1363038606044; Mon, 11 Mar 2013 14:50:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.32.106 with HTTP; Mon, 11 Mar 2013 14:49:35 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Mon, 11 Mar 2013 17:49:35 -0400 Message-ID: To: "Richer, Justin P." Content-Type: multipart/alternative; boundary=f46d04462eb6edcfad04d7ad27d0 X-Gm-Message-State: ALoCoQmbB1emexUMQLwWRpaH78Vba0OSPr8JR4DKyTRH96LB1ipbo2DeiGWcoJVQ2sNOI7dP6HluhXruZk2jIIqw6MuEmZtJYyZbvMKpOm0xMZELjpSPxdtUL6xhSBmtgwD26qd/lTCX Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readable names X-BeenThere: oauth@ietf.org X-Mailman-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, 11 Mar 2013 21:50:12 -0000 --f46d04462eb6edcfad04d7ad27d0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit FWIW, the closely related OpenID Connect client registration draft does have some support for doing this, which could maybe be borrowed. See client_name in $B!x(B2 at http://openid.net/specs/openid-connect-registration-1_0-15.html#client-metadataand the examples. "client_name": "My Example", "client_name#ja-Jpan-JP":"$B%/%i%$%"%s%HL>(B", On Mon, Mar 11, 2013 at 5:15 PM, Richer, Justin P. wrote: > It was brought up at the in-person meeting today that we'll want to > consider issues around internationalization and localization of > human-readable fields like client_name in the client registration. Which is > to say: if a client supports ten languages and wants to present itself in > ten languages, should it have to register itself ten times with an AS? > > At the moment, I'm of the opinion a client with ten languages could > register itself ten times, or do something with the context in which it > runs to determine which human-facing language to use. Keep in mind that in > some cases (such as native clients), you'll be dynamically registering a > client for each user, in effect. In other words, I personally think that > this is a rathole that will cause more harm than good. > > -- Justin > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --f46d04462eb6edcfad04d7ad27d0 Content-Type: text/html; charset=ISO-2022-JP Content-Transfer-Encoding: base64 PGRpdiBkaXI9Imx0ciI+RldJVywgdGhlIGNsb3NlbHkgcmVsYXRlZCBPcGVuSUQgQ29ubmVjdCBj bGllbnQgcmVnaXN0cmF0aW9uIGRyYWZ0IGRvZXMgaGF2ZSBzb21lIHN1cHBvcnQgZm9yIGRvaW5n IHRoaXMsIHdoaWNoIGNvdWxkIG1heWJlIGJlIGJvcnJvd2VkLiBTZWUgY2xpZW50X25hbWUgaW4g GyRCIXgbKEIyIGF0IDxhIGhyZWY9Imh0dHA6Ly9vcGVuaWQubmV0L3NwZWNzL29wZW5pZC1jb25u ZWN0LXJlZ2lzdHJhdGlvbi0xXzAtMTUuaHRtbCNjbGllbnQtbWV0YWRhdGEiPmh0dHA6Ly9vcGVu aWQubmV0L3NwZWNzL29wZW5pZC1jb25uZWN0LXJlZ2lzdHJhdGlvbi0xXzAtMTUuaHRtbCNjbGll bnQtbWV0YWRhdGE8L2E+IGFuZCB0aGUgZXhhbXBsZXMuPGJyPg0KDQombmJzcDs8YnI+PHByZT4g ICAmcXVvdDtjbGllbnRfbmFtZSZxdW90OzogJnF1b3Q7TXkgRXhhbXBsZSZxdW90OywNCiAgICZx dW90O2NsaWVudF9uYW1lI2phLUpwYW4tSlAmcXVvdDs6JnF1b3Q7GyRCJS8laSUkJSIlcyVITD4b KEImcXVvdDssPC9wcmU+PGJyPjwvZGl2PjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48YnI+PGJy PjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBNb24sIE1hciAxMSwgMjAxMyBhdCA1OjE1IFBN LCBSaWNoZXIsIEp1c3RpbiBQLiA8c3BhbiBkaXI9Imx0ciI+Jmx0OzxhIGhyZWY9Im1haWx0bzpq cmljaGVyQG1pdHJlLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmpyaWNoZXJAbWl0cmUub3JnPC9hPiZn dDs8L3NwYW4+IHdyb3RlOjxicj4NCg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBz dHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGlu Zy1sZWZ0OjFleCI+SXQgd2FzIGJyb3VnaHQgdXAgYXQgdGhlIGluLXBlcnNvbiBtZWV0aW5nIHRv ZGF5IHRoYXQgd2UmIzM5O2xsIHdhbnQgdG8gY29uc2lkZXIgaXNzdWVzIGFyb3VuZCBpbnRlcm5h dGlvbmFsaXphdGlvbiBhbmQgbG9jYWxpemF0aW9uIG9mIGh1bWFuLXJlYWRhYmxlIGZpZWxkcyBs aWtlIGNsaWVudF9uYW1lIGluIHRoZSBjbGllbnQgcmVnaXN0cmF0aW9uLiBXaGljaCBpcyB0byBz YXk6IGlmIGEgY2xpZW50IHN1cHBvcnRzIHRlbiBsYW5ndWFnZXMgYW5kIHdhbnRzIHRvIHByZXNl bnQgaXRzZWxmIGluIHRlbiBsYW5ndWFnZXMsIHNob3VsZCBpdCBoYXZlIHRvIHJlZ2lzdGVyIGl0 c2VsZiB0ZW4gdGltZXMgd2l0aCBhbiBBUz88YnI+DQoNCg0KPGJyPg0KQXQgdGhlIG1vbWVudCwg SSYjMzk7bSBvZiB0aGUgb3BpbmlvbiBhIGNsaWVudCB3aXRoIHRlbiBsYW5ndWFnZXMgY291bGQg cmVnaXN0ZXIgaXRzZWxmIHRlbiB0aW1lcywgb3IgZG8gc29tZXRoaW5nIHdpdGggdGhlIGNvbnRl eHQgaW4gd2hpY2ggaXQgcnVucyB0byBkZXRlcm1pbmUgd2hpY2ggaHVtYW4tZmFjaW5nIGxhbmd1 YWdlIHRvIHVzZS4gS2VlcCBpbiBtaW5kIHRoYXQgaW4gc29tZSBjYXNlcyAoc3VjaCBhcyBuYXRp dmUgY2xpZW50cyksIHlvdSYjMzk7bGwgYmUgZHluYW1pY2FsbHkgcmVnaXN0ZXJpbmcgYSBjbGll bnQgZm9yIGVhY2ggdXNlciwgaW4gZWZmZWN0LiBJbiBvdGhlciB3b3JkcywgSSBwZXJzb25hbGx5 IHRoaW5rIHRoYXQgdGhpcyBpcyBhIHJhdGhvbGUgdGhhdCB3aWxsIGNhdXNlIG1vcmUgaGFybSB0 aGFuIGdvb2QuPGJyPg0KDQoNCjxicj4NCiZuYnNwOy0tIEp1c3Rpbjxicj4NCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBs aXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwv YT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h dXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9vYXV0aDwvYT48YnI+DQo8L2Jsb2NrcXVvdGU+PC9kaXY+PGJyPjwvZGl2Pg0K --f46d04462eb6edcfad04d7ad27d0-- From sakimura@gmail.com Mon Mar 11 14:54:15 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 7343B21F8FDF for ; Mon, 11 Mar 2013 14:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.347 X-Spam-Level: X-Spam-Status: No, score=-2.347 tagged_above=-999 required=5 tests=[AWL=-0.502, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, 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 qLuTWH8miAHD for ; Mon, 11 Mar 2013 14:54:14 -0700 (PDT) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by ietfa.amsl.com (Postfix) with ESMTP id 884E321F8FC7 for ; Mon, 11 Mar 2013 14:54:13 -0700 (PDT) Received: by mail-lb0-f182.google.com with SMTP id gg6so3464677lbb.41 for ; Mon, 11 Mar 2013 14:54:12 -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=W1MIWZEB4vbiILdZetvA+s/EaMYeWneFuERT+Lyp/xM=; b=Nb+xwAH7SKTjIgA0f2viOx42DmIfX4QPk4XRQOjCtlRunD63R2sqf2GN37CLZidz6g gl3oMfwVNRULNQPxaOSt2IRcpZaKvHtMXSyX1sMdQx7fcqzay8/qGLjKq88YqCSYBLu6 GvZWeCTrQJQqhJ+QGQ1idxOAqmTtpygC8HMeCt7dNHFxCfVbZyZnnp7ygu/5lCAuH9j0 us8h4bmhY3q/qQXdjdWFNgX5873kXESBmTMLxZrGd6rbbSizvhqBzvQ2COgrjWIfLiuH XWSiRzLv/fnAXZ9kxF+jXwtfQ2B7M5S8pY8C8qVhUml8UurYFApC+wNoIjUdoo7A005k xNUg== MIME-Version: 1.0 X-Received: by 10.152.132.138 with SMTP id ou10mr11760346lab.56.1363038852521; Mon, 11 Mar 2013 14:54:12 -0700 (PDT) Received: by 10.112.14.44 with HTTP; Mon, 11 Mar 2013 14:54:12 -0700 (PDT) In-Reply-To: References: Date: Tue, 12 Mar 2013 06:54:12 +0900 Message-ID: From: Nat Sakimura To: Brian Campbell Content-Type: multipart/alternative; boundary=f46d042d051c9ea9ca04d7ad36ec Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readable names X-BeenThere: oauth@ietf.org X-Mailman-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, 11 Mar 2013 21:54:15 -0000 --f46d042d051c9ea9ca04d7ad36ec Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit +1 2013/3/12 Brian Campbell > FWIW, the closely related OpenID Connect client registration draft does > have some support for doing this, which could maybe be borrowed. See > client_name in $B!x(B2 at > http://openid.net/specs/openid-connect-registration-1_0-15.html#client-metadataand the examples. > > > "client_name": "My Example", > "client_name#ja-Jpan-JP":"$B%/%i%$%"%s%HL>(B", > > > > > On Mon, Mar 11, 2013 at 5:15 PM, Richer, Justin P. wrote: > >> It was brought up at the in-person meeting today that we'll want to >> consider issues around internationalization and localization of >> human-readable fields like client_name in the client registration. Which is >> to say: if a client supports ten languages and wants to present itself in >> ten languages, should it have to register itself ten times with an AS? >> >> At the moment, I'm of the opinion a client with ten languages could >> register itself ten times, or do something with the context in which it >> runs to determine which human-facing language to use. Keep in mind that in >> some cases (such as native clients), you'll be dynamically registering a >> client for each user, in effect. In other words, I personally think that >> this is a rathole that will cause more harm than good. >> >> -- Justin >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --f46d042d051c9ea9ca04d7ad36ec Content-Type: text/html; charset=ISO-2022-JP Content-Transfer-Encoding: base64 KzE8YnI+PGJyPjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4yMDEzLzMvMTIgQnJpYW4gQ2FtcGJl bGwgPHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVu dGl0eS5jb20iIHRhcmdldD0iX2JsYW5rIj5iY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTwvYT4m Z3Q7PC9zcGFuPjxicj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJn aW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4 Ij4NCjxkaXYgZGlyPSJsdHIiPkZXSVcsIHRoZSBjbG9zZWx5IHJlbGF0ZWQgT3BlbklEIENvbm5l Y3QgY2xpZW50IHJlZ2lzdHJhdGlvbiBkcmFmdCBkb2VzIGhhdmUgc29tZSBzdXBwb3J0IGZvciBk b2luZyB0aGlzLCB3aGljaCBjb3VsZCBtYXliZSBiZSBib3Jyb3dlZC4gU2VlIGNsaWVudF9uYW1l IGluIBskQiF4GyhCMiBhdCA8YSBocmVmPSJodHRwOi8vb3BlbmlkLm5ldC9zcGVjcy9vcGVuaWQt Y29ubmVjdC1yZWdpc3RyYXRpb24tMV8wLTE1Lmh0bWwjY2xpZW50LW1ldGFkYXRhIiB0YXJnZXQ9 Il9ibGFuayI+aHR0cDovL29wZW5pZC5uZXQvc3BlY3Mvb3BlbmlkLWNvbm5lY3QtcmVnaXN0cmF0 aW9uLTFfMC0xNS5odG1sI2NsaWVudC1tZXRhZGF0YTwvYT4gYW5kIHRoZSBleGFtcGxlcy48YnI+ DQoNCg0KJm5ic3A7PGJyPjxwcmU+ICAgJnF1b3Q7Y2xpZW50X25hbWUmcXVvdDs6ICZxdW90O015 IEV4YW1wbGUmcXVvdDssDQogICAmcXVvdDtjbGllbnRfbmFtZSNqYS1KcGFuLUpQJnF1b3Q7OiZx dW90OxskQiUvJWklJCUiJXMlSEw+GyhCJnF1b3Q7LDwvcHJlPjxicj48L2Rpdj48ZGl2IGNsYXNz PSJIT0VuWmIiPjxkaXYgY2xhc3M9Img1Ij48ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJyPjxi cj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gTW9uLCBNYXIgMTEsIDIwMTMgYXQgNToxNSBQ TSwgUmljaGVyLCBKdXN0aW4gUC4gPHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJtYWlsdG86 anJpY2hlckBtaXRyZS5vcmciIHRhcmdldD0iX2JsYW5rIj5qcmljaGVyQG1pdHJlLm9yZzwvYT4m Z3Q7PC9zcGFuPiB3cm90ZTo8YnI+DQoNCg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3Rl IiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFk ZGluZy1sZWZ0OjFleCI+SXQgd2FzIGJyb3VnaHQgdXAgYXQgdGhlIGluLXBlcnNvbiBtZWV0aW5n IHRvZGF5IHRoYXQgd2UmIzM5O2xsIHdhbnQgdG8gY29uc2lkZXIgaXNzdWVzIGFyb3VuZCBpbnRl cm5hdGlvbmFsaXphdGlvbiBhbmQgbG9jYWxpemF0aW9uIG9mIGh1bWFuLXJlYWRhYmxlIGZpZWxk cyBsaWtlIGNsaWVudF9uYW1lIGluIHRoZSBjbGllbnQgcmVnaXN0cmF0aW9uLiBXaGljaCBpcyB0 byBzYXk6IGlmIGEgY2xpZW50IHN1cHBvcnRzIHRlbiBsYW5ndWFnZXMgYW5kIHdhbnRzIHRvIHBy ZXNlbnQgaXRzZWxmIGluIHRlbiBsYW5ndWFnZXMsIHNob3VsZCBpdCBoYXZlIHRvIHJlZ2lzdGVy IGl0c2VsZiB0ZW4gdGltZXMgd2l0aCBhbiBBUz88YnI+DQoNCg0KDQo8YnI+DQpBdCB0aGUgbW9t ZW50LCBJJiMzOTttIG9mIHRoZSBvcGluaW9uIGEgY2xpZW50IHdpdGggdGVuIGxhbmd1YWdlcyBj b3VsZCByZWdpc3RlciBpdHNlbGYgdGVuIHRpbWVzLCBvciBkbyBzb21ldGhpbmcgd2l0aCB0aGUg Y29udGV4dCBpbiB3aGljaCBpdCBydW5zIHRvIGRldGVybWluZSB3aGljaCBodW1hbi1mYWNpbmcg bGFuZ3VhZ2UgdG8gdXNlLiBLZWVwIGluIG1pbmQgdGhhdCBpbiBzb21lIGNhc2VzIChzdWNoIGFz IG5hdGl2ZSBjbGllbnRzKSwgeW91JiMzOTtsbCBiZSBkeW5hbWljYWxseSByZWdpc3RlcmluZyBh IGNsaWVudCBmb3IgZWFjaCB1c2VyLCBpbiBlZmZlY3QuIEluIG90aGVyIHdvcmRzLCBJIHBlcnNv bmFsbHkgdGhpbmsgdGhhdCB0aGlzIGlzIGEgcmF0aG9sZSB0aGF0IHdpbGwgY2F1c2UgbW9yZSBo YXJtIHRoYW4gZ29vZC48YnI+DQoNCg0KDQo8YnI+DQombmJzcDstLSBKdXN0aW48YnI+DQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1h aWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxicj4NCjwvYmxvY2txdW90ZT48L2Rp dj48YnI+PC9kaXY+DQo8L2Rpdj48L2Rpdj48YnI+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVm PSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2Js YW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxicj4N Cjxicj48L2Jsb2NrcXVvdGU+PC9kaXY+PGJyPjxiciBjbGVhcj0iYWxsIj48ZGl2Pjxicj48L2Rp dj4tLSA8YnI+TmF0IFNha2ltdXJhICg9bmF0KTxkaXY+Q2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0 aW9uPGJyPjxhIGhyZWY9Imh0dHA6Ly9uYXQuc2FraW11cmEub3JnLyIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHA6Ly9uYXQuc2FraW11cmEub3JnLzwvYT48YnI+QF9uYXRfZW48L2Rpdj4NCg== --f46d042d051c9ea9ca04d7ad36ec-- From ve7jtb@ve7jtb.com Mon Mar 11 14:54:24 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 2E2AD21F905B for ; Mon, 11 Mar 2013 14:54:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.987 X-Spam-Level: X-Spam-Status: No, score=-1.987 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, 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 bO84BV9OlRdr for ; Mon, 11 Mar 2013 14:54:23 -0700 (PDT) Received: from mail-ia0-x233.google.com (mail-ia0-x233.google.com [IPv6:2607:f8b0:4001:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 1072721F9052 for ; Mon, 11 Mar 2013 14:54:22 -0700 (PDT) Received: by mail-ia0-f179.google.com with SMTP id x24so4174837iak.10 for ; Mon, 11 Mar 2013 14:54: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=docvKTQGHSAZ3SPB0jw/ezSWp5TgySZPFXTnBdOh7aI=; b=Sf0poqByhjKRXpCmFawj/ljG5l147dKfUrXWGWMQA4N6ebvR0+8bGMrfRDrmJRe9Ol injtvra1tPwVEoL0k8/Nzuc4qc0PzamlPD58Nznfg4zoVObBbDmP+dnMVWhjNgnkgPUN mVTAbVwYUcrXf5dx+9Nrg7F/iBG4oAr6zw6DtI6d7KreJ4usPG74JXQZRL3rcsiGVP0Q 2WHoUzJINtfnY5kKkcNWWGgwvtte6f+40chuvSmsPpGnW3/1u2m194AcqpYyH8jemj2q N5aEnQJJhHNmNEUl4xtQ2f0rIe1op2lQRZtJBcZJEqMwbuDunr8bHWmdEEbzszezVCqk jhVA== X-Received: by 10.50.196.234 with SMTP id ip10mr9171434igc.27.1363038862537; Mon, 11 Mar 2013 14:54:22 -0700 (PDT) Received: from dhcp-543c.meeting.ietf.org (dhcp-543c.meeting.ietf.org. [130.129.84.60]) by mx.google.com with ESMTPS id l2sm15215243igb.1.2013.03.11.14.54.18 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 11 Mar 2013 14:54:20 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_8F7C58F1-DD6E-451B-849E-F8EA89A9B5D7"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Bradley In-Reply-To: Date: Mon, 11 Mar 2013 22:54:14 +0100 Message-Id: <1B4C0C9F-4B8E-4B2D-BAF7-665D3EBBE56C@ve7jtb.com> References: To: Brian Campbell X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQkahZ18T4UORSWaD+ng+3UxoTCfezfSfsaV6bZzCxeI7DXSfrYwa4OiHLBUb6FA+hrLqFfV Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readable names X-BeenThere: oauth@ietf.org X-Mailman-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, 11 Mar 2013 21:54:24 -0000 --Apple-Mail=_8F7C58F1-DD6E-451B-849E-F8EA89A9B5D7 Content-Type: multipart/alternative; boundary="Apple-Mail=_86E931C6-2B17-4A01-9E9F-C1CD5B7311FB" --Apple-Mail=_86E931C6-2B17-4A01-9E9F-C1CD5B7311FB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-2022-jp That is what I was thinking. It would be up to the AS to determine = what language and script to present based on the user preference. While a large number of clients will be native and might be able to = customize themselves for a single user during registration , we don't = want to forget the web server clients that are multi user. On 2013-03-11, at 10:49 PM, Brian Campbell = wrote: > FWIW, the closely related OpenID Connect client registration draft = does have some support for doing this, which could maybe be borrowed. = See client_name in =1B$B!x=1B(B2 at = http://openid.net/specs/openid-connect-registration-1_0-15.html#client-met= adata and the examples. > =20 > "client_name": "My Example", > "client_name#ja-Jpan-JP":"=1B$B%/%i%$%"%s%HL>=1B(B", >=20 >=20 >=20 > On Mon, Mar 11, 2013 at 5:15 PM, Richer, Justin P. = wrote: > It was brought up at the in-person meeting today that we'll want to = consider issues around internationalization and localization of = human-readable fields like client_name in the client registration. Which = is to say: if a client supports ten languages and wants to present = itself in ten languages, should it have to register itself ten times = with an AS? >=20 > At the moment, I'm of the opinion a client with ten languages could = register itself ten times, or do something with the context in which it = runs to determine which human-facing language to use. Keep in mind that = in some cases (such as native clients), you'll be dynamically = registering a client for each user, in effect. In other words, I = personally think that this is a rathole that will cause more harm than = good. >=20 > -- Justin > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_86E931C6-2B17-4A01-9E9F-C1CD5B7311FB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-2022-jp That = is what I was thinking.   It would be up to the AS to determine = what language and script to present based on the user = preference.

While a large number of clients will be = native and might be able to customize themselves for a single user = during registration , we don't want to forget the web server clients = that are multi user.

On 2013-03-11, at 10:49 PM, = Brian Campbell <bcampbell@pingidentity.com&= gt; wrote:

FWIW, the closely related OpenID Connect = client registration draft does have some support for doing this, which = could maybe be borrowed. See client_name in =1B$B!x=1B(B2 at http://openid.net/specs/openid-connect-registration-1_0-15.= html#client-metadata and the examples.
 
   "client_name": "My Example",
   "client_name#ja-Jpan-JP":"=1B$B%/%i%$%"%s%HL>=1B(B",



On Mon, Mar = 11, 2013 at 5:15 PM, Richer, Justin P. <jricher@mitre.org> wrote:
It was brought up at = the in-person meeting today that we'll want to consider issues around = internationalization and localization of human-readable fields like = client_name in the client registration. Which is to say: if a client = supports ten languages and wants to present itself in ten languages, = should it have to register itself ten times with an AS?

At the moment, I'm of the opinion a client with ten languages could = register itself ten times, or do something with the context in which it = runs to determine which human-facing language to use. Keep in mind that = in some cases (such as native clients), you'll be dynamically = registering a client for each user, in effect. In other words, I = personally think that this is a rathole that will cause more harm than = good.

 -- Justin
_______________________________________________
OAuth mailing 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=_86E931C6-2B17-4A01-9E9F-C1CD5B7311FB-- --Apple-Mail=_8F7C58F1-DD6E-451B-849E-F8EA89A9B5D7 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 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMzExMjE1NDE0WjAjBgkqhkiG9w0BCQQxFgQU2Flm4piF IM3OhaetOWWwHnWXxmswgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAhclNIK1RG/pjK8mA+En4IbagT9kE7zCtqlu0GMsw kc+7bJZDmjvgntrjZskh8HqDFwKJPrxM3AXgYJrQWbWTXiiIyCrVWVYpL0q1pALGLlBiqSCthfyy BhOTcEvQXYF90LPBBpz8R3snJeFlXDp+8eIgpstaVxen6CaVDbb40+zVZqLIy+WR2z9UMmpHuAKp ZSU0jHAk8hW82I7PeCE5wxqHklWn6vX/pwOjYeCTQ/qCbzG+Jt0+abr1TasS0lhGba/8gzPDdEwX 5WcDLDRgDRLolwRSBDcn23QaSVK1Lq3/CYs+z/G06Lb+9d6a+GC/riPYjIHOpOf4LJLUqEXmmQAA AAAAAA== --Apple-Mail=_8F7C58F1-DD6E-451B-849E-F8EA89A9B5D7-- From jricher@mitre.org Mon Mar 11 15:26:32 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 F18A221F8E78 for ; Mon, 11 Mar 2013 15:26:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.498 X-Spam-Level: X-Spam-Status: No, score=-6.498 tagged_above=-999 required=5 tests=[AWL=0.100, 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 ivR1hRrxmPOM for ; Mon, 11 Mar 2013 15:26:32 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id E7D1E21F8E4E for ; Mon, 11 Mar 2013 15:26:31 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 7F1E61F0923; Mon, 11 Mar 2013 18:26:31 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 7072E1F058B; Mon, 11 Mar 2013 18:26:31 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.59]) by IMCCAS01.MITRE.ORG ([129.83.29.68]) with mapi id 14.02.0318.004; Mon, 11 Mar 2013 18:26:31 -0400 From: "Richer, Justin P." To: John Bradley Thread-Topic: [OAUTH-WG] Registration: Internationalization of Human-Readable names Thread-Index: AQHOHp2D44pYbE8oI0KylL+zHw2NHJihSneAgAABTACAAAkEAA== Date: Mon, 11 Mar 2013 22:26:30 +0000 Message-ID: References: <1B4C0C9F-4B8E-4B2D-BAF7-665D3EBBE56C@ve7jtb.com> In-Reply-To: <1B4C0C9F-4B8E-4B2D-BAF7-665D3EBBE56C@ve7jtb.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.4.254] Content-Type: multipart/alternative; boundary="_000_B33BFB58CCC8BE4998958016839DE27E08F3EEB3IMCMBX01MITREOR_" MIME-Version: 1.0 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readable names X-BeenThere: oauth@ietf.org X-Mailman-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, 11 Mar 2013 22:26:33 -0000 --_000_B33BFB58CCC8BE4998958016839DE27E08F3EEB3IMCMBX01MITREOR_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable My concern with this is that OIDC can get away with defining this multi-lan= guage structure because it defines the mechanism once (in Messages) and app= lies it to all user-readable strings throughout the whole application proto= col, of which there are several. Do we really want to pull in that whole st= ructure and mechanism for one field in client registration? I really don't = think it should be something that's defined completely inside of DynReg for= a corner case for a single field, but I also doubt we want to normatively = point to OIDC Messages for this solution either. There are also other ways to do this: Webfinger [1] for instance uses JSON = structures to give language tags to field values, and has a default mechani= sm: { "en_us": "my client", =1B$B!D=1B(B } The fundamental question is this: should a client be able to register mult= iple names (in different locales) with a single client_id, or should it get= a different client_id for each display language set? -- Justin [1] http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-11 On Mar 11, 2013, at 5:54 PM, John Bradley > wrote: That is what I was thinking. It would be up to the AS to determine what l= anguage and script to present based on the user preference. While a large number of clients will be native and might be able to customi= ze themselves for a single user during registration , we don't want to forg= et the web server clients that are multi user. On 2013-03-11, at 10:49 PM, Brian Campbell > wrote: FWIW, the closely related OpenID Connect client registration draft does hav= e some support for doing this, which could maybe be borrowed. See client_na= me in =1B$B!x=1B(B2 at http://openid.net/specs/openid-connect-registration-= 1_0-15.html#client-metadata and the examples. "client_name": "My Example", "client_name#ja-Jpan-JP":"=1B$B%/%i%$%"%s%HL>=1B(B", On Mon, Mar 11, 2013 at 5:15 PM, Richer, Justin P. > wrote: It was brought up at the in-person meeting today that we'll want to conside= r issues around internationalization and localization of human-readable fie= lds like client_name in the client registration. Which is to say: if a clie= nt supports ten languages and wants to present itself in ten languages, sho= uld it have to register itself ten times with an AS? At the moment, I'm of the opinion a client with ten languages could registe= r itself ten times, or do something with the context in which it runs to de= termine which human-facing language to use. Keep in mind that in some cases= (such as native clients), you'll be dynamically registering a client for e= ach user, in effect. In other words, I personally think that this is a rath= ole that will cause more harm than good. -- Justin _______________________________________________ OAuth mailing 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_B33BFB58CCC8BE4998958016839DE27E08F3EEB3IMCMBX01MITREOR_ Content-Type: text/html; charset="iso-2022-jp" Content-ID: <04DD19E0B6999840A2ECB94248073E9B@imc.mitre.org> Content-Transfer-Encoding: quoted-printable My concern with this is that OIDC can get away with defining this multi-lan= guage structure because it defines the mechanism once (in Messages) and app= lies it to all user-readable strings throughout the whole application proto= col, of which there are several. Do we really want to pull in that whole structure and mechanism for one fi= eld in client registration? I really don't think it should be something tha= t's defined completely inside of DynReg for a corner case for a single fiel= d, but I also doubt we want to normatively point to OIDC Messages for this solution either.

There are also other ways to do this: Webfinger [1] for instance uses = JSON structures to give language tags to field values, and has a default me= chanism:

   { "en_us": "my client", =1B$B!D=1B(B = }

The fundamental question is  this: should a client be able to reg= ister multiple names (in different locales) with a single client_id, or sho= uld it get a different client_id for each display language set?

 -- Justin

[1] http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-11

On Mar 11, 2013, at 5:54 PM, John Bradley <ve7jtb@ve7jtb.com>
 wrote:

That is what I was thinking.   It would be up to the AS to determine w= hat language and script to present based on the user preference.

While a large number of clients will be native and might be able to cu= stomize themselves for a single user during registration , we don't want to= forget the web server clients that are multi user.

On 2013-03-11, at 10:49 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:

FWIW, the closely related OpenID Connect client registrati= on draft does have some support for doing this, which could maybe be borrow= ed. See client_name in =1B$B!x=1B(B2 at http://openid.net/specs/openid-connect-registration-1_0-15.html#client-meta= data and the examples.
 
   "client_name": "My Example",
   "client_name#ja-Jpan-JP":"=1B$B%/%i%$%"%s%HL>=1B(B",=



On Mon, Mar 11, 2013 at 5:15 PM, Richer, Justin = P. <jricher@mitre.or= g> wrote:
It was brought up at the in-person meeting today that we'll want to conside= r issues around internationalization and localization of human-readable fie= lds like client_name in the client registration. Which is to say: if a clie= nt supports ten languages and wants to present itself in ten languages, should it have to register itself ten = times with an AS?

At the moment, I'm of the opinion a client with ten languages could registe= r itself ten times, or do something with the context in which it runs to de= termine which human-facing language to use. Keep in mind that in some cases= (such as native clients), you'll be dynamically registering a client for each user, in effect. In other wor= ds, I personally think that this is a rathole that will cause more harm tha= n good.

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

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


--_000_B33BFB58CCC8BE4998958016839DE27E08F3EEB3IMCMBX01MITREOR_-- From bcampbell@pingidentity.com Mon Mar 11 15:36:11 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 136C321F8FCC for ; Mon, 11 Mar 2013 15:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.807 X-Spam-Level: X-Spam-Status: No, score=-4.807 tagged_above=-999 required=5 tests=[AWL=-0.584, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8EIqnZh8+qJ for ; Mon, 11 Mar 2013 15:36:09 -0700 (PDT) Received: from na3sys009aog111.obsmtp.com (na3sys009aog111.obsmtp.com [74.125.149.205]) by ietfa.amsl.com (Postfix) with ESMTP id D5CC221F8F52 for ; Mon, 11 Mar 2013 15:36:08 -0700 (PDT) Received: from mail-ia0-f200.google.com ([209.85.210.200]) (using TLSv1) by na3sys009aob111.postini.com ([74.125.148.12]) with SMTP ID DSNKUT5cWB35opJJyFfNO5dvuB1GCPdSader@postini.com; Mon, 11 Mar 2013 15:36:08 PDT Received: by mail-ia0-f200.google.com with SMTP id k38so9575017iah.3 for ; Mon, 11 Mar 2013 15:36:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=NL1qELeO2cAR/ELMH8O5cNdc6QlhuMZVo3IfNmbD1Pc=; b=BK4BP3Mm1hZBgSTTfKwmOGBmUu9FpIvgrh3Uh7zzCT5/AYlw+U4twQWrqtv03GX2n6 AWHhYA6JJV8njoiUkbSvUhFgVbvL1K/d4CR51veTAbd8mh9bSLebOn7Dy7MNVpO6NQmJ nhX9mh9Lh0Py0K+YVD7nNsaHN31svPj8D8/yEefFQqENRIMBYH4G7jZjPzYf4UVRW2mT HAvg/A0M9kRlrFEholyjFSq7N3A+MeSoSWlx/1Y3CcXeV4P9v9z8WW2RMsspiqtEzM/5 Vw+HxTvmk0BE4+miocxdT8RhAvjlSOt5ITANayiio3Jsqza0Ho3v3ppKAKF9JTT0Zkn/ hfMQ== X-Received: by 10.42.30.132 with SMTP id v4mr10249853icc.34.1363041368199; Mon, 11 Mar 2013 15:36:08 -0700 (PDT) X-Received: by 10.42.30.132 with SMTP id v4mr10249849icc.34.1363041368078; Mon, 11 Mar 2013 15:36:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.32.106 with HTTP; Mon, 11 Mar 2013 15:35:37 -0700 (PDT) In-Reply-To: References: <1B4C0C9F-4B8E-4B2D-BAF7-665D3EBBE56C@ve7jtb.com> From: Brian Campbell Date: Mon, 11 Mar 2013 18:35:37 -0400 Message-ID: To: "Richer, Justin P." Content-Type: multipart/alternative; boundary=20cf301d420e8f196604d7adcc2b X-Gm-Message-State: ALoCoQmWEkOGvdudlNBZi4YvXJlo/ktSEgl+/3de37j7HTfOz0SbGshIygO9x5gfHQd7Pzt0iLdbf3WX/yuLH36qTZMUBukTOQzUeFn4kBH1LoY1LKHOd2EOtxcHad8LWQ83KVS1dWsM Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readable names X-BeenThere: oauth@ietf.org X-Mailman-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, 11 Mar 2013 22:36:11 -0000 --20cf301d420e8f196604d7adcc2b Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit A fair question but what would need to be pulled in is really probably only a couple sentences (and reference) from http://openid.net/specs/openid-connect-messages-1_0-16.html#ClaimsLanguagesAndScripts(note the reference to 2.1.1.1.3 inside http://openid.net/specs/openid-connect-registration-1_0-15.html is broken) On Mon, Mar 11, 2013 at 6:26 PM, Richer, Justin P. wrote: > My concern with this is that OIDC can get away with defining this > multi-language structure because it defines the mechanism once (in > Messages) and applies it to all user-readable strings throughout the whole > application protocol, of which there are several. Do we really want to pull > in that whole structure and mechanism for one field in client registration? > I really don't think it should be something that's defined completely > inside of DynReg for a corner case for a single field, but I also doubt we > want to normatively point to OIDC Messages for this solution either. > > There are also other ways to do this: Webfinger [1] for instance uses > JSON structures to give language tags to field values, and has a default > mechanism: > > { "en_us": "my client", $B!D(B } > > The fundamental question is this: should a client be able to register > multiple names (in different locales) with a single client_id, or should it > get a different client_id for each display language set? > > -- Justin > > [1] http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-11 > > On Mar 11, 2013, at 5:54 PM, John Bradley > wrote: > > That is what I was thinking. It would be up to the AS to determine > what language and script to present based on the user preference. > > While a large number of clients will be native and might be able to > customize themselves for a single user during registration , we don't want > to forget the web server clients that are multi user. > > On 2013-03-11, at 10:49 PM, Brian Campbell > wrote: > > FWIW, the closely related OpenID Connect client registration draft does > have some support for doing this, which could maybe be borrowed. See > client_name in $B!x(B2 at > http://openid.net/specs/openid-connect-registration-1_0-15.html#client-metadataand the examples. > > > "client_name": "My Example", > "client_name#ja-Jpan-JP":"$B%/%i%$%"%s%HL>(B", > > > > > On Mon, Mar 11, 2013 at 5:15 PM, Richer, Justin P. wrote: > >> It was brought up at the in-person meeting today that we'll want to >> consider issues around internationalization and localization of >> human-readable fields like client_name in the client registration. Which is >> to say: if a client supports ten languages and wants to present itself in >> ten languages, should it have to register itself ten times with an AS? >> >> At the moment, I'm of the opinion a client with ten languages could >> register itself ten times, or do something with the context in which it >> runs to determine which human-facing language to use. Keep in mind that in >> some cases (such as native clients), you'll be dynamically registering a >> client for each user, in effect. In other words, I personally think that >> this is a rathole that will cause more harm than good. >> >> -- Justin >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > --20cf301d420e8f196604d7adcc2b Content-Type: text/html; charset=ISO-2022-JP Content-Transfer-Encoding: base64 PGRpdiBkaXI9Imx0ciI+PGRpdj5BIGZhaXIgcXVlc3Rpb24gYnV0IHdoYXQgd291bGQgbmVlZCB0 byBiZSBwdWxsZWQgaW4gaXMgcmVhbGx5IHByb2JhYmx5IG9ubHkgYSBjb3VwbGUgc2VudGVuY2Vz IChhbmQgcmVmZXJlbmNlKSBmcm9tIDxhIGhyZWY9Imh0dHA6Ly9vcGVuaWQubmV0L3NwZWNzL29w ZW5pZC1jb25uZWN0LW1lc3NhZ2VzLTFfMC0xNi5odG1sI0NsYWltc0xhbmd1YWdlc0FuZFNjcmlw dHMiPmh0dHA6Ly9vcGVuaWQubmV0L3NwZWNzL29wZW5pZC1jb25uZWN0LW1lc3NhZ2VzLTFfMC0x Ni5odG1sI0NsYWltc0xhbmd1YWdlc0FuZFNjcmlwdHM8L2E+IChub3RlIHRoZSByZWZlcmVuY2Ug dG8gMi4xLjEuMS4zIGluc2lkZSA8YSBocmVmPSJodHRwOi8vb3BlbmlkLm5ldC9zcGVjcy9vcGVu aWQtY29ubmVjdC1yZWdpc3RyYXRpb24tMV8wLTE1Lmh0bWwiPmh0dHA6Ly9vcGVuaWQubmV0L3Nw ZWNzL29wZW5pZC1jb25uZWN0LXJlZ2lzdHJhdGlvbi0xXzAtMTUuaHRtbDwvYT4gaXMgYnJva2Vu KTxicj4NCg0KPC9kaXY+PC9kaXY+PGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxicj48YnI+PGRp diBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIE1vbiwgTWFyIDExLCAyMDEzIGF0IDY6MjYgUE0sIFJp Y2hlciwgSnVzdGluIFAuIDxzcGFuIGRpcj0ibHRyIj4mbHQ7PGEgaHJlZj0ibWFpbHRvOmpyaWNo ZXJAbWl0cmUub3JnIiB0YXJnZXQ9Il9ibGFuayI+anJpY2hlckBtaXRyZS5vcmc8L2E+Jmd0Ozwv c3Bhbj4gd3JvdGU6PGJyPg0KDQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxl PSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxl ZnQ6MWV4Ij4NCg0KDQoNCjxkaXYgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj4NCk15IGNv bmNlcm4gd2l0aCB0aGlzIGlzIHRoYXQgT0lEQyBjYW4gZ2V0IGF3YXkgd2l0aCBkZWZpbmluZyB0 aGlzIG11bHRpLWxhbmd1YWdlIHN0cnVjdHVyZSBiZWNhdXNlIGl0IGRlZmluZXMgdGhlIG1lY2hh bmlzbSBvbmNlIChpbiBNZXNzYWdlcykgYW5kIGFwcGxpZXMgaXQgdG8gYWxsIHVzZXItcmVhZGFi bGUgc3RyaW5ncyB0aHJvdWdob3V0IHRoZSB3aG9sZSBhcHBsaWNhdGlvbiBwcm90b2NvbCwgb2Yg d2hpY2ggdGhlcmUgYXJlIHNldmVyYWwuDQogRG8gd2UgcmVhbGx5IHdhbnQgdG8gcHVsbCBpbiB0 aGF0IHdob2xlIHN0cnVjdHVyZSBhbmQgbWVjaGFuaXNtIGZvciBvbmUgZmllbGQgaW4gY2xpZW50 IHJlZ2lzdHJhdGlvbj8gSSByZWFsbHkgZG9uJiMzOTt0IHRoaW5rIGl0IHNob3VsZCBiZSBzb21l dGhpbmcgdGhhdCYjMzk7cyBkZWZpbmVkIGNvbXBsZXRlbHkgaW5zaWRlIG9mIER5blJlZyBmb3Ig YSBjb3JuZXIgY2FzZSBmb3IgYSBzaW5nbGUgZmllbGQsIGJ1dCBJIGFsc28gZG91YnQgd2Ugd2Fu dCB0byBub3JtYXRpdmVseQ0KIHBvaW50IHRvIE9JREMgTWVzc2FnZXMgZm9yIHRoaXMgc29sdXRp b24gZWl0aGVyLg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhlcmUgYXJlIGFsc28gb3RoZXIg d2F5cyB0byBkbyB0aGlzOiBXZWJmaW5nZXIgWzFdIGZvciBpbnN0YW5jZSB1c2VzIEpTT04gc3Ry dWN0dXJlcyB0byBnaXZlIGxhbmd1YWdlIHRhZ3MgdG8gZmllbGQgdmFsdWVzLCBhbmQgaGFzIGEg ZGVmYXVsdCBtZWNoYW5pc206PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4mbmJzcDsg Jm5ic3A7eyAmcXVvdDtlbl91cyZxdW90OzogJnF1b3Q7bXkgY2xpZW50JnF1b3Q7LCAmaGVsbGlw OyB9PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGUgZnVuZGFtZW50YWwgcXVlc3Rp b24gaXMgJm5ic3A7dGhpczogc2hvdWxkIGEgY2xpZW50IGJlIGFibGUgdG8gcmVnaXN0ZXIgbXVs dGlwbGUgbmFtZXMgKGluIGRpZmZlcmVudCBsb2NhbGVzKSB3aXRoIGEgc2luZ2xlIGNsaWVudF9p ZCwgb3Igc2hvdWxkIGl0IGdldCBhIGRpZmZlcmVudCBjbGllbnRfaWQgZm9yIGVhY2ggZGlzcGxh eSBsYW5ndWFnZSBzZXQ/PGJyPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+Jm5ic3A7LS0gSnVz dGluPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5bMV0mbmJzcDs8YSBocmVmPSJodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWFwcHNhd2ctd2ViZmluZ2VyLTExIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1hcHBz YXdnLXdlYmZpbmdlci0xMTwvYT48L2Rpdj4NCjxkaXY+PGJyPg0KPGRpdj4NCjxkaXY+T24gTWFy IDExLCAyMDEzLCBhdCA1OjU0IFBNLCBKb2huIEJyYWRsZXkgJmx0OzxhIGhyZWY9Im1haWx0bzp2 ZTdqdGJAdmU3anRiLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnZlN2p0YkB2ZTdqdGIuY29tPC9hPiZn dDs8L2Rpdj4NCjxkaXY+Jm5ic3A7d3JvdGU6PC9kaXY+PGRpdj48ZGl2IGNsYXNzPSJoNSI+DQo8 YnI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDpicmVh ay13b3JkIj4NClRoYXQgaXMgd2hhdCBJIHdhcyB0aGlua2luZy4gJm5ic3A7IEl0IHdvdWxkIGJl IHVwIHRvIHRoZSBBUyB0byBkZXRlcm1pbmUgd2hhdCBsYW5ndWFnZSBhbmQgc2NyaXB0IHRvIHBy ZXNlbnQgYmFzZWQgb24gdGhlIHVzZXIgcHJlZmVyZW5jZS4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8 ZGl2PldoaWxlIGEgbGFyZ2UgbnVtYmVyIG9mIGNsaWVudHMgd2lsbCBiZSBuYXRpdmUgYW5kIG1p Z2h0IGJlIGFibGUgdG8gY3VzdG9taXplIHRoZW1zZWx2ZXMgZm9yIGEgc2luZ2xlIHVzZXIgZHVy aW5nIHJlZ2lzdHJhdGlvbiAsIHdlIGRvbiYjMzk7dCB3YW50IHRvIGZvcmdldCB0aGUgd2ViIHNl cnZlciBjbGllbnRzIHRoYXQgYXJlIG11bHRpIHVzZXIuPC9kaXY+DQo8ZGl2Pjxicj4NCjxkaXY+ DQo8ZGl2Pk9uIDIwMTMtMDMtMTEsIGF0IDEwOjQ5IFBNLCBCcmlhbiBDYW1wYmVsbCAmbHQ7PGEg aHJlZj0ibWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tIiB0YXJnZXQ9Il9ibGFuayI+ YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxicj4NCjxi bG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdiBkaXI9Imx0ciI+RldJVywgdGhlIGNsb3NlbHkg cmVsYXRlZCBPcGVuSUQgQ29ubmVjdCBjbGllbnQgcmVnaXN0cmF0aW9uIGRyYWZ0IGRvZXMgaGF2 ZSBzb21lIHN1cHBvcnQgZm9yIGRvaW5nIHRoaXMsIHdoaWNoIGNvdWxkIG1heWJlIGJlIGJvcnJv d2VkLiBTZWUgY2xpZW50X25hbWUgaW4gGyRCIXgbKEIyIGF0DQo8YSBocmVmPSJodHRwOi8vb3Bl bmlkLm5ldC9zcGVjcy9vcGVuaWQtY29ubmVjdC1yZWdpc3RyYXRpb24tMV8wLTE1Lmh0bWwjY2xp ZW50LW1ldGFkYXRhIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwOi8vb3BlbmlkLm5ldC9zcGVjcy9v cGVuaWQtY29ubmVjdC1yZWdpc3RyYXRpb24tMV8wLTE1Lmh0bWwjY2xpZW50LW1ldGFkYXRhPC9h PiBhbmQgdGhlIGV4YW1wbGVzLjxicj4NCiZuYnNwOzxicj4NCjxwcmU+ICAgJnF1b3Q7Y2xpZW50 X25hbWUmcXVvdDs6ICZxdW90O015IEV4YW1wbGUmcXVvdDssDQogICAmcXVvdDtjbGllbnRfbmFt ZSNqYS1KcGFuLUpQJnF1b3Q7OiZxdW90OxskQiUvJWklJCUiJXMlSEw+GyhCJnF1b3Q7LDwvcHJl Pg0KPGJyPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJyPg0KPGJyPg0KPGRp diBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIE1vbiwgTWFyIDExLCAyMDEzIGF0IDU6MTUgUE0sIFJp Y2hlciwgSnVzdGluIFAuIDxzcGFuIGRpcj0ibHRyIj4NCiZsdDs8YSBocmVmPSJtYWlsdG86anJp Y2hlckBtaXRyZS5vcmciIHRhcmdldD0iX2JsYW5rIj5qcmljaGVyQG1pdHJlLm9yZzwvYT4mZ3Q7 PC9zcGFuPiB3cm90ZTo8YnI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxl PSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxl ZnQ6MWV4Ij4NCkl0IHdhcyBicm91Z2h0IHVwIGF0IHRoZSBpbi1wZXJzb24gbWVldGluZyB0b2Rh eSB0aGF0IHdlJiMzOTtsbCB3YW50IHRvIGNvbnNpZGVyIGlzc3VlcyBhcm91bmQgaW50ZXJuYXRp b25hbGl6YXRpb24gYW5kIGxvY2FsaXphdGlvbiBvZiBodW1hbi1yZWFkYWJsZSBmaWVsZHMgbGlr ZSBjbGllbnRfbmFtZSBpbiB0aGUgY2xpZW50IHJlZ2lzdHJhdGlvbi4gV2hpY2ggaXMgdG8gc2F5 OiBpZiBhIGNsaWVudCBzdXBwb3J0cyB0ZW4gbGFuZ3VhZ2VzIGFuZCB3YW50cw0KIHRvIHByZXNl bnQgaXRzZWxmIGluIHRlbiBsYW5ndWFnZXMsIHNob3VsZCBpdCBoYXZlIHRvIHJlZ2lzdGVyIGl0 c2VsZiB0ZW4gdGltZXMgd2l0aCBhbiBBUz88YnI+DQo8YnI+DQpBdCB0aGUgbW9tZW50LCBJJiMz OTttIG9mIHRoZSBvcGluaW9uIGEgY2xpZW50IHdpdGggdGVuIGxhbmd1YWdlcyBjb3VsZCByZWdp c3RlciBpdHNlbGYgdGVuIHRpbWVzLCBvciBkbyBzb21ldGhpbmcgd2l0aCB0aGUgY29udGV4dCBp biB3aGljaCBpdCBydW5zIHRvIGRldGVybWluZSB3aGljaCBodW1hbi1mYWNpbmcgbGFuZ3VhZ2Ug dG8gdXNlLiBLZWVwIGluIG1pbmQgdGhhdCBpbiBzb21lIGNhc2VzIChzdWNoIGFzIG5hdGl2ZSBj bGllbnRzKSwgeW91JiMzOTtsbA0KIGJlIGR5bmFtaWNhbGx5IHJlZ2lzdGVyaW5nIGEgY2xpZW50 IGZvciBlYWNoIHVzZXIsIGluIGVmZmVjdC4gSW4gb3RoZXIgd29yZHMsIEkgcGVyc29uYWxseSB0 aGluayB0aGF0IHRoaXMgaXMgYSByYXRob2xlIHRoYXQgd2lsbCBjYXVzZSBtb3JlIGhhcm0gdGhh biBnb29kLjxicj4NCjxicj4NCiZuYnNwOy0tIEp1c3Rpbjxicj4NCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJy Pg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhA aWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vb2F1dGg8L2E+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnI+DQo8 L2Rpdj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PGJyPg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+PC9kaXY+PC9kaXY+DQo8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQoNCjwvYmxvY2tx dW90ZT48L2Rpdj48YnI+PC9kaXY+DQo= --20cf301d420e8f196604d7adcc2b-- From Michael.Jones@microsoft.com Mon Mar 11 15:39:32 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 640C021F8E7D for ; Mon, 11 Mar 2013 15:39:32 -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 Q3GIUSzshPGd for ; Mon, 11 Mar 2013 15:39:31 -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 183D021F8E78 for ; Mon, 11 Mar 2013 15:39:25 -0700 (PDT) Received: from BL2FFO11FD021.protection.gbl (10.173.161.203) by BL2FFO11HUB036.protection.gbl (10.173.161.116) with Microsoft SMTP Server (TLS) id 15.0.620.12; Mon, 11 Mar 2013 22:39:17 +0000 Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD021.mail.protection.outlook.com (10.173.161.100) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Mon, 11 Mar 2013 22:39:17 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.132]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0318.003; Mon, 11 Mar 2013 22:37:55 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: OAuth Feature Matrix Thread-Index: Ac4eqQVABmcfQE/KQwy7KfSVJ7BEnA== Date: Mon, 11 Mar 2013 22:37:54 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943674F7728@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.32] Content-Type: multipart/mixed; boundary="_004_4E1F6AAD24975D4BA5B1680429673943674F7728TK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(53824001)(199002)(189002)(16236675001)(5343635001)(20776003)(56776001)(76482001)(47736001)(16406001)(63696002)(80022001)(512954001)(56816002)(47976001)(33656001)(54316002)(50986001)(77982001)(47446002)(59766001)(51856001)(5343665001)(65816001)(55846006)(5343655001)(69226001)(53806001)(54356001)(49866001)(74662001)(79102001)(31966008)(74502001)(46102001)(4396001)(562884003)(66066001)(15202345001)(44976002)(6606295001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB036; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0782EC617F Subject: [OAUTH-WG] OAuth Feature Matrix X-BeenThere: oauth@ietf.org X-Mailman-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, 11 Mar 2013 22:39:33 -0000 --_004_4E1F6AAD24975D4BA5B1680429673943674F7728TK5EX14MBXC283r_ Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943674F7728TK5EX14MBXC283r_" --_000_4E1F6AAD24975D4BA5B1680429673943674F7728TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The OAuth Feature Matrix spreadsheet that I talked about at the OAuth WG me= eting today is attached and available at http://self-issued.info/misc/OAuth= %20Feature%20Matrix.xlsx. Tony Nadalin and I created it as a tool to chara= cterize OAuth implementations to help promote interoperability by understan= ding the choices that different implementers have made. Also as discussed today, I propose that people with implementations get tog= ether tomorrow (Tuesday) afternoon to take a quick pass at characterizing t= he choices made in your implementations to date. Then we can report back t= o the working group on Thursday with a snapshot of the choices made, which = will help us get a sense of which features are likely to be interoperable a= cross implementations. (Actually, all those who are interested are welcome= , not just those with implementations.) I'll create a Doodle poll now to help us choose a time window between 1:00 = and 5:00 to get together and do this. Also, stay tuned for the room where = we'll meet. Hopefully this will be a useful and informative exercise... -- Mike --_000_4E1F6AAD24975D4BA5B1680429673943674F7728TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The OAuth Feature Matrix spreadsheet that I talked a= bout at the OAuth WG meeting today is attached and available at http= ://self-issued.info/misc/OAuth%20Feature%20Matrix.xlsx.  Tony Nada= lin and I created it as a tool to characterize OAuth implementations to hel= p promote interoperability by understanding the choices that different implementers have made.

 

Also as discussed today, I propose that people with = implementations get together tomorrow (Tuesday) afternoon to take a quick p= ass at characterizing the choices made in your implementations to date.&nbs= p; Then we can report back to the working group on Thursday with a snapshot of the choices made, which will help us = get a sense of which features are likely to be interoperable across impleme= ntations.  (Actually, all those who are interested are welcome, not ju= st those with implementations.)

 

I’ll create a Doodle poll now to help us choos= e a time window between 1:00 and 5:00 to get together and do this.  Al= so, stay tuned for the room where we’ll meet.

 

Hopefully this will be a useful and informative exer= cise…

 

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

 

--_000_4E1F6AAD24975D4BA5B1680429673943674F7728TK5EX14MBXC283r_-- --_004_4E1F6AAD24975D4BA5B1680429673943674F7728TK5EX14MBXC283r_ Content-Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet; name="OAuth Feature Matrix.xlsx" Content-Description: OAuth Feature Matrix.xlsx Content-Disposition: attachment; filename="OAuth Feature Matrix.xlsx"; size=19053; creation-date="Mon, 11 Mar 2013 19:42:12 GMT"; modification-date="Mon, 11 Mar 2013 21:00:38 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQBBN4LPcgEAAAQFAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACs lMtuwjAQRfeV+g+Rt1Vi6KKqKgKLPpYtEvQDTDwkFo5teQYKf99JeKhCPBSVTaLYnnvudTwejNa1 TVYQ0XiXi37WEwm4wmvjylx8Tz/SZ5EgKaeV9Q5ysQEUo+H93WC6CYAJVzvMRUUUXqTEooJaYeYD OJ6Z+1gr4s9YyqCKhSpBPvZ6T7LwjsBRSo2GGA7eYK6WlpL3NQ9vncyME8nrdl2DyoUKwZpCERuV K6ePIKmfz00B2hfLmqUzDBGUxgqAapuFaJgYJ0DEwVDIk8wIFrtBd6kyrmyNYWUCPnD0M4Rm5nyq Xd0X/45oNCRjFelT1Zxdrq388XEx836RXRbpujXtFmW1Mm7v+wK/XYyyffVvbKTJ1wpf8UF8xkC2 z/9baGWuAJE2FvDGabei18iViqAnxKe3vLmBv9qXfHBLjaMPyF0bofsu7FukqU4DC0EkA4cmOXXY DkRu+e7Ao4sAmjtFgz7Blu0dNvwFAAD//wMAUEsDBBQABgAIAAAAIQC1VTAj9QAAAEwCAAALAAgC X3JlbHMvLnJlbHMgogQCKKAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAjJLPTsMwDMbvSLxD5PvqbkgIoaW7TEi7IVQewCTuH7WNoyRA9/aE A4JKY9vR9ufPP1ve7uZpVB8cYi9Ow7ooQbEzYnvXanitn1YPoGIiZ2kUxxqOHGFX3d5sX3iklJti 1/uosouLGrqU/CNiNB1PFAvx7HKlkTBRymFo0ZMZqGXclOU9hr8eUC081cFqCAd7B6o++jz5src0 TW94L+Z9YpdOjECeEzvLduVDZgupz9uomkLLSYMV85zTEcn7ImMDnibaXE/0/7Y4cSJLidBI4PM8 34pzQOvrgS6faKn4vc484qeE4U1k+GHBxQ9UXwAAAP//AwBQSwMEFAAGAAgAAAAhAIE+lJf0AAAA ugIAABoACAF4bC9fcmVscy93b3JrYm9vay54bWwucmVscyCiBAEooAABAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAKySz0rEMBDG74LvEOZu064iIpvuRYS9an2AkEybsm0SMuOfvr2hotuFZb30 EvhmyPf9Mpnt7mscxAcm6oNXUBUlCPQm2N53Ct6a55sHEMTaWz0EjwomJNjV11fbFxw050vk+kgi u3hS4Jjjo5RkHI6aihDR504b0qg5y9TJqM1Bdyg3ZXkv09ID6hNPsbcK0t7egmimmJP/9w5t2xt8 CuZ9RM9nIiTxNOQHiEanDlnBjy4yI8jz8Zs14zmPBY/ps5TzWV1iqNZk+AzpQA6Rjxx/JZJz5yLM 3Zow5HRC+8opr9vyW5bl38nIk42rvwEAAP//AwBQSwMEFAAGAAgAAAAhAB0ldkGlAQAAswIAAA8A AAB4bC93b3JrYm9vay54bWyMUk1vnDAQvVfqf7B8Z4352OyugKjbpWqkqoraNDm7MCzWYhvZ3kJU 9b93ANFEyqWn+bD95s17zm5H1ZFfYJ00Oqd8E1ICujK11Oec/nj4FOwocV7oWnRGQ06fwdHb4v27 bDD28tOYC0EA7XLaet8fGHNVC0q4jelB40ljrBIeS3tmrrcgatcCeNWxKAy3TAmp6YJwsP+DYZpG VnAy1VWB9guIhU54pO9a2TtaZI3s4HHZiIi+/yoU8h47SjrhfFlLD3VOUyzNAC+NLSX22h+vssPT fRzGlBX/lry3WEzbPkoY3Et/Ksn4JHVthpyids+v8mFuP8natzmN4ijFEUvvM8hz61FuvoujaQ57 hT0LhDPmSPTM/vskGkcnpniHBDG3B4mJvav5jLA+q0RX3Vsyhflikm6j+QaM/ovzRYaRXK3M6W+e hB9uwn0ShGWcBsluHwW7JI6Cj8kpKtOb8lQe0z+rPSNP3xikZGWNM43fVEaxxZs3NvOQcb44XWSI clh/zsSyFdY/WFFd8L99g+YoHHq1LIQ8UZiVNVtfFX8BAAD//wMAUEsDBBQABgAIAAAAIQByS/aP MQ0AALtLAAAUAAAAeGwvc2hhcmVkU3RyaW5ncy54bWzMXOtyE0cW/r9V+w5d82ehCsm2uGUpI8o4 OGGLBBabUPvL1da0rCZzUaZbGOeFeA+ebL/T3aO5Sz0jmSK1xQZp5tzv5yjHL77EEfssMiXT5Hlw ND4MmEhmaSiT6+fBh4uz0U8BU5onIY/SRDwPboUKXkz/+Y9jpTTDu4l6Hiy0Xj47OFCzhYi5GqdL keCbeZrFXOOv2fWBWmaCh2ohhI6jg8nh4ZODmMskYLN0lejnwcPDJwFbJfKvlTi1n0wePQymx0pO j/X0THC9yoQ6PtDT4wP6zH7+XsxFBmqb35xGUiSaXdwuhXpWf+2XjOffsXvBPEpvVHC/8ZQD8S5L 5zJqgXKy0os0k39zDcmx9wKkQyLveMZjoSHPBsD6C2qZJkoMeONVlqUt8C/SPwUR4uC2P0Uqe6aW fAZVQidKZJ9FMGX4pySyZ/T3WZrMZQgpSh7VJOgPZLm6iuSs7+tO5oaMG3HF+HIJKEbQu4BagdsR vwZLoyuuRLgvuAko+ywGQStM0TBbNZHTNBQwUDijYGSlwX1v7kmBrxXTxiREEi5TCZOHH2sxX0Us zey/w67VC2+gNWJfx6QVqUGizP+1J5k1iLDddJXNBHt7k4gMnqHUTZqF7DQTzhDrIaDbEmugnXXv AdL5yW9vJuyl4BlIPFGwKQoAQ4X4n48Xw2HNTJS7lKE3dmcX6xdhBtlqRsE1JKNIlxxhzN8i8JrM xExfrjLpTYOaIUH4P0026/00+Yr3w7kwyL92k4OgiOyN1zx9GQo1y+Syl/HYN/sIm8+QHdWlCQTe BDrBlN/dUUAG/6VGOka0sL4TPGBCz8b+MU18WcLY1KX0d7ZMzPHGopX9KbKMTmdpxF65+NhI2d3R pfEuwnc1eOdAvYXeBtKm9N6gSH+nPGF6IZDGYd1XgiH5hSxOM4FP8VWKqsnfz9toe+98n6qfQRR+ XHDNIjkXWsaCScWukUVBdMqs4dnshY+pXAPx8yyNGTcM+VNOohiIyBmPJWNvGNkdgSU9+xPZLx7I sNWDut3DGF3vtwxRrPdrBtnAdxP0NDUPncarSMtlJEYIHaZEH1HcUuzb14f+jz7yf/Rx/dEcr42X p2l8JanERLfAzlfLZZrBGxrdhcmq7A8eoQ3pfqxbZdS09SgklrYtqpHeDR6NofRvI3gYQgj+xd5y 0dRjNy3pfB7JRFzaMFNlIUO/2f7mWwjo9c/sNE0SVDzsN9CHXkIx+z7eo/+9wx/qb/aZR+ilj4KD 6TESDAorROIYHZf5JDtLUYubR055JK8ySc/NeSyjW/vxhD44MMD09NvXydhZE4CXu9+zU/bk6aN/ wzAn46MqG3r6vvj229ej8cPx0QP2yOOxCT022QIN8Oixhj80kD6ixxq+oHgcTUZXtoRupf7TDXq0 Dd+XEP20kYzJRl4glS3fb2IR4twoUPp+kyTN91shbKLgyRY9GfFvJuLb16fONJp6Kkn529fHfo8d jR8bQxvDkDaRB9FvIP7hFsG1GHzDqBqirxlV43uMk6ha3DZCmTaeK4Y+7J5KUcykGKhFfMlupF4w W8S9d8mkOWgqwNVHSJugmWebwKrISsOlNljVinVNYV0vOUwf8uog28lsj7BUq9E/GFy4IsmWHV69 x9R1+EQADa3suAhhGlO6sEdl3woG1f16GPFZcvbrxcU79pKrxmirHHYnFHRrsuxm3AtvPmV8mYa3 O0N2Iwyj3Rowx8bjw9rn3eST3k7QXKDVMIMRTZMnZbsODIKZnTgwXtXObl034TS1fZj2Q4vRpsb0 2b9c7lLOjrOgLrAeQ6HpxZtzdo8G7+rZffaHnd/XC6apG8zrNI3UWAo9N8P4Bc3gs/mMioeagre+ 0TCJTW+EGZ/rEeEdpaT5UTlG98DcgFNE8g4otpodJ0Jj9SBm6sDi/zwZdVT3o6PLwzEJxhugqZdH MCUqB0exKwc74SCXPnn6+JDde0sRik3Gh27uVx+ATC2pHXTWyTNgUQOWwJ6iyW8A7ahe6+DOISw5 z4PnG5n82Qid03LcYBdozlUsFa2P8mBbBYqitaOituUFZGJfoPr57kpoF4nLJfQPQpmrQ35Aylzp WaZMTz9+/DgqJVlRlEu/YsWHmfiZFFFtIv1DSLonN3Z/9gPa8rqqqOqlHFvzcED5iWF4RxvMRkgo gmj+OOWd9qe7FVhB+8M58nenrsWZ9fSDwjadGWWsF0bKNgfrbOBraCWt/XDS/s60bZA1LHmogL+z ybRGpaqp0MxJo6cBR2htbE1tOssO49FTw37vt0rqa5l1VuTS/H5za3CGFuCG5v1YQ7AZlu+KBv56 QVN/c41hVkO0o/Avytflv+k17LAUUzWaf6IFYSoflfaDiOYzTG+SEc1TyWuruwizg3DNab6fGIiI uqV8f0rFk8i3UHR5Qe0JYUf7nN2y5fqoZChXw5Bh45b2Vgmh4sktwwxX0tCaR61slpkKxRzzWLOB 7mcCpvujTsgdMN1T96u6Z9R7ppgIZP9ShYT9LQLWQEs0qneatz7leofh6AeDhiH6cTjgIvHoFZ1e QRLU4BfDm92Bf3j/mv3X2NJ6VrU70CATPIqDQpNDuCdzIRHLBL6L3U9mD6kerD8w3v0AJhXiI7Wa ozuh265Lu/AwG3E1BDGFjxZbbZS3GAnaQy2Hyhlrbxuyu/vS1p91o1o7/BDGnD1ZfLgVuEM8q9bC hquaw5hbnEFKAi/tOMivW8cnAyVG0Qrx9kTrTF6ttDins5MYdsZEZP4fCStplHBmqV5NxQPxWy5N 3r4L8RnAdySzUqCfRVzGRlIG4Z7E0+KlRdGAdD00e6wLCCwzZyKkC1M6gjp59zrPI4YBHCRk4loq jd7WjjF73MytcVAENtUJFT4GLqnDnQ5asOULwiEoAJgiqbnyKwXlHJl/xCKiK1GkHLUInAvHc6bS B2yR3uwAmgLUXkAW50GFeJGzr7E7j6pVXIV6472mNLW1Y29W2vC6ChGJvFI+7gmxqXps+ivVu7kb UKKESkwdBHO4NdLw56rF2WKBGR9L5yhM4xhH2rRaQayEu9hrTZNpEB5h0Dj4plqWFOqPksztQ0Kj I6OHmcxmq5huznG6ZtiotkPOfTrC5F2j7Qyi/oiN/ozmKnGGINtiM0SBgytYl3n8AZMgDXCriUqk Ici/4zQdJwzD4TYD2C5gDanGfazV5HdgecCqp1t/QSB4cfZ7ql8KSGItSBsXmmm8H9wEoVGtxOuE LHRdHuwOe628diEP0ZsRMI+uEQb1Iq4YG5KaktdeFY2/eDbjg01nt0td16qVXLWI8kdJUtsYO4pC 5O4DRoFrr1Gi4ccB9i0Bu4c/0dLdR1GCqstfZEZL7UYWqNUVAOPPT1hqDYO8yaFJQP6EGi8Okqs5 SEpSjR0vebOjau1w/WEmLJBc5wJEjs45HQhzi+cGn7TED50GKGmz6xbWNtR5/Px1T3i6E17AVyG0 gT9N3uttdiR/W67S6In6AY4TTlaqkKqFF+aQ/kZIwE1NVB5n/bXCJTp1h+h1YjMjw0G1Q7iis8C7 gU89KWy0F3yiXXzRGS86ApVPGFGfIhtSCqftfDHgcjMYhgQBh+tRydUE1Q51PdyotG6EE0LtgayH ZojFfgfSWzhxI6F2VvpXvwZbdWZqi2pz22w8pyKsfhj8eLEI98FRDZ8Z4KFbsOdj+0DQQ/O2/7J3 ZP2cslxVpImdZZutBQcv9lDQcmbScA+7JfFs98iq1Hb1xBzaHu22Q8vlYWk55OTtKZqcftZLynbD iHxdQj83K2AzHt3wW7oZtBGEfkFyZfc/+H2cCXH4wUtrLOpnETtTsTYc5wy90dvRznfkl5ezaCFh ZI3CC3oz4+cAuZPlgWNXF6jD+x6BCEWBC0AmkLtawV/tNR8rWLg7P27g2F9eWIftaqarema+Bi38 e4fM14HRRsO9YqppChNl+9vCHMk+mNhegZqFXN8KEWGNs8BUy4EbUWcCPwmmjawrDzs3Vf6mTKrY kFKr+GUyi1a0B3X48x3ccHSVmaIEx1i40492yz/DrTF/B8gob9nOO5dwPyTGyuA9LtXZDgT7F0jK nYbQYLY+Lt158JGjLW16zu2IADcmc+mmvj9zzfPZIgRsqEIqrlHjz3ALVqDLC7Hd4ZNF2g64cKwy Amomd2aibvYVO+RAsWnjaND7C6yNoY3gcw77oSC9bDZAMzHY2eqIHU9cexi3bVUUlJHfs7g15x7U k0Mapom69W53yhwP1ciDHRMJIxPLiN/STqgGhS0zgV9x4xeq/kZVTgsV/7Bx+gSzieR8vY8v54Ya cn+UFRaMuQ6ge+1voNNOGNyZHsRCf28QjkEuJrZhXWb+ZBNGQzqtozO7NQGySl+0nrM5H+2hCAee aK+AXJfKPq2WPYsDANPv+/NmjLl2yxWmmOYto/QWQisqKfSP/mCJpzyTbI5aNWMyp2OtJyb+yA1P NuHDRqjvNVBJwM5X84RZhzn9H3arjP4TO2bOaFRdnAgf4D++Nf0/AAAA//8DAFBLAwQUAAYACAAA ACEAcLFAvWoBAADBBQAAIwAAAHhsL3dvcmtzaGVldHMvX3JlbHMvc2hlZXQxLnhtbC5yZWxzxFRN TwIxEL2b+B82vXcLCPgRFi5qwsGL4tmU7ixb6bZNZ0D49xYIRggGMASOM03fvDczbzq9WWWSKQTU zmasntZYAla5XNtRxt4Hz/yOJUjS5tI4CxmbA7Je9/qq8wpGUvyEpfaYRBSLGSuJ/IMQqEqoJKbO g40vhQuVpBiGkfBSjeUIRKNWa4vwG4N1NzCTfp6x0M9vWDKY+1h5P7YrCq3g0alJBZZ2lBBlRApG 23EElWEE9ANLzhlMNVCxpFlSZUQeZEF8keNOTqjkKCvT4EOQAcIa4cXlkdzTjCBYaZjYreL2lCp8 0DaWewOiOCZcM8lYmoqtt+24ng61/Ytk45Qkj2t1KFT7thWXbzWWw5pavzDf5v1xfNvn4btwnc5T CyTQg0KxSnDlrAVFvALEaEHk9Y9aulj041S0LqViacFpg1cTQ9ob4AHQxwMEnKKt/yuneR45B92X zy/ae13ExuHtfgMAAP//AwBQSwMEFAAGAAgAAAAhAP/x+4CnBgAAWxoAABMAAAB4bC90aGVtZS90 aGVtZTEueG1s7FnPjxs1FL4j8T+M5p7m18wkWTVbJZOkC91tqyYt6tFJnIwbzziacXYbVZVQe0RC QhTEBYkbBwRUaiUu5a9ZKIIi9V/g2TOZ2InDblc9FNTdS8bzvefP79nfs8eXr9wPqXWM44SwqGmX L5VsC0cjNibRtGnfHvQKddtKOIrGiLIIN+0lTuwr+x9+cBnt8QCH2AL7KNlDTTvgfL5XLCYjaEbJ JTbHEbybsDhEHB7jaXEcoxPwG9JipVTyiiEikW1FKAS3NyYTMsLWQLi091fOuxQeI56IhhGN+8I1 1iwkdjwrC0SyTHwaW8eINm3oZ8xOBvg+ty2KEg4vmnZJ/tnF/ctFtJcZUb7DVrHryb/MLjMYzyqy z3g6zDt1HNfxWrl/CaB8G9etdb2ul/uTADQawUhTLqpPt91od9wMq4DSnwbfnVqnWtbwiv/qFueW K/41vASl/p0tfK/nQxQ1vASleHcL7zi1iu9oeAlK8d4WvlZqdZyahpeggJJotoUuuV7VX402h0wY PTDCG67Tq1Uy52sUzIZ8dokuJiziu+ZaiO6xuAcAAaSIk8jiyzmeoBHMYh9RMoyJdUimARfdoD2M lPdp0yjZahI9WskoJnPetD+eI1gXa6+vX/z4+sUz6/WLp6ePnp8++uX08ePTRz+nvjTDAxRNVcNX 33/x97efWn89++7Vk6/M+ETF//7TZ7/9+qUZCOtozejl10//eP705Tef//nDEwO8FaOhCh+QECfW dXxi3WIhjE0GRmeOh/GbWQwCRDQLFIBvg+suDzTg9SWiJlwb68G7E4OEmIBXF/c0rv0gXnBi6Pla EGrAI8Zom8XGAFwTfSkRHiyiqbnzeKHibiF0bOrbR5GW2u5iDtpJTC79AGs0b1IUcTTFEeaWeMdm GBtGd5cQLa5HZBSzhE24dZdYbUSMIRmQoTaR1kYHJIS8LE0EIdVabI7uWG1GTaPu4GMdCQsCUQP5 AaZaGK+iBUehyeUAhVQN+CHigYlkfxmPVFw34ZDpKabM6o5xkphsbsQwXiXp10A+zGk/ostQR8ac zEw+DxFjKrLDZn6AwrkJ2ydRoGI/SmYwRZF1k3ET/IjpK0Q8Qx5QtDPddwjW0n22ENwG5VQprSeI eLOIDbm8ipk2f/tLOkFYqgwIu6bXIYnOFO+0h/ey3bRbMTEunoMNsd6F+w9KdActopsYVsV2iXqv 0O8V2v7fK/Sutfz2dXktxaDSYjOY7rjl/jvcuf2eEEr7fEnxYSJ34AkUoHEPGoWdPHri/Dg2D+Cn WMnQgYabxkjaWDHjnxAe9AM0h9172RZOpknmeppYc5bAqVE2G30LPF2ER2ycnjrLZXHCTMUjQXzd XnLzdjgx8BTt1dYnqdy9ZDuVJ94VAWH7JiSUznQSVQOJ2qpRBEmeryFoBhJyZG+FRcPAoi7cr1K1 xQKo5VmBHZIF+6qm7TpgAkZwbEIUj0We0lSvsiuT+TYzvSuY2gwowaeNbAasM90QXHcOT4wunWrn yLRGQpluOgkZGVnDkgCNcTY7Ret5aLxprhvrlGr0RCiyWCg0avV/Y3HRXIPdpjbQSFUKGlknTdur ujBlRmjetCdweoef4RzmTiJ2tohO4RPYiMfpgr+IsszjhHdQEqQBl6KTqkFIOI4tSsKmLYafp4FG UkMkt3IFBOGdJdcAWXnXyEHS9STjyQSPuJp2pUVEOn0EhU+1wvhWml8cLCzZAtLdD8Yn1pAu4lsI pphbK4sAjkkCn3jKaTTHBL5K5kK2nn8bhSmTXfWzoJxDaTui8wBlFUUV8xQupTynI5/yGChP2Zgh oEpIskI4nIoCqwZVq6Z51Ug57Ky6ZxuJyCmiua6ZmqqIqmlWMa2HVRnYiOXFirzCahViKJdqhU+l e1NyGyut29gn5FUCAp7Hz1B1z1EQFGrrzjRqgvG2DAvNzlr12rEa4BnUzlMkFNX3Vm434pbXCGN3 0Hihyg92m7MWmiarfaWMtLy+UG8Y2PAeiEcHvuUuKE9kKuH+IEawIerLPUkqG7BE7vNsacAvaxGT pv2g5LYcv+L6hVLd7RacqlMq1N1WtdBy3Wq565ZLnXblIRQWHoRlN7066cEXJ7pML1Catp3dpEjA 1m1KuPq6dmnEwiKTtyVFOQJ5m1Ku7L5NsQiozwOv0mtUG22v0Ki2egWn064XGr7XLnQ8v9bpdXy3 3ug9tK1jCXZaVd/xuvWCV/b9guOVxDjqjULNqVRaTq1V7zqth9l+BkKQ6kgWFIiz5LX/DwAAAP// AwBQSwMEFAAGAAgAAAAhAGUk4i6NAwAAfQ4AAA0AAAB4bC9zdHlsZXMueG1szFfbbts4EH1fYP9B 4LtCSbZc25BU1HGELdAtCiQF+kpLlE2EF4GiUruL/fcdUpatbTc3Jw72xSZHnOE5M8MZMnm/Fdy7 o7phSqYovAiQR2WhSibXKfp6k/tT5DWGyJJwJWmKdrRB77Pff0sas+P0ekOp8cCEbFK0MaaeY9wU GypIc6FqKuFLpbQgBqZ6jZtaU1I2VklwHAXBBAvCJOoszEXxFCOC6Nu29gslamLYinFmds4W8kQx /7iWSpMVB6jbcEyK3rab/GJesEKrRlXmAsxhVVWsoL+inOEZBktZUilpGq9QrTQpegem7Q7zW6m+ y9x+AgfuV2VJ88O7IxwkIcJZUiiutGfAMwDMSSQRtFtxSThbaWaXVUQwvuvEkRU4Z+7XCQbUrBBb HB2aLFnZVW+01+vscz98R/l8rjrAP/M+7SMhCWwQXzP+bLjh2ci5uDWQd4zzwymIbMKDIEvgNBqq ZQ4Tbz++2dWQ7hIKR5e2bt0jq9ea7MIoHihgtyFkutIlFKr+/Nmj1omyhNPKgA80W2/sv1E1/K6U MXCqs6RkZK0k4TDEvcZ+AHQKyvm1LWbfqoNty2pbebIVuTAfyxRBWbSHrh8Ckf2ws9dNwP59SjHo /7eSR+qa7z63YkV17mql281JrS+Ps4Xjf5x/4GwtBbW1COA5hS9aGVoYV8tdluEhu47rgGY4Oomn t60eJWwddg/hXruDPGBhIwq1sCPlbZRmP8Dntoja+CLvuyb1Dd0CX1dB8ba63+Fn2N+mzxtvaTuz YYV1AeT08zwQPjUCtnVZl/4/4vEmaEbP9c0DR3v8irbOH7MXJNSTj9TJIXwBuGd77oGIPlCsu9p1 wll5AbXJCQnm6j5U+kF7+1dzO7QFz95DUvQHdGrNmbyFS60r7kBx1TJumLSlfmrb8c86n2234r0C ZMdA4afmAzjK7bG9uq/G3tJd4z0gAxslrUjLzc3hY4qO4z9pyVoRHVZ9YXfKOBMpOo4/2VtAOLGQ oVl8auCqDP9eq1mK/rpavJstr/LInwaLqT8e0difxYulH48vF8tlPgui4PLvwaPhBU8G97SBDhWO 5w2Hh4Xek91TvD7KUjSYdPDd/QdgD7HPoknwIQ4DPx8FoT+ekKk/nYxiP4/DaDkZL67iPB5gj0/D HgY4DLt3mQUfzw0TFFKjj1UfoaEUggTTB0jgPhK4Obwbs38AAAD//wMAUEsDBBQABgAIAAAAIQC2 mxt9KBEAAKxsAAAYAAAAeGwvd29ya3NoZWV0cy9zaGVldDEueG1slF3bbhvJEX0PkH8g+B6J3SSH pGB6sevFIgskwCKbyzNNjSzCEqmQtL3O16e6u/pSl5GmXmSJPuy6dNWZmuEZzrsf/nh+mnztz5fD 6bidupvZdNIf96f7w/HTdvqvf/7yl/V0crnujve7p9Ox306/95fpD+///Kd3307nz5fHvr9OYIXj ZTt9vF5f7m5vL/vH/nl3uTm99Ef4n4fT+Xl3hT/Pn24vL+d+dx/f9Px062ez7vZ5dzhO0wp35zFr nB4eDvv+59P+y3N/vKZFzv3T7gr+Xx4PL5e82vN+zHLPu/PnLy9/2Z+eX2CJj4enw/V7XHQ6ed7f /frpeDrvPj5B3H+4xW6f145/iOWfD/vz6XJ6uN7AcrfJURnz5nZzCyu9f3d/gAhC2ifn/mE7/dHd ffBzP719/y5m6N+H/tul+X1y3X38vX/q99f+HjZqOgkb8PF0+hyAv8JLM1jzZXfsJ99/f4EwIuZ6 evlb/3D90D89gQU/nez218PX/jeAbacfT9fr6Tn8f9ziK7z0cD79rz9GH6Kp4F1Yk4LTImnRD3N4 839jBPArOH9bvG9/z5H8Esvht/Pkvn/YfXm6/uP07a/94dNjcHdxs4AEhzzf3X//ub/sYYMhrJu4 7P70BGvAz8nzIRQq7M/uj5SHw/31cTtddzddt5h1fjmd7L9cILL/pP9wwavyRshBfCP8+y39P+T8 tTdAfPEN8C++wbsbN9vMV2DoY3+5/oK5lkZvk9MxIT/vrrv3786nbxMoc/D+AmmFpnF3IX/b6Sr7 kBIUITEpy5tuICkQVFjrx7DYdgooSNYFauDr+9m726+Q/D0ifpIIRxEfEsJBJsoifuEL6Bb8Ls4D qHU+ean6CFuRnQxv2k5hf+v6ZfUYxk8JsYwl1JoL+WlypdZHtpJyCcEUKxtmJSFg5wqimxcICRN8 HW03YLdTWLus6vgeJMgYw4AZbThgofQbw4sSTUprQsi0Qr2MthKwLDxWQD8lyJjwoNJHGw5YZrgW ZYovQcYYDgeysYUUsMxwLZNkOEHGGN4YDAcs3VBuNyHkhjo4co+OL4JZgLxyEEMirBjSKy7wx9jc RjCzPV+xskWQEiajn1f5IBAa38eOW8rEU5u3WxYMDdPCRS5RDSEFGWYCKWFa6Mcp/CMSqhBQTQUN E7Z8/G4G8Ju7mUBKmBYacgoPrctOpa5EDCnamgoaZstEUASvV5JCRXI3MxmFMag9hrmWe940pZAP P4zFBbdTEmZNBbXd0s+bthO7vFG0QxTkWwp6y1QE08Lx/KCJGBJmTQUJ07cU9KbtNO+8HmZcMeSY 76aH5Ut/vGkqgGmYblm3KlVtXJFu56rmgsYZGCNT7ZvGE71AQZXBpFIbmk4QJcqWgd40JBnI8xHB SwZaVQwNMvDF6CADmGbY8ykhnBQARomyJaA3o1QIaFnrEROaQIopC994yTeeTwKIabtjVQOnCbUQ kJcE5AXXIUgJ08I3XvKNn4kSHeKbuYVvIpiWietqk6XNQ5CMam6hlwimpnydnNBSoiCyeXWDyeaF E9TR3RDB1LbbiDDDilo7zC3sEsHcVO1ojHOIX+YWfolgasrzMkEMyWjNOs1ooIOx/DIPYGrbdSLM BFIKx0Iwc0kwflbHF8zoEMHMLQQTwSyqTWUPNDU00MwtfBLB3FStdTSVSEdJoIVP5pJP3KYWAZoa 4pOFhU8imJ6q1Xk6GUKIjGlhYZMIpunzwpLCJrU/SO0vLGwSwcw2r0fEKFFayGSReAJ+llFlwTcO MYolC5cs5KziNjVZuHV5WOHD38JCHRFM0+c2Yu+GqGNhoY4IpuUoNmqIOBYW4ohgGpPn8yxiILCy masaNi1HC5Ms5GTiNiLMISZZWJgkglmYfNRDzJgwlxZqiWBq23WcmxEkm2FpIZcIpqbmfFpAzKgw LeSyTFNI2/KuuRqbGhFBSpgWdllKdnEbXrUIUkxZ6GWZmAOKsNS+OK4iRrEUuGDsYLIMYLp34hwB MWTvasOQTlxa6CaCuW2R0CHCWVoIJ4KpKbfhrYggJaMWflkm6iB7xyc9xCiWLPSylIPKXFjKc0qt pFWNm+xdZ6GXCKYJXXDbiJFRdhZ2iWBqac55DDGKJQuXdJJL4PNldnEQQYopC5d0kkvmfJpFTNt2 6+oN3ToLuXSJXMCDQi5uztsOQUqYFnbpJLvM+UCGGBJmrSQapoVdukQcJMxOGB9il87CLhHMSpQP g4ghYdYypmFa6KZLdNOGuRGVlDDKZlroppN0sxCWMt3wkXdlIZcIpvn0s1oT6aCOIBnUysIuEcxN 1X1BU/nMSERloZeVRi88gQhSogqMMfaovgpgOsjzBkeIYsjCJSvJJX7GmwxBiikLlwSpBItJXJNC jGLJwhwryRxz3s6Iadt5VVNM2nlloZIIZvUoaiQsyK70D8xjKwuVRDCzPaunXNgLQ1yysnBJBDNT omwyl9Tj1FCK1xZ2iWBq283rTJTCRJCspLWFXSKYmvKzWiZoaohd1hZ2iWBuSkSVKEiJysIu68Qu 8LMMEF5oVRCkmLLwyzrxC9RcMbUWQSWMYslCL+tEL21QYphGDGn66g1p+rWFcCKY7l0jnMIqGZpU 1hZ6iWBqyTt+ZEWQklALm6wTUZCEciZDTJvQoRF3baGXCKZhyhEXQTLMjYVNIpiaEiMuYkiYNemk bjYWeolgats1upNUOAhSwrTQy0YOL+KYiBgSZh2laJiBQsZOM5sApmHKcRBBSpgWvtkkLmmLVsy4 iFEsQeTjgwpgFpSr2cK9SyDFlIVeNok6CInygxBiFEsWetmkyaRNn3e86RGkmLLQyybRSxuU+JAG MYolC5ls0hwCP8sxSFzqR0xb+s01elL6bmahl4TeTon1OuylMsmgceYtDONmaTgh5nntZBAxP3Bc dDML6yQ0jR6CZZdkMkrus5tZeCahubVK1DnZiY40axaqcTPJNRCJiC2h2tyu60zOKgtQownIzQKa MhBkQNhPKGK/1h+zb2ElN5O0NK+R5WQnkJZsCzG5WWKmto6FHCWDSKw1ISxWC1m5WWIrSoz8hCej tGDBccPOBjSt44VsmgRqgx1S/jiiC4YGfl3miKLfNtdO2i/SYH5RxREl8NvWJEM5cSk6rampVVzU 944dRRKaNY2Y1TNK2cio6B1vLVFNm0lxpdahSLjdyHUtLVq1UeU73rzCUPxCiEPhsBYruDS+aF1A 08yKs3KHIM2YiXsUGbB3MrRB8nEm8olo2o/eCapDlBabiWtQ19tORstaD8irRfwruy/wwvgSSSzS VqgQljiXQG2FrqpHtEJN+l+H4t7W/EJso6IAXlcQM2+ajlDeS8yLfS0a4Do/LutQwcybpiOU/BLz 9diMO63ogpdDBzVvGpcimpb1oo592XyelproB82b5ifUApPoxWiqCIaHozfxFcqBiXkZfSK1tvKH zZsYzCduas0vxTEeQcR8nTBZ6ZkoDXXDhGRqT+W9T0OXwmhR+TuaZFAnTGKVbZZGrDbWRu/CYoWl xnMcCoyJedlmYUl6UX7QvElz7FBPTMyLOi+i49pmw+ZNHIdCZGJe1DmCRiXfJEV2qEVuzQvFdQaN M2/iONQnE/OVvLHOETTOvInjUI/cmnedKP2iWhYH86g7bvoMKjTM3ek24+Y24dcHelQvt80OZ6/8 TLGgpBcmZtMEzHISLChpzURkmoZZXPJzBSWtBdppMvxGJhNJkUzKSbCInaU1qASDtYCmI7UTglj4 7EuiXOU3ypwmeTOc9cml5XymoVxlOOaAibwU3bNbiP7RUK5yHHPANKKhsJlsuLhFzRWJtNjwKFce XV6KANot6lYiXWmo5k4rFq6JrxRdtG9qKTuQzytluMCh4+tbkUb7pnCytbAm64LhcE1UhYJpOKKU S8O+KZzsQBrV0jdbkFs6TaJp2MkYCK2lOs5lawmlWQvkM76WApqlbVG7MltTUI2AlNWSib0U9bST 5xcFJWrJJJd2ml5aDtQaarCWTCJqp6iovWSKgpLhmnhJ0003Z6W4uxpqOFzTYKWoqX2zdHYgnT0q xRzlz6OLGcXSbaO6ThBjQcnkmngJBdO0UUXrFOm1tGYiIUVG7ZaCFjRUc6WGNqpJW+00cXUnwx3k paiGHr+VknG8uFcXbo9G9pLJNZGQorF2zRl8LlNlhPK1vGhyTTpruL1U0nBXZxN0oKBEuCatNdyT KKx5eem+oKQ1Ewmhlpr0iZBBw10rQ1sZFdKjC0fRXLvmDvmcycw49ZAOp5flXIdtpWk4UoTXXn5S oaBeccDES4oc2zW3z+cM5HlJ7q6JlzQBdvMJU7Y2OByZJNjA5qJy3apeaMzWFNTw7gYOGV9emXGa wmmucmcHFNSwAyaqUvTZbiWuyWmoQQdMqm1oJrEFvpkFMQMKari+TVpuqGXpQBNbdiCjRH1H8fXo Ddf03OIWfaegXgnXNEKhhLsdary4ox2aAJMiwzWxlyb1lmStoF4J18ReKO5uw3XNHaF5dwfZK0q2 x+9u5qXazl4I+8C+qLhXwg3kM94BSVVe6iOKXlzurom9FO23k58aaqimwejB0SQId5oivJlP8+7m QUuEa5KAO0UD7puBDa0VlLRmugqlyMDdqo6H2VrmpVpxrtlwmlyTNtwp4nDXaOmzA3nQGuWAiapQ DQ4lWS6UOCGvdkVYLvNtoipUjROmWIojoYbydbJm+TZRlSImhwIvQ2TO9yBVmdTjTpGPe3E7fUXJ 5Jp4SZGQu6W4pKqhmpvCWXJNVKUIy6GfRXLzoCXDNU1VipTcN1WSt3KQl0xicviWnXg8oX0iPmkp mnMRm0k+7jT9+Fp8uqWhGu033cqoAR99jFNU5cBVfCs11LADJl5SpOVO3GDiNNSwAyaqUgTnQIMi A2FNdi122AETVW0yCTXM3MjHsL411LADptNEVJ4Tsm7kOdkBbdCqlM6K0ERommi9iS07IMcx16CY AyZCQ5k6zYBg1IKSTW8iNJSqE2tLMYxoqKFw4SZ5w2Cb0LSYfXNoSPmuKB4u3PphsianKi8mj7Rm 8Elas1zR8lHdTmNza55cFTWcXAuh+Sh45w7wa7EqatgBC6HB3b9IVZDJvJXNS6RP4Gv6TFuZqIoc HIVoM62pb6WFlzzK04MYuc6s8nsFEUbaqbnlhcVrISb41raYSuYBJ4YMox7UozjzwMJMcK+q5oGs 5wQjHjRXQpgHFrbyszRYsRzIgs7zV7NXzaUQ6oFJze5Rp8484MN8hpEcNPdzMQ9MFBZMw9GfeiBu uIX7OCOMelBnR+aBidbKd2DXpm5fYkuDB6Mvc8DtYeh1s3TzElvaREXlK62bpQepKCrLxw6uoBWX XjcvMa9NvFOk6Y3XefiBl9jSJkJBhXk8yiE3ty+xpU1MgXpysnRmBem1iQJQPU6Wzu0uljbJx+Hz dbGN7Us0IbZvh0bVd+t1+xJb2tSNqOgmS+dLNzIhpm5ESTdZerAbo7Z6dMugEpssPdiNUVw9fumm 9bCuUZ0drbFcm7oRFdTxkTp56dSN8SW2tKkbUUJNlk5HfG1pUzeiYJosnbpRW9rUjSiGJkunblSW Ngmd4SQgdmO7dPsSzbXpy5Rh4pdLNy+xpU3diAJl4nXqxiYh6YFG6fk9j99f+vPT4fgZnkVUfsfn N8Wp83x3uN9Oz7/ex6cOSQgUSYFEGxICm10gsQckBDatQBbhvEdAwuRTIFHELyGQxALp4tlTwUB4 L7tP/d9350+H42XyBM+ICk9iCt6nhzXF3+HpUvFVaOH0LKn81yM85quHZxOFZzdNHk6na/4DXA3r /t5fv7xMTucDPOEpPrlrO305na/n3eHa+LSKPpXnjL3/vwAAAAD//wMAUEsDBBQABgAIAAAAIQAz VNitVAEAAGoCAAARAAgBZG9jUHJvcHMvY29yZS54bWwgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAACEkl9LwzAUxd8Fv0PJe5umxTlC2+Ef9iBOBCuKbyG528LapCTRrt/etNtqh4KP yTn3l3MuyRb7ugq+wFipVY5IFKMAFNdCqk2OXstlOEeBdUwJVmkFOerAokVxeZHxhnJt4NnoBoyT YANPUpbyJkdb5xqKseVbqJmNvEN5ca1NzZw/mg1uGN+xDeAkjme4BscEcwz3wLAZieiIFHxENp+m GgCCY6igBuUsJhHBP14HprZ/DgzKxFlL1zW+0zHulC34QRzdeytHY9u2UZsOMXx+gt9Xjy9D1VCq flccUJEJTrkB5rQpbpTbatUFT75lJVWGJ1q/x4pZt/IrX0sQt12xkjsIHvy2bYZ/qx489DjQQQQ+ GT30OClv6d19uURFEpM0jElIrsokpeSaJrOP/vGz+T7p4aI+RviXmIaElAmhcUzT+YR4AhRD7vPf UXwDAAD//wMAUEsDBBQABgAIAAAAIQDsFjgO1wsAALQbAAAnAAAAeGwvcHJpbnRlclNldHRpbmdz L3ByaW50ZXJTZXR0aW5nczEuYmlu7FdpNNRtG7/HpIenrIkYZSlJjD2DGAqVrI1lZMZubIMxjDAZ Km2UrWSKJNF4ky1ZRoWieJMlW9YQj2WU5Y0oTeb9T8uXPj3nPB/ec97jus+13vd1nf/9O3PNuW48 wANbgAHWAAlMgA1k2QINKBYKCMAbRECMBFpAHWgCFGR5g98JtgFsHAJ9UnYcwAMDMDDzJ4nPG9JC wAnyeSAJhzxLqBoFWgSo7j8n2M8SGyDNA/Ev//fKthhzxzH136P/3N/2vYSwIncBwOUf9BSkwX/Z v+tfG6YSwgBvAQd+Jtyv/0Fc3H4njXEtOC8U5EB7XP6V//u5df//G4HffxlPoevaWdkf5d5aGJQC p+89RQKRQBZgAQnqLyLUxwQQDHUbt4dlwT6gA/E+yLIFdlCWJcHD2z/Y18zblwCArYcvwc6fSoCi FAoh9LuPIfj6k4IBMA0PCSRE/lTWJPvwIM9AAsAQwkiB4RTuCR119UiIvUP8uV/z98hUAgANa4wT 916bIfvvUq37J1M+qA/m+IWhFBj4Q/aAmPRmbraVnckhru7g50oAVH4oAIf96Cs9dQD9q3FzYGBK ++fmT6Wm5hDsRQoKCSWEhRG8kaYeFA81NaDXrqwTwT+lbWLxAicQKI0VuYUbjM+qY/TltA6QVast xkcbH8y3xRbJVmTt9ieKeuHcTeU0k3CHTwQ2PUBkLtjZIjrOHLxf4DAj7qdgi2PqKAQtDpryJEid Md5z8TlSvmDDXlHTvLN8wvJPUVqPa2uMmhCzb1tnWK01tPnZFZ/J1szjJZkZVRTta2lIWVu7RZci q9bZIjM0+7oNpfzU4AAuUTYGkRZbKe2g8NlgbEejc5CgygGHu2znSZNmGVzS3sJoxaoIJc6OxWy4 m6nLRvOXO72qhj8w+XtQaXWRWgWKYq88MSphR+ZrXq3cwqy9xNj/sYE+lNU9eXWIfXmBF12we/x4 ULuayaegCQQ9ZzXpY0xwrDWjvw3ZTgxTiNDbuSc6U0WskVqzslltQiKhtDNemGYxW3tSgDVYK9oT Nzql1PxwAOkZcdIsf8jnjv6/2LsWjRzX9pZMBmUFjOy1n6qgaeXe4hEiSM77DfKfZxfHcbI+Zk/U xmLW8ls4OEdcOxJbUZ32WG2Zf6Rx1ZXBVjAqCM1GM1wH53x4UZ8jE8a2uiNoXXv9Pr0cY3x4UcG6 aGLwqqZZ5q8O3LXY1EGjHLbmpFEu22Io322K+voWEdQtfpFr0NGauaR0Am/Mljyoc2LV89EIYWX7 4os0Qz9UUl8LnFoVrVQg95icbKlnz3fi0jBH2ItdTuPoWai04z553KM1itxHB/RMURYiLh375irR E6zWXHbe5+vKylKVPyfpjFLeyfln1lHH+2rTozVd87bh81vxr/tRu1tcI749pCOe9Cl0m9VoHzTR to5ZFZsRmckXLxfo3PPZtfwNZvtRpOQrwhH0o4qG569HUQyXw49LCZsyjl4W9BoI0C8SGRe7YyW2 2ytz4KvosL5Js426kcr2Xo/OvQU5G+81jBbcnkE+FT7oElcfYdI5YFyVS4OXVnYEnXE54LCr9Rhy vMBfQDJ5ZqfNM46k0bEYCVJNtqQ8elBRksSqqYmeVztk6UdPM2qaPRcVID0R1SlezdsTOoFSn8fG GC4SFz2/vuclDhGjHkS5YddmAuxJezhuk0LK8/dPkVrtStKq2ur59iwYcE5LVEe7v+u2kolWCZEz CF/tY5zUfw0/ekMYPkVrSO4DqAUM6piyvX7CpWtzF0qlZDOcQwrXpPDKcgxLDIx2IOQbWS7VCNb7 rdsKrmRrppmU4CdIO9d4W7yxsv70fXjZjHjUbLnOuRFNDUS2Z6tYffWSw5+tCjMXdmD1Q97G+65g hBJhHYJUY50AXh3jrZWHLUN7JBsqL+4QPV6TbJxbf1rZNczDYP9jys7ZrZl1p2qeDJ2+v8WZbVBI 5OscUC3zJFaR3/gO1QffpS1hiUbnpZlS48uuyyy5VfnZZzkRvJWxF+BYxK4KRGUPvDrRSfSSLgVH 94g3tHTLFXJfkbh0ES3l66Yx2HbuyXIHfVompZdgeq5qf0h/6L12/r13ZDrpL2I1ireTmQWhCUUX a61F+r7tSiqWDalwYma4WwXayXXkjW3yQHXnDscrd63VpuwQsaQtbDmti/fYRPf0wIvwG5XFEdGG R/NzDqf3F+jiK9J7EyznYbgT/U8rTi13GXwuPm9mWqUb8tYq4t3lJbvFcjQxf0L8PP2i97aRg6vi 157ZqFf2KJH7Q4lABxdcIVn1MHHJSvOdoimdTC18uGDfZKYrcLzTS8Jw9zvFV4Wqd58ERstdKHHo J4iOxFAzBXExY5W7jB44yN8UuXlkv7DRsvPUMT6sbkNt7vXhHKWzw3U8lQdelawBZuVodGH94md2 7Ray3Pj4tGdfwvN65uD0RWGEIVrNYrqKovWBqNjWtE8p5J7vkXMq8qxUeeKSARpvNmXq+tjd7b00 Ey24IU7UYsl2RMXbcV6jDKNvU5TSC5v+z850mkaxwL8NMLn34vff0AznSesQCx9rqd2MvyaIR45t x4wXhEWWpRxpOYlH4+O/eGnLxebd/CuZ1xwyVWPzpCeSw658bPJrZqeW3TRqs2qWyVVaPNwcusbc oxTrjUd4sODG2mfR1S9lSJbNMpISg8tM74S0q+wH27BjenlUyyVhWOSG5jE9+ysUwbsNL5ZNj++/ 4KiQZXKP/CLbMu1d2LQjPn4edufjDne8SkLo0o7bfFjPW+IVY2rN/rccr6flmxUZJIZm5LfaNHfd cbx1SK+1S3zXhP/lV23t2m2+Yv1tXeK7J/wT7uvAsCcWyzH4eLJHgNGzVHmChqqKRcImu/GAG5XM wOfnEGSFyYpjyiV3b05WuJhHFQ1gXc7QCPtL3man9WoW20sGfchymlwcMGT2RdQkf2MyeEJ5iukK 89uurtSaRLqq+kn3YpRv/YsyGnDlPfoLnGCdIid3tOWCq1UKXUacMdCyQ5IdXm8QRRuJYtN937j1 fwpbs363UWzt6W1znuiNvcjTMcl5R+Dacu79iSGi6vqG2zlfvmKUSJn8THqwShCKeuLg9Fu/G7Dz ydNHlaxWliz6QoKaG5h1TYmb2gPw6EaXJIREhsvqRXLsJQRW6z65ZEP5NPPAEYLTwUPWLKpPSkvO qXQffs2qdueiEt7y8ubsIiebx7775hJPpUc+/CAWtNxWOtAAQ7Ia716dSz2VThnv9F/0M7Z4RGYV TjlxdYV/43YhP3NUsWorcwv3YE++5IqPsQVCuzeRhtK1qMne7GduMFliRoLKx1sVb32SeyZtVtEQ KRjQnzBMe3MYtjzjY3k4zlkn1w2VYj2qy3qhP9+kkqt1GSfa3ZkUnmhOWjbxipyjXc9XnLWjb6zo ez9OvfDEmpVFxt44gMycqOAhFgrYINLsSYxU4hnnm+2SqbKl2JQkj8oOsbKCzQH+EnX6pzVDBM4e dTiAbOsl0uQHbzRJwcicQRGXpbphmSEqm/1CKHci1XOleIRIbaGQ1ly7xhkn6bP7DD0ejaS7dl1l fM19TqQ2U+bfPGHAIaePSB2gzAfXMMy7aoiLGa7qb2VkXLuSLVcOx/VSuikyxVFWTZYrOdm9lCGK zCGqlaLlity93iUGC/3kU4Z1xpwJoYSVxkJ/WM6ICXok5FDDMGF8Le0lrtay0NqfMpKuzzUEtI9U flYY8sEuXLAJ3n9ysvvZSwv0FbXRG8FO28ffF2EwbWqcYVzgZLLENg5bRqgOTnM0WCsZ2Zy+3PIq v0/4a7bvzF9XP5HvL3tlNbx+lIl1MC2ZJN5LRXX3fOy9+zq8pSlsa1tP/bzFbLVUsZfqmue3codA +964eBaHhwMRANpTJjZW+3iAKDTFRgIvSAYC1e82AUCPThAEPEEA2AzZXBIAYtB8R+Kb+fPnaAcp 7owpBqSh96w2lKkOsQ5ka0JSFZqH1aGlBcSBFBTjvnBVv+/pfT/FlShoSUDVQ9Ax3LF5ndYRWEdg HYF1BNYRWEdgHYF1BNYRWEdgHYH/AQL/BQAA//8DAFBLAwQUAAYACAAAACEAPAIw/oEBAAD+AgAA EAAIAWRvY1Byb3BzL2FwcC54bWwgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACc kkFv2zAMhe8D+h8M3RM5bTAMgayiaFr00GIBknZnVaZjIYpkiKyR7NePtpHF2XrqjeR7ePpESd0e 9j5rIaGLoRCzaS4yCDaWLmwL8bp5nPwQGZIJpfExQCGOgOJWX31TqxQbSOQAM44IWIiaqFlIibaG vcEpy4GVKqa9IW7TVsaqchaW0X7sIZC8zvPvEg4EoYRy0vwNFEPioqWvhpbRdnz4tjk2DKzVXdN4 Zw3xLfWLsylirCh7OFjwSo5FxXRrsB/J0VHnSo5btbbGwz0H68p4BCXPA/UEplvayriEWrW0aMFS TBm637y2a5G9G4QOpxCtSc4EYqzONjR97RukpH/FtMMagFBJNgzDvhx7x7Wb61lv4OLS2AUMICxc Im4cecCf1cok+oR4NibuGQbeAWfd8Q1njvn6K/NJ/2Q/u7DD12YTl4bgtLvLoVrXJkHJ6z7p54F6 4rUl34Xc1yZsoTx5/he6l34bvrOezaf5Tc6POJopef64+g8AAAD//wMAUEsBAi0AFAAGAAgAAAAh AEE3gs9yAQAABAUAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAU AAYACAAAACEAtVUwI/UAAABMAgAACwAAAAAAAAAAAAAAAACrAwAAX3JlbHMvLnJlbHNQSwECLQAU AAYACAAAACEAgT6Ul/QAAAC6AgAAGgAAAAAAAAAAAAAAAADRBgAAeGwvX3JlbHMvd29ya2Jvb2su eG1sLnJlbHNQSwECLQAUAAYACAAAACEAHSV2QaUBAACzAgAADwAAAAAAAAAAAAAAAAAFCQAAeGwv d29ya2Jvb2sueG1sUEsBAi0AFAAGAAgAAAAhAHJL9o8xDQAAu0sAABQAAAAAAAAAAAAAAAAA1woA AHhsL3NoYXJlZFN0cmluZ3MueG1sUEsBAi0AFAAGAAgAAAAhAHCxQL1qAQAAwQUAACMAAAAAAAAA AAAAAAAAOhgAAHhsL3dvcmtzaGVldHMvX3JlbHMvc2hlZXQxLnhtbC5yZWxzUEsBAi0AFAAGAAgA AAAhAP/x+4CnBgAAWxoAABMAAAAAAAAAAAAAAAAA5RkAAHhsL3RoZW1lL3RoZW1lMS54bWxQSwEC LQAUAAYACAAAACEAZSTiLo0DAAB9DgAADQAAAAAAAAAAAAAAAAC9IAAAeGwvc3R5bGVzLnhtbFBL AQItABQABgAIAAAAIQC2mxt9KBEAAKxsAAAYAAAAAAAAAAAAAAAAAHUkAAB4bC93b3Jrc2hlZXRz L3NoZWV0MS54bWxQSwECLQAUAAYACAAAACEAM1TYrVQBAABqAgAAEQAAAAAAAAAAAAAAAADTNQAA ZG9jUHJvcHMvY29yZS54bWxQSwECLQAUAAYACAAAACEA7BY4DtcLAAC0GwAAJwAAAAAAAAAAAAAA AABeOAAAeGwvcHJpbnRlclNldHRpbmdzL3ByaW50ZXJTZXR0aW5nczEuYmluUEsBAi0AFAAGAAgA AAAhADwCMP6BAQAA/gIAABAAAAAAAAAAAAAAAAAAekQAAGRvY1Byb3BzL2FwcC54bWxQSwUGAAAA AAwADAAmAwAAMUcAAAAA --_004_4E1F6AAD24975D4BA5B1680429673943674F7728TK5EX14MBXC283r_-- From jricher@mitre.org Mon Mar 11 15:42: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 54DD421F902A for ; Mon, 11 Mar 2013 15:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.518 X-Spam-Level: X-Spam-Status: No, score=-6.518 tagged_above=-999 required=5 tests=[AWL=0.080, 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 YrNfGU96qO7y for ; Mon, 11 Mar 2013 15:42:20 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id EF3B521F902D for ; Mon, 11 Mar 2013 15:42:19 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 9A14262501CD; Mon, 11 Mar 2013 18:42:19 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 870D462501CA; Mon, 11 Mar 2013 18:42:19 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.59]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.02.0318.004; Mon, 11 Mar 2013 18:42:19 -0400 From: "Richer, Justin P." To: Brian Campbell Thread-Topic: [OAUTH-WG] Registration: Internationalization of Human-Readable names Thread-Index: AQHOHp2D44pYbE8oI0KylL+zHw2NHJihSneAgAABTACAAAkEAIAAAoyAgAAB2QA= Date: Mon, 11 Mar 2013 22:42:18 +0000 Message-ID: References: <1B4C0C9F-4B8E-4B2D-BAF7-665D3EBBE56C@ve7jtb.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.4.254] Content-Type: multipart/alternative; boundary="_000_B33BFB58CCC8BE4998958016839DE27E08F3EF85IMCMBX01MITREOR_" MIME-Version: 1.0 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readable names X-BeenThere: oauth@ietf.org X-Mailman-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, 11 Mar 2013 22:42:21 -0000 --_000_B33BFB58CCC8BE4998958016839DE27E08F3EF85IMCMBX01MITREOR_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable It does presume a definition of "claim", which I suppose we could turn to "= metadata field" for DynReg and its extensions to be appropriately limiting.= But we also need a good definition of what a language-tag-less field means= , and whether or not it's required if the other fields are present or not (= which is something that Connect is trying to fix at the moment, as I recall= from last week). So it turns into about a paragraph worth of text. Is that worth it? I'm not= entirely convinced that it is, but I'm interested to hear what others thin= k, particularly those who *aren't* tied into the OpenID Connect protocol so= much. (I don't want to pick a solution just because it's familiar, if we n= eed a solution at all.) -- Justin On Mar 11, 2013, at 6:35 PM, Brian Campbell > wrote: A fair question but what would need to be pulled in is really probably only= a couple sentences (and reference) from http://openid.net/specs/openid-con= nect-messages-1_0-16.html#ClaimsLanguagesAndScripts (note the reference to = 2.1.1.1.3 inside http://openid.net/specs/openid-connect-registration-1_0-15= .html is broken) On Mon, Mar 11, 2013 at 6:26 PM, Richer, Justin P. > wrote: My concern with this is that OIDC can get away with defining this multi-lan= guage structure because it defines the mechanism once (in Messages) and app= lies it to all user-readable strings throughout the whole application proto= col, of which there are several. Do we really want to pull in that whole st= ructure and mechanism for one field in client registration? I really don't = think it should be something that's defined completely inside of DynReg for= a corner case for a single field, but I also doubt we want to normatively = point to OIDC Messages for this solution either. There are also other ways to do this: Webfinger [1] for instance uses JSON = structures to give language tags to field values, and has a default mechani= sm: { "en_us": "my client", =1B$B!D=1B(B } The fundamental question is this: should a client be able to register mult= iple names (in different locales) with a single client_id, or should it get= a different client_id for each display language set? -- Justin [1] http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-11 On Mar 11, 2013, at 5:54 PM, John Bradley > wrote: That is what I was thinking. It would be up to the AS to determine what l= anguage and script to present based on the user preference. While a large number of clients will be native and might be able to customi= ze themselves for a single user during registration , we don't want to forg= et the web server clients that are multi user. On 2013-03-11, at 10:49 PM, Brian Campbell > wrote: FWIW, the closely related OpenID Connect client registration draft does hav= e some support for doing this, which could maybe be borrowed. See client_na= me in =1B$B!x=1B(B2 at http://openid.net/specs/openid-connect-registration-= 1_0-15.html#client-metadata and the examples. "client_name": "My Example", "client_name#ja-Jpan-JP":"=1B$B%/%i%$%"%s%HL>=1B(B", On Mon, Mar 11, 2013 at 5:15 PM, Richer, Justin P. > wrote: It was brought up at the in-person meeting today that we'll want to conside= r issues around internationalization and localization of human-readable fie= lds like client_name in the client registration. Which is to say: if a clie= nt supports ten languages and wants to present itself in ten languages, sho= uld it have to register itself ten times with an AS? At the moment, I'm of the opinion a client with ten languages could registe= r itself ten times, or do something with the context in which it runs to de= termine which human-facing language to use. Keep in mind that in some cases= (such as native clients), you'll be dynamically registering a client for e= ach user, in effect. In other words, I personally think that this is a rath= ole that will cause more harm than good. -- Justin _______________________________________________ OAuth mailing 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_B33BFB58CCC8BE4998958016839DE27E08F3EF85IMCMBX01MITREOR_ Content-Type: text/html; charset="iso-2022-jp" Content-ID: <2412AD20DD269F42A7B9245C53495B46@imc.mitre.org> Content-Transfer-Encoding: quoted-printable It does presume a definition of "claim", which I suppose we could= turn to "metadata field" for DynReg and its extensions to be app= ropriately limiting. But we also need a good definition of what a language-= tag-less field means, and whether or not it's required if the other fields are present or not (which is something that Connect is= trying to fix at the moment, as I recall from last week). 

So it turns into about a paragraph worth of text. Is that worth it? I'= m not entirely convinced that it is, but I'm interested to hear what others= think, particularly those who *aren't* tied into the OpenID Connect protoc= ol so much. (I don't want to pick a solution just because it's familiar, if we need a solution at all.)

 -- Justin

On Mar 11, 2013, at 6:35 PM, Brian Campbell <bcampbell@pingidentity.com>
 wrote:

A fair question but what would need to be pulled in is rea= lly probably only a couple sentences (and reference) from http://openid.net/specs/openid-connect-messages-1_0-16.html#ClaimsLanguages= AndScripts (note the reference to 2.1.1.1.3 inside http://openid.net/specs/openid-connect-registration-1_0-15.html is bro= ken)


On Mon, Mar 11, 2013 at 6:26 PM, Richer, Justin = P. <jricher@mitre.or= g> wrote:
My concern with this is that OIDC can g= et away with defining this multi-language structure because it defines the = mechanism once (in Messages) and applies it to all user-readable strings th= roughout the whole application protocol, of which there are several. Do we really want to pull in that whole struct= ure and mechanism for one field in client registration? I really don't thin= k it should be something that's defined completely inside of DynReg for a c= orner case for a single field, but I also doubt we want to normatively point to OIDC Messages for this soluti= on either.

There are also other ways to do this: Webfinger [1] for instance uses = JSON structures to give language tags to field values, and has a default me= chanism:

   { "en_us": "my client", =1B$B!D=1B(B = }

The fundamental question is  this: should a client be able to reg= ister multiple names (in different locales) with a single client_id, or sho= uld it get a different client_id for each display language set?

 -- Justin


On Mar 11, 2013, at 5:54 PM, John Bradley <ve7jtb@ve7jtb.com>
 wrote:

That is what I was thinking.   It = would be up to the AS to determine what language and script to present base= d on the user preference.

While a large number of clients will be native and might be able to cu= stomize themselves for a single user during registration , we don't want to= forget the web server clients that are multi user.

On 2013-03-11, at 10:49 PM, Brian Campbell <bcampbell@pingidentity.com>= wrote:

FWIW, the closely related OpenID Connect client registrati= on draft does have some support for doing this, which could maybe be borrow= ed. See client_name in =1B$B!x=1B(B2 at http://openid.net/specs/openid-connect-registration-1_0-15.html#client-meta= data and the examples.
 
   "client_name": "My Example",
   "client_name#ja-Jpan-JP":"=1B$B%/%i%$%"%s%HL>=1B(B",=



On Mon, Mar 11, 2013 at 5:15 PM, Richer, Justin = P. <jricher@mitre.or= g> wrote:
It was brought up at the in-person meeting today that we'll want to conside= r issues around internationalization and localization of human-readable fie= lds like client_name in the client registration. Which is to say: if a clie= nt supports ten languages and wants to present itself in ten languages, should it have to register itself ten = times with an AS?

At the moment, I'm of the opinion a client with ten languages could registe= r itself ten times, or do something with the context in which it runs to de= termine which human-facing language to use. Keep in mind that in some cases= (such as native clients), you'll be dynamically registering a client for each user, in effect. In other wor= ds, I personally think that this is a rathole that will cause more harm tha= n good.

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

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




--_000_B33BFB58CCC8BE4998958016839DE27E08F3EF85IMCMBX01MITREOR_-- From sakimura@gmail.com Mon Mar 11 15:52: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 0F42C21F90D2 for ; Mon, 11 Mar 2013 15:52:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.247 X-Spam-Level: X-Spam-Status: No, score=-2.247 tagged_above=-999 required=5 tests=[AWL=-0.402, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, 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 Cj2GrZQV-FXs for ; Mon, 11 Mar 2013 15:52:42 -0700 (PDT) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) by ietfa.amsl.com (Postfix) with ESMTP id 6524621F90D0 for ; Mon, 11 Mar 2013 15:52:41 -0700 (PDT) Received: by mail-lb0-f177.google.com with SMTP id go11so3508709lbb.8 for ; Mon, 11 Mar 2013 15:52:40 -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=t/WmzqQDzNUtzj5pXPgWPI3QVBMyFAbuq7ZKf8iVvas=; b=NiCJoz52gjR9YhTu78uAomHAN3FuBWiTd2IW6v3BIN7nH0PxVbpS+oI5Ot/g/Ku5iq FprdL/SLNgUYUIqRuuC99D43Nph5c75al/pLr8LLHpRWWlr3VvI4FWbJfNKaas2Tw2Rx 7dX6XG1z0zw3sB80jxUhAJamVTs6TeouqnAUgMXFbTcf7KE4taKs+/JYxieJJubt9ykv oSYIhJlHaK0yLa0+3gO8qazg1+V2RXOvV66OI8yPVrvdtE3kX1eakvU+1wD0FRMoD0Eb 9RPYjZ6cLfImcdeY3ExuYC1LZ8JMPazvbcO4Uz6xtRqgMtbF5SOhUqSRy0bVOOSrpo9g znPA== MIME-Version: 1.0 X-Received: by 10.152.105.38 with SMTP id gj6mr11693058lab.25.1363042360070; Mon, 11 Mar 2013 15:52:40 -0700 (PDT) Received: by 10.112.14.44 with HTTP; Mon, 11 Mar 2013 15:52:39 -0700 (PDT) In-Reply-To: References: <1B4C0C9F-4B8E-4B2D-BAF7-665D3EBBE56C@ve7jtb.com> Date: Tue, 12 Mar 2013 07:52:39 +0900 Message-ID: From: Nat Sakimura To: "Richer, Justin P." Content-Type: multipart/alternative; boundary=f46d0408d3f7af97e104d7ae070d Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readable names X-BeenThere: oauth@ietf.org X-Mailman-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, 11 Mar 2013 22:52:44 -0000 --f46d0408d3f7af97e104d7ae070d Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Similar work is in progress at Webfinger. See: http://www.ietf.org/mail-archive/web/webfinger/current/msg00530.html Paul is proposing the same syntax as Connect. 2013/3/12 Richer, Justin P. > It does presume a definition of "claim", which I suppose we could turn to > "metadata field" for DynReg and its extensions to be appropriately > limiting. But we also need a good definition of what a language-tag-less > field means, and whether or not it's required if the other fields are > present or not (which is something that Connect is trying to fix at the > moment, as I recall from last week). > > So it turns into about a paragraph worth of text. Is that worth it? I'm > not entirely convinced that it is, but I'm interested to hear what others > think, particularly those who *aren't* tied into the OpenID Connect > protocol so much. (I don't want to pick a solution just because it's > familiar, if we need a solution at all.) > > -- Justin > > On Mar 11, 2013, at 6:35 PM, Brian Campbell > wrote: > > A fair question but what would need to be pulled in is really probably > only a couple sentences (and reference) from > http://openid.net/specs/openid-connect-messages-1_0-16.html#ClaimsLanguagesAndScripts(note the reference to 2.1.1.1.3 inside > http://openid.net/specs/openid-connect-registration-1_0-15.html is broken) > > > On Mon, Mar 11, 2013 at 6:26 PM, Richer, Justin P. wrote: > >> My concern with this is that OIDC can get away with defining this >> multi-language structure because it defines the mechanism once (in >> Messages) and applies it to all user-readable strings throughout the whole >> application protocol, of which there are several. Do we really want to pull >> in that whole structure and mechanism for one field in client registration? >> I really don't think it should be something that's defined completely >> inside of DynReg for a corner case for a single field, but I also doubt we >> want to normatively point to OIDC Messages for this solution either. >> >> There are also other ways to do this: Webfinger [1] for instance uses >> JSON structures to give language tags to field values, and has a default >> mechanism: >> >> { "en_us": "my client", $B!D(B } >> >> The fundamental question is this: should a client be able to register >> multiple names (in different locales) with a single client_id, or should it >> get a different client_id for each display language set? >> >> -- Justin >> >> [1] http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-11 >> >> On Mar 11, 2013, at 5:54 PM, John Bradley >> wrote: >> >> That is what I was thinking. It would be up to the AS to determine >> what language and script to present based on the user preference. >> >> While a large number of clients will be native and might be able to >> customize themselves for a single user during registration , we don't want >> to forget the web server clients that are multi user. >> >> On 2013-03-11, at 10:49 PM, Brian Campbell >> wrote: >> >> FWIW, the closely related OpenID Connect client registration draft does >> have some support for doing this, which could maybe be borrowed. See >> client_name in $B!x(B2 at >> http://openid.net/specs/openid-connect-registration-1_0-15.html#client-metadataand the examples. >> >> >> "client_name": "My Example", >> "client_name#ja-Jpan-JP":"$B%/%i%$%"%s%HL>(B", >> >> >> >> >> On Mon, Mar 11, 2013 at 5:15 PM, Richer, Justin P. wrote: >> >>> It was brought up at the in-person meeting today that we'll want to >>> consider issues around internationalization and localization of >>> human-readable fields like client_name in the client registration. Which is >>> to say: if a client supports ten languages and wants to present itself in >>> ten languages, should it have to register itself ten times with an AS? >>> >>> At the moment, I'm of the opinion a client with ten languages could >>> register itself ten times, or do something with the context in which it >>> runs to determine which human-facing language to use. Keep in mind that in >>> some cases (such as native clients), you'll be dynamically registering a >>> client for each user, in effect. In other words, I personally think that >>> this is a rathole that will cause more harm than good. >>> >>> -- Justin >>> _______________________________________________ >>> OAuth mailing 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 > > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --f46d0408d3f7af97e104d7ae070d Content-Type: text/html; charset=ISO-2022-JP Content-Transfer-Encoding: base64 U2ltaWxhciB3b3JrIGlzIGluIHByb2dyZXNzIGF0IFdlYmZpbmdlci4mbmJzcDs8ZGl2Pjxicj48 L2Rpdj48ZGl2PlNlZTombmJzcDs8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJj aGl2ZS93ZWIvd2ViZmluZ2VyL2N1cnJlbnQvbXNnMDA1MzAuaHRtbCI+aHR0cDovL3d3dy5pZXRm Lm9yZy9tYWlsLWFyY2hpdmUvd2ViL3dlYmZpbmdlci9jdXJyZW50L21zZzAwNTMwLmh0bWw8L2E+ PC9kaXY+DQo8ZGl2Pjxicj48L2Rpdj48ZGl2PlBhdWwgaXMgcHJvcG9zaW5nIHRoZSBzYW1lIHN5 bnRheCBhcyBDb25uZWN0LiZuYnNwOzxicj48YnI+PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPjIw MTMvMy8xMiBSaWNoZXIsIEp1c3RpbiBQLiA8c3BhbiBkaXI9Imx0ciI+Jmx0OzxhIGhyZWY9Im1h aWx0bzpqcmljaGVyQG1pdHJlLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmpyaWNoZXJAbWl0cmUub3Jn PC9hPiZndDs8L3NwYW4+PGJyPg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHls ZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1s ZWZ0OjFleCI+DQoNCg0KDQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+DQpJdCBk b2VzIHByZXN1bWUgYSBkZWZpbml0aW9uIG9mICZxdW90O2NsYWltJnF1b3Q7LCB3aGljaCBJIHN1 cHBvc2Ugd2UgY291bGQgdHVybiB0byAmcXVvdDttZXRhZGF0YSBmaWVsZCZxdW90OyBmb3IgRHlu UmVnIGFuZCBpdHMgZXh0ZW5zaW9ucyB0byBiZSBhcHByb3ByaWF0ZWx5IGxpbWl0aW5nLiBCdXQg d2UgYWxzbyBuZWVkIGEgZ29vZCBkZWZpbml0aW9uIG9mIHdoYXQgYSBsYW5ndWFnZS10YWctbGVz cyBmaWVsZCBtZWFucywgYW5kIHdoZXRoZXIgb3Igbm90IGl0JiMzOTtzIHJlcXVpcmVkDQogaWYg dGhlIG90aGVyIGZpZWxkcyBhcmUgcHJlc2VudCBvciBub3QgKHdoaWNoIGlzIHNvbWV0aGluZyB0 aGF0IENvbm5lY3QgaXMgdHJ5aW5nIHRvIGZpeCBhdCB0aGUgbW9tZW50LCBhcyBJIHJlY2FsbCBm cm9tIGxhc3Qgd2VlaykuJm5ic3A7DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5TbyBpdCB0dXJu cyBpbnRvIGFib3V0IGEgcGFyYWdyYXBoIHdvcnRoIG9mIHRleHQuIElzIHRoYXQgd29ydGggaXQ/ IEkmIzM5O20gbm90IGVudGlyZWx5IGNvbnZpbmNlZCB0aGF0IGl0IGlzLCBidXQgSSYjMzk7bSBp bnRlcmVzdGVkIHRvIGhlYXIgd2hhdCBvdGhlcnMgdGhpbmssIHBhcnRpY3VsYXJseSB0aG9zZSB3 aG8gKmFyZW4mIzM5O3QqIHRpZWQgaW50byB0aGUgT3BlbklEIENvbm5lY3QgcHJvdG9jb2wgc28g bXVjaC4gKEkgZG9uJiMzOTt0IHdhbnQgdG8gcGljaw0KIGEgc29sdXRpb24ganVzdCBiZWNhdXNl IGl0JiMzOTtzIGZhbWlsaWFyLCBpZiB3ZSBuZWVkIGEgc29sdXRpb24gYXQgYWxsLik8YnI+DQo8 ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4mbmJzcDstLSBKdXN0aW48L2Rpdj4NCjxkaXY+PGJyPg0K PGRpdj4NCjxkaXY+T24gTWFyIDExLCAyMDEzLCBhdCA2OjM1IFBNLCBCcmlhbiBDYW1wYmVsbCAm bHQ7PGEgaHJlZj0ibWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tIiB0YXJnZXQ9Il9i bGFuayI+YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208L2E+Jmd0OzwvZGl2PjxkaXY+PGRpdiBj bGFzcz0iaDUiPg0KPGRpdj4mbmJzcDt3cm90ZTo8L2Rpdj4NCjxicj4NCjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiPg0KPGRpdiBkaXI9Imx0ciI+QSBmYWlyIHF1ZXN0aW9uIGJ1dCB3aGF0IHdvdWxk IG5lZWQgdG8gYmUgcHVsbGVkIGluIGlzIHJlYWxseSBwcm9iYWJseSBvbmx5IGEgY291cGxlIHNl bnRlbmNlcyAoYW5kIHJlZmVyZW5jZSkgZnJvbQ0KPGEgaHJlZj0iaHR0cDovL29wZW5pZC5uZXQv c3BlY3Mvb3BlbmlkLWNvbm5lY3QtbWVzc2FnZXMtMV8wLTE2Lmh0bWwjQ2xhaW1zTGFuZ3VhZ2Vz QW5kU2NyaXB0cyIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cDovL29wZW5pZC5uZXQvc3BlY3Mvb3Bl bmlkLWNvbm5lY3QtbWVzc2FnZXMtMV8wLTE2Lmh0bWwjQ2xhaW1zTGFuZ3VhZ2VzQW5kU2NyaXB0 czwvYT4gKG5vdGUgdGhlIHJlZmVyZW5jZSB0byAyLjEuMS4xLjMgaW5zaWRlDQo8YSBocmVmPSJo dHRwOi8vb3BlbmlkLm5ldC9zcGVjcy9vcGVuaWQtY29ubmVjdC1yZWdpc3RyYXRpb24tMV8wLTE1 Lmh0bWwiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vb3BlbmlkLm5ldC9zcGVjcy9vcGVuaWQtY29u bmVjdC1yZWdpc3RyYXRpb24tMV8wLTE1Lmh0bWw8L2E+IGlzIGJyb2tlbik8YnI+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48YnI+DQo8YnI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9x dW90ZSI+T24gTW9uLCBNYXIgMTEsIDIwMTMgYXQgNjoyNiBQTSwgUmljaGVyLCBKdXN0aW4gUC4g PHNwYW4gZGlyPSJsdHIiPg0KJmx0OzxhIGhyZWY9Im1haWx0bzpqcmljaGVyQG1pdHJlLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPmpyaWNoZXJAbWl0cmUub3JnPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxi cj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAu OGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBz dHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQiPk15IGNvbmNlcm4gd2l0aCB0aGlzIGlzIHRoYXQg T0lEQyBjYW4gZ2V0IGF3YXkgd2l0aCBkZWZpbmluZyB0aGlzIG11bHRpLWxhbmd1YWdlIHN0cnVj dHVyZSBiZWNhdXNlIGl0IGRlZmluZXMgdGhlIG1lY2hhbmlzbSBvbmNlIChpbiBNZXNzYWdlcykg YW5kIGFwcGxpZXMgaXQgdG8gYWxsIHVzZXItcmVhZGFibGUgc3RyaW5ncyB0aHJvdWdob3V0IHRo ZSB3aG9sZSBhcHBsaWNhdGlvbiBwcm90b2NvbCwNCiBvZiB3aGljaCB0aGVyZSBhcmUgc2V2ZXJh bC4gRG8gd2UgcmVhbGx5IHdhbnQgdG8gcHVsbCBpbiB0aGF0IHdob2xlIHN0cnVjdHVyZSBhbmQg bWVjaGFuaXNtIGZvciBvbmUgZmllbGQgaW4gY2xpZW50IHJlZ2lzdHJhdGlvbj8gSSByZWFsbHkg ZG9uJiMzOTt0IHRoaW5rIGl0IHNob3VsZCBiZSBzb21ldGhpbmcgdGhhdCYjMzk7cyBkZWZpbmVk IGNvbXBsZXRlbHkgaW5zaWRlIG9mIER5blJlZyBmb3IgYSBjb3JuZXIgY2FzZSBmb3IgYSBzaW5n bGUgZmllbGQsIGJ1dA0KIEkgYWxzbyBkb3VidCB3ZSB3YW50IHRvIG5vcm1hdGl2ZWx5IHBvaW50 IHRvIE9JREMgTWVzc2FnZXMgZm9yIHRoaXMgc29sdXRpb24gZWl0aGVyLg0KPGRpdj48YnI+DQo8 L2Rpdj4NCjxkaXY+VGhlcmUgYXJlIGFsc28gb3RoZXIgd2F5cyB0byBkbyB0aGlzOiBXZWJmaW5n ZXIgWzFdIGZvciBpbnN0YW5jZSB1c2VzIEpTT04gc3RydWN0dXJlcyB0byBnaXZlIGxhbmd1YWdl IHRhZ3MgdG8gZmllbGQgdmFsdWVzLCBhbmQgaGFzIGEgZGVmYXVsdCBtZWNoYW5pc206PC9kaXY+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4mbmJzcDsgJm5ic3A7eyAmcXVvdDtlbl91cyZxdW90 OzogJnF1b3Q7bXkgY2xpZW50JnF1b3Q7LCAmaGVsbGlwOyB9PC9kaXY+DQo8ZGl2Pjxicj4NCjwv ZGl2Pg0KPGRpdj5UaGUgZnVuZGFtZW50YWwgcXVlc3Rpb24gaXMgJm5ic3A7dGhpczogc2hvdWxk IGEgY2xpZW50IGJlIGFibGUgdG8gcmVnaXN0ZXIgbXVsdGlwbGUgbmFtZXMgKGluIGRpZmZlcmVu dCBsb2NhbGVzKSB3aXRoIGEgc2luZ2xlIGNsaWVudF9pZCwgb3Igc2hvdWxkIGl0IGdldCBhIGRp ZmZlcmVudCBjbGllbnRfaWQgZm9yIGVhY2ggZGlzcGxheSBsYW5ndWFnZSBzZXQ/PGJyPg0KPGRp dj48YnI+DQo8L2Rpdj4NCjxkaXY+Jm5ic3A7LS0gSnVzdGluPC9kaXY+DQo8ZGl2Pjxicj4NCjwv ZGl2Pg0KPGRpdj5bMV0mbmJzcDs8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLWFwcHNhd2ctd2ViZmluZ2VyLTExIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1hcHBzYXdnLXdlYmZpbmdlci0xMTwvYT48L2Rp dj4NCjxkaXY+PGJyPg0KPGRpdj4NCjxkaXY+T24gTWFyIDExLCAyMDEzLCBhdCA1OjU0IFBNLCBK b2huIEJyYWRsZXkgJmx0OzxhIGhyZWY9Im1haWx0bzp2ZTdqdGJAdmU3anRiLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPnZlN2p0YkB2ZTdqdGIuY29tPC9hPiZndDs8L2Rpdj4NCjxkaXY+Jm5ic3A7d3Jv dGU6PC9kaXY+DQo8ZGl2Pg0KPGRpdj48YnI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxk aXYgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj5UaGF0IGlzIHdoYXQgSSB3YXMgdGhpbmtp bmcuICZuYnNwOyBJdCB3b3VsZCBiZSB1cCB0byB0aGUgQVMgdG8gZGV0ZXJtaW5lIHdoYXQgbGFu Z3VhZ2UgYW5kIHNjcmlwdCB0byBwcmVzZW50IGJhc2VkIG9uIHRoZSB1c2VyIHByZWZlcmVuY2Uu DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5XaGlsZSBhIGxhcmdlIG51bWJlciBvZiBjbGllbnRz IHdpbGwgYmUgbmF0aXZlIGFuZCBtaWdodCBiZSBhYmxlIHRvIGN1c3RvbWl6ZSB0aGVtc2VsdmVz IGZvciBhIHNpbmdsZSB1c2VyIGR1cmluZyByZWdpc3RyYXRpb24gLCB3ZSBkb24mIzM5O3Qgd2Fu dCB0byBmb3JnZXQgdGhlIHdlYiBzZXJ2ZXIgY2xpZW50cyB0aGF0IGFyZSBtdWx0aSB1c2VyLjwv ZGl2Pg0KPGRpdj48YnI+DQo8ZGl2Pg0KPGRpdj5PbiAyMDEzLTAzLTExLCBhdCAxMDo0OSBQTSwg QnJpYW4gQ2FtcGJlbGwgJmx0OzxhIGhyZWY9Im1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5 LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPC9hPiZndDsg d3JvdGU6PC9kaXY+DQo8YnI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXYgZGlyPSJs dHIiPkZXSVcsIHRoZSBjbG9zZWx5IHJlbGF0ZWQgT3BlbklEIENvbm5lY3QgY2xpZW50IHJlZ2lz dHJhdGlvbiBkcmFmdCBkb2VzIGhhdmUgc29tZSBzdXBwb3J0IGZvciBkb2luZyB0aGlzLCB3aGlj aCBjb3VsZCBtYXliZSBiZSBib3Jyb3dlZC4gU2VlIGNsaWVudF9uYW1lIGluIBskQiF4GyhCMiBh dA0KPGEgaHJlZj0iaHR0cDovL29wZW5pZC5uZXQvc3BlY3Mvb3BlbmlkLWNvbm5lY3QtcmVnaXN0 cmF0aW9uLTFfMC0xNS5odG1sI2NsaWVudC1tZXRhZGF0YSIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0 cDovL29wZW5pZC5uZXQvc3BlY3Mvb3BlbmlkLWNvbm5lY3QtcmVnaXN0cmF0aW9uLTFfMC0xNS5o dG1sI2NsaWVudC1tZXRhZGF0YTwvYT4gYW5kIHRoZSBleGFtcGxlcy48YnI+DQombmJzcDs8YnI+ DQo8cHJlPiAgICZxdW90O2NsaWVudF9uYW1lJnF1b3Q7OiAmcXVvdDtNeSBFeGFtcGxlJnF1b3Q7 LA0KICAgJnF1b3Q7Y2xpZW50X25hbWUjamEtSnBhbi1KUCZxdW90OzomcXVvdDsbJEIlLyVpJSQl IiVzJUhMPhsoQiZxdW90Oyw8L3ByZT4NCjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxf ZXh0cmEiPjxicj4NCjxicj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBNb24sIE1hciAx MSwgMjAxMyBhdCA1OjE1IFBNLCBSaWNoZXIsIEp1c3RpbiBQLiA8c3BhbiBkaXI9Imx0ciI+DQom bHQ7PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0cmUub3JnIiB0YXJnZXQ9Il9ibGFuayI+anJp Y2hlckBtaXRyZS5vcmc8L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJyPg0KPGJsb2NrcXVvdGUgY2xh c3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4 ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQpJdCB3YXMgYnJvdWdodCB1cCBhdCB0aGUg aW4tcGVyc29uIG1lZXRpbmcgdG9kYXkgdGhhdCB3ZSYjMzk7bGwgd2FudCB0byBjb25zaWRlciBp c3N1ZXMgYXJvdW5kIGludGVybmF0aW9uYWxpemF0aW9uIGFuZCBsb2NhbGl6YXRpb24gb2YgaHVt YW4tcmVhZGFibGUgZmllbGRzIGxpa2UgY2xpZW50X25hbWUgaW4gdGhlIGNsaWVudCByZWdpc3Ry YXRpb24uIFdoaWNoIGlzIHRvIHNheTogaWYgYSBjbGllbnQgc3VwcG9ydHMgdGVuIGxhbmd1YWdl cyBhbmQgd2FudHMNCiB0byBwcmVzZW50IGl0c2VsZiBpbiB0ZW4gbGFuZ3VhZ2VzLCBzaG91bGQg aXQgaGF2ZSB0byByZWdpc3RlciBpdHNlbGYgdGVuIHRpbWVzIHdpdGggYW4gQVM/PGJyPg0KPGJy Pg0KQXQgdGhlIG1vbWVudCwgSSYjMzk7bSBvZiB0aGUgb3BpbmlvbiBhIGNsaWVudCB3aXRoIHRl biBsYW5ndWFnZXMgY291bGQgcmVnaXN0ZXIgaXRzZWxmIHRlbiB0aW1lcywgb3IgZG8gc29tZXRo aW5nIHdpdGggdGhlIGNvbnRleHQgaW4gd2hpY2ggaXQgcnVucyB0byBkZXRlcm1pbmUgd2hpY2gg aHVtYW4tZmFjaW5nIGxhbmd1YWdlIHRvIHVzZS4gS2VlcCBpbiBtaW5kIHRoYXQgaW4gc29tZSBj YXNlcyAoc3VjaCBhcyBuYXRpdmUgY2xpZW50cyksIHlvdSYjMzk7bGwNCiBiZSBkeW5hbWljYWxs eSByZWdpc3RlcmluZyBhIGNsaWVudCBmb3IgZWFjaCB1c2VyLCBpbiBlZmZlY3QuIEluIG90aGVy IHdvcmRzLCBJIHBlcnNvbmFsbHkgdGhpbmsgdGhhdCB0aGlzIGlzIGEgcmF0aG9sZSB0aGF0IHdp bGwgY2F1c2UgbW9yZSBoYXJtIHRoYW4gZ29vZC48YnI+DQo8YnI+DQombmJzcDstLSBKdXN0aW48 YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N Ck9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxicj4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPGJyPg0KPC9kaXY+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9 Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9h Pjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1 dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L29hdXRoPC9hPjxicj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxicj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyPg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj48L2Rpdj48L2Rpdj4NCjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCg0KPGJyPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYu b3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48YnI+DQo8YnI+PC9ibG9ja3F1b3RlPjwv ZGl2Pjxicj48YnIgY2xlYXI9ImFsbCI+PGRpdj48YnI+PC9kaXY+LS0gPGJyPk5hdCBTYWtpbXVy YSAoPW5hdCk8ZGl2PkNoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbjxicj48YSBocmVmPSJodHRw Oi8vbmF0LnNha2ltdXJhLm9yZy8iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vbmF0LnNha2ltdXJh Lm9yZy88L2E+PGJyPkBfbmF0X2VuPC9kaXY+DQo8L2Rpdj4NCg== --f46d0408d3f7af97e104d7ae070d-- From Michael.Jones@microsoft.com Mon Mar 11 16:50: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 E06DD11E8140 for ; Mon, 11 Mar 2013 16:50:35 -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 UcZQOYmLErLo for ; Mon, 11 Mar 2013 16:50:34 -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 17A3511E813F for ; Mon, 11 Mar 2013 16:50:33 -0700 (PDT) Received: from BY2FFO11FD021.protection.gbl (10.1.15.201) by BY2FFO11HUB024.protection.gbl (10.1.14.138) with Microsoft SMTP Server (TLS) id 15.0.620.12; Mon, 11 Mar 2013 23:50:25 +0000 Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD021.mail.protection.outlook.com (10.1.15.210) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Mon, 11 Mar 2013 23:50:24 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.132]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.02.0318.003; Mon, 11 Mar 2013 23:49:48 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: OAuth Feature Matrix Thread-Index: Ac4eqQVABmcfQE/KQwy7KfSVJ7BEnAACfp7Q Date: Mon, 11 Mar 2013 23:49:47 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943674F7A8D@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.33] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943674F7A8DTK5EX14MBXC283r_" 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)(189002)(199002)(53824001)(47736001)(54316002)(76482001)(47446002)(50986001)(55846006)(47976001)(5343665001)(16236675001)(54356001)(53806001)(20776003)(16406001)(56776001)(5343635001)(15395725002)(80022001)(77982001)(74662001)(79102001)(59766001)(512954001)(63696002)(66066001)(65816001)(31966008)(5343655001)(15202345001)(4396001)(33656001)(74502001)(69226001)(49866001)(56816002)(51856001)(46102001)(44976002)(6606295001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB024; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0782EC617F Subject: Re: [OAUTH-WG] OAuth Feature Matrix X-BeenThere: oauth@ietf.org X-Mailman-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, 11 Mar 2013 23:50:36 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943674F7A8DTK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please respond to this Doodle Poll http://doodle.com/fvrkmr8qtiktc3um to in= dicate which times you'd prefer to meet tomorrow (Tuesday) afternoon. -- Mike From: Mike Jones Sent: Monday, March 11, 2013 3:38 PM To: oauth@ietf.org Subject: OAuth Feature Matrix The OAuth Feature Matrix spreadsheet that I talked about at the OAuth WG me= eting today is attached and available at http://self-issued.info/misc/OAuth= %20Feature%20Matrix.xlsx. Tony Nadalin and I created it as a tool to chara= cterize OAuth implementations to help promote interoperability by understan= ding the choices that different implementers have made. Also as discussed today, I propose that people with implementations get tog= ether tomorrow (Tuesday) afternoon to take a quick pass at characterizing t= he choices made in your implementations to date. Then we can report back t= o the working group on Thursday with a snapshot of the choices made, which = will help us get a sense of which features are likely to be interoperable a= cross implementations. (Actually, all those who are interested are welcome= , not just those with implementations.) I'll create a Doodle poll now to help us choose a time window between 1:00 = and 5:00 to get together and do this. Also, stay tuned for the room where = we'll meet. Hopefully this will be a useful and informative exercise... -- Mike --_000_4E1F6AAD24975D4BA5B1680429673943674F7A8DTK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Please respond to this= Doodle Poll http://doodle.com/fvrkmr8qti= ktc3um to indicate which times you’d prefer to meet tomorrow (Tue= sday) afternoon.

 

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

 

From: Mike Jon= es
Sent: Monday, March 11, 2013 3:38 PM
To: oauth@ietf.org
Subject: OAuth Feature Matrix

 

The OAuth Feature Matrix spreadsheet that I talked a= bout at the OAuth WG meeting today is attached and available at http= ://self-issued.info/misc/OAuth%20Feature%20Matrix.xlsx.  Tony Nada= lin and I created it as a tool to characterize OAuth implementations to hel= p promote interoperability by understanding the choices that different implementers have made.

 

Also as discussed today, I propose that people with = implementations get together tomorrow (Tuesday) afternoon to take a quick p= ass at characterizing the choices made in your implementations to date.&nbs= p; Then we can report back to the working group on Thursday with a snapshot of the choices made, which will help us = get a sense of which features are likely to be interoperable across impleme= ntations.  (Actually, all those who are interested are welcome, not ju= st those with implementations.)

 

I’ll create a Doodle poll now to help us choos= e a time window between 1:00 and 5:00 to get together and do this.  Al= so, stay tuned for the room where we’ll meet.

 

Hopefully this will be a useful and informative exer= cise…

 

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

 

--_000_4E1F6AAD24975D4BA5B1680429673943674F7A8DTK5EX14MBXC283r_-- From lainhart@us.ibm.com Tue Mar 12 06:33: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 83EF121F8B2B for ; Tue, 12 Mar 2013 06:33:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mUlfbPWI4JCq for ; Tue, 12 Mar 2013 06:33:30 -0700 (PDT) Received: from e39.co.us.ibm.com (e39.co.us.ibm.com [32.97.110.160]) by ietfa.amsl.com (Postfix) with ESMTP id 5789921F8B61 for ; Tue, 12 Mar 2013 06:33:29 -0700 (PDT) Received: from /spool/local by e39.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 12 Mar 2013 07:33:27 -0600 Received: from d01dlp02.pok.ibm.com (9.56.250.167) by e39.co.us.ibm.com (192.168.1.139) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 12 Mar 2013 07:33:22 -0600 Received: from d01relay05.pok.ibm.com (d01relay05.pok.ibm.com [9.56.227.237]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id CC6A46E8020; Tue, 12 Mar 2013 09:33:19 -0400 (EDT) Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r2CDXLE4338572; Tue, 12 Mar 2013 09:33:21 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r2CDXLr1027586; Tue, 12 Mar 2013 09:33:21 -0400 Received: from d01ml255.pok.ibm.com (d01ml255.pok.ibm.com [9.63.10.54]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id r2CDXLQa027572; Tue, 12 Mar 2013 09:33:21 -0400 In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943674F7728@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B1680429673943674F7728@TK5EX14MBXC283.redmond.corp.microsoft.com> To: Mike Jones MIME-Version: 1.0 X-KeepSent: 16B20C89:52BD5BF9-85257B2C:004A6830; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3FP2 SHF22 July 19, 2012 Message-ID: From: Todd W Lainhart Date: Tue, 12 Mar 2013 09:33:19 -0400 X-MIMETrack: Serialize by Router on D01ML255/01/M/IBM(Release 8.5.3FP2 ZX853FP2HF5|February, 2013) at 03/12/2013 09:33:20, Serialize complete at 03/12/2013 09:33:20 Content-Type: multipart/alternative; boundary="=_alternative 004A765485257B2C_=" X-TM-AS-MML: No X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13031213-3620-0000-0000-00000197C78D Cc: "oauth@ietf.org" , oauth-bounces@ietf.org Subject: Re: [OAUTH-WG] OAuth Feature Matrix X-BeenThere: oauth@ietf.org X-Mailman-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, 12 Mar 2013 13:33:31 -0000 This is a multipart message in MIME format. --=_alternative 004A765485257B2C_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 QXJlIHlvdSBpbnRlcmVzdGVkIGluIHN1cnZleSByZXN1bHRzIGZyb20gbm9uLW1lZXRpbmcgbWVt YmVycz8gIElmIHNvLCANCndoZXJlL2hvdyBkbyB5b3Ugd2FudCB0aGF0IHBvc3RlZD8NCg0KDQoN Cg0KDQpUb2RkIExhaW5oYXJ0DQpSYXRpb25hbCBzb2Z0d2FyZQ0KSUJNIENvcnBvcmF0aW9uDQo1 NTAgS2luZyBTdHJlZXQsIExpdHRsZXRvbiwgTUEgMDE0NjAtMTI1MA0KMS05NzgtODk5LTQ3MDUN CjItMjc2LTQ3MDUgKFQvTCkNCmxhaW5oYXJ0QHVzLmlibS5jb20NCg0KDQoNCg0KRnJvbTogICBN aWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+DQpUbzogICAgICJvYXV0aEBp ZXRmLm9yZyIgPG9hdXRoQGlldGYub3JnPiwgDQpEYXRlOiAgIDAzLzExLzIwMTMgMDY6MzkgUE0N ClN1YmplY3Q6ICAgICAgICBbT0FVVEgtV0ddIE9BdXRoIEZlYXR1cmUgTWF0cml4DQpTZW50IGJ5 OiAgICAgICAgb2F1dGgtYm91bmNlc0BpZXRmLm9yZw0KDQoNCg0KVGhlIE9BdXRoIEZlYXR1cmUg TWF0cml4IHNwcmVhZHNoZWV0IHRoYXQgSSB0YWxrZWQgYWJvdXQgYXQgdGhlIE9BdXRoIFdHIA0K bWVldGluZyB0b2RheSBpcyBhdHRhY2hlZCBhbmQgYXZhaWxhYmxlIGF0IA0KaHR0cDovL3NlbGYt aXNzdWVkLmluZm8vbWlzYy9PQXV0aCUyMEZlYXR1cmUlMjBNYXRyaXgueGxzeC4gIFRvbnkgTmFk YWxpbiANCmFuZCBJIGNyZWF0ZWQgaXQgYXMgYSB0b29sIHRvIGNoYXJhY3Rlcml6ZSBPQXV0aCBp bXBsZW1lbnRhdGlvbnMgdG8gaGVscCANCnByb21vdGUgaW50ZXJvcGVyYWJpbGl0eSBieSB1bmRl cnN0YW5kaW5nIHRoZSBjaG9pY2VzIHRoYXQgZGlmZmVyZW50IA0KaW1wbGVtZW50ZXJzIGhhdmUg bWFkZS4NCiANCkFsc28gYXMgZGlzY3Vzc2VkIHRvZGF5LCBJIHByb3Bvc2UgdGhhdCBwZW9wbGUg d2l0aCBpbXBsZW1lbnRhdGlvbnMgZ2V0IA0KdG9nZXRoZXIgdG9tb3Jyb3cgKFR1ZXNkYXkpIGFm dGVybm9vbiB0byB0YWtlIGEgcXVpY2sgcGFzcyBhdCANCmNoYXJhY3Rlcml6aW5nIHRoZSBjaG9p Y2VzIG1hZGUgaW4geW91ciBpbXBsZW1lbnRhdGlvbnMgdG8gZGF0ZS4gIFRoZW4gd2UgDQpjYW4g cmVwb3J0IGJhY2sgdG8gdGhlIHdvcmtpbmcgZ3JvdXAgb24gVGh1cnNkYXkgd2l0aCBhIHNuYXBz aG90IG9mIHRoZSANCmNob2ljZXMgbWFkZSwgd2hpY2ggd2lsbCBoZWxwIHVzIGdldCBhIHNlbnNl IG9mIHdoaWNoIGZlYXR1cmVzIGFyZSBsaWtlbHkgDQp0byBiZSBpbnRlcm9wZXJhYmxlIGFjcm9z cyBpbXBsZW1lbnRhdGlvbnMuICAoQWN0dWFsbHksIGFsbCB0aG9zZSB3aG8gYXJlIA0KaW50ZXJl c3RlZCBhcmUgd2VsY29tZSwgbm90IGp1c3QgdGhvc2Ugd2l0aCBpbXBsZW1lbnRhdGlvbnMuKQ0K IA0KSeKAmWxsIGNyZWF0ZSBhIERvb2RsZSBwb2xsIG5vdyB0byBoZWxwIHVzIGNob29zZSBhIHRp bWUgd2luZG93IGJldHdlZW4gMTowMCANCmFuZCA1OjAwIHRvIGdldCB0b2dldGhlciBhbmQgZG8g dGhpcy4gIEFsc28sIHN0YXkgdHVuZWQgZm9yIHRoZSByb29tIHdoZXJlIA0Kd2XigJlsbCBtZWV0 Lg0KIA0KSG9wZWZ1bGx5IHRoaXMgd2lsbCBiZSBhIHVzZWZ1bCBhbmQgaW5mb3JtYXRpdmUgZXhl cmNpc2XigKYNCiANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIC0tIE1pa2UNCiBbYXR0YWNobWVudCAiT0F1dGggRmVhdHVyZSBNYXRy aXgueGxzeCIgZGVsZXRlZCBieSBUb2RkIFcgDQpMYWluaGFydC9MZXhpbmd0b24vSUJNXSBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGlu ZyBsaXN0DQpPQXV0aEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9vYXV0aA0KDQoNCg== --=_alternative 004A765485257B2C_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkFyZSB5b3UgaW50ZXJlc3RlZCBpbiBzdXJ2 ZXkgcmVzdWx0cyBmcm9tDQpub24tbWVldGluZyBtZW1iZXJzPyAmbmJzcDtJZiBzbywgd2hlcmUv aG93IGRvIHlvdSB3YW50IHRoYXQgcG9zdGVkPzxicj4NCjwvZm9udD4NCjxicj4NCjx0YWJsZSB3 aWR0aD0yMjMgc3R5bGU9ImJvcmRlci1jb2xsYXBzZTpjb2xsYXBzZTsiPg0KPHRyIGhlaWdodD04 Pg0KPHRkIHdpZHRoPTIyMyBiZ2NvbG9yPXdoaXRlIHN0eWxlPSJib3JkZXItc3R5bGU6c29saWQ7 Ym9yZGVyLWNvbG9yOiMwMDAwMDA7Ym9yZGVyLXdpZHRoOjBweCAwcHggMHB4IDBweDtwYWRkaW5n OjBweCAwcHg7Ij48Zm9udCBzaXplPTEgZmFjZT0iVmVyZGFuYSI+PGI+PGJyPg0KPGJyPg0KPGJy Pg0KVG9kZCBMYWluaGFydDxicj4NClJhdGlvbmFsIHNvZnR3YXJlPGJyPg0KSUJNIENvcnBvcmF0 aW9uPGJyPg0KNTUwIEtpbmcgU3RyZWV0LCBMaXR0bGV0b24sIE1BIDAxNDYwLTEyNTA8L2I+PC9m b250Pjxmb250IHNpemU9MSBmYWNlPSJBcmlhbCI+PGI+PGJyPg0KMS05NzgtODk5LTQ3MDU8YnI+ DQoyLTI3Ni00NzA1IChUL0wpPGJyPg0KbGFpbmhhcnRAdXMuaWJtLmNvbTwvYj48L2ZvbnQ+PC90 YWJsZT4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTEgY29sb3I9IzVm NWY1ZiBmYWNlPSJzYW5zLXNlcmlmIj5Gcm9tOiAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7 PC9mb250Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5NaWtlIEpvbmVzICZsdDtNaWNo YWVsLkpvbmVzQG1pY3Jvc29mdC5jb20mZ3Q7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBjb2xv cj0jNWY1ZjVmIGZhY2U9InNhbnMtc2VyaWYiPlRvOiAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5i c3A7PC9mb250Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDtvYXV0aEBpZXRm Lm9yZyZxdW90Ow0KJmx0O29hdXRoQGlldGYub3JnJmd0OywgPC9mb250Pg0KPGJyPjxmb250IHNp emU9MSBjb2xvcj0jNWY1ZjVmIGZhY2U9InNhbnMtc2VyaWYiPkRhdGU6ICZuYnNwOyAmbmJzcDsg Jm5ic3A7DQombmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjAzLzEx LzIwMTMgMDY6MzkgUE08L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGNvbG9yPSM1ZjVmNWYgZmFj ZT0ic2Fucy1zZXJpZiI+U3ViamVjdDogJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOzwvZm9u dD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+W09BVVRILVdHXSBPQXV0aA0KRmVhdHVy ZSBNYXRyaXg8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGNvbG9yPSM1ZjVmNWYgZmFjZT0ic2Fu cy1zZXJpZiI+U2VudCBieTogJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOzwvZm9udD48Zm9u dCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvZm9udD4N Cjxicj4NCjxociBub3NoYWRlPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJD YWxpYnJpIj5UaGUgT0F1dGggRmVhdHVyZSBNYXRyaXggc3ByZWFkc2hlZXQgdGhhdA0KSSB0YWxr ZWQgYWJvdXQgYXQgdGhlIE9BdXRoIFdHIG1lZXRpbmcgdG9kYXkgaXMgYXR0YWNoZWQgYW5kIGF2 YWlsYWJsZQ0KYXQgPC9mb250PjxhIGhyZWY9Imh0dHA6Ly9zZWxmLWlzc3VlZC5pbmZvL21pc2Mv T0F1dGglMjBGZWF0dXJlJTIwTWF0cml4Lnhsc3giPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZh Y2U9IkNhbGlicmkiPjx1Pmh0dHA6Ly9zZWxmLWlzc3VlZC5pbmZvL21pc2MvT0F1dGglMjBGZWF0 dXJlJTIwTWF0cml4Lnhsc3g8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJy aSI+Lg0KJm5ic3A7VG9ueSBOYWRhbGluIGFuZCBJIGNyZWF0ZWQgaXQgYXMgYSB0b29sIHRvIGNo YXJhY3Rlcml6ZSBPQXV0aCBpbXBsZW1lbnRhdGlvbnMNCnRvIGhlbHAgcHJvbW90ZSBpbnRlcm9w ZXJhYmlsaXR5IGJ5IHVuZGVyc3RhbmRpbmcgdGhlIGNob2ljZXMgdGhhdCBkaWZmZXJlbnQNCmlt cGxlbWVudGVycyBoYXZlIG1hZGUuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxp YnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPkFsc28g YXMgZGlzY3Vzc2VkIHRvZGF5LCBJIHByb3Bvc2UgdGhhdA0KcGVvcGxlIHdpdGggaW1wbGVtZW50 YXRpb25zIGdldCB0b2dldGhlciB0b21vcnJvdyAoVHVlc2RheSkgYWZ0ZXJub29uIHRvDQp0YWtl IGEgcXVpY2sgcGFzcyBhdCBjaGFyYWN0ZXJpemluZyB0aGUgY2hvaWNlcyBtYWRlIGluIHlvdXIg aW1wbGVtZW50YXRpb25zDQp0byBkYXRlLiAmbmJzcDtUaGVuIHdlIGNhbiByZXBvcnQgYmFjayB0 byB0aGUgd29ya2luZyBncm91cCBvbiBUaHVyc2RheQ0Kd2l0aCBhIHNuYXBzaG90IG9mIHRoZSBj aG9pY2VzIG1hZGUsIHdoaWNoIHdpbGwgaGVscCB1cyBnZXQgYSBzZW5zZSBvZg0Kd2hpY2ggZmVh dHVyZXMgYXJlIGxpa2VseSB0byBiZSBpbnRlcm9wZXJhYmxlIGFjcm9zcyBpbXBsZW1lbnRhdGlv bnMuICZuYnNwOyhBY3R1YWxseSwNCmFsbCB0aG9zZSB3aG8gYXJlIGludGVyZXN0ZWQgYXJlIHdl bGNvbWUsIG5vdCBqdXN0IHRob3NlIHdpdGggaW1wbGVtZW50YXRpb25zLik8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0iQ2FsaWJyaSI+SeKAmWxsIGNyZWF0ZSBhIERvb2RsZSBwb2xsIG5vdyB0byBoZWxw DQp1cyBjaG9vc2UgYSB0aW1lIHdpbmRvdyBiZXR3ZWVuIDE6MDAgYW5kIDU6MDAgdG8gZ2V0IHRv Z2V0aGVyIGFuZCBkbyB0aGlzLg0KJm5ic3A7QWxzbywgc3RheSB0dW5lZCBmb3IgdGhlIHJvb20g d2hlcmUgd2XigJlsbCBtZWV0LjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJy aSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5Ib3BlZnVs bHkgdGhpcyB3aWxsIGJlIGEgdXNlZnVsIGFuZCBpbmZvcm1hdGl2ZQ0KZXhlcmNpc2XigKY8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZu YnNwOyAmbmJzcDsgLS0gTWlrZTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJy aSI+Jm5ic3A7W2F0dGFjaG1lbnQgJnF1b3Q7T0F1dGggRmVhdHVyZSBNYXRyaXgueGxzeCZxdW90 Ow0KZGVsZXRlZCBieSBUb2RkIFcgTGFpbmhhcnQvTGV4aW5ndG9uL0lCTV0gPC9mb250Pjx0dD48 Zm9udCBzaXplPTI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQpPQXV0aEBpZXRmLm9yZzxicj4NCjwvZm9u dD48L3R0PjxhIGhyZWY9aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0 aD48dHQ+PGZvbnQgc2l6ZT0yPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v b2F1dGg8L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNpemU9Mj48YnI+DQo8L2ZvbnQ+PC90dD4N Cjxicj4NCg== --=_alternative 004A765485257B2C_=-- From Michael.Jones@microsoft.com Tue Mar 12 06:46: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 C7BA221F8BD9; Tue, 12 Mar 2013 06:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.098 X-Spam-Level: X-Spam-Status: No, score=-3.098 tagged_above=-999 required=5 tests=[AWL=-0.500, 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 KBabjT2VYvqn; Tue, 12 Mar 2013 06:46:46 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0208.outbound.protection.outlook.com [207.46.163.208]) by ietfa.amsl.com (Postfix) with ESMTP id 84D3721F8BD7; Tue, 12 Mar 2013 06:46:46 -0700 (PDT) Received: from BL2FFO11FD017.protection.gbl (10.173.161.200) by BL2FFO11HUB019.protection.gbl (10.173.160.111) with Microsoft SMTP Server (TLS) id 15.0.620.12; Tue, 12 Mar 2013 13:46:44 +0000 Received: from TK5EX14MLTC102.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.620.12 via Frontend Transport; Tue, 12 Mar 2013 13:46:44 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.132]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0318.003; Tue, 12 Mar 2013 13:46:06 +0000 From: Mike Jones To: Todd W Lainhart Thread-Topic: [OAUTH-WG] OAuth Feature Matrix Thread-Index: Ac4fJ/G1BmcfQE/KQwy7KfSVJ7BEnA== Date: Tue, 12 Mar 2013 13:46:06 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943674FA494@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943674FA494TK5EX14MBXC283r_" 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)(479174001)(377454001)(53824001)(16406001)(512874001)(16236675001)(55846006)(69226001)(56776001)(20776003)(54356001)(59766001)(50986001)(4396001)(5343635001)(49866001)(76482001)(54316002)(80022001)(46102001)(33656001)(15202345001)(56816002)(5343655001)(63696002)(44976002)(74662001)(31966008)(47446002)(53806001)(65816001)(77982001)(79102001)(51856001)(5343665001)(47736001)(74502001)(47976001)(6606295001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB019; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 078310077C Cc: "oauth@ietf.org" , "oauth-bounces@ietf.org" Subject: Re: [OAUTH-WG] OAuth Feature Matrix X-BeenThere: oauth@ietf.org X-Mailman-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, 12 Mar 2013 13:46:47 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943674FA494TK5EX14MBXC283r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWJzb2x1dGVseSEgIEluIGZhY3QsIENodWNrIE1vcnRpbW9yZSBhbHJlYWR5IHNlbnQgbWUgcmVz dWx0cyBmb3IgU2FsZXNmb3JjZSBhbmQgSnVzdGluIFJpY2hlciBhbHJlYWR5IGdhdmUgbWUgcmVz dWx0cyBmb3IgTWl0cmUsIGV2ZW4gdGhvdWdoIGJvdGggd29u4oCZdCBiZSBhYmxlIHRvIGJlIHRo ZXJlIG9uIFRodXJzZGF5LiAgSWYgeW91IHNlbmQgbWUgeW91ciByZXN1bHRzIEnigJlsbCBhZ2dy ZWdhdGUgdGhlbSBpbnRvIHRoZSBwcmVzZW50YXRpb24uDQoNCkJlc3Qgd2lzaGVzLA0KLS0gTWlr ZQ0KDQpGcm9tOiBUb2RkIFcgTGFpbmhhcnQNClNlbnQ6IOKAjk1hcmNo4oCOIOKAjjEy4oCOLCDi gI4yMDEzIOKAjjbigI464oCOMzPigI4g4oCOQU0NClRvOiBNaWtlIEpvbmVzDQpDQzogb2F1dGhA aWV0Zi5vcmcsIG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0dd IE9BdXRoIEZlYXR1cmUgTWF0cml4DQoNCkFyZSB5b3UgaW50ZXJlc3RlZCBpbiBzdXJ2ZXkgcmVz dWx0cyBmcm9tIG5vbi1tZWV0aW5nIG1lbWJlcnM/ICBJZiBzbywgd2hlcmUvaG93IGRvIHlvdSB3 YW50IHRoYXQgcG9zdGVkPw0KDQoNCg0KDQpUb2RkIExhaW5oYXJ0DQpSYXRpb25hbCBzb2Z0d2Fy ZQ0KSUJNIENvcnBvcmF0aW9uDQo1NTAgS2luZyBTdHJlZXQsIExpdHRsZXRvbiwgTUEgMDE0NjAt MTI1MA0KMS05NzgtODk5LTQ3MDUNCjItMjc2LTQ3MDUgKFQvTCkNCmxhaW5oYXJ0QHVzLmlibS5j b20NCg0KDQoNCg0KDQpGcm9tOiAgICAgICAgTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNy b3NvZnQuY29tPg0KVG86ICAgICAgICAib2F1dGhAaWV0Zi5vcmciIDxvYXV0aEBpZXRmLm9yZz4s DQpEYXRlOiAgICAgICAgMDMvMTEvMjAxMyAwNjozOSBQTQ0KU3ViamVjdDogICAgICAgIFtPQVVU SC1XR10gT0F1dGggRmVhdHVyZSBNYXRyaXgNClNlbnQgYnk6ICAgICAgICBvYXV0aC1ib3VuY2Vz QGlldGYub3JnDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQoNCg0KVGhlIE9B dXRoIEZlYXR1cmUgTWF0cml4IHNwcmVhZHNoZWV0IHRoYXQgSSB0YWxrZWQgYWJvdXQgYXQgdGhl IE9BdXRoIFdHIG1lZXRpbmcgdG9kYXkgaXMgYXR0YWNoZWQgYW5kIGF2YWlsYWJsZSBhdCBodHRw Oi8vc2VsZi1pc3N1ZWQuaW5mby9taXNjL09BdXRoJTIwRmVhdHVyZSUyME1hdHJpeC54bHN4LiAg VG9ueSBOYWRhbGluIGFuZCBJIGNyZWF0ZWQgaXQgYXMgYSB0b29sIHRvIGNoYXJhY3Rlcml6ZSBP QXV0aCBpbXBsZW1lbnRhdGlvbnMgdG8gaGVscCBwcm9tb3RlIGludGVyb3BlcmFiaWxpdHkgYnkg dW5kZXJzdGFuZGluZyB0aGUgY2hvaWNlcyB0aGF0IGRpZmZlcmVudCBpbXBsZW1lbnRlcnMgaGF2 ZSBtYWRlLg0KDQpBbHNvIGFzIGRpc2N1c3NlZCB0b2RheSwgSSBwcm9wb3NlIHRoYXQgcGVvcGxl IHdpdGggaW1wbGVtZW50YXRpb25zIGdldCB0b2dldGhlciB0b21vcnJvdyAoVHVlc2RheSkgYWZ0 ZXJub29uIHRvIHRha2UgYSBxdWljayBwYXNzIGF0IGNoYXJhY3Rlcml6aW5nIHRoZSBjaG9pY2Vz IG1hZGUgaW4geW91ciBpbXBsZW1lbnRhdGlvbnMgdG8gZGF0ZS4gIFRoZW4gd2UgY2FuIHJlcG9y dCBiYWNrIHRvIHRoZSB3b3JraW5nIGdyb3VwIG9uIFRodXJzZGF5IHdpdGggYSBzbmFwc2hvdCBv ZiB0aGUgY2hvaWNlcyBtYWRlLCB3aGljaCB3aWxsIGhlbHAgdXMgZ2V0IGEgc2Vuc2Ugb2Ygd2hp Y2ggZmVhdHVyZXMgYXJlIGxpa2VseSB0byBiZSBpbnRlcm9wZXJhYmxlIGFjcm9zcyBpbXBsZW1l bnRhdGlvbnMuICAoQWN0dWFsbHksIGFsbCB0aG9zZSB3aG8gYXJlIGludGVyZXN0ZWQgYXJlIHdl bGNvbWUsIG5vdCBqdXN0IHRob3NlIHdpdGggaW1wbGVtZW50YXRpb25zLikNCg0KSeKAmWxsIGNy ZWF0ZSBhIERvb2RsZSBwb2xsIG5vdyB0byBoZWxwIHVzIGNob29zZSBhIHRpbWUgd2luZG93IGJl dHdlZW4gMTowMCBhbmQgNTowMCB0byBnZXQgdG9nZXRoZXIgYW5kIGRvIHRoaXMuICBBbHNvLCBz dGF5IHR1bmVkIGZvciB0aGUgcm9vbSB3aGVyZSB3ZeKAmWxsIG1lZXQuDQoNCkhvcGVmdWxseSB0 aGlzIHdpbGwgYmUgYSB1c2VmdWwgYW5kIGluZm9ybWF0aXZlIGV4ZXJjaXNl4oCmDQoNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0t IE1pa2UNCiBbYXR0YWNobWVudCAiT0F1dGggRmVhdHVyZSBNYXRyaXgueGxzeCIgZGVsZXRlZCBi eSBUb2RkIFcgTGFpbmhhcnQvTGV4aW5ndG9uL0lCTV0gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5v cmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0K --_000_4E1F6AAD24975D4BA5B1680429673943674FA494TK5EX14MBXC283r_ Content-Type: text/html; charset="utf-8" Content-ID: <88C37963A9A7E347A6BBEAB4282A3BA5@microsoft.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGRpdiBzdHlsZT0i Zm9udC1mYW1pbHk6Q2FsaWJyaSwmcXVvdDtTZWdvZSBVSSZxdW90OyxNZWlyeW8sJnF1b3Q7TWlj cm9zb2Z0IFlhSGVpIFVJJnF1b3Q7LCZxdW90O01pY3Jvc29mdCBKaGVuZ0hlaSBVSSZxdW90Oywm cXVvdDtNYWxndW4gR290aGljJnF1b3Q7LCZxdW90O0tobWVyIFVJJnF1b3Q7LCZxdW90O05pcm1h bGEgVUkmcXVvdDssVHVuZ2EsJnF1b3Q7TGFvIFVJJnF1b3Q7LEVicmltYSxzYW5zLXNlcmlmO2Zv bnQtc2l6ZToxNnB4OyI+DQo8ZGl2PkFic29sdXRlbHkhJm5ic3A7IEluIGZhY3QsIENodWNrIE1v cnRpbW9yZSBhbHJlYWR5IHNlbnQgbWUgcmVzdWx0cyBmb3IgU2FsZXNmb3JjZSBhbmQgSnVzdGlu IFJpY2hlciBhbHJlYWR5IGdhdmUgbWUgcmVzdWx0cyBmb3IgTWl0cmUsIGV2ZW4gdGhvdWdoIGJv dGggd29u4oCZdCBiZSBhYmxlIHRvIGJlIHRoZXJlIG9uIFRodXJzZGF5LiZuYnNwOyBJZiB5b3Ug c2VuZCBtZSB5b3VyIHJlc3VsdHMgSeKAmWxsIGFnZ3JlZ2F0ZSB0aGVtIGludG8gdGhlIHByZXNl bnRhdGlvbi48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PkJlc3Qgd2lzaGVzLDwvZGl2 Pg0KPGRpdj4tLSBNaWtlPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyLXRvcC1jb2xvcjogcmdiKDIyOSwgMjI5LCAyMjkpOyBib3JkZXItdG9wLXdpZHRoOiAycHg7 IGJvcmRlci10b3Atc3R5bGU6IHNvbGlkOyI+DQo8c3Ryb25nPkZyb206PC9zdHJvbmc+Jm5ic3A7 VG9kZCBXIExhaW5oYXJ0PGJyPg0KPHN0cm9uZz5TZW50Ojwvc3Ryb25nPiZuYnNwO+KAjk1hcmNo 4oCOIOKAjjEy4oCOLCDigI4yMDEzIOKAjjbigI464oCOMzPigI4g4oCOQU08YnI+DQo8c3Ryb25n PlRvOjwvc3Ryb25nPiZuYnNwO01pa2UgSm9uZXM8YnI+DQo8c3Ryb25nPkNDOjwvc3Ryb25nPiZu YnNwO29hdXRoQGlldGYub3JnLCBvYXV0aC1ib3VuY2VzQGlldGYub3JnPGJyPg0KPHN0cm9uZz5T dWJqZWN0Ojwvc3Ryb25nPiZuYnNwO1JlOiBbT0FVVEgtV0ddIE9BdXRoIEZlYXR1cmUgTWF0cml4 PGJyPg0KPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGZvbnQgZmFjZT0ic2Fucy1zZXJpZiIg c2l6ZT0iMiI+QXJlIHlvdSBpbnRlcmVzdGVkIGluIHN1cnZleSByZXN1bHRzIGZyb20gbm9uLW1l ZXRpbmcgbWVtYmVycz8gJm5ic3A7SWYgc28sIHdoZXJlL2hvdyBkbyB5b3Ugd2FudCB0aGF0IHBv c3RlZD88YnI+DQo8L2ZvbnQ+PGJyPg0KPHRhYmxlIHdpZHRoPSIyMjMiIHRhYmluZGV4PSItMSIg c3R5bGU9ImJvcmRlci1jb2xsYXBzZTogY29sbGFwc2U7Ij4NCjx0Ym9keT4NCjx0ciBoZWlnaHQ9 IjgiPg0KPHRkIHdpZHRoPSIyMjMiIHN0eWxlPSJwYWRkaW5nOiAwcHg7IGJvcmRlcjogMHB4IHNv bGlkIHJnYigwLCAwLCAwKTsiIGJnY29sb3I9IndoaXRlIj4NCjxmb250IGZhY2U9IlZlcmRhbmEi IHNpemU9IjEiPjxiPjxicj4NCjxicj4NCjxicj4NClRvZGQgTGFpbmhhcnQ8YnI+DQpSYXRpb25h bCBzb2Z0d2FyZTxicj4NCklCTSBDb3Jwb3JhdGlvbjxicj4NCjU1MCBLaW5nIFN0cmVldCwgTGl0 dGxldG9uLCBNQSAwMTQ2MC0xMjUwPC9iPjwvZm9udD48Zm9udCBmYWNlPSJBcmlhbCIgc2l6ZT0i MSI+PGI+PGJyPg0KMS05NzgtODk5LTQ3MDU8YnI+DQoyLTI3Ni00NzA1IChUL0wpPGJyPg0KbGFp bmhhcnRAdXMuaWJtLmNvbTwvYj48L2ZvbnQ+PC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJs ZT4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxmb250IGNvbG9yPSIjNWY1ZjVmIiBm YWNlPSJzYW5zLXNlcmlmIiBzaXplPSIxIj5Gcm9tOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDs8L2ZvbnQ+PGZvbnQgZmFjZT0ic2Fucy1zZXJpZiIgc2l6ZT0iMSI+TWlrZSBKb25lcyAmbHQ7 TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tJmd0OzwvZm9udD4NCjxicj4NCjxmb250IGNvbG9y PSIjNWY1ZjVmIiBmYWNlPSJzYW5zLXNlcmlmIiBzaXplPSIxIj5UbzogJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7PC9mb250Pjxmb250IGZhY2U9InNhbnMtc2VyaWYiIHNpemU9IjEiPiZxdW90 O29hdXRoQGlldGYub3JnJnF1b3Q7ICZsdDtvYXV0aEBpZXRmLm9yZyZndDssDQo8L2ZvbnQ+PGJy Pg0KPGZvbnQgY29sb3I9IiM1ZjVmNWYiIGZhY2U9InNhbnMtc2VyaWYiIHNpemU9IjEiPkRhdGU6 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzwvZm9udD48Zm9udCBmYWNlPSJzYW5zLXNlcmlm IiBzaXplPSIxIj4wMy8xMS8yMDEzIDA2OjM5IFBNPC9mb250Pg0KPGJyPg0KPGZvbnQgY29sb3I9 IiM1ZjVmNWYiIGZhY2U9InNhbnMtc2VyaWYiIHNpemU9IjEiPlN1YmplY3Q6ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOzwvZm9udD48Zm9udCBmYWNlPSJzYW5zLXNlcmlmIiBzaXplPSIxIj5b T0FVVEgtV0ddIE9BdXRoIEZlYXR1cmUgTWF0cml4PC9mb250Pg0KPGJyPg0KPGZvbnQgY29sb3I9 IiM1ZjVmNWYiIGZhY2U9InNhbnMtc2VyaWYiIHNpemU9IjEiPlNlbnQgYnk6ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOzwvZm9udD48Zm9udCBmYWNlPSJzYW5zLXNlcmlmIiBzaXplPSIxIj5v YXV0aC1ib3VuY2VzQGlldGYub3JnPC9mb250Pg0KPGJyPg0KPGhyIG5vc2hhZGU9IiI+DQo8YnI+ DQo8YnI+DQo8YnI+DQo8Zm9udCBmYWNlPSJDYWxpYnJpIiBzaXplPSIyIj5UaGUgT0F1dGggRmVh dHVyZSBNYXRyaXggc3ByZWFkc2hlZXQgdGhhdCBJIHRhbGtlZCBhYm91dCBhdCB0aGUgT0F1dGgg V0cgbWVldGluZyB0b2RheSBpcyBhdHRhY2hlZCBhbmQgYXZhaWxhYmxlIGF0DQo8L2ZvbnQ+PGEg aHJlZj0iaHR0cDovL3NlbGYtaXNzdWVkLmluZm8vbWlzYy9PQXV0aCUyMEZlYXR1cmUlMjBNYXRy aXgueGxzeCI+PGZvbnQgY29sb3I9ImJsdWUiIGZhY2U9IkNhbGlicmkiIHNpemU9IjIiPjx1Pmh0 dHA6Ly9zZWxmLWlzc3VlZC5pbmZvL21pc2MvT0F1dGglMjBGZWF0dXJlJTIwTWF0cml4Lnhsc3g8 L3U+PC9mb250PjwvYT48Zm9udCBmYWNlPSJDYWxpYnJpIiBzaXplPSIyIj4uICZuYnNwO1Rvbnkg TmFkYWxpbiBhbmQgSSBjcmVhdGVkIGl0DQogYXMgYSB0b29sIHRvIGNoYXJhY3Rlcml6ZSBPQXV0 aCBpbXBsZW1lbnRhdGlvbnMgdG8gaGVscCBwcm9tb3RlIGludGVyb3BlcmFiaWxpdHkgYnkgdW5k ZXJzdGFuZGluZyB0aGUgY2hvaWNlcyB0aGF0IGRpZmZlcmVudCBpbXBsZW1lbnRlcnMgaGF2ZSBt YWRlLjwvZm9udD4NCjxicj4NCjxmb250IGZhY2U9IkNhbGlicmkiIHNpemU9IjIiPiZuYnNwOzwv Zm9udD4gPGJyPg0KPGZvbnQgZmFjZT0iQ2FsaWJyaSIgc2l6ZT0iMiI+QWxzbyBhcyBkaXNjdXNz ZWQgdG9kYXksIEkgcHJvcG9zZSB0aGF0IHBlb3BsZSB3aXRoIGltcGxlbWVudGF0aW9ucyBnZXQg dG9nZXRoZXIgdG9tb3Jyb3cgKFR1ZXNkYXkpIGFmdGVybm9vbiB0byB0YWtlIGEgcXVpY2sgcGFz cyBhdCBjaGFyYWN0ZXJpemluZyB0aGUgY2hvaWNlcyBtYWRlIGluIHlvdXIgaW1wbGVtZW50YXRp b25zIHRvIGRhdGUuICZuYnNwO1RoZW4gd2UgY2FuIHJlcG9ydCBiYWNrIHRvDQogdGhlIHdvcmtp bmcgZ3JvdXAgb24gVGh1cnNkYXkgd2l0aCBhIHNuYXBzaG90IG9mIHRoZSBjaG9pY2VzIG1hZGUs IHdoaWNoIHdpbGwgaGVscCB1cyBnZXQgYSBzZW5zZSBvZiB3aGljaCBmZWF0dXJlcyBhcmUgbGlr ZWx5IHRvIGJlIGludGVyb3BlcmFibGUgYWNyb3NzIGltcGxlbWVudGF0aW9ucy4gJm5ic3A7KEFj dHVhbGx5LCBhbGwgdGhvc2Ugd2hvIGFyZSBpbnRlcmVzdGVkIGFyZSB3ZWxjb21lLCBub3QganVz dCB0aG9zZSB3aXRoIGltcGxlbWVudGF0aW9ucy4pPC9mb250Pg0KPGJyPg0KPGZvbnQgZmFjZT0i Q2FsaWJyaSIgc2l6ZT0iMiI+Jm5ic3A7PC9mb250PiA8YnI+DQo8Zm9udCBmYWNlPSJDYWxpYnJp IiBzaXplPSIyIj5J4oCZbGwgY3JlYXRlIGEgRG9vZGxlIHBvbGwgbm93IHRvIGhlbHAgdXMgY2hv b3NlIGEgdGltZSB3aW5kb3cgYmV0d2VlbiAxOjAwIGFuZCA1OjAwIHRvIGdldCB0b2dldGhlciBh bmQgZG8gdGhpcy4gJm5ic3A7QWxzbywgc3RheSB0dW5lZCBmb3IgdGhlIHJvb20gd2hlcmUgd2Xi gJlsbCBtZWV0LjwvZm9udD4NCjxicj4NCjxmb250IGZhY2U9IkNhbGlicmkiIHNpemU9IjIiPiZu YnNwOzwvZm9udD4gPGJyPg0KPGZvbnQgZmFjZT0iQ2FsaWJyaSIgc2l6ZT0iMiI+SG9wZWZ1bGx5 IHRoaXMgd2lsbCBiZSBhIHVzZWZ1bCBhbmQgaW5mb3JtYXRpdmUgZXhlcmNpc2XigKY8L2ZvbnQ+ DQo8YnI+DQo8Zm9udCBmYWNlPSJDYWxpYnJpIiBzaXplPSIyIj4mbmJzcDs8L2ZvbnQ+IDxicj4N Cjxmb250IGZhY2U9IkNhbGlicmkiIHNpemU9IjIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IC0tIE1pa2U8L2ZvbnQ+DQo8YnI+DQo8Zm9udCBmYWNlPSJDYWxpYnJpIiBz aXplPSIyIj4mbmJzcDtbYXR0YWNobWVudCAmcXVvdDtPQXV0aCBGZWF0dXJlIE1hdHJpeC54bHN4 JnF1b3Q7IGRlbGV0ZWQgYnkgVG9kZCBXIExhaW5oYXJ0L0xleGluZ3Rvbi9JQk1dDQo8L2ZvbnQ+ PHR0Pjxmb250IHNpemU9IjIiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KT0F1dGhAaWV0Zi5vcmc8YnI+ DQo8L2ZvbnQ+PC90dD48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL29hdXRoIj48dHQ+PGZvbnQgc2l6ZT0iMiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9vYXV0aDwvZm9udD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0iMiI+PGJyPg0K PC9mb250PjwvdHQ+PGJyPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_4E1F6AAD24975D4BA5B1680429673943674FA494TK5EX14MBXC283r_-- From Michael.Jones@microsoft.com Tue Mar 12 06:51: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 EAF0221F89E9 for ; Tue, 12 Mar 2013 06:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.931 X-Spam-Level: X-Spam-Status: No, score=-2.931 tagged_above=-999 required=5 tests=[AWL=-0.333, 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 L04AJz4Zl473 for ; Tue, 12 Mar 2013 06:51:38 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0236.outbound.protection.outlook.com [207.46.163.236]) by ietfa.amsl.com (Postfix) with ESMTP id A505221F896D for ; Tue, 12 Mar 2013 06:51:38 -0700 (PDT) Received: from BY2FFO11FD017.protection.gbl (10.1.15.204) by BY2FFO11HUB021.protection.gbl (10.1.14.108) with Microsoft SMTP Server (TLS) id 15.0.620.12; Tue, 12 Mar 2013 13:51:36 +0000 Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD017.mail.protection.outlook.com (10.1.14.105) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Tue, 12 Mar 2013 13:51:36 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.132]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.02.0318.003; Tue, 12 Mar 2013 13:51:15 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: Doodle poll about OAuth Feature Matrix meeting today Thread-Index: Ac4fKKoyLy6UMTSkTm+OLBRXlWlZJw== Date: Tue, 12 Mar 2013 13:51:15 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943674FA96B@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943674FA96BTK5EX14MBXC283r_" 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)(377454001)(199002)(164054002)(53824001)(74662001)(51856001)(76482001)(512874001)(50986001)(55846006)(5343665001)(16236675001)(54356001)(53806001)(47736001)(16406001)(47976001)(47446002)(54316002)(5343635001)(77982001)(80022001)(15395725002)(59766001)(63696002)(65816001)(74502001)(20776003)(56776001)(5343655001)(15202345001)(4396001)(33656001)(31966008)(56816002)(46102001)(49866001)(69226001)(79102001)(44976002)(6606295001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB021; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 078310077C Subject: [OAUTH-WG] Doodle poll about OAuth Feature Matrix meeting today X-BeenThere: oauth@ietf.org X-Mailman-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, 12 Mar 2013 13:51:40 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943674FA96BTK5EX14MBXC283r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SWYgeW914oCZcmUgaW50ZXJlc3RlZCBpbiBtZWV0aW5nIHdpdGggdXMgdG9kYXkgdG8gZ2F0aGVy IGRhdGEgYWJvdXQgd2hhdCBPQXV0aCBmZWF0dXJlcyBhcmUgaW1wbGVtZW50ZWQgYW5kIGNob2lj ZXMgYXJlIG1hZGUgaW4gZGlmZmVyZW50IGltcGxlbWVudGF0aW9ucywgcGxlYXNlIHRha2UgYSBt aW51dGUgdGhpcyBtb3JuaW5nIGFuZCBmaWxsIGluIHRoZSBEb29kbGUgcG9sbCB0byBoZWxwIHVz IGNob29zZSBhIG1lZXRpbmcgdGltZS4NCg0KVGhhbmtzLA0KLS0gTWlrZQ0KDQpGcm9tOiBNaWtl IEpvbmVzDQpTZW50OiDigI5NYXJjaOKAjiDigI4xMeKAjiwg4oCOMjAxMyDigI404oCOOuKAjjUw 4oCOIOKAjlBNDQpUbzogb2F1dGhAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE9B dXRoIEZlYXR1cmUgTWF0cml4DQoNClBsZWFzZSByZXNwb25kIHRvIHRoaXMgRG9vZGxlIFBvbGwg aHR0cDovL2Rvb2RsZS5jb20vZnZya21yOHF0aWt0YzN1bSB0byBpbmRpY2F0ZSB3aGljaCB0aW1l cyB5b3XigJlkIHByZWZlciB0byBtZWV0IHRvbW9ycm93IChUdWVzZGF5KSBhZnRlcm5vb24uDQoN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIC0tIE1pa2UNCg0KRnJvbTogTWlrZSBKb25lcw0KU2VudDogTW9uZGF5LCBNYXJjaCAxMSwg MjAxMyAzOjM4IFBNDQpUbzogb2F1dGhAaWV0Zi5vcmcNClN1YmplY3Q6IE9BdXRoIEZlYXR1cmUg TWF0cml4DQoNClRoZSBPQXV0aCBGZWF0dXJlIE1hdHJpeCBzcHJlYWRzaGVldCB0aGF0IEkgdGFs a2VkIGFib3V0IGF0IHRoZSBPQXV0aCBXRyBtZWV0aW5nIHRvZGF5IGlzIGF0dGFjaGVkIGFuZCBh dmFpbGFibGUgYXQgaHR0cDovL3NlbGYtaXNzdWVkLmluZm8vbWlzYy9PQXV0aCUyMEZlYXR1cmUl MjBNYXRyaXgueGxzeC4gIFRvbnkgTmFkYWxpbiBhbmQgSSBjcmVhdGVkIGl0IGFzIGEgdG9vbCB0 byBjaGFyYWN0ZXJpemUgT0F1dGggaW1wbGVtZW50YXRpb25zIHRvIGhlbHAgcHJvbW90ZSBpbnRl cm9wZXJhYmlsaXR5IGJ5IHVuZGVyc3RhbmRpbmcgdGhlIGNob2ljZXMgdGhhdCBkaWZmZXJlbnQg aW1wbGVtZW50ZXJzIGhhdmUgbWFkZS4NCg0KQWxzbyBhcyBkaXNjdXNzZWQgdG9kYXksIEkgcHJv cG9zZSB0aGF0IHBlb3BsZSB3aXRoIGltcGxlbWVudGF0aW9ucyBnZXQgdG9nZXRoZXIgdG9tb3Jy b3cgKFR1ZXNkYXkpIGFmdGVybm9vbiB0byB0YWtlIGEgcXVpY2sgcGFzcyBhdCBjaGFyYWN0ZXJp emluZyB0aGUgY2hvaWNlcyBtYWRlIGluIHlvdXIgaW1wbGVtZW50YXRpb25zIHRvIGRhdGUuICBU aGVuIHdlIGNhbiByZXBvcnQgYmFjayB0byB0aGUgd29ya2luZyBncm91cCBvbiBUaHVyc2RheSB3 aXRoIGEgc25hcHNob3Qgb2YgdGhlIGNob2ljZXMgbWFkZSwgd2hpY2ggd2lsbCBoZWxwIHVzIGdl dCBhIHNlbnNlIG9mIHdoaWNoIGZlYXR1cmVzIGFyZSBsaWtlbHkgdG8gYmUgaW50ZXJvcGVyYWJs ZSBhY3Jvc3MgaW1wbGVtZW50YXRpb25zLiAgKEFjdHVhbGx5LCBhbGwgdGhvc2Ugd2hvIGFyZSBp bnRlcmVzdGVkIGFyZSB3ZWxjb21lLCBub3QganVzdCB0aG9zZSB3aXRoIGltcGxlbWVudGF0aW9u cy4pDQoNCknigJlsbCBjcmVhdGUgYSBEb29kbGUgcG9sbCBub3cgdG8gaGVscCB1cyBjaG9vc2Ug YSB0aW1lIHdpbmRvdyBiZXR3ZWVuIDE6MDAgYW5kIDU6MDAgdG8gZ2V0IHRvZ2V0aGVyIGFuZCBk byB0aGlzLiAgQWxzbywgc3RheSB0dW5lZCBmb3IgdGhlIHJvb20gd2hlcmUgd2XigJlsbCBtZWV0 Lg0KDQpIb3BlZnVsbHkgdGhpcyB3aWxsIGJlIGEgdXNlZnVsIGFuZCBpbmZvcm1hdGl2ZSBleGVy Y2lzZeKApg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAtLSBNaWtlDQoNCg== --_000_4E1F6AAD24975D4BA5B1680429673943674FA96BTK5EX14MBXC283r_ Content-Type: text/html; charset="utf-8" Content-ID: <15B8EFC0581F034BB485F62D4CCA7D42@microsoft.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT48IS0tCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwgewptYXJnaW46MGluIDBpbiAwcHQ7CmZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7CmZvbnQtc2l6ZToxMXB0Owp9CgpsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwgewptYXJnaW46MGluIDBpbiAwcHQ7CmZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7CmZvbnQtc2l6ZToxMXB0Owp9CgpkaXYuTXNvTm9ybWFsIHsKbWFyZ2lu OjBpbiAwaW4gMHB0Owpmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOwpmb250LXNp emU6MTFwdDsKfQoKYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluayB7CmNvbG9yOmJsdWU7CnRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7Cn0KCnNwYW4uTXNvSHlwZXJsaW5rIHsKY29sb3I6Ymx1ZTsK dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsKfQoKc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZCB7 CmNvbG9yOnB1cnBsZTsKdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsKfQoKc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZCB7CmNvbG9yOnB1cnBsZTsKdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsK fQoKc3Bhbi5FbWFpbFN0eWxlMTcgewpjb2xvcjp3aW5kb3d0ZXh0Owpmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOwp9CgpzcGFuLkVtYWlsU3R5bGUxOCB7CmNvbG9yOnJnYigzMSwg NzMsIDEyNSk7CmZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Cn0KCi5Nc29DaHBE ZWZhdWx0IHsKZm9udC1zaXplOjEwcHQ7Cn0KCmRpdi5Xb3JkU2VjdGlvbjEgewp9Ci0tPjwvc3R5 bGU+DQo8L2hlYWQ+DQo8Ym9keT4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksJnF1 b3Q7U2Vnb2UgVUkmcXVvdDssTWVpcnlvLCZxdW90O01pY3Jvc29mdCBZYUhlaSBVSSZxdW90Oywm cXVvdDtNaWNyb3NvZnQgSmhlbmdIZWkgVUkmcXVvdDssJnF1b3Q7TWFsZ3VuIEdvdGhpYyZxdW90 OywmcXVvdDtLaG1lciBVSSZxdW90OywmcXVvdDtOaXJtYWxhIFVJJnF1b3Q7LFR1bmdhLCZxdW90 O0xhbyBVSSZxdW90OyxFYnJpbWEsc2Fucy1zZXJpZjtmb250LXNpemU6MTZweDsiPg0KPGRpdiBk YXRhLWZvY3VzZnJvbXBvaW50ZXI9InRydWUiPklmIHlvdeKAmXJlIGludGVyZXN0ZWQgaW4gbWVl dGluZyB3aXRoIHVzIHRvZGF5IHRvIGdhdGhlciBkYXRhIGFib3V0IHdoYXQgT0F1dGggZmVhdHVy ZXMgYXJlIGltcGxlbWVudGVkIGFuZCBjaG9pY2VzIGFyZSBtYWRlJm5ic3A7aW4gZGlmZmVyZW50 IGltcGxlbWVudGF0aW9ucywgcGxlYXNlIHRha2UgYSBtaW51dGUgdGhpcyBtb3JuaW5nIGFuZCBm aWxsIGluIHRoZSBEb29kbGUgcG9sbCB0byBoZWxwDQogdXMgY2hvb3NlIGEgbWVldGluZyB0aW1l LjwvZGl2Pg0KPGRpdiBkYXRhLWZvY3VzZnJvbXBvaW50ZXI9InRydWUiPiZuYnNwOzwvZGl2Pg0K PGRpdiBkYXRhLWZvY3VzZnJvbXBvaW50ZXI9InRydWUiPlRoYW5rcyw8L2Rpdj4NCjxkaXYgZGF0 YS1mb2N1c2Zyb21wb2ludGVyPSJ0cnVlIj4tLSBNaWtlPC9kaXY+DQo8ZGl2IGRhdGEtZm9jdXNm cm9tcG9pbnRlcj0idHJ1ZSI+Jm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXItdG9wLWNv bG9yOiByZ2IoMjI5LCAyMjksIDIyOSk7IGJvcmRlci10b3Atd2lkdGg6IDJweDsgYm9yZGVyLXRv cC1zdHlsZTogc29saWQ7IiBkYXRhLWZvY3VzZnJvbXBvaW50ZXI9InRydWUiPg0KPHN0cm9uZz5G cm9tOjwvc3Ryb25nPiZuYnNwO01pa2UgSm9uZXM8YnI+DQo8c3Ryb25nPlNlbnQ6PC9zdHJvbmc+ Jm5ic3A74oCOTWFyY2jigI4g4oCOMTHigI4sIOKAjjIwMTMg4oCONOKAjjrigI41MOKAjiDigI5Q TTxicj4NCjxzdHJvbmc+VG86PC9zdHJvbmc+Jm5ic3A7b2F1dGhAaWV0Zi5vcmc8YnI+DQo8c3Ry b25nPlN1YmplY3Q6PC9zdHJvbmc+Jm5ic3A7UmU6IFtPQVVUSC1XR10gT0F1dGggRmVhdHVyZSBN YXRyaXg8YnI+DQo8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMzEs IDczLCAxMjUpOyI+UGxlYXNlIHJlc3BvbmQgdG8gdGhpcyBEb29kbGUgUG9sbA0KPGEgaHJlZj0i aHR0cDovL2Rvb2RsZS5jb20vZnZya21yOHF0aWt0YzN1bSI+aHR0cDovL2Rvb2RsZS5jb20vZnZy a21yOHF0aWt0YzN1bTwvYT4gdG8gaW5kaWNhdGUgd2hpY2ggdGltZXMgeW914oCZZCBwcmVmZXIg dG8gbWVldCB0b21vcnJvdyAoVHVlc2RheSkgYWZ0ZXJub29uLjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij4mbmJz cDs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiBy Z2IoMzEsIDczLCAxMjUpOyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+Jm5i c3A7PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXItd2lkdGg6IDFwdCBtZWRp dW0gbWVkaXVtOyBib3JkZXItc3R5bGU6IHNvbGlkIG5vbmUgbm9uZTsgYm9yZGVyLWNvbG9yOiBy Z2IoMTgxLCAxOTYsIDIyMykgYmxhY2sgYmxhY2s7IHBhZGRpbmc6IDNwdCAwaW4gMGluOyI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6ICZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBmb250LXNpemU6IDEwcHQ7Ij5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAmcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgZm9udC1zaXplOiAxMHB0OyI+IE1pa2UgSm9uZXMNCjxi cj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIE1hcmNoIDExLCAyMDEzIDM6MzggUE08YnI+DQo8Yj5U bzo8L2I+IG9hdXRoQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IE9BdXRoIEZlYXR1cmUg TWF0cml4PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgT0F1dGggRmVhdHVyZSBNYXRyaXgg c3ByZWFkc2hlZXQgdGhhdCBJIHRhbGtlZCBhYm91dCBhdCB0aGUgT0F1dGggV0cgbWVldGluZyB0 b2RheSBpcyBhdHRhY2hlZCBhbmQgYXZhaWxhYmxlIGF0DQo8YSBocmVmPSJodHRwOi8vc2VsZi1p c3N1ZWQuaW5mby9taXNjL09BdXRoJTIwRmVhdHVyZSUyME1hdHJpeC54bHN4Ij5odHRwOi8vc2Vs Zi1pc3N1ZWQuaW5mby9taXNjL09BdXRoJTIwRmVhdHVyZSUyME1hdHJpeC54bHN4PC9hPi4mbmJz cDsgVG9ueSBOYWRhbGluIGFuZCBJIGNyZWF0ZWQgaXQgYXMgYSB0b29sIHRvIGNoYXJhY3Rlcml6 ZSBPQXV0aCBpbXBsZW1lbnRhdGlvbnMgdG8gaGVscCBwcm9tb3RlIGludGVyb3BlcmFiaWxpdHkg YnkgdW5kZXJzdGFuZGluZw0KIHRoZSBjaG9pY2VzIHRoYXQgZGlmZmVyZW50IGltcGxlbWVudGVy cyBoYXZlIG1hZGUuPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+QWxzbyBhcyBkaXNjdXNzZWQgdG9kYXksIEkgcHJvcG9zZSB0aGF0IHBl b3BsZSB3aXRoIGltcGxlbWVudGF0aW9ucyBnZXQgdG9nZXRoZXIgdG9tb3Jyb3cgKFR1ZXNkYXkp IGFmdGVybm9vbiB0byB0YWtlIGEgcXVpY2sgcGFzcyBhdCBjaGFyYWN0ZXJpemluZyB0aGUgY2hv aWNlcyBtYWRlIGluIHlvdXIgaW1wbGVtZW50YXRpb25zIHRvIGRhdGUuJm5ic3A7IFRoZW4gd2Ug Y2FuIHJlcG9ydCBiYWNrIHRvIHRoZSB3b3JraW5nDQogZ3JvdXAgb24gVGh1cnNkYXkgd2l0aCBh IHNuYXBzaG90IG9mIHRoZSBjaG9pY2VzIG1hZGUsIHdoaWNoIHdpbGwgaGVscCB1cyBnZXQgYSBz ZW5zZSBvZiB3aGljaCBmZWF0dXJlcyBhcmUgbGlrZWx5IHRvIGJlIGludGVyb3BlcmFibGUgYWNy b3NzIGltcGxlbWVudGF0aW9ucy4mbmJzcDsgKEFjdHVhbGx5LCBhbGwgdGhvc2Ugd2hvIGFyZSBp bnRlcmVzdGVkIGFyZSB3ZWxjb21lLCBub3QganVzdCB0aG9zZSB3aXRoIGltcGxlbWVudGF0aW9u cy4pPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SeKAmWxsIGNyZWF0ZSBhIERvb2RsZSBwb2xsIG5vdyB0byBoZWxwIHVzIGNob29zZSBh IHRpbWUgd2luZG93IGJldHdlZW4gMTowMCBhbmQgNTowMCB0byBnZXQgdG9nZXRoZXIgYW5kIGRv IHRoaXMuJm5ic3A7IEFsc28sIHN0YXkgdHVuZWQgZm9yIHRoZSByb29tIHdoZXJlIHdl4oCZbGwg bWVldC48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5Ib3BlZnVsbHkgdGhpcyB3aWxsIGJlIGEgdXNlZnVsIGFuZCBpbmZvcm1hdGl2ZSBl eGVyY2lzZeKApjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_4E1F6AAD24975D4BA5B1680429673943674FA96BTK5EX14MBXC283r_-- From Michael.Jones@microsoft.com Tue Mar 12 07:41: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 B03D721F8C11 for ; Tue, 12 Mar 2013 07:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.765 X-Spam-Level: X-Spam-Status: No, score=-2.765 tagged_above=-999 required=5 tests=[AWL=-0.167, 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 r6fpuz90EXyg for ; Tue, 12 Mar 2013 07:41:34 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0237.outbound.protection.outlook.com [207.46.163.237]) by ietfa.amsl.com (Postfix) with ESMTP id 7172D21F8C0C for ; Tue, 12 Mar 2013 07:41:34 -0700 (PDT) Received: from BY2FFO11FD004.protection.gbl (10.1.15.200) by BY2FFO11HUB018.protection.gbl (10.1.14.92) with Microsoft SMTP Server (TLS) id 15.0.620.12; Tue, 12 Mar 2013 14:41:32 +0000 Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD004.mail.protection.outlook.com (10.1.14.158) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Tue, 12 Mar 2013 14:41:32 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.132]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.02.0318.003; Tue, 12 Mar 2013 14:40:57 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: [OAUTH-WG] OAuth Feature Matrix Thread-Index: Ac4fL5q4BmcfQE/KQwy7KfSVJ7BEnA== Date: Tue, 12 Mar 2013 14:40:56 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943674FD69C@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943674FD69CTK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(53824001)(189002)(164054002)(377454001)(199002)(63696002)(59766001)(56816002)(15395725002)(50986001)(49866001)(74662001)(51856001)(69226001)(33656001)(46102001)(74502001)(16406001)(54316002)(16236675001)(76482001)(56776001)(47736001)(79102001)(55846006)(47976001)(4396001)(5343655001)(5343665001)(65816001)(54356001)(77982001)(15202345001)(47446002)(44976002)(53806001)(20776003)(80022001)(512874001)(5343635001)(31966008)(6606295001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB018; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 078310077C Subject: Re: [OAUTH-WG] OAuth Feature Matrix X-BeenThere: oauth@ietf.org X-Mailman-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, 12 Mar 2013 14:41:35 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943674FD69CTK5EX14MBXC283r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2Ugd2lsbCBtZWV0IHRvZGF5IGZyb20gMTowMC00OjAwIGluIEJvY2EgNCAodGhlIElBQiByb29t KS4gIFRoYW5rcywgSGFubmVzLCBmb3Igc2NoZWR1bGluZyB0aGUgcm9vbSBmb3IgdXMuDQoNCi0t IE1pa2UNCg0KRnJvbTogTWlrZSBKb25lcw0KU2VudDog4oCOTWFyY2jigI4g4oCOMTHigI4sIOKA jjIwMTMg4oCONOKAjjrigI41MOKAjiDigI5QTQ0KVG86IG9hdXRoQGlldGYub3JnDQpTdWJqZWN0 OiBSZTogW09BVVRILVdHXSBPQXV0aCBGZWF0dXJlIE1hdHJpeA0KDQpQbGVhc2UgcmVzcG9uZCB0 byB0aGlzIERvb2RsZSBQb2xsIGh0dHA6Ly9kb29kbGUuY29tL2Z2cmttcjhxdGlrdGMzdW0gdG8g aW5kaWNhdGUgd2hpY2ggdGltZXMgeW914oCZZCBwcmVmZXIgdG8gbWVldCB0b21vcnJvdyAoVHVl c2RheSkgYWZ0ZXJub29uLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IE1pa2UgSm9uZXMNClNlbnQ6 IE1vbmRheSwgTWFyY2ggMTEsIDIwMTMgMzozOCBQTQ0KVG86IG9hdXRoQGlldGYub3JnDQpTdWJq ZWN0OiBPQXV0aCBGZWF0dXJlIE1hdHJpeA0KDQpUaGUgT0F1dGggRmVhdHVyZSBNYXRyaXggc3By ZWFkc2hlZXQgdGhhdCBJIHRhbGtlZCBhYm91dCBhdCB0aGUgT0F1dGggV0cgbWVldGluZyB0b2Rh eSBpcyBhdHRhY2hlZCBhbmQgYXZhaWxhYmxlIGF0IGh0dHA6Ly9zZWxmLWlzc3VlZC5pbmZvL21p c2MvT0F1dGglMjBGZWF0dXJlJTIwTWF0cml4Lnhsc3guICBUb255IE5hZGFsaW4gYW5kIEkgY3Jl YXRlZCBpdCBhcyBhIHRvb2wgdG8gY2hhcmFjdGVyaXplIE9BdXRoIGltcGxlbWVudGF0aW9ucyB0 byBoZWxwIHByb21vdGUgaW50ZXJvcGVyYWJpbGl0eSBieSB1bmRlcnN0YW5kaW5nIHRoZSBjaG9p Y2VzIHRoYXQgZGlmZmVyZW50IGltcGxlbWVudGVycyBoYXZlIG1hZGUuDQoNCkFsc28gYXMgZGlz Y3Vzc2VkIHRvZGF5LCBJIHByb3Bvc2UgdGhhdCBwZW9wbGUgd2l0aCBpbXBsZW1lbnRhdGlvbnMg Z2V0IHRvZ2V0aGVyIHRvbW9ycm93IChUdWVzZGF5KSBhZnRlcm5vb24gdG8gdGFrZSBhIHF1aWNr IHBhc3MgYXQgY2hhcmFjdGVyaXppbmcgdGhlIGNob2ljZXMgbWFkZSBpbiB5b3VyIGltcGxlbWVu dGF0aW9ucyB0byBkYXRlLiAgVGhlbiB3ZSBjYW4gcmVwb3J0IGJhY2sgdG8gdGhlIHdvcmtpbmcg Z3JvdXAgb24gVGh1cnNkYXkgd2l0aCBhIHNuYXBzaG90IG9mIHRoZSBjaG9pY2VzIG1hZGUsIHdo aWNoIHdpbGwgaGVscCB1cyBnZXQgYSBzZW5zZSBvZiB3aGljaCBmZWF0dXJlcyBhcmUgbGlrZWx5 IHRvIGJlIGludGVyb3BlcmFibGUgYWNyb3NzIGltcGxlbWVudGF0aW9ucy4gIChBY3R1YWxseSwg YWxsIHRob3NlIHdobyBhcmUgaW50ZXJlc3RlZCBhcmUgd2VsY29tZSwgbm90IGp1c3QgdGhvc2Ug d2l0aCBpbXBsZW1lbnRhdGlvbnMuKQ0KDQpJ4oCZbGwgY3JlYXRlIGEgRG9vZGxlIHBvbGwgbm93 IHRvIGhlbHAgdXMgY2hvb3NlIGEgdGltZSB3aW5kb3cgYmV0d2VlbiAxOjAwIGFuZCA1OjAwIHRv IGdldCB0b2dldGhlciBhbmQgZG8gdGhpcy4gIEFsc28sIHN0YXkgdHVuZWQgZm9yIHRoZSByb29t IHdoZXJlIHdl4oCZbGwgbWVldC4NCg0KSG9wZWZ1bGx5IHRoaXMgd2lsbCBiZSBhIHVzZWZ1bCBh bmQgaW5mb3JtYXRpdmUgZXhlcmNpc2XigKYNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQo= --_000_4E1F6AAD24975D4BA5B1680429673943674FD69CTK5EX14MBXC283r_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT48IS0tCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwgewptYXJnaW46MGluIDBpbiAwcHQ7CmZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7CmZvbnQtc2l6ZToxMXB0Owp9CgpsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwgewptYXJnaW46MGluIDBpbiAwcHQ7CmZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7CmZvbnQtc2l6ZToxMXB0Owp9CgpkaXYuTXNvTm9ybWFsIHsKbWFyZ2lu OjBpbiAwaW4gMHB0Owpmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOwpmb250LXNp emU6MTFwdDsKfQoKYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluayB7CmNvbG9yOmJsdWU7CnRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7Cn0KCnNwYW4uTXNvSHlwZXJsaW5rIHsKY29sb3I6Ymx1ZTsK dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsKfQoKc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZCB7 CmNvbG9yOnB1cnBsZTsKdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsKfQoKc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZCB7CmNvbG9yOnB1cnBsZTsKdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsK fQoKc3Bhbi5FbWFpbFN0eWxlMTcgewpjb2xvcjp3aW5kb3d0ZXh0Owpmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOwp9CgpzcGFuLkVtYWlsU3R5bGUxOCB7CmNvbG9yOnJnYigzMSwg NzMsIDEyNSk7CmZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Cn0KCi5Nc29DaHBE ZWZhdWx0IHsKZm9udC1zaXplOjEwcHQ7Cn0KCmRpdi5Xb3JkU2VjdGlvbjEgewp9Ci0tPjwvc3R5 bGU+DQo8L2hlYWQ+DQo8Ym9keT4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksJnF1 b3Q7U2Vnb2UgVUkmcXVvdDssTWVpcnlvLCZxdW90O01pY3Jvc29mdCBZYUhlaSBVSSZxdW90Oywm cXVvdDtNaWNyb3NvZnQgSmhlbmdIZWkgVUkmcXVvdDssJnF1b3Q7TWFsZ3VuIEdvdGhpYyZxdW90 OywmcXVvdDtLaG1lciBVSSZxdW90OywmcXVvdDtOaXJtYWxhIFVJJnF1b3Q7LFR1bmdhLCZxdW90 O0xhbyBVSSZxdW90OyxFYnJpbWEsc2Fucy1zZXJpZjtmb250LXNpemU6MTZweDsiPg0KPGRpdj5X ZSB3aWxsIG1lZXQgdG9kYXkgZnJvbSAxOjAwLTQ6MDAgaW4gQm9jYSA0ICh0aGUgSUFCIHJvb20p LiZuYnNwOyBUaGFua3MsIEhhbm5lcywgZm9yIHNjaGVkdWxpbmcgdGhlIHJvb20gZm9yIHVzLjwv ZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+LS0gTWlrZTwvZGl2Pg0KPGRpdj4mbmJzcDs8 L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlci10b3AtY29sb3I6IHJnYigyMjksIDIyOSwgMjI5KTsg Ym9yZGVyLXRvcC13aWR0aDogMnB4OyBib3JkZXItdG9wLXN0eWxlOiBzb2xpZDsiPg0KPHN0cm9u Zz5Gcm9tOjwvc3Ryb25nPiZuYnNwO01pa2UgSm9uZXM8YnI+DQo8c3Ryb25nPlNlbnQ6PC9zdHJv bmc+Jm5ic3A74oCOTWFyY2jigI4g4oCOMTHigI4sIOKAjjIwMTMg4oCONOKAjjrigI41MOKAjiDi gI5QTTxicj4NCjxzdHJvbmc+VG86PC9zdHJvbmc+Jm5ic3A7b2F1dGhAaWV0Zi5vcmc8YnI+DQo8 c3Ryb25nPlN1YmplY3Q6PC9zdHJvbmc+Jm5ic3A7UmU6IFtPQVVUSC1XR10gT0F1dGggRmVhdHVy ZSBNYXRyaXg8YnI+DQo8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSJXb3Jk U2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2Io MzEsIDczLCAxMjUpOyI+UGxlYXNlIHJlc3BvbmQgdG8gdGhpcyBEb29kbGUgUG9sbA0KPGEgaHJl Zj0iaHR0cDovL2Rvb2RsZS5jb20vZnZya21yOHF0aWt0YzN1bSI+aHR0cDovL2Rvb2RsZS5jb20v ZnZya21yOHF0aWt0YzN1bTwvYT4gdG8gaW5kaWNhdGUgd2hpY2ggdGltZXMgeW914oCZZCBwcmVm ZXIgdG8gbWVldCB0b21vcnJvdyAoVHVlc2RheSkgYWZ0ZXJub29uLjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij4m bmJzcDs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OiByZ2IoMzEsIDczLCAxMjUpOyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+ Jm5ic3A7PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXItd2lkdGg6IDFwdCBt ZWRpdW0gbWVkaXVtOyBib3JkZXItc3R5bGU6IHNvbGlkIG5vbmUgbm9uZTsgYm9yZGVyLWNvbG9y OiByZ2IoMTgxLCAxOTYsIDIyMykgYmxhY2sgYmxhY2s7IHBhZGRpbmc6IDNwdCAwaW4gMGluOyI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6ICZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBmb250LXNpemU6IDEwcHQ7Ij5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAmcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgZm9udC1zaXplOiAxMHB0OyI+IE1pa2UgSm9uZXMN Cjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIE1hcmNoIDExLCAyMDEzIDM6MzggUE08YnI+DQo8 Yj5Ubzo8L2I+IG9hdXRoQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IE9BdXRoIEZlYXR1 cmUgTWF0cml4PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgT0F1dGggRmVhdHVyZSBNYXRy aXggc3ByZWFkc2hlZXQgdGhhdCBJIHRhbGtlZCBhYm91dCBhdCB0aGUgT0F1dGggV0cgbWVldGlu ZyB0b2RheSBpcyBhdHRhY2hlZCBhbmQgYXZhaWxhYmxlIGF0DQo8YSBocmVmPSJodHRwOi8vc2Vs Zi1pc3N1ZWQuaW5mby9taXNjL09BdXRoJTIwRmVhdHVyZSUyME1hdHJpeC54bHN4Ij5odHRwOi8v c2VsZi1pc3N1ZWQuaW5mby9taXNjL09BdXRoJTIwRmVhdHVyZSUyME1hdHJpeC54bHN4PC9hPi4m bmJzcDsgVG9ueSBOYWRhbGluIGFuZCBJIGNyZWF0ZWQgaXQgYXMgYSB0b29sIHRvIGNoYXJhY3Rl cml6ZSBPQXV0aCBpbXBsZW1lbnRhdGlvbnMgdG8gaGVscCBwcm9tb3RlIGludGVyb3BlcmFiaWxp dHkgYnkgdW5kZXJzdGFuZGluZw0KIHRoZSBjaG9pY2VzIHRoYXQgZGlmZmVyZW50IGltcGxlbWVu dGVycyBoYXZlIG1hZGUuPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+QWxzbyBhcyBkaXNjdXNzZWQgdG9kYXksIEkgcHJvcG9zZSB0aGF0 IHBlb3BsZSB3aXRoIGltcGxlbWVudGF0aW9ucyBnZXQgdG9nZXRoZXIgdG9tb3Jyb3cgKFR1ZXNk YXkpIGFmdGVybm9vbiB0byB0YWtlIGEgcXVpY2sgcGFzcyBhdCBjaGFyYWN0ZXJpemluZyB0aGUg Y2hvaWNlcyBtYWRlIGluIHlvdXIgaW1wbGVtZW50YXRpb25zIHRvIGRhdGUuJm5ic3A7IFRoZW4g d2UgY2FuIHJlcG9ydCBiYWNrIHRvIHRoZSB3b3JraW5nDQogZ3JvdXAgb24gVGh1cnNkYXkgd2l0 aCBhIHNuYXBzaG90IG9mIHRoZSBjaG9pY2VzIG1hZGUsIHdoaWNoIHdpbGwgaGVscCB1cyBnZXQg YSBzZW5zZSBvZiB3aGljaCBmZWF0dXJlcyBhcmUgbGlrZWx5IHRvIGJlIGludGVyb3BlcmFibGUg YWNyb3NzIGltcGxlbWVudGF0aW9ucy4mbmJzcDsgKEFjdHVhbGx5LCBhbGwgdGhvc2Ugd2hvIGFy ZSBpbnRlcmVzdGVkIGFyZSB3ZWxjb21lLCBub3QganVzdCB0aG9zZSB3aXRoIGltcGxlbWVudGF0 aW9ucy4pPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SeKAmWxsIGNyZWF0ZSBhIERvb2RsZSBwb2xsIG5vdyB0byBoZWxwIHVzIGNob29z ZSBhIHRpbWUgd2luZG93IGJldHdlZW4gMTowMCBhbmQgNTowMCB0byBnZXQgdG9nZXRoZXIgYW5k IGRvIHRoaXMuJm5ic3A7IEFsc28sIHN0YXkgdHVuZWQgZm9yIHRoZSByb29tIHdoZXJlIHdl4oCZ bGwgbWVldC48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5Ib3BlZnVsbHkgdGhpcyB3aWxsIGJlIGEgdXNlZnVsIGFuZCBpbmZvcm1hdGl2 ZSBleGVyY2lzZeKApjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_4E1F6AAD24975D4BA5B1680429673943674FD69CTK5EX14MBXC283r_-- From sakimura@gmail.com Tue Mar 12 08:28: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 2AF9F21F8CB6; Tue, 12 Mar 2013 08:28:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.056 X-Spam-Level: X-Spam-Status: No, score=-3.056 tagged_above=-999 required=5 tests=[AWL=0.542, 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 aXrR7qGK8HHq; Tue, 12 Mar 2013 08:28:33 -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 6543A21F8CBE; Tue, 12 Mar 2013 08:28:32 -0700 (PDT) Received: by mail-lb0-f178.google.com with SMTP id n1so87207lba.9 for ; Tue, 12 Mar 2013 08:28: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:cc:content-type; bh=hL/BEswdkdpYHvFPcNAOpajLkh21UpN/pb+KENj9eWY=; b=w+T4LNfhroioukJp5eW9uWxoyOg4piIVXHm459pSlJYVdK76pn1Q0hUrB87cI1qK+f 5BgkgJRgD4RG2R31KHlRTbIzRPvk7rV9S11WMKFnkF6ZSDK2cScBMr75v43Im4Jp1Igt l05eDw0cXOKqoBTMgeLhmDZ4c8t/zeGWe8OXcExZKAzlGtAQlhue5qAh7lwkwIAMz3/1 evVp4Y+Ip0ASa/wyCq+005qqSLQzeWd2LoeAFGNN1R9Yvv75cE0XqXHg5dy9eDeFnGFm W4fm405vI1rO338jZg1YQU1M8lUVuWAWWCgMN5y6zzb1O7bUTgnCZNjHWjiew90fJpqo vsbQ== MIME-Version: 1.0 X-Received: by 10.152.132.138 with SMTP id ou10mr14401330lab.56.1363102107506; Tue, 12 Mar 2013 08:28:27 -0700 (PDT) Received: by 10.112.103.202 with HTTP; Tue, 12 Mar 2013 08:28:27 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943674FA494@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B1680429673943674FA494@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Wed, 13 Mar 2013 00:28:27 +0900 Message-ID: From: Nat Sakimura To: Mike Jones Content-Type: multipart/alternative; boundary=f46d042d051ce9268804d7bbf048 Cc: "oauth@ietf.org" , "oauth-bounces@ietf.org" Subject: Re: [OAUTH-WG] OAuth Feature Matrix X-BeenThere: oauth@ietf.org X-Mailman-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, 12 Mar 2013 15:28:34 -0000 --f46d042d051ce9268804d7bbf048 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I have asked several Japanese developers to fill the form. Nat 2013/3/12 Mike Jones > Absolutely! In fact, Chuck Mortimore already sent me results for > Salesforce and Justin Richer already gave me results for Mitre, even thou= gh > both won=92t be able to be there on Thursday. If you send me your result= s > I=92ll aggregate them into the presentation. > > Best wishes, > -- Mike > > *From:* Todd W Lainhart > *Sent:* March 12, 2013 6:33 AM > *To:* Mike Jones > *CC:* oauth@ietf.org, oauth-bounces@ietf.org > *Subject:* Re: [OAUTH-WG] OAuth Feature Matrix > > Are you interested in survey results from non-meeting members? If so, > where/how do you want that posted? > > * > > > Todd Lainhart > Rational software > IBM Corporation > 550 King Street, Littleton, MA 01460-1250** > 1-978-899-4705 > 2-276-4705 (T/L) > lainhart@us.ibm.com* > > > > > From: Mike Jones > To: "oauth@ietf.org" , > Date: 03/11/2013 06:39 PM > Subject: [OAUTH-WG] OAuth Feature Matrix > Sent by: oauth-bounces@ietf.org > ------------------------------ > > > > The OAuth Feature Matrix spreadsheet that I talked about at the OAuth WG > meeting today is attached and available at * > http://self-issued.info/misc/OAuth%20Feature%20Matrix.xlsx*. > Tony Nadalin and I created it as a tool to characterize OAuth > implementations to help promote interoperability by understanding the > choices that different implementers have made. > > Also as discussed today, I propose that people with implementations get > together tomorrow (Tuesday) afternoon to take a quick pass at > characterizing the choices made in your implementations to date. Then we > can report back to the working group on Thursday with a snapshot of the > choices made, which will help us get a sense of which features are likely > to be interoperable across implementations. (Actually, all those who are > interested are welcome, not just those with implementations.) > > I=92ll create a Doodle poll now to help us choose a time window between 1= :00 > and 5:00 to get together and do this. Also, stay tuned for the room wher= e > we=92ll meet. > > Hopefully this will be a useful and informative exercise=85 > > -- Mike > [attachment "OAuth Feature Matrix.xlsx" deleted by Todd W > Lainhart/Lexington/IBM] _______________________________________________ > OAuth mailing 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 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --f46d042d051ce9268804d7bbf048 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I have asked several Japanese developers to fill the form.=A0

Nat

2013/3/12 Mike Jones <Michael.Jones@microsoft.com>
Absolutely!=A0 In fact, Chuck Mortimore already sent me results for Sa= lesforce and Justin Richer already gave me results for Mitre, even though b= oth won=92t be able to be there on Thursday.=A0 If you send me your results= I=92ll aggregate them into the presentation.
=A0
Best wishes,
-- Mike
=A0
From:=A0Todd W Lainhart
Sent:=A0March 12, 2013 6:33 AM
To:=A0Mike Jones
CC:=A0= oauth@ietf.org, oauth-bounces@ietf.org
Subject:=A0Re: [OAUTH-WG] OAuth Feature Matrix
=A0
Are you interested in survey results from non-mee= ting members? =A0If so, where/how do you want that posted?




Todd Lainhart
Rational software
IBM Corporation
550 King Street, Littleton, MA 01460-1250
1-9= 78-899-4705
2-276-4705 (T/L)
lainhart@us.ibm.co= m





From: =A0 =A0 =A0 = =A0Mike Jones <Michael.Jones@microsoft= .com>
To: =A0 =A0 =A0 =A0<= /font>"oauth@ietf.org" <oauth@ietf.org>,
Date: =A0 =A0 =A0 = =A003/11/2013 06:39 PM
Subject: =A0 =A0 =A0= =A0[OAUTH-WG] OAuth Feature Ma= trix
Sent by: =A0 =A0 =A0= =A0oauth-bounces@ietf.org



The OAuth Feature Matrix spreadsheet that I talked a= bout at the OAuth WG meeting today is attached and available at http://self-i= ssued.info/misc/OAuth%20Feature%20Matrix.xlsx. =A0Tony Nadalin and I created it as a tool to characterize OAuth implementations to help promote interopera= bility by understanding the choices that different implementers have made.<= /font>
=A0
Also as discussed today, I propose that people with = implementations get together tomorrow (Tuesday) afternoon to take a quick p= ass at characterizing the choices made in your implementations to date. =A0= Then we can report back to the working group on Thursday with a snapshot of the choices made, which w= ill help us get a sense of which features are likely to be interoperable ac= ross implementations. =A0(Actually, all those who are interested are welcom= e, not just those with implementations.)
=A0
I=92ll create a Doodle poll now to help us choose a = time window between 1:00 and 5:00 to get together and do this. =A0Also, sta= y tuned for the room where we=92ll meet.
=A0
Hopefully this will be a useful and informative exer= cise=85
=A0
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -- Mike=
=A0[attachment "OAuth Feature Matrix.xlsx"= deleted by Todd W Lainhart/Lexington/IBM] _______________________________________________
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




--
Nat Saki= mura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
--f46d042d051ce9268804d7bbf048-- From vanni156@yahoo.com.vn Tue Mar 12 08:45:42 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 8829011E80D7 for ; Tue, 12 Mar 2013 08:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.796 X-Spam-Level: * X-Spam-Status: No, score=1.796 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, 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 bOd36InV5LNy for ; Tue, 12 Mar 2013 08:45:35 -0700 (PDT) Received: from nm14.bullet.mail.bf1.yahoo.com (nm14.bullet.mail.bf1.yahoo.com [98.139.212.173]) by ietfa.amsl.com (Postfix) with SMTP id 44C5311E80D3 for ; Tue, 12 Mar 2013 08:45:34 -0700 (PDT) Received: from [98.139.212.145] by nm14.bullet.mail.bf1.yahoo.com with NNFMP; 12 Mar 2013 15:45:33 -0000 Received: from [98.139.173.167] by tm2.bullet.mail.bf1.yahoo.com with NNFMP; 12 Mar 2013 15:45:33 -0000 Received: from [127.0.0.1] by smtp110-mob.biz.mail.bf1.yahoo.com with NNFMP; 12 Mar 2013 15:45:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.vn; s=s1024; t=1363103133; bh=z+3wJhbdJ4eL83VG/YzibfBoUNHW7hDOG/T/2mdrHS4=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:X-rim-org-msg-ref-id:Message-ID:Content-Transfer-Encoding:Reply-To:X-Priority:Sensitivity:Importance:Subject:To:From:Date:Content-Type:MIME-Version; b=Lp0kW85Y4ljryMf/cJKaU8Jam9N396oMu4uaJhHJ+qHRNT4ArJstdkSN7W/naawiIvzaKQ+T07FUEBQa/g40veDkToYNwUuBSEy7tXAwCLytTe35RNU3eDIxEpGdTr7XrqHXTOvIHKvdZ7hmMaFTrTdgs5Utlt64kjGRRdejoLA= X-Yahoo-Newman-Id: 509739.63162.bm@smtp110-mob.biz.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: To3M4gkVM1lQoXAQPwV7WmF0Vu0.lj8S1ibbiTrUBJ2tB9p 1MurbtZamzgj735hr2UKx_vNWWNSCN4v4iLTz9egx3BVJdQplpWs8EXePpVI WrxSY0oIewK6.vcWzTp5lgeSLcwLsGP.3iHdcaXTbPvgkIKewc6qAd1yiy5i zc8_WjJM.9B1I_5zWqxpNXZk4knoBbYymwpOCKvDFuoXvCRHoZUnHGboFASr hYQc_rBKiDAwhtmz.Yv5PkNPSf0OkXDxLiyEtfAoSTrRrU4E0cJSRkKnmvTI pedRsI3DZtVbtG8fOR94In9Ik.yCaI4NRmxTnCHad_4J9Wxjnb3vlbAcD7di PQ64UuvQJIfabLfsNSC31KYPtV35emolzvL2OhkIiJeDew8Z2z8kvHTos37K A2CSnkV2a7GNRYRiKc0zaSyNFdM6N X-Yahoo-SMTP: CQnEgimswBAaOuU_hrhhAc8WBEkC Received: from b1.c6.bise3.blackberry (vanni156@216.9.250.208 with xymcookie) by smtp110-mob.biz.mail.bf1.yahoo.com with SMTP; 12 Mar 2013 08:45:32 -0700 PDT X-rim-org-msg-ref-id: 2130330688 Message-ID: <2130330688-1363103130-cardhu_decombobulator_blackberry.rim.net-1831374427-@b28.c6.bise3.blackberry> Content-Transfer-Encoding: base64 X-Priority: Normal Sensitivity: Normal Importance: Normal To: oauth@ietf.org From: "LuongKhanhVan" Date: Tue, 12 Mar 2013 15:45:29 +0000 Content-Type: text/plain; charset="Windows-1252" MIME-Version: 1.0 Subject: [OAUTH-WG] ABCDEFGHIKLMN X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: vanni156@yahoo.com.vn List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 15:45:42 -0000 DQpTZW50IGZyb20gbXkgQmxhY2tCZXJyea4gc21hcnRwaG9uZQ== From vanni156@yahoo.com.vn Tue Mar 12 08:46: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 8D32811E80E1 for ; Tue, 12 Mar 2013 08:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.796 X-Spam-Level: * X-Spam-Status: No, score=1.796 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, 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 HR949XRwMifs for ; Tue, 12 Mar 2013 08:46:55 -0700 (PDT) Received: from nm18-vm0.bullet.mail.bf1.yahoo.com (nm18-vm0.bullet.mail.bf1.yahoo.com [98.139.213.138]) by ietfa.amsl.com (Postfix) with SMTP id 8D4C411E80E0 for ; Tue, 12 Mar 2013 08:46:55 -0700 (PDT) Received: from [98.139.212.150] by nm18.bullet.mail.bf1.yahoo.com with NNFMP; 12 Mar 2013 15:46:54 -0000 Received: from [98.139.173.188] by tm7.bullet.mail.bf1.yahoo.com with NNFMP; 12 Mar 2013 15:46:54 -0000 Received: from [127.0.0.1] by smtp115-mob.biz.mail.bf1.yahoo.com with NNFMP; 12 Mar 2013 15:46:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.vn; s=s1024; t=1363103214; bh=tp4Yq68i6fc0fNEEAMo4Jxxb+gd06T5nRZWRzPVLUV8=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:X-rim-org-msg-ref-id:Message-ID:Content-Transfer-Encoding:Reply-To:X-Priority:References:In-Reply-To:Sensitivity:Importance:Subject:To:From:Date:Content-Type:MIME-Version; b=ZfR80KgW0Zey3ihJ68ajF0QBpSOQJDhsLYQRvsAXhr9IlE55LxmOg4Wyd37KOjCc4vQwKHyW6v9dVMpfAgDBFym1zNaQHmCM1K0RaS6//Ws/dkfp4AOLYq2tuZh5iyhoj4exEz1POzdBxyKov1IzGbNcxpvNkuQFUdRcHld3WeY= X-Yahoo-Newman-Id: 713047.4098.bm@smtp115-mob.biz.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: eullUiQVM1kB44IBI8cugQXbr8yVVRoxCnzxJ4P8Usmgr24 IiKhEBk.D7Uqtrb4cg716dBYd4nMWSsZKxX6RH_9iHt_mb9Umimy9ojGEvx7 iwDfO2hJvI91HZ2vFPkNH2GI5_oBpCtshnr.duCnQPwx.kWoCiZTyiImJdDX tYScN5hAmZWLlk8hXteU_b61e7vVwwLucxvqJuzpgfRpgPiIRUQ0K6X6UsKL io.mV7VejQNDIJEFmUjS28sRvKIBBE57I.VI1Lo2isooTRFIHoJKNh1brX1j Ihb0300mTvmgiSZGPRcvndUlVhTmSmF923eSC2eLc6dHYIQV7FQ91RrQh.ii VP3a2zPZbnKbzbuXViP5ndTtC0_g2E1EKOqxU3TBRfq3qeQQZEHCxbwR5sE9 W4oqojetezQs1nb0hqf__WXjat.5sA5aQOB7aSfiS0Eu7L90UWpl4.yh3QaL 9vbm9FfmS X-Yahoo-SMTP: CQnEgimswBAaOuU_hrhhAc8WBEkC Received: from b1.c6.bise3.blackberry (vanni156@216.9.250.208 with xymcookie) by smtp115-mob.biz.mail.bf1.yahoo.com with SMTP; 12 Mar 2013 08:46:54 -0700 PDT X-rim-org-msg-ref-id: 565184402 Message-ID: <565184402-1363103212-cardhu_decombobulator_blackberry.rim.net-1792164210-@b28.c6.bise3.blackberry> Content-Transfer-Encoding: base64 X-Priority: Normal References: <2130330688-1363103130-cardhu_blackberry.rim.net-copy_sent_folder-781626904-@b28.c6.bise3.blackberry> In-Reply-To: <2130330688-1363103130-cardhu_blackberry.rim.net-copy_sent_folder-781626904-@b28.c6.bise3.blackberry> Sensitivity: Normal Importance: Normal To: oauth@ietf.org From: "LuongKhanhVan" Date: Tue, 12 Mar 2013 15:46:51 +0000 Content-Type: text/plain; charset="Windows-1252" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] ABCDEFGHIKLMN X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: vanni156@yahoo.com.vn List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 15:46:56 -0000 V2llIGhlaXBlbiBTaWUgPyANClNlbnQgZnJvbSBteSBCbGFja0JlcnJ5riBzbWFydHBob25lDQoN Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiAiTHVvbmdLaGFuaFZhbiIgPHZhbm5p MTU2QHlhaG9vLmNvbS52bj4NCkRhdGU6IFR1ZSwgMTIgTWFyIDIwMTMgMTU6NDU6MjkgDQpUbzog PG9hdXRoQGlldGYub3JnPg0KUmVwbHktVG86IHZhbm5pMTU2QHlhaG9vLmNvbS52bg0KU3ViamVj dDogQUJDREVGR0hJS0xNTg0KDQoNClNlbnQgZnJvbSBteSBCbGFja0JlcnJ5riBzbWFydHBob25l From matake@gmail.com Tue Mar 12 08:51: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 2290A21F8CC2; Tue, 12 Mar 2013 08:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id myLbuAiARch0; Tue, 12 Mar 2013 08:51:38 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2517621F8CBD; Tue, 12 Mar 2013 08:51:38 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id wz12so5121751pbc.31 for ; Tue, 12 Mar 2013 08:51:38 -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:message-id:references:to:x-mailer; bh=vX5xrKM1yMc2HbS5p7uim8/AlEcSsc837wlNNyOQCn8=; b=Js1cBWkpqf3dVFbvTpsEniJoEhq1hiRTVPLYIQ9l6rJMvGwXtsywYfzeROzzm1owDV BQ4l7ZiAMjskAgsm8q+Kd8KrUu0Z1uUX+3aXzkLzrAKV08u8KaUcPD2aEyIFMf+AO9ZZ DirxpZi/9f40iLge+sx3kPGYoRg76NSZ39uwktwwSv4LThApBCODrRrZOoh+aYy4SfR5 /MSplQYJVjt7DrMOUuuqP6I59Mu9F6y923ZliX3nThevlHRJsA/+V5zUvFyW4lxyfKgn fcv6wHdXkZhY69BL9gCjnSUVOK9hYODOmgQ2zri7U3LRfnlfYQsynEYPEfJ1xD/Wt0Z4 wLLg== X-Received: by 10.68.75.72 with SMTP id a8mr37998556pbw.143.1363103497786; Tue, 12 Mar 2013 08:51:37 -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 b9sm25555873pba.6.2013.03.12.08.51.33 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Mar 2013 08:51:34 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_37BFEBEB-6B0F-4B28-B14C-05EEC5AA354F" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: nov matake In-Reply-To: Date: Wed, 13 Mar 2013 00:51:38 +0900 Message-Id: <0C1CD7A0-5711-4FD0-AFBA-DED6290B08BC@gmail.com> References: <4E1F6AAD24975D4BA5B1680429673943674FA494@TK5EX14MBXC283.redmond.corp.microsoft.com> To: Nat Sakimura X-Mailer: Apple Mail (2.1499) Cc: "oauth@ietf.org" , "oauth-bounces@ietf.org" Subject: Re: [OAUTH-WG] OAuth Feature Matrix X-BeenThere: oauth@ietf.org X-Mailman-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, 12 Mar 2013 15:51:39 -0000 --Apple-Mail=_37BFEBEB-6B0F-4B28-B14C-05EEC5AA354F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Mike, This is my OpenID Connect OP's case. = https://docs.google.com/spreadsheet/ccc?key=3D0Alz2DOj-3mbldGc1bDVCN3lwZnB= qSUFFVGp4dWVnaWc&usp=3Dsharing Cheers, nov On 2013/03/13, at 0:28, Nat Sakimura wrote: > I have asked several Japanese developers to fill the form.=20 >=20 > Nat >=20 > 2013/3/12 Mike Jones > Absolutely! In fact, Chuck Mortimore already sent me results for = Salesforce and Justin Richer already gave me results for Mitre, even = though both won=92t be able to be there on Thursday. If you send me = your results I=92ll aggregate them into the presentation. > =20 > Best wishes, > -- Mike > =20 > From: Todd W Lainhart > Sent: March 12, 2013 6:33 AM > To: Mike Jones > CC: oauth@ietf.org, oauth-bounces@ietf.org > Subject: Re: [OAUTH-WG] OAuth Feature Matrix > =20 > Are you interested in survey results from non-meeting members? If so, = where/how do you want that posted? >=20 >=20 >=20 >=20 > Todd Lainhart > Rational software > IBM Corporation > 550 King Street, Littleton, MA 01460-1250 > 1-978-899-4705 > 2-276-4705 (T/L) > lainhart@us.ibm.com >=20 >=20 >=20 >=20 > From: Mike Jones =20 > To: "oauth@ietf.org" ,=20 > Date: 03/11/2013 06:39 PM=20 > Subject: [OAUTH-WG] OAuth Feature Matrix=20 > Sent by: oauth-bounces@ietf.org=20 >=20 >=20 >=20 > The OAuth Feature Matrix spreadsheet that I talked about at the OAuth = WG meeting today is attached and available at = http://self-issued.info/misc/OAuth%20Feature%20Matrix.xlsx. Tony = Nadalin and I created it as a tool to characterize OAuth implementations = to help promote interoperability by understanding the choices that = different implementers have made.=20 > =20 > Also as discussed today, I propose that people with implementations = get together tomorrow (Tuesday) afternoon to take a quick pass at = characterizing the choices made in your implementations to date. Then = we can report back to the working group on Thursday with a snapshot of = the choices made, which will help us get a sense of which features are = likely to be interoperable across implementations. (Actually, all those = who are interested are welcome, not just those with implementations.)=20 > =20 > I=92ll create a Doodle poll now to help us choose a time window = between 1:00 and 5:00 to get together and do this. Also, stay tuned for = the room where we=92ll meet.=20 > =20 > Hopefully this will be a useful and informative exercise=85=20 > =20 > -- Mike=20 > [attachment "OAuth Feature Matrix.xlsx" deleted by Todd W = Lainhart/Lexington/IBM] _______________________________________________ > 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 > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_37BFEBEB-6B0F-4B28-B14C-05EEC5AA354F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 https://docs.google.com/spread= sheet/ccc?key=3D0Alz2DOj-3mbldGc1bDVCN3lwZnBqSUFFVGp4dWVnaWc&usp=3Dsha= ring

Cheers,
nov

On 2013/03/13, at 0:28, Nat Sakimura <sakimura@gmail.com> = wrote:

I have asked several Japanese developers to fill the = form. 

Nat

2013/3/12 Mike Jones <Michael.Jones@microsoft.com>
Absolutely!  In fact, Chuck Mortimore already sent me results = for Salesforce and Justin Richer already gave me results for Mitre, even = though both won=92t be able to be there on Thursday.  If you send = me your results I=92ll aggregate them into the presentation.
 
Best wishes,
-- Mike
 
From: Todd W Lainhart
Sent: March 12, 2013 6:33 AM
To: Mike Jones
CC: oauth@ietf.org, oauth-bounces@ietf.org
Subject: Re: [OAUTH-WG] OAuth Feature Matrix
 
Are you interested in survey results from = non-meeting members?  If so, where/how do you want that posted?




Todd Lainhart
Rational software
IBM Corporation
550 King Street, Littleton, MA 01460-1250
1-978-899-4705
2-276-4705 (T/L)
lainhart@us.ibm.com





From:   =      Mike = Jones <Michael.Jones@microsoft.com>
To:     =    "oauth@ietf.org" = <oauth@ietf.org>,
Date:   =      03/11/2013= 06:39 PM
Subject:   =      [OAUTH-WG]= OAuth Feature Matrix
Sent by:   =      oauth-bounces@ietf.org



The OAuth Feature Matrix spreadsheet that I = talked about at the OAuth WG meeting today is attached and available at http://self-issued.info/misc/OAuth%20Feature%20Matrix.= xlsx.  Tony Nadalin and I = created it as a tool to characterize OAuth implementations to help promote = interoperability by understanding the choices that different = implementers have made.
 
Also as discussed today, I propose that people = with implementations get together tomorrow (Tuesday) afternoon to take a = quick pass at characterizing the choices made in your implementations to = date.  Then we can report back to the working group on Thursday with a snapshot of the choices made, = which will help us get a sense of which features are likely to be = interoperable across implementations.  (Actually, all those who are = interested are welcome, not just those with implementations.)
 
I=92ll create a Doodle poll now to help us choose = a time window between 1:00 and 5:00 to get together and do this. =  Also, stay tuned for the room where we=92ll meet.
 
Hopefully this will be a useful and informative = exercise=85
 
              =                     =                     =       -- Mike
 [attachment "OAuth Feature Matrix.xlsx" = deleted by Todd W Lainhart/Lexington/IBM] _______________________________________________
OAuth mailing list
OAuth@ietf.org
= https://www.ietf.org/mailman/listinfo/oauth=


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




--
Nat = Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
_______________________________________________
OAuth mailing = list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth

= --Apple-Mail=_37BFEBEB-6B0F-4B28-B14C-05EEC5AA354F-- From donald.coffin@reminetworks.com Tue Mar 12 10:11: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 D6E2F11E80D5 for ; Tue, 12 Mar 2013 10:11:54 -0700 (PDT) X-Quarantine-ID: X-Amavis-Modified: Mail body modified (defanged) by ietfa.amsl.com X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BANNED, message contains part: multipart/mixed | application/vnd.openxmlformats-officedocument.wordprocessingml.document, .zip, Encoding of OAuth 2 Scope Parameter.docx | .dat,docProps/thumbnail.emf 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 s08qfeF57MKQ for ; Tue, 12 Mar 2013 10:11:53 -0700 (PDT) Content-Type: multipart/mixed; boundary="----------=_1363108314-22861-0" Content-Transfer-Encoding: binary MIME-Version: 1.0 Received: from oproxy14-pub.unifiedlayer.com (oproxy14-pub.unifiedlayer.com [67.222.51.224]) by ietfa.amsl.com (Postfix) with SMTP id 088B31F0C74 for ; Tue, 12 Mar 2013 10:11:52 -0700 (PDT) Received: (qmail 25368 invoked by uid 0); 12 Mar 2013 17:05:09 -0000 Received: from unknown (HELO host125.hostmonster.com) (74.220.207.125) by oproxy14.unifiedlayer.com with SMTP; 12 Mar 2013 17:05:09 -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:To:From; bh=Bc3HWKKKWxMos3unOTvoatKbsSsxOmvWrjMZu487XL0=; b=Dm3N61MvaSx70CPFKdxlWA5csOD0PwJhp42Ile9/lx5g7ZnLwL4ItrsMQDlXhpymXy/ej6JQ7kCH5FRzMLIIgr+Xp93pBmiAK92gsjaaSPeBj1aSy8zWIh9QwLzLx1Lp; Received: from [68.4.207.246] (port=1447 helo=HPPavilionElite) by host125.hostmonster.com with esmtpa (Exim 4.80) (envelope-from ) id 1UFSdR-00042Q-6L; Tue, 12 Mar 2013 11:05:09 -0600 From: "Donald F Coffin" To: "'Mike Jones'" , References: <4E1F6AAD24975D4BA5B1680429673943674F7728@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943674F7728@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Tue, 12 Mar 2013 10:04:16 -0700 Message-ID: <007b01ce1f43$a1fdd580$e5f98080$@reminetworks.com> X-Mailer: Microsoft Outlook 14.0 Subject: Re: [OAUTH-WG] OAuth Feature Matrix X-BeenThere: oauth@ietf.org X-Mailman-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, 12 Mar 2013 17:11:55 -0000 This is a multi-part message in MIME format... ------------=_1363108314-22861-0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit WARNING: contains banned part ------------=_1363108314-22861-0 Content-Type: message/rfc822; x-spam-type=original; name="message" Content-Disposition: attachment; filename="message" Content-Transfer-Encoding: 7bit Content-Description: Original message Return-Path: Received: from oproxy14-pub.unifiedlayer.com (oproxy14-pub.unifiedlayer.com [67.222.51.224]) by ietfa.amsl.com (Postfix) with SMTP id 088B31F0C74 for ; Tue, 12 Mar 2013 10:11:52 -0700 (PDT) Received: (qmail 25368 invoked by uid 0); 12 Mar 2013 17:05:09 -0000 Received: from unknown (HELO host125.hostmonster.com) (74.220.207.125) by oproxy14.unifiedlayer.com with SMTP; 12 Mar 2013 17:05:09 -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:To:From; bh=Bc3HWKKKWxMos3unOTvoatKbsSsxOmvWrjMZu487XL0=; b=Dm3N61MvaSx70CPFKdxlWA5csOD0PwJhp42Ile9/lx5g7ZnLwL4ItrsMQDlXhpymXy/ej6JQ7kCH5FRzMLIIgr+Xp93pBmiAK92gsjaaSPeBj1aSy8zWIh9QwLzLx1Lp; Received: from [68.4.207.246] (port=1447 helo=HPPavilionElite) by host125.hostmonster.com with esmtpa (Exim 4.80) (envelope-from ) id 1UFSdR-00042Q-6L; Tue, 12 Mar 2013 11:05:09 -0600 From: "Donald F Coffin" To: "'Mike Jones'" , References: <4E1F6AAD24975D4BA5B1680429673943674F7728@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943674F7728@TK5EX14MBXC283.redmond.corp.microsoft.com> Subject: RE: [OAUTH-WG] OAuth Feature Matrix Date: Tue, 12 Mar 2013 10:04:16 -0700 Message-ID: <007b01ce1f43$a1fdd580$e5f98080$@reminetworks.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_007C_01CE1F08.F5A14770" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGXjJ6EmPRtUaFYgrgnwqhStM02KZkPbZRA 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} This is a multipart message in MIME format. ------=_NextPart_000_007C_01CE1F08.F5A14770 Content-Type: multipart/alternative; boundary="----=_NextPart_001_007D_01CE1F08.F5A14770" ------=_NextPart_001_007D_01CE1F08.F5A14770 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Mike, I've attached a completed copy of the OAuth Feature survey you posted yesterday. Hope this helps. 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: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Monday, March 11, 2013 3:38 PM To: oauth@ietf.org Subject: [OAUTH-WG] OAuth Feature Matrix The OAuth Feature Matrix spreadsheet that I talked about at the OAuth WG meeting today is attached and available at http://self-issued.info/misc/OAuth%20Feature%20Matrix.xlsx. Tony Nadalin and I created it as a tool to characterize OAuth implementations to help promote interoperability by understanding the choices that different implementers have made. Also as discussed today, I propose that people with implementations get together tomorrow (Tuesday) afternoon to take a quick pass at characterizing the choices made in your implementations to date. Then we can report back to the working group on Thursday with a snapshot of the choices made, which will help us get a sense of which features are likely to be interoperable across implementations. (Actually, all those who are interested are welcome, not just those with implementations.) I'll create a Doodle poll now to help us choose a time window between 1:00 and 5:00 to get together and do this. Also, stay tuned for the room where we'll meet. Hopefully this will be a useful and informative exercise. -- Mike ------=_NextPart_001_007D_01CE1F08.F5A14770 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Mike,=

 

I’ve = attached a completed copy of the OAuth Feature survey you posted = yesterday.

 

Hope this = helps.

 

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:= = Mike Jones [mailto:Michael.Jones@microsoft.com]
Sent: Monday, = March 11, 2013 3:38 PM
To: oauth@ietf.org
Subject: = [OAUTH-WG] OAuth Feature Matrix

 

The OAuth = Feature Matrix spreadsheet that I talked about at the OAuth WG meeting = today is attached and available at http:= //self-issued.info/misc/OAuth%20Feature%20Matrix.xlsx.  Tony = Nadalin and I created it as a tool to characterize OAuth implementations = to help promote interoperability by understanding the choices that = different implementers have made.

 

Also as = discussed today, I propose that people with implementations get together = tomorrow (Tuesday) afternoon to take a quick pass at characterizing the = choices made in your implementations to date.  Then we can report = back to the working group on Thursday with a snapshot of the choices = made, which will help us get a sense of which features are likely to be = interoperable across implementations.  (Actually, all those who are = interested are welcome, not just those with = implementations.)

 

I’ll = create a Doodle poll now to help us choose a time window between 1:00 = and 5:00 to get together and do this.  Also, stay tuned for the = room where we’ll meet.

 

Hopefully = this will be a useful and informative exercise…

 

         &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;  -- Mike

 

------=_NextPart_001_007D_01CE1F08.F5A14770-- ------=_NextPart_000_007C_01CE1F08.F5A14770 Content-Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet; name="OAuth Feature Matrix.xlsx" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="OAuth Feature Matrix.xlsx" UEsDBBQABgAIAAAAIQBBN4LPcgEAAAQFAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACs lMtuwjAQRfeV+g+Rt1Vi6KKqKgKLPpYtEvQDTDwkFo5teQYKf99JeKhCPBSVTaLYnnvudTwejNa1 TVYQ0XiXi37WEwm4wmvjylx8Tz/SZ5EgKaeV9Q5ysQEUo+H93WC6CYAJVzvMRUUUXqTEooJaYeYD OJ6Z+1gr4s9YyqCKhSpBPvZ6T7LwjsBRSo2GGA7eYK6WlpL3NQ9vncyME8nrdl2DyoUKwZpCERuV K6ePIKmfz00B2hfLmqUzDBGUxgqAapuFaJgYJ0DEwVDIk8wIFrtBd6kyrmyNYWUCPnD0M4Rm5nyq Xd0X/45oNCRjFelT1Zxdrq388XEx836RXRbpujXtFmW1Mm7v+wK/XYyyffVvbKTJ1wpf8UF8xkC2 z/9baGWuAJE2FvDGabei18iViqAnxKe3vLmBv9qXfHBLjaMPyF0bofsu7FukqU4DC0EkA4cmOXXY DkRu+e7Ao4sAmjtFgz7Blu0dNvwFAAD//wMAUEsDBBQABgAIAAAAIQC1VTAj9QAAAEwCAAALAAgC X3JlbHMvLnJlbHMgogQCKKAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAjJLPTsMwDMbvSLxD5PvqbkgIoaW7TEi7IVQewCTuH7WNoyRA9/aE A4JKY9vR9ufPP1ve7uZpVB8cYi9Ow7ooQbEzYnvXanitn1YPoGIiZ2kUxxqOHGFX3d5sX3iklJti 1/uosouLGrqU/CNiNB1PFAvx7HKlkTBRymFo0ZMZqGXclOU9hr8eUC081cFqCAd7B6o++jz5src0 TW94L+Z9YpdOjECeEzvLduVDZgupz9uomkLLSYMV85zTEcn7ImMDnibaXE/0/7Y4cSJLidBI4PM8 34pzQOvrgS6faKn4vc484qeE4U1k+GHBxQ9UXwAAAP//AwBQSwMEFAAGAAgAAAAhAIE+lJf0AAAA ugIAABoACAF4bC9fcmVscy93b3JrYm9vay54bWwucmVscyCiBAEooAABAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAKySz0rEMBDG74LvEOZu064iIpvuRYS9an2AkEybsm0SMuOfvr2hotuFZb30 EvhmyPf9Mpnt7mscxAcm6oNXUBUlCPQm2N53Ct6a55sHEMTaWz0EjwomJNjV11fbFxw050vk+kgi u3hS4Jjjo5RkHI6aihDR504b0qg5y9TJqM1Bdyg3ZXkv09ID6hNPsbcK0t7egmimmJP/9w5t2xt8 CuZ9RM9nIiTxNOQHiEanDlnBjy4yI8jz8Zs14zmPBY/ps5TzWV1iqNZk+AzpQA6Rjxx/JZJz5yLM 3Zow5HRC+8opr9vyW5bl38nIk42rvwEAAP//AwBQSwMEFAAGAAgAAAAhACYa18akAQAAswIAAA8A AAB4bC93b3JrYm9vay54bWyMUl1vmzAUfZ+0/2D5nRjzkSYRUC0L0ypNU7V17bMHl2AF28h2BtW0 /74LiLVSX/Z0v+zjc89xdjuqjvwC66TROeWbkBLQlamlPuf0x8OnYEeJ80LXojMacvoMjt4W799l g7GXn8ZcCAJol9PW+/7AmKtaUMJtTA8aJ42xSngs7Zm53oKoXQvgVceiMNwyJaSmC8LB/g+GaRpZ wclUVwXaLyAWOuGRvmtl72iRNbKDx2UjIvr+q1DIe+wo6YTzZS091DlNsTQDvDS2lNhrf7zKDqf7 OIwpK/4teW+xmLZ9lDC4l/5UkvFJ6toMOUXtnl/lw9x+krVvcxrFUYrzpfcZ5Ln1KDffxen0DnuF PQuEb8yR6Jn990k0jk5M8Q4JYm4PEhN7V/MZYb1Wia66t2QK88Ek3UbzCRj9F+eLDCO5WpnT3zwJ P9yE+yQIyzgNkt0+CnZJHAUfk1NUpjflqTymf1Z7Rp6+MUjJyhpnGr+pjGKLN29s5iHjfHG6yBDl sP6ciWUrrH+worrgf/sGzVE49GpZCHmiMCtrtt4q/gIAAP//AwBQSwMEFAAGAAgAAAAhADsO7qtU DgAAek4AABQAAAB4bC9zaGFyZWRTdHJpbmdzLnhtbMxcW2/bRhZ+X2D/w4AP3QSIJNu5tE0cFY6T bL3oJWs7DfbJGIsjiy0vKmdoR/1D+RP7lP1j+52ZoUQOKWlIyUGKIm0o8pwz534jj3/4mMTsVuQy ytKXweHwIGAinWRhlN68DN5fvh18FzCpeBryOEvFy2AhZPDD+O9/O5ZSMTybypfBTKn589FITmYi 4XKYzUWKX6ZZnnCFv+Y3IznPBQ/lTAiVxKOjg4Nno4RHacAmWZGql8Hj7x8HrEijPwtxaq4cPTsM xscyGh+r8VvBVZELeTxS4+MRXTPXz8VU5KC2+ctpHIlUscvFXMjn7mP/zHn5G3sQTOPsTgYPG3dZ EO/ybBrFLVBOCjXL8ugvrsA5di5AOjjyjuc8EQr8bAB0H5DzLJWixxNv8jxrgX+Z/SGIEAu3/S4S 2XM55xOIEjKRIr8VwZjhnwrLntPfJ1k6jUJwMeKxw0F/IPPiOo4mXR+3PNdk3IlrxudzQNGM3gVU gdMO+A2ONLjmUoT7gpuCslvRC9pKFfVh6ypymoUCCgpjFIy0NHjofXoS4JlkSquESMN5FkHlYcdK TIuYZbn5f+i1/MEbqEPsWUJSiRRIjMr/7UimAxG6mxX5RLBf71KRwzKkvMvykJ3mwiqi6wLWa6ID 2mr3HiBdnPz80xF7JXgOEk8kdIocQF8m/uvDZX9YE+3lrqLQG7vVi+WDUIO8mJBzDUkpsjmHG/PX CDwW5WKiroo88qZBThAg/O8mnfW+m2zF++aSGWRfu/FBkEf2xqvvvgqFnOTRvJPymCe7MJtPEB3l lXYE3gRaxlSf3ZFBGv+VQjiGtzC2EzxiQk2G/j5NfJxD2eRV5G9suZjiiVnr8ceIMiqbZDF7Y/1j I2Sv9y6NZ+G+6867BOrN9DaQJqR3BkXyO+UpUzOBMA7tvhYMwS9kSZYLXMVPGbImfztvo+3c2j5l P70o/DDjisXRVKgoESyS7AZRFERnzCieiV64TOkaiJ/mWcK4PpA/5cSKnois8hgy9oaR3RNYkrM/ kd38QRS2WtB689BK1/kpTRTr/JhG1vPZFDWNY6HjpIhVNI/FAK5Dp+gD8luSff702P/WJ/63PnVv LfEaf3maJdcRpZioFthFMZ9nOayhUV3oqMp+4zHKkPW3rRcZFW0dEom5KYsc0teDR2EY+ZcRPAzB BP9kbz5rynE9Ldl0GkepuDJupn6EHPVm+5O/gkFnr9lplqbIeNjPoA+1hGTmeTxH/77DH/Ivdstj 1NKHwWh8jACDxAqeOEHFpa/kbzPk4vqWUx5H13lE9015EsULc/mILow0MDX+/OloaLUJwKvV79tT 9uzbJ99DMY+Gh/VjqPH56tfPnw6Hj4eHj9gTj9uO6LajLdAAj25r2EMD6RO6rWELkifx0eDapNCt 1P9+hxptw+8VRN9tJONo41nAlS2/bzoi2LmRofT7Jk7q37dC2ETBsy1y0uzfTMTnT99a1WjKqcLl z5+e+t12OHyqFW0IRdpEHli/gfjHWxjXovANpWqw3lGqxu9oJ1G2uK2FMm7ct2r6sAcyQzKToaEW 8zm7i9SMmSTu3AaTZqNpBc5tIW2Cpu9tAqsjqzSX2mDVM9Ylha5cSpg+5Lkg28ls97CUq9E/aFzY JMmkHV61x9hW+EQANa1MuwhuGl26sENm3woG2f2yGXEbcfbj5eU79orLRmur6naPyOk6vFx/cC+8 ZZfxVRYudoZsWxhaug4we4ynB8719eST3E5QXKDU0I0RRZ0naaoONIKZ6TgwXpfOblU34dS5fZh1 Q4vWpkL32T9dXiecHXtB68B6NIXGlz9dsAfUeJfPH7LfTP/eTZjGtjGvsiyWw0ioqW7Gz6gHn08n lDw4At76REMlNj0R5nyqBoR3kJHkB1Uf3QFzA87Kk6+BYrLZYSoURg9iIkcG/+3RYE12Pzi8OhgS Y7wB6nx5AFWidHCQ2HRwLRzE0mffPj1gD34lD8WOhge27+c2QMaG1DV0uuRpsMgBK2BPUeQ3gK7J Xl1wF2BWNC2d509R+kfDdY6rfoNdojiXSSRpfFQ62zpQJK1rMmqTXoAn5gHKn+8vhbaeuJpCfyWU 2TzkK6TMpp5VytT4w4cPg0qQFat06UeM+NATfxuJ2OlIfxWc7ngaMz/7CnV5mVXU5VL1raU7oPjE 0LyjCWbDJaycaHk7xZ32u9cLsIb2qzPkL05dizGr8XuJaTrTwlgOjKQpDpbRwFfRKlL76rj9hWnb wGtocl8Gf2GVafVKdVWhnpNCTYMTobQxObWuLNcojxrr43d+qiK+ll5njS/N3zeXBm9RAtxRvx9j CDbB8F1Sw1/NqOuvtzH0aIhmFP5J+TL917WGaZaiq0b9T5QgTJat0m4QUXyG2V06oH4qWW19FqFn ELY4LecTPRFRtVTOTyl5EuUUijYvqDwh7Cif8wWbL5dK+p6qHzJM3LLOIiFUPF0w9HAjalrzuPWY 1UOFYop+rJ5Ad1MBXf1RJWQXmB7Ih3XZM6o9M3QE8n/IFYf9NQLaQEM0yneauz7VfIdh6QeNhj7y sThgIsngDa1egRNU4K+aN7sDf39+xv6tdWnZq9odaJALHifBSpJ9Tk/qQiyOUtguZj+5WaR6tLyg rfsRVCrEJVlMUZ3QbteVGXjoibjsg5jcR4uuNtJbtATNopZFZZW1sw6Z2X1l6s/Wo1oafJ+DWX0y +LArcI94itbEhkvHYPQuTi8h4SztOMiuW9snPTlG3gr+9kSpPLoulLigtZMEesZErP+LgJU2Ujg9 VK+H4p74zSl13L4P9mnA98SziqOfxDxKNKc0wj2xp8VKV0kDwnXf6LFMIDDMnIiQNkxpCerk3VkZ R/QBsJCQi5tIKtS2po3ZYWduiYM8sM5OKPHRcEkcdnXQgK1uEPZBAcDkSfWWX8Upl8j8PRYRXfMi Va9F4Kw7njKZPWKz7G4H0OSg9gJytR60Yi9i9g1m53E9i6tRr61Xp6Ymd+x8lDa8NkNEIK+lj3tC rLMeE/4q+W5pBhQoIRKdB0EdFpob/qdqMbZEoMfHsikS0yTBkjaNVuArYS5mW1NHGrhHKDQWvimX JYH6oyR1e59S60jLYRLlkyKhnXOsrulj1Mshaz5r3OR9o13rRP0Ra/lpydX8DEE2yWaIBAdbsDby +AMmRmrgRhI1T0OQf8FqOlYY+sNtOrBdwGpStfkYrSn3wEqH5YZbf0bAeXH2S6ZeCXBiyUjjF5ph vBvcFK5RFuIsJQ1dpge7w14Kr53JfeSmGczjG7hBNUtqyoagJqMbr4zGnz2b8UGn88VcuVI1nKsn Uf4oiWsbfccqEbl/h7HCtVcv0bDjAPOWgD3AnyjpHiIpQdblzzItpXYlC2RxDcD483cMtfpB3mTQ xCB/QrUVB+n1FCSlmcKMl6zZUrU0uO4wUxZEXJUMRIwuT9oT5hbLDX5XEV506iGkzaa70ra+xuNn r3vCsz7gBbwIIQ38qeNeZ7Uj/pt0lVpPVA9wrHCySoZUT7zQh/RXQgKuc6JqO+vPApvoVB2i1kl0 jwwL1RZhQWuB9wOfalLoaCf4RLv4qHK+qghk2WFEfopoSCGcpvOrBpftwTAECBhch0zOYVQ71GVz o1a6EU4wtQOyDpKhI3ZbkN5yEtsSaj9K9+xXY6v3TE1SrXebteXUmNUNg99ZDMJ9nMjBpxt4qBbM +tg+EHSQvKm/zB5ZN6OsZhVZanrZemrBcRazKGhOpsNwB70l9my3yDrXdrXEEtoe9XaNlKvN0qrL KctTFDndtJeEbZsR5biEXjdbwWY8vuML2hk0HoTeILk28x+8H6ddHF54afVF3TRiZyqWimONoTN6 09r5gufl1Si64jCixsoKOh/GzwBKIysdx64m4ML7Eo4ISYF1QNqR21zBX+yOja2OcH923MCxv7iw dNv1SFe3zHIMurLvHSLfGozGG+4VkyMpdJTNu4Ulkn0cYnsGqgdyXTNEuDXOAp0tB7ZFnQu8EkwT WZserp1U+asyiWJDSK3jj9JJXNAc1OIvZ3D90dV6ihFOjIE7vbRbfQ3XOfw9IKO4ZSrvksPdkGgt g/XYUGcqEMxfwCm7GkKNWbddunPjo0RbmfRcmBYBdkymke36vuaKl71FMFhThVDsUON/4BasQFcm YrvDJ400FfDKsKoIqJjc+RCu2tf0kAPFpomjRu/PsLYDbQRfnrAbCpLLZgXUHYOdtY6O44lrD+22 rYKCMMp9Fjvm3IN4Skj9JOFq73ajLPFQjtzbMBEwcjGP+YJmQg4UNs8F3uLGG6r+SlUNCzX7MH76 BL2J9GI5j6/GBge5P8raEbS69qB7aW+g03QY7Joe2EJ/bxCORi46tqHLM3+yCaMmncbRuZmaAFmt Llr22ayNdhCEBU+010AuU2WfUsusxQGArvf9z6aV2dnlCjN08+ZxtgDTVpkU6kd/sHSmMpJs9lqO MunVsdYVE3/k+kwm4ENHqO7VUInB1lbLgOnCHNMLG28u3p3V94LV+H//da+Yj7a4V09i/WGLwXt8 oMZZxzk3onGfuMSHF2J8Zqjcq4GLQJaSR7BnFrwq4j/wha55iBZk4zWj/zQv/ZK54BP+MUqKhHzG U5ZEKZZsGoAuaV6dFPiOVoIvhena00yaKw1XPH9+sWTjmzTUR3Sx/czTAnP/b3gyf8FeL1K8XT1h 53qNw9iN+4CV9DexejEYfHOjXrCTC3axSCezPEvtV77cZ+gLSLoNbCzxtYDM6ENF7n3mjRn3Kvit 3SgmvZSN6q+bhOxEf7DFvDTqPgE+v8Ah7NidNkqgVbR+qvscegqw6fELAbWjj++w17Qyo6MZe51h 2N5Cs3a49H2oFiLYYMBGhplQLsNj/P0W7/y5d5NB4wXkET4st/pphG/Hjf8PAAD//wMAUEsDBBQA BgAIAAAAIQBwsUC9agEAAMEFAAAjAAAAeGwvd29ya3NoZWV0cy9fcmVscy9zaGVldDEueG1sLnJl bHPEVE1PAjEQvZv4Hza9dwsI+BEWLmrCwYvi2ZTuLFvptk1nQPj3FghGCAYwBI4zTd+8NzNvOr1Z ZZIpBNTOZqye1lgCVrlc21HG3gfP/I4lSNLm0jgLGZsDsl73+qrzCkZS/ISl9phEFIsZK4n8gxCo Sqgkps6DjS+FC5WkGIaR8FKN5QhEo1Zri/Abg3U3MJN+nrHQz29YMpj7WHk/tisKreDRqUkFlnaU EGVECkbbcQSVYQT0A0vOGUw1ULGkWVJlRB5kQXyR405OqOQoK9PgQ5ABwhrhxeWR3NOMIFhpmNit 4vaUKnzQNpZ7A6I4JlwzyViaiq237bieDrX9i2TjlCSPa3UoVPu2FZdvNZbDmlq/MN/m/XF82+fh u3CdzlMLJNCDQrFKcOWsBUW8AsRoQeT1j1q6WPTjVLQupWJpwWmDVxND2hvgAdDHAwScoq3/K6d5 HjkH3ZfPL9p7XcTG4e1+AwAA//8DAFBLAwQUAAYACAAAACEA2n3icqgGAABbGgAAEwAAAHhsL3Ro ZW1lL3RoZW1lMS54bWzsWc+PGzUUviPxP4zmnubXzCRZNVslk6QL3W2rJi3q0UmcjBvPOJpxdhtV lVB7REJCFMQFiRsHBFRqJS7lr1kogiL1X+DZM5nYicNuVz0U1N1LxvO958/v2d+zx5ev3A+pdYzj hLCoaZcvlWwLRyM2JtG0ad8e9Ap120o4isaIsgg37SVO7Cv7H35wGe3xAIfYAvso2UNNO+B8vlcs JiNoRsklNscRvJuwOEQcHuNpcRyjE/Ab0mKlVPKKISKRbUUoBLc3JhMywtZAuLT3V867FB4jnoiG EY37wjXWLCR2PCsLRLJMfBpbx4g2behnzE4G+D63LYoSDi+adkn+2cX9y0W0lxlRvsNWsevJv8wu MxjPKrLPeDrMO3Uc1/FauX8JoHwb1611va6X+5MANBrBSFMuqk+33Wh33AyrgNKfBt+dWqda1vCK /+oW55Yr/jW8BKX+nS18r+dDFDW8BKV4dwvvOLWK72h4CUrx3ha+Vmp1nJqGl6CAkmi2hS65XtVf jTaHTBg9MMIbrtOrVTLnaxTMhnx2iS4mLOK75lqI7rG4BwABpIiTyOLLOZ6gEcxiH1EyjIl1SKYB F92gPYyU92nTKNlqEj1aySgmc960P54jWBdrr69f/Pj6xTPr9Yunp4+enz765fTx49NHP6e+NMMD FE1Vw1fff/H3t59afz377tWTr8z4RMX//tNnv/36pRkI62jN6OXXT/94/vTlN5//+cMTA7wVo6EK H5AQJ9Z1fGLdYiGMTQZGZ46H8ZtZDAJENAsUgG+D6y4PNOD1JaImXBvrwbsTg4SYgFcX9zSu/SBe cGLo+VoQasAjxmibxcYAXBN9KREeLKKpufN4oeJuIXRs6ttHkZba7mIO2klMLv0AazRvUhRxNMUR 5pZ4x2YYG0Z3lxAtrkdkFLOETbh1l1htRIwhGZChNpHWRgckhLwsTQQh1Vpsju5YbUZNo+7gYx0J CwJRA/kBploYr6IFR6HJ5QCFVA34IeKBiWR/GY9UXDfhkOkppszqjnGSmGxuxDBeJenXQD7MaT+i y1BHxpzMTD4PEWMqssNmfoDCuQnbJ1GgYj9KZjBFkXWTcRP8iOkrRDxDHlC0M913CNbSfbYQ3Abl VCmtJ4h4s4gNubyKmTZ/+0s6QViqDAi7ptchic4U77SH97LdtFsxMS6egw2x3oX7D0p0By2imxhW xXaJeq/Q7xXa/t8r9K61/PZ1eS3FoNJiM5juuOX+O9y5/Z4QSvt8SfFhInfgCRSgcQ8ahZ08euL8 ODYP4KdYydCBhpvGSNpYMeOfEB70AzSH3XvZFk6mSeZ6mlhzlsCpUTYbfQs8XYRHbJyeOstlccJM xSNBfN1ecvN2ODHwFO3V1iep3L1kO5Un3hUBYfsmJJTOdBJVA4naqlEESZ6vIWgGEnJkb4VFw8Ci LtyvUrXFAqjlWYEdkgX7qqbtOmACRnBsQhSPRZ7SVK+yK5P5NjO9K5jaDCjBp41sBqwz3RBcdw5P jC6daufItEZCmW46CRkZWcOSAI1xNjtF63lovGmuG+uUavREKLJYKDRq9X9jcdFcg92mNtBIVQoa WSdN26u6MGVGaN60J3B6h5/hHOZOIna2iE7hE9iIx+mCv4iyzOOEd1ASpAGXopOqQUg4ji1KwqYt hp+ngUZSQyS3cgUE4Z0l1wBZedfIQdL1JOPJBI+4mnalRUQ6fQSFT7XC+FaaXxwsLNkC0t0PxifW kC7iWwimmFsriwCOSQKfeMppNMcEvkrmQraefxuFKZNd9bOgnENpO6LzAGUVRRXzFC6lPKcjn/IY KE/ZmCGgSkiyQjicigKrBlWrpnnVSDnsrLpnG4nIKaK5rpmaqoiqaVYxrYdVGdiI5cWKvMJqFWIo l2qFT6V7U3IbK63b2CfkVQICnsfPUHXPURAUauvONGqC8bYMC83OWvXasRrgGdTOUyQU1fdWbjfi ltcIY3fQeKHKD3absxaaJqt9pYy0vL5QbxjY8B6IRwe+5S4oT2Qq4f4gRrAh6ss9SSobsETu82xp wC9rEZOm/aDkthy/4vqFUt3tFpyqUyrU3Va10HLdarnrlkudduUhFBYehGU3vTrpwRcnuswuUGT7 1iVKuPqodmnEwiKTlyRFSVxeopQr2SWKvIRp2sbbFIuA+jzwKr1GtdH2Co1qq1dwOu16oeF77ULH 82udXsd3643eQ9s6lmCnVfUdr1sveGXfLzheSYyj3ijUnEql5dRa9a7TepjtZyAEqY5kQYE4S4L7 /wAAAP//AwBQSwMEFAAGAAgAAAAhAIeyoInYAwAA2xEAAA0AAAB4bC9zdHlsZXMueG1szFjfb+I4 EH4/6f6HKO9pEkooIJLVUhrdSnurldrT3atJHLDqH5FturCn+99vxiGQvb3SQkvVF7Adz8w3M57J 50w+rAX3Hqg2TMnUjy8i36OyUCWTi9T/4y4Phr5nLJEl4UrS1N9Q43/Ifv1lYuyG09slpdYDFdKk /tLaehyGplhSQcyFqqmEJ5XSgliY6kVoak1JaVBI8LAXRYNQECb9RsNYFM9RIoi+X9VBoURNLJsz zuzG6fI9UYw/LaTSZM4B6jruk6LV7SY/qRes0Mqoyl6AulBVFSvozyhH4SgETdmkUtIar1AraVN/ BKrRwvheqm8yx0cQwO2ubGK+ew+Ew0rsh9mkUFxpz0JkAJhbkUTQZsc14WyuGW6riGB80yz3cMEF c7tPMHANF0PE0aDJJnPc9Ua2XsfO4/Cdy+cL1Q7+me2snkhJhEl8zfyzrsEzO4fn7Qd7b3C+j7P3 J/Qu7F8Gw1wsiTbQo1wtutBsj5/7M1BFjPNdTfewfGEhm0BvsVTLHCbedny3qaF4JbRBVBw2+57Y vdBkE/eSjoCTA7tzpUtou203wcbRLGUTTisLFjRbLPHfqhp+58pa6FHZpGRkoSThMAxbie0A1BaU 81tszX9VO93o1bry5Erkwn4qUx+aPLaQdgg+boeNvmYC+h8TSkD+/4U8Utd882Ul5lTnrvM7a24V Y7mfTZ3/+/lHzhZSUOysAM8JfNXK0sK6N5OrmbDrXeNrx8346iQ/vXX1pMMYsEccbqUbyB0vMKPQ 2RunvKXS7DvEHF8JmF/f+6ZJfUfX4K+roHBdPR7wM9jH4/PGJpFnWFZgCOBMHxeB+LkZwBcxhvR9 5ONN0FweG5sDpd1/RV3nz9kLDtSzS+rkFL4A3NGRO5DRA8266V0n1MoLXBsce8COKOQCXh9UH9dY rt4ZHrhvPe9Vc8K5fG/xOf5FeGK2Gupx1EE/FCvHQ4B5dOjWD2RrR1M8ZPmp/xswR82ZvIcroyMb gGS+YtwyidRj6IhqS9y2Ml+QPfFWALpVR+A/ZAhwlOs93XNPLd6BHRHcIQMdJa3Iitu73cPU349/ pyVbid5u11f2oKxTkfr78WdkpfEAIQN5+WzgIgr/3kqz1P/7Zno1mt3kvWAYTYdB/5ImwSiZzoKk fz2dzfJR1Iuu/+lcyV9wIXcfDoAxxf2x4XBt11tnty7e7tdSvzNp4Ds+DrC72Ee9QfQxiaMgv4zi oD8gw2A4uEyCPIl7s0F/epPkSQd7chr2OArjuPnqgeCTsWWCwtFoc9VmqLsKSYLpASfCNhOh2X2V yf4FAAD//wMAUEsDBBQABgAIAAAAIQDkXKwH4BMAAPN6AAAYAAAAeGwvd29ya3NoZWV0cy9zaGVl dDEueG1slJ1dbxs5sobvD7D/wdD9xmLrO4izWGkwOAPsARY7e85eK7aSCGNbPpIymeyv3yKrSNYH 22bdZCadt8mqYtXT7FaX9OEvfzw93vx+OF+Op+e7SXg3ndwcnu9PD8fnL3eT//3nz39eT24u1/3z w/7x9Hy4m/w4XCZ/+fin//rw/XT+7fL1cLjewAjPl7vJ1+v15f3t7eX+6+Fpf3l3ejk8w798Pp2f 9lf46/nL7eXlfNg/pJOeHm+H6XR5+7Q/Pk9whPfnnjFOnz8f7w8/ne6/PR2erzjI+fC4v4L9l6/H l0se7em+Z7in/fm3by9/vj89vcAQn46Px+uPNOjk5un+/S9fnk/n/adH8PuPMN/f57HTX8zwT8f7 8+ly+nx9B8PdoqHW583t5hZG+vjh4QgexLDfnA+f7yZ/De93w2yY3H78kCL0f8fD9wv7/5vr/tOv h8fD/fXwAAs1uYkL8Ol0+i0Kf4FDUxjzZf98uPnx6wu4kTTX08vfDp+vu8PjI8wwTG7299fj74e/ g+xu8ul0vZ6e4r+nJb7Coc/n078Pz8mGNFW0Lo4pxTgIDroL85gh/598SH8BB26LB/z/szc/p5T4 +/nm4fB5/+3x+o/T9/8+HL98jSYvIMQx0u8ffvx0uNzDEoNj74ZFNOn+9AhDwJ83T8eYq7BE+z8w FMeH69e7yXr5bhWmm9kKRrn/dgHn/oX/EOh0PBHCkE6E/37Hf4ewv3bCjE6A/+YTNjFkP2JiBDj6 6XC5/kwhtxPfouEpJj/tr/uPH86n7zeQ7eDBBaILtRPewyjw31W2A2OUJBiXd9GpdmggJnG0v8bh 7ibLyQ3E7ALJ8PvH6Yfb32EF7kmxtYogFTtUBIhHGWSYD0V0C5YX80HEzX/duCi+m8z5uGXUZP4W FWmlxTQxMixKr0+DYQQvivkbNQ0qIJhFsZxJyY4GEcbOq0hYB6J+66L4bgLDl7mDXiKUjJgnZgZN /8xRDAXCZp5Lp7eosOGHfOqfJoqVgyrDtigZcTBlwg4loSv+UDH95kWxMq/mNmYhSkbME/GP2OvO yyhWM9eEwplR0jNzhE/3zFEsV15PjAq78gH2Av3zJLVyUecYaYSPSrMjTd/qh8ir7lAktTJxtlJ1 QCK84kSu7uhIBH2p22G+KOeJrIjodFiE0OMjh2UZGPMijXg3EUEbmzySqz8cUf1mOFDUyA4X+eJy 6rlM5Bvsq8GQUYZoOByN6jcdRVHDURcBQwOBa72iDQaqYOxonM4ycFEwNDBoyyCDMG68sAzwiCqD sQVy0TE08Kiv26QRZVADK7PDBciA/BM1aMMxBsnBBcmklpk46B0AaYSjNRjC0cGFv6SWkwfjKIls GQwusCW1mmtRlwvJRiLu6apGQ3rqItuA0IKsKsCuxKS5x7g2uLiW1NLPQe94SCPcVJodafrKHW6H HPRLamWi3vWQhl306Iiq9nqxlqvjQuTQQOSiZjitT2Zk4Q+dJi1a1EBKi1xEHCwRB71LIo1YRRXG HWk6V9GFyMEicrDFiyK+jHhEBm1eLzYyaC5uDpabw9SUGeMmXkbotD6LZi66JrXM9LCsQMHEIpEF 3MwF06SWcw21OmiqOKLcua1UWu1onL6Uic8p+rc9SS1NDBsTDtyBspSh0+IGpNBzmFd2i5SZKS7H hxUxwm/cpSN84c8yQ9jUSqboMUJj6qTJ4JkIr8FhUT2Slrk4PrP700HnMmn47Cu15DvSdC6ni+Oz qFbLuTRBQxFfTjwi621RySWD5gL5zIJ8mFa20DIakNNp0qIxJs1cIE9qFaNN9ZUsQtrzGOERZdFY yru4PbPcDhsFgS2JuEUebs9c3E5qHSOVx1sScYuQ5H0xmru4ndTyGUW9rcA1I0myR2Ts3EXtpJa+ D2aqBrUVCnY0Tl+Zz13UTmploq4p0rDVoSNqdeqqypgpaL8O67mF9bwOTMtjWE1nKYPqLk8a5GL1 3LI6bNQKbUnEQ4SnKYtGinzuQnNSyzULG5NXBs10WqdFLjTPkbpAkXKFNUnEwCxXw4XcObITEqDM NNSgUnpk4lbNSoVnR+N0lpSLwekTKr08JhxIXJ4wTQZX32TQXAyeI0xF0GptUNBQA1lTAmuDRlCG 1C6iYeyjioULykmtgrbUl1ISsaDREZnTi3rBE0FbuOCd1NKiWd38YdBI82rQSNOXaQsXvJNamhj0 x0tbEvGg4Sa8M2iRtd0PeRdIZp5pYVNzmKKGIm4RHpEWjd0ELFz4Tmp5tTdbNNIkg2TGuLi8QORy 5819PWlExig27EjTmTEuUC+QwtJEsz4M1WnFdnSaWp9qtwyaC+gLC/Sw0XAiEc8YPE1ZVD2RFrn4 vUAQw58FcuZukTSNjHGBeWHBPNP3WKQRGaPisyNNX8YsXWBOasmYuTaRNGx56IhcnjEuL11cTmpp 0ExfKEjDDcJttjSIbSxFvixdFE5qaRC8bKQ+hCERt6hF4THmLSMguymc1NKiWb0mIoRJw9NqrYze kaYzrVxYXuL2mIMozGr5ko0o4kHDI3IZF/X+QC5j5HF/0KJaBa0OTAahRgRNFcNuiZrOoLnovbT0 Dktjo6E3naaCVhNCBs1F76Wl90zfG5FGBE0V7I40nUFz4XyJOOeZZp6IkIYnGp4lYzbKCxf0lxb6 bA9NiYYabhAekQaNEXXlQnxSy8wfpiqttyRiFtERZVFdfZFWKxfjk1pbpHJmSyJuURPyI9uUlYJ8 37PkdJa2rJYSrh6JuGUEe14Ew6LelMpYuWC/imq5wdUcJUmyR87kYvbKMnuYavyQiPveYvbYhS6+ d9jP7KSWvpuPHEjTcN7F3pVlryEdafgir9Ra7EjTR7qVC8ZJrXLTpCYCW5hYCySl747GARPjy7X8 HcyVi7xJreyZ1pynWkHQNpbHBdWVhar5gIw0wnezPIRZyNmy+x99xLF2YTapZTjCTO3ktyRi5UNH JGbHymftwmxSS4uGqYrIlkTcIg9m1wqzrz/9TWptkYkRwpRbRHjlF/lh7DOetQuvSa0sMq/Rkohb hFTuXDUXhtfIU6ibkqFrEyLUJINEBa9dfE1q6by5PyWNqCplzo40fdBbu7ic1NJE9gY5MoY0fHmQ 5nJ5xnZTaxeFk1oaNAS9myIRtwjBLC0aLXMXh9eIWF4c5naQNHwVze0gaTpX0YXvtcW3vR0kEQ8a 0Zq7NozdDm5ctE5quYwzvdchjQiaWukdafqCtnHhO6mliWFZ99+Y+yRiQaMjMtPGcn/jwndSS4vM Jok0Imhqa78jTWfQXDzfIJhFxpibHRLxoOFpKmg12AKyGxfPk1oGzdwPkoYbhIRXBtXtnjQIot2/ q95EtTRoCGqJtiTiFuFp0qIxgm1ckE9quc9f630KaZJB0nkXvjfIYZEfoYaVigpF3HkPvjcufCe1 dH5jSISIbzjvwvAGeQp/lq2F+aibNLx+9YfPO9L01W+YusCM8ruJMFLdwmyzaMRKkR9h6qIuytX8 OhmzSMyvd0VZBGHSN1ph6uIuyqVNEAL1DDqrbJaEacRb96NSlOvp1JUP1gCZ2ZrOBcgwRdbxmgRf jHeo4iFf17tNteSg8vgb5ZKI4J0xAFXCgJqYygAX/8IU96tQ5aUwZ9U3hFIWteLtQmCYIsx4hZmX f7NIeKtCAt1VhEVYmmL46O10mLq4iHK5KkPQZMyqFJUUKLAKadl3pYIWX1+uRLmsjbmtRBTx4K1U QoOZKOqkqLN/jhrfYIqyMMHaWVroynvxIXfM8WocfWE3eFvm8NGCtMqAhTfNybJy9sNRsxt3JZi7 x1Ba4lgQmg8c6lVAWRVB2E/XmJcqg8xHY4FEPIPWKvehlRBH6s0gH5XjqBqKdUNMTCIRrz46JKuP deuo2IGHnthFuWSCecYW4ivdIBJG4SFp1NjmNaR2OceCIr15mg3BhgpVwio81GuVj/LUmMdrbbDt oKQSVhHUhT+spUYtoA/q1HjHr3Tshj5nFQI8GaVmi8x0rEyUS1ibN3QDtexBhhRUmjfxs6iz1Hx9 fIGa9PhSsY5gCkqjk2+tkmyXRwIzzZbT194XqHVP2GS2JKW/r4ZurIcq+Fr+UC6Xjj3xzTFBTvOl G3vSEVIbX3/qUNef8F/t8Lc4puzJGZ/fh1/q4RPz1wtQ9h8Z3ed/RKDD/yhX8bf+o6hv/gg7x/zI Ru4/a87J/memsvyr+yyJjtRO55gfKShApcoN1h9FDVClDjvHbEg84a2ttozF6i17h1Z5C0N5oh3l crUX9d4mRxtFfLVH5/f12gXqoxP+m2wvzXYd/vv67wI1zon5TbaTqM9/3w0+tcnx+U2vYSBR3/xx a9iff9QMJ+Y3+3IS9c3vox11uvH5w9IUQOmZqzv13CInNys1dWVVpK43FhVI+Xi/g9+yxL4l6fVP MQM1z3E2wEMM/bygqJi1ELs458xenlMfGzPtLROQfMJtuxMuPXXMBDxR7jlZrqmA+facrY4587Ab viYgRSEFIaFllw/1WhVB6IgVclMsl90Jl946s3PydcTBh/7kXsVUYK+WEUxbqlDzNscFx5JxYfsg uVq+Rjl4HtAw1FzjWqqg2Axf1YZjKUOrTBnqeyTbaLQLc0OHliooiIOh+Aii11AfxqlxTmSa+UoO eARR81/FxUftRjNdYMlBmdZSsa+VUBb4uN3onht0Fm8h+0cdjkDMlQxheYN6jda4QeciTIeU5WyE 25mCZ+Vw5KHDggZ3dZKBBVllWJIa0xzT2V0o3BkVV/IKM6Aq7zgpO+KLpBSRY09J8nQNFeuEURZE gjkcbsFTFTHEN6tMfEVb2tsOt/rS7G1GSzWaUKINrcMC5BEP+WCRUbrVrMMwhSO+rZ4ydstOK9xS jTvModXhcJTLR3gDGztbkFXWYU6ojukye9jVeKmus9tALWKNfVnq1urPX2rukleAehnM3mVCWe98 OGo0fAX2dQx5uowjFgP2HEwWbGrGcjic2cPGXlqHs8o67CMUdWbJcjFALCo7nQ9HjQ6uwJ7w5Phm HLEYDDXHZHxFf9bb+dto0ApLA8SiMg6L7quO6Ro4sp8blSYtOx1M4cAR9U2JcjEvr4XSgmWn87Gn 0TkV2JeE0XK2VKwHTS2nD0eNxqjBNNxB149hJNz9l8u+ssC3h6IGJl5BYVV3RzkGo4RK7Ub9fGg1 NenPQrdwr08O2xWO5HBMl0HDSlF/TRJM11CNx9dHqEZDUtCfJ4AFcVB5FXxlhX3QanQghZW5r2up RmMgOo7epkir5YjtECnHGqrxGIgOow4LGhxj3mULssqknWgf6pguYk8u52AaFEKju+gVh31ooyYg XtaD+dKpUFTWYR/HWs1CFtwN1SsO+zhGjT/c4aC/0mILeT8GltSp0w+WRoPQYN4YBgNMHrzisA9t zf4f8xSkqOwK+zjWaO+BbXK5BuUK8nAsdeg4Qm63VQPbtmYLsso4LPp33q7hRgPPwHZxNF1R2eki TPq9a3TnhFXdNObpMqHY9Yy9GiZ3AqIZp8NhC62gG9q2odGzE8Yt8EGLGmsgh8pH7/BRjM6x0qNj Q+6DFrXWCGQszIWxpRrqjluF3AetRsdNWNWx86KPQks0z3SssMXRYL5PKZQeGxtfH6EavTGBdcFm 71qbr/oKnYqvD1qNXpigG10gpTO0rMO+nVajr2VgqZIdHiWU6Fl5ezmp2USWi0EyqRrPMkT/Scd0 DfasTXW22lRYV4hcTtFv0mEBSNS2Cnik+dBoS4GP6IpKWeAjVKOfJJh2PPgORmvnuAU+aDX6R8Ja vYm7DS3VuAU+aDUaRoJ+GREsyNDiLB9dhQim/mslNX8IcOuXn8ACS7tX8sCHtlbfCIsvVXpD9YoF PrRRn4iMgdn+FZVBW2racIQ8Q4stp30lhDpBhFEsLKL04FtzPIuOcnVPZb6iraq0w/AdF77pLO0G sxfBQaNRdrrIqu74DqkDRHoX1nr711SNxzdSyGFBlGsL9JPbgbo8OlfYhTb4dgmyAIKJFSQOqexx QQu+PDyNLa6V5qXcrGotp4tQA3VwxFfX61bWfoE5yUQ0WfuZ8tiFKPiy5OSxMkETIsukCfWqrkxQ jOr7FhX4loGWKTa7USZMYU9NlCmurdmQuyvkgtj0bmCOPTaRJqTeiP4Cy60U0gS92x9IJqLA+jGV CZFSDhOiHF44EiaY7zeABvYkkybUjaUywQe60oRRi5wfUmODCR73opxoTACJL3bkQ2psH5yojyGh IY/NeKXG9sGJOhTE2Hn7ZC4sohvhzT0zvONfA5DtZoeU3T7ElB/7YWuJ1GkQNL3q70jVDAM2Njuk 7PbBoPwqDxs7F76Jt3h5/+1403v5fC35IWm3eAm/Y+xcl9VueuW+EW/xgn3H2CDJhUJ5Un5nx8bE V5f08ryIyWhdpjfd+/OEXowXY4/WZfrhGcfYrAhzTNghtZa+HQL94kz6TdY8NtZlOqTG9tUlvYcu xsa6bI0dq8oREyxCMTY7pOz21SX9fIsYG+uyYbd4pfzt/Ka3xfnY/JC0W7wu3jE21qUYmx1SY8dC 6483veUtxsZSZTHB38TF33/9+uPlcH48Pv8Gv2db/p9+BjjtS8/vjw93k/MvD+mXa60EMqVI0hxW AgteJKnyrATWrUhS+5GRxI1OkaSeCSuBKBbJMt1kFQ2497L/cvif/fnL8fly8wg/NRx/zjdaj7/3 m/4ffqQ4HYWyxZ8kzn/7Cr8WfYBfYJy+AxJ9Pp2u+S8Auzjur4frt5eb0/kIPxOcfgD6bvJyOl/P ++OV2bRKNpWfq/74HwEAAAD//wMAUEsDBBQABgAIAAAAIQAURdmXVgEAAG8CAAARAAgBZG9jUHJv cHMvY29yZS54bWwgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACEklFPgzAUhd9N /A+k71AK2TQNsOiWPTljIkbjW9NeNiK0pK0y/r0FNmTRxMf2nPv1nJsmq2NdeV+gTalkikgQIg8k V6KU+xS95Fv/FnnGMilYpSSkqAODVtn1VcIbypWGJ60a0LYE4zmSNJQ3KTpY21CMDT9AzUzgHNKJ hdI1s+6o97hh/IPtAUdhuMQ1WCaYZbgH+s1ERCek4BOy+dTVABAcQwU1SGswCQj+8VrQtflzYFBm zrq0XeM6neLO2YKP4uQ+mnIytm0btPEQw+Un+G338DxU9UvZ74oDyhLBKdfArNLZnbQHJTvv0bWs SpngmdbvsWLG7tzKixLEfZdtlGSV8LbeWhVFb/9tcfShzPgECM/Fo2OZs/Iarzf5FmVRSGI/JD5Z 5FFMyQ2Nlu99gov5Pu54UZ9y/EuMfRLlYUgXEY3iGfEMyIbcl18k+wYAAP//AwBQSwMEFAAGAAgA AAAhABPUK0efCAAA1B4AACcAAAB4bC9wcmludGVyU2V0dGluZ3MvcHJpbnRlclNldHRpbmdzMS5i aW7smVdYU9kWx3ciRYqjFEWKFAEBBwgqAqKXqHQpiSRBvAaQCwEDSDIJSDVwEQekKghRCUgVEBEV KSK5AUGaDkWlRBCigMAYpPd2E3RmnG/uy7x6s8+3z1r7f/ZZZ63f/vY5D8cCIIEiMAE4QAZewJNj fTljM6DLOXQ4hyJHxwESwG/MAH9pED4g0AsWdhmvhwlCAAT8KkzY7MaxmyAOUCjHfjlbb8T13Yj0 lxB/W4B8vQPKsdzOHa9z2lf5d2NiaYvZDdqA6Ca2zN2eqGe/X/gfjuA32m/xv5F47v8BgW/XvY1T L8oGfYJb9jZQDf7uPrH0Ifr5Hsf7ADOEnQ0KgbEzNgV2pigTa2uA8cGTcGSuh3Qh4kgofBAOWJui 0aZ2AEHC43x8XXzxBB+ARNih7Y5ZooEdjkzw9tvQ9HR03Ih4YEzwJpBsCG64L95+XWCBROHPE73x 7nicG8YSoEl+OG7mfzS2DACWGKQFBIgDhfwDfM9gVsYZnhc3q7e9VnLgbCJut+JM53Z7CQD2SwPA 5thGjv2Wyx8R/+xx5+j7bwLGhlgkieBBcjmvaIb3xpGxNnhXEoFMcPdVRLi7411x2C9mny7W1MHY 1Frb1MH0z5F4Ix6B74NAlQAAjzldXggCAt6OpfUQJDFyDaEl5TtyH2PflGErw67vPjH36jP/0CvZ trpt0cn5dTuVtxfyWce0L0C3Gu28HbLfqBGeWbxnx2y7oHOIWSzE1cJBWcb61pv+m4u/sJmj0oaX z5fSxj2me/pv3iwpKfHwgJPdPS6kRBnaHpJ8QE/ORzUrkKuaTw4i/eaaF8TiD6IVnIQ91/Dpp+BU AjkkTeWuYR+ZdG3thFjREG2gIjU6PeGfZbNyF/FZ72gMVv4d+hAmYf3KCy3aj3Jdr/u8kLWO0lmx L+EvLkt43lDzPuc30tqjf2mxy8j3Y8Fcw8kxjZJSqzE7a/mP9o3jzICDmLTUBEXLrbtKC39g7KWM zUxnPgk1OES9hDHf3kLMwVVY9SHN6w9lWlgYzEdFKNF2JpBTFippe1rH18NLnmUyYE2qZal3gyPH P5N6309tC41uMDAbFxNaInxIi+pqvR2kJjfvWazST7+eH3phZc5uAH218R5KdjjyvsxUevAaEVGB obcOF+WU91JWz2DTJ6gu9+010+VVlq5lJys3HBOUHZjSD8J6ZjK99A/ovkgofngYvhsvJVwkuBSc inXDBVwaiNbs337lwH6tlScIyyeOObY/t+KP35ltmtDcylZELNBpeYf8yWvYKWpi6NUQYz1Jzz1N 11NLHhUhYzp66gm16u1qNNRKFYOmEvTpR0q3iEn/9MyA1g//QCT5XiMk6dqc7hMfy4YshU2FpGZN H6kTqUWhF3fHtYs6ZpBnDKl5Fb7p8ZOrolsnQ0Ydg5K8WtqW0R+1mEZO4eSQ6TzrdmajRpIY6g2N fES1FXUn8CV/6cucviXNtI8ep6x0Rn1s/u0ol61k2DS+GujkWnXQP7ykfE945G2XNTZjOMiSvlyt 9yad6fHWrONdQEuLQKCqYeKuworXW261qs+nohVwt8qPF7cbNIjpRl9WaeOrHolIkjM+JylimSV0 NEdCoF19R+JxCZAtYfaez8oyWyisXUiCCKUBVsRViYmLXIfvnVDtOUkDSLXQLQmiprgtIIZ/jsj+ TYnPPMniA2qsiktDbhvRqe/5uHOV1GIzTmrm8NuAWNsAsdWvGoumKos35T6u/idNcc6LoeBT7WIX ZrI4l7Vu/wpue1NozONxs2unBcVkKjux64RPUpUt6ekR88jB2UR9iz71wKTBBhW49qJQU1riUxV/ qz7NwJjBosHVHSGpVXfkA216jM+znLdpfx6vL/YLYBLKKXvtaugUdWDCmF6a9De/uNNLoI1euVM/ lqKRDYGsQHdfCXZi+mU7R587ChhhFh/SE/41ZwXZshnKGKmGHRWbN5grNmOIZkAgSzDFxIqGutAD S7nRAnzaA5YzztXHO+vuzV84k+0sgGWg28KqHdX0/GpgZ5Uc9326WK7UG1owYfgGsTxqEKl/PSlz f0+e+HWrLQNWdvfhwssOW5UnRJC+xRnOLMkF/u7nH3HzIkuaEyIPkrVesKUM+CmQuUelTZSaeS1A gRj1pLTDiMIrUPadvFHKsdv81bBq5eWjFA1ZRmhBQgFf7l09I0aGezqBUsCKFyy8NKmyAs1irgFK E2rSqCWgSX8mKOR2hCNZLuU0hrIoOTwO3XQ4pWMjorf78MUl1bfaIw+rYRMiE90dOWsic1dYUgv8 EaPnKzeSo0Dkn6bOrW6ktwKVGQ1WZIjqysW16ItujzUv7GgzOXvjVZYAtLAWZt75jFN9cEoNTIeT LAM8R9nMiARxqlqB+s7pPYf5wVkKVuyZGGhXP7/LhyXWPaz6HrEj2sNzZoC4maO5f3A65l/2yyCV oqsY5nxU5ad1yNnm7tCaWTpnpbKYCiVOGoNU8dQCPkbYZkbAJ8H/xJWkeQwENbKoJKLJW9m9fKps feZn6qNg+g8r8JSxI1IlfchG2Mh6+PPV8LWYMbmo04S6ttACXdrJ4bgaeF8tzI/BqrxcRtZxp+9b 4NdkwroRZWnG+z7Rw1eVH7gxznq5Ho507Xz6IGM9K14+ObwfMdw70AEoBcu5YWsxs6L198pzex6H ojvm4u7WbD9bpdRd785Nq8X5QVrmjVlb6Zbi1+sPxValFlTZ1L3xiDOtxJdBgrHDDNGoM1Vepu97 pRYuy5TBRxjdLRYvg9REKQUCp/KnfybqilPwbAZr2bFHOu70eI9fHEWjkk6FymxjzZtzdow97UK8 ZEexbHJns3TRvbXh9n6Tsbbm1nNDRkW0jublx1M+Rb2Fyf74obzSKduilRz7zkWp6F+Flb+PrzCv Ch4BHgEeAR4BHgEeAR4BHgEeAR4BHgEeAR4BHoHvjQD3H9R/AQAA//8DAFBLAwQUAAYACAAAACEA PAIw/oEBAAD+AgAAEAAIAWRvY1Byb3BzL2FwcC54bWwgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAACckkFv2zAMhe8D+h8M3RM5bTAMgayiaFr00GIBknZnVaZjIYpkiKyR7NePtpHF 2XrqjeR7ePpESd0e9j5rIaGLoRCzaS4yCDaWLmwL8bp5nPwQGZIJpfExQCGOgOJWX31TqxQbSOQA M44IWIiaqFlIibaGvcEpy4GVKqa9IW7TVsaqchaW0X7sIZC8zvPvEg4EoYRy0vwNFEPioqWvhpbR dnz4tjk2DKzVXdN4Zw3xLfWLsylirCh7OFjwSo5FxXRrsB/J0VHnSo5btbbGwz0H68p4BCXPA/UE plvayriEWrW0aMFSTBm637y2a5G9G4QOpxCtSc4EYqzONjR97RukpH/FtMMagFBJNgzDvhx7x7Wb 61lv4OLS2AUMICxcIm4cecCf1cok+oR4NibuGQbeAWfd8Q1njvn6K/NJ/2Q/u7DD12YTl4bgtLvL oVrXJkHJ6z7p54F64rUl34Xc1yZsoTx5/he6l34bvrOezaf5Tc6POJopef64+g8AAAD//wMAUEsB Ai0AFAAGAAgAAAAhAEE3gs9yAQAABAUAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVz XS54bWxQSwECLQAUAAYACAAAACEAtVUwI/UAAABMAgAACwAAAAAAAAAAAAAAAACrAwAAX3JlbHMv LnJlbHNQSwECLQAUAAYACAAAACEAgT6Ul/QAAAC6AgAAGgAAAAAAAAAAAAAAAADRBgAAeGwvX3Jl bHMvd29ya2Jvb2sueG1sLnJlbHNQSwECLQAUAAYACAAAACEAJhrXxqQBAACzAgAADwAAAAAAAAAA AAAAAAAFCQAAeGwvd29ya2Jvb2sueG1sUEsBAi0AFAAGAAgAAAAhADsO7qtUDgAAek4AABQAAAAA AAAAAAAAAAAA1goAAHhsL3NoYXJlZFN0cmluZ3MueG1sUEsBAi0AFAAGAAgAAAAhAHCxQL1qAQAA wQUAACMAAAAAAAAAAAAAAAAAXBkAAHhsL3dvcmtzaGVldHMvX3JlbHMvc2hlZXQxLnhtbC5yZWxz UEsBAi0AFAAGAAgAAAAhANp94nKoBgAAWxoAABMAAAAAAAAAAAAAAAAABxsAAHhsL3RoZW1lL3Ro ZW1lMS54bWxQSwECLQAUAAYACAAAACEAh7KgidgDAADbEQAADQAAAAAAAAAAAAAAAADgIQAAeGwv c3R5bGVzLnhtbFBLAQItABQABgAIAAAAIQDkXKwH4BMAAPN6AAAYAAAAAAAAAAAAAAAAAOMlAAB4 bC93b3Jrc2hlZXRzL3NoZWV0MS54bWxQSwECLQAUAAYACAAAACEAFEXZl1YBAABvAgAAEQAAAAAA AAAAAAAAAAD5OQAAZG9jUHJvcHMvY29yZS54bWxQSwECLQAUAAYACAAAACEAE9QrR58IAADUHgAA JwAAAAAAAAAAAAAAAACGPAAAeGwvcHJpbnRlclNldHRpbmdzL3ByaW50ZXJTZXR0aW5nczEuYmlu UEsBAi0AFAAGAAgAAAAhADwCMP6BAQAA/gIAABAAAAAAAAAAAAAAAAAAakUAAGRvY1Byb3BzL2Fw cC54bWxQSwUGAAAAAAwADAAmAwAAIUgAAAAA ------=_NextPart_000_007C_01CE1F08.F5A14770 Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="Encoding of OAuth 2 Scope Parameter.docx" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Encoding of OAuth 2 Scope Parameter.docx" UEsDBBQABgAIAAAAIQDfrfoCnAEAAEcGAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0 lctOwzAQRfdI/EPkLUpcWCCEmrKAsoRKFLF2nUljET/kcV9/zzgtUUEpKa9NpMS59x6PM5PhzVrX yRI8Kmtydp4NWAJG2kKZec6ep/fpFUswCFOI2hrI2QaQ3YxOT4bTjQNMSG0wZ1UI7ppzlBVogZl1 YGiltF6LQLd+zp2Qr2IO/GIwuOTSmgAmpCF6sNHwDkqxqEMyXtPjLQnokiW32/diVM6Ujvp1Gld4 p8ZDjZ9EwrlaSRFod3xpik9k6Y4qI2XzDlbK4RmhH0iIKx+p9gN2ukcqp1cFJBPhw4PQxM5X1he8 sHKhad/Z1zYdnLYslYRWH92ctxIQ6Zx0nbUrWijzzn+Qwyz0DDwp/x6kte6FwLCpAf+eYOt7ZPyL CtW4LEHSV9p/KBrTWPlsG7Gn7U+DEKjex4R87J207+Rx59yLsILZ079R7Jn3gpTU1FMxq+GIin+z GK11L0SgQQW8uZ7/mqOx+SqS2nPirUMafP4H236fUlGdUt878EFBO6e6+rxNpPn06/1BHMsFFB3Z vPkNjN4AAAD//wMAUEsDBBQABgAIAAAAIQBLIEW4AgEAAN4CAAALAAgCX3JlbHMvLnJlbHMgogQC KKAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAArJLbSgMxEIbvBd8hzH032yoi0mxvROidyPoAYzK7G9wcSKbavr2h4GFhLYK9nNM/3xzWm70b xRulbINXsKxqEOR1MNb3Cp7bh8UtiMzoDY7Bk4IDZdg0lxfrJxqRS1EebMyiqPisYGCOd1JmPZDD XIVIvkS6kBxyMVMvI+pX7Emu6vpGpp8a0Ew0xdYoSFtzBaI9xNL5P9rSEaNBRqlDokVMhSyxLbOI FlNPrMAE/Vjc+ZhRFWqQ80Cr8wLxsHMvHu04g/IVq8h1v/Es/84Tus5qug9658jzzA3kNOMb6T0k I8uKjoWntnN9ThraM3lD5vTBMMZPIjn5yuYDAAD//wMAUEsDBBQABgAIAAAAIQDQRNOHLAEAAD4E AAAcAAgBd29yZC9fcmVscy9kb2N1bWVudC54bWwucmVscyCiBAEooAABAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAKyTwU7DMAyG70i8Q5U7TTtgQ2jtLoC0KwxxTlOnrWiSKvaAvT3Rqq0tKz31 6N/y78+Os9786Dr4AoeVNQmLw4gFYKTNK1Mk7H33cvPAAiRhclFbAwk7ALJNen21foVakC/Csmow 8C4GE1YSNY+coyxBCwxtA8ZnlHVakA9dwRshP0UBfBFFS+76HiwdeAbbPGFum9+yYHdofOc/3rqS zqJVFEqruVWqkkfX1dCVIx1qwI+KymelQBJ6P+EKoIRdpEIPy/g4x+ofjpEZW5gnK/caDI2Mysnv BzqQY9iK8RTDYk6GdvoOoo2n2sdztjd7nYHzZ9YRnKUpiOWcEMoa2oms7r3FWZqCuJ8T4huyNyDy q+jdZk+cArmbEwQvKE7KCYEPfn36CwAA//8DAFBLAwQUAAYACAAAACEA41J6DQUNAADsWAAAEQAA AHdvcmQvZG9jdW1lbnQueG1s7FzbbuNGEn1fYP+hwacZwGOLsnxNpMDXibEZr3fsZB4MI2iRLYkw ySaapDXKZoH8w77uAvu0H7Kfki/ZU90kRcqUI89IijwRYMi8NKurq6uqq+vSX3/zMfDZg1CxJ8O2 ZW82LCZCR7pe2G9b39+cv9m3WJzw0OW+DEXbGonY+qbz5z99PTx0pZMGIkwYQITx4TBy2tYgSaLD ra3YGYiAx5uB5ygZy16y6chgS/Z6niO2hlK5W82G3dBXkZKOiGP0d8LDBx5bGbjgMTQZiRB99aQK eBJvStXfCri6T6M3gB7xxOt6vpeMALuxm4ORbStV4WGG0JsCIfrk0CCU/cu/UI9GUdOv+fI0o4Du cUsJHzjIMB540XgYnwoNQxzkKD08NYiHwM/bDSO79ai/YsizzMGp4kNMxRjgI3A1xHDNR4Fv6EDz O57VSYh246nBZDNCIAocZkGh2meOScC9sADzaaQpExcS8Tn8/VbJNCrQibzPg3YR3hewSDCfgVlj V0teeWjxswA8Et3rAY+ExQLn8KIfSsW7PjAa2i1GHGl1oCy60h3R/4gND6Fs3Pdtq9E4OWm2Ts6s /NGp6PHUTx6/uSo90kCulP53nYx8ga8fuN+2vhWctNa2tdX5egsdmTa6oVZRh3HEHaAVKREL9SCs zlmm6Jjssb8epcmANTcb7Ndf/hU74PJff/k3I0CJBgc4BHQuQwCCcyKEHp3KRnouwyQGNXjseGCu I+VxaIbh4eAojMv3DibbvDSUyr6fQqSbgWA96fuS9AJzRc8LRcw4i2QC3Y8uppAu4ooHIhEKX5O+ 3mTsImFezLo8Fi6TIUsA+a0SImTHaZLgwY2IE3bl85D10tAhVcq6vnTuYwKhm7s84cxJ4wQLFJq9 ytEZDriG7RmoPc8XrzcXNHslBpwL5Sd4dS4wiWvPlQw00RIia0RkfQWSx4JxJfQLL3S9B89NMYcZ nSEIjgz1hIUONQJZh56P97gBGEwcXr4+XKBcJF2fKIx/hq1x8QFMPGxbB9t7MEbwahRBjN2PnCRd tzwRvv+Oa2HwRQ8oU3NYMo/aKq8/mPqaZL3rl2Dh7jsp7wFGK5hG60jD7HkqTt5LdGFTFz7P7sYv T6SfBmRO5e/zB7pJKL89hkGVYRjKH8ydnSmu8sjfKs+lMfbxHzDMwLb3DvbN0CuPd3b2G2MQ+ZeJ wkdTFO4NTJ1Go3nasptHlialY34zyjsZ4XWHADNB+FB+UDwyc+Bk5E8kKfgp1B/Pjd2om8muhBoI pn9fmr06ADR/OR4PR77XDwFKz5wBbGg28FwBZO+N7kscM9ZPX5ZK5NMMmHRuz49/bN2xixDKD92z d6QFoTxrhEaj/ATl9Zw+pvy00WlwixmQvXPHvo95X7DrNIDVPZo+GsLCkGLNe21r+byHmSp478wX TqI8B9uiL4QPdyf4EOsTDLcTGSdrjiwvjKukDTFnp/AHhC778vhx745dySHM3L/BjiIxW+vHmsV9 lbgRM3Ypki9EHe7fsXfYM3sRNsJ6fb6SHraBa124qroQE3Yu1ZArl5FCfC/I+Sq+EG48gDLkSnsF 0gibdcFox75mxlVlRszXe9H3sLFX7Afup+IJxUG7q9rt4epsUppQ7ZVNijEOje0BpxXk7UqJB0+m MTvlI3aUwDbupvBsrFl0VVnUbtyxt/yJCXoJfAmlX+VL2q8Yt+ZJqhQF0Y7hZiMP6xV8BdJd8+PK 8qN9xz5gZVPTp+h5HDlPp03u1NLBirUT5nd0ANrNO+2UoNhS4Y05fdIYWiG2IZ40fvhPd4xmwT0y GbQ3cG6Bjf/9p0b0VjGg1jn7iBiZi6DJMXfu0/jNJU8VWf8Be3V2fHn+Wse1rinYyIpw2YJiKysx DVc64LC7vXOwfUShER2XeG7UN+HdWNuhvJv79ymwQPAiidBm094t4iBZUwS68JZa4fVOU0dhBjzs Y73NHugoxlw4FKJTDj3PBSakkbJiHkewDe9UxGHO0sa7JsBT33+7GmNdRN+gp1YfyCiRvTNFIQUT h+ojvnydYLdp4jrz1TG32BfFMlWOuBEqmCBwLSpnobsAROrJzu422C07PybcYnOjd2/Z/VcVfIkh SV7moskz1l6UDC5IeDqLXDJeJknqGStnqQoDLUKqIcSd9lJ6sc6P29bGLbJ6WhtI6SHJwfVO6Xq3 dL1Xut4vXR+Uru1G+cYu3zTLN+U+7HIndrkXu9yNXe6nWW7WNM3Y82V7vejOOSOqpGqXwsFLkZN6 fXBr5XuX01Tp5FbIEgtleCn6uH0Ql2nQhe/wZxbyQLh5IwjZAinTVU+ZJLfWMeWM5aisEL6dW+tb uFqlGn0nwn4yqEXtbi3gdemJizMMynZe1cv4stc9LHJHUeR7jhbbC5PURzmVlNf6M2W5UsarVN5P ukHxdBxELB7lOkALVvFUpzW9N0m3xcM8vq9D4llEPAuI17fR3U22yKDewAdYfPWddLh/4wUCASbo GjjgYryrqJlZLN0/1mpYu1NZ2KapsgZUZga7j7rt21L3TBMIzXW/mO+Sl2PT1q/VkGjUv1AMwYQQ CslxueePirsAWeKD0n0seCxD7hcNhkLc5+8rNFuL16H25ozXolqmXpx4TZpdldlZqogtl987rtf3 kg32d6Yv2D/WNtLTNtJy+VJPyh+GF6mu4GdGqf34berfbf3b0r87+hflh3i7p3+R6Y7rA+sTtu7P dY1X/NzkBoezdOznzvziMGtNirj6rIKhXAvOsirMPI65LsqdDwOhxALjKZnnbyaq5+QC9TEpOvBh TNHW7vbR+balIxqd8mZkQqI0aeB3NXvfDpVlnV1fXTBUs2k/NSz6f1J5FlXQUZkVzIGKKV8BN8uk zcVS/jzaZJEiQ5vMN1kZxyNqlr+o0GqyoixOo0gqKmh6JUN/pPPUqPaJitrgWUeykBKTXWk86o2v R/6O6iSX0er4lG/lvq5Af4kTMvaDVYYy85xklWhF5NP7CbOBfV1Q3Ya/RNLkO+bcC/V8AtWz2c0A ko0/Kp2chPkEdwZe6AVp8OiT6Uxa332uXnztv6LUBhQVenmdE4ovYwERcmP2Smz2N9lBo6Ej3PYO AwaUZrfBtnezhzhNYBKf3zRbpuPbGUAJbkDp/bcqV09bxS+RtSrezUkemE6gkjIcs1BpHk0FqKn4 JDWIynnDZvn0YlKLyl0R4uAH4w8mJnjHccqD2XT+hRQ+GEEvTbwrH1BtGledw9UJeolTUPHizm0K INrkG2bdtNeDSx10VZAmBWkCPUFw8rOXk4k0I+SiZje1pHE2Elwxr8cqbJLZA+Otf3UOoLHNErvJ LlHVfQguMDyiy6pJ11Di0klRdo1DGuB9+4oNUPeC7PUNrY4ytAOk1YYyoYLhXorCYZQLs0RxVKCT 7xHVkNp1R4mO8QjLYAAwpmgbq4GDyvCY+TgNxCzHeeWxEgnO8MDikKLg3C/3BjSpl83KJMzCUjNb pJmNF1WOGjjGYQY34mOWefBcG8fQepEh6Xma0bq8mbKYlHCvUP95rASn4lmK4F7LQDDxkQeoPomX a2jvIYsHWNBcZ7sZQmkuOxsaWe7HpoKufDEvajRIDGm9gdnoS+4yrFt04oBRoWDTTM7M2rdtbk32 OWeprqGNTQ3tF0Uyk4vUpo0HQu6tikhOWYYX5irb2Nmwd2bBYKke6JyRcquwrY2hiqZu57xTWWPa 9vanxDpmVnLz1BfJMpJtyip3wZrgnfGX48ASiLsolVMXC5kXOn5KR88wI9YenY8CM8gpcvztXAn8 LgI/J7W4KFW7anqjCdWxYe+uvvbIVcUKKJAaT1gmlnNmvkXYdjXK5AVgPRdTZ1EyfSIDcCdK4ft9 c2qQFvIlm4jNfRyIgx3xoj3gNcZNHOFEooVZNyXjVCdhYOn5LW2lEVqMsVN4FtaKPNuRZKI5JWe/ 2E8UZuBakS/iPMDyJn1CzyWdizhGsfPizbHpfoNJlOo9rqYq2+T1c6RzjRj52uAg4fCtUJjCBBMy HwqLdS3RKxxAZe9TEzmMWVBzPATT/lnyzfThniNjtWTZvv493SmzkeVSYJsdk/ehm+LoWPIYqRQ+ iEmP8kSsbe+4cXJkW8Z5Ae9kmpAPiyUSpxlGKU5vFTqKRnTJvBob5EsbyRRezHu9n8/3cNroYjHc AD4OckjgtcIxcAxq1vF6I8xMdf9Lo6JeKzUY23br3KxQk3VQp7t7ezv7Gs8uDqDDcVv3ejHBYuYV 58YhCa5t/fhWUm0ZKR46Y9O0hZ4vWmY+EnoN53xyVVCEjn7LMNCY9a9/wkd0qF2z2TLrJq539nGt gUd9nJqGFjjhDc9bpok+kW18a866Gt+biqu88QC5ggIVYGQZAlBPwtc4vu3jDEi6zbpzpE9nWWZn dhbGJM4cppPt8AaJTuLKSxyk0WIbnWleM0TtFjIHjoLw+THFnf8DAAD//wMAUEsDBBQABgAIAAAA IQAw3UMpqAYAAKQbAAAVAAAAd29yZC90aGVtZS90aGVtZTEueG1s7FlPb9s2FL8P2HcgdG9jJ3Ya B3WK2LGbLU0bxG6HHmmJlthQokDSSX0b2uOAAcO6YYcV2G2HYVuBFtil+zTZOmwd0K+wR1KSxVhe kjbYiq0+JBL54/v/Hh+pq9fuxwwdEiEpT9pe/XLNQyTxeUCTsO3dHvYvrXlIKpwEmPGEtL0pkd61 jfffu4rXVURigmB9Itdx24uUSteXlqQPw1he5ilJYG7MRYwVvIpwKRD4COjGbGm5VltdijFNPJTg GMjeGo+pT9BQk/Q2cuI9Bq+JknrAZ2KgSRNnhcEGB3WNkFPZZQIdYtb2gE/Aj4bkvvIQw1LBRNur mZ+3tHF1Ca9ni5hasLa0rm9+2bpsQXCwbHiKcFQwrfcbrStbBX0DYGoe1+v1ur16Qc8AsO+DplaW Ms1Gf63eyWmWQPZxnna31qw1XHyJ/sqczK1Op9NsZbJYogZkHxtz+LXaamNz2cEbkMU35/CNzma3 u+rgDcjiV+fw/Sut1YaLN6CI0eRgDq0d2u9n1AvImLPtSvgawNdqGXyGgmgookuzGPNELYq1GN/j og8ADWRY0QSpaUrG2Ico7uJ4JCjWDPA6waUZO+TLuSHNC0lf0FS1vQ9TDBkxo/fq+fevnj9Fxw+e HT/46fjhw+MHP1pCzqptnITlVS+//ezPxx+jP55+8/LRF9V4Wcb/+sMnv/z8eTUQ0mcmzosvn/z2 7MmLrz79/btHFfBNgUdl+JDGRKKb5Ajt8xgUM1ZxJScjcb4VwwjT8orNJJQ4wZpLBf2eihz0zSlm mXccOTrEteAdAeWjCnh9cs8ReBCJiaIVnHei2AHucs46XFRaYUfzKpl5OEnCauZiUsbtY3xYxbuL E8e/vUkKdTMPS0fxbkQcMfcYThQOSUIU0nP8gJAK7e5S6th1l/qCSz5W6C5FHUwrTTKkIyeaZou2 aQx+mVbpDP52bLN7B3U4q9J6ixy6SMgKzCqEHxLmmPE6nigcV5Ec4piVDX4Dq6hKyMFU+GVcTyrw dEgYR72ASFm15pYAfUtO38FQsSrdvsumsYsUih5U0byBOS8jt/hBN8JxWoUd0CQqYz+QBxCiGO1x VQXf5W6G6HfwA04WuvsOJY67T68Gt2noiDQLED0zERW+vE64E7+DKRtjYkoNFHWnVsc0+bvCzShU bsvh4go3lMoXXz+ukPttLdmbsHtV5cz2iUK9CHeyPHe5COjbX5238CTZI5AQ81vUu+L8rjh7//ni vCifL74kz6owFGjdi9hG27Td8cKue0wZG6gpIzekabwl7D1BHwb1OnPiJMUpLI3gUWcyMHBwocBm DRJcfURVNIhwCk173dNEQpmRDiVKuYTDohmupK3x0Pgre9Rs6kOIrRwSq10e2OEVPZyfNQoyRqrQ HGhzRiuawFmZrVzJiIJur8OsroU6M7e6Ec0URYdbobI2sTmUg8kL1WCwsCY0NQhaIbDyKpz5NWs4 7GBGAm1366PcLcYLF+kiGeGAZD7Ses/7qG6clMfKnCJaDxsM+uB4itVK3Fqa7BtwO4uTyuwaC9jl 3nsTL+URPPMSUDuZjiwpJydL0FHbazWXmx7ycdr2xnBOhsc4Ba9L3UdiFsJlk6+EDftTk9lk+cyb rVwxNwnqcPVh7T6nsFMHUiHVFpaRDQ0zlYUASzQnK/9yE8x6UQpUVKOzSbGyBsHwr0kBdnRdS8Zj 4quys0sj2nb2NSulfKKIGETBERqxidjH4H4dqqBPQCVcd5iKoF/gbk5b20y5xTlLuvKNmMHZcczS CGflVqdonskWbgpSIYN5K4kHulXKbpQ7vyom5S9IlXIY/89U0fsJ3D6sBNoDPlwNC4x0prQ9LlTE oQqlEfX7AhoHUzsgWuB+F6YhqOCC2vwX5FD/tzlnaZi0hkOk2qchEhT2IxUJQvagLJnoO4VYPdu7 LEmWETIRVRJXplbsETkkbKhr4Kre2z0UQaibapKVAYM7GX/ue5ZBo1A3OeV8cypZsffaHPinOx+b zKCUW4dNQ5PbvxCxaA9mu6pdb5bne29ZET0xa7MaeVYAs9JW0MrS/jVFOOdWayvWnMbLzVw48OK8 xjBYNEQp3CEh/Qf2Pyp8Zr926A11yPehtiL4eKGJQdhAVF+yjQfSBdIOjqBxsoM2mDQpa9qsddJW yzfrC+50C74njK0lO4u/z2nsojlz2Tm5eJHGzizs2NqOLTQ1ePZkisLQOD/IGMeYz2TlL1l8dA8c vQXfDCZMSRNM8J1KYOihByYPIPktR7N04y8AAAD//wMAUEsDBBQABgAIAAAAIQDscVf1Ij0AALDj AAAWAAAAZG9jUHJvcHMvdGh1bWJuYWlsLmVtZsyde5RdVZ3nz72VhEoqvMLD0k7gpCTTQUNIFQRC aGiSkFA8Ei6kCNAhkkrqJqmxXtYjIRpdIOik1VGagOPStoXB16jt0IuMKL74Q51I9xpdi46LHlmK jzVIzzgdZ+GaDmoz38/Z53fPvrvOqXsrKZ2+ub/a+/z23r/9e+999j33phRF0YDAXjvLUfS6FruK oi09UXTBYBTF6zduiKJS9MTPomiF2udkXZLavadE0apZUfQpjX8nRL3X0dvmRd3fnx2JQPTo+ih6 WHDdtdevU7d7I9FaPPier9P9gPClaG4UtXyjI4pmRx9LaIho1FJq1XUUtYk6LVE0v7x4VmcLbctL 7dFClb8p/+o1FXp9Lek165powbrewR2j/b0OnfOX8ReJjWbLgnk61mgSX4vhVI5+KZ2n2TKfr3Kp lGhgbvnm+75ePktTdc17R7RdOGbBOvGszuX6J022pFA0P5p0dE5VDTr3yQIZnTg6vVA32dhV6dgH o/O8seuHdg739Q/tjod3xTevmRjfE3ctXxEfGts5PFJ9OJ4rzk4RzBXfc6PWqJzUytE8/XM4MI7/ Oerp+rbK78qe9Mb1W6QTn2soIJn+lOtt9mDim/KNjnW9A/1yDnXJfzmdlVP5mysz24hm2XH3Adlm +tw151EtKXfNlfXcEV1d8z4u7rZ7uuvZU413DQ8MDO/DdH3VXf1D1bG4Nx4ZHq8OjcvLc2w50jva O1gdr45q5Ohg7/jyOL5+PO4fi3f0jlX74uGheFxUrxutVodibN2q+Wbpb4v+tUZtyV8s61rAuRr9 rEadlhb1my/PcG20A7P1z43i7+yUIrhTBa6Hm3N2iuEKirPS3m4mR8PVXX9Gt9WoM4/5Ff6BRp2f TLZA1vP9iaa/KD3flvR2Mbp2Ynxcqumpjo3HlYHeoXjXxNDO8X6hdgwM73zrGMpMFNfXO94b75wY G1c4qdtSM8q+Pb2Jlvudfnf1D1QvVPTAsZPARRbXLcI7vZIlTEqH4drVTqmNpZdpgd7UTcMOb2Md 1tnG9WxTX8cDfVyLUYOus7qvydNS/YyUXZQ5/SyPsU1RFGbadVH2xWh/uTjKimxkNsyovS7h5Zuy FbzzIp9uGB0exBbkFXwKayNlNs5x8c3oo0Gs+3IeTGl/Itrs0R7HAUZwgKWaYawa945WE7v3D/X1 7+3vm1DMpR6hTLpzeCgJsqGddJID7OsfULsuREbBpsYLV6fcOa1nlnI8+/bM7OJ6tSjPupqLtHrP cFZlPDWkJ7rcP9MINiOi+Wc6cqX9dSOx7GTtPRbY0New2crZcnI+Dql9XzYs9ogW2eI8SRtF5856 KdpSOhrdKY5cRGeULk4s9lNRalfrndFR9Xwp2rph7d2XbouvH1LK2yvrbCT3KV3OFr1WwSmSzEmP t4A9RaPLyltcAeiAXpZLnPf8NPp1wrHNE9f1gbs/Lr32Wj3nz5bhyThvrJs3pxJtKZ0jLpD72bKT qHPltvi2sd7d1XjzxOBg7+j+hHMnj5NornIvsuAV/J2vf7TkSfJykhmNfmNJjieazWzQWJI1iSSv yDYXJLbBiscT20iQmm3WD1R3jo/27+wf39+0nbAW6xGxO0slnjpHMmf2I0YmS/1KdEki9Z2R46UZ qdH+dOy3OpV6S+l88YU3Plt2UndeFthPqUGbrnXDY+OJjZqzZFnRi7zsyIhsp4V6P30luiCJU5u9 sZxtJWwzHetencg5p7Q96hA/d0b4R1uJyJOY11YHe4f64sa2ZZ+AjyJJWeVku57SRFzOKa1K7eq4 aEZerDIdu8apvFtKpyV2PS67Onk7L98WV4b3aXeV5RcXj0jFajtbMmS5pCOl9Dcl9u7oHUq3aBkh Biy22SegD2yNDqaO5zmlN6QWd9Qaa2CRLN5Wmo7FlyZ8t8viZ4mrOyN8ZlFicSlgU3W8Fr4Jx86b ybNIggay6MzPru2lF9Ls6ig3IwOam44VV6YybCktTHTfVnq27GToXLUt3jgxMN4/MlB1abYy3D80 PhbaFCmwCTIA3AVZ1sXe4MhLmb3d2tFemptayM3ZWLrliX6nY6FrEuneJAu9UXzcGWHj5YmFJNyG 4dF9vaN9MYF5a3VvdXSsWmQxfI1dAl7s4hLJ3L7DtXEv0NiibyptSOPScdKMzNhjOha9NJV5S+mP JDMe+WzZydx5heKydzS5J5oY0Sa9GrNTl0zIwDppUUqJRd0uAFlptxxLDajPsW8qvZquoG7GxrLd mlhjOvZclsi2UfY8N7EnHnFrYk+Jdmt1d792lKPxlt6Biarnp3Z3hTSsDi76uJt3cQeuXpaNpV+k kedmaEYWtDwdO92ZyHKlxlwqPvDLZ8tOli6lj7p9jVsX3RqiW1v5a2W0urd/eGIsvrZ3fxzaL4u/ cNfjr5X+SsMZBT6AD6Mdl2m5pgVNkXEzLdnuLcO8IbXMltI8T5o149rJ7JjQTp/7EOdTUGWGPK0/ knqQ00Vjrfcl9p+OB3G20jXvbnkQu4Y7I3ywL/GgzhXb4ut6x8RbfTQg/WRe7y59JvUQR6EZXrHv dDykM+V1S+n1iU5vlYc4XruUvuo9RJumHM4tD0/2A2fbzH6Xp3OVyou8ucbdPf26idFRnaXEa3Xn xiFLRTcPw32az51tYU+XC7Gwsy9+xFrNP7zJ7c1cTqF/fbzdXfpUuhY4GRtrc29it+lY/vxEwrfJ 8qeKpzsjfGevs3zntvh2ZcNR8VVv+1N17fJFyPHbSk+l9nd0muEY603H/m6dfJvGcFeInz5b3ltq PNPBRLLp6MZZ/37pBuvfGaHdg043XduSDTlnorVblGvzVw0X03gCuxu37lMne3A3SSRxFery/tL8 dFV08zYjIZqYvi7v1xiny73S5cECXVp2c3d03Bdz5p6VIf+PSG/19+14PWMa3/M/UuoLxvonwc1z 0qH5uuZ9Wpy48293CrT+Hp2B9umQZW3vzrdOjGnn6dY8YtTFKXtR4tNd1Uflp0vP1fF2kSyXyb4u nfH5aEkirZtxU+/EKDurwXjp+rWbNlyYnAlu5gQ9rh26rk52wHjGrORclFOZFl1xku7O0l3WoN3x B3f4E2PCE9Lm9Pzp0ouJ5cV0cj4Wa+ZMlub17GLyqZOw+FMzZPGzE/0fESfc75tcTtW+1jIpHe9H Sh+ss2oc7fA04U42j5SOJRFsVK+K52qOyZR+F1Di3Nl86ELVuuYdKbWWzvb426pt2tjwxOjOak9V TrJtWbw1xtruDNYs3Or5Ba3Enu9756a031fCn3mtaNGZ51pojmksXoSvcNqXcWTyHwk8Ad8zrq3P 39b12ZbMb31MR99L49vNviyGz4yS9fpBXS8nbdbL7ZuOlH6U7JtMkmQHmwiDHG5tnUqii5LV00bH 4iKbwSTqqutTL5H1uayuz5V1Uluf1XV94joN+yd98awVXCb24RRwujH2/EnE2PNTxtjMcOnO3V8W l+Qm033qg4oX3wd9v3B6fLn0WBA7N0+y2cuKQn9duUpeHdr1ZZ2W+H1i5f+sz+vFVte8lxWDxK/x 2LFh7VUdy7YeulQ9HZ9kWiJscrS8XFpXFwnLkn4WCS4OXy5dVxeHDxPVh1aKHlSLKfc3QXkwh/Jl DSl/qAnKh3IoX55ShvN8bXypCcpP51Be1ZDnF5qg/GIO5SsaUi7XRWy9Bc2L55R9L3YW7FxhfuG0 kecdnU3QXplHu7PeO/Jo390E7Z15tLsa8/3BJmg/lEd7ZWO+vzYF7TPTiHymTFxYRKJv4zmL3pnJ U27GV5UD/Bm3Huq8rMiqr5YWT+GLzmNeLS3REy71Eojm5Y2082rp5iZob86jvco0VMz3u5qg/e48 2lc05vsLTdB+Iod2V6oTZiCnTPb0V0s/bIL2j/NopzqxHJtH252ymqfVR7/5xqmBN8ZXOm6dxzRz H/Nq6fw6r4/r1qqZ8WR3dtNWdmc3JlG2V2LOybsltG7rlVt728pPBmvmVTl9Gq+9bfrEpHjtdWeV beXWEmeVxu3WDruLvnZitJeHJ7QUx/DILs/dM3M31pJ+TgLO9n/YxL97XiKiXfPayh8qnakWm2Fo eGhTdbdI761umhjcoVMNfK61dicFPWbgHsF9Gj55t9hWPiuwpn8C9m/SeV9fXuDNeyAe6h2s9plY ymjsepjZzeI+98nkcT472TYPBTPP92zTjB9lFN3nMwtlgbM8Prd2rOVpFeMT9auVu0+n51MKNO9r yWl+Yfn+Gdf8wvIpgfyTNb+wfOrvQfMLy+8NZj5xzTsPuUia9z1ka0e3DuiHR/ffVB3aPb5Hms/0 nnm+81au2e1Ojt6LygfqsmVcdzrrLHNR+d0zaBl3J3dReU7d0z7brnQeXJ9bLiqfFmjRz8nT81+X ra5WvqvPMr5O3Knm1eU+RVmWA/x77LHCe2ufM5vre8Fci73osz6NM+PVU2bGapI/rpZ3/InH86E1 IyMD/TuTnHi9e2SI9PhwfCA+xMOYw6P9b08aE0xy+p18IMmlPTfmntTKckyWU8lBlkk5gyQ3uVF2 ruSiP+tDRqZPdpZCzVEE71rN+tOz7EiigU3SwDpfA7Y0JAkqETN5UOfWai+PpSYIe4Ig+Xz9FvcR efoJOe0JX0iKbd06kuU190wIvJOLXR87d3HSZz1sFL5GG7K7DM7nveiBM5lT0lXEnbOwNjl8loOn p5dKope7pZflvl7qhE4s74l8KFVPz36e0sUXinmvt+Wp6fmQz3e9PjixRtqTtbd7hmlEcp3jy3XT 8M7egZ7+wao+ldXaqU8gxh7WXC4DomOeJ0a38A3eebGrw5N5n4vMkfLjQWakp/WZniXixBL3Kffw dAcvTtjqVvgYPuHIPCOLMD9DOd7uKx8JMstSjzfr0ziz3DdlZnHnEfdJz/654KEdyedWiQbxT/75 mulNZb2wdIUn6273KVcSdX29/QP7k9rg8ND4nrQ+Vu0dGx7qHUga9lWrb3V40Xb2CmMKTTE3/mb5 w+mPWHR48g+t5gOuBMdIWpyHksF8OmZl0+S7ZmwVWpJo5yF5wkzvMh8q/zzwCX/H4SR5qNzYJx6a 0ieM/9a6HUFf/+7+8WXxO+KkEr/zysQCWMH2pc4mDoPeJ/v0Q+W7Zizezkq0/Li0zEy8iLeEOY+z LJqddh4vvz3Q4F6Nr/eFx5vQ4ONTarBPFLvmPa6o4kSYF7x1rOhQtu3oTP52JX8vSf5emvxdmfy9 LPl7efJ3VfL3io74SvFI/FkMUM/8/veDz7Pf4+X68+7pn2WHuj4s+9Xv1fw8g+6ae/7+bPXsmvdt UfM/27l9T3W0uvr0JDegwebvzr9dfjDgyz9JNr4yaRYl8x/V/PM9i/u7SvKS+/4Dewb3CeJs9c5o OA89Wv5KMPPlXh93n3BUHurfJ/CNjvWbK9fHo+lHRbFbhXlGhZrzlfr5/adTbOb679h8OMmX9bFx tFwNIpgca32Wp1rYU3qdpwV9maFXj8XxbZFD3i5UfGFrx5/7/JunI+ZoDbenMOjhdl3+PZ1x++uA k6kt5Fa6l2Qhf6WzT8DgAsAik+d6qfxIYJOtntTurvkl2cS/a8Ymwdc9khl4YsitVsyDdO4ZImrI nTf7rkBS33ZrEp2/VN5TusDT+djEyMjwKN8WWDo8NLA/eWyNLxbwDZ94w1o9EzVadd7orOA4Ms54 6ou1mPWSJ1HMb11f9+STewLK5SWzv7PMS+UNwVrq82t26C77dhjgQbS+CyWBPXGGLTLPMsojAeWp be4+Kzwum/OMFS/ycHb+xW7VWaDY9sfLnwtsv8Hjyz0Hcly2X+TNINuPuS951D7C73+7bKH9qj5t ZS4Xi2gSDfKsj9O1/4Sr07qzSb5fHi9/MfCMqfXxxsRX2lq2R2d43NpNlB3wuIhzsYl+3Oeo8EcL Zb2921q+HWjozV6fRemcx+oyY88eZQO99XWYGH1g9XLyl3ziYiKbx52gt7VcXHeiO9g/1D84MRiT caGA7uaLSjZuRzr3YGm12nlhf8tHA8mhCs/p6Is5/fZND33VaqyqSOkbi5dWl+9eHl+xYkXyTEbn ytj5P/zCJfyCcZZzO2QXG67FxYY9y0NfF0kWd/YsGPtSnvahp7vPRvfu2o+ByavOqkS+RS3H6r6V Kb3wAOGy+JLLUtaHh6rxHj1DsCx+z4VOW8yAD2bzwoPj2D155rzSSUyveWrNNOvicVHLf5qW/7mz l4tb3BNlZo+600VxhabIhPV+B8f1fndxi3uizOjE0RVeHxeZF0s39ZGZ+Z1nf/ftK82Z74mZnZ1W nHWwuPE6mbdDgWZ8v9wqlrvmXdzySGmlKBj/yXe9yNG9/UMuMswp5Yq171lWhyYGq+4gHNeVxM4D +dak+afjymUOOOba90bzPFYbRrv7LrN79o0fPJPxeLjP/2RPvDWRaI20fbEn0cbenaPD7q7wRn3V TUHmtim9O4b3Kj+O1R+AX6jodesfcsCx07vTssnh4gIcNfoZj0jFlTtvCb1n8t3ImpY3Tms1cd67 uaXee+tOaOWztn6xcjqLoL3J3ru55UtB1lytfubhBxN9bpY+N3v69LNm5r1KpZwRxzsmdu3Sw9xy ilElsFElMOlb3qJPNOoeRkzizbJbor287Ot073hHr3iAiw7zJOcvZAVrdV7i1jawLqe7mCE3O6sa tdArHX0X++ah9kR9ppnJvrcx0VVVulrm6aqzK8navfH+au9o3L8rrkszyWbUjiYudDnayYHPO79H du5uTfL8rER0wS3fWXbyoSXnxxnXzneqLa+U/FPn5fEmfed6tVZBZSXNZd90cesB/DjaGR33iV61 5fIyT2PzWtESz9Lo5JvCWk3TEZx5WNQ6rsyzXOautoTfpZ06vg8kOt4nHd/ozctjretq31oexv3G rtRKs48vhyxLFvfUKQf11P3Q8DjfYt01oW+z6jus8fho79BYP0fW+oKlIgd+XUSzB4Zr9Oi8x7zM rVi08d0S/pElskznZIUOViOfZE9SO391fdlnuprzWTcz1C3rmA1Mb5P97v5EJwelk4rG8cIWyakk z3yP7deWdlD6UBTKMGPVeKe+Kz8WD1THxtx+3L7XO1odnxgd0v5wQl+/H/DVJsPiVc4ziRe3G7cs yd0jctBiOiDn4I0u+1gEzkl81PkENPAepwM0ZppwM9HLrQjO/41yFu9Ou6FvTtaQO6P5qDQEn6Yh HGB5IpPjIfNu55sfbZkbrJ1T72rdqC+0hCcJ/p2p9dkZ5FyfMrH1m/IZkp6X+4WRUrncsTkxZIKM jlyy44ykdvqcpPz4G3ckz+ldlD4rQok8Z5fpRe2scizRrbaixdXwFau51rO1Frlf/TirfP6srHZx 2q8UZTXXerY+XcM2zHHerKy2PB1RjrJaWRbldaZgvqBV0CY4Q9AnXtvVPDe4npdeq0he1t6pvosl E3dy0GoXsP6PlCJJEEW/eu2111TUXk6Teq6RX2uJeqNBPT87GvWrNjOve2/4CKLUXtfc2FWrJxXc 7CReUo/e3uvFV197TU5yyS1P7kuwDeiPPPi5hL/1N3w86f/MU8vP8KjVqsfud3w/mGLsGr3z+mVn 9bW+vYnp9AS50z36Ppn6rRqP3RBwCrt1rEktNqB+M/X6fejF500yIVb2mqbdvnf0qfgaLdxmN+P3 G6fueO1fZH/0zusX7YsXUGILXm9+wzzCq9Z+zvrJdoMxs9vJ1KeyP0wRn/QhRqnze0I9KrFjt+AW wXbBNgH9/svG59bs3vfcGnDvEMwW3CTwA2iF4p+cdofwndHyFG5J8oea6spmZAx5g79eAbzB51sE Pm/36RrewBXxVlFbHK3Rs72Znulv/IT1kAeIM/ctgjmqh/p5UHh4OE9QxMNBta2PhqKd0XDUp3w3 FO2OYtV36e/N4m0iGo/2qN4lHa5QuTAeS/qORNVoUcyOyOlSrlarYw/wrQL8hjo46uRrwHCU1se3 yxzhoenThR54+oe6wB7o4BaV81WGuniLcM3aA56MvqrlW/VnROPhL8w/DwrPS+tGB+vGgHToVg6H n+7fWNq5QX774r/rSoZOxxYMSNmZMr59nqRL1Jm9gvxj+WT+mS6f2LUNsGvawdm1tVspkZKXtVt+ Qs+8yE/huoG+LRZOpL5A4+cL0IlvT3wF6BYQt5sEbxXQz88tH0hxRbFTUTvxW+QvyDyVv8zEeoW/ 3KiJzF9MvzNpD4lRe/1r9hf0bf5yIvWp/OUDEhx/wU9er/o9KkN/+bhw2wVF/kJe6lE2rcprdinH DujfcLSvlnX71LIruapGY+rTKxhRj3Hhh/SX3eiAcM3k5RH1HRUMaizjR9M5R4XpFWa5ruPoetVi 0R3T3x3Cj6lnn+rDmi9Wm+P1Oo2u6h84fL01BXQMcE18AtTbvDrX5Gx/jPXzcdSNVl7dxlBCj7g2 XmxcWLLmADaPX4I3muCt36lpf6MFnrp/7fexNkroUfq0bZw/N3UfTz28RofGk43lul2A7HrpadEs vy1J69Apqvtje9TvptSn96n+XCmKHlCpoi4HflHXtwmKfPqf1bY22SWMp17TI08ZS/yqIm/tTbxm l3qwx8CHnW/tSHx/p+IJ3yMa8FDzuD6NGxfEGjORUHO7E0dtqXy0PlL2yVMZYb7MPiajRkwNaMSF 0Zt/xd4DfaIngDqAbs2frB170j/0E3+c39doWbs/jn2M9bV25qRu19Ye0qGf4cI+/hzQ8fty7bfb WHzL6Nn81s8fY23W1/ilr/UH1y4wn+xR/Q7Bc6VImS2K/kHlAypV1PxqRH6HX6ko9KuK2shR8MAc SwTMwbxF9ZAPePnvKR8v5vCxP+UD3or8u6K2ODr6u3CNNx7gr6i+QG3wDP2QtwPCdQvQzZjgLwT0 8/cf39R1q6CIt7vUtkFxM6ycbt4On7PTceQp9AWP0AHaBfCkV3KPhY6YHz72CkI+PiocfMBbER8V tcUC5g3pXyMdQxf6/1dEQvqfEB76mwVF9F9RG2uYyyojtayyNM0XrFqslqxSpgcywVByR7NXtT5l Ebd21ucdd5/Dvc9QmoNYHclURsllFdZoVmtWSdfiuHGrpcteF0arxecsgemaul1jBx+PrqzN8JSG Mxv6NGgH79OiTm7xcfTj2tZdv83PQzafzcm14SiZy9Y6a6OEnj+GOn1t3ac97EN7OMZogrc2+lnf dtVDX/3nkvOl36n8C7WrqMXMY/K1Zn2VuX36fqwuSedFhqK6P7ZH/YBuATxxP/FXAp+37br+foor 8vOK2uPo9kn3E4uFh9/zBMx7p+CoYIsmeEmlz3vI1wtqh69HBU8JPi8I+fqpcIwzvkL6B9S2VZlm bXR3dKnurNk3sh9lV7k3jauNunIYd4YwW2PM1ygBcL5fcN2a4q0PfiAzJna3NivNR+gLv/MFetXy 2Jd18ajg64JQzl8Lh5zIXiRnRW3cz4X0O4RnLh0Zv7ZYJfyYLbDBUV0/K6ZfUrlAQF/mWZLWp+NH f6cxDH5UxZDKUA7mQ45zBCZHyMM9ajN7dUYrE4vdpuzZq7MdstdmZcPB5D5gNNqvU/HZ6o/MyEVp AB7eWVPIJYanH3gbg7wA10arPcWpqNkHeR4VYixHrpdTuVQUylVRWxxdnszj05/KPvjySwJ0dFzl ydrnAtHpFp2/FvwPwVcE8Oyv26/o+gKB2Sfk4WG1mX2cdSbH0/pkx8qOmU8hdgrGZas4muk4w2YW V9gY+wHguKbkmjo2x87YH5yV4KlDq11AH71qdkdP6Ot/CkJ9XSLlvSI8OizSV0VtJxKX2J24nAm7 t8KgADk+qjKUA/9CjvMFJgc4n4cPqM3s3hld1iAu4+RkwJ2+rtMOhd3PxkTv6Nn0TR3AHicaq1JR snabraENjhIwv2hXPbTtx1KdPJqjkwtEJLRtqJOKaMZaWZDBp9+RzpWXc4knbAqtNsGCtK+qJ5Rz 2zWwW2O/KnhZ8B0BtPyYniMEPJltQx4eVJvZ1ln2WuVat5vkRGUm4nmu5sAe2MB8gGupObnGflyb vfLimHH0hwZ9/Ti28aEtetQP+EcBOvonQaijVdIPOtK7UEcVtZ1IHGNr4ngmbP2oaMEkclyrMpQD n0KO09Rutgbn87BHbWbrTq1H7IgqitB9yY4obhij6B1oS0tsgE3aBdhFryR3flYVeITXh1SGvP6N cPB6utqLeB1Q2y3p3Y+tIfXr/5rkjAN+sDs+AMCT+Qol7fAGcG3tIc/4yaGU54/k8PwGCQrPehfy XFHbdP2EeMQ/sNUiwQJdw6uqJ5QTntG4bsERwScFfy+Alp8TyBtnCXeTAJ2FPIwLZ37ivGRTskue vIqvrekTPaNf0zE5nTMo8OYnyGXXVjK/jW1XnT561dbgT+niiOBzglCWF4RDFuQrkqWitli7f/jy 6Xfomrny8jS2wCbE7kzY5BXNA5PI8V6VoRzMhxwL1W5yhDw8oDazSWe0KondjYqPAa2u/Tpt55ww 1omn7ZaJa+5oxoUxn28VDbORbyf0QNssAX0p7ZpSasjdS9Pm92Ms0C6Apl41OyL3ESHerzKUn/9n JrRjKH9FY08ktrAftJYLFogGfKl6QrEVa2C3xv5A8IrgJwJo+bH1JiHeKJzZkdjyeXhY12ZHZ8UN stSocjDnQKy4nONQ3iqL7k0yszsnCnfQa3Ltiv6JPeyLbbgmX5u9wWFPa+ea/pSA4Rk3J8XR33wE PP0ozU8Y0y4IbY6O0BVr0E8EUk1NVxt0ga7AFemqorbp2hxbo29idyZsfkw8wCRyvF3lT9xlTQ7m Q44/Et7kCHl4QG1m8049R78tYt3F3tlnYxOKYffpAXFsnyOsy7Wx2dLsZtdmE66xDXYzu5ptzX7W ZmMp82z4DsmG7Peq/IlKFTXZX9VFaMNQ9or6T9eGxAy2g9atggW6xrdUPaG4/b7GdQvY/3Ef9FsB tPy43SjEucKZDUMe7lGb2dBZkPjcrRzL/Y37nHKLbDqgnMwZK3pGp6Z307PZzPDYaY7A7EKJbeYK GEO79aVfuwBd6FXLrV/UBbI9KQhl+4VwyIa8RbJV1BaL89AHOoRnrqI1EhsRZzNhowdgUPBTFXr0 Mvrf7rJmI3zhSsGlwpsc4HweDqvNbNSV7m+zFTE8P/LvU/17nrEoy8EVxShZmE//JmTVOLpWNuY8 I8++vo2xH/YCB2BDbG919ArYGEqJnXs/Cy3GW3/qAPQZYzTBcU1p/kSb+ZA/xvzL5m1XP+jrVff5 rI/vUeNBekjv+NvFKn/rLuvshL+x97tJwNyhnbYLt0ZR486IdkizRBC/lOr4hnfA59vkKYoBeIGn S3N4ekS4MAZCnioaG4sE+vBl7tA1esmLgTuFx/eh1SdYkPZV9YTy1IMa1y34neCdgrkiBC0/T90t BOu56TbkoU9tFgOdevJtWxRH18lnxzQMHZqvUBqAxzfNJ4p0DE/w9m76Brx9Rjh407uQt4raYh0P M2+zOka36Jg8MxM6/rnmhknkuFdlKAfzIcfr1W46Dnm4V22m4650Lz5VnnGnYPn7NXTh6/9Eckar aAB5dvut8MiJvKzXobz6OeBE3kVqL5L3oNq4j8ied1inmB1NciN3GJyDuc8Z3Wco7G5YEcma8sdh 5IM3TVXLSyaz8c414F/Tn2vygA/g0Ju1c81Y+oDnul0wX6BXbZ38TaoHBoZ64P9dDf03tHtFxPTc 2rnT8V/iE7+F1l7BAl3Dl6onlCP+UuO6BW0i8OcqX6cSWn6OeJsQpwpn9gx52KM2899OPWFMjrhd OcLtYz5xPro0PVIagCdPQBuc2YsyT9/wB58fVBny+ZRw8Kl3IZ8VtcVabZnLp9+ha3SYl5PRM/om X8yEvns0D0wix2xBKAfzhXKEPFRE4kT2wPAPrYOCk/Wb34oH/Ib77CMqL1Cpd53f3C+EnwfwG5+H g7rO/KYr8Rs74efZu11R3ies7JjGBasSf8GWrQJKA/Mr8AC5wsdRlzmT+KadayuNBrFPn7kCcPSh bBfgK3rV8sB3dYEe/pvKUA8864ge9K7zS18PFbXF0Z9Not8h/FR+CQ38cibsaX6JHPhlKMcW4UI5 wPk8NCPHglQmDa3lK3S9JMWH9Tx9d6sv/N2gslMltPx8xf4M3E0C6NlrhZJNLERFCOLHn4s8ZDyE 9TweblR/eLhFZchDn3DN8bA28S+f/snq57OaG/3A01+pvFql3nX6+bQQpwtXpJ8Bta3Xk73kb86O 3NM9axVzPKfIfYs7Kyce0GFrDhAvdl5LO32tX7vq+LVetRiCV3h+TGXI83PCwbPehTxX1HaR+GLe kP4yDfyPwkN/tyCk/7zaoI/9i3TyEbVtkgbYp8R6BoQztkHVlkpTa9WyQU9VZvuZzdLUsE5gqsKN aFT9E8ir5TW+buAZPZJrWgVcsybih9Tpa0Af62+6t2ufJnQA62N0KaHtt9n4JcJjl9D/fXx72kdF zXZ7Sk63QypD3b4oXDO2i6MtMx4LPWKyWwBPN6i8UaXedbHwVIorsntF/TkHR4++HorqefohV8DD LSpDHvqEa46Hyd+vONlcMaK50Q88/VuVd6jUu04/R4Rg/SzSzx1q8729yAfz9MKczP2kynBu9njM DT9Fc1fURh7foTKkD1+HBdD/usqQ/jHhoF9WORX9qzQDMYf9wzl6hPuGgDm+ozKc43fCNSsD9+Ah /W8JB13o/7EgpN8qHPTPVp8iGcbVtjWKk9P/MeUk8hdPdfYIXAbbpl9iiJM+s9QXgJfWAGZ713l5 ysaSO6jTP5TnHuGQA3luE4TyvE845GGtKJLnLrXxBJ7xz1oEP/hdyBcyhDz0CLdFc8AD84c8MD+g dyEPFbXhd8iaRx+a0P8zQUj/b4Vrhv420UePIf07hNua0t+eQ/97Kf1Gfo3NoZ8nA3NAGxmqglCG HwiHDI3m2Bq5OfLkOKg5dokGczwmCOf4kXDMgV2LfGG72rIz8swjzA+QrTUFw+GXtv61qz5foFdt LYMXePqkIOTpIgkMT3oX8lRRG76R5//43qc0GPqfEYT0u5qkX+Qb0P9sSv9zOfQva5L+lQW+B/3P p/SfyKG/ukn66Ae7+PpfrGtw56V4FclrhYwYy4E6dIWtuEdfkNbFQm1NVpfCuj8PMgDdgttF4AaV fSqh5d9DPJ/iinyvov7I4c+Lvy0RwGdYz+OBfQE83KIy5KFPuGZ5wLd9+ot13Sr4Q+jygOZBlzsl xz0qR1TqXafLl4WAnyJd3qW2+pzu1tyinI5u2wXoWa9a7O7XBXwcVhny8Zhw8KF3IR8VtfFsx80q 8+hDF/pPqwzpHxOuGfpXyWdCe/VoLPBVAfRZ80P6x4Vrhj4+yb1dyP8DwkEX+v9HZUi/VXjow1uR nbarrSOx1FUql2nPsDC+VPOR6xhn9uJ6VgrUsX3ID/LCB/y8ojLkZ13Kj4pCfipqW6b7U+YK6d8j 3K8F0D9NENK/LqXfaK+xKLb90cJ4pT7/8GVrRkbmhoczcnjoT3lQ0UDGJAXmynimBkP/TYJQxkHh sOl0ZLwsilZPV8Y3aw54uEgQ8vAh4Zrx22XSQZEdl6f0u3PoH0rpT0fGy6NoqS+j1SmLfJW5kfGG HB6+lPKgooEdl3+ySEb2BNBnHQh1+LRw07XjKn3iZHKZn1JOJSN7PXjYncPDCykPKhrIGHUWybhH g6F/nyCU8UXhpivjFVHUO10ZmRse7s/hoVxu2leX5sl4QLp5IKX/yRz6c1L6+FhRjr1LbX7O4TNX X0armx2L/JX5kfPTOXx0Ni3nrtyYRM7PpPS/k0N/5QnJ2Vknp/lsIzn/a8rHd3P4uLtpOfPvtZDz 2ZT+P+bQ33lCcnbVydmsPZkfe/6vHD4+2LSc+TkWOX+Z0p8vWmFsPnRCcq6sk7NZezI/cp6Ww8fX Uj7UXBg/FbUtiz6xLi8++9R2ekp/YQ79Z1L6jL1JQGkvuw/pEcLi02xHP+rtgvkCvcqL9YfY/EPs wfs0j+0Zn1f9nVIQOrL7GfZ2rwrgcyq52M/xfRyTB/6BdoHJ1aM68A8C/OSHKsP5FqfzqSicr6K2 Zen9U0j/gNpeEED/NypD+ktS+vBWJM9dajM7ObkuPyF/ZH744Cwv5OPmlA8VhXxU1LZMn5ig0zw5 /0V46J8nCOlvTulPT073uSjzAeajlNABQj6wJ/PDR5zDx7tSPlQ0kLM4j+IT0L9GEMr5buHwz+nJ 6X4/2uS0spGcazQPfKwThHx8QTj40LuBnPn3HPjttRoM/T5BSP8J4aYrJ88dmg2nY0/mhw/O2EI+ fpjyoaKBnGsL/db2iO/Nof/jlP507MlzT76czdqT+ZHzYA4ffA+gOXtuyJWzT/r585T+h3Pon5rS h9eiPNSjNvJQHPH/wtTH5BJdzxeEZ0U+Pi9W/0PK08dzeDq/SZnzPm9bLF6w2R9izXpQ83QL8M33 qnyfSr1ra9Z21dskS5vKIt1in7zzX75XxHkEsqBbSsBw2MHOgLFduwA76FU7S4IneHtSZcgbOHiD 3yLeKmrjObarVObRPyw89DlLCukfE64Z+lcpNyBTHv2vCg999gUh/eNN0of/vLOk72s8dKHPvX9I n/0G/J+rPkX6uUdtW3WKFH7j+9rkEyqe8HG/kOROmuLaWmb2xG6tAmzJvT912vAXw1PSz8Zwjb4Y A55x7QLf9tgFmZDt3+fIxnkGsp2pfkWyjahtSJ+1Dem5AJ7pd9Lw3ZtNko5f1OWzN3cGDk8AZ2dW pzS+TTZrN7+lD3K0C3z+e3T9QfEI/w8JQtucRUw15bs7cp///LLoQxf63IuE9PlNOOgvUL+p9HMg iqUf97tsfXoKns8lM6u7MzfshozICviyN7Iz+gOKdPTLVIZf58jA/U5zOlqT6N63weKU1+nmUJ8G NnxGYLHbIR7J+XrX8iMxxj3MWcIV6XlcbcTYWn0XYzh5difUs0WX27ehK/zMjxf8r5Gu/ZjK0/dh 0UAGfOUBQSjL/aksZ6pfkSwjamscU2trvoK/WMxQB/AHZDuRmHqPeIR/9gMh/6fIDthCTYX8V9RG Pp2jMrT1l4WDLvR/Jgjps8+A/gL1m0o//79j6uepDOSFUIb3pjKoqVCGitr4/GK+Sl9Hi3WN/U42 ptAzMcVebqHgcYHedTHFZ7yN9ExMdWt94ptaPAe2XxLxpNxuXe/Ris9nI/haGE/gkAO8+SDXBtbu x1O72tGHXrW9ySIxjQzcU4UyHBAOGVQ01HOeLx7WOOhCn7gM6b9bOOifOQX9EbU1jtXfz/p3h+Ym x8A/MRXyzxks/Os9pX62ab+OPYA8GxCrzMF+IJyDs6tmbYDtffqLdQ3uZH29RzS6BfB2g8onVOpd 8/Xtql8tPsEV5ZSK2vg8NE8Hf6m2GwXQ/5jKkH6fcNBnzS6iv0dtfOsx77mkMe3hbd1BHwbEjtWJ E+rgbG/QrnoYL/AHn0+qDPn8nnDN6WFTtFh98+gfTuk/nUP/mHDN0G/0uTD8k7tC/o83ST/Wc6h5 e/nDKV3ovyAI6bPPgP8/0TxFdvyW2hbGazQDvxvArzRlOzn29+53Ad3v7bpd/aI4jg5EcTLK/bI6 ebQ/ers3MuuTfRcq+xUCa8X25gf4Auu7v3/Bd/1rq4MPfSfsa3maMdT9uWy80TC6XOfRYaxPJ9yb MM5wRgs6Nq+NbRfO/Hux6ow72VzxomyMb/1nlZyPf02l3rVcgQ9sEn6dcEU+8PdqWxiHd3PZztPs tTDOfneA2O/V5/fuW15Zj/A3grC6+02Z+l9wqf/9Fht/fsl0bbagBGdrLrpE16Zn2mmjD2ui6Zpr y0Fmbx/HOMCnk0cjnMvsauPM7jYXNLCxT5++jINP60/Os7zHGJOBvta/XfWZ9pft8gf8BT95WvBd gd51/sJnb8uFK/KXz6ptYVxs6Szm8628MK73nh7twuz/YjgQxYktT0TvplvTPaXhmtF3I/8gV5kf Qpv+APaibBfMtL3+TjSxF3ZaLfiBQO86e43IXucIV2Sve9S2ML4puY/kVwl6FLWDit+KIrj+2w1j Ou90siCfD8iI/JTmt6ZbZKev4f14Ax/qpkc4AHmQ608FoVyPC4dcKgrlqqgtFjBHu2Cmdf+oaHYL joqJR1T+VCX82Gdz21W/TzyeprJI93vUVnxWEtd0bLpDFj+XcI0+0Tt1u25X3eQ1fX5YOHh9UmXI 6xHh4BX+i3itqC3WLwAvVZlH/7Dw0H9aZUj/mHDN0L9KPxWAH+XR/6rw0MffQ/rHm6TPrzLk7ZXu 0XjoQv9HOfRZJ+Gf+C7Sz11qWxjvUPTwO8qsfO75uVbhsY8P4EIZP6k5fix8woPqoYwXpjxcoT5F PDyjtt1136m2tXNh3Kd4hrf9imLbow0q6vle9p4Az+8I8UsAtJITshGs1lV9V8ynsz7xOz/efX8k vucIwFEHkN/Xi61vtPn9fL/Hz22M9TffD+kafb80upRWZ5zFE32hS5vR9/lpF36+QK/a/fqPZBPs 9TNBaK93yV+a8Xm+H8rcPv3FugZ3svs/YrJbAG+fU/lPKvWuy1GciZ4pXJFPjait8T2/kwGeAfMF uzY7oVe/3bcvum4XhDr+vHDw/6TKkP+fCwf/yFTEf0VtsZ7Ehm4efXQEffJWSP+YcM3Qb3SPB33y S0ifvNUM/aLPa+Dd8uEszRHSJ281Y1926vxC0bjOt2L9L1Jxsnd3mFi/MML3BrAbsWElNgUs9qhb m5Vhe7v6hPadLR7RzzxByP9dwjWnn5n73kHI44B47hbA21aVv1Wpd10MPS4fRA9FPniH2jId9+Tq KZy3R2OYj3nx/XDetwvHvPBSNG9FbZy77lWZR/+w8NDH90P6x4Rrhn4j34c+PhrSx/eboV/03PsT KV3of1YQ0sf3oX+l5inSz7fU1qHnMDsityJ26DcusnqXV7/Eq1/q1Vd69cu8+uVefZVXvyKpXxm5 38Ns1fwWP8SW1Q1P/OTh6ZeH/9fWHz7hKc/3sBm2+2tBaDu+z9Scb+xPYsmnv1jzob+TXTt7RKNb AG8bVfLMiap1cX+4qfjbOYnHBaIzXwC9JWkdPRXVffnga0RwnaBV879V5Tk5vH1buDlqK/L9O9R2 e/L/X41qR7c62RejNwC7Ufo84W/GX1hvVxvy6FXbGw3oAv5GVYb8PSgc/CF/EX8VtRH7c1X69Bfo mrkY6+PRy8OCbsHZov0+lYvTOfx7sqPCMb5o3j61FZ1dt6oNQK9WR1d2bfsbcMzRnpYqanp5vy7g 77DKkL+vCAd/jfWyVk+ITKb/ZeGgC/05IhLSP6Y26C9QWST/iNp6Er/gN703627ietkBH/FP8+O6 sw6RTK5N/lm6tvw0lb4Yl6cjeEeGthwZ3iJcMzo6K578/1z8P97OJsTOq4zjk5CNNq3TKHjRVq+1 SoJhEqtVLCpGahmbVgYzYBdZpEkmDZgvMmnSQMXsjKBSabswZuFCUEtwk1sVKVIEdeXGbPzYCAq6 cDGLuhCK8fd7z/3fOff0vpmZjS+c+5zzPM95znP+5znnPe/HvXe561uxq/27Z9hf2aR9Y9M+tv7/ Ed492ND+pRn2T47tvxu9vjF4Hpm/znGCq6/yy73536/7huv3z+p75uvP3Iy9ehwsi7NjYpyalzqv pOpG37EyqStNbA/IG88ckzi2b/bxazP6+O9xHyG9fVxCttX5/Rx1FkkP0O5Z6D6obdTz+x/w7E8f toeRTX8nscSJ/Q0Omb/iM6vv5+Drwwja+vAyPH3YTN/d37X2X4enXe3vxEhrfw2Z9t8J7evjBWSZ w3f+Z7r1vtt/zE7Wfsv2XywSD9GRhpcY6sPKPtgX51rblxPwNouVvg1IdRw+SH3nWjcWM+w717T/ IPX6sHoJ2SqzzGdcPqu6wLw7Pufvv3j3w/scXg353Otpcsc6rjrl9+yMpFX43itd6fASmzqJnym8 FmNxFDvXEnWMQfWl6ipL3dqOeeWJWfVSjt4AXo3XMuXRtoLXq9B2PB7DwObG4wtdW63957CvXcfj DzPsL47t63PfeBxG5v2z8mu5x/n1nfJOdnBK38TEfOuDfbw19uFPM3w4t+k+nt/S3uMq7S6SxPTr 0E9DaX5qbfoPvLfD6+v7EWSz3nt1rRYzMbDfpoy7GDjGffNPX/TpJrT16RV4+qSffT4tIRuSHiMN SLbF0Z0H3iQzImn/8xhp7a8h0/790D77V5GVtar8enmZSUNmY/v8wafIZW46//yNk1VcCw5ikrlC kx0+iRXLwUyedeyHvOhIE2PyTdar5dbpw9n+i8PiDBx+Cm9zOB/bvZX97g38WSR9hnZfhD4Opamp mLuLhWUeXh/+p5C1T3fbtwkTdzUWYmhSps/BUl6wlGd5QBI7jsn+4SUK+j2Ctn7/Bp5+25c+v5eQ DQnLj0Bb+9rWrvb/Bm3tr8HTvj712T+OzLgs/x1cPi+M98X2yb7tIBkPNDPJY3YSM+ooa/17Hp5+ 6d+9dLL1bx88/bN+n3+HkZ3GuzOk093bx8OuP/oU33aO89JZfngNbvv64ftTrR+nx348Qv0+P15H 1u5V/Y+JvDU35Ix5Ys4z5Bk+9bfM3otwTo05Q2byyvjcerw7n+6mvMA9yQU0PsUdmv3Q8rbJkHs0 D1OyjyZjLeMR7O1rcFAnMSlVJ/XUS926Tl+c1zrms96ExqfEROzYpu3oU9q0HH+iJ63llgckx49j +y4+zG8j1fxlyjJHEMfws+S/AlUve+M18vfjiPdF+sbyKrISU/ml7b1zw7mP8c3B6RFwZ7SC5CRj 6/vdan14uGcq/sQi/RKPWX0PJtFL/62bJB7Jx2ZseS5tMRILkxiIxaPQFoufwBMLSC8WS8iGc+/Z 0h7gOnUWSU/R7jehK80YHIG3j3Z97tE3BieRrb9d067EBQv7LxbiKoZ3Wn/VG5CMG47J+qt/+nkT 2vr5c3j6uTE+q8zOt9p/E96IpP0FjLT215BpfzP7glnr7+z1xf+uzfvwi5N5LVaZj8nT9CQ2xQc3 Z64XkUkTm5mz8tpxGMBrcbb/4uCa3uLwIrzN4Xxg5vr9LeuP7fseeWv/5bH9h/GrL95+gczzmlc4 69c3Pis+063EOee1K/cq2rtB3OfEZVfmqjAkf6Y7G7lDW39bMGeB9fve4iimjoXjI54mecpqbB0f +dGpxyv81EvdjHnk8tOOedut7SUvdQzViU2p+vKU237k5gekjPuucR7op/jLlL0eHUEdp++RPw9V r16jD9DQPnh943UD2ZMgewx8z0496z/YjZnXro5VfffuacbpbPcfQZ6HV5H1v3WyB+vpv3gFv+Bj OWMTXl0Wj5TNi1Nwkx9e6kYWfsZNuTJ9ie5G65z2B+M6kMladw2QxfwH0BbzD8IXc0S9mC8h2+q9 quvUWSStYv8q9ArUNjLWR8gfot2NzgX930co98btcz1OidnEutiJY8ZxFj76p583oa2fP4Onnxvj c6z7f/DW/uewOxrb935ha39tbP8Q9AmS/cmxn3aHMN6A0bcXn3UuKLv2fIfD88Kz7B5PsDadZxzL ftT7Nd7N8b+0nBFlzpS16+iU5heZLdN71vXzszXrvepXp2I9sWyfzNOdyTg4LsDR9de8qR4nZfIc t+RjJ2OZsY48+rU8stiJLPFRl9W1De2knvl6DsZO2qrrxJbUvpi0F1uxbdvKgk/qKa/rDCjbNscd 977LBOcIpSs0dJH8t6GQyVxbI78C+HuhfTH2Q2QfnXuI8cx1hvf7LhMJ3ocwPryKWR/5dmemhtFw 37B9q2rPFBbpq9R4sL+hYmo5MvEw34ffRuuh9bQRnKXtWNqmOhkP26txX6Z8neT9fvF179zi+wY8 8d1oLVsAny8x55xNj5B3b1FQK89SxME9vT7pRx0LluNr+tP6+QI6+qeff4a2fn4Svn7ehV5fHBxH Vny6NNkVlT1Q+S5l2taG/mS8xDo+ym99E0d90re/zPDt8tg3RL2+LSHzPGRbtf1dlB1X69Z825xH eQT9DvQ2Ct+Hqpfz0Br5S2ByENqHyd+RPco88B64/+hSvh/nGy3lqt4Vtayuq7xvUa4LfVOw/Cuh V4fZRU6vxH5z5DJS3y9z9+m66/zzmdepLuf6bG33ku5HfUepfNOk3D34eHftkzGQir3JcarHYwfl yIGg01EeHal11ItcO46z9ZLUi07qqlfXkW+yjlSZ4xMbrW5dNh+7ttO2FXtSkzbTX3XlSeWZlMfG gLx+cNxxPd2LEyOUrkF3kn5E2ka5jpmrxMwSvL6Y+Rcy3yMvZ07Prs8wkquMd7mz791bY6Wcd0t8 lDvAfsvI3CpSz+6rXW79Gcwl6pT4KPHimfwCMXOeNsqVyLPkjBNjaHbklRkuFmIkZqHBTtzodhcT 5ut4sl5wVid1zMeW9qwjbe1EVtdV1yRPuW1qK34Yh7aTFL3YT7stjS3XVvMmdSxrSzupE1u1nrL4 En/j5wCZWHDcMZ5OoTAi/RgDv4W+Ct0mffLWgWcu3TqwRv4aDtnWEyT9yrEf/hDGUzCyMiywBsZn dZNqf5bhm35Hst3fQ9t234YTtqsvfe0uIdvq3t92F0m29zj0101/j8C7scl2UXvLmq597Wp/Cdra PwZvs/bdQ9S4fZnyOQAR33mSY5/jNdrz2LZ9+wOHqplcuFv/HHK2/+WOubm/fuOhrvL/c33wLL/R +lDuP8/N7f/uK06/uXMvFLrz3qO363LnfPVBl7oj+r+6++jt/wKkOHv8c/CBXccvdlNx8k6VeH+I 5Hwy/17SPCnHJ8jMjwvOh5QzP+qyaimPq0zsGeumyM2/v7Ln/ai23Opbjn+GhCn2zL+vsreAvbbc 6ltO34HpSvKwr+znQ0zeUfHZZ145CG+e5CFeu0nq6Vvy2k3eeZS845O8de8hvYvkMU8y/z8AAAD/ /wMAUEsDBBQABgAIAAAAIQCnL0E9oAMAAPIIAAARAAAAd29yZC9zZXR0aW5ncy54bWykVttu2zgQ fV+g/2DoeR3JqmN3hThF66x3W8TbYJV+ACWNbSK8YUhZcb9+h6IYJZs0KNonk3M5M8OZOfLF+3sp JkdAy7VaJbOzLJmAqnXD1X6VfL3dTN8lE+uYapjQClbJCWzy/vLNbxddYcE5MrMTglC2kPUqOThn ijS19QEks2fagCLlTqNkjq64TyXDu9ZMay0Nc7zigrtTmmfZIhlg9CppURUDxFTyGrXVO+ddCr3b 8RqGn+iBPxI3eF7pupWgXB8xRRCUg1b2wI2NaPJn0ajEQwQ5vlbEUYpo182y1yyHcjuNzYPHj6Tn HQzqGqylBkkRypWMqweY2fwZ0MNTn9FTpyF26qHIfZb1pzFzK575v9Dt0MVrXiHD0GYaAJ+FrItP e6WRVYKGqpvNk0uaqG9ay0lXHBmBV2DdhruE7gawpqatknz2R5J6QypO70rHHJDaGhCin9daACPw rtgjkzRpqyRIep8GdqwV7pZVpdMmhlnmWYCsDwxZ7QBLw2pCW2vlUIto1+h/tFvT1CI9avCw7Ag3 CEcO3Q2vXYvQxwmj7bMMpzKsCQEpJqnYIB1Gf6sb8Am3yJ+953f74R36N6JnexTy/4E0rTXyBqhi AaU7CdhQTSX/Bh9U87m1jtMy9QvwCxm8lgAoH/kLkcDtycAGmH8jWrSfLve1YH2DNoKbLUfU+Ek1 NDK/GiyNTfTtJI5sbDz8q7WLbciy9Tqfr/8M6XmzUbPIlvk8f0nzfZ+rxXJ5/u4ln82H8/WyH1jK bMhHFp55bvDyIpx8kycyDMiayQo5m2w9N9GoyKLCu49cRX0FxM3wWFO2VVROp0FhJRNiQ8sRFX0C smi4NVew62HFluF+xB0s8EUpLeLnByy/2IB/oW5NiNYhM6F5MdxsPh/wuHLXXEa5basyeinil0eq VjVfjugB0/F5usLRZ6lfgmum9rFHoKZfS29KvRZY+k8XbJkxxAFkUu1nq0Tw/cHN/OA6ujX0Cesv 1T4fdHmvo5vX9RdW+8rIejh4g3Akq+Ewyt5G2dtRRgQd7Oaj7DzKzkfZIsroE9oVB9o0JDa8IzqJ Ry/faSF0B83fUbhKnonCI9gDM0B99WRJ466LXjCwp50cC7gnKobGc7M1vJHsnv44ZPnCuw/Wgp10 657Yep03Nk+kk4Y5Ru59q544U+uI2p/m0hUN1JzGsTzJauTms5C44NaVYIjGnUYquafI33vk8c/K 5X8AAAD//wMAUEsDBBQABgAIAAAAIQAlMTZF4AEAAKoFAAASAAAAd29yZC9mb250VGFibGUueG1s tJPdjpswEIXvK/UdkO83GMJud9GSVZo2Um96UW0fwHFMsOof5HFC8/YdbCAX2ahJtQUJwRn7aObj +Pnlt1bJQTiQ1lQkm1GSCMPtVppdRX6+ru8eSQKemS1T1oiKHAWQl8XHD89dWVvjIcH9BkrNK9J4 35ZpCrwRmsHMtsJgsbZOM4+fbpdq5n7t2ztudcu83Egl/THNKX0gg427xsXWteTii+V7LYwP+1Mn FDpaA41sYXTrrnHrrNu2znIBgDNrFf00k2ayyYozIy25s2BrP8Nh0thR2lvh9oyGN61Ionn5bWes YxuF7LqsIIsBXNKVhmkUV0zJjZOh0DJjQWRYOzBVEZrTNb3HZ38XdN4/Sdo78IY5EH5aSKNcMy3V cVShkwCx0ErPm1E/MCf7hmIJ5A4Le9jQinyleOXrNYlKVpECheVqUnJsKl7ZsGY+KZgcbCz4hCXZ U/BBBX2GXaHPNEbnjMSr1AKS76JLfljNzAUiOX1AEvfIoyczv4mIC76B4A1E8uU0P06ywlE+PRbj /CciT38nEn2uJ7JiGqPBLpDoCUQSPZHbsvFvJM6zQYuJzYlESAIm6h2zsUQM6gKHz5iIAucf7/9/ Rt5MxHz4/ycO75GI4bDA4g8AAAD//wMAUEsDBBQABgAIAAAAIQDiU/kt9AoAALpjAAAPAAAAd29y ZC9zdHlsZXMueG1s7F3bcts4En3fqv0Hlt4TXS3ZrlGmYiXeuMqTyUR27TNFQRbXFKklqTier99G A4R4A9kw4Vklu5UHi7c+APrgNNlEM7/8+n0XON9YnPhROO8N3w56Dgu9aO2HD/Pe/d31m/Oek6Ru uHaDKGTz3jNLer+++/vffnm6TNLngCUOGAiTy503723TdH/Z7yfelu3c5G20ZyEc3ETxzk1hM37o 79z48bB/40W7vZv6Kz/w0+f+aDCY9qSZmGIl2mx8j32IvMOOhSle349ZABajMNn6+ySz9kSx9hTF 630ceSxJoNO7QNjbuX6ozAwnFUM734ujJNqkb6EzfdGiPjcFlw8H+GsX9Jydd3nzEEaxuwpg8J6G k947GLl15H1gG/cQpAnfjL/EclNu4Z/rKEwT5+nSTTzfv4MhBQM7H2x9eh8mfg+OMDdJ3ye+W3tw y8+qPeIlac7alb/2e32OmPwJNr+5wbw3GmV7FrwFhX2BGz5k+1j45n6Zb8m8p3atwO6858Zvlu+5 sT52M/ub6+6+0HnYwqbsXQ+cATjuJmVACuAIxwl8zsHRDPgiNr4e+Li6hzSSIGgAwPJmYbM04sAV YM5SEBiOss1t5D2y9TKFA/MeYsHO+5svsR/FQNJ57+KCY8LOJdv5n/z1mvH5Ivfdh1t/zf65ZeF9 wtbH/X9cI/mlRS86hCk0fzpDFgTJ+uN3j+05bcF06HIPf+YXAHHAHTkcbNDBP7ZG7Cih4s5/Z5BD 4cNalC1z+Qx3sP2NQNjrQ2egEe9RvgNo16it4+4mJt1NnHU3geTtNhaz7q0AXe/qEcGNHCvpTk0j T5AvPw7jiwbK8isqLGq9okKa1isqHGm9okKJ1isqDGi9ouLw1isq/m29ouLOxis8F4WrzKIxjgZp Yt/5acD49Y0CNOwodTLUOF/c2H2I3f3W4YG13OwmsbyK1s/OHfuOF5F6tjysUlrnUIBfLq/LNI7C h9YxhHjOJ/uLVfzjbr91Ex/uq1qcNerorDt+n+T8I/bXrVBngq6VPuGtTG3Q+xK4HttGwZrFyp3V MdFf/zlyluK+pLVxHd166z9sU2e5xSDdCjbVDLq+J8L+rZ8gpRun31TTlTbjJB9ONbzUG/+Nrf3D Lhsawv3LVEQAA5qUILCJzUM04S4yYZKE4A6gdEEEGPMuoH1C+0U4MrfPfUxpvwheL7RPaL8IdS+0 j/xo9q+x0nyAx1yHNL1mxnN3EQVRvDkE2RxolYeZ8QxWELQuGE9iZZ8kEjPjGVyQT+e958GzHoWn xr446qgBirE7BApONnpfjJ1Skr2hQY+MHVTCGhlgddNaAyBj0f3Kvvk8i2YaDFCl1d1p63Qea0YA QhDp3vSPQ5S233WPNJpHRbkJIcGSMIeGNtbMPCpaPp6akKlb4DMgU7cIaADULRQaAGn4ob9zUzGR DtI9OBpgGcuyimI4gcnKPDNWZgVkFgIsxU3C/Zdm9uq5UI2bBBRjB1XjJgHF2DulWKbiJgHLWtwk YGmiht5HeU016ZRx3MwDKfEm9MiOeBOA7Ig3AciOeBOAuot3O4g98SZgGWuD0tS8eBOA8BSTR30F lBdvApCxNgi1kzmjLO6hleaHWwviTUAxdlBVvAkoxt7RiTcBC08xYUIJS0kdAcuOeBOA7Ig3AciO eBOA7Ig3AciOeBOAuot3O4g98SZgGWuD0tS8eBOAjOVBAeXFmwCEp5hoQ61446x/dfEmoBg7qCre BBRj75QEVd2kErCMHVTCUuJNwMJTTMggsZDcJp2yI96EHtkRbwKQHfEmANkRbwJQd/FuB7En3gQs Y21QmpoXbwKQsTwooLx4E4CMtaFWvHEyvrp4E1CMHVQVbwKKsXdKgqp0joBl7KASlhJvAhbypbN4 E4DwlJcCmfTIjngTemRHvAlAdsSbANRdvNtB7Ik3ActYG5Sm5sWbAGQsDwooL94EIGNtqBVvnCOv Lt4EFGMHVcWbgGLsnZKgKvEmYBk7qISlpI6AZUe8CUBIzM7iTQDCU14AhLPIxE12xJvQIzviTQDq Lt7tIPbEm4BlrA1KU/PiTQAylgcFlBdvApCxNvB1trBelLw8daghAXWdQbaqgQw40jiJCig7+JVt WAxlWax9dUhHwKyHBogaelC7eBVFjw5tKfhYQxAylL8K/AgXgT/jKp1c6cJ41lB7cPf7wvkkSmYq 1yGliitvoN4oX2CEBU281AjamT7vochnn61F59agpIhXgsmiISyqu4ESIlkIxC/mlUFwIpZhyd34 3lai4m8o4Ftn5wwGi8VosvgoeqQrqcIXP7KgaqI26guqZPEW/ClUpc17CzfwV7HP+4EFZ4U9XnLc hEbmSsCwly3jokZCjvwQi6byY3GsYsIhWLlQe/U7L6WqjFQIq/ez/Xw5P67mx4tgAB6zIxnQYuvG YuyO1SnZObJExWjoHxnbf4YWICDfuIUytgS3wsNOVLzBjxvlQKxGgOFSRxNVD7diUE8JFJqcD0QT o0PKnXj7LciaiAfgaul4qC7kI130XFYY6P6roZ6QH/woawyVh2uvPJYU8muOJYUr4ZiF6KzHl65m rRxPz64vUK2wGhFjBlTy4WLN427+PhN6e3UtOpsrUTzP9uRKFHFfR5qNtDSTRZG2aDYi0Kx4q4eD aZ15fnCkjiyDMSUjr87ExlXJmFH5tMk4uT4fXn3gHK8jI3YtR71pDfVwX0fqjbXUGwtEIvXyMaJG 38YnSDw5tywSDy2evAq2Eq8jpUS9eV3QnNik1OQEKSXnjEVKocVTpJSPCuXXhdnXJtiZVrPObBLs jECwY8IOh+Ovjp1yQlnkG1o8Db4Vbt1Gk/G1KDqsi5ZZEF2KW7cZ3rp1lLGplmUyFtuJjNPTZ5mc VRZZhhZPg2UNOvbXc058pKMudMpUgR3OzU6fc3KOWeRcdrd8Ak8FDZybDPi/8lNBCk/yxwfUO59/ 0kU8n3YUuXOtyMlnXTuEOz99wskJZpFwaPE0RK4QSk0pVvhKk3zoTv7MpUCy5A9mfaDDL8m0XWiJ KLNfdoh4cfpElBPPIhGzFNXPpXy2aOlB5tX14ItfXHQ1iXH5QRdVMYufcymnyTVffREPBirtn+Ui Zdqr7QFCP51S/t2Shjbjd00aM/oOniIemWqyznLitbUQ8lerQOR74cdNyDPK8BE8EcPw1cP6uytA 4PiCBcFvbszHLo32+lMDtuHZczA0HOD7WvEWQ5laRWka7fTXx/g5E60BGNZ8Y8Qm74R+vGFCrlgM XzBrGPPPEX/PWZEy+IoL7tdQAT7zhkfaRlrftgKHvUMCQ7Pkb3/KL3gKbxvK/JUHnaFzFMmS6tbO A2x7Tc5PMryGWaK7+tdH/399IIMo8Fvw3tDBIs+vc/DIkoNlAvXncXBr4qoQc+QjSuFWKHvIaLkV MnSnyJ7r3Dm25E6ZvPwfcicIql1HiZy0zlETS46SWb8f2lFNj8BtL8asu01kenVuO7PkNplG07qt FP5PMzwWniRfJUFmqI0if6rz3dSS76TW/9i+a5hzp+BJkZXUeXJmyZMyz/PTetI0u2NdTEWuT+fG c0tulFmSH9uNBTE1dVzhXrRDWs5Qb0UGTefeC0vulU/EP7Z7G/T2v+XswipQtdpRLU8su/X4GWJ8 yC9lA3RrfjJzi6Y1jdLDRkvLjksS5Sf6h/DxX2gZaBglt1n4jwxM/68CezpZGB7tiHedSBmKyLXU TCTpAN1tJvRX5vGzX8m7/wAAAP//AwBQSwMEFAAGAAgAAAAhAEjxkoV1CwAAq2YAABoAAAB3b3Jk L3N0eWxlc1dpdGhFZmZlY3RzLnhtbOxdXXPbthJ9vzP9Dxy9O9aXJdtTpRPLceMZN00je+4zRcEW rylSl6TsuL++iwUI8QvkwoR7lfROHixRxB4Ae3AWXHKZn3/5tgmcJxYnfhTOeoN3/Z7DQi9a+eHD rHd3e3V02nOS1A1XbhCFbNZ7YUnvl/c//evn5/MkfQlY4oCBMDl/3nqz3jpNt+fHx4m3Zhs3ebfx vThKovv0nRdtjqP7e99jx89RvDoe9gd9/LSNI48lCaDN3fDJTXrS3KZqLdqyELDuo3jjpsm7KH44 3rjx4257BNa3buov/cBPX8B2f5KZiWa9XRyeyw4dqQ7xJueiQ/JP1iKujKIGV7S8jLzdhoUpIh7H LIA+RGGy9rf7YbzWGgxxnXXpqWkQT5sgO+95OxhX8NSQKT64jN1ncMXeYMVczWSsRKNNIOaB+3fv 1bLFQb9pMNIj3ITqA6ULRcysJxvXD5WZ101NfnJhPXTh969xtNuq7mz9btauw0dliy9Lg571J7jy 8kNLjAxUlu5i7W5Zz9l459cPYRS7ywB69DwYO5yRvfcgFavIu2T37i5IE/41/hLLr/Ib/rmKwjRx ns/dxPP9W5AQsLLxweCnD2Hi9+AX5ibph8R3a39c87Nqf/GSNGftwl/5vWOOmPwJNp/cYNYbDrMj c96DwrHADR+yYyw8ulvkezLrqUNLsDvrufHR4gM3dozDzP7mhrstDB6+YVe2rgcrD3Dc+5SBCIGK cZzA594dTkHRxJevOz657i6NJAgaALC8WfhamnHQJlCqhVBs+JXd30TeI1stUvhh1kMsOHh3/SX2 oxhkdNY7O+OYcHDBNv4nf7ViPEDIY3fh2l+xf69ZeJew1f74H1coz9KiF+3CFLo/mSILgmT18ZvH tlwmwXTocg9/5g1Aw8AdORzs0M7f90YcKKHiwf9mkAPhw1qUNXN5SHOw/41AOOpdZ6AhH1F+AGjX qK+j7ibG3U2cdDeB5O02F9PuvYCNTFePCG7kWEl3ahp5gnz5eRidNVCWt6iwqLVFhTStLSocaW1R oURriwoDWltUHN7aouLf1hYVdza28FwUrjKLRjgbpIV966cBxMkWpRt0lDoZapwvbuw+xO527fDA Wu52k1heRKsX55Z9w0akkS12y5Q2OBTg18vrIo0jvkFtmUOI53yxv1rFP262azfxYR/fBtTRWbd8 s+T8GvurVqgTQdfKmHArUxv0vgSux9ZRsGKxcmd1TvTtP0fOQuxLWjvX0a03/sM6dWAfyYN0K9hE M+n6kQj7N36ClG6M/xPNUNqMk3w40fBSb/w3tvJ3m2xqCPuXiYgABjQpQWAXm6dozF1kwiQJwR1A GYIIMOZDQPuE/otwZG6f+5jSfxG8Xmmf0H8R6l5pH/nR7F9jpbmERIxDWl5T47U7j4Iovt8F2Rpo lYep8QpWELQhGC9iZZ8kElPjFVyQT+eD58G1HoWnxr7Y66gBirE7BAouNvpYjJ1Skr2BwYiMHVTC GhpgddNaAyBj0f3KnnyeNjYNBqjSanfaupxHmhmAEETam/6xi9L2XfdQo3lUlOsQEiwJc2hoI83K o6Ll46kJmboFPgMydYuABkDdQqEBkIYf+p2biol0kO7B0QDLWJZVFMMFTFbmqbEyKyCzEGApbhL2 X5rVq+dCNW4SUIwdVI2bBBRj75RimYqbBCxrcZOApYkaeh/lNdVkUMZxMw+kxJswIjviTQCyI94E IDviTQDqLt7tIPbEm4BlrA1KU/PiTQDCU0wu9RVQXrwJQMbaINRO5oyyuIdWmi9uLYg3AcXYQVXx JqAYe0cn3gQsPMWECSUsJXUELDviTQCyI94EIDviTQCyI94EIDviTQDqLt7tIPbEm4BlrA1KU/Pi TQAylgcFlBdvAhCeYqINteKNq/7NxZuAYuygqngTUIy9UxJUtUklYBk7qISlxJuAhaeYkEFiIblN BmVHvAkjsiPeBCA74k0AsiPeBKDu4t0OYk+8CVjG2qA0NS/eBCBjeVBAefEmABlrQ61442J8c/Em oBg7qCreBBRj75QEVekcAcvYQSUsJd4ELORLZ/EmAOEprwUyGZEd8SaMyI54E4DsiDcBqLt4t4PY E28ClrE2KE3NizcByFgeFFBevAlAxtpQK964Rt5cvAkoxg6qijcBxdg7JUFV4k3AMnZQCUtJHQHL jngTgJCYncWbAISnvAIIV5GJm+yIN2FEdsSbANRdvNtB7Ik3ActYG5Sm5sWbAGQsDwooL94EIGNt 4M/ZwvOi5MdTBxoSUJ8zyJ5qIAMONU6iAsoBfmX3LIY6RNb+dEhHwGyEBogaelCHeBFFjw7tUfCR hiBkKH8Z+BE+BP6CT+nkShdG04bag9vf584nUTJTaYeUKj55A/VG+QIjLGjipUbQz/RlC0U+2+xZ dG4NSop4JZgsGsIq0msoIZKFQLwxrwyCE7EMSx7G+7YSFT9DxeoqO6ffn8+H4/lHMSJdSRXe+JEF VWP1pb6gShZvwZ9CVdqsN3cDfxn7fBxYcFY44kEhXXYCdDJXAoajbJkXNRNy5gdYNJWfi30VE07B 0oXaq995KVVlpkJ4ej87zh/nx6f5sRFMwGP2SwY0X7uxmLt9dUp2jixRMZr6R8a2n6EHCMi/3EAZ W4Lfwt1GVLzBh2vlQKxGgOlSvyaqHm7JoOIXKDQ+7YsuRruUO/HmKci6iD9Aa+l4qC7kM130XFYY 6P6noZ6Q//hR1hgqD9e23JcU8jb7ksKlcMxcDNbjj65mvRxNTq7OUK2wGhFjBlTy4cOa+8P8fiaM 9uJKDDZXoniaHcmVKOKxjjQbamkmiyJt0WxIoFlxq4eTaZ15frCnjiyDMSUjr87EzlXJmFH5sMk4 vjodXFxyjteREYeWo96khnp4rCP1RlrqjQQikXr5GFGjb6MDJJ5cWxaJhxYPXgVbideRUqLevC5o jm1SanyAlJJrxiKl0OIhUspHhfLrwuxbE+xEq1knNgl2QiDYPmGH0/F3x065oCzyDS0eBt8KW7fh eHQlig7romUWRBdi6zbFrVtHGZtoWSZjsZ3IODl8lslVZZFlaPEwWNagY38/58RLOupCp0wV2OHc 9PA5J9eYRc5lu+UDuCpo4Ny4z/+VrwpSuJLfX6De+vyVLuL6tKPInWpFTl7r2iHc6eETTi4wi4RD i4chcoVQakoxeP/C/i1N8qI7+TOXAsmSP5j1gQG/JtN2piWizH7ZIeLZ4RNRLjyLRMxSVD+W8tmi pQeZV9eDN35x0dUkxuULXVTFLL7OpZwm17z1RVwYqLR/louUaa+2Cwj9ckr5e0sa+ozvNWnM6Dt4 irhkqsk6y4XX1kPIXy0Dke+FD9chzyg/y7ePiVsPq2+uAIHf5ywIfnNjPndptNWfGrB7nj0HQ4M+ 3q8tmVpGaRpt9O1jfJ2J1gBMa74z4isfhH6+YUEuWSxfjqLhyeeI3+esSBm8xQWPa6gAr3nDX9pm Wt+3Aoe9XQJTs+B3f8o3eAp3G8r8lT86A2cvkiXVrV0H2PeanJ9keA2zxHD1t4/+f/tABlHgt+C9 oYNFnl/n4KElB8sE6o/j4NbEVSHmyEuUwlYou8ho2QoZulNkz3XuHFlyp0xe/oPcCYJq11EiJ61z 1NiSo2TW77t2VNMlcNuNMetuE5lendtOLLlNptG0biuF/8MMj4UryTdJkBlqo8if6nw3seQ7qfXf t+8a1twheFJkJXWenFrypMzz/LCeNM3uWBdTkevTufHUkhtlluT7dmNBTE0dV9iLdkjLGeqtyKDp 3Htmyb3yivj7dm+D3v6vnF14ClQ97ageTyy7df8aYrzIL2UDdM/8ZObmTc80Sg8bPVq2fyRRvqJ/ MMxyz5TcZuE/MjD9vwrs6WRherQz3nUhZSht6T3dNhPGK/P42afk/V8AAAD//wMAUEsDBBQABgAI AAAAIQCsaimQIwIAAIoEAAAQAAgBZG9jUHJvcHMvYXBwLnhtbCCiBAEooAABAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAKRUXU/bMBR9n7T/YOWdJi0doMo1QoWJSYNWa4Bnz7lpLBI7sm87uid+ yPbn+CW7Tto0jGkPW57uV07OPT4OP3+qSrYB57U102g4SCIGRtlMm9U0uks/Hp1FzKM0mSytgWm0 BR+di/fv+MLZGhxq8IwgjJ9GBWI9iWOvCqikH1DbUCe3rpJIqVvFNs+1gkur1hUYjEdJchLDE4LJ IDuqO8CoRZxs8F9BM6sCP3+fbmsiLHgKVV1KBHEb6JSDzGLF467KU4uyTHUFIqFyl/CFXIEXIx63 AX+wLvNifPqBx23IZ4V0UiEpKEanw2Me9wr8oq5LrSSSuOJGK2e9zZHNGxlYAOBxf4STNEtQa6dx G4j0U/5Zm0CFuLQRcXNy5WRdeHESCHYZXypZwowEELksPfD4UODXIMPhLqQmxnyDkw0otI55/Z2O dxyxr9JDkG0abaTT0iDJF8bapInL2qMTqcaSsKnX5k3YH+vHeiyGzQAFfx1ssXYs/f/DB37tivTd 18s3C/h5TtLhH7QY9bVoaLVK9LbdhZ0EbPdc7a4QszmbX6yxYKNBwl6ef3hF1+Ll+Sd7s1hzCkTx N1IzW9XSbMWXq5tP7Bbwm3WPpMq+HFzx6O/q1F4Gd++O+3WxZ9EHjcWyloqMdDw8IysdzNpr8SV5 GjJy3x7wUODXZA1Xhq/Su2YF2X7mbSPY/779tYjheJDQ0/h9XyPTdnde/AIAAP//AwBQSwMEFAAG AAgAAAAhAHsHw0NMAQAAiwIAABEACAFkb2NQcm9wcy9jb3JlLnhtbCCiBAEooAABAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAJySUUvDMBSF3wX/Q8l7m6QFldJ24MaeHAhOFN9CcrsFm6Qkcd3+ vWk7a8d88jE9534556bF4qia6ADWSaNLRBOCItDcCKl3JXrdruMHFDnPtGCN0VCiEzi0qG5vCt7m 3Fh4tqYF6yW4KJC0y3lbor33bY6x43tQzCXBoYNYG6uYD0e7wy3jn2wHOCXkDivwTDDPcA+M24mI zkjBJ2T7ZZsBIDiGBhRo7zBNKP71erDK/TkwKDOnkv7Uhk7nuHO24KM4uY9OTsau65IuG2KE/BS/ b55ehqqx1P2uOKCqEDznFpg3tloZzRoRraOlqWupCzzT+j02zPlNWHktQTyeru3Xln7KwkH2r1al BZ4fw81D0fF6EFGIno9Ff5S3bLnarlGVEprFJItpuqX3OaE5IR99uov5vsr4QZ0z/pv4A6iGxJe/ T/UNAAD//wMAUEsDBBQABgAIAAAAIQAXoBZOAgEAAKwBAAAUAAAAd29yZC93ZWJTZXR0aW5ncy54 bWyM0MFKAzEQBuC74DssubfZlSKydLcgUvEigvoAaXZ2G8xkwkxqrE9v2qogXnrLJJmPmX+5+kBf vQOLo9CpZl6rCoKlwYWpU68v69mNqiSZMBhPATq1B1Gr/vJimdsMm2dIqfyUqihBWrSd2qYUW63F bgGNzClCKI8jMZpUSp40Gn7bxZkljCa5jfMu7fVVXV+rb4bPUWgcnYU7sjuEkI79msEXkYJsXZQf LZ+jZeIhMlkQKfugP3loXPhlmsU/CJ1lEhrTvCyjTxPpA1Xam/p4Qq8qtO3DFIjNxpcEc7NQfYmP YnLoPmFNfMuUBVgfro33lJ8e70uh/2TcfwEAAP//AwBQSwMEFAAGAAgAAAAhAHjyNkr9AgAArgwA ABIAAAB3b3JkL251bWJlcmluZy54bWysl21P2zAQgL9P2n+oLOUjSdymL0QUPgzYOk3TJNgPcFO3 tYhfZLst/fc7J83bCiRAvhB8Pt/d4/PdwdXNM08He6oNk2KOsB+iARWJXDGxmaO/j/cXMzQwlogV SaWgc3SkBt1cf/1ydYjFji+pBsUB2BAmPqhkjrbWqjgITLKlnBifs0RLI9fWTyQP5HrNEhocpF4F wxCH2W9Ky4QaA3a+EbEnBp3M8XNrUlEBvtZSc2KNL/Um4EQ/7dQFWFfEsiVLmT2C7XBSmJFztNMi PgV0UQbkjsR5QKdPcUKfUbzgNz95K5Mdp8JmHgNNU4hBCrNlqsL4qDVA3BYh7d+C2PO00DsoHJ35 K5G75OBWkwOkojJ4Zu6Fy1jlh3ia34PLb5XV/y3i8C2YU0aciTKGLiE0fRaRcMJEaeZjV1O/XCiJ z7zv71ruVBmOYp+zthBPpS1Xme+ILJxklVdHM+8ycFa6D1uiKBrwJF5shNRkmUJEBxwN3ItE19At yNJYTRL7e8cHjdViNUdhpiIMW8HenqRzFM3u7jAeXaLAHea71LJfdE/Tx6OihU4mTZ0017JcpcVe GIWXYTgc5zvp3m0w+BS+oKdpWyjjXAsa2j0vhSuaME5OptWDPaal4x+UuAZ5OgZWH+lzec6rxD+T wkNK1zZ3ov5oR8SEQ3ViYB0NESy2RGzAar4G7OAQZ8rwBRfuUB0DZ1fWB8awvKMmhu9VOx1JxlPo uzUSt24lGfZGMnqdxPeqzY4w0yEMwxqMW7fCjHqDid6E8b1qvyPPbBI1eNy6lScv3j6eWVWKZ88M kgM8vlepdETCYQh/n9RylAlaoca9JSl73llhvg7le5VWVy48brYE7AStXJPeuKZtjw+SBVy+Vyl2 RRteNnsEdoJWtGlvaLPOaL5X6Xali6Jm08BO0Eo3643uNDDPZhI087LK8sQBne9V6l0Bx7NmF8FO 8AIgTK3ayHfTC8YrlCr8dBM/H181jYWbh9noL+4LNLMhCN/8/4zrfwAAAP//AwBQSwECLQAUAAYA CAAAACEA3636ApwBAABHBgAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBL AQItABQABgAIAAAAIQBLIEW4AgEAAN4CAAALAAAAAAAAAAAAAAAAANUDAABfcmVscy8ucmVsc1BL AQItABQABgAIAAAAIQDQRNOHLAEAAD4EAAAcAAAAAAAAAAAAAAAAAAgHAAB3b3JkL19yZWxzL2Rv Y3VtZW50LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAONSeg0FDQAA7FgAABEAAAAAAAAAAAAAAAAA dgkAAHdvcmQvZG9jdW1lbnQueG1sUEsBAi0AFAAGAAgAAAAhADDdQymoBgAApBsAABUAAAAAAAAA AAAAAAAAqhYAAHdvcmQvdGhlbWUvdGhlbWUxLnhtbFBLAQItABQABgAIAAAAIQDscVf1Ij0AALDj AAAWAAAAAAAAAAAAAAAAAIUdAABkb2NQcm9wcy90aHVtYm5haWwuZW1mUEsBAi0AFAAGAAgAAAAh AKcvQT2gAwAA8ggAABEAAAAAAAAAAAAAAAAA21oAAHdvcmQvc2V0dGluZ3MueG1sUEsBAi0AFAAG AAgAAAAhACUxNkXgAQAAqgUAABIAAAAAAAAAAAAAAAAAql4AAHdvcmQvZm9udFRhYmxlLnhtbFBL AQItABQABgAIAAAAIQDiU/kt9AoAALpjAAAPAAAAAAAAAAAAAAAAALpgAAB3b3JkL3N0eWxlcy54 bWxQSwECLQAUAAYACAAAACEASPGShXULAACrZgAAGgAAAAAAAAAAAAAAAADbawAAd29yZC9zdHls ZXNXaXRoRWZmZWN0cy54bWxQSwECLQAUAAYACAAAACEArGopkCMCAACKBAAAEAAAAAAAAAAAAAAA AACIdwAAZG9jUHJvcHMvYXBwLnhtbFBLAQItABQABgAIAAAAIQB7B8NDTAEAAIsCAAARAAAAAAAA AAAAAAAAAOF6AABkb2NQcm9wcy9jb3JlLnhtbFBLAQItABQABgAIAAAAIQAXoBZOAgEAAKwBAAAU AAAAAAAAAAAAAAAAAGR9AAB3b3JkL3dlYlNldHRpbmdzLnhtbFBLAQItABQABgAIAAAAIQB48jZK /QIAAK4MAAASAAAAAAAAAAAAAAAAAJh+AAB3b3JkL251bWJlcmluZy54bWxQSwUGAAAAAA4ADgCN AwAAxYEAAAAA ------=_NextPart_000_007C_01CE1F08.F5A14770-- ------------=_1363108314-22861-0-- From Michael.Jones@microsoft.com Tue Mar 12 10:30: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 36D4321F8941 for ; Tue, 12 Mar 2013 10:30:25 -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 JZk3RXfRLcn6 for ; Tue, 12 Mar 2013 10:30:22 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0209.outbound.protection.outlook.com [207.46.163.209]) by ietfa.amsl.com (Postfix) with ESMTP id B311A21F8930 for ; Tue, 12 Mar 2013 10:30:17 -0700 (PDT) Received: from BY2FFO11FD012.protection.gbl (10.1.15.202) by BY2FFO11HUB023.protection.gbl (10.1.14.110) with Microsoft SMTP Server (TLS) id 15.0.620.12; Tue, 12 Mar 2013 17:30:14 +0000 Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD012.mail.protection.outlook.com (10.1.14.130) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Tue, 12 Mar 2013 17:30:14 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.132]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.02.0318.003; Tue, 12 Mar 2013 17:29:18 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: [OAUTH-WG] OAuth Feature Matrix Thread-Index: Ac4fL5q4BmcfQE/KQwy7KfSVJ7BEnAAF20mg Date: Tue, 12 Mar 2013 17:29:18 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943674FFA8D@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B1680429673943674FD69C@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943674FD69C@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.33] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943674FFA8DTK5EX14MBXC283r_" 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)(377454001)(199002)(164054002)(53824001)(512874001)(50986001)(74662001)(76482001)(16236675001)(55846006)(5343665001)(54356001)(53806001)(51856001)(47736001)(16406001)(47446002)(54316002)(5343635001)(47976001)(77982001)(80022001)(15395725002)(69226001)(59766001)(63696002)(74502001)(65816001)(5343655001)(56776001)(20776003)(4396001)(15202345001)(31966008)(33656001)(56816002)(44976002)(46102001)(49866001)(79102001)(66066001)(6606295001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB023; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 078310077C Subject: Re: [OAUTH-WG] OAuth Feature Matrix X-BeenThere: oauth@ietf.org X-Mailman-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, 12 Mar 2013 17:30:25 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943674FFA8DTK5EX14MBXC283r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q29ycmVjdGlvbiDigJMgaXTigJlzIDE6MDAtMzowMC4gIFdl4oCZcmUgdGhlcmUgbm93Lg0KDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAtLSBNaWtlDQoNCkZyb206IG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpvYXV0aC1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWlrZSBKb25lcw0KU2VudDogVHVlc2RheSwg TWFyY2ggMTIsIDIwMTMgNzo0MSBBTQ0KVG86IG9hdXRoQGlldGYub3JnDQpTdWJqZWN0OiBSZTog W09BVVRILVdHXSBPQXV0aCBGZWF0dXJlIE1hdHJpeA0KDQpXZSB3aWxsIG1lZXQgdG9kYXkgZnJv bSAxOjAwLTQ6MDAgaW4gQm9jYSA0ICh0aGUgSUFCIHJvb20pLiAgVGhhbmtzLCBIYW5uZXMsIGZv ciBzY2hlZHVsaW5nIHRoZSByb29tIGZvciB1cy4NCg0KLS0gTWlrZQ0KDQpGcm9tOiBNaWtlIEpv bmVzDQpTZW50OiDigI5NYXJjaOKAjiDigI4xMeKAjiwg4oCOMjAxMyDigI404oCOOuKAjjUw4oCO IOKAjlBNDQpUbzogb2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPg0KU3ViamVj dDogUmU6IFtPQVVUSC1XR10gT0F1dGggRmVhdHVyZSBNYXRyaXgNCg0KUGxlYXNlIHJlc3BvbmQg dG8gdGhpcyBEb29kbGUgUG9sbCBodHRwOi8vZG9vZGxlLmNvbS9mdnJrbXI4cXRpa3RjM3VtIHRv IGluZGljYXRlIHdoaWNoIHRpbWVzIHlvdeKAmWQgcHJlZmVyIHRvIG1lZXQgdG9tb3Jyb3cgKFR1 ZXNkYXkpIGFmdGVybm9vbi4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBNaWtlIEpvbmVzDQpTZW50 OiBNb25kYXksIE1hcmNoIDExLCAyMDEzIDM6MzggUE0NClRvOiBvYXV0aEBpZXRmLm9yZzxtYWls dG86b2F1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBPQXV0aCBGZWF0dXJlIE1hdHJpeA0KDQpUaGUg T0F1dGggRmVhdHVyZSBNYXRyaXggc3ByZWFkc2hlZXQgdGhhdCBJIHRhbGtlZCBhYm91dCBhdCB0 aGUgT0F1dGggV0cgbWVldGluZyB0b2RheSBpcyBhdHRhY2hlZCBhbmQgYXZhaWxhYmxlIGF0IGh0 dHA6Ly9zZWxmLWlzc3VlZC5pbmZvL21pc2MvT0F1dGglMjBGZWF0dXJlJTIwTWF0cml4Lnhsc3gu ICBUb255IE5hZGFsaW4gYW5kIEkgY3JlYXRlZCBpdCBhcyBhIHRvb2wgdG8gY2hhcmFjdGVyaXpl IE9BdXRoIGltcGxlbWVudGF0aW9ucyB0byBoZWxwIHByb21vdGUgaW50ZXJvcGVyYWJpbGl0eSBi eSB1bmRlcnN0YW5kaW5nIHRoZSBjaG9pY2VzIHRoYXQgZGlmZmVyZW50IGltcGxlbWVudGVycyBo YXZlIG1hZGUuDQoNCkFsc28gYXMgZGlzY3Vzc2VkIHRvZGF5LCBJIHByb3Bvc2UgdGhhdCBwZW9w bGUgd2l0aCBpbXBsZW1lbnRhdGlvbnMgZ2V0IHRvZ2V0aGVyIHRvbW9ycm93IChUdWVzZGF5KSBh ZnRlcm5vb24gdG8gdGFrZSBhIHF1aWNrIHBhc3MgYXQgY2hhcmFjdGVyaXppbmcgdGhlIGNob2lj ZXMgbWFkZSBpbiB5b3VyIGltcGxlbWVudGF0aW9ucyB0byBkYXRlLiAgVGhlbiB3ZSBjYW4gcmVw b3J0IGJhY2sgdG8gdGhlIHdvcmtpbmcgZ3JvdXAgb24gVGh1cnNkYXkgd2l0aCBhIHNuYXBzaG90 IG9mIHRoZSBjaG9pY2VzIG1hZGUsIHdoaWNoIHdpbGwgaGVscCB1cyBnZXQgYSBzZW5zZSBvZiB3 aGljaCBmZWF0dXJlcyBhcmUgbGlrZWx5IHRvIGJlIGludGVyb3BlcmFibGUgYWNyb3NzIGltcGxl bWVudGF0aW9ucy4gIChBY3R1YWxseSwgYWxsIHRob3NlIHdobyBhcmUgaW50ZXJlc3RlZCBhcmUg d2VsY29tZSwgbm90IGp1c3QgdGhvc2Ugd2l0aCBpbXBsZW1lbnRhdGlvbnMuKQ0KDQpJ4oCZbGwg Y3JlYXRlIGEgRG9vZGxlIHBvbGwgbm93IHRvIGhlbHAgdXMgY2hvb3NlIGEgdGltZSB3aW5kb3cg YmV0d2VlbiAxOjAwIGFuZCA1OjAwIHRvIGdldCB0b2dldGhlciBhbmQgZG8gdGhpcy4gIEFsc28s IHN0YXkgdHVuZWQgZm9yIHRoZSByb29tIHdoZXJlIHdl4oCZbGwgbWVldC4NCg0KSG9wZWZ1bGx5 IHRoaXMgd2lsbCBiZSBhIHVzZWZ1bCBhbmQgaW5mb3JtYXRpdmUgZXhlcmNpc2XigKYNCg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg LS0gTWlrZQ0KDQo= --_000_4E1F6AAD24975D4BA5B1680429673943674FFA8DTK5EX14MBXC283r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRl LCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2Vy aWYiO30NCnAubXNvY2hwZGVmYXVsdCwgbGkubXNvY2hwZGVmYXVsdCwgZGl2Lm1zb2NocGRlZmF1 bHQNCgl7bXNvLXN0eWxlLW5hbWU6bXNvY2hwZGVmYXVsdDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0K CW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5lbWFpbHN0eWxlMTcNCgl7bXNvLXN0eWxlLW5h bWU6ZW1haWxzdHlsZTE3Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ Y29sb3I6d2luZG93dGV4dDt9DQpzcGFuLmVtYWlsc3R5bGUxOA0KCXttc28tc3R5bGUtbmFtZTpl bWFpbHN0eWxlMTg7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xv cjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFG NDk3RDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBU ZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFs bG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBw dDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEu MGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5Db3JyZWN0aW9uIOKAkyBpdOKAmXMgMTow MC0zOjAwLiZuYnNwOyBXZeKAmXJlIHRoZXJlIG5vdy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gb2F1dGgtYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9i Pk1pa2UgSm9uZXM8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgTWFyY2ggMTIsIDIwMTMgNzo0 MSBBTTxicj4NCjxiPlRvOjwvYj4gb2F1dGhAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4g UmU6IFtPQVVUSC1XR10gT0F1dGggRmVhdHVyZSBNYXRyaXg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0Ij5XZSB3aWxsIG1lZXQgdG9kYXkgZnJvbSAxOjAwLTQ6MDAgaW4gQm9jYSA0 ICh0aGUgSUFCIHJvb20pLiZuYnNwOyBUaGFua3MsIEhhbm5lcywgZm9yIHNjaGVkdWxpbmcgdGhl IHJvb20gZm9yIHVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+LS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0U1RTVFNSAxLjVwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Ryb25nPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9zdHJvbmc+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQiPiZuYnNwO01pa2UgSm9uZXM8YnI+DQo8c3Ryb25nPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PlNlbnQ6PC9zcGFuPjwvc3Ryb25nPiZuYnNwO+KAjk1hcmNo4oCOIOKAjjEx4oCOLCDigI4yMDEz IOKAjjTigI464oCONTDigI4g4oCOUE08YnI+DQo8c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRvOjwvc3Bh bj48L3N0cm9uZz4mbmJzcDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGll dGYub3JnPC9hPjxicj4NCjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+U3ViamVjdDo8L3NwYW4+PC9zdHJv bmc+Jm5ic3A7UmU6IFtPQVVUSC1XR10gT0F1dGggRmVhdHVyZSBNYXRyaXg8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PlBsZWFzZSByZXNwb25kIHRvIHRoaXMgRG9vZGxlIFBvbGwNCjxhIGhyZWY9Imh0dHA6Ly9kb29k bGUuY29tL2Z2cmttcjhxdGlrdGMzdW0iPmh0dHA6Ly9kb29kbGUuY29tL2Z2cmttcjhxdGlrdGMz dW08L2E+IHRvIGluZGljYXRlIHdoaWNoIHRpbWVzIHlvdeKAmWQgcHJlZmVyIHRvIG1lZXQgdG9t b3Jyb3cgKFR1ZXNkYXkpIGFmdGVybm9vbi48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gTWlrZSBKb25lcw0KPGJyPg0KPGI+U2Vu dDo8L2I+IE1vbmRheSwgTWFyY2ggMTEsIDIwMTMgMzozOCBQTTxicj4NCjxiPlRvOjwvYj4gPGEg aHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj5vYXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8Yj5T dWJqZWN0OjwvYj4gT0F1dGggRmVhdHVyZSBNYXRyaXg8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgT0F1dGggRmVhdHVyZSBNYXRyaXggc3ByZWFkc2hl ZXQgdGhhdCBJIHRhbGtlZCBhYm91dCBhdCB0aGUgT0F1dGggV0cgbWVldGluZyB0b2RheSBpcyBh dHRhY2hlZCBhbmQgYXZhaWxhYmxlIGF0DQo8YSBocmVmPSJodHRwOi8vc2VsZi1pc3N1ZWQuaW5m by9taXNjL09BdXRoJTIwRmVhdHVyZSUyME1hdHJpeC54bHN4Ij5odHRwOi8vc2VsZi1pc3N1ZWQu aW5mby9taXNjL09BdXRoJTIwRmVhdHVyZSUyME1hdHJpeC54bHN4PC9hPi4mbmJzcDsgVG9ueSBO YWRhbGluIGFuZCBJIGNyZWF0ZWQgaXQgYXMgYSB0b29sIHRvIGNoYXJhY3Rlcml6ZSBPQXV0aCBp bXBsZW1lbnRhdGlvbnMgdG8gaGVscCBwcm9tb3RlIGludGVyb3BlcmFiaWxpdHkgYnkgdW5kZXJz dGFuZGluZw0KIHRoZSBjaG9pY2VzIHRoYXQgZGlmZmVyZW50IGltcGxlbWVudGVycyBoYXZlIG1h ZGUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFsc28gYXMgZGlzY3Vzc2VkIHRvZGF5LCBJIHBy b3Bvc2UgdGhhdCBwZW9wbGUgd2l0aCBpbXBsZW1lbnRhdGlvbnMgZ2V0IHRvZ2V0aGVyIHRvbW9y cm93IChUdWVzZGF5KSBhZnRlcm5vb24gdG8gdGFrZSBhIHF1aWNrIHBhc3MgYXQgY2hhcmFjdGVy aXppbmcgdGhlIGNob2ljZXMgbWFkZSBpbiB5b3VyIGltcGxlbWVudGF0aW9ucyB0byBkYXRlLiZu YnNwOyBUaGVuIHdlIGNhbiByZXBvcnQgYmFjayB0byB0aGUgd29ya2luZw0KIGdyb3VwIG9uIFRo dXJzZGF5IHdpdGggYSBzbmFwc2hvdCBvZiB0aGUgY2hvaWNlcyBtYWRlLCB3aGljaCB3aWxsIGhl bHAgdXMgZ2V0IGEgc2Vuc2Ugb2Ygd2hpY2ggZmVhdHVyZXMgYXJlIGxpa2VseSB0byBiZSBpbnRl cm9wZXJhYmxlIGFjcm9zcyBpbXBsZW1lbnRhdGlvbnMuJm5ic3A7IChBY3R1YWxseSwgYWxsIHRo b3NlIHdobyBhcmUgaW50ZXJlc3RlZCBhcmUgd2VsY29tZSwgbm90IGp1c3QgdGhvc2Ugd2l0aCBp bXBsZW1lbnRhdGlvbnMuKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J4oCZbGwgY3JlYXRlIGEg RG9vZGxlIHBvbGwgbm93IHRvIGhlbHAgdXMgY2hvb3NlIGEgdGltZSB3aW5kb3cgYmV0d2VlbiAx OjAwIGFuZCA1OjAwIHRvIGdldCB0b2dldGhlciBhbmQgZG8gdGhpcy4mbmJzcDsgQWxzbywgc3Rh eSB0dW5lZCBmb3IgdGhlIHJvb20gd2hlcmUgd2XigJlsbCBtZWV0LjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5Ib3BlZnVsbHkgdGhpcyB3aWxsIGJlIGEgdXNlZnVsIGFuZCBpbmZvcm1hdGl2ZSBl eGVyY2lzZeKApjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_4E1F6AAD24975D4BA5B1680429673943674FFA8DTK5EX14MBXC283r_-- From Michael.Jones@microsoft.com Tue Mar 12 12:52: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 D46FB11E818E for ; Tue, 12 Mar 2013 12:52:38 -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 fuJVBMq6Ty8B for ; Tue, 12 Mar 2013 12:52:36 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0212.outbound.protection.outlook.com [207.46.163.212]) by ietfa.amsl.com (Postfix) with ESMTP id C544611E817F for ; Tue, 12 Mar 2013 12:52:31 -0700 (PDT) Received: from BY2FFO11FD009.protection.gbl (10.1.15.200) by BY2FFO11HUB032.protection.gbl (10.1.14.177) with Microsoft SMTP Server (TLS) id 15.0.620.12; Tue, 12 Mar 2013 19:52:22 +0000 Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD009.mail.protection.outlook.com (10.1.14.73) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Tue, 12 Mar 2013 19:52:21 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.132]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.02.0318.003; Tue, 12 Mar 2013 19:51:39 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: OAuth Feature Matrix Thread-Index: Ac4eqQVABmcfQE/KQwy7KfSVJ7BEnAAsOMGA Date: Tue, 12 Mar 2013 19:51:39 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943674FFF98@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B1680429673943674F7728@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943674F7728@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Content-Type: multipart/mixed; boundary="_004_4E1F6AAD24975D4BA5B1680429673943674FFF98TK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(53824001)(377454001)(189002)(199002)(59766001)(56816002)(74662001)(33656001)(76482001)(5343655001)(4396001)(54356001)(55846006)(44976002)(512954001)(56776001)(562884003)(66066001)(69226001)(79102001)(47736001)(80022001)(77982001)(54316002)(16236675001)(74502001)(16406001)(5343635001)(53806001)(20776003)(15202345001)(51856001)(5343665001)(47446002)(65816001)(63696002)(46102001)(50986001)(31966008)(49866001)(47976001)(6606295001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB032; H:TK5EX14HUBC106.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 078310077C Subject: Re: [OAUTH-WG] OAuth Feature Matrix X-BeenThere: oauth@ietf.org X-Mailman-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, 12 Mar 2013 19:52:40 -0000 --_004_4E1F6AAD24975D4BA5B1680429673943674FFF98TK5EX14MBXC283r_ Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943674FFF98TK5EX14MBXC283r_" --_000_4E1F6AAD24975D4BA5B1680429673943674FFF98TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We've had great participation thus far. Currently we have data characteriz= ing 9 different implementations, with more promised to follow. The attache= d spreadsheet combines the data provided to date. As you can see, the different implementations have often made very differen= t choices. I'll plan to produce a set of highlights of the different choic= es made to present on Thursday. -- Mike From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= ike Jones Sent: Monday, March 11, 2013 3:38 PM To: oauth@ietf.org Subject: [OAUTH-WG] OAuth Feature Matrix The OAuth Feature Matrix spreadsheet that I talked about at the OAuth WG me= eting today is attached and available at http://self-issued.info/misc/OAuth= %20Feature%20Matrix.xlsx. Tony Nadalin and I created it as a tool to chara= cterize OAuth implementations to help promote interoperability by understan= ding the choices that different implementers have made. Also as discussed today, I propose that people with implementations get tog= ether tomorrow (Tuesday) afternoon to take a quick pass at characterizing t= he choices made in your implementations to date. Then we can report back t= o the working group on Thursday with a snapshot of the choices made, which = will help us get a sense of which features are likely to be interoperable a= cross implementations. (Actually, all those who are interested are welcome= , not just those with implementations.) I'll create a Doodle poll now to help us choose a time window between 1:00 = and 5:00 to get together and do this. Also, stay tuned for the room where = we'll meet. Hopefully this will be a useful and informative exercise... -- Mike --_000_4E1F6AAD24975D4BA5B1680429673943674FFF98TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We’ve had great = participation thus far.  Currently we have data characterizing 9 diffe= rent implementations, with more promised to follow.  The attached spre= adsheet combines the data provided to date.

 

As you can see, the di= fferent implementations have often made very different choices.  IR= 17;ll plan to produce a set of highlights of the different choices made to = present on Thursday.

 

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

 

From: oauth-bo= unces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Monday, March 11, 2013 3:38 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] OAuth Feature Matrix

 

The OAuth Feature Matrix spreadsheet that I talked a= bout at the OAuth WG meeting today is attached and available at http= ://self-issued.info/misc/OAuth%20Feature%20Matrix.xlsx.  Tony Nada= lin and I created it as a tool to characterize OAuth implementations to hel= p promote interoperability by understanding the choices that different implementers have made.

 

Also as discussed today, I propose that people with = implementations get together tomorrow (Tuesday) afternoon to take a quick p= ass at characterizing the choices made in your implementations to date.&nbs= p; Then we can report back to the working group on Thursday with a snapshot of the choices made, which will help us = get a sense of which features are likely to be interoperable across impleme= ntations.  (Actually, all those who are interested are welcome, not ju= st those with implementations.)

 

I’ll create a Doodle poll now to help us choos= e a time window between 1:00 and 5:00 to get together and do this.  Al= so, stay tuned for the room where we’ll meet.

 

Hopefully this will be a useful and informative exer= cise…

 

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

 

--_000_4E1F6AAD24975D4BA5B1680429673943674FFF98TK5EX14MBXC283r_-- --_004_4E1F6AAD24975D4BA5B1680429673943674FFF98TK5EX14MBXC283r_ Content-Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet; name="OAuth Feature Matrix - All.xlsx" Content-Description: OAuth Feature Matrix - All.xlsx Content-Disposition: attachment; filename="OAuth Feature Matrix - All.xlsx"; size=30732; creation-date="Tue, 12 Mar 2013 17:37:34 GMT"; modification-date="Tue, 12 Mar 2013 19:41:11 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQBBN4LPcgEAAAQFAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACs lMtuwjAQRfeV+g+Rt1Vi6KKqKgKLPpYtEvQDTDwkFo5teQYKf99JeKhCPBSVTaLYnnvudTwejNa1 TVYQ0XiXi37WEwm4wmvjylx8Tz/SZ5EgKaeV9Q5ysQEUo+H93WC6CYAJVzvMRUUUXqTEooJaYeYD OJ6Z+1gr4s9YyqCKhSpBPvZ6T7LwjsBRSo2GGA7eYK6WlpL3NQ9vncyME8nrdl2DyoUKwZpCERuV K6ePIKmfz00B2hfLmqUzDBGUxgqAapuFaJgYJ0DEwVDIk8wIFrtBd6kyrmyNYWUCPnD0M4Rm5nyq Xd0X/45oNCRjFelT1Zxdrq388XEx836RXRbpujXtFmW1Mm7v+wK/XYyyffVvbKTJ1wpf8UF8xkC2 z/9baGWuAJE2FvDGabei18iViqAnxKe3vLmBv9qXfHBLjaMPyF0bofsu7FukqU4DC0EkA4cmOXXY DkRu+e7Ao4sAmjtFgz7Blu0dNvwFAAD//wMAUEsDBBQABgAIAAAAIQC1VTAj9QAAAEwCAAALAAgC X3JlbHMvLnJlbHMgogQCKKAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAjJLPTsMwDMbvSLxD5PvqbkgIoaW7TEi7IVQewCTuH7WNoyRA9/aE A4JKY9vR9ufPP1ve7uZpVB8cYi9Ow7ooQbEzYnvXanitn1YPoGIiZ2kUxxqOHGFX3d5sX3iklJti 1/uosouLGrqU/CNiNB1PFAvx7HKlkTBRymFo0ZMZqGXclOU9hr8eUC081cFqCAd7B6o++jz5src0 TW94L+Z9YpdOjECeEzvLduVDZgupz9uomkLLSYMV85zTEcn7ImMDnibaXE/0/7Y4cSJLidBI4PM8 34pzQOvrgS6faKn4vc484qeE4U1k+GHBxQ9UXwAAAP//AwBQSwMEFAAGAAgAAAAhAIE+lJf0AAAA ugIAABoACAF4bC9fcmVscy93b3JrYm9vay54bWwucmVscyCiBAEooAABAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAKySz0rEMBDG74LvEOZu064iIpvuRYS9an2AkEybsm0SMuOfvr2hotuFZb30 EvhmyPf9Mpnt7mscxAcm6oNXUBUlCPQm2N53Ct6a55sHEMTaWz0EjwomJNjV11fbFxw050vk+kgi u3hS4Jjjo5RkHI6aihDR504b0qg5y9TJqM1Bdyg3ZXkv09ID6hNPsbcK0t7egmimmJP/9w5t2xt8 CuZ9RM9nIiTxNOQHiEanDlnBjy4yI8jz8Zs14zmPBY/ps5TzWV1iqNZk+AzpQA6Rjxx/JZJz5yLM 3Zow5HRC+8opr9vyW5bl38nIk42rvwEAAP//AwBQSwMEFAAGAAgAAAAhAKharMM3AQAA9AEAAA8A AAB4bC93b3JrYm9vay54bWyMUcFuwjAMvU/aP0S+j5YyYCBSpGmbxmVCGoNz1rg0Ik2iJKzw93Nb sbHbTvazk+fn58XyVGv2hT4oazgMBykwNIWVyuw5fGxe7h6AhSiMFNoa5HDGAMv89mbRWH/4tPbA iMAEDlWMbp4koaiwFmFgHRrqlNbXIhL0+yQ4j0KGCjHWOsnSdJLUQhnoGeb+Pxy2LFWBT7Y41mhi T+JRi0jyQ6VcgHxRKo3bfiMmnHsTNek+aWBahPgsVUTJYUzQNvin4I/u8ag0dWejdARJ/rPk2hNo t90qbMJvvYXstFNG2oYDeXe+ypuuvFMyVuRslk4zYH3tFdW+ihym49mkHZNcUXf+0IguMtOJf289 G9Ih2rgifZT7uaLEr+SwY7h8K4Qu1p61oXt4P55k/YvLwfJvAAAA//8DAFBLAwQUAAYACAAAACEA LqylaaEhAAATiwAAFAAAAHhsL3NoYXJlZFN0cmluZ3MueG1s1F3bcttGmr6fqnmHLk7VRN6IkqXE zoyT0CXL9liziawR5XHlygWSoAgbBDgAaJm5mqfZvMReZd9kn2S/7/8bpwYogaScyroSW8Lh7+7/ fOrGd08/zUPz0U/SII6+7x0dPOwZPxrHkyC6/r735upl/y89k2ZeNPHCOPK/7638tPd08Mc/fJem mcG7Ufp9b5ZliyeHh+l45s+99CBe+BHuTONk7mX4Nbk+TBeJ703Sme9n8/Dw+OHDx4dzL4h6Zhwv owzjHh9/3TPLKPjX0j/VS48eftMbfJcGg++ywUvfy5aJn353mA2+O+Q1vX7pT/0E023eOQ0DP8rM 1Wrhp0/c1/6WePk9s9ebhvFN2nvQeMqCuEjiaRC2QDlZZrM4CX72MqDOXPqYOlBy4SXe3M+A0AZA 94V0EUepv8UbL5IkboF/FX/wORELt/0p0uxJuvDGoCWIkvrJR783MPhTQdkT/j6Oo2kwARYDL3Qw 2B3IYjkKg/Gmr1ucyzRu/JHxFgtAEUTvAmqJ1fa9ayypP/JSf3JfcCPM7KO/FbSSFWWxdRY5jSc+ GBTS6Btyae9B59WTgGepyYQl/GiyiAOwPAQ586fL0MSJ/gy+Tp92BupM9mxOqgQZphjkP244TQci eDdeJmPfvL6J/ASSkaY3cTIxp4lvGdFVAes50QFtufseIA1Pfvzh2DzzvQRTPEnBU1QA2yLx72+v toc1Fi33Lph0Ht3yRfEi2CBZjqlcJ2SKeOFBjXXnCLwWJP44e7dMgs5zSMewEN2fJs92fpqy0vnh HBmUr93w4FMjdx5Xnn438dNxEiw2Yh59cxNke2NYx/SdKILOE7SIqb67I4Jk/HcZzDG0hcpOb9/4 2figu07zPy3AbOm7oLuwJf4Ub8xalz+AlcnicRyaF1Y/Nkz2eu3SeBfqu668c6Cdkd4GUk36xqBI v1MvMtnMhxkHd498A+M3MfM48XEVt2J4Td3lvG1ul1b26f1sNcO3My8zYTD1s2DumyA117CimHRs lPHUeuEy3TVMfprEc+PJgrrPnKjYciDLPDqNexvRfCawpHP3SW6mD4JJqwStFw9huo3fkkmZjV+T wbZ8N0JQ40joYL4Ms2AR+n2oDnHR+9Rbqfn1l6+6P/p190cfuY/m46q+PI3no4AuJqIFM1wuFnEC aWhEF2JVzT+9EGHI+sfWk4xR2waOxELDImfq68EjMgy6hxHeZAIkdHf2FrMmHdfPJZ5OwyDy36ma qS8hQbzZ/uZrIOjsuTmNowgej/kR80MskRp9H+/xvwv8lf5sPnohgtqj3uHgOxgYOFbQxHNEXHIl eRnDF5dHTr0wGCUBn5t68yBc6eVjXjgUYNng11+ODyw3AXg1+n15ah5/8/VfwZjHB0f1ZWSDy/Lu r78cHXx1cLRvvu7w2DEfO74DGuDxsYY8NAb9mo81ZCH15uFxf6QudOvs398gRrvlfmWgv9w6jeNb 1wKs3HH/tiUCnbcilPdvw6TcvxPCbTN4fAedBP23T+LXX76xrNGkUwXLv/7yqNtjRwePhNEOwEi3 TQ+ov2XyX92BuBaGbzBVA/UOUzXuI51Eb/GuFMqg8VyZ9DF7aQxnJkZGLfQW5ibIZkaduEtrTJqJ phKcm0K6DZo82wRWH6ySXGqDVfdYixm6dMlhdpmeC7J9mu0alr4a/yBxYZ0kdTs6xR4DG+FzAkxa aboIahpZuskGnn0rGHj3RTLiY+CZV1dXF+aZlzZSW1W1e0yl6+By/cI7jZtnGZ/Fk9XOkG0KQ6jr ALPLePTQub5++qTbCYILhBqSGMmYeUo16kAm2GjGwXh16uwWdXNM8e0n8WbDIrWZIf3c3V1eR5wd c0HrwHZICg2ufhiaPWbe0ycPzD81ge86TAObmc/iOEwPAj+bSjZ+xiR8Mh3TeXAIfOcbDZa47Y1J 4k2zPsftx6R8v6qjNxi5AafU5GugqDd7EPkZag/+OD3U8T8e99d49/2jdw8PiJjOAMVf7oOV6A72 59YdXAsHtvTxN48emr3X1FDm+OChzfu5CZCBTnXNPN3pCVj4gBWwpwjyG0DXeK8uuCGQFUxz5flD EH1oqM5BVW+YKwTn6TxIWT/KlW0dKJzWNR61uhfAib5A//nzudBWE1dd6N/JzKwf8jucmXU9qzPL Bm/fvu1XjKxfukuvUONDTvxl4IdORvp3gekNV6P1s98hLxdeRZ0uVd2aqwPaJ4PkHSuYDZVQKtH8 cdqd9qfXE7A27O9OkH/z2bUIczZ4k6KcboQYRcEo1eCgsAZdGa1Ctd8dtn/jud2Ca3Dytgj+jVmm VSvVWYU5pwwxDVaE0EZ9aoks1zBPNpDlb/xWhXwtuc4aXpr3bw8NXiIEuGG+H2UIM0bxPWXCP5sx 6y/dGFIaYo2iu1NeuP8Sa2iyFFk15j8Rgpg0T5VuBhHB5yS+ifrMp1Jq67UIqUHY4DSvT2w5EKOl vH5K58nPq1DsvGB4wtERPicrsyiaSrZd1XaDoeIWb0wSDuVFK4McbsCktRe2LrO6qIk/RT5WKtCb sYBEf4yEbAfTXvqgTnvD2DNGRiD5Ii0x3J0jwA0sotHfafb6VP0dg6YfJBq2oY8dAyIy779g7xUw wQC/TN7sDvzN5Zn5h/BSkavaHWgv8b1w3ispuc3qyS5EcRBBdlH7SbSRar+4INK9D5aa4FK6nCI6 YW/XOy14SEU83WZgqo8WXm24t0gJaqOWHcoy68Y8pLX7StXfrB+qEPhtFmb5ScdDr8BnHGfZ6th4 qSMw0ouzFZGwlvYxKNet6ZMtMUZtBX17kmVJMFpm/pBtJ3PwmfFD+RcGK2q4cFJUr5viLcfXVYrd /hzoE8CfCWcVRT8OvWAumJIB7wk9LVJaOg0w19taj8KBQDFz7E/YYcomqJOLs9yOyALQkJD410Ga IbbVNOYGPXPFGNTA4p3Q8RG4JIdtHVSw1Q7CbYYAYGpS6fKrKOV8sO4ai5OuaZGq1iI4q46nJo33 zSy+2QE0FdS9gCzbg0r0wmZfo3Ye1r242uxFesU1Vd9x46W0jWs9RBjymvt4TwOL16Pmr+Lv5mJA QwmSiB8EdlgJNrqvqkXY5j5yfCaewjGdz9GkzdIKdCXERbs1xdJAPYKh0fFNX5YE7T4k2e1NxNSR 0GEcJOPlnE3naF2TZdTDISs+a9Tk5x52rRLtPrDQTyhX0zOErM7mBA4OumCt5ekOmIgU4EqJmqYh 5HO0pqOFYXu4TQW2C1iZqoiPck3eB5YrLNfcdkcElJdnzuPsmQ9MFIhUvdA045vBjaAa06V/FpFD C/dgd9gF8dqRvA3dBMFeeA01mM3mNWaDUUuD604eTXf03D4eeDpZLTKXqoq5uhPVfUhi7VbdUToi n19hlGPdq5ZoyHEP9Zae2cPfCOkewCmB19UdZUKldibrpcsRAOPv9yhqbQf5NoEmgrpPVKS4F42m mFIUZ6jxUprtrAqB2xxmZHqBl+UIhI3OV7olzDskt/c+C7DTaQsi3S66JbdtKzzd5PWexllv8Hre cgJq4G+xexuzHfGv7ipTT4wHPLRwmoqHVHe8kIfszoQELj5RNZ31ryU60RkdItaZS44MDdV2wCXb Aj8PfMak4NGN4HPu/qcs8cqIIM0zjPBPYQ1pwlmdLxNcNgdjYCAgcBt4cg6i2qEWyY1a6MYxgdQN BtuAMlziZg3Sd6zEpoTal7K59yuj1XOm6lRLb7NITg1Zm43QbS064H2syBlPEniIFrR97D4G2IDy Gn9pH9lmQln1KuJIc9lStfCwFm0U1JWJGd6Ab4meuyWyjrVdJTGHdo98u4bK1WRpVeXk4SmCnM24 l8S2yYi8XMLtZiVs44U33oo9g6pBuINkpPUf7I8TFYcNL626aDOOwCw0t/IbDuhVzVi5RKjtkg2t aHVfTDcOzLk8l9xdedCFdx+awGHCcojPx+iNMe5PcRZ6rW4K6qyb1wlLAdjBNKwZUdXFvY7kUAop V918lw9yH4u420WTitWmLhTk3jM9cSd7Noeb+Ngzy5Kl9Z/WlnK6CyVJcYvNqY8fRONwyUKhHT8v Um0/XC3pFmDFqEhzV2t1n6qz+M8wGBW7hqY5hjcbRLgM0mNtgbroKFAAU7Z3gplLN5+4c2YgH7ZS ChlqDI0mjGlg06LPvczLk29AsMwKtsqZTfcFt4yK4XJPZXf45EgNEUvBqg7AaGvnRbhsX+NDD0Pc VpKT4bsjrG1Bt4LPV7jZEKTL7QwoIfXOXMfldBzrHvJRdxIKxMgbPmwd8B7Ik0PajhIu994tlPk4 dCK3FkwYjMRfhN6KRRMHilkkPrY5Ywtnd6aqmoWafKiePkHwHg2LgnXVNjiDdx+ytgRh1y3mXcgb 5qkhuO1jA1r4e2PiyHQipTlxcdZ92hxRps56baJlBQxWCxyKRJSV0Q0IYcFz7jWQhSvbJRbRvjEA kIC4+9qEmZ1mp0mMdNcijFdAWulJIcDqDpZryi3J7VrLYSbprWrtweg+uKxJDT54hIGhQCWCrazm BtOFOVjVO2azwepJvsvoz9588a2Rs42Slqfab9i0ofv8JIDjt0yQc0PVWyZIlwtHPcGRcJ+NkKTm I+51HbCv/0gVNd3P54qmS4NzbvQUmcYGHveoi0EefYCpg4ntQHSH01Nc3KveZI6ZLwPkQuUnb4Ef J6sIvQ3uox+9JPAxxWW69EJsSu7NVziCCUd84SwwHvLlbplv7/1cYY30fq6BvVGIgz8shqELYtPT HTrQhtKcTkcCPix69LhP3Mh+7t4DuzGkPPALp4/ta0CcmvkSx22NKIjam0EXj9stT4bSK2Y7NYrH 9HCJohxvobgrb3BZ3pmhKYYUMoYcUIZJ8OCsxPjjWcxe1swEU2p2PJC5MI8eAvGp2asio9GMHwE9 cfRFBr2ITTfoq2g8IWufLedehIMJvImgVEPPancGDT13PHETjzrwTZ4ClxYKC/hEuxPGw65VniyA 6j2yHAvfwxxyMLLbkZlIOK3oQfbDxiapCKRGwABqAAclQVxMVDFgFkU7DdhQU/bCGUcz97XKLkFY osZd5CVA+9FqjcDrdiX3LeUk1MMNq84xUIClFdzBg9Rq7Ho0a9Cj02Ii4FoKYgw79s6Uuk+bsPS4 Oi/9kGrHau2EAuVVdwURWm+6IN1ZCayOFyrE5jRq4vr0QZ0uDw342J1FFQuQCiIUiOxFPhpQ5Ogh q6N6xhthV7T7OqTGStiMryU+1CckupJeRaFzGnrXOBwQ+rMhW/Xhq2xUxbw7KjSTM/D7mw8ps4oY jLuXwEpgCDTS5BleKZa3KHY6XTxEzR0Bp60lMQWIArWPFX2MdUNyofdVStRFEcOSsIHGhZOvDwzO fce5DmebWqHF3XegstdIfinI7ju5MvUYfcOw5LbFfc4SK/J96MFZcI3G6j6sFzQ8G1aYqFrzhgww 83BMXo5qICVX3PsWz/ks2JnQRHYFF1r5Nm8uf6CHrbrYHXi4AEYR6/tj0DVDEz1+HQcLMH8ELnWf 1oXhKDWRP+uG6kX30ZzJa/ztPgSETOJ5uOrjuEEfVAYB37w5e+4+duNjtwHVPhw5GpEI0/TANGNf 9TJcD3cvHY72GB4/enx4OXx0ZHfAlAbycnhihvj/6F3jVJmfmqdknjf4LWpcgaJ0Jx1BqRWbHtyb +TBiwrGQiwQYjbKzyfc9nC3KbR7f96L4NI5sy74cdVIuwE5py7eHapUZu+lPkEMfvaLSlCbewRsw S26oD+D5OvtiX/IwUFnSljP4MR5hr53ojud++iGLF1bB7QT1tnXtMtu3xTYZ5vsqAby4+oVbKqdP wnZh/46e9wefUFS1hnXy8Fuc0zkcvjaXebv8S+kGFHFStQ5J9T8hLKNUTnGgo5JlJ7xUPN0t6fUc wXgIXzRhyG6bfEXTwvbZO+IXeeE+la5qBHgKzBMss5j9jmPxkcdwyijlEGF1ppL4Y8Bd0VyuNBjD yd9psTViraD8zlRHwOtE0zqOJKLWEj0sEW/VhtLcBRm2wHhw30bUmztwTbu3D7k3ffZOa6/FmRzY CbW7w0CD0+HlS+IuUzsqUiV5DsPTg7ElDsfYCoNZs5Tm55Cudhk1gnpj1Bdy79MugG78L2CKEUzB NaV/PfJhAAMc3Qv2wSHHE3N2AaZT4onfTY9DNisxcGL+AotEcIHT+pbw6lfoQJ/vMh8lEQQdvYRF ACBI5TXpZwQ+aVQL15+a1IODg7BirDZzSznTsWHuxAeoaBoJYSh8oYgPBjxheGrTNzxWt9aaMkV4 iEb9XdBwyf0ClEqNnhjY7ALugkfrEhymLucrFn7clqiyNnjLt1e7KZndBk/hOxIVNwG8nxumphAw s0sW3VEUV/yUe3Fik3fBOxYKhUNnN0XcKv3p6hIvYh5LjLsYCl44Tjum9MBJp4ztMmIlktySOM8F IZhrpFwO04K57qStzqYIuD7A8EBEoXpDODD4BdFwBRmId6haYAR4PrM+JEkLsCxiduvt4pdqYtPA bd4FWzsy4v/r16VNBAdta6JkS2bRw9dhQqmR9xCB4oBAD1sEYhzTzLMayd9yFKHG8VuOQjHyQnT/ La9nJoLpo4DSdYOsrmzAvSVoGj1mV3YSunorwi4MSeYugsBdAJVnWW6LmMKkMl2cFPHoluBKPx0J ENlILaEOWoc0CErBSblKhmv4iHkcbHHciSxkG2hf27K7AzbbvUkyYl6e2cmF5DwFGzQCcCXBAH5G j4x+cJrGohF3mP4AMEs/n9TcCa1QHDCYyU5uJ3FXD8+35KvPFXVab92eNrvl5IjqUpypFZE3gSnc hZZZ8B5c4Y/0cwm7QLJL3EQed5r5jm7bPXDdaQg1hJoD5Aq1IhPG2HgpGKycWHsOpw8evUXOzWGc /4jgWeJFL1QsVN45Kb/9gawkyivM5cFAaYyCZOXPcHcYwItD2Xj9Jz9Fmmeo3t+BO6HLF8MrxFfY 2TvNQ0lUxHAS7zifWTVNS0ClEb5hOuTvKEIhPkPtkrol5nb4xiDnOJu4cRF5KE01SoybzW48+LDu 9I5rmrqCFFkV8kv6AQGgNENDcWOM87hxiS+6o5xWsv6Nm6/lixDuKxaf7uVzaJ7cZ6jM1j6dKyX3 rSueAkOXQ7NJc+8996tJ7wSVNgTdnhjTB3PJr8iUkgN4dwyOSMAFRKfwnDV66vHyKdkqzqCkyNey CoOviiAExiiVb8uAU04QTlTvKqsilFgm+NCQHl+D+5gvHGkdg7MA06cB9mYEWeqHSLWkcKs5JCoZ QcasENQT11G82sDzFYHiPzwlOSSYZwaVOsQNaiP5Vmak3uQZQLRKXrx2O4O1cO0C8reJGHz5AxmF SQ0D4l2OePoM6+4fJSSHyfyInCbOunYp93qZ9eMpPqaD4KIqKCIPkCnQFPDzWERDeqQ/XDCnitwQ YQprkSDyHK0zEwgUc+KQKWQlcFET5RLhsG4tUpp3YTBYacC9wN0Yvg5cWaz79etnBXxsRQTZUNMX 3JEy8IvGQAe+MKAVbuQpokkIa97AaDFblKTqZrbK8rJVp0iyaMJQ6AZstDBYWWsnXTNuWtXpoL5S JGOqO6wLrMQR1qZIgcMHlkH2uYqVA3MFvzdnUEwhb2LHQNpjSZrTNx7H4HHYUKDS4NxOmFcRqAYC zqFtXRIOZeA+wKPAlZPTwCQgMAcbIJWK4NQSVzJ3IhK6d4qpZ6mRrhpDvWAHKtIIxZdSChHBnFnR l+1eNk9blsWrL4Cw6vjH6EHQ9FmFTm9VofgyDnmIyGD5CWUiSeYUyNdHKiTA50uuYRH0CNbDQ8XV bDkB18i5o5MYx47KW+mfLlH/Q4x+IhVROQ3FRSAUc4GggvtFXVR6chr4eW63umHex1KepVuvcBjG Fa0XMI99VWUNEC0V9bf+F+A/6B8owwmPcDVHOMwbvnIERuG5vnLWllaql1Cab3kqGQTU1m338TMT n8gsADj+QbIcyhp82hhcVi3uOWmkTCAFecojL53QPEOlYzWTpiiqcWpARYIPadWZzlVFz0dnCCZB PFgzoCeIgLtUZsi6BzDvIj/4OX957PEXGHdyD9W6XgDLLtE5EwbShoFjZvGdqg95QI48k1Tm9VG8 j4wv2Ir5ZC4qwBEjV5KQubxqzP2FTjRSicH0AIs/s+Ciq6LqzsMEMUOkgDReTLFCIg2ZVEqv/V4K kAfGhqXTb4ABsR8DH7aL0gj1atkLM6Q/w9eBa6YVuArwVb7IA/MSA7cYBZI7h1ICqZhV3MSG4jnL m9AGRbCqpm1CrsId9v1REbSgxJJTrKgcKi0pZM5UKrE1Rq+yEIwmH8oNJ5DewHaNU7jaYmdP2d7f 2GfTgHKWzv733/9FNLAsVKo/8gQYCn4KAhPRKv4ESkr3wdE4AuGkpvWHmeimf2tPLr+ZBeMZ58Q0 CprXAXoEPvMha54IFq2uZ4Zvr4T+ZNMXX/3la9Ve/KIXfAYwDkdGMwPI/sFf9T96QPPCC2DXYBcA XM/2IJ6kOSCfXRjHaEV5D4uIL/R8oJqVXjChMzyTQlVdA/TFf0qOvjJ1K7xrNI5eRql9n1N6B+YE K4RwdT7wkihfTl/5gygRMspZh8dat2hqAgiAFhasOMuMio7IgtmpWdGxJYKIgLFEuJgBiClLfzzo cN8c96f/QkQJ8iyCSGp/FGSmag4XN672fnOHJ9DWIiK6j+RvylSDw17bc2xg6sFlM4+ET326F3A6 875P4aVcS1C6xXyAxkjDw7DTl2sAJg9NlwmwnIi5W+XmQ90KCIQhF9t6lWyhgK+BKYPbWIpp+Fzn cdxoIZCVot5FZsTLtfNdXEyuM6fS8QLiag7USozGg+jYSWglyMRNXMKfQ+EhCZqxkFrMxgpeDB8d u8f2DxjDlZJdsD/5yZvEONTCHm5BpUmaSr0PYsDgIAW94puVuaY4RnKmmM6/ycb/898uPk6AsBfR pP+G6Y6TWinsUjWJ+8YVGJtVgPx4NFge+HlIe8Fb6j1bhh/wodXFBNzQWPmPXsTeMO2efW497Eup imt03RiKxwtJ084cX3aVpjLqO2tSdPMNkHA5FJyQPvlSXEin2gD35zD7tt//83X2Lds4h6toPEtQ QddvrLrvzL1PwXw5p2qrpzQr/t0ZPkwpG/UlO2C0/gJN5cIC0qRjfyxGSKwI7I36a/oBD/cNMPW3 bHYAhfEST/eiqsaZo7LnVHyaO143/b45VPSCtop1/E5P0R1s6KMfmp9NxApYvBTj/DzGMUlta8F5 mPjmyyE+5uvCWRuviBmix2jTMNYmNViEz+k3Xdc9AVUDG5d3domb8xrlisqXk3LOsjS/jcGqIZlH JLsL8q4RqsJIMYvi3oMuw8HW9bElIku1YFJhk7X8IzDyL5I1Xosk02qr0RVwx18b1FOaga5Ay2/S UoFztPjWAP30qbOc9jw5twOAzo1GaRzA6rw/UNfGudoOlVsC+OcEPkelVF+T68q5F9ajltCgcbzL AJr5729fOOMOKj29fSArzYoiSAWPtLiV9ByNleUI9Jk0IIp8QAjBJtI00TIqBBvHsNidjS6AJXwv nlUroZp7U6MY9+r5iXvl5PwnA6K4l0H5ffM+hXWAX7ZAHboh4tDZ7kvMozZbBuFL83CeljsArdqo +RLq8fQr4TK3fHx18KqtlfAETYanz06/bLu5nm3y1MM7ZhH65h9vkGE9e31uzs7Ni8vL15e4dk5/ H0EdumOdFa8HS24EVWlCaiMUGZbSc19/CABe1RDKerlP2yboTGnw+uz5aSXdRMWmxnAfWSqxl6rt 2i2k9CmB42gWpSjsgkeFQA6r+d4cFQG8+8xLKF1p/Gdoli7nbd+MHbDDy9kUTP/2Z7tWF2Y57uO1 47Y9o1El6aCntSFdhzhLlZg7xjIK4a/B7XRvSHTrXsxr5u515tkZAUvVO03R7qEHezds02UcUkO8 8icjP2nsaYGFFwfxE/pQ6BrbYJdbXeIlQiVBqugN+aYeI7l11rKdTX/y08NaLOouxH3AvS86gga2 qk+p/spO8ifw+uH/46s/2IyDBJPYf3FtDhZgsbw+cjCO54doYeMWxMOLl48fH0rO6csrdN9+eYGo Qb9Q/ye5yovltf7Rw2/+evxNwwEmdVAVeXNGR1zKJi0q+BxbEiJKN3pS8kBsCcU+QiKKSM5FN3eX Kn4C1036qGfcEqcgcKvmZx3ktZNEMCp9j7cSpqCzakfNGFXf6DQY/OwRAhBuCELO2xt/YM6nXJJr ottnfCVxPpmvmkApkpCFurPpGsYfGBR2UvKpMz9cgENCmgeODBhS8abiLw7xRLjIZBfYrAx/GbZQ dlDBSoMRokzQGcJ0vUSK/MAgLkA6XrYZik9fsjn9UNbXEaSQ7twWwIHnmlyynbAFJvVp3EcGDDOQ HBlYYgkvSGY7R1OkZCpKu89eeMyNgBG9dsNhMR43nTmkGzCOE82FMdx7SG/u2UYYzsdxHTWVq4sd Nb6m0k5OiDwPMqelWB3O4eXYShY4Q7PX5ZbpSmYZObIq6ZBkdmbaPhilj1ZAVDL3FCzgEFDZYQJc j+T36XxIi16RFiMb4BeNsSCikp46+OMfnDEHVbS697Qzzux9ieJB9MRVRU/ki1bHT2RrCXjRfk1Y lpmXcQUxEiau134NJ1nRq5ni2mvcTORhK88n8KMEc6IjhfDIezGFXb0Mn7G6uIbyGXmUL7ChKqfy YeFNhNKei49zcFKu7MQTClLZ5GHbc6jscl9E+5s0G22Rz5QfKIZp6WueQfUNZBXKQBwaeMh3pDxu fHCT+7DqIxWbbW3X3x7mEsU4AbFcZV45kOVVOhQrnnnUWPKZrFBmTWaTKeUTJqW/+qsb0QwKg4fi NT4WSEEXPLiWvZ3dz6L8W7zIQOe5UrC67duXPItLFywUVh3aFZ8AFpng/gzkD+YrM8OeSvdxmSC7 S/FM6z0SEvqU2kx+kBS7+6RkzUC+ufcBESkkEqovVwD1huEKgkt1iwWNZSOBCxeijbQ++gBpOpWn 7SdE3Cer3C0yVkJ3H4VI4WBRbhUgM/JAPtmoKVs8pDLqNbiPPRBycnP1JWLGVn44ujNMO0W5eelL M3x14uq7AWb1H3DWUZhCEmu0DHC6I5kMOSL09zJlM9GMG7o4gjCgqwJ/G04QlB2wpJUqvoBMFF+A Rn2G/CjKVACHsrIPCciFO42nGZox8MxJlN6wdEOTDL5KEdJjZyDMLRbEljriJpst0/a6VmkkaYb6 BuyKUFpEyvoFJ0MpnVjvoxgfkGVIbVt7O+xfsU5vhleNoBI7xT7ohxWPzd55/BGGOgOPNQj0Y5CB 5fdsr8olygo4NdahyKBs8zd7p7Ml3JcfuR2YDNp49uzZj2bvKp5MzA+IbWboo2g8ckEKnOX9OnvP kgDFnVPsyx9h+3Dj6VdSNjV7z+KR+Ru8wjhZNZ6hOX4xvDgze8M5RsRzYP2+ec4vzEzMywNoA3wb pKkcT44vvgLkU/O3Mv+K1wKs8BU67apTP0zTbPB/AgAAAP//AwBQSwMEFAAGAAgAAAAhAEpV2LeF AQAAaAYAACMAAAB4bC93b3Jrc2hlZXRzL19yZWxzL3NoZWV0MS54bWwucmVsc8SVTU8bMRCG70j8 h5XvtpM0hLZik0tB4sCFj3Nl7NldF69teSZ8/HsmAQShqdJUVXK0Lb/zPuOZ8cnssQ/VPRT0KdZi qAaigmiT87Gtxc31mfwqKiQTnQkpQi2eAMVsenhwcgnBEF/CzmesWCViLTqi/F1rtB30BlXKEPmk SaU3xMvS6mzsnWlBjwaDiS4fNcR0RbM6d7Uo547jXz9ljrxZOzWNt/Aj2XkPkdaE0Ln4SFCugIgB kaVNaYFqodTns8/robr1Uej1Jr/8T5Md45bg4927vVd2Simg8kDNMpcd9UG7YhqSiz2ZzJw6iaYP I3kLpkB5U7hIjjN4+sjs0YQ/URzvgAK5PEJqfVTd3LkAKgLp7WyOdmCTXa5Ldmns5PiIe+Slbv4u rcM9+x1/287vZDd+F8PBu+X7YwaL+mVD2hQjWJI9IPKkQDn8OVCLUt+O4mhfFMsmvB/Jfh7I5wCy AGaekyCJG/tfcca7wVlX9L9NmF8PtHG+6JX/YfoMAAD//wMAUEsDBBQABgAIAAAAIQDafeJyqAYA AFsaAAATAAAAeGwvdGhlbWUvdGhlbWUxLnhtbOxZz48bNRS+I/E/jOae5tfMJFk1WyWTpAvdbasm LerRSZyMG884mnF2G1WVUHtEQkIUxAWJGwcEVGolLuWvWSiCIvVf4NkzmdiJw25XPRTU3UvG873n z+/Z37PHl6/cD6l1jOOEsKhply+VbAtHIzYm0bRp3x70CnXbSjiKxoiyCDftJU7sK/sffnAZ7fEA h9gC+yjZQ0074Hy+VywmI2hGySU2xxG8m7A4RBwe42lxHKMT8BvSYqVU8oohIpFtRSgEtzcmEzLC 1kC4tPdXzrsUHiOeiIYRjfvCNdYsJHY8KwtEskx8GlvHiDZt6GfMTgb4PrctihIOL5p2Sf7Zxf3L RbSXGVG+w1ax68m/zC4zGM8qss94Osw7dRzX8Vq5fwmgfBvXrXW9rpf7kwA0GsFIUy6qT7fdaHfc DKuA0p8G351ap1rW8Ir/6hbnliv+NbwEpf6dLXyv50MUNbwEpXh3C+84tYrvaHgJSvHeFr5WanWc moaXoICSaLaFLrle1V+NNodMGD0wwhuu06tVMudrFMyGfHaJLiYs4rvmWojusbgHAAGkiJPI4ss5 nqARzGIfUTKMiXVIpgEX3aA9jJT3adMo2WoSPVrJKCZz3rQ/niNYF2uvr1/8+PrFM+v1i6enj56f Pvrl9PHj00c/p740wwMUTVXDV99/8fe3n1p/Pfvu1ZOvzPhExf/+02e//fqlGQjraM3o5ddP/3j+ 9OU3n//5wxMDvBWjoQofkBAn1nV8Yt1iIYxNBkZnjofxm1kMAkQ0CxSAb4PrLg804PUloiZcG+vB uxODhJiAVxf3NK79IF5wYuj5WhBqwCPGaJvFxgBcE30pER4soqm583ih4m4hdGzq20eRltruYg7a SUwu/QBrNG9SFHE0xRHmlnjHZhgbRneXEC2uR2QUs4RNuHWXWG1EjCEZkKE2kdZGBySEvCxNBCHV WmyO7lhtRk2j7uBjHQkLAlED+QGmWhivogVHocnlAIVUDfgh4oGJZH8Zj1RcN+GQ6SmmzOqOcZKY bG7EMF4l6ddAPsxpP6LLUEfGnMxMPg8RYyqyw2Z+gMK5CdsnUaBiP0pmMEWRdZNxE/yI6StEPEMe ULQz3XcI1tJ9thDcBuVUKa0niHiziA25vIqZNn/7SzpBWKoMCLum1yGJzhTvtIf3st20WzExLp6D DbHehfsPSnQHLaKbGFbFdol6r9DvFdr+3yv0rrX89nV5LcWg0mIzmO645f473Ln9nhBK+3xJ8WEi d+AJFKBxDxqFnTx64vw4Ng/gp1jJ0IGGm8ZI2lgx458QHvQDNIfde9kWTqZJ5nqaWHOWwKlRNht9 CzxdhEdsnJ46y2VxwkzFI0F83V5y83Y4MfAU7dXWJ6ncvWQ7lSfeFQFh+yYklM50ElUDidqqUQRJ nq8haAYScmRvhUXDwKIu3K9StcUCqOVZgR2SBfuqpu06YAJGcGxCFI9FntJUr7Irk/k2M70rmNoM KMGnjWwGrDPdEFx3Dk+MLp1q58i0RkKZbjoJGRlZw5IAjXE2O0XreWi8aa4b65Rq9EQoslgoNGr1 f2Nx0VyD3aY20EhVChpZJ03bq7owZUZo3rQncHqHn+Ec5k4idraITuET2IjH6YK/iLLM44R3UBKk AZeik6pBSDiOLUrCpi2Gn6eBRlJDJLdyBQThnSXXAFl518hB0vUk48kEj7iadqVFRDp9BIVPtcL4 VppfHCws2QLS3Q/GJ9aQLuJbCKaYWyuLAI5JAp94ymk0xwS+SuZCtp5/G4Upk131s6CcQ2k7ovMA ZRVFFfMULqU8pyOf8hgoT9mYIaBKSLJCOJyKAqsGVaumedVIOeysumcbicgpormumZqqiKppVjGt h1UZ2IjlxYq8wmoVYiiXaoVPpXtTchsrrdvYJ+RVAgKex89Qdc9REBRq6840aoLxtgwLzc5a9dqx GuAZ1M5TJBTV91ZuN+KW1whjd9B4ocoPdpuzFpomq32ljLS8vlBvGNjwHohHB77lLihPZCrh/iBG sCHqyz1JKhuwRO7zbGnAL2sRk6b9oOS2HL/i+oVS3e0WnKpTKtTdVrXQct1queuWS5125SEUFh6E ZTe9OunBFye6zC5QZPvWJUq4+qh2acTCIpOXJEVJXF6ilCvZJYq8hGnaxtsUi4D6PPAqvUa10fYK jWqrV3A67Xqh4XvtQsfza51ex3frjd5D2zqWYKdV9R2vWy94Zd8vOF5JjKPeKNScSqXl1Fr1rtN6 mO1nIASpjmRBgThLgvv/AAAA//8DAFBLAwQUAAYACAAAACEAYpgIjaMDAACOEgAADQAAAHhsL3N0 eWxlcy54bWzUWF9v2jAQf5+07xD5nQYYtAUlmUY7tElbNamdtleTOGDVfyLb6WDTvvvuHAhZW1ZW aMdewL747n53Z9+dHb2eSxHcMGO5VjHpHLVJwFSqM66mMfl8NW6dksA6qjIqtGIxWTBLXicvX0TW LQS7nDHmAhChbExmzhXDMLTpjElqj3TBFHzJtZHUwdRMQ1sYRjOLTFKE3Xb7OJSUK1JJGMp0GyGS muuyaKVaFtTxCRfcLbwsEsh0+H6qtKETAVDnnR5NV7L95I54yVOjrc7dEYgLdZ7zlN1FOQgHIUhK olwrZ4NUl8qBrzogG1UMr5X+psb4DajLZUlkvwc3VPh1YRKlWmgTOHANIOsQoCgqWbXijAo+MRyJ OZVcLCpyFwnem8t1koNtSAwRSAUniSa46pl07UfPZvje5KdzVQ3/ifWUD4SkjUHcZ/x5U+ETG1c7 0e/iKlhcZWzOspicbm/ZnV2wyYi9CH8S1PcJvf+If4F8ijnVon/SGTUW8qZPDz5aS1/4PwsHmwtR 55kuZhQgJBHkO8eMGsMkWI6vFgXkEwWpGQWH1boHVk8NXXS6/QaD5wO9E20yKAV1hgPNFSmJBMsd aDB8OsN/pwv4nWjnIG8mUcbpVCsqYBiuOJYDEJsyIS6xXHzNa9lo1TwPVCnH0r2HnQOFB7Paagg2 LoeVvGoC8jcx9YH/fqaAFoVYXJRywszYVyOvzVPRl+vZyNu/nr8RfKokw2wP8DzDJ6MdS52vlv4Y h03rKlsbZnZOHmVnMM8fNBgdtsHgFXcFuWEFVicoNpVRwUwb/h18jlUK40uwEXA8xTkEmATfDC2u 2ByLnd8t83yz/6EabgcHCyUKfE5wW/vqX4D7w86tAvm8vnq150DusKeODwcKtMF73d47eKV3OFC2 Plcbc9AOftha+SMOdQpJn5ndEuKB4zv5D7fR75GsivdfZcd9xPVw/DY4HCi7F7EtMoHvtaC7arSU vzWUdSsW4OUqJu+gOzaCq2u4qfuGCvbKpOTCcYXtlb+s3Oa5wA5RrBjgDDcYbjV8gCObr1ta/9Xh 24NvdmtkICNjOS2Fu6o/xmQ9/sgyXspuveoTv9HOi4jJevwBO+/OMfZh0JF9sHD/h/+gNDwmP96O Tgbnb8fd1ml7dNrqvWL91qA/Om/1e2ej8/PxoN1tn/1sPIXs8BDiH2ygDez0hlbAc4lZGrs08XJN i0ljUsH3XSTAhmvCyojQ1g9JyS8AAAD//wMAUEsDBBQABgAIAAAAIQDQjTl8kyoAABL9AAAYAAAA eGwvd29ya3NoZWV0cy9zaGVldDEueG1snH1Zc9zGkvX7RMx/YPB9JGLh5rA8cdEru2e+mPjutzzT UstimCIVJH19Pb9+sjYg8+RpAGw/yDZ0kKg6uReqUT//+z+/P5794/Dy+vD89Om8+nBxfnZ4+vz8 5eHpt0/n//f/rP/t5vzs9e3+6cv94/PT4dP5X4fX83//5V//5ec/n19+f/12OLydiYSn10/n397e fvz08ePr52+H7/evH55/HJ7kb74+v3y/f5P/ffnt4+uPl8P9l3jT98eP9cXF1cfv9w9P50nCTy9z ZDx//frw+bB8/vzH98PTWxLycni8f5Pxv357+PFapH3/PEfc9/uX3//48W+fn7//EBG/Pjw+vP0V hZ6fff/8091vT88v978+yrz/WbX3n4vs+D9O/PeHzy/Pr89f3z6IuI9poH7Otx9vP4qkX37+8iAz CLSfvRy+fjr/W/XTvm7q84+//BwZ+n8Phz9f1X+fvd3/+vfD4+Hz2+GLKOr87L+fn7///fP94+F/ BYof5dqFKC+o5dfn59/D7XcCvJAn/bh/Opz99fcfMrl459vzj/84fH1bHB7lrr/V52f3n98e/nH4 L4F9Ov/1+e3t+Xv4+6j4N7n09eX5vw9PcWRxAGHMQaYBy7g/9gPX/10msY6W8F8vZ18OX+//eHz7 389/bg8Pv30LY2o/tMJtoPinL38tD6+fRbcy9g9NeOjn50eRIX+efX8INiqquf9n/PefD1/evn06 b68/XF21F1f1ZRjyX0Fdt+dnn/94lYn8/wSpsqAkQqYcRci/s4jq8kPbVu+R0WQZV1rG9fV10zbX c8dxnWXIv4dxOBmVqHVkMuKgiQ8hZkTKOCNVoaS6am5EF1nQzYebm6vr6sbMKGg66STqe3n/dv/L zy/Pf56JA8sYXsU0JBxUP1Xhfz6dy/jS6JMBRExQ+lV9VOmi7SDsb0mAsCnwVzHkf/xy8fPHf4TH Z0TnEZVFLBJCtNTLuLwAKUuGATmrhBFNKTm1fdaayWktZsMwlxaz9Zj29tZi7jzm8uLKYnYe016C nL3HXF40vZyPotdeuWIjRrnUYYvuAvjTufzZ8wVsdQkRXdw8RjzLPCZFiGMBojwv3BVtq38ezLRL CPmzR1wNE40Gt0gQcZUeUrdoLARzC8SvGAYMal0wwazh7zbp74ID9QNp0AK2RcCAaSvg+M5j6luw yN0MzN5j2ttrbiWiKKO+USsJYKu1CvjuEkQG0FPh1JYg42ojGKc2hgHVrAuGqG1b/m4YqteIx9S3 YIY7hgGt7RlmGKtxqJCOdFAe1UgAW7+FJ3cJ4f1WYqx5TPDbS0nNRzJ7cdxwG5jAMI/oll2CjJpA glgTADFLgnEmwDAgZ10wxAQ26e8mPLcIGLMTj/GeOwOz95j2anAxYyeS3E5RYLgNFAhhqEuQUQUm iFUgiFkSjFMgw4CcdcEQBW7L343pxmO8D8/A7D3mqG5CG6Z9eKZzhdtANxBsugQZ1U2CjOuGYFSG iH68YhiILuuCYbopfzemG4/xupmB2XvMUd0IMUY3o/E1gG18RYUkhI+voQ8wzwk2UEuJPhFg431g BMB6lzHGCgCzyBhrBkMoiSpeloeZwu8WIuiKiULQugcRU9iU54yXSL2IMYshIG8yFAQM7QmovRrm boJt7I7Qo+tKwvWo+cTbQJnNUImlfJlBqXsOndQiX7G6A8NbFtlWdzd9mZecmIhqWhjBmoGwbNuU 54ld97Vdi83Zlohqq2HoltTQUzhSZ7hI6kW0MVVQ03ehRRbPNS4CjdsiYyzNzkXyw+Rf/bRrtP4V E3ULiWxLQL7iJCBi32lQZuTYKeyJpPZqGJNVhRB1kirCfZMGnkDawNMVM/4W/HNZZdmWeegTtxml RcnSUO8FdpahDD/F4FL5bgwOfKirEkbG3JvJFRjlImP0WH3HmkFBe72k2hVOTBRa5boHkZi87f9S PwZc5I6CBneOMWZHQYMKImhPQMetEXugkDuvhZDxYJtaHaMlH2xVPxQHtqjSFasU4GGZQUYpDQa/ FRHVtBCR1wx0NbBlDTb0A6cYbOojDBUwji4kL4yQYNSLjLHcuAiZH2YNFkStmCg02E0GhSTS275f SqGiQGN3FOQsNw3dzM/HUQ86brmhSUCFzWirq9Rc6HlX3nYTSMdR35PULUSdVZatJ9m0EEY3ZQA2 ux+rhkK5jbOc9s9UpJs5wjC6KmFMFAXDXWSMnk+NJc2SgXwQTU8zknzWZiBnbQzkrG0GaE8G3t4O FNjwICN3epjTY4T7JrN2Ag3WtqzSFflzcE4VA83Qamx/RkN3RNsB1RBmuowxpgHms8gYPUKfYBnI mQYFDcVTTB3rHsTya/+XA1v1LdoNBQ3JIOVXCgLj2hNQc6ybqcUHnd1M+m+8yyrJx6gMGqxmka9Y nQwGHae4JCCXXtcMdDUwau1PspGbYtVKkTZuiOE2mOMlDLarE0hb4jVY6yJj7KwhJy4JqLkYYm6k ZsVAl/C4LQERY0vjNmNyq9lUkjM2L6lVDaPVhPBkNDGugIC2Ky6DhiMhXZ0g0cTsk7C8H3+SL+pr 4L6rfVF/DZhFxhhW3WsoBsKYs+5BJJxs8l9OlEa9iCHo+BaTgeohlFpOWSk+I8XEt/vWkWoIn13G 6FjBavFhZDlWeFBzAbJXWbbVCkhaE1CDr1w3ZSa6MqqxftoSUQ50R0BtA668IyAnaT8BsioM9StW a5XsoRAnHveQXNirfF8hPV2dQFqJvl6uMWAt821aP416k51Dn5fUXIL/rZkk7Lw3GRSW/PrapUWj 2RJRbQXh546BGhjUjoGwE9wz0LFOsMbGYlxzvp2oIYZ3UaJdIbsGL1pkjNYSqadIE+JjWwHR2JaH q1sD3/aRwZDYVp4z6Fkvn1nHCPW4doxxTlP1rsdYN2AcXZ1A2htI0e+6lXyb4RkpXFEQGN56DmiT QcYb3JrmlopytSmZHtYU+wlJVilCglHKrLWfOtwF6ebCKSeBtHLSFfmzjwq+lcyyDcgrh0jC5Y01 kdRcQVG4KVPRoYoohz0PXHxHnqedIQbZPQG1x6rqBru6WcqJd1nlVOqtdqrqMkgpJ18xvGP0XxJQ cwFGumKgS4h1awa6gtJ/S0AtvnvYM5DKSMbcG9aKzaiv4n2W0xqm3WWM6VPARBYZY0h21SsDOQ+g IEdymG7c8Nk7XHMFZdkmS5oodcnzfDpgoAYGtSMgvXvD6it0PjpnzPOA1C/p3FHdQuHXyXbiwI32 gHTFKAftdplv06AGQ98mg8LLkp742i11EVEuXuzmgPYE1KpIZykN/dz7KU1doKUUsmHXJJCmNF3R bNWX4BTLfJsB4faITS97YLTFCnZLJcHjdnNAewJqVXiyjL6rEW5II4ypM2OEvN58riHcLDLGsOZD SXqYAWEo2ZQRaeX6epA8jwQA9jynAAYapme5ZQ1xdV1PbuxoUtuq51SpBbqcBRNIG6zvduvLYWzx tmWWrVltcH/xioHQ9NcMhItbmzIVXaK0mHW3RFRbQbWzYyBsrvcMpLKG1U/oGTGazHgD06ReU6un Rgq7DNLq8S1qfQnes8y3afXUGE9WFASpak1ADa5IbTJoorwnokiwJ9Nz5f2EJKue0J+heubUO7lF VAGowvzVNQmk1UPaQdd95dtG1bPJICAV9LOloly4IYPypI6DLKmhCTuF1NS8aZuvcCBdk0CaVNLz +UBPQBjoV1m2ZR6S+HoOaJNBoB4QtaWiIJju5oD2EyCrHpmfU09TXU2njHCjLfIrfD3dNQmk9ZOu yJ99svZdbb7NgLx+iCT0uk2WBNQ7z/Ci2graqx0dFOhnT0CtSlGG+hYb1tElnoi2Lx/gZXqXIZFt +yTxIqPk8ScFtNVs7R6VMKbmgsyyaBPGaNG5IgOhqjcZNNF0EVG65rKMYKs0zohvkWooFrrWdUj5 ip0/9JNLAvIvDAjILbuvCci/MMgg6w9Y02yJKPe83RzQfgJkdRLaH8wUk29+29Q0ia31AQV363UZ o8JQvmJ0cwlGviSg5gL0vmIgrIHXDIQL2psMMrppsVveElFtBVa1YyB8zbFnIFWvWd2ELuT9ukm9 i9ZNhdsMuvDe2y4t5CtGOa4wIqDmAmL2ioDcysImgwzvDrWlorB6mgPaE1CrjMHyzjq6aZ8g7RwG 1a517Vy+MsG77/maC7C/FZPkcnMGTfHun9fi/psdfR4oZz8BsrxjpzaeH1InIhmgj0EQJro2QUhu DrU0etaMpqNNNbj2rRrMv8sYk6UhyC0yxiodlv+WDIQGtSkj0kPyKyNElM7Scc3gjoCOrnq2oZhH Am+uJn8SHu+zZU6FjW+XQTpzkN7hErS9zLdpUhv8OeqKgFzYWc8BbTJoypPIyLGjuqPPgyp3R0HO 3fzj2usBZN1NmHI6nOME4T6rQ7VZJC1btQkz7gQJI3/2DuzfJWdBBuSdIEmaKlX984gTeNBRJ7jE XiIs/c9wgnifJbBSv8NIDGaQcoJ8xVCBW9GWBNRU0PWuGAjXqNYMpEwpjnKTQcYJ5DMc/a8tImpL RLW4teqOgZrBdKOkHQPhK8A9A6nFaeMElxI4T3GCeJ/VIW7c6TJm1AkyxijV9WsM5JygjGg8E1BR 0ETeUdCgCksgNnXBCeZsJrr0/Z18vcRaTpdB2gvSbZYwTAX5Ng1q8OMKKwbCdmTNQMqWshfkqdjl b/CCHRHl1lf3EyBLfejCMAlP1qmX4S5ruZXaTx5n1GWQ5j3dpimtce/XMt+mQY36sV9mKw9As+Vy 8JaIcmzt5oD2EyBLKWu5ZuTEy9RPiR30uQxL7y5jIqf2oaHa1nocrXsvU22u3dxt5coYIbofzjX4 yCJjtK58+mUgH3nyiPSQfA1KRPn0S0Ba65Y2bBdi5Lm4mFxFvUxtgR5u3YC3dhmkPSDdZgjDXSvL fJsGNerXh9EDVgyE5eyaga4hUm8yyORfvzeIiNKsxkHtCKjFvQV7BlKDsvo5scm69E1WhV/P6TJI qyfdppn3i9z5Ng1qcEPnioBcfNqUUU5EMTIoLP939HmQCfcTIMs8687mRLHUPZgoBrVjd5kwJIoJ qSaKBXec89Bwn81HuHu2u0wYE89g+WORMVq1JJ4lQQbk41kCTbQT5HkknrHnYWdHJB3tOa5YzzHj bXa8z7LcomozRvlUvmLowi0KSwKSd1m2kFsxEDYvawa6BkmbDDIhz7ccRFSLvze4Y6AGtcNAuEti z0DHlnWvJPEYRxlN9xFtFYf71bqM0YoLz7Db6mpsMZf5Nq1d/xqEgbDuWzMQFhybDDKKc284tkSU A93NAe3mgPYE1CqTM2H1KpT5uk4LEW6O7+X2QFVj8vVU6yBdFG42++UrWj01NkhLAmpwT80mgyzz WJ9uiShfJcwB7SdAltTQDSCpM9LGVe4iFKm4WtBljE4bN8D7ImMMy64BZyBcttyUEem60pfBRJRP GwykflpgCWQti3xMdrIMvko9ix5u1eBqdgbp0JJuM4SpH6nEYnKZb9OgBl/urxgIC+o1A13DKDcZ ZA0cB7UlomoE7QioVdTH6e0ZSMU7qx/s7mbWRVe+z8Pc1GWMMXDI6ouM0arwdREDeQOf1ecRUcTA kygzKFUXWwJZnze5zHHlm7wKld1lkLZu1uRB17XKt+nRN76Y8ZKaayhaN2WUuosgxYwX1WLPvyOD avGd+J6BlDdZ3k/s3658/4YO1GWMMVzYILTIGM0yMVzWYEHJuCKS9E/ho09vyrB1PCThmz0P7OOO PE9nUssy9mrj1WDqvvQYldvEiXRXqkOLVxb5imHSV4PpNg1y1eCaSGowpW4yyEZj3O+yI6Jcobef AFkmZeiukpizEfsq3GhL7Bba7y5jdKRId2m+avWjnsj8Mt+mQQ1uHFkz0A2E8U0Z5Gik2BFRLb7Z 2TPQsZr3mvWbddtOVhfxRktqjZ8y6DJIsZqvaMJq9TuRxCoBNbg9Yc1ANxBjNhlkTLXF7UY7IqrF vWh7BlLx3pjqtTiwM9UZRW+8D0mFOXUZpEkNj4Nu0NW4+TbNvFu7XzMQrlxuyii1qbpFyR0RpVc9 oqb3EyBL6ontWSglwP1r/N1Ol0Ga1HSb5suvN+bbNMitN64ZCF9EbfoBDEv6LW692hFJOvFkTsnA VRKxnIYuS3dno9npOqDtdlmo1LsMGXi8y1c0RdoO7HBYrzPHb3yrU+PPU7rrBBqGtshXzNDcnjgG ckuKGWTijFtT3lJRkInu5oB2c0D7CZBl/sQuJh49YU3C/c4xYwbiV/mKIR7XK+4IqFWvcezwQwU9 345Tva2rLFfBXieMrmBVIR09bZExZho+7vrivsHNEeteEvtaQv7Lo+vVlgms6sc92tfyLX5PrrtO IEMFvm3MmAkqfHHd4KLtupdEqcjjjQfG2HljnR3a8Bmbda59xd1iDOgyaLDgRb5i5qt+nZnrGFJy +/l6EEmmDASRY0/G1Kri3dIlI3+HwwQ01CWwjt5dJ4yxEsgOi4wxrHmHSYI0yFnJJkua5xM3tMid /u5wvM9Ou2qgxe8ySNlGvqIn4BtbAvLlGAO5yiGDxnPPjojSaTiVDhQ0dCrGgm5OrHHjfZbUGivy LoM0qaTGVT8JTQ6Xb9PM+3KMgTyp6XFA6kBFfN6OiPL1GAUNRb0lldW4MwqgG1bjgvd1GaRJJaWi 88d8myEVV6fWDOQahzLK8caBiCKWSkaufilnSQ1lqy4OZq7Q3oT70FKd+yeQJjVd0Xz5xiHL1iDi /l5S4y01j9KSOthXtlQviljqOMiSemKpHo4vwx7CcYqV+irfpely5fUdAR0tGG9OrHfjfdYm3G6G jBEyh91ZMMVFxpgJec/zq+gNet6mjMhUs2o/jdUa1snBFUJXOVol3vh6uQUD6zJG+4EvfGv1s80c sT3IbS5YZ9marOYGqp9NGaT2A7fUviOiWve2n4GOve2/CRXpKcElV7LKSFr3W5Mo3Lw0zlc0FSS4 kDrbbdPMkiDDgVp37HlqMSEqcT8BshYYKtlT+EoVsLFyMIHuJmG046n6N451kTGWQHhpvCQgF503 GTSzBJUHmmmPO1xA2yjjX93eJJD2uHRF/uwDj3sBusy3aZB7dbvJIGsc+HptR0T5d6kTIGMctycW 6vE+y5d7l5oxxjignltkjObGV+4E5I2jjMjY67GofBuKTfSJGRtP4n122pX6kls0+C6DlJnkK2aW KrzF29YE5F9vlgGMx1wiyr+5ZCD1ksSaSSj+kK8ZVfJtKhqNTuDdXpcxxkwgKC4yxhDokjcB+eRd RmSGdNRMZFBu2jOWOG7DfdZM/KuaDNJmkm4zs1Q/qc1m4kFyQq3d+7QpA7BmAktIu4zSz2ux2t0z kHrrY82ElahtM/kZ3NtUfmqduPeFGaPpSnfp4dfu91RFtGUC3mfvM0qLapWD2kmeWMjeptpST7LG X1N2GaRn6UtSX3/k2/T4SYTMA9BUuJp+R0T5vmUCZPnCCng0Ed+m8lTiRp9Rb7CtzpiBpLt8Rc// aCNye2L9GO8Dp8YfAnYZNAxtka/ooRH9zakfywAm9OdFEf2Ng6z+sH4c11+qCLX+1CpBTpClagwn Z+sDlW+FJRNvxx8V0Pbzyu6zDFEiYMD5FxljNYQFKgE5D1sRkFtZXlMQJLxNBh0tdSORWyLK7Qzb EZBf3ZkAGS3JVsj3qCnBQQeQijoKQkUV0LimGMotZ8uJi2ES8Aof34jJkYsMBUXslqG8HhjKK2IK BZqQbGIcJi20iX+Nek51Ee4DlWCUpSBcVSkgqxLQrhyCmZ6nUd57GMrlJ1EJkXUDRaUch5lQ4kAS ZJK3lGt6FO4Ijx1HQYElJ1v6UeixgppOLJ+ri1Q/S8nXZ0MxEFvsie8UVJmqTCJdMlPFDWMyCY9q 1TIPTCIUntgDzOiZqotUsdpJgA/JJAqqTEI0nS7pSTQ3EBRkEh41MglWoc5oZKoLX6IKfU4TCaWn igOWY2NJ3YovQMVlPIq5jEdpMyyGz1DgMmIzDOUNn6GGdSGwGVYrz7IZXyyLoh3dCWXohtgjdCeQ tqIaf3AudHsUo9ujGN0M5elmKE83Qw1EAN3vKrWrC19rq+0eqVYroFjRwtOwkJ7IOanm1Mry5+9d eJAKSHFIolFSvbrVAIbyywEFNVFoFZg2Ipfh7xhK195AH9bVIXdLdJ/cCFpdpPpZMlCfFWr8GIME VFVlF+LSJT0L14tIZeRRDW5uluBMUDfgfJKGE8oua2KZJQWUF+Y/XclQmt44SckHRJZaIAElCBcm qU3YcIDbugkNT4j3IFzFERtOIPlz0CFJAh7V4CEEogqCwqZZVJFQk5buhTFL9yitCkty0L4heebr 4CreaOmuPN89qlQOcnC3L9tJNCco167JodxJVvjXoCpvwlQYhPNdESbsKVmA2k+hgN1QiWJdNqek CZYAxly5nzBXPUqx62tfxq5HkVyZxWtCWrRwoY3JGrJg9nyGUj/YAdpC7XsSbalolhH1Kqzcy9kq Hw0+LASJUfpqm9HmUY42Mco8iCmjZMKAN2F3BkqMkqCOsxuKcs3ueFzNR4yb2sD1owSk4npOceSw cv9CqSIot0QgJIdJSE7WqvY/YCowY8IqHYPZhfL5HcSkaluPAL+u0VX54O/B1hblkh5TrT4rEskS i/S1fFNDobpiKCdrzVDNDSwXCKV5PtpuHWxbYHr4LCr44bdqCxQQHwrpdxCf6m5NvNuIKB/ligZi iCf1us/r7IRy1KsQT2Rh4hHiPcrvWSqoySzmhem8Hu1GAsYMlASMcRSoB1uX2TVCamK0omrceiEu klBGU+mStjFXDIuLeBQL2h7lgrZoyqMa3LsvLpJQk5rywpimZqBEUx7VqiU10BS2fUFTkzuaqnz8 uQ7xNX7HSfRU+r9SbUgoI92e+nFdCWUe1eD33kUDBIVnyIkGEspooMWvA0uQ8sKYBmagRAMe1aqV I9BA6HDeEcpSQyTpuy9YVN6O/AnxCTQ4yF25pB3k6Eu1Kp5c/o4xiVSoPVFbMiYPwoUbMY8E0qNk Cd+j3G9CJOB6lFuhFyMqKPZ7ifK3k0VDETIoxbVZEmg9yg1IjGccZY0nnmI+X1H50HPtti1UCF1F QCp8RAtbFJCMtTdDoih2yDr+gmNFZeFrxvWAoorKTxJFlVizHe4Yxki0QsZItDKBAq1I/jIuHYLq jJ0TVX8avBoxLJGLfoJ020fjN15FPwlk9QMLOkuGIvmQycJNjMK2fyJj26MY2+MoYDu0MtoHZrOd eiDjDUCRsO1BuOFV2E6gKbY9irHtUS4RCdsexdj2KMb2OArYDm3USWyHG63Z4jssYduDCNsJNMW2 RzG2PYqx7VGMbY9ibI+jgO3QFJ3Eduqm5Fl9fMbztIVtDyJs+76MVNZZlNYJY5vIIpHEoxjbHsXY HkcB26HHOYnt1BwZtqFbFrY9iLBN2izfcZLj7BnbRBZh26MY2x7F2B5HAduhTzmJ7dTgaLbxIBlh m4DgDa/Ebd8qMdv2KMa2R7FIwlBQgu3ouLAi2nPUsB4IbIeeRLM9voaXD4+XzNDHD/xQinCc+hzd ZrBD59VrSBgTtj5zlwnyAenGAnydVJqgYQr44kssIIF03GJ1rEcxC/AoZgEexfzNo5i/edTxRjMe XK4tYDbbwg5kbrUwl1vOfCy6VglhO0maYtujGvyejHQNHsXY9ijGtkcxtj3qONvxUPNT2M6noWsi 8eNpXUVAnm1yrjqxbYIitk1QhG2CImwTFGGboEbYDg3DSWynTsOw7TJ3PvBcgwjbpGfB15vLipyd ztgmsnzmJrIY20yWe0nJZB1dsoqnlZ/Eduo0DJFuA1w+C92AXOYmB6Yz2/adDWPbo5htexRj26OY bXvUiG0LE6fZdrjRdlz4dWqJJATk2U4giX99NcDY9ijGtkcxthnK1UnkkHfGtpc1wnZoGNC256zd kCPfK/zgndCd+pGhZFqUS4Zc9bXUmF83BWWXsfEXJ/sC08KOfrC5iueE67mKtYR3ep//eH17/r5+ fvl+L/qW+DFeK+bjxsWme+uQ7Ye4va9HlQW6VXq+POCyX7STeaYWQuZZcHf9NRla/4RWbTezVWU8 XlvPam6dU84BV0+p1VNyodOjyvhEg6Sox0V5mW1BxQXMD7I5TP8DW2jXCAefFKKSODAIELMtMGMQ +FZ4R1FYdYhxlRkoNahdYqAGbDhmqyF1FWJ2vbIr9wOyqpwv3puJqCHdqKdaoxqEtyxev7Ru8ac/ wpsX1uJLDeGNoAhvBHWct1DTa/OdcL7UAhjnw+MFJOwklP/uk3yQBx43W03hxhgdlJq81xMUfoBd NJdQ8mcvi+UXj3L7PMTNPMrlBPGuGSixlYQyPuY2lYmtzBAmUWwGSixqBko8cRxlPdEd6j1Xxfnw buuJkIQ72cPnDQE/Zr4oKBn3mIqzLI1q8P3/isrC8njNUWCgm4ICFUO03RaYHpizqrtZqN0s1H4K BSoORb4OGkHFc7bml2PMlVoq9wU72UhIVAxtkqg4oQxHvgMiqAa/3CEqJrKIij2qwT01ouI8eh3x 3YYOUbEXxlQ8AyUqnoESFY+jQMWhZ9AqHs8L+ZRzkxfwI8Diu0FoCOJSzMDjQtH8jselGlsm1Lt3 hevW8jiCwo85ih35ep1kA4JioYLIwpVUCRUe1ahfjMfKTwzEo5iBMNSwKhtliYEwFAQnMRCPatVe cNAY61zmbB0uh40r3dW4f010lzqX4QW7KCpdsg4Pb1CFNoJCVxZCxlEw1dAkaOOcndFyd2Gm6laO yyngCiWvt21DI7MnLzuw3FwyFDNTIgs5EiZnoCQJzUAJ3zNQYoAe1ap9oKCV0B6cpJXcyii+aywS xQALyseqUF/rB0+ExlSO29AIGV8el1AsNGKFPtv6ShWug6TbGV1OzlZsyHtxZ31JlvU9WEuTNEpQ JPwxFNi7WB9DQcgS62MoGL1Y3wyUWB9DDU8E6xMqjBHM1kq4ERsZKG7EHApqaPvZ4duY8yS3pBvl zz4zNsS1Pcqtigkh4yhLSDznWXvFXELyAdEml/sXrAzlgyQ5bNrl8lXFUN5MKQr8djtL1h1HOTOl TwTUnss6Zqbx8GjUypz1xXKAtbKjGtusrupRg5my46rxW9xCm69F/SEOFKU2PYMBYsU62wBLVTq4 jDzZRkCZKkERA0wo7X7uFb8YIEGhk64ZqkEzFSZnyBIDnIHazUKJAY7LAq2EmhINcE6ZmA+K1mGh xsNaRCupZB3KRBkeq2IHL4LhhTrwpOGlAlIPr8KjUWR4BaX8g1Se6mSSWLCLhRAU6l4shKF8iGKo gZD4RLEQj2rxADoh16N04gByQzmnyR0vlPJx02JdfeqSDRPOD1ONOGhchu7LxpFBnVo2ltOd9fDw SGbReCkb9SSg5F8U1GiYWDKU+xW6mEp6opFFgolHkZ5zjiwJE16W5jsalJgKQx3NU1hTzw7epW5W fOOn/UUrBVX8UMhNlzRtDX4eRSbhUa360QfYeyggtb3PnkSqPHUwqf3qST7sebB8mYQvWV27J5Pw qJFJCCOnTSLcCIUt7jgUTRAU7raReSWU/NmHAjcvSX0e5exQrHUGSjgaR1lFxwOGT1F0PplYK7rC 7+J3VY8Sa4UHy50nKSefrKsfXGN0lwcH8XR9Lh4iq2c8HsrzmbMmlLsDYauMGgx6VS5pxbu10zuO GjIacHZqBVKOkFVGWOEnsYWzUoEMplrhmdDLgtLzamro+vYM1aoFZphXSMVaJXOjTTmfVc2r9r9P JSg2L18PNA2sC8i8PKpVKQrmhVXD7HmVykBpApdVRV8FNaQCckhqg9+Jl0n4KmNkEiH5naSclDW1 o8qpiVgElZNK+9fRYmE+3TZohzIJjxqZREh+OIk5r3nK6Z3Kwir8uqpooiRlpS8csczLZ+AGQ4nM y6NG5oV5eiKY+exc4W8JZTYERWbjU7F7qSyz8Sid2MBfQuZCLc1p8cshlkZL7n0rQ5F5+fTJ5uVR repq7LziEY6nzKscI6nmVWOn3kkkF9qgXPHzIudINvix8n2RpaN7qz4nCvM6NYeXkxz1vDDWyryO 5vB4HiESOqcVzwcZ6phU4+8q5cFpWUCjSMLIKE2Vq+yE0PcsMcQzC0+al0/dNS59y7wKylVj8cg+ /eDxOJJP+NME1Zhm5HEpV2oUo9FnVOJv7zlTsIon+L1jNiWPquiNP62X2RTUkG3JSYH6aGNwllPz aDmGzziLy6MExcj2SbPBIwjFZj1Kv6+FebHUOssXfdKsMSAJ7QXlbTakFq3lUF3NyRbk6D1ZDcLC hKFIVPX5rVE/28kLCOSEvBFCQ2rBec0iNOUk7W81fkRKCC0oZcfpkvw59Ki4f1OswqOOFybxRLdT JlFOlVNjqXHbZVf1qDKJfbmkJ3F8A288G+2k4Qm7mGtxz7EMj6DQKpYFpUfcYCcr80qyNKpV58Ba Z4xnmJ00L5Ly8F2HzIugyLx8ymuwK5N5eZT+DDHMCzvf8fyUTzmTJ/QGLT8gQQ/vz1krRnRXkePR jjtqPPdLkz0xKJIO/U8D82Fi2onlF1t26IuKHDnm3g6KgbHUCjSsGEqX6DGErRmKrLqSJzpZwrIf l2Y5PnHHUcPSSA6tVNaAAjMKOVxrbG5DXg470waFrzrEPbBEEEWlS9p7a/w9uSjKoxrcACi0eVSr /Aqmemq5Uc4zU1Otcf+2TDWVCMOCl0yVVA14DJZM1aNc1SxT9ShtRzBVrEAm/LBUFCo44HkvMkGC whZF5pxQVr2waCRz9ig35y1D6TlHexdmvCyHEt+ZgZIQPI4Clk8tt8p5ZcqgJFnbiCZ8p0LKGJSv repjRzNV8bgvdO05KzzlyDE1vBqX8WV4ouKynhw1IbpPl4zujx0JVMVzufTwxm00H+NlE5grUcth X34TajzVSj8uBLrQik48ltQtivE48a4qp28pxuSXRlahi4Ky9AyBOcpaMlSDX19dF1T4QFuf0Bu1 LJF9g53lpcKoted4BBZSNKfMLmdnqbFIMWOnLySl8sbkcUJSQlmSQM9Ckkc1+K3VO4ZqFZUwe11Q yePnJsJypJaZPJQnMvmy0DCoi1lIQtnJgx3J5D2qwV81yeQ9qlUUweRD/VFUnyc/J1SUU7TM5MGk ZfKkziOaJzWQ+t1wcQ+PalqwD3EPglItQvEOj2rVNhSgKNQaiqKJuJEqE2Ps+FFaIYagCDG+ynH7 jkTfBHX0PUw8F2v+ZFLtYScDZimTISgyGVLHqIhUNENQxycTkvb8yaQUrydT4zsHmYxHMX8l5QJu 2xR/9Si31UP051G6jAFj1KXHe4JVqSlUGEIfk8kXVGkDJXexygP258scCEp9FRDmIOPWapsdcMN9 sLjvPyJSDsrSkYlYY5Ilf/ZZlHSN5BCsRk2r2CyRdewFSG2OypIbw+RnrNSl++zka7ePakD1CiyX zEzV7z/SHBiqVanFKFBOrrQKHI2ICY0jxzw5oGTk8LSQ8pWXzzSXOp9lpP1dynwoTijKmUtBWRJh DkuGavCHcGuKuoVx3TFUq9IdUBRSPlA05+CQOh+VZDnC3XkURTjydUet9vVGQxOOPMqtiAlHBHUL 4xKOPKpV7gkchZyvOJow2lQhDD1YV/cHPnkLDRl4vuiUr8Wq+9AjX8Z2dplQcQAwkZAi1dNm+0NK rTKx4bkX/rkJZSxC/XoWhhJS1ylDSSnPDgX2UwrhCWWHMqzZwVBCBoKhzIqrKXPZoYA3ylASygxF vU+AoYR8UIYiap4d4sN9kg2MgsDoZSgJZYcyqNEOJfwkGYcyo7Gr4304FIh3XUGZoRw756COZ3EA K7OGIuKRFfxmiQwloexQhu4AWNEZRf57PBSUkzX6bTnytCAgpDQXCuIJEWqWE6JTANNRphwxQUSL YWhdTogO6DzEGHpl1OoSEKID2DQhKjQV0eoSiNbRalp0iT6lfpFRq0sgWkefadElmijR6hKI1tFk WnSJDkq0ugSiITpMqLF4uxKtLlnR8QPTs42vfO5a2bW+BKKDf80XXbxxGHX+tDNxmfgZ4vmiRRtg 1/k7xkx08K/5or035m8JM9Hv8sb8aVvt6PoScP0ub8zfcTWij3pj/FjpfEKU62VHz187ZYS8yxvz Nz7NqI96Y/zA5vxRK9cro1aXgOt3eWP+XqQZ9VFvjB8fnD3q/KlCLVpfsqOOX9qbL9p7Y/5UH1Gj +S7fZOTLn9Azo1YOmkb98fXb4fC2vH+7/+Xnb3/9OLw8Pjz9/qr+++zl8PXT+d/qcPzky08PXz6d v9x9iTJ7eA8RI+khdQhdHiLK7iHxI2keIkrrIS2VEiqgHhI/LuakhJqjh1wRKWm1vofI0L88vP54 vP/r0/m3t7cfrz99/Pj4/NvD04dvf3z58nj48HR4C1I+9k8Skn7c/3b4z/sXQb2ePR6+Sul+8SFw 8PBbKCvjf789/4j/JV7/6/ObfHWt/N+3w/2Xw0v4P4lsX5+f38r/yEOC3L8f3v74cfb88nB4ert/ e3h++nT+4/nl7eX+4U3N7CaO6c/nl9+jHn/5HwEAAAD//wMAUEsDBBQABgAIAAAAIQAOiozUVAEA AGoCAAARAAgBZG9jUHJvcHMvY29yZS54bWwgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAACEkl1LwzAYhe8F/0PJfZum9TO0HX6wC3EiWFG8C8m7LaxNQxLt9u9N2612KHiZnPM+Oecl 2WxbV8EXGCsblSMSxSgAxRsh1SpHr+U8vEKBdUwJVjUKcrQDi2bF6UnGNeWNgWfTaDBOgg08SVnK dY7WzmmKseVrqJmNvEN5cdmYmjl/NCusGd+wFeAkji9wDY4J5hjugKEeiWiPFHxE6k9T9QDBMVRQ g3IWk4jgH68DU9s/B3pl4qyl22nfaR93yhZ8EEf31srR2LZt1KZ9DJ+f4PfF40tfNZSq2xUHVGSC U26AucYUN8qtG7ULnnzLSqoMT7RujxWzbuFXvpQgbnfFQm4gePDbthn+rXpw32Oggwh8Mjr0OChv 6d19OUdFEpM0jElIzsskpeSSJhcf3eNH813S4aLeR/iXmIYkKck1PSOUkAnxACj63Me/o/gGAAD/ /wMAUEsDBBQABgAIAAAAIQDsFjgO1wsAALQbAAAnAAAAeGwvcHJpbnRlclNldHRpbmdzL3ByaW50 ZXJTZXR0aW5nczEuYmlu7FdpNNRtG7/HpIenrIkYZSlJjD2DGAqVrI1lZMZubIMxjDAZKm2UrWSK JNF4ky1ZRoWieJMlW9YQj2WU5Y0oTeb9T8uXPj3nPB/ec97jus+13vd1nf/9O3PNuW48wANbgAHW AAlMgA1k2QINKBYKCMAbRECMBFpAHWgCFGR5g98JtgFsHAJ9UnYcwAMDMDDzJ4nPG9JCwAnyeSAJ hzxLqBoFWgSo7j8n2M8SGyDNA/Ev//fKthhzxzH136P/3N/2vYSwIncBwOUf9BSkwX/Zv+tfG6YS wgBvAQd+Jtyv/0Fc3H4njXEtOC8U5EB7XP6V//u5df//G4HffxlPoevaWdkf5d5aGJQCp+89RQKR QBZgAQnqLyLUxwQQDHUbt4dlwT6gA/E+yLIFdlCWJcHD2z/Y18zblwCArYcvwc6fSoCiFAoh9LuP Ifj6k4IBMA0PCSRE/lTWJPvwIM9AAsAQwkiB4RTuCR119UiIvUP8uV/z98hUAgANa4wT916bIfvv Uq37J1M+qA/m+IWhFBj4Q/aAmPRmbraVnckhru7g50oAVH4oAIf96Cs9dQD9q3FzYGBK++fmT6Wm 5hDsRQoKCSWEhRG8kaYeFA81NaDXrqwTwT+lbWLxAicQKI0VuYUbjM+qY/TltA6QVastxkcbH8y3 xRbJVmTt9ieKeuHcTeU0k3CHTwQ2PUBkLtjZIjrOHLxf4DAj7qdgi2PqKAQtDpryJEidMd5z8TlS vmDDXlHTvLN8wvJPUVqPa2uMmhCzb1tnWK01tPnZFZ/J1szjJZkZVRTta2lIWVu7RZciq9bZIjM0 +7oNpfzU4AAuUTYGkRZbKe2g8NlgbEejc5CgygGHu2znSZNmGVzS3sJoxaoIJc6OxWy4m6nLRvOX O72qhj8w+XtQaXWRWgWKYq88MSphR+ZrXq3cwqy9xNj/sYE+lNU9eXWIfXmBF12we/x4ULuayaeg CQQ9ZzXpY0xwrDWjvw3ZTgxTiNDbuSc6U0WskVqzslltQiKhtDNemGYxW3tSgDVYK9oTNzql1Pxw AOkZcdIsf8jnjv6/2LsWjRzX9pZMBmUFjOy1n6qgaeXe4hEiSM77DfKfZxfHcbI+Zk/UxmLW8ls4 OEdcOxJbUZ32WG2Zf6Rx1ZXBVjAqCM1GM1wH53x4UZ8jE8a2uiNoXXv9Pr0cY3x4UcG6aGLwqqZZ 5q8O3LXY1EGjHLbmpFEu22Io322K+voWEdQtfpFr0NGauaR0Am/Mljyoc2LV89EIYWX74os0Qz9U Ul8LnFoVrVQg95icbKlnz3fi0jBH2ItdTuPoWai04z553KM1itxHB/RMURYiLh375irRE6zWXHbe 5+vKylKVPyfpjFLeyfln1lHH+2rTozVd87bh81vxr/tRu1tcI749pCOe9Cl0m9VoHzTRto5ZFZsR mckXLxfo3PPZtfwNZvtRpOQrwhH0o4qG569HUQyXw49LCZsyjl4W9BoI0C8SGRe7YyW22ytz4Kvo sL5Js426kcr2Xo/OvQU5G+81jBbcnkE+FT7oElcfYdI5YFyVS4OXVnYEnXE54LCr9RhyvMBfQDJ5 ZqfNM46k0bEYCVJNtqQ8elBRksSqqYmeVztk6UdPM2qaPRcVID0R1SlezdsTOoFSn8fGGC4SFz2/ vuclDhGjHkS5YddmAuxJezhuk0LK8/dPkVrtStKq2ur59iwYcE5LVEe7v+u2kolWCZEzCF/tY5zU fw0/ekMYPkVrSO4DqAUM6piyvX7CpWtzF0qlZDOcQwrXpPDKcgxLDIx2IOQbWS7VCNb7rdsKrmRr ppmU4CdIO9d4W7yxsv70fXjZjHjUbLnOuRFNDUS2Z6tYffWSw5+tCjMXdmD1Q97G+65ghBJhHYJU Y50AXh3jrZWHLUN7JBsqL+4QPV6TbJxbf1rZNczDYP9jys7ZrZl1p2qeDJ2+v8WZbVBI5OscUC3z JFaR3/gO1QffpS1hiUbnpZlS48uuyyy5VfnZZzkRvJWxF+BYxK4KRGUPvDrRSfSSLgVH94g3tHTL FXJfkbh0ES3l66Yx2HbuyXIHfVompZdgeq5qf0h/6L12/r13ZDrpL2I1ireTmQWhCUUXa61F+r7t SiqWDalwYma4WwXayXXkjW3yQHXnDscrd63VpuwQsaQtbDmti/fYRPf0wIvwG5XFEdGGR/NzDqf3 F+jiK9J7EyznYbgT/U8rTi13GXwuPm9mWqUb8tYq4t3lJbvFcjQxf0L8PP2i97aRg6vi157ZqFf2 KJH7Q4lABxdcIVn1MHHJSvOdoimdTC18uGDfZKYrcLzTS8Jw9zvFV4Wqd58ERstdKHHoJ4iOxFAz BXExY5W7jB44yN8UuXlkv7DRsvPUMT6sbkNt7vXhHKWzw3U8lQdelawBZuVodGH94md27Ray3Pj4 tGdfwvN65uD0RWGEIVrNYrqKovWBqNjWtE8p5J7vkXMq8qxUeeKSARpvNmXq+tjd7b00Ey24IU7U Ysl2RMXbcV6jDKNvU5TSC5v+z850mkaxwL8NMLn34vff0AznSesQCx9rqd2MvyaIR45tx4wXhEWW pRxpOYlH4+O/eGnLxebd/CuZ1xwyVWPzpCeSw658bPJrZqeW3TRqs2qWyVVaPNwcusbcoxTrjUd4 sODG2mfR1S9lSJbNMpISg8tM74S0q+wH27BjenlUyyVhWOSG5jE9+ysUwbsNL5ZNj++/4KiQZXKP /CLbMu1d2LQjPn4edufjDne8SkLo0o7bfFjPW+IVY2rN/rccr6flmxUZJIZm5LfaNHfdcbx1SK+1 S3zXhP/lV23t2m2+Yv1tXeK7J/wT7uvAsCcWyzH4eLJHgNGzVHmChqqKRcImu/GAG5XMwOfnEGSF yYpjyiV3b05WuJhHFQ1gXc7QCPtL3man9WoW20sGfchymlwcMGT2RdQkf2MyeEJ5iukK89uurtSa RLqq+kn3YpRv/YsyGnDlPfoLnGCdIid3tOWCq1UKXUacMdCyQ5IdXm8QRRuJYtN937j1fwpbs363 UWzt6W1znuiNvcjTMcl5R+Dacu79iSGi6vqG2zlfvmKUSJn8THqwShCKeuLg9Fu/G7DzydNHlaxW liz6QoKaG5h1TYmb2gPw6EaXJIREhsvqRXLsJQRW6z65ZEP5NPPAEYLTwUPWLKpPSkvOqXQffs2q dueiEt7y8ubsIiebx7775hJPpUc+/CAWtNxWOtAAQ7Ia716dSz2VThnv9F/0M7Z4RGYVTjlxdYV/ 43YhP3NUsWorcwv3YE++5IqPsQVCuzeRhtK1qMne7GduMFliRoLKx1sVb32SeyZtVtEQKRjQnzBM e3MYtjzjY3k4zlkn1w2VYj2qy3qhP9+kkqt1GSfa3ZkUnmhOWjbxipyjXc9XnLWjb6zoez9OvfDE mpVFxt44gMycqOAhFgrYINLsSYxU4hnnm+2SqbKl2JQkj8oOsbKCzQH+EnX6pzVDBM4edTiAbOsl 0uQHbzRJwcicQRGXpbphmSEqm/1CKHci1XOleIRIbaGQ1ly7xhkn6bP7DD0ejaS7dl1lfM19TqQ2 U+bfPGHAIaePSB2gzAfXMMy7aoiLGa7qb2VkXLuSLVcOx/VSuikyxVFWTZYrOdm9lCGKzCGqlaLl ity93iUGC/3kU4Z1xpwJoYSVxkJ/WM6ICXok5FDDMGF8Le0lrtay0NqfMpKuzzUEtI9UflYY8sEu XLAJ3n9ysvvZSwv0FbXRG8FO28ffF2EwbWqcYVzgZLLENg5bRqgOTnM0WCsZ2Zy+3PIqv0/4a7bv zF9XP5HvL3tlNbx+lIl1MC2ZJN5LRXX3fOy9+zq8pSlsa1tP/bzFbLVUsZfqmue3codA+964eBaH hwMRANpTJjZW+3iAKDTFRgIvSAYC1e82AUCPThAEPEEA2AzZXBIAYtB8R+Kb+fPnaAcp7owpBqSh 96w2lKkOsQ5ka0JSFZqH1aGlBcSBFBTjvnBVv+/pfT/FlShoSUDVQ9Ax3LF5ndYRWEdgHYF1BNYR WEdgHYF1BNYRWEdgHYH/AQL/BQAA//8DAFBLAwQUAAYACAAAACEAPAIw/oEBAAD+AgAAEAAIAWRv Y1Byb3BzL2FwcC54bWwgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACckkFv2zAM he8D+h8M3RM5bTAMgayiaFr00GIBknZnVaZjIYpkiKyR7NePtpHF2XrqjeR7ePpESd0e9j5rIaGL oRCzaS4yCDaWLmwL8bp5nPwQGZIJpfExQCGOgOJWX31TqxQbSOQAM44IWIiaqFlIibaGvcEpy4GV Kqa9IW7TVsaqchaW0X7sIZC8zvPvEg4EoYRy0vwNFEPioqWvhpbRdnz4tjk2DKzVXdN4Zw3xLfWL sylirCh7OFjwSo5FxXRrsB/J0VHnSo5btbbGwz0H68p4BCXPA/UEplvayriEWrW0aMFSTBm637y2 a5G9G4QOpxCtSc4EYqzONjR97RukpH/FtMMagFBJNgzDvhx7x7Wb61lv4OLS2AUMICxcIm4cecCf 1cok+oR4NibuGQbeAWfd8Q1njvn6K/NJ/2Q/u7DD12YTl4bgtLvLoVrXJkHJ6z7p54F64rUl34Xc 1yZsoTx5/he6l34bvrOezaf5Tc6POJopef64+g8AAAD//wMAUEsBAi0AFAAGAAgAAAAhAEE3gs9y AQAABAUAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAA ACEAtVUwI/UAAABMAgAACwAAAAAAAAAAAAAAAACrAwAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAA ACEAgT6Ul/QAAAC6AgAAGgAAAAAAAAAAAAAAAADRBgAAeGwvX3JlbHMvd29ya2Jvb2sueG1sLnJl bHNQSwECLQAUAAYACAAAACEAqFqswzcBAAD0AQAADwAAAAAAAAAAAAAAAAAFCQAAeGwvd29ya2Jv b2sueG1sUEsBAi0AFAAGAAgAAAAhAC6spWmhIQAAE4sAABQAAAAAAAAAAAAAAAAAaQoAAHhsL3No YXJlZFN0cmluZ3MueG1sUEsBAi0AFAAGAAgAAAAhAEpV2LeFAQAAaAYAACMAAAAAAAAAAAAAAAAA PCwAAHhsL3dvcmtzaGVldHMvX3JlbHMvc2hlZXQxLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhANp9 4nKoBgAAWxoAABMAAAAAAAAAAAAAAAAAAi4AAHhsL3RoZW1lL3RoZW1lMS54bWxQSwECLQAUAAYA CAAAACEAYpgIjaMDAACOEgAADQAAAAAAAAAAAAAAAADbNAAAeGwvc3R5bGVzLnhtbFBLAQItABQA BgAIAAAAIQDQjTl8kyoAABL9AAAYAAAAAAAAAAAAAAAAAKk4AAB4bC93b3Jrc2hlZXRzL3NoZWV0 MS54bWxQSwECLQAUAAYACAAAACEADoqM1FQBAABqAgAAEQAAAAAAAAAAAAAAAAByYwAAZG9jUHJv cHMvY29yZS54bWxQSwECLQAUAAYACAAAACEA7BY4DtcLAAC0GwAAJwAAAAAAAAAAAAAAAAD9ZQAA eGwvcHJpbnRlclNldHRpbmdzL3ByaW50ZXJTZXR0aW5nczEuYmluUEsBAi0AFAAGAAgAAAAhADwC MP6BAQAA/gIAABAAAAAAAAAAAAAAAAAAGXIAAGRvY1Byb3BzL2FwcC54bWxQSwUGAAAAAAwADAAm AwAA0HQAAAAA --_004_4E1F6AAD24975D4BA5B1680429673943674FFF98TK5EX14MBXC283r_-- From Michael.Jones@microsoft.com Tue Mar 12 12:57: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 9DB7C11E810A for ; Tue, 12 Mar 2013 12:57:49 -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 oK9vzR4XElsL for ; Tue, 12 Mar 2013 12:57:44 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0243.outbound.protection.outlook.com [207.46.163.243]) by ietfa.amsl.com (Postfix) with ESMTP id A35C411E80D5 for ; Tue, 12 Mar 2013 12:57:44 -0700 (PDT) Received: from BY2FFO11FD014.protection.gbl (10.1.15.204) by BY2FFO11HUB022.protection.gbl (10.1.14.109) with Microsoft SMTP Server (TLS) id 15.0.620.12; Tue, 12 Mar 2013 19:57:42 +0000 Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD014.mail.protection.outlook.com (10.1.14.76) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Tue, 12 Mar 2013 19:57:42 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.132]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.02.0318.003; Tue, 12 Mar 2013 19:56:48 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: OAuth Feature Matrix Thread-Index: Ac4eqQVABmcfQE/KQwy7KfSVJ7BEnAAsOMGAAABVUGA= Date: Tue, 12 Mar 2013 19:56:48 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943674FFFFC@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B1680429673943674F7728@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B1680429673943674FFF98@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943674FFF98@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Content-Type: multipart/mixed; boundary="_004_4E1F6AAD24975D4BA5B1680429673943674FFFFCTK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(53824001)(377454001)(199002)(189002)(46102001)(31966008)(44976002)(50986001)(47446002)(77982001)(15202345001)(47976001)(63696002)(49866001)(54356001)(5343635001)(47736001)(80022001)(69226001)(562884003)(33656001)(74502001)(74662001)(53806001)(65816001)(56776001)(51856001)(5343665001)(512954001)(66066001)(20776003)(56816002)(4396001)(16406001)(16236675001)(76482001)(5343655001)(54316002)(55846006)(79102001)(59766001)(6606295001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB022; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 078310077C Subject: Re: [OAUTH-WG] OAuth Feature Matrix X-BeenThere: oauth@ietf.org X-Mailman-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, 12 Mar 2013 19:57:49 -0000 --_004_4E1F6AAD24975D4BA5B1680429673943674FFFFCTK5EX14MBXC283r_ Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943674FFFFCTK5EX14MBXC283r_" --_000_4E1F6AAD24975D4BA5B1680429673943674FFFFCTK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The attached version of the spreadsheet incorporates some corrections ident= ified by those who've filled it in to date. If you plan to characterize yo= ur implementation, start with this version, rather than the one previously = posted. -- Mike P.S. The version at http://self-issued.info/misc/OAuth%20Feature%20Matrix.= xlsx has also been updated. From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= ike Jones Sent: Tuesday, March 12, 2013 12:52 PM To: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth Feature Matrix We've had great participation thus far. Currently we have data characteriz= ing 9 different implementations, with more promised to follow. The attache= d spreadsheet combines the data provided to date. As you can see, the different implementations have often made very differen= t choices. I'll plan to produce a set of highlights of the different choic= es made to present on Thursday. -- Mike From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Mike Jones Sent: Monday, March 11, 2013 3:38 PM To: oauth@ietf.org Subject: [OAUTH-WG] OAuth Feature Matrix The OAuth Feature Matrix spreadsheet that I talked about at the OAuth WG me= eting today is attached and available at http://self-issued.info/misc/OAuth= %20Feature%20Matrix.xlsx. Tony Nadalin and I created it as a tool to chara= cterize OAuth implementations to help promote interoperability by understan= ding the choices that different implementers have made. Also as discussed today, I propose that people with implementations get tog= ether tomorrow (Tuesday) afternoon to take a quick pass at characterizing t= he choices made in your implementations to date. Then we can report back t= o the working group on Thursday with a snapshot of the choices made, which = will help us get a sense of which features are likely to be interoperable a= cross implementations. (Actually, all those who are interested are welcome= , not just those with implementations.) I'll create a Doodle poll now to help us choose a time window between 1:00 = and 5:00 to get together and do this. Also, stay tuned for the room where = we'll meet. Hopefully this will be a useful and informative exercise... -- Mike --_000_4E1F6AAD24975D4BA5B1680429673943674FFFFCTK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The attached version o= f the spreadsheet incorporates some corrections identified by those whoR= 17;ve filled it in to date.  If you plan to characterize your implemen= tation, start with this version, rather than the one previously posted.

 

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

 

P.S.  The version= at http://self-issued.info/misc/OAuth%20Feature%20Matrix.xlsx has also been updated.

 

From: oauth-bo= unces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Tuesday, March 12, 2013 12:52 PM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth Feature Matrix

 

We’ve had great = participation thus far.  Currently we have data characterizing 9 diffe= rent implementations, with more promised to follow.  The attached spre= adsheet combines the data provided to date.

 

As you can see, the di= fferent implementations have often made very different choices.  IR= 17;ll plan to produce a set of highlights of the different choices made to = present on Thursday.

 

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

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Monday, March 11, 2013 3:38 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] OAuth Feature Matrix

 

The OAuth Feature Matrix spreadsheet that I talked a= bout at the OAuth WG meeting today is attached and available at http= ://self-issued.info/misc/OAuth%20Feature%20Matrix.xlsx.  Tony Nada= lin and I created it as a tool to characterize OAuth implementations to hel= p promote interoperability by understanding the choices that different implementers have made.

 

Also as discussed today, I propose that people with = implementations get together tomorrow (Tuesday) afternoon to take a quick p= ass at characterizing the choices made in your implementations to date.&nbs= p; Then we can report back to the working group on Thursday with a snapshot of the choices made, which will help us = get a sense of which features are likely to be interoperable across impleme= ntations.  (Actually, all those who are interested are welcome, not ju= st those with implementations.)

 

I’ll create a Doodle poll now to help us choos= e a time window between 1:00 and 5:00 to get together and do this.  Al= so, stay tuned for the room where we’ll meet.

 

Hopefully this will be a useful and informative exer= cise…

 

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

 

--_000_4E1F6AAD24975D4BA5B1680429673943674FFFFCTK5EX14MBXC283r_-- --_004_4E1F6AAD24975D4BA5B1680429673943674FFFFCTK5EX14MBXC283r_ Content-Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet; name="OAuth Feature Matrix.xlsx" Content-Description: OAuth Feature Matrix.xlsx Content-Disposition: attachment; filename="OAuth Feature Matrix.xlsx"; size=19076; creation-date="Mon, 11 Mar 2013 19:42:12 GMT"; modification-date="Tue, 12 Mar 2013 18:20:56 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQBBN4LPcgEAAAQFAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACs lMtuwjAQRfeV+g+Rt1Vi6KKqKgKLPpYtEvQDTDwkFo5teQYKf99JeKhCPBSVTaLYnnvudTwejNa1 TVYQ0XiXi37WEwm4wmvjylx8Tz/SZ5EgKaeV9Q5ysQEUo+H93WC6CYAJVzvMRUUUXqTEooJaYeYD OJ6Z+1gr4s9YyqCKhSpBPvZ6T7LwjsBRSo2GGA7eYK6WlpL3NQ9vncyME8nrdl2DyoUKwZpCERuV K6ePIKmfz00B2hfLmqUzDBGUxgqAapuFaJgYJ0DEwVDIk8wIFrtBd6kyrmyNYWUCPnD0M4Rm5nyq Xd0X/45oNCRjFelT1Zxdrq388XEx836RXRbpujXtFmW1Mm7v+wK/XYyyffVvbKTJ1wpf8UF8xkC2 z/9baGWuAJE2FvDGabei18iViqAnxKe3vLmBv9qXfHBLjaMPyF0bofsu7FukqU4DC0EkA4cmOXXY DkRu+e7Ao4sAmjtFgz7Blu0dNvwFAAD//wMAUEsDBBQABgAIAAAAIQC1VTAj9QAAAEwCAAALAAgC X3JlbHMvLnJlbHMgogQCKKAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAjJLPTsMwDMbvSLxD5PvqbkgIoaW7TEi7IVQewCTuH7WNoyRA9/aE A4JKY9vR9ufPP1ve7uZpVB8cYi9Ow7ooQbEzYnvXanitn1YPoGIiZ2kUxxqOHGFX3d5sX3iklJti 1/uosouLGrqU/CNiNB1PFAvx7HKlkTBRymFo0ZMZqGXclOU9hr8eUC081cFqCAd7B6o++jz5src0 TW94L+Z9YpdOjECeEzvLduVDZgupz9uomkLLSYMV85zTEcn7ImMDnibaXE/0/7Y4cSJLidBI4PM8 34pzQOvrgS6faKn4vc484qeE4U1k+GHBxQ9UXwAAAP//AwBQSwMEFAAGAAgAAAAhAIE+lJf0AAAA ugIAABoACAF4bC9fcmVscy93b3JrYm9vay54bWwucmVscyCiBAEooAABAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAKySz0rEMBDG74LvEOZu064iIpvuRYS9an2AkEybsm0SMuOfvr2hotuFZb30 EvhmyPf9Mpnt7mscxAcm6oNXUBUlCPQm2N53Ct6a55sHEMTaWz0EjwomJNjV11fbFxw050vk+kgi u3hS4Jjjo5RkHI6aihDR504b0qg5y9TJqM1Bdyg3ZXkv09ID6hNPsbcK0t7egmimmJP/9w5t2xt8 CuZ9RM9nIiTxNOQHiEanDlnBjy4yI8jz8Zs14zmPBY/ps5TzWV1iqNZk+AzpQA6Rjxx/JZJz5yLM 3Zow5HRC+8opr9vyW5bl38nIk42rvwEAAP//AwBQSwMEFAAGAAgAAAAhAB0ldkGlAQAAswIAAA8A AAB4bC93b3JrYm9vay54bWyMUk1vnDAQvVfqf7B8Z4352OyugKjbpWqkqoraNDm7MCzWYhvZ3kJU 9b93ANFEyqWn+bD95s17zm5H1ZFfYJ00Oqd8E1ICujK11Oec/nj4FOwocV7oWnRGQ06fwdHb4v27 bDD28tOYC0EA7XLaet8fGHNVC0q4jelB40ljrBIeS3tmrrcgatcCeNWxKAy3TAmp6YJwsP+DYZpG VnAy1VWB9guIhU54pO9a2TtaZI3s4HHZiIi+/yoU8h47SjrhfFlLD3VOUyzNAC+NLSX22h+vssPT fRzGlBX/lry3WEzbPkoY3Et/Ksn4JHVthpyids+v8mFuP8natzmN4ijFEUvvM8hz61FuvoujaQ57 hT0LhDPmSPTM/vskGkcnpniHBDG3B4mJvav5jLA+q0RX3Vsyhflikm6j+QaM/ovzRYaRXK3M6W+e hB9uwn0ShGWcBsluHwW7JI6Cj8kpKtOb8lQe0z+rPSNP3xikZGWNM43fVEaxxZs3NvOQcb44XWSI clh/zsSyFdY/WFFd8L99g+YoHHq1LIQ8UZiVNVtfFX8BAAD//wMAUEsDBBQABgAIAAAAIQBpOAzm Zg0AACxMAAAUAAAAeGwvc2hhcmVkU3RyaW5ncy54bWzMXNtuGzcavl9g34GYm02ASLaVUzdwFDhu svWiTVLbabBXBq2hLLZzUIdUXPeF8h55sv1+kqM5S5yRHMQo3GQO//n8c3L86q84Yp9FpmSavAyO xocBE8ksDWVy8zL4ePl29EPAlOZJyKM0ES+DO6GCV9N//uNYKc3wbqJeBgutly8ODtRsIWKuxulS JLgzT7OYa/w1uzlQy0zwUC2E0HF0MDk8fHYQc5kEbJauEv0yeHz4LGCrRP65Eqf2yuTJk2B6rOT0 WE/fCq5XmVDHB3p6fEDX7PVzMRcZqG3eOY2kSDS7vFsK9aL+2n8ynt9jD4J5lN6q4GHjKQfiQ5bO ZdQC5WSlF2km/+YakmPnAqRDIh94xmOhIc8GwPoLapkmSgx4402WpS3wL9M/BBHi4LY/RSp7oZZ8 BlVCJ0pkn0UwZfgpiewF/X2WJnMZQoqSRzUJ+gNZrq4jOev7upO5IeNWXDO+XAKKEfQuoFbgdsRv wNLomisR7gtuAso+i0HQClM0zFZN5DQNBQwUzigYWWnw0Jt7UuCZYtqYhEjCZSph8vBjLeariKWZ /TPsWr3yBloj9iwmrUgNEmX+x55k1iDCdtNVNhPs/W0iMniGUrdpFrLTTDhDrIeAbkusgXbWvQdI Fye//DxhrwXPQOKJgk1RABgqxP9+uhwOa2ai3JUMvbE7u1i/CDPIVjMKriEZRbrkCGP+FoHXZCZm +mqVSW8a1AwJwv9pslnvp8lXvB/OhUH+tZscBEVkb7zm6atQqFkml72Mx77ZR9h8huyorkwg8CbQ Cab87o4CMvivNNIxooX1neARE3o29o9p4q8ljE1dSX9ny8Qcbyxa2Z8iy+h0lkbsjYuPjZTdHV0a 7yJ8V4N3DtRb6G0gbUrvDYr0d8oTphcCaRzWfS0Ykl/I4jQTuIpbKaomfz9vo+3c+T5VP4Mo/LTg mkVyLrSMBZOK3SCLguiUWcOz2QuXqVwD8fMsjRk3DPlTTqIYiMgZjyVjbxjZPYElPfsT2S8eyLDV g7rdwxhd77cMUaz3awbZwHcT9DQ1D53Gq0jLZSRGCB2mRB9R3FLs65fH/o8+8X/0af3RHK+Nl6dp fC2pxES3wC5Wy2WawRsa3YXJquw3HqEN6X6sW2XUtPUoJJa2LaqR3g0ejaH0byN4GEII/sXectHU Yzct6XweyURc2TBTZSFDv9n+5nsI6OxHdpomCSoe9gvoQy+hmH0f79F/H/BL/c0+8wi99FFwMD1G gkFhhUgco+MyV7K3KWpx88gpj+R1Jum5OY9ldGcvT+jCgQGmp1+/TMbOmgC83P2+PWXPnj/5Nwxz Mj6qsqGn58Xdr1+Oxo/HR4/YE4/HJvTYZAs0wKPHGv7QQPqEHmv4guJxNBld2xK6lfrfb9Gjbbhf QvTDRjImG3mBVLbc38QixLlRoHR/kyTN/a0QNlHwbIuejPg3E/H1y3NnGk09laT89ctTv8eOxk+N oY1hSJvIg+g3EP94i+BaDL5hVA3R14yqcR/jJKoWt41Qpo3niqEPe6BSFDMpBmoRX7JbqRfMFnHn Lpk0B00FuPoIaRM082wTWBVZabjUBqtasa4prOslh+lDXh1kO5ntEZZqNfrB4MIVSbbs8Oo9pq7D JwJoaGXHRQjTmNKFPSr7VjCo7tfDiM+Ss58uLz+w11w1RlvlsDuhoFuTZTfjXnjzKePrNLzbGbIb YRjt1oA5Np4e1q53k096O0FzgVbDDEY0TZ6U7TowCGZ24sB4VTu7dd2E09T2YdoPLUabGtNn/3K5 Szk7zoK6wHoMhaaXP1+wBzR4Vy8est/s/L5eME3dYF6naaTGUui5GcYvaAafzWdUPNQUvPWNhkls eiPM+FyPCO8oJc2PyjG6B+YGnCKSd0Cx1ew4ERqrBzFTBxb/58moo7ofHV0djkkw3gBNvTyCKVE5 OIpdOdgJB7n02fOnh+zBe4pQbDI+dHO/+gBkakntoLNOngGLGrAE9hRNfgNoR/VaB3cBYcl5Hjx/ lskfjdA5LccNdonmXMVS0fooD7ZVoChaOypqW15AJvYFqp/vr4R2kbhcQn8nlLk65DukzJWeZcr0 9NOnT6NSkhVFufQTVnyYib+VIqpNpL8LSffkxu7PvkNbXlcVVb2UY2seDig/MQzvaIPZCAlFEM0f p7zT/nS3AitovztH/ubUtTiznn5U2KYzo4z1wkjZ5mCdDXwNraS1707a35i2DbKGJQ8V8Dc2mdao VDUVmjlp9DTgCK2NralNZ9lhPHpq2O/9Vkl9LbPOilya9ze3Bm/RAtzSvB9rCDbD8l3RwF8vaOpv TmOY1RDtKPyL8nX5b3oNOyzFVI3mn2hBmMpHpf0govkM09tkRPNU8trqLsLsIFxzmu8nBiKibinf n1LxJPItFJ28oPaEsKN9zu7Ycn2oZChXw5Bh45b2Vgmh4skdwwxX0tCaR61slpkKxRzzWLOB7mcC pvujTsgdYHqgHlZ1z6j3TDERyP6lCgn7WwSsgZZoVO80z/qU6x2GQz8YNAzRj8MBF4lHb+joFSRB DX4xvNkd+MfzM/arsaX1rGp3oEEmeBQHhSaHcE/mQiKWCXwXu5/MHqR6tL5gvPsRTCrEJbWaozuh s11XduFhNuJqCGIKHy222ihvMRK0B7UcKmesvW3I7u5LW3/WjWrt8EMYc/Zk8eGswD3iWbUWNlzV HMacxRmkJPDSjoP8unV8MlBiFK0Qb0+0zuT1SosLOnYSw86YiMz/kbCSRglnlurVVDwQv+XS5O37 EJ8BfE8yKwX6WcRlbCRlEO5JPC1eWhQNSNdDs8e6gMAycyZCOmFKh6BOPpzlecQwgAMJmbiRSqO3 tWPMHmfm1jgoApvqhAofA5fU4Y4OWrDlE4RDUAAwRVJzyq8UlHNk/hGLiK5EkXLUInAuHM+ZSh+x RXq7A2gKUHsBWRwPKsSLnH2D3XlUreIq1BvvNaWprR17s9KG11WISOSV8nFPiE3VY9Nfqd7N3YAS JVRi6iCYw52Rhj9XLc4WC8z4WDpHYRrHOKRNqxXESriLPa1pMg3CIwwaB76pliWF+qMkc/uY0OjI 6GEms9kqpjPnOLpm2Ki2Q859OsLkfaPtDKL+iI3+jOYqcYYg22IzRIGDU7Au8/gDJkEa4FYTlUhD kN/haDqOMAyH2wxgu4A1pBr3sVaTnwPLA1Y93foLAsGLs3epfi0gibUgbVxopvF+cBOERrUSZwlZ 6Lo82B32WnntQh6iNyNgHt0gDOpFXDE2JDUlb7wqGn/xbMYHm87ulrquVSu5ahHlj5KktjF2FIXI /QeMAtdeo0TDjwPsWwL2AL/R0j1EUYKqy19kRkvtRhao1TUA4/fvWGoNg7zJoUlA/oQaLw6S6zlI SlKNHS95s6Nq7XD9YSYskFznAkSOzjkdCHOL5wa/a4kPnQYoabPrFtY21Hn8/HVPeLoTXsBXIbSB 3ybv9TY7kr8tV2n0RP0AxxFOVqqQqoUX5pD+RkjATU1UHmf9ucJJdOoO0evEZkaGA9UO4YqOBd4P fOpJYaO94BPt4i+d8aIjUPmEEfUpsiGlcNrOFwMuN4NhSBBwuB6VXE1Q7VDXw41K60Y4IdQeyHpo hljsd0B6CyduJNTOSv/q12CrzkxtUW3ONhvPqQirHwY/XizCfXBUw2cGeOgW7PGxfSDooXnbf9lz ZP2cslxVpImdZZutBQcv9qCg5cyk4R52S+LZ7pFVqe3qiTm0Pdpth5bLw9JyyMnbUzQ5/ayXlO2G Efm6hD43K2AzHt3yOzozaCMIfUFybfc/+D7OhDh88NIai/pZBKiws5VviJCX01jBIsJ2YYbOtfyZ 8bPA3Mpzz93VBuvw9hEJakZYoLg/Q2/g2F/gXMe1aiqomm6+JywcYIfU0IHRhou9YqppCiNX+/Fd jmQfTGwv0czGqm8JBb/nLDDlZOBmuJnAN7O0snT1U+cqx98pSRUbck4Vv0xm0YoWhQ5/vqQajq4y dJPgGBtp+qq1/J1qjfl7QEaB3bamuYT7ITFWBu9xucCW6FhQQFLu7ARNLuvzxJ0nAzna0irkwvbQ OIQxl24s+iPXPB++QcCGKuSqGjX+DLdgBbq8UtkdPlmkbRELxyojoG5rZybqZl+xQw4Um1ZyBr2/ wNoY2gg+57AfCtLLZgM0LfXOVkfseOLawzxqq6KgjPzAh9sD7kE9OaRhmqhb73anzPFQETnYMZEw MrGM+B0tTWpQ2DIT+MwZn3D6G1U5LVT8w8bpEzTvycV6YV3ODTXk/igrLBhzHUD32t9Ap23B3Tk2 iIX+3iAck06MNMO6zPzJJoyGdNrXZnatAGSVxmE9iHI+2kMRDjzRXgG5LmV9ehF7bgwATEPsz5sx 5tphpzDFuGsZpXcQWlFJocHyB0s85Zlkc9SqGZM5W9V6BsMfueHJJnzYCDWGBioJ2PlqnjDrMKf/ w/KR0b9BYwZxRtXVM7QdXx0Qv/RjeC5CVoX10lCvssCtE9F96LFiHiP268c3F5dn79+xs3fszfn5 +3M2ov1UXr7RNyq9iIeN72iERRtjzRAENYgsSDrAv/Y1/T8AAAD//wMAUEsDBBQABgAIAAAAIQBw sUC9agEAAMEFAAAjAAAAeGwvd29ya3NoZWV0cy9fcmVscy9zaGVldDEueG1sLnJlbHPEVE1PAjEQ vZv4Hza9dwsI+BEWLmrCwYvi2ZTuLFvptk1nQPj3FghGCAYwBI4zTd+8NzNvOr1ZZZIpBNTOZqye 1lgCVrlc21HG3gfP/I4lSNLm0jgLGZsDsl73+qrzCkZS/ISl9phEFIsZK4n8gxCoSqgkps6DjS+F C5WkGIaR8FKN5QhEo1Zri/Abg3U3MJN+nrHQz29YMpj7WHk/tisKreDRqUkFlnaUEGVECkbbcQSV YQT0A0vOGUw1ULGkWVJlRB5kQXyR405OqOQoK9PgQ5ABwhrhxeWR3NOMIFhpmNit4vaUKnzQNpZ7 A6I4JlwzyViaiq237bieDrX9i2TjlCSPa3UoVPu2FZdvNZbDmlq/MN/m/XF82+fhu3CdzlMLJNCD QrFKcOWsBUW8AsRoQeT1j1q6WPTjVLQupWJpwWmDVxND2hvgAdDHAwScoq3/K6d5HjkH3ZfPL9p7 XcTG4e1+AwAA//8DAFBLAwQUAAYACAAAACEA//H7gKcGAABbGgAAEwAAAHhsL3RoZW1lL3RoZW1l MS54bWzsWc+PGzUUviPxP4zmnubXzCRZNVslk6QL3W2rJi3q0UmcjBvPOJpxdhtVlVB7REJCFMQF iRsHBFRqJS7lr1kogiL1X+DZM5nYicNuVz0U1N1LxvO958/v2d+zx5ev3A+pdYzjhLCoaZcvlWwL RyM2JtG0ad8e9Ap120o4isaIsgg37SVO7Cv7H35wGe3xAIfYAvso2UNNO+B8vlcsJiNoRsklNscR vJuwOEQcHuNpcRyjE/Ab0mKlVPKKISKRbUUoBLc3JhMywtZAuLT3V867FB4jnoiGEY37wjXWLCR2 PCsLRLJMfBpbx4g2behnzE4G+D63LYoSDi+adkn+2cX9y0W0lxlRvsNWsevJv8wuMxjPKrLPeDrM O3Uc1/FauX8JoHwb1611va6X+5MANBrBSFMuqk+33Wh33AyrgNKfBt+dWqda1vCK/+oW55Yr/jW8 BKX+nS18r+dDFDW8BKV4dwvvOLWK72h4CUrx3ha+Vmp1nJqGl6CAkmi2hS65XtVfjTaHTBg9MMIb rtOrVTLnaxTMhnx2iS4mLOK75lqI7rG4BwABpIiTyOLLOZ6gEcxiH1EyjIl1SKYBF92gPYyU92nT KNlqEj1aySgmc960P54jWBdrr69f/Pj6xTPr9Yunp4+enz765fTx49NHP6e+NMMDFE1Vw1fff/H3 t59afz377tWTr8z4RMX//tNnv/36pRkI62jN6OXXT/94/vTlN5//+cMTA7wVo6EKH5AQJ9Z1fGLd YiGMTQZGZ46H8ZtZDAJENAsUgG+D6y4PNOD1JaImXBvrwbsTg4SYgFcX9zSu/SBecGLo+VoQasAj xmibxcYAXBN9KREeLKKpufN4oeJuIXRs6ttHkZba7mIO2klMLv0AazRvUhRxNMUR5pZ4x2YYG0Z3 lxAtrkdkFLOETbh1l1htRIwhGZChNpHWRgckhLwsTQQh1Vpsju5YbUZNo+7gYx0JCwJRA/kBploY r6IFR6HJ5QCFVA34IeKBiWR/GY9UXDfhkOkppszqjnGSmGxuxDBeJenXQD7MaT+iy1BHxpzMTD4P EWMqssNmfoDCuQnbJ1GgYj9KZjBFkXWTcRP8iOkrRDxDHlC0M913CNbSfbYQ3AblVCmtJ4h4s4gN ubyKmTZ/+0s6QViqDAi7ptchic4U77SH97LdtFsxMS6egw2x3oX7D0p0By2imxhWxXaJeq/Q7xXa /t8r9K61/PZ1eS3FoNJiM5juuOX+O9y5/Z4QSvt8SfFhInfgCRSgcQ8ahZ08euL8ODYP4KdYydCB hpvGSNpYMeOfEB70AzSH3XvZFk6mSeZ6mlhzlsCpUTYbfQs8XYRHbJyeOstlccJMxSNBfN1ecvN2 ODHwFO3V1iep3L1kO5Un3hUBYfsmJJTOdBJVA4naqlEESZ6vIWgGEnJkb4VFw8CiLtyvUrXFAqjl WYEdkgX7qqbtOmACRnBsQhSPRZ7SVK+yK5P5NjO9K5jaDCjBp41sBqwz3RBcdw5PjC6daufItEZC mW46CRkZWcOSAI1xNjtF63lovGmuG+uUavREKLJYKDRq9X9jcdFcg92mNtBIVQoaWSdN26u6MGVG aN60J3B6h5/hHOZOIna2iE7hE9iIx+mCv4iyzOOEd1ASpAGXopOqQUg4ji1KwqYthp+ngUZSQyS3 cgUE4Z0l1wBZedfIQdL1JOPJBI+4mnalRUQ6fQSFT7XC+FaaXxwsLNkC0t0PxifWkC7iWwimmFsr iwCOSQKfeMppNMcEvkrmQraefxuFKZNd9bOgnENpO6LzAGUVRRXzFC6lPKcjn/IYKE/ZmCGgSkiy QjicigKrBlWrpnnVSDnsrLpnG4nIKaK5rpmaqoiqaVYxrYdVGdiI5cWKvMJqFWIol2qFT6V7U3Ib K63b2CfkVQICnsfPUHXPURAUauvONGqC8bYMC83OWvXasRrgGdTOUyQU1fdWbjfiltcIY3fQeKHK D3absxaaJqt9pYy0vL5QbxjY8B6IRwe+5S4oT2Qq4f4gRrAh6ss9SSobsETu82xpwC9rEZOm/aDk thy/4vqFUt3tFpyqUyrU3Va10HLdarnrlkudduUhFBYehGU3vTrpwRcnukwvUJq2nd2kSMDWbUq4 +rp2acTCIpO3JUU5AnmbUq7svk2xCKjPA6/Sa1Qbba/QqLZ6BafTrhcavtcudDy/1ul1fLfe6D20 rWMJdlpV3/G69YJX9v2C45XEOOqNQs2pVFpOrVXvOq2H2X4GQpDqSBYUiLPktf8PAAAA//8DAFBL AwQUAAYACAAAACEAZSTiLo0DAAB9DgAADQAAAHhsL3N0eWxlcy54bWzMV9tu2zgQfV9g/0Hgu0JJ tlzbkFTUcYQt0C0KJAX6SkuUTYQXgaJSu4v99x1Slq1tNzcnDvbFJkec4Tkzwxkyeb8V3LujumFK pii8CJBHZaFKJtcp+nqT+1PkNYbIknAlaYp2tEHvs99/Sxqz4/R6Q6nxwIRsUrQxpp5j3BQbKkhz oWoq4UultCAGpnqNm1pTUjZWSXAcBcEEC8Ik6izMRfEUI4Lo27b2CyVqYtiKcWZ2zhbyRDH/uJZK kxUHqNtwTIretpv8Yl6wQqtGVeYCzGFVVaygv6Kc4RkGS1lSKWkar1CtNCl6B6btDvNbqb7L3H4C B+5XZUnzw7sjHCQhwllSKK60Z8AzAMxJJBG0W3FJOFtpZpdVRDC+68SRFThn7tcJBtSsEFscHZos WdlVb7TX6+xzP3xH+XyuOsA/8z7tIyEJbBBfM/5suOHZyLm4NZB3jPPDKYhswoMgS+A0GqplDhNv P77Z1ZDuEgpHl7Zu3SOr15rswigeKGC3IWS60iUUqv782aPWibKE08qADzRbb+y/UTX8rpQxcKqz pGRkrSThMMS9xn4AdArK+bUtZt+qg23Lalt5shW5MB/LFEFZtIeuHwKR/bCz103A/n1KMej/t5JH 6prvPrdiRXXuaqXbzUmtL4+zheN/nH/gbC0FtbUI4DmFL1oZWhhXy12W4SG7juuAZjg6iae3rR4l bB12D+Feu4M8YGEjCrWwI+VtlGY/wOe2iNr4Iu+7JvUN3QJfV0Hxtrrf4WfY36bPG29pO7NhhXUB 5PTzPBA+NQK2dVmX/j/i8SZoRs/1zQNHe/yKts4fsxck1JOP1MkhfAG4Z3vugYg+UKy72nXCWXkB tckJCebqPlT6QXv7V3M7tAXP3kNS9Ad0as2ZvIVLrSvuQHHVMm6YtKV+atvxzzqfbbfivQJkx0Dh p+YDOMrtsb26r8be0l3jPSADGyWtSMvNzeFjio7jP2nJWhEdVn1hd8o4Eyk6jj/ZW0A4sZChWXxq 4KoM/16rWYr+ulq8my2v8sifBoupPx7R2J/Fi6Ufjy8Xy2U+C6Lg8u/Bo+EFTwb3tIEOFY7nDYeH hd6T3VO8PspSNJh08N39B2APsc+iSfAhDgM/HwWhP56QqT+djGI/j8NoORkvruI8HmCPT8MeBjgM u3eZBR/PDRMUUqOPVR+hoRSCBNMHSOA+Erg5vBuzfwAAAP//AwBQSwMEFAAGAAgAAAAhAF2RztoK EQAApWwAABgAAAB4bC93b3Jrc2hlZXRzL3NoZWV0MS54bWyUXdtuGzkSfV9g/0HQ+9gidTeiDCYJ BjvALjDY7OVZkduxEFnySkoy2a+fIqvYZLGqbdaLYytHLNbtdHXrtPrNz388HUbfuvNlfzpuxu5m Mh51x93pfn/8vBn/+1+//rQajy7X7fF+ezgdu834R3cZ//z2r3958/10/nJ57LrrCFY4Xjbjx+v1 +e729rJ77J62l5vTc3eE/3k4nZ+2V/jz/Pn28nzutvfxTU+HWz+ZLG6ftvvjGFe4O7escXp42O+6 D6fd16fueMVFzt1he4X9Xx73z5e02tOuZbmn7fnL1+efdqenZ1ji0/6wv/6Ii45HT7u73z4fT+ft pwP4/YebbXdp7fiHWP5pvzufLqeH6w0sd4sblT6vb9e3sNLbN/d78CCEfXTuHjbjX9zdez/149u3 b2KE/rPvvl+K30fX7aeP3aHbXbt7SNR4FBLw6XT6EoC/wUsTWPN5e+xGPz4+gxsRcz09/717uL7v Dgew4Mej7e66/9b9DrDN+NPpej09hf+PKb7CSw/n0/+7Y9xDNBV2F9bkYFwEF30/hTf/L3oAv8Lm b/vdl78nT36N5fD7eXTfPWy/Hq7/PH3/W7f//Bi2O7uZQYBDnO/uf3zoLjtIMLh1E5fdnQ6wBvwc Pe1DoUJ+tn9gHPb318fNeLUej3ZfL+DRf/EFF3bTvwF8j2+Af7/j/0OsX3oD+BXfAP/SG7y7cZP1 dDkfjz51l+uvFGNp9BY3GwPxYXvdvn1zPn0fQXnDri8QTmgWdxfithkv0x4wMBESgzG/WQwEA5wK a/0SFtuMAQVBukDuv72dvLn9BkHfEeKdRDiOeI8IB5HoF/GzvMwt7LvfPIDKzeMu1T36OWwHNxne tBlDXvP6fAvvEDGPpVOaC/EpYqXWRbKCsQRneivrygoiIHM9YjHtIcxN2Guz3YDdjGHtflWXgxcD 8A4hLYYB02w4YKHkC8Oz3hu0iwgZVqiXZisBW7lXFdA7hLS4B5XebDhgK8O+8g8hLYbDAay1kAK2 MpzLBAOLkBbDQEjNhgOWJ7S2iwiZUAdH7GYzEVw5WFcOYZiHGcN6xQX+aI1tBFe2p8sqrQRS3Kzo 50U+CIRW53FRW0rEk5t3Me8x3E0LFzmkGkYK0k0EKW5a6Mcp/CMCqhBQDgV3E1Lens0AfjWbCFLc tNCQU3ho1WcKu5IwrGhzKLibJRNBEbxcSQoVyWwmMgrjT3kMcyX3vGpKIZ/6MBYX3IyZmzkU3HZJ P6/aRnZ5pWiHKMiXFPSaqQjmhePrgyZhmJs5FMxNX1LQq7Zx3nnZzbhiiHGdTQ/L9/3xqqkA5m66 eU4VVm1ckadzmWPB/QyMkaj2VeNIL1BQ/WCSqY1MI0TxsmSgVw1JBvL1iOAlAy0zhjsZ+KLZyQDm Efb1lACTaMAoXpYE9KqXCgHNcz1SQBGkmLLwjZd84+tJgDBldyyz4zygFgLykoD8VNQNghQ3LXzj Jd/4iTA1xDdTC99EMC8Tt8hNhskjkPRqaqGXCOamfJ6cyBJSEEteTjBLXjhBbe6GCOa23Vq4GVbU 2mFqYZcIrk3ljiY/h/hlauGXCOamfF0mhGERzVHnEQ100Mov0wDmtt1CuIkgpXAsBDOVBOMneUqj iA4RzNRCMBFcebXO7EGmhgaaqYVPIrg2lWudTA3xydTCJxFcm8pFQKaG+GRm4ZMI5qdqdaYIIoti ZmGTCOY+eWFJYZPcH6z2ZxY2ieDKdh6nMZyEUby0kMkMeQJ+9qPKrE4cYRRLFi6ZyVnFrXOwyKk0 rNTD38xCHRHMw+fWIndD1DGzUEcE83IUiRoijpmFOCKY++TreZYw4FifzGV2m5ejhUlmSBJlkbi1 cHOISWYWJongys161CNMi5tzC7VEMLftFjU3E0g2w9xCLhHMTU3raYEwTW5ayGWOUwjLZnE1FhuR QIqbgTBaj+HzAOZuunVdtQRSTFnoZY7MAUXY1744rhJGsRS4oNmpAOZOiXOEOWJY7nLDsE6cW+gm gmvbucUpd0OEM7cQTgRzU25dtyKBlIha+GWO1MFyV096hFEsWehljjNIWftTYSnNKbmSltlvlruF hV4imAd0VtsmjPRyYWGXCOaWpjWPEUaxZOGSheQS+Fy5ujhIIMWUhUsWkkum9TRLmLLtVnk3PHUW clkguZRl46Y1jxFIcTOQQSu7LJA5SlPTeiAjDHMzVxJ308IuCySO0rZbCOND7LKwsEsEVyVaD4OE YW7mMuZuWuhmgXRTurkWlYQYJZkWullIupkJS4lu6pF3aSGXCObx9JNcE3hgIJB0amlhlwiuTeW8 kKl0ZiS8stDLUqOXOoAEUryCDDf33TKA+SBfNzhBFEMWLllKLvGTuskIpJiycEmQSlQ+iWtShFEs WZhjKZlDXLokTNnOyxxi1s5LC5VEcFWPM1GPYcXqUv/AQLa0cEkE18ZFhQ6RydJCJhFcm6oOtYRp ifHKQi8RzG27aR6KsOcJJEtpZaGXCOam/CSnikwN0cvKQi8RXJvKJUmmkIMUryz0skJ6gZ/96Ymf iAAiSDFlIZgVEgzUXG9qJSwhRrFk4ZcV8kvplJimCcMqMu+Gdf3KwjgRzHMnmp4wipcWflkhdZRe ejG4E0gxZWGTFRJFaUrMuIQpAzo04wZNXvMBMIJ5QOWMSyDp5trCJhHMTYkZlzDMzTzPsLpZW+gl grltVwhPsOcJpLhpoZe1nF7EQZEwzM187OJuBnZoPY1YBzB3U86DBFLctPDNGrmkLFox5BJGsQSe tzsVwJVTQvG3RpBiykIvaxxoGInWRwbCKJYs9LJW6MXlSqeCRJBiykIva6SX0ql1PXkSRrFkIZM1 ntTAz/4YJK71E6Ys/eIiPSt9N7HQC6I3Y2a9niASqM28hWHcBIcTZr6unQRi5geOi25iYR1Ec+/B 2WpQTCiZZzex8Ayia2t1+SaUZs1CNW4iuQY8Eb4hqoztKl8krSoLUM0E5CYBzRkIfBP2EcXs5/qr 7FtYyU0kLU2zZ8gVCaQF20JMboKkU9ax1N4RiPmaA1L5aiErN0G2Ko8r3slcI0pzFjZuyGxA8zou lPgpsggqnR2S/jgmDIYGflnnSKrfMtZO2u+1wfVVFcekwK9bkwzlxEiLa2pyFRcFvq2jCKKrphGz ekIpiYyS3nZrOPmUkRSXah2phMtErvKRkFdtlPm2m1cYqr6w6Ug5rPkKW2ovWhfQPLLirNwRSDNm 4h5FB+xdbnVqkV4JLEvURD5Oko93OUXJGqI030xcQ8JeeE8/r8ylsUGqcYEX2ksEWaSsUKEscXHJ 6oJV3hGvUJMA2JG6tzQ/ExWqSIBXGVSZN01HpO9l5sUhrBcBF/nIQ0Vl3jQdkeaXmc/HZiorRRg8 z5VemTeNS16y0yyPfck8gkp2GjZvmp9IDMy8F6OpohgeNm/iK9IDM/PSeyS1Nu9NDOZxeirNz8Vg TCBmPk8dVe5NlEbCYUYyuadS7gcZLeqDm0mG1MTMV9lmidFymxWCl8pXWKqd40hhzMzLNgtLco4b NG8SHTsSFDPzos571XGD9yYhsiMlMjMv6pxAZaENe2/iOBIjl+aF5NoRqM28ieNIoMzMZ/KmOidQ m3kTx5EguTTvFqL0e9mymFOi8LjoM6jQMHfjfcbFfcIvD/QkXy6bHc5e6zPFHiV3YWI2TcEsz9V6 lLRmIjJNxCwu+bkeJa0F2iki/EokkaRYJJ3MJ6LwHnh2E5hJyQyfakVOgoLvJ0EnFLEqymV+48xp 0jfDWZ+yAXGY0FAuM1y1AdOApgif3UzEW0O5zHHVBkz0RcpmlnBxj5rrNdKivKJeubm8FAW0m+VU El1pqOJWq8pdE18pwmjvZMLTeaV0Fzi0vZsUbbSX3aSg3LC7JqoixXTZYL5onRRvHNWUdjappiGT sZt4LeVxLllDlGYt0Ep7LSUSKskjd2WypqAKBWlVS4GP2jegsVfuyrSBhBK1ZNJLO00wLQdqDTVY SyYVtVNk1L5gQXK3R0l3TbykCafnYrDRUMPumgYrRU7tC85N7oY1w0Uh6a6Jl0gtXTaqWwhi7FHS momXSDHNG1W0DqE030wkpOio3VzQgoYqrtTwRjWJq52mrl5Idwd5Kcqhm2mBxNNlKr08ovYomUoT CSkia1dcQEhlmkio4Eqfy4sH1yS0hvtLqQOKpReCBXuUcNcktoabEoU1L6849yhpzURCJKZmfSI0 InDbyhAHRIl0c+EoomtX3CJPqdRQheC8SqWJhBTltZeXuBUUnN/2J1vVBky8pOixXXH/fIpAWFPl 3Kipbo93GnuKyi0+YUrWEkrWkuk8ThFhu2W+zpmsJRIq9jQc3DDbtLurTEJLcZKs6LVfyK6JqhSB tluK2VtDDUbAJNuGZpLkUUwLlAIFNRwBk5gballuQNyKllGi4qL6ujnhmqBbfGuEU1AvuGsaoUjD zY+EouR7lHTXxF6a1lsoJJ2CesFdE3uRurt01xW3hKbyGmSvqNluz27ipcwU8JWKPQ0naxL1grsm QtOk4EJZ6HqUzK6JvRTtt5OfGmqoIij82GQShDtNES6+8SKjhLsmCbhTNOBefBtERklrpqtQigwc ElfXkoYqBDE8uCZtuFPE4a64X4GKWUMNb8BEVSQZ55OeON3sheUy3iaqItU4Y4q5OBJqKJ8n6yre JqpSxORQuiLhg1RlUo87RT7ui1O7lN1EVTK4Jl5SJORuLi6paqjiUFwF10RVirAcOlUEN41j0l3T VKVIyX1xapeCm04AhTWTmBy+ZidOMLxPxBDZa86lNRMvafrxlehKDVVov3kqowa8+SCrqMqBq+pU aqjhDZh4SZGWO3GDidNQwxswUZUiOHcrMcNpqOENmKiKJOaMKwv5GNW3hhreQGCa9hpIvJQHLVfI c9IGFNTwBkyEponW5VUIBeWGN2AiNJKp8xQIRu1RsulNhEZSdWZtLoYRDTXkLtwlb0g4ornQz4uv f8mo2l249cNkTTknLI7yWF64pnbNw5v06ojmvrlVHVwVNRxcC6H5KHivN1Bfi1VRwxuwEBrc/huP YPGqdgpu8RI7WsD39JlSifMSOziKDxdxTT2VFl6CL02LjgQxcv70XH6xIMFYOxVK0spfCzHBnaLa DmpiSDC+g3wUr3ZgYSZPsvUqBrKew6JV0RXnbtUOLGwF95VqMZAFneavIlfF+RzfgUnN7kmnXsWg HuYTjGchjzLVDkwUFvXwINxhlSjuFfME4zvIs2O1A8uFerhVgRIMZExNXb5ULQ07aD78g+paLl28 VC1toqL+O62LXQ9SUVSWtw4toGmQuy5eqnZt4p1eml7sOg0/4lgYleXtu0ZCKbmZpOnyQ0j47NmU xkQBxa6Ll6qAmCiA1ONs16ndRUBM8nH43FCksXyJ79r29dCk+i53Xb5ULW3qRlJ0s6WLBq2WNnUj SbrZ0oPdGLXVzcVHSmy29GA3RnF1+9JF6xE9kTo7WqsCYupGUlDHZ+mkpbEb40vV0qbDO0mo2dLY oNrSpm4kwTRbGrtRW9rUjSSGZktjNypLm4TOnjTM5dLlSzzWJhGzJ30yWxpPDLRdm7qRtMdsaezG Yml8khE+wOfxx3N3PuyPX+AhRP3v9OCmOHWe7/b3m/H5t/v42CEJgSLpIdGGhECye0jsAQmBpPWQ WdDXCEiYfHpIvC1JQiCIPWQRVTo9Btx73n7u/rE9f94fL6MDPBwqPIIp7B6f0hR/h8dKxVehhfEh UumvR3i+VwcPJwoPbRo9nE7X9AdsNaz7sbt+fR6dznt4tFN8ZNdm/Hw6X8/b/bXY0zLuqX/A2Ns/ BQAAAP//AwBQSwMEFAAGAAgAAAAhAPyky/RUAQAAagIAABEACAFkb2NQcm9wcy9jb3JlLnhtbCCi BAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAISSX0vDMBTF3wW/Q8l7m6ZlU0Lb4R/2 IE4EK4pvIbnbwtqkJNGu396022qHgo/JOfeXcy7JFvu6Cr7AWKlVjkgUowAU10KqTY5ey2V4jQLr mBKs0gpy1IFFi+LyIuMN5drAs9ENGCfBBp6kLOVNjrbONRRjy7dQMxt5h/LiWpuaOX80G9wwvmMb wEkcz3ENjgnmGO6BYTMS0REp+IhsPk01AATHUEENyllMIoJ/vA5Mbf8cGJSJs5aua3ynY9wpW/CD OLr3Vo7Gtm2jNh1i+PwEv68eX4aqoVT9rjigIhOccgPMaVPcKLfVqguefMtKqgxPtH6PFbNu5Ve+ liBuu2IldxA8+G3bDP9WPXjocaCDCHwyeuhxUt7Su/tyiYokJmkYk5DMyiSl5Iom84/+8bP5Punh oj5G+JeYhiQpyTVNYjqbEk+AYsh9/juKbwAAAP//AwBQSwMEFAAGAAgAAAAhAOwWOA7XCwAAtBsA ACcAAAB4bC9wcmludGVyU2V0dGluZ3MvcHJpbnRlclNldHRpbmdzMS5iaW7sV2k01G0bv8ekh6es iRhlKUmMPYMYCpWsjWVkxm5sgzGMMBkqbZStZIok0XiTLVlGhaJ4kyVb1hCPZZTljShN5v1Py5c+ Pec8H95z3uO6z7Xe93Wd//07c825bjzAA1uAAdYACUyADWTZAg0oFgoIwBtEQIwEWkAdaAIUZHmD 3wm2AWwcAn1SdhzAAwMwMPMnic8b0kLACfJ5IAmHPEuoGgVaBKjuPyfYzxIbIM0D8S//98q2GHPH MfXfo//c3/a9hLAidwHA5R/0FKTBf9m/618bphLCAG8BB34m3K//QVzcfieNcS04LxTkQHtc/pX/ +7l1//8bgd9/GU+h69pZ2R/l3loYlAKn7z1FApFAFmABCeovItTHBBAMdRu3h2XBPqAD8T7IsgV2 UJYlwcPbP9jXzNuXAICthy/Bzp9KgKIUCiH0u48h+PqTggEwDQ8JJET+VNYk+/Agz0ACwBDCSIHh FO4JHXX1SIi9Q/y5X/P3yFQCAA1rjBP3Xpsh++9SrfsnUz6oD+b4haEUGPhD9oCY9GZutpWdySGu 7uDnSgBUfigAh/3oKz11AP2rcXNgYEr75+ZPpabmEOxFCgoJJYSFEbyRph4UDzU1oNeurBPBP6Vt YvECJxAojRW5hRuMz6pj9OW0DpBVqy3GRxsfzLfFFslWZO32J4p64dxN5TSTcIdPBDY9QGQu2Nki Os4cvF/gMCPup2CLY+ooBC0OmvIkSJ0x3nPxOVK+YMNeUdO8s3zC8k9RWo9ra4yaELNvW2dYrTW0 +dkVn8nWzOMlmRlVFO1raUhZW7tFlyKr1tkiMzT7ug2l/NTgAC5RNgaRFlsp7aDw2WBsR6NzkKDK AYe7bOdJk2YZXNLewmjFqgglzo7FbLibqctG85c7vaqGPzD5e1BpdZFaBYpirzwxKmFH5mterdzC rL3E2P+xgT6U1T15dYh9eYEXXbB7/HhQu5rJp6AJBD1nNeljTHCsNaO/DdlODFOI0Nu5JzpTRayR WrOyWW1CIqG0M16YZjFbe1KANVgr2hM3OqXU/HAA6Rlx0ix/yOeO/r/YuxaNHNf2lkwGZQWM7LWf qqBp5d7iESJIzvsN8p9nF8dxsj5mT9TGYtbyWzg4R1w7EltRnfZYbZl/pHHVlcFWMCoIzUYzXAfn fHhRnyMTxra6I2hde/0+vRxjfHhRwbpoYvCqplnmrw7ctdjUQaMctuakUS7bYijfbYr6+hYR1C1+ kWvQ0Zq5pHQCb8yWPKhzYtXz0QhhZfviizRDP1RSXwucWhWtVCD3mJxsqWfPd+LSMEfYi11O4+hZ qLTjPnncozWK3EcH9ExRFiIuHfvmKtETrNZcdt7n68rKUpU/J+mMUt7J+WfWUcf7atOjNV3ztuHz W/Gv+1G7W1wjvj2kI570KXSb1WgfNNG2jlkVmxGZyRcvF+jc89m1/A1m+1Gk5CvCEfSjiobnr0dR DJfDj0sJmzKOXhb0GgjQLxIZF7tjJbbbK3Pgq+iwvkmzjbqRyvZej869BTkb7zWMFtyeQT4VPugS Vx9h0jlgXJVLg5dWdgSdcTngsKv1GHK8wF9AMnlmp80zjqTRsRgJUk22pDx6UFGSxKqpiZ5XO2Tp R08zapo9FxUgPRHVKV7N2xM6gVKfx8YYLhIXPb++5yUOEaMeRLlh12YC7El7OG6TQsrz90+RWu1K 0qra6vn2LBhwTktUR7u/67aSiVYJkTMIX+1jnNR/DT96Qxg+RWtI7gOoBQzqmLK9fsKla3MXSqVk M5xDCtek8MpyDEsMjHYg5BtZLtUI1vut2wquZGummZTgJ0g713hbvLGy/vR9eNmMeNRsuc65EU0N RLZnq1h99ZLDn60KMxd2YPVD3sb7rmCEEmEdglRjnQBeHeOtlYctQ3skGyov7hA9XpNsnFt/Wtk1 zMNg/2PKztmtmXWnap4Mnb6/xZltUEjk6xxQLfMkVpHf+A7VB9+lLWGJRuelmVLjy67LLLlV+dln ORG8lbEX4FjErgpEZQ+8OtFJ9JIuBUf3iDe0dMsVcl+RuHQRLeXrpjHYdu7Jcgd9Wiall2B6rmp/ SH/ovXb+vXdkOukvYjWKt5OZBaEJRRdrrUX6vu1KKpYNqXBiZrhbBdrJdeSNbfJAdecOxyt3rdWm 7BCxpC1sOa2L99hE9/TAi/AblcUR0YZH83MOp/cX6OIr0nsTLOdhuBP9TytOLXcZfC4+b2ZapRvy 1iri3eUlu8VyNDF/Qvw8/aL3tpGDq+LXntmoV/YokftDiUAHF1whWfUwcclK852iKZ1MLXy4YN9k pitwvNNLwnD3O8VXhap3nwRGy10ocegniI7EUDMFcTFjlbuMHjjI3xS5eWS/sNGy89QxPqxuQ23u 9eEcpbPDdTyVB16VrAFm5Wh0Yf3iZ3btFrLc+Pi0Z1/C83rm4PRFYYQhWs1iuoqi9YGo2Na0Tynk nu+RcyryrFR54pIBGm82Zer62N3tvTQTLbghTtRiyXZExdtxXqMMo29TlNILm/7PznSaRrHAvw0w uffi99/QDOdJ6xALH2up3Yy/JohHjm3HjBeERZalHGk5iUfj4794acvF5t38K5nXHDJVY/OkJ5LD rnxs8mtmp5bdNGqzapbJVVo83By6xtyjFOuNR3iw4MbaZ9HVL2VIls0ykhKDy0zvhLSr7AfbsGN6 eVTLJWFY5IbmMT37KxTBuw0vlk2P77/gqJBlco/8Itsy7V3YtCM+fh525+MOd7xKQujSjtt8WM9b 4hVjas3+txyvp+WbFRkkhmbkt9o0d91xvHVIr7VLfNeE/+VXbe3abb5i/W1d4rsn/BPu68CwJxbL Mfh4skeA0bNUeYKGqopFwia78YAblczA5+cQZIXJimPKJXdvTla4mEcVDWBdztAI+0veZqf1ahbb SwZ9yHKaXBwwZPZF1CR/YzJ4QnmK6Qrz266u1JpEuqr6SfdilG/9izIacOU9+gucYJ0iJ3e05YKr VQpdRpwx0LJDkh1ebxBFG4li033fuPV/CluzfrdRbO3pbXOe6I29yNMxyXlH4Npy7v2JIaLq+obb OV++YpRImfxMerBKEIp64uD0W78bsPPJ00eVrFaWLPpCgpobmHVNiZvaA/DoRpckhESGy+pFcuwl BFbrPrlkQ/k088ARgtPBQ9Ysqk9KS86pdB9+zap256IS3vLy5uwiJ5vHvvvmEk+lRz78IBa03FY6 0ABDshrvXp1LPZVOGe/0X/QztnhEZhVOOXF1hX/jdiE/c1SxaitzC/dgT77kio+xBUK7N5GG0rWo yd7sZ24wWWJGgsrHWxVvfZJ7Jm1W0RApGNCfMEx7cxi2PONjeTjOWSfXDZViParLeqE/36SSq3UZ J9rdmRSeaE5aNvGKnKNdz1ectaNvrOh7P0698MSalUXG3jiAzJyo4CEWCtgg0uxJjFTiGeeb7ZKp sqXYlCSPyg6xsoLNAf4SdfqnNUMEzh51OIBs6yXS5AdvNEnByJxBEZelumGZISqb/UIodyLVc6V4 hEhtoZDWXLvGGSfps/sMPR6NpLt2XWV8zX1OpDZT5t88YcAhp49IHaDMB9cwzLtqiIsZrupvZWRc u5ItVw7H9VK6KTLFUVZNlis52b2UIYrMIaqVouWK3L3eJQYL/eRThnXGnAmhhJXGQn9YzogJeiTk UMMwYXwt7SWu1rLQ2p8ykq7PNQS0j1R+VhjywS5csAnef3Ky+9lLC/QVtdEbwU7bx98XYTBtapxh XOBkssQ2DltGqA5OczRYKxnZnL7c8iq/T/hrtu/MX1c/ke8ve2U1vH6UiXUwLZkk3ktFdfd87L37 OrylKWxrW0/9vMVstVSxl+qa57dyh0D73rh4FoeHAxEA2lMmNlb7eIAoNMVGAi9IBgLV7zYBQI9O EAQ8QQDYDNlcEgBi0HxH4pv58+doBynujCkGpKH3rDaUqQ6xDmRrQlIVmofVoaUFxIEUFOO+cFW/ 7+l9P8WVKGhJQNVD0DHcsXmd1hFYR2AdgXUE1hFYR2AdgXUE1hFYR2Adgf8BAv8FAAD//wMAUEsD BBQABgAIAAAAIQA8AjD+gQEAAP4CAAAQAAgBZG9jUHJvcHMvYXBwLnhtbCCiBAEooAABAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAJySQW/bMAyF7wP6HwzdEzltMAyBrKJoWvTQYgGSdmdVpmMh imSIrJHs14+2kcXZeuqN5Ht4+kRJ3R72PmshoYuhELNpLjIINpYubAvxunmc/BAZkgml8TFAIY6A 4lZffVOrFBtI5AAzjghYiJqoWUiJtoa9wSnLgZUqpr0hbtNWxqpyFpbRfuwhkLzO8+8SDgShhHLS /A0UQ+Kipa+GltF2fPi2OTYMrNVd03hnDfEt9YuzKWKsKHs4WPBKjkXFdGuwH8nRUedKjlu1tsbD PQfryngEJc8D9QSmW9rKuIRatbRowVJMGbrfvLZrkb0bhA6nEK1JzgRirM42NH3tG6Skf8W0wxqA UEk2DMO+HHvHtZvrWW/g4tLYBQwgLFwibhx5wJ/VyiT6hHg2Ju4ZBt4BZ93xDWeO+for80n/ZD+7 sMPXZhOXhuC0u8uhWtcmQcnrPunngXritSXfhdzXJmyhPHn+F7qXfhu+s57Np/lNzo84mil5/rj6 DwAAAP//AwBQSwECLQAUAAYACAAAACEAQTeCz3IBAAAEBQAAEwAAAAAAAAAAAAAAAAAAAAAAW0Nv bnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQC1VTAj9QAAAEwCAAALAAAAAAAAAAAAAAAA AKsDAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQCBPpSX9AAAALoCAAAaAAAAAAAAAAAAAAAA ANEGAAB4bC9fcmVscy93b3JrYm9vay54bWwucmVsc1BLAQItABQABgAIAAAAIQAdJXZBpQEAALMC AAAPAAAAAAAAAAAAAAAAAAUJAAB4bC93b3JrYm9vay54bWxQSwECLQAUAAYACAAAACEAaTgM5mYN AAAsTAAAFAAAAAAAAAAAAAAAAADXCgAAeGwvc2hhcmVkU3RyaW5ncy54bWxQSwECLQAUAAYACAAA ACEAcLFAvWoBAADBBQAAIwAAAAAAAAAAAAAAAABvGAAAeGwvd29ya3NoZWV0cy9fcmVscy9zaGVl dDEueG1sLnJlbHNQSwECLQAUAAYACAAAACEA//H7gKcGAABbGgAAEwAAAAAAAAAAAAAAAAAaGgAA eGwvdGhlbWUvdGhlbWUxLnhtbFBLAQItABQABgAIAAAAIQBlJOIujQMAAH0OAAANAAAAAAAAAAAA AAAAAPIgAAB4bC9zdHlsZXMueG1sUEsBAi0AFAAGAAgAAAAhAF2RztoKEQAApWwAABgAAAAAAAAA AAAAAAAAqiQAAHhsL3dvcmtzaGVldHMvc2hlZXQxLnhtbFBLAQItABQABgAIAAAAIQD8pMv0VAEA AGoCAAARAAAAAAAAAAAAAAAAAOo1AABkb2NQcm9wcy9jb3JlLnhtbFBLAQItABQABgAIAAAAIQDs FjgO1wsAALQbAAAnAAAAAAAAAAAAAAAAAHU4AAB4bC9wcmludGVyU2V0dGluZ3MvcHJpbnRlclNl dHRpbmdzMS5iaW5QSwECLQAUAAYACAAAACEAPAIw/oEBAAD+AgAAEAAAAAAAAAAAAAAAAACRRAAA ZG9jUHJvcHMvYXBwLnhtbFBLBQYAAAAADAAMACYDAABIRwAAAAA= --_004_4E1F6AAD24975D4BA5B1680429673943674FFFFCTK5EX14MBXC283r_-- From jricher@mitre.org Wed Mar 13 07:23: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 55EE221F8E0A for ; Wed, 13 Mar 2013 07:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.531 X-Spam-Level: X-Spam-Status: No, score=-6.531 tagged_above=-999 required=5 tests=[AWL=0.067, 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 ajDFNGwgKfdM for ; Wed, 13 Mar 2013 07:23:21 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 66BE021F8E09 for ; Wed, 13 Mar 2013 07:23:21 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C5072229000F; Wed, 13 Mar 2013 10:23:20 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 690BC1F038E; Wed, 13 Mar 2013 10:23: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; Wed, 13 Mar 2013 10:23:20 -0400 Message-ID: <51408B8B.9000800@mitre.org> Date: Wed, 13 Mar 2013 10:22:03 -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: Nat Sakimura References: <1B4C0C9F-4B8E-4B2D-BAF7-665D3EBBE56C@ve7jtb.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050901020602050906010403" X-Originating-IP: [129.83.31.58] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readable names X-BeenThere: oauth@ietf.org X-Mailman-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, 13 Mar 2013 14:23:23 -0000 --------------050901020602050906010403 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit So with what little feedback I've gotten, I'm proposing to add text from the proposed webfinger and OIDC drafts for the hash-based localization of strings, with the following properties: * All localized versions of fields are fully optional on both client and server * If a localized version of a field is included, its bare-value (perhaps internationalized) field MUST be included * All human-readable fields are eligible for this mechanism (including any uri's for user-facing web pages, which can be used to point to language-specific pages) * Clients and servers can decide to use whatever language/script they want to for the bare-value field, and no assumptions can be made on either side about what that is I think that with these constraints, we can add functionality to address Stephen's concerns without getting too complicated or putting too much burden of support. -- Justin On 03/11/2013 06:52 PM, Nat Sakimura wrote: > Similar work is in progress at Webfinger. > > See: http://www.ietf.org/mail-archive/web/webfinger/current/msg00530.html > > Paul is proposing the same syntax as Connect. > > 2013/3/12 Richer, Justin P. > > > It does presume a definition of "claim", which I suppose we could > turn to "metadata field" for DynReg and its extensions to be > appropriately limiting. But we also need a good definition of what > a language-tag-less field means, and whether or not it's required > if the other fields are present or not (which is something that > Connect is trying to fix at the moment, as I recall from last week). > > So it turns into about a paragraph worth of text. Is that worth > it? I'm not entirely convinced that it is, but I'm interested to > hear what others think, particularly those who *aren't* tied into > the OpenID Connect protocol so much. (I don't want to pick a > solution just because it's familiar, if we need a solution at all.) > > -- Justin > > On Mar 11, 2013, at 6:35 PM, Brian Campbell > > > wrote: > >> A fair question but what would need to be pulled in is really >> probably only a couple sentences (and reference) from >> http://openid.net/specs/openid-connect-messages-1_0-16.html#ClaimsLanguagesAndScripts >> (note the reference to 2.1.1.1.3 inside >> http://openid.net/specs/openid-connect-registration-1_0-15.html >> is broken) >> >> >> On Mon, Mar 11, 2013 at 6:26 PM, Richer, Justin P. >> > wrote: >> >> My concern with this is that OIDC can get away with defining >> this multi-language structure because it defines the >> mechanism once (in Messages) and applies it to all >> user-readable strings throughout the whole application >> protocol, of which there are several. Do we really want to >> pull in that whole structure and mechanism for one field in >> client registration? I really don't think it should be >> something that's defined completely inside of DynReg for a >> corner case for a single field, but I also doubt we want to >> normatively point to OIDC Messages for this solution either. >> >> There are also other ways to do this: Webfinger [1] for >> instance uses JSON structures to give language tags to field >> values, and has a default mechanism: >> >> { "en_us": "my client", $B!D(B } >> >> The fundamental question is this: should a client be able to >> register multiple names (in different locales) with a single >> client_id, or should it get a different client_id for each >> display language set? >> >> -- Justin >> >> [1] http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-11 >> >> On Mar 11, 2013, at 5:54 PM, John Bradley > > >> wrote: >> >>> That is what I was thinking. It would be up to the AS to >>> determine what language and script to present based on the >>> user preference. >>> >>> While a large number of clients will be native and might be >>> able to customize themselves for a single user during >>> registration , we don't want to forget the web server >>> clients that are multi user. >>> >>> On 2013-03-11, at 10:49 PM, Brian Campbell >>> >> > wrote: >>> >>>> FWIW, the closely related OpenID Connect client >>>> registration draft does have some support for doing this, >>>> which could maybe be borrowed. See client_name in $B!x(B2 at >>>> http://openid.net/specs/openid-connect-registration-1_0-15.html#client-metadata >>>> and the examples. >>>> >>>> "client_name": "My Example", >>>> "client_name#ja-Jpan-JP":"$B%/%i%$%"%s%HL>(B", >>>> >>>> >>>> >>>> On Mon, Mar 11, 2013 at 5:15 PM, Richer, Justin P. >>>> > wrote: >>>> >>>> It was brought up at the in-person meeting today that >>>> we'll want to consider issues around >>>> internationalization and localization of human-readable >>>> fields like client_name in the client registration. >>>> Which is to say: if a client supports ten languages and >>>> wants to present itself in ten languages, should it >>>> have to register itself ten times with an AS? >>>> >>>> At the moment, I'm of the opinion a client with ten >>>> languages could register itself ten times, or do >>>> something with the context in which it runs to >>>> determine which human-facing language to use. Keep in >>>> mind that in some cases (such as native clients), >>>> you'll be dynamically registering a client for each >>>> user, in effect. In other words, I personally think >>>> that this is a rathole that will cause more harm than good. >>>> >>>> -- Justin >>>> _______________________________________________ >>>> OAuth mailing 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 > > > > > -- > Nat Sakimura (=nat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en --------------050901020602050906010403 Content-Type: text/html; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit So with what little feedback I've gotten, I'm proposing to add text from the proposed webfinger and OIDC drafts for the hash-based localization of strings, with the following properties:

* All localized versions of fields are fully optional on both client and server
* If a localized version of a field is included, its bare-value (perhaps internationalized) field MUST be included
* All human-readable fields are eligible for this mechanism (including any uri's for user-facing web pages, which can be used to point to language-specific pages)
* Clients and servers can decide to use whatever language/script they want to for the bare-value field, and no assumptions can be made on either side about what that is

I think that with these constraints, we can add functionality to address Stephen's concerns without getting too complicated or putting too much burden of support.

 -- Justin

On 03/11/2013 06:52 PM, Nat Sakimura wrote:
Similar work is in progress at Webfinger. 


Paul is proposing the same syntax as Connect. 

2013/3/12 Richer, Justin P. <jricher@mitre.org>
It does presume a definition of "claim", which I suppose we could turn to "metadata field" for DynReg and its extensions to be appropriately limiting. But we also need a good definition of what a language-tag-less field means, and whether or not it's required if the other fields are present or not (which is something that Connect is trying to fix at the moment, as I recall from last week). 

So it turns into about a paragraph worth of text. Is that worth it? I'm not entirely convinced that it is, but I'm interested to hear what others think, particularly those who *aren't* tied into the OpenID Connect protocol so much. (I don't want to pick a solution just because it's familiar, if we need a solution at all.)

 -- Justin

On Mar 11, 2013, at 6:35 PM, Brian Campbell <bcampbell@pingidentity.com>
 wrote:

A fair question but what would need to be pulled in is really probably only a couple sentences (and reference) from http://openid.net/specs/openid-connect-messages-1_0-16.html#ClaimsLanguagesAndScripts (note the reference to 2.1.1.1.3 inside http://openid.net/specs/openid-connect-registration-1_0-15.html is broken)


On Mon, Mar 11, 2013 at 6:26 PM, Richer, Justin P. <jricher@mitre.org> wrote:
My concern with this is that OIDC can get away with defining this multi-language structure because it defines the mechanism once (in Messages) and applies it to all user-readable strings throughout the whole application protocol, of which there are several. Do we really want to pull in that whole structure and mechanism for one field in client registration? I really don't think it should be something that's defined completely inside of DynReg for a corner case for a single field, but I also doubt we want to normatively point to OIDC Messages for this solution either.

There are also other ways to do this: Webfinger [1] for instance uses JSON structures to give language tags to field values, and has a default mechanism:

   { "en_us": "my client", $B!D(B }

The fundamental question is  this: should a client be able to register multiple names (in different locales) with a single client_id, or should it get a different client_id for each display language set?

 -- Justin


On Mar 11, 2013, at 5:54 PM, John Bradley <ve7jtb@ve7jtb.com>
 wrote:

That is what I was thinking.   It would be up to the AS to determine what language and script to present based on the user preference.

While a large number of clients will be native and might be able to customize themselves for a single user during registration , we don't want to forget the web server clients that are multi user.

On 2013-03-11, at 10:49 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:

FWIW, the closely related OpenID Connect client registration draft does have some support for doing this, which could maybe be borrowed. See client_name in $B!x(B2 at http://openid.net/specs/openid-connect-registration-1_0-15.html#client-metadata and the examples.
 
   "client_name": "My Example",
   "client_name#ja-Jpan-JP":"$B%/%i%$%"%s%HL>(B",



On Mon, Mar 11, 2013 at 5:15 PM, Richer, Justin P. <jricher@mitre.org> wrote:
It was brought up at the in-person meeting today that we'll want to consider issues around internationalization and localization of human-readable fields like client_name in the client registration. Which is to say: if a client supports ten languages and wants to present itself in ten languages, should it have to register itself ten times with an AS?

At the moment, I'm of the opinion a client with ten languages could register itself ten times, or do something with the context in which it runs to determine which human-facing language to use. Keep in mind that in some cases (such as native clients), you'll be dynamically registering a client for each user, in effect. In other words, I personally think that this is a rathole that will cause more harm than good.

 -- Justin
_______________________________________________
OAuth mailing 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




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

--------------050901020602050906010403-- From bcampbell@pingidentity.com Wed Mar 13 11: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 46CEA21F8EA8 for ; Wed, 13 Mar 2013 11:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.769 X-Spam-Level: X-Spam-Status: No, score=-3.769 tagged_above=-999 required=5 tests=[AWL=-1.996, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 i6qeliNWAh+P for ; Wed, 13 Mar 2013 11:18:44 -0700 (PDT) Received: from na3sys009aog131.obsmtp.com (na3sys009aog131.obsmtp.com [74.125.149.247]) by ietfa.amsl.com (Postfix) with ESMTP id C3B5C21F8E8B for ; Wed, 13 Mar 2013 11:18:43 -0700 (PDT) Received: from mail-ob0-f199.google.com ([209.85.214.199]) (using TLSv1) by na3sys009aob131.postini.com ([74.125.148.12]) with SMTP ID DSNKUUDDAU3jjsZVCfZEyEcXZt3F862BXERF@postini.com; Wed, 13 Mar 2013 11:18:43 PDT Received: by mail-ob0-f199.google.com with SMTP id wd20so6889821obb.6 for ; Wed, 13 Mar 2013 11:18:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=v8Wi2rwQ3FPSba7B47q519CpyogZn1kYTi/5NQm3y9Q=; b=GOyuyw5XrSftuufeIVatlT/KGnfaHFGkM+S+LfnPnJiN348tcngY1DkautW8JCY4Ay KgdxJeQAgbMAYzUftU1RVHNKtlmxNJvJHyWMCjvBWc1ZUH4ndjCdKuHzysfyLPQzmEwX aH75YU74o3p9hFduxnFzBkk7mX79xoGFH8v/nLnHJUIUPywd9ZJNfGNYWrMK2IgaWOqR 5iCCUsn2plyLqk9n7kT2cUkws56ZLRNQshGeoNmmC3PsbGYWWhno1VmA3sPerBkqpHUo WpVjpBrxJGDiQRSVFDV0CF2zwMxolyK9Kiymc+kSl74ZD5gvbkoKUjulhG3nLnfvPJk0 /Egw== X-Received: by 10.50.151.179 with SMTP id ur19mr16899797igb.79.1363198719317; Wed, 13 Mar 2013 11:18:39 -0700 (PDT) X-Received: by 10.50.151.179 with SMTP id ur19mr16899781igb.79.1363198719084; Wed, 13 Mar 2013 11:18:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.32.106 with HTTP; Wed, 13 Mar 2013 11:18:08 -0700 (PDT) In-Reply-To: <51408B8B.9000800@mitre.org> References: <1B4C0C9F-4B8E-4B2D-BAF7-665D3EBBE56C@ve7jtb.com> <51408B8B.9000800@mitre.org> From: Brian Campbell Date: Wed, 13 Mar 2013 14:18:08 -0400 Message-ID: To: Justin Richer Content-Type: multipart/alternative; boundary=e89a8f3b9ff568ddb404d7d26fb6 X-Gm-Message-State: ALoCoQmZJgq1KLQY3TU78JmTvRqGV3zXor7bLiRxMFnvYbz+5pQrOE6SyATPfHInHaU7iKffyJ2wXK4lCw0QnOTK9XqmbDeMQ/dLRlLRfsQKu+VdrM0p4SXXo3t6Hd0ikyQepDvxcYDC Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readable names X-BeenThere: oauth@ietf.org X-Mailman-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, 13 Mar 2013 18:18:48 -0000 --e89a8f3b9ff568ddb404d7d26fb6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Seems reasonable to me. On Wed, Mar 13, 2013 at 10:22 AM, Justin Richer wrote: > So with what little feedback I've gotten, I'm proposing to add text from > the proposed webfinger and OIDC drafts for the hash-based localization of > strings, with the following properties: > > * All localized versions of fields are fully optional on both client and > server > * If a localized version of a field is included, its bare-value (perhaps > internationalized) field MUST be included > * All human-readable fields are eligible for this mechanism (including an= y > uri's for user-facing web pages, which can be used to point to > language-specific pages) > * Clients and servers can decide to use whatever language/script they wan= t > to for the bare-value field, and no assumptions can be made on either sid= e > about what that is > > I think that with these constraints, we can add functionality to address > Stephen's concerns without getting too complicated or putting too much > burden of support. > > -- Justin > > > On 03/11/2013 06:52 PM, Nat Sakimura wrote: > > Similar work is in progress at Webfinger. > > See: http://www.ietf.org/mail-archive/web/webfinger/current/msg00530.htm= l > > Paul is proposing the same syntax as Connect. > > 2013/3/12 Richer, Justin P. > >> It does presume a definition of "claim", which I suppose we could turn >> to "metadata field" for DynReg and its extensions to be appropriately >> limiting. But we also need a good definition of what a language-tag-less >> field means, and whether or not it's required if the other fields are >> present or not (which is something that Connect is trying to fix at the >> moment, as I recall from last week). >> >> So it turns into about a paragraph worth of text. Is that worth it? I'm >> not entirely convinced that it is, but I'm interested to hear what other= s >> think, particularly those who *aren't* tied into the OpenID Connect >> protocol so much. (I don't want to pick a solution just because it's >> familiar, if we need a solution at all.) >> >> -- Justin >> >> On Mar 11, 2013, at 6:35 PM, Brian Campbell >> wrote: >> >> A fair question but what would need to be pulled in is really probably >> only a couple sentences (and reference) from >> http://openid.net/specs/openid-connect-messages-1_0-16.html#ClaimsLangua= gesAndScripts(note the reference to 2.1.1.1.3 inside >> http://openid.net/specs/openid-connect-registration-1_0-15.html is >> broken) >> >> >> On Mon, Mar 11, 2013 at 6:26 PM, Richer, Justin P. wr= ote: >> >>> My concern with this is that OIDC can get away with defining this >>> multi-language structure because it defines the mechanism once (in >>> Messages) and applies it to all user-readable strings throughout the wh= ole >>> application protocol, of which there are several. Do we really want to = pull >>> in that whole structure and mechanism for one field in client registrat= ion? >>> I really don't think it should be something that's defined completely >>> inside of DynReg for a corner case for a single field, but I also doubt= we >>> want to normatively point to OIDC Messages for this solution either. >>> >>> There are also other ways to do this: Webfinger [1] for instance uses >>> JSON structures to give language tags to field values, and has a defaul= t >>> mechanism: >>> >>> { "en_us": "my client", =E2=80=A6 } >>> >>> The fundamental question is this: should a client be able to register >>> multiple names (in different locales) with a single client_id, or shoul= d it >>> get a different client_id for each display language set? >>> >>> -- Justin >>> >>> [1] http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-11 >>> >>> On Mar 11, 2013, at 5:54 PM, John Bradley >>> wrote: >>> >>> That is what I was thinking. It would be up to the AS to determine >>> what language and script to present based on the user preference. >>> >>> While a large number of clients will be native and might be able to >>> customize themselves for a single user during registration , we don't w= ant >>> to forget the web server clients that are multi user. >>> >>> On 2013-03-11, at 10:49 PM, Brian Campbell >>> wrote: >>> >>> FWIW, the closely related OpenID Connect client registration draft >>> does have some support for doing this, which could maybe be borrowed. S= ee >>> client_name in =C2=A72 at >>> http://openid.net/specs/openid-connect-registration-1_0-15.html#client-= metadataand the examples. >>> >>> >>> "client_name": "My Example", >>> "client_name#ja-Jpan-JP":"=E3=82=AF=E3=83=A9=E3=82=A4=E3=82=A2=E3=83= =B3=E3=83=88=E5=90=8D", >>> >>> >>> >>> >>> On Mon, Mar 11, 2013 at 5:15 PM, Richer, Justin P. w= rote: >>> >>>> It was brought up at the in-person meeting today that we'll want to >>>> consider issues around internationalization and localization of >>>> human-readable fields like client_name in the client registration. Whi= ch is >>>> to say: if a client supports ten languages and wants to present itself= in >>>> ten languages, should it have to register itself ten times with an AS? >>>> >>>> At the moment, I'm of the opinion a client with ten languages could >>>> register itself ten times, or do something with the context in which i= t >>>> runs to determine which human-facing language to use. Keep in mind tha= t in >>>> some cases (such as native clients), you'll be dynamically registering= a >>>> client for each user, in effect. In other words, I personally think th= at >>>> this is a rathole that will cause more harm than good. >>>> >>>> -- Justin >>>> _______________________________________________ >>>> OAuth mailing 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 >> >> > > > -- > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > > --e89a8f3b9ff568ddb404d7d26fb6 Content-Type: text/html; charset=ISO-2022-JP Content-Transfer-Encoding: base64 PGRpdiBkaXI9Imx0ciI+U2VlbXMgcmVhc29uYWJsZSB0byBtZS48YnI+PC9kaXY+PGRpdiBjbGFz cz0iZ21haWxfZXh0cmEiPjxicj48YnI+PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIFdlZCwg TWFyIDEzLCAyMDEzIGF0IDEwOjIyIEFNLCBKdXN0aW4gUmljaGVyIDxzcGFuIGRpcj0ibHRyIj4m bHQ7PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0cmUub3JnIiB0YXJnZXQ9Il9ibGFuayI+anJp Y2hlckBtaXRyZS5vcmc8L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJyPg0KDQo8YmxvY2txdW90ZSBj bGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDox cHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCiAgDQogICAgDQogIA0KICA8ZGl2IGJn Y29sb3I9IiNGRkZGRkYiIHRleHQ9IiMwMDAwMDAiPg0KICAgIFNvIHdpdGggd2hhdCBsaXR0bGUg ZmVlZGJhY2sgSSYjMzk7dmUgZ290dGVuLCBJJiMzOTttIHByb3Bvc2luZyB0byBhZGQgdGV4dA0K ICAgIGZyb20gdGhlIHByb3Bvc2VkIHdlYmZpbmdlciBhbmQgT0lEQyBkcmFmdHMgZm9yIHRoZSBo YXNoLWJhc2VkDQogICAgbG9jYWxpemF0aW9uIG9mIHN0cmluZ3MsIHdpdGggdGhlIGZvbGxvd2lu ZyBwcm9wZXJ0aWVzOjxicj4NCiAgICA8YnI+DQogICAgKiBBbGwgbG9jYWxpemVkIHZlcnNpb25z IG9mIGZpZWxkcyBhcmUgZnVsbHkgb3B0aW9uYWwgb24gYm90aCBjbGllbnQNCiAgICBhbmQgc2Vy dmVyPGJyPg0KICAgICogSWYgYSBsb2NhbGl6ZWQgdmVyc2lvbiBvZiBhIGZpZWxkIGlzIGluY2x1 ZGVkLCBpdHMgYmFyZS12YWx1ZQ0KICAgIChwZXJoYXBzIGludGVybmF0aW9uYWxpemVkKSBmaWVs ZCBNVVNUIGJlIGluY2x1ZGVkPGJyPg0KICAgICogQWxsIGh1bWFuLXJlYWRhYmxlIGZpZWxkcyBh cmUgZWxpZ2libGUgZm9yIHRoaXMgbWVjaGFuaXNtDQogICAgKGluY2x1ZGluZyBhbnkgdXJpJiMz OTtzIGZvciB1c2VyLWZhY2luZyB3ZWIgcGFnZXMsIHdoaWNoIGNhbiBiZSB1c2VkIHRvDQogICAg cG9pbnQgdG8gbGFuZ3VhZ2Utc3BlY2lmaWMgcGFnZXMpPGJyPg0KICAgICogQ2xpZW50cyBhbmQg c2VydmVycyBjYW4gZGVjaWRlIHRvIHVzZSB3aGF0ZXZlciBsYW5ndWFnZS9zY3JpcHQNCiAgICB0 aGV5IHdhbnQgdG8gZm9yIHRoZSBiYXJlLXZhbHVlIGZpZWxkLCBhbmQgbm8gYXNzdW1wdGlvbnMg Y2FuIGJlDQogICAgbWFkZSBvbiBlaXRoZXIgc2lkZSBhYm91dCB3aGF0IHRoYXQgaXM8YnI+DQog ICAgPGJyPg0KICAgIEkgdGhpbmsgdGhhdCB3aXRoIHRoZXNlIGNvbnN0cmFpbnRzLCB3ZSBjYW4g YWRkIGZ1bmN0aW9uYWxpdHkgdG8NCiAgICBhZGRyZXNzIFN0ZXBoZW4mIzM5O3MgY29uY2VybnMg d2l0aG91dCBnZXR0aW5nIHRvbyBjb21wbGljYXRlZCBvcg0KICAgIHB1dHRpbmcgdG9vIG11Y2gg YnVyZGVuIG9mIHN1cHBvcnQuPHNwYW4gY2xhc3M9IkhPRW5aYiI+PGZvbnQgY29sb3I9IiM4ODg4 ODgiPjxicj4NCiAgICA8YnI+DQogICAgJm5ic3A7LS0gSnVzdGluPC9mb250Pjwvc3Bhbj48ZGl2 PjxkaXYgY2xhc3M9Img1Ij48YnI+DQogICAgPGJyPg0KICAgIDxkaXY+T24gMDMvMTEvMjAxMyAw Njo1MiBQTSwgTmF0IFNha2ltdXJhDQogICAgICB3cm90ZTo8YnI+DQogICAgPC9kaXY+DQogICAg PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQogICAgICANCiAgICAgIFNpbWlsYXIgd29yayBpcyBp biBwcm9ncmVzcyBhdCBXZWJmaW5nZXIuJm5ic3A7DQogICAgICA8ZGl2Pjxicj4NCiAgICAgIDwv ZGl2Pg0KICAgICAgPGRpdj5TZWU6Jm5ic3A7PGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9t YWlsLWFyY2hpdmUvd2ViL3dlYmZpbmdlci9jdXJyZW50L21zZzAwNTMwLmh0bWwiIHRhcmdldD0i X2JsYW5rIj5odHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvd2ViZmluZ2VyL2N1 cnJlbnQvbXNnMDA1MzAuaHRtbDwvYT48L2Rpdj4NCiAgICAgIDxkaXY+PGJyPg0KICAgICAgPC9k aXY+DQogICAgICA8ZGl2PlBhdWwgaXMgcHJvcG9zaW5nIHRoZSBzYW1lIHN5bnRheCBhcyBDb25u ZWN0LiZuYnNwOzxicj4NCiAgICAgICAgPGJyPg0KICAgICAgICA8ZGl2IGNsYXNzPSJnbWFpbF9x dW90ZSI+MjAxMy8zLzEyIFJpY2hlciwgSnVzdGluIFAuIDxzcGFuIGRpcj0ibHRyIj4mbHQ7PGEg aHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0cmUub3JnIiB0YXJnZXQ9Il9ibGFuayI+anJpY2hlckBt aXRyZS5vcmc8L2E+Jmd0Ozwvc3Bhbj48YnI+DQogICAgICAgICAgPGJsb2NrcXVvdGUgY2xhc3M9 ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNj Y2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQogICAgICAgICAgICA8ZGl2IHN0eWxlPSJ3b3Jk LXdyYXA6YnJlYWstd29yZCI+DQogICAgICAgICAgICAgIEl0IGRvZXMgcHJlc3VtZSBhIGRlZmlu aXRpb24gb2YgJnF1b3Q7Y2xhaW0mcXVvdDssIHdoaWNoIEkgc3VwcG9zZQ0KICAgICAgICAgICAg ICB3ZSBjb3VsZCB0dXJuIHRvICZxdW90O21ldGFkYXRhIGZpZWxkJnF1b3Q7IGZvciBEeW5SZWcg YW5kIGl0cw0KICAgICAgICAgICAgICBleHRlbnNpb25zIHRvIGJlIGFwcHJvcHJpYXRlbHkgbGlt aXRpbmcuIEJ1dCB3ZSBhbHNvIG5lZWQNCiAgICAgICAgICAgICAgYSBnb29kIGRlZmluaXRpb24g b2Ygd2hhdCBhIGxhbmd1YWdlLXRhZy1sZXNzIGZpZWxkIG1lYW5zLA0KICAgICAgICAgICAgICBh bmQgd2hldGhlciBvciBub3QgaXQmIzM5O3MgcmVxdWlyZWQgaWYgdGhlIG90aGVyIGZpZWxkcyBh cmUNCiAgICAgICAgICAgICAgcHJlc2VudCBvciBub3QgKHdoaWNoIGlzIHNvbWV0aGluZyB0aGF0 IENvbm5lY3QgaXMgdHJ5aW5nDQogICAgICAgICAgICAgIHRvIGZpeCBhdCB0aGUgbW9tZW50LCBh cyBJIHJlY2FsbCBmcm9tIGxhc3Qgd2VlaykuJm5ic3A7DQogICAgICAgICAgICAgIDxkaXY+PGJy Pg0KICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgPGRpdj5TbyBpdCB0dXJucyBp bnRvIGFib3V0IGEgcGFyYWdyYXBoIHdvcnRoIG9mIHRleHQuIElzDQogICAgICAgICAgICAgICAg dGhhdCB3b3J0aCBpdD8gSSYjMzk7bSBub3QgZW50aXJlbHkgY29udmluY2VkIHRoYXQgaXQgaXMs DQogICAgICAgICAgICAgICAgYnV0IEkmIzM5O20gaW50ZXJlc3RlZCB0byBoZWFyIHdoYXQgb3Ro ZXJzIHRoaW5rLA0KICAgICAgICAgICAgICAgIHBhcnRpY3VsYXJseSB0aG9zZSB3aG8gKmFyZW4m IzM5O3QqIHRpZWQgaW50byB0aGUgT3BlbklEDQogICAgICAgICAgICAgICAgQ29ubmVjdCBwcm90 b2NvbCBzbyBtdWNoLiAoSSBkb24mIzM5O3Qgd2FudCB0byBwaWNrIGENCiAgICAgICAgICAgICAg ICBzb2x1dGlvbiBqdXN0IGJlY2F1c2UgaXQmIzM5O3MgZmFtaWxpYXIsIGlmIHdlIG5lZWQgYQ0K ICAgICAgICAgICAgICAgIHNvbHV0aW9uIGF0IGFsbC4pPGJyPg0KICAgICAgICAgICAgICAgIDxk aXY+PGJyPg0KICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgIDxkaXY+Jm5i c3A7LS0gSnVzdGluPC9kaXY+DQogICAgICAgICAgICAgICAgPGRpdj48YnI+DQogICAgICAgICAg ICAgICAgICA8ZGl2Pg0KICAgICAgICAgICAgICAgICAgICA8ZGl2Pk9uIE1hciAxMSwgMjAxMywg YXQgNjozNSBQTSwgQnJpYW4gQ2FtcGJlbGwNCiAgICAgICAgICAgICAgICAgICAgICAmbHQ7PGEg aHJlZj0ibWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tIiB0YXJnZXQ9Il9ibGFuayI+ YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208L2E+Jmd0OzwvZGl2Pg0KICAgICAgICAgICAgICAg ICAgICA8ZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgIDxkaXY+DQogICAgICAgICAgICAgICAg ICAgICAgICA8ZGl2PiZuYnNwO3dyb3RlOjwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAg PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQog ICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXYgZGlyPSJsdHIiPkEgZmFpciBxdWVzdGlvbiBi dXQgd2hhdCB3b3VsZA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIG5lZWQgdG8gYmUgcHVs bGVkIGluIGlzIHJlYWxseSBwcm9iYWJseSBvbmx5DQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgYSBjb3VwbGUgc2VudGVuY2VzIChhbmQgcmVmZXJlbmNlKSBmcm9tDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgPGEgaHJlZj0iaHR0cDovL29wZW5pZC5uZXQvc3BlY3Mvb3BlbmlkLWNv bm5lY3QtbWVzc2FnZXMtMV8wLTE2Lmh0bWwjQ2xhaW1zTGFuZ3VhZ2VzQW5kU2NyaXB0cyIgdGFy Z2V0PSJfYmxhbmsiPg0KaHR0cDovL29wZW5pZC5uZXQvc3BlY3Mvb3BlbmlkLWNvbm5lY3QtbWVz c2FnZXMtMV8wLTE2Lmh0bWwjQ2xhaW1zTGFuZ3VhZ2VzQW5kU2NyaXB0czwvYT4NCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAobm90ZSB0aGUgcmVmZXJlbmNlIHRvIDIuMS4xLjEuMyBpbnNp ZGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICA8YSBocmVmPSJodHRwOi8vb3BlbmlkLm5l dC9zcGVjcy9vcGVuaWQtY29ubmVjdC1yZWdpc3RyYXRpb24tMV8wLTE1Lmh0bWwiIHRhcmdldD0i X2JsYW5rIj5odHRwOi8vb3BlbmlkLm5ldC9zcGVjcy9vcGVuaWQtY29ubmVjdC1yZWdpc3RyYXRp b24tMV8wLTE1Lmh0bWw8L2E+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgaXMgYnJva2Vu KTxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAg ICAgICAgICAgIDxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48YnI+DQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXYgY2xhc3M9 ImdtYWlsX3F1b3RlIj5PbiBNb24sIE1hciAxMSwNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIDIwMTMgYXQgNjoyNiBQTSwgUmljaGVyLCBKdXN0aW4gUC4gPHNwYW4gZGlyPSJsdHIiPg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpyaWNo ZXJAbWl0cmUub3JnIiB0YXJnZXQ9Il9ibGFuayI+anJpY2hlckBtaXRyZS5vcmc8L2E+Jmd0Ozwv c3Bhbj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHdyb3RlOjxicj4NCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIDxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5 bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmct bGVmdDoxZXgiPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2IHN0eWxlPSJ3 b3JkLXdyYXA6YnJlYWstd29yZCI+TXkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBjb25jZXJuIHdpdGggdGhpcyBpcyB0aGF0IE9JREMgY2FuIGdldA0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIGF3YXkgd2l0aCBkZWZpbmluZyB0aGlzIG11bHRpLWxhbmd1YWdl DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3RydWN0dXJlIGJlY2F1c2UgaXQg ZGVmaW5lcyB0aGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBtZWNoYW5pc20g b25jZSAoaW4gTWVzc2FnZXMpIGFuZA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IGFwcGxpZXMgaXQgdG8gYWxsIHVzZXItcmVhZGFibGUNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBzdHJpbmdzIHRocm91Z2hvdXQgdGhlIHdob2xlDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgYXBwbGljYXRpb24gcHJvdG9jb2wsIG9mIHdoaWNoIHRoZXJlDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYXJlIHNldmVyYWwuIERvIHdlIHJlYWxs eSB3YW50IHRvIHB1bGwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpbiB0aGF0 IHdob2xlIHN0cnVjdHVyZSBhbmQgbWVjaGFuaXNtDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgZm9yIG9uZSBmaWVsZCBpbiBjbGllbnQgcmVnaXN0cmF0aW9uPw0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIEkgcmVhbGx5IGRvbiYjMzk7dCB0aGluayBpdCBzaG91 bGQgYmUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzb21ldGhpbmcgdGhhdCYj Mzk7cyBkZWZpbmVkIGNvbXBsZXRlbHkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBpbnNpZGUgb2YgRHluUmVnIGZvciBhIGNvcm5lciBjYXNlIGZvcg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIGEgc2luZ2xlIGZpZWxkLCBidXQgSSBhbHNvIGRvdWJ0IHdlDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgd2FudCB0byBub3JtYXRpdmVseSBwb2lu dCB0byBPSURDDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTWVzc2FnZXMgZm9y IHRoaXMgc29sdXRpb24gZWl0aGVyLg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IDxkaXY+PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+VGhlcmUgYXJlIGFsc28gb3RoZXIg d2F5cyB0byBkbw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhpczogV2Vi ZmluZ2VyIFsxXSBmb3IgaW5zdGFuY2UNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHVzZXMgSlNPTiBzdHJ1Y3R1cmVzIHRvIGdpdmUNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIGxhbmd1YWdlIHRhZ3MgdG8gZmllbGQgdmFsdWVzLCBhbmQNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGhhcyBhIGRlZmF1bHQgbWVjaGFuaXNtOjwvZGl2 Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+PGJyPg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIDxkaXY+Jm5ic3A7ICZuYnNwO3sgJnF1b3Q7ZW5fdXMmcXVvdDs6ICZxdW90O215 IGNsaWVudCZxdW90OywgJmhlbGxpcDsgfTwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIDxkaXY+PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwv ZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+VGhlIGZ1bmRhbWVu dGFsIHF1ZXN0aW9uIGlzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmbmJz cDt0aGlzOiBzaG91bGQgYSBjbGllbnQgYmUgYWJsZSB0bw0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgcmVnaXN0ZXIgbXVsdGlwbGUgbmFtZXMgKGluDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBkaWZmZXJlbnQgbG9jYWxlcykgd2l0aCBhIHNpbmdsZQ0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY2xpZW50X2lkLCBvciBzaG91bGQg aXQgZ2V0IGENCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGRpZmZlcmVudCBj bGllbnRfaWQgZm9yIGVhY2ggZGlzcGxheQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgbGFuZ3VhZ2Ugc2V0Pzxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIDxkaXY+PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+ DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2PiZuYnNwOy0tIEp1c3Rp bjwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj48YnI+DQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIDxkaXY+WzFdJm5ic3A7PGEgaHJlZj0iaHR0cDovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1hcHBzYXdnLXdlYmZpbmdlci0xMSIgdGFyZ2V0PSJf YmxhbmsiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYXBwc2F3Zy13ZWJm aW5nZXItMTE8L2E+PC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8 ZGl2Pjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj4NCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2Pk9uIE1hciAxMSwgMjAx MywgYXQgNTo1NA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUE0s IEpvaG4gQnJhZGxleSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tIiB0YXJn ZXQ9Il9ibGFuayI+dmU3anRiQHZlN2p0Yi5jb208L2E+Jmd0OzwvZGl2Pg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+Jm5ic3A7d3JvdGU6PC9kaXY+DQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj4NCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+PGJyPg0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2IHN0eWxlPSJ3b3Jk LXdyYXA6YnJlYWstd29yZCI+VGhhdA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgaXMgd2hhdCBJIHdhcyB0aGlua2luZy4NCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZuYnNwOyBJdCB3b3VsZCBiZSB1cCB0byB0 aGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEFTIHRv IGRldGVybWluZSB3aGF0DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBsYW5ndWFnZSBhbmQgc2NyaXB0IHRvDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBwcmVzZW50IGJhc2VkIG9uIHRoZQ0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdXNlciBwcmVmZXJlbmNlLg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj48YnI+DQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+V2hpbGUg YSBsYXJnZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBudW1iZXIgb2YgY2xpZW50cyB3aWxsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIGJlIG5hdGl2ZSBhbmQgbWlnaHQgYmUNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYWJsZSB0byBjdXN0b21pemUNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhlbXNlbHZl cyBmb3IgYQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBzaW5nbGUgdXNlciBkdXJpbmcNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgcmVnaXN0cmF0aW9uICwgd2UNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgZG9uJiMzOTt0IHdhbnQgdG8gZm9yZ2V0DQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRoZSB3ZWIgc2Vy dmVyIGNsaWVudHMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgdGhhdCBhcmUgbXVsdGkgdXNlci48L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+PGJyPg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2Pg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+T24gMjAxMy0wMy0xMSwNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGF0IDEwOjQ5 IFBNLCBCcmlhbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgQ2FtcGJlbGwgJmx0OzxhIGhyZWY9Im1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50 aXR5LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPC9hPiZn dDsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHdyb3RlOjwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXYgZGlyPSJsdHIiPkZXSVcsDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRo ZSBjbG9zZWx5DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHJlbGF0ZWQgT3BlbklEDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIENvbm5lY3QgY2xpZW50DQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJlZ2lzdHJhdGlvbg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBkcmFm dCBkb2VzIGhhdmUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgc29tZSBzdXBwb3J0IGZvcg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBkb2luZyB0aGlzLA0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB3aGljaCBjb3VsZA0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBtYXli ZSBiZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBib3Jyb3dlZC4gU2VlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIGNsaWVudF9uYW1lIGluDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIBskQiF4GyhCMiBhdA0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8YSBocmVmPSJo dHRwOi8vb3BlbmlkLm5ldC9zcGVjcy9vcGVuaWQtY29ubmVjdC1yZWdpc3RyYXRpb24tMV8wLTE1 Lmh0bWwjY2xpZW50LW1ldGFkYXRhIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwOi8vb3BlbmlkLm5l dC9zcGVjcy9vcGVuaWQtY29ubmVjdC1yZWdpc3RyYXRpb24tMV8wLTE1Lmh0bWwjY2xpZW50LW1l dGFkYXRhPC9hPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBhbmQgdGhlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIGV4YW1wbGVzLjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJm5ic3A7PGJyPg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8cHJlPiAgICZxdW90 O2NsaWVudF9uYW1lJnF1b3Q7OiAmcXVvdDtNeSBFeGFtcGxlJnF1b3Q7LA0KICAgJnF1b3Q7Y2xp ZW50X25hbWUjamEtSnBhbi1KUCZxdW90OzomcXVvdDsbJEIlLyVpJSQlIiVzJUhMPhsoQiZxdW90 Oyw8L3ByZT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICA8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJyPg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8YnI+DQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXYg Y2xhc3M9ImdtYWlsX3F1b3RlIj5Pbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIE1vbiwgTWFyIDExLA0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDIwMTMgYXQgNToxNQ0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFBN LCBSaWNoZXIsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgSnVzdGluIFAuIDxzcGFuIGRpcj0ibHRyIj4NCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmbHQ7PGEgaHJlZj0ibWFp bHRvOmpyaWNoZXJAbWl0cmUub3JnIiB0YXJnZXQ9Il9ibGFuayI+anJpY2hlckBtaXRyZS5vcmc8 L2E+Jmd0Ozwvc3Bhbj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB3cm90ZTo8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1 b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7 cGFkZGluZy1sZWZ0OjFleCI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgSXQgd2FzIGJyb3VnaHQNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1cCBhdCB0aGUNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpbi1wZXJz b24NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBtZWV0aW5nIHRvZGF5DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgdGhhdCB3ZSYjMzk7bGwNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB3YW50IHRvDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc2lkZXIN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBpc3N1ZXMgYXJvdW5kDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgaW50ZXJuYXRpb25hbGl6YXRpb24NCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhbmQNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBsb2NhbGl6YXRp b24NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBvZg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIGh1bWFuLXJlYWRhYmxlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgZmllbGRzIGxpa2UNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjbGllbnRfbmFtZSBpbg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHRoZSBjbGllbnQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICByZWdpc3RyYXRpb24uDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgV2hpY2ggaXMgdG8NCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzYXk6IGlmIGENCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBj bGllbnQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBzdXBwb3J0cyB0ZW4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBsYW5ndWFnZXMgYW5kDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgd2FudHMgdG8NCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBwcmVzZW50 IGl0c2VsZg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIGluIHRlbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIGxhbmd1YWdlcywNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzaG91bGQgaXQgaGF2ZQ0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRvIHJlZ2lz dGVyDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgaXRzZWxmIHRlbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHRpbWVzIHdpdGggYW4NCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBUz88YnI+DQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGJyPg0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEF0IHRo ZSBtb21lbnQsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgSSYjMzk7bSBvZiB0aGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBvcGluaW9uIGENCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjbGllbnQgd2l0aA0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRl biBsYW5ndWFnZXMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBjb3VsZCByZWdpc3Rlcg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGl0c2VsZiB0ZW4NCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0aW1lcywgb3IgZG8N CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBzb21ldGhpbmcgd2l0aA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHRoZSBjb250ZXh0IGluDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgd2hpY2ggaXQgcnVucw0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRvIGRl dGVybWluZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHdoaWNoDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgaHVtYW4tZmFjaW5nDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbGFuZ3VhZ2UgdG8NCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1c2UuIEtlZXAg aW4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBtaW5kIHRoYXQgaW4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBzb21lIGNhc2VzDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKHN1Y2ggYXMNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBuYXRpdmUNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjbGll bnRzKSwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB5b3UmIzM5O2xsIGJlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgZHluYW1pY2FsbHkNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICByZWdpc3RlcmluZyBhDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY2xp ZW50IGZvcg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIGVhY2ggdXNlciwgaW4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBlZmZlY3QuIEluDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgb3RoZXIgd29yZHMsIEkNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBw ZXJzb25hbGx5DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgdGhpbmsgdGhhdA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHRoaXMgaXMgYQ0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJhdGhvbGUgdGhhdA0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHdpbGwg Y2F1c2UNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBtb3JlIGhhcm0gdGhhbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIGdvb2QuPGJyPg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmbmJzcDstLSBKdXN0 aW48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBPQXV0aCBtYWlsaW5nDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgbGlzdDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PGJyPg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IDwvYmxvY2txdW90ZT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8YSBocmVmPSJt YWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48 YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0 aDwvYT48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgPC9ibG9ja3F1b3RlPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIDwvYmxvY2txdW90ZT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2 Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg PC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgPC9ibG9ja3F1b3RlPg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAg ICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICA8L2Jsb2Nr cXVvdGU+DQogICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAg IDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICA8YnI+ DQogICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAg ICAgPC9kaXY+DQogICAgICAgICAgICA8YnI+DQogICAgICAgICAgICBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiAgICAgICAgICAgIE9BdXRoIG1h aWxpbmcgbGlzdDxicj4NCiAgICAgICAgICAgIDxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCiAgICAgICAgICAgIDxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9h Pjxicj4NCiAgICAgICAgICAgIDxicj4NCiAgICAgICAgICA8L2Jsb2NrcXVvdGU+DQogICAgICAg IDwvZGl2Pg0KICAgICAgICA8YnI+DQogICAgICAgIDxiciBjbGVhcj0iYWxsIj4NCiAgICAgICAg PGRpdj48YnI+DQogICAgICAgIDwvZGl2Pg0KICAgICAgICAtLSA8YnI+DQogICAgICAgIE5hdCBT YWtpbXVyYSAoPW5hdCkNCiAgICAgICAgPGRpdj5DaGFpcm1hbiwgT3BlbklEIEZvdW5kYXRpb248 YnI+DQogICAgICAgICAgPGEgaHJlZj0iaHR0cDovL25hdC5zYWtpbXVyYS5vcmcvIiB0YXJnZXQ9 Il9ibGFuayI+aHR0cDovL25hdC5zYWtpbXVyYS5vcmcvPC9hPjxicj4NCiAgICAgICAgICBAX25h dF9lbjwvZGl2Pg0KICAgICAgPC9kaXY+DQogICAgPC9ibG9ja3F1b3RlPg0KICAgIDxicj4NCiAg PC9kaXY+PC9kaXY+PC9kaXY+DQoNCjwvYmxvY2txdW90ZT48L2Rpdj48YnI+PC9kaXY+DQo= --e89a8f3b9ff568ddb404d7d26fb6-- From Michael.Jones@microsoft.com Wed Mar 13 12:09: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 838B511E8180 for ; Wed, 13 Mar 2013 12:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.086, 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 DqsoVvWZJKAo for ; Wed, 13 Mar 2013 12:09:04 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0210.outbound.protection.outlook.com [207.46.163.210]) by ietfa.amsl.com (Postfix) with ESMTP id A5CF921F8EAC for ; Wed, 13 Mar 2013 12:09:03 -0700 (PDT) Received: from BY2FFO11FD021.protection.gbl (10.1.15.203) by BY2FFO11HUB037.protection.gbl (10.1.14.120) with Microsoft SMTP Server (TLS) id 15.0.620.12; Wed, 13 Mar 2013 19:08:54 +0000 Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD021.mail.protection.outlook.com (10.1.15.210) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Wed, 13 Mar 2013 19:08:54 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.132]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.02.0318.003; Wed, 13 Mar 2013 19:08:27 +0000 From: Mike Jones To: "Justin P. Richer" , Chuck Mortimore , "Todd W Lainhart (lainhart@us.ibm.com)" , Nov Matake , "Bob Gregory (bob@huddle.net)" , "Donald F Coffin (donald.coffin@reminetworks.com)" , "Roland Hedberg" , Brian Campbell Thread-Topic: Additional OAuth Feature Matrix questions intended to clarify extensions used Thread-Index: Ac4gHiPCNq+MEwoTQQGyxHxLfnHgUA== Date: Wed, 13 Mar 2013 19:08:27 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943675061A2@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.32] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943675061A2TK5EX14MBXC283r_" 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)(52544001)(74502001)(31966008)(54356001)(53806001)(5343635001)(66066001)(20776003)(79102001)(15202345001)(46102001)(65816001)(63696002)(5343655001)(55846006)(56776001)(76482001)(47446002)(51856001)(4396001)(49866001)(47736001)(47976001)(59766001)(77982001)(44976002)(33656001)(54316002)(50986001)(80022001)(16236675001)(16406001)(69226001)(512954001)(74662001)(56816002); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB037; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0784C803FD Cc: "oauth@ietf.org" Subject: [OAUTH-WG] Additional OAuth Feature Matrix questions intended to clarify extensions used X-BeenThere: oauth@ietf.org X-Mailman-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, 13 Mar 2013 19:09:05 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943675061A2TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Having looked at the results yesterday, I'd appreciate it if each you that = already supplied data about your implementations could also answer these ad= ditional questions. All are intended to give more insight into extensions = defined and used. (In many cases, I recognize that your answers will be "n= one".) What additional grant types are defined, and what do they do? What scope values do you use, and what do they mean? What additional authorization request parameters are defined, and what do t= hey do? What additional authorization response parameters are defined, and what do = they do? What additional authorization error parameters are defined, and what do the= y do? What additional token request parameters are defined, and what do they do? What additional token response parameters are defined, and what do they do? What additional token error parameters are defined, and what do they do? What additional refresh request parameters are defined, and what do they do= ? What additional refresh response parameters are defined, and what do they d= o? What additional refresh error parameters are defined, and what do they do? What additional redirection endpoint parameters are defined, and what do th= ey do? What additional protocol endpoints are utilized, and what do they do? What additional means of communicating resource errors are defined, and wha= t do they do? Thanks a bunch! -- Mike --_000_4E1F6AAD24975D4BA5B1680429673943675061A2TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Having looked at the results yesterday, I’d ap= preciate it if each you that already supplied data about your implementatio= ns could also answer these additional questions.  All are intended to = give more insight into extensions defined and used.  (In many cases, I recognize that your answers will be “n= one”.)

 

What additional grant types are defined, and what do= they do?

What scope values do you use, and what do they mean?=

 

What additional authorization request parameters are= defined, and what do they do?

What additional authorization response parameters ar= e defined, and what do they do?

What additional authorization error parameters are d= efined, and what do they do?

 

What additional token request parameters are defined= , and what do they do?

What additional token response parameters are define= d, and what do they do?

What additional token error parameters are defined, = and what do they do?

 

What additional refresh request parameters are defin= ed, and what do they do?

What additional refresh response parameters are defi= ned, and what do they do?

What additional refresh error parameters are defined= , and what do they do?

 

What additional redirection endpoint parameters are = defined, and what do they do?

What additional protocol endpoints are utilized, and= what do they do?

What additional means of communicating resource erro= rs are defined, and what do they do?

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p; Thanks a bunch!

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

 

--_000_4E1F6AAD24975D4BA5B1680429673943675061A2TK5EX14MBXC283r_-- From Michael.Jones@microsoft.com Wed Mar 13 12: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 5ED7811E8120 for ; Wed, 13 Mar 2013 12:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q8MGAZmjr9Ue for ; Wed, 13 Mar 2013 12:21:45 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0237.outbound.protection.outlook.com [207.46.163.237]) by ietfa.amsl.com (Postfix) with ESMTP id 96EB311E8168 for ; Wed, 13 Mar 2013 12:21:44 -0700 (PDT) Received: from BY2FFO11FD022.protection.gbl (10.1.15.201) by BY2FFO11HUB019.protection.gbl (10.1.14.178) with Microsoft SMTP Server (TLS) id 15.0.620.12; Wed, 13 Mar 2013 19:21:42 +0000 Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD022.mail.protection.outlook.com (10.1.15.211) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Wed, 13 Mar 2013 19:21:41 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.132]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0318.003; Wed, 13 Mar 2013 19:20:56 +0000 From: Mike Jones To: "Justin P. Richer" , Chuck Mortimore , "Todd W Lainhart (lainhart@us.ibm.com)" , Nov Matake , "Bob Gregory (bob@huddle.net)" , "Donald F Coffin (donald.coffin@reminetworks.com)" , "Roland Hedberg" , Brian Campbell Thread-Topic: [OAUTH-WG] Additional OAuth Feature Matrix questions intended to clarify extensions used Thread-Index: Ac4gHiPCNq+MEwoTQQGyxHxLfnHgUAAAaMLA Date: Wed, 13 Mar 2013 19:20:55 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943675065BC@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B1680429673943675061A2@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943675061A2@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.32] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943675065BCTK5EX14MBXC283r_" 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)(199002)(52544001)(189002)(65816001)(49866001)(50986001)(63696002)(56816002)(31966008)(54316002)(47446002)(76482001)(16406001)(77982001)(4396001)(66066001)(15202345001)(79102001)(59766001)(46102001)(512954001)(54356001)(80022001)(53806001)(5343655001)(20776003)(74662001)(74502001)(47976001)(51856001)(44976002)(69226001)(55846006)(56776001)(5343635001)(47736001)(16236675001)(33656001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB019; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0784C803FD Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Additional OAuth Feature Matrix questions intended to clarify extensions used X-BeenThere: oauth@ietf.org X-Mailman-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, 13 Mar 2013 19:21:47 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943675065BCTK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable And one more question... What additional response_type values do you define, and what do they do? From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= ike Jones Sent: Wednesday, March 13, 2013 12:08 PM To: Justin P. Richer; Chuck Mortimore; Todd W Lainhart (lainhart@us.ibm.com= ); Nov Matake; Bob Gregory (bob@huddle.net); Donald F Coffin (donald.coffin= @reminetworks.com); Roland Hedberg; Brian Campbell Cc: oauth@ietf.org Subject: [OAUTH-WG] Additional OAuth Feature Matrix questions intended to c= larify extensions used Having looked at the results yesterday, I'd appreciate it if each you that = already supplied data about your implementations could also answer these ad= ditional questions. All are intended to give more insight into extensions = defined and used. (In many cases, I recognize that your answers will be "n= one".) What additional grant types are defined, and what do they do? What scope values do you use, and what do they mean? What additional authorization request parameters are defined, and what do t= hey do? What additional authorization response parameters are defined, and what do = they do? What additional authorization error parameters are defined, and what do the= y do? What additional token request parameters are defined, and what do they do? What additional token response parameters are defined, and what do they do? What additional token error parameters are defined, and what do they do? What additional refresh request parameters are defined, and what do they do= ? What additional refresh response parameters are defined, and what do they d= o? What additional refresh error parameters are defined, and what do they do? What additional redirection endpoint parameters are defined, and what do th= ey do? What additional protocol endpoints are utilized, and what do they do? What additional means of communicating resource errors are defined, and wha= t do they do? Thanks a bunch! -- Mike --_000_4E1F6AAD24975D4BA5B1680429673943675065BCTK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

And one more question&= #8230;

 

What additional respon= se_type values do you define, and what do they do?

 

 

From: oauth-bo= unces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Wednesday, March 13, 2013 12:08 PM
To: Justin P. Richer; Chuck Mortimore; Todd W Lainhart (lainhart@us.= ibm.com); Nov Matake; Bob Gregory (bob@huddle.net); Donald F Coffin (donald= .coffin@reminetworks.com); Roland Hedberg; Brian Campbell
Cc: oauth@ietf.org
Subject: [OAUTH-WG] Additional OAuth Feature Matrix questions intend= ed to clarify extensions used

 

Having looked at the results yesterday, I’d ap= preciate it if each you that already supplied data about your implementatio= ns could also answer these additional questions.  All are intended to = give more insight into extensions defined and used.  (In many cases, I recognize that your answers will be “n= one”.)

 

What additional grant types are defined, and what do= they do?

What scope values do you use, and what do they mean?=

 

What additional authorization request parameters are= defined, and what do they do?

What additional authorization response parameters ar= e defined, and what do they do?

What additional authorization error parameters are d= efined, and what do they do?

 

What additional token request parameters are defined= , and what do they do?

What additional token response parameters are define= d, and what do they do?

What additional token error parameters are defined, = and what do they do?

 

What additional refresh request parameters are defin= ed, and what do they do?

What additional refresh response parameters are defi= ned, and what do they do?

What additional refresh error parameters are defined= , and what do they do?

 

What additional redirection endpoint parameters are = defined, and what do they do?

What additional protocol endpoints are utilized, and= what do they do?

What additional means of communicating resource erro= rs are defined, and what do they do?

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p; Thanks a bunch!

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

 

--_000_4E1F6AAD24975D4BA5B1680429673943675065BCTK5EX14MBXC283r_-- From prateek.mishra@oracle.com Wed Mar 13 13:13:24 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 33F0B11E816E for ; Wed, 13 Mar 2013 13:13:24 -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 tWqeep7Xea7F for ; Wed, 13 Mar 2013 13:13:23 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA2511E813B for ; Wed, 13 Mar 2013 13:13:23 -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 r2DKDM3i021352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 13 Mar 2013 20:13:23 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r2DKDL2p012043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Mar 2013 20:13:22 GMT Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r2DKDLmg016897; Wed, 13 Mar 2013 15:13:21 -0500 Received: from [10.159.143.165] (/10.159.143.165) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 13 Mar 2013 13:13:21 -0700 Message-ID: <5140DDD8.40800@oracle.com> Date: Wed, 13 Mar 2013 16:13:12 -0400 From: prateek mishra Organization: Oracle Corporation User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: "oauth@ietf.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsinet22.oracle.com [141.146.126.238] Subject: [OAUTH-WG] Support for SAML assertion reference formats in OAuth SAML Assertion profile X-BeenThere: oauth@ietf.org X-Mailman-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, 13 Mar 2013 20:13:24 -0000 SAML supports a couple of SAML assertion reference formats, wherein assertions are passed by reference. One format is the artifact, which can be carried by a thisisanartifact element Another possibility is the SAML URI binding which supports references of the form (abcde is a SAML id) GET https:example.com/SamlService?ID=abcde HTTP/1.1 My question is whether there is value in supporting these reference formats in the profile in place of a (verbose) SAML assertion.. - prateek From ve7jtb@ve7jtb.com Wed Mar 13 13:17: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 E176A21F8AE3 for ; Wed, 13 Mar 2013 13:17:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8eV319vqCpGp for ; Wed, 13 Mar 2013 13:17:16 -0700 (PDT) Received: from mail-da0-x230.google.com (mail-da0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id 5F93F21F870F for ; Wed, 13 Mar 2013 13:17:16 -0700 (PDT) Received: by mail-da0-f48.google.com with SMTP id w4so565491dam.21 for ; Wed, 13 Mar 2013 13:17:16 -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=gJmMsHr+4rLilD4Ub3PH2dr/f7aBMvopk9zhmK8TG7k=; b=k5Sossrb7Gum+Aw4imibuM1LjnHQl9ioVOvq+u1vpgkRkEXhzXN4JJfUmqkaKzwkgZ m+AXsO684a1pWjSLIujQZgtYRu6xjfqIMTPywZj61l8AAjrgrCMDsLq29sUiV3KedvVC eTgRRyEiM8ngpgEzCSdEi9cIk0iRio2dFdcFlLpRZxVZre+lTPL8avKUJxCjQXgLdmU9 ta42ALa3Mq+Jw3NBriKfYqMcEuDE0UhuAC4/5UQ4Mtr+6q4YXCiOI1YMuAYoBvjSpdD3 UMiKzRihT6JSAHJIb3jmQkppR18vv9QywLA+EAl9eNgGUEXRDV6rvB44b+Xaquf75I7g Y1cg== X-Received: by 10.68.252.193 with SMTP id zu1mr48105455pbc.175.1363205835570; Wed, 13 Mar 2013 13:17:15 -0700 (PDT) Received: from dhcp-543c.meeting.ietf.org (dhcp-543c.meeting.ietf.org. [130.129.84.60]) by mx.google.com with ESMTPS id vd4sm30980798pbc.35.2013.03.13.13.17.12 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 13 Mar 2013 13:17:13 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_3C8058ED-7E61-4893-A7CD-B978A50AD076"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Bradley In-Reply-To: <5140DDD8.40800@oracle.com> Date: Wed, 13 Mar 2013 16:17:10 -0400 Message-Id: References: <5140DDD8.40800@oracle.com> To: prateek mishra X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQlR/NkqKlifhMKr1Ohyrgqp2V2iF79jbUCtuuY9pKCj4SsyD5FnLMFXl+J62xKoR3G30C73 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Support for SAML assertion reference formats in OAuth SAML Assertion profile X-BeenThere: oauth@ietf.org X-Mailman-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, 13 Mar 2013 20:17:17 -0000 --Apple-Mail=_3C8058ED-7E61-4893-A7CD-B978A50AD076 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii It is a direct connection and not a browser redirect. I don't think = there is much value in supporting something like artifact. On 2013-03-13, at 4:13 PM, prateek mishra = wrote: > SAML supports a couple of SAML assertion reference formats, wherein = assertions are passed by reference. >=20 > One format is the artifact, which can be carried by a = thisisanartifact element >=20 > Another possibility is the SAML URI binding which supports references = of the form (abcde is a SAML id) >=20 > GET https:example.com/SamlService?ID=3Dabcde HTTP/1.1 >=20 > My question is whether there is value in supporting these reference = formats in the profile in place of a (verbose) SAML assertion.. >=20 > - prateek > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_3C8058ED-7E61-4893-A7CD-B978A50AD076 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 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMzEzMjAxNzExWjAjBgkqhkiG9w0BCQQxFgQU/7RQ1Nr3 I0TESYJep9vcOAUalUAwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAAOhHim194cABy2wnrB9Bd4LWX3U087OYidJvLvmj 4b8geIG6EeIjMopOYz0pHM087yen2H8o22fVZzhi4kfE47RQ4wtagxtthK9K+s4e7GjYxy4qsBLn G7G6Uyq0g3qifCK10whsShVjSsol2pGnbSoClyafWfMGUAeou4DIidW6FHO4gpxwAb61JEqvotBm EVRvvIafhCCPFJ3z7natQqtZ9hbJnJuymb4KGcsMy+sZVTmfJ/dwkQYNsjqhKcfagmHvL4PzCAZz 9giaZKUNnEMG8IhGn5l46KZQeMqc+/HnWQ6sKt4ybRtLIwLuhYrUww+wpzj6AKjljYB5jOyzEAAA AAAAAA== --Apple-Mail=_3C8058ED-7E61-4893-A7CD-B978A50AD076-- From bcampbell@pingidentity.com Wed Mar 13 13:57: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 68E5811E80FE for ; Wed, 13 Mar 2013 13:57:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.689 X-Spam-Level: X-Spam-Status: No, score=-5.689 tagged_above=-999 required=5 tests=[AWL=0.287, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3g98MLrJSsl8 for ; Wed, 13 Mar 2013 13:57:02 -0700 (PDT) Received: from na3sys009aog124.obsmtp.com (na3sys009aog124.obsmtp.com [74.125.149.151]) by ietfa.amsl.com (Postfix) with ESMTP id 414A811E80DC for ; Wed, 13 Mar 2013 13:57:02 -0700 (PDT) Received: from mail-ob0-f199.google.com ([209.85.214.199]) (using TLSv1) by na3sys009aob124.postini.com ([74.125.148.12]) with SMTP ID DSNKUUDoHmfGLaFDSh1jGnzBaFJ5n1YxaoK9@postini.com; Wed, 13 Mar 2013 13:57:02 PDT Received: by mail-ob0-f199.google.com with SMTP id wd20so7748317obb.6 for ; Wed, 13 Mar 2013 13:57:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=0hCSp2PfqgK18hhlhMqwuxUvzBaRRuOnrvvpP3hLEpo=; b=YNGkRfjIs3rT6P8uZyyaRcFJrzSnUZ+NgZIB/lOC7r2v649vqdwj4LFVlE+qU1f/Xj 9jB+Yqg1JK/pwN78b7PovI0O0Pymez00qeh821GmQ1KnoVClKrPQtG8WyH3ayS3gscBB gVBSqODO6jB+JV+9+Ep+guqpDkc+4ri6xEkXQM9ue2u+C4OK6BuwQsQIZbblHT3gi1z1 FSoJiAqhyBneyxRn/7BsLKwcONTxgXPblfG86LDonhg7F2WSLVY4vT+7NoHuKtqcA6M2 aJL+VdtPOh1MMPJfeEllFAFBEo0JhXJ/8EPmixUvP2yTnnBCAZA8zzKD+VvXEuvIoNuZ W4mg== X-Received: by 10.50.213.41 with SMTP id np9mr17492170igc.79.1363208221226; Wed, 13 Mar 2013 13:57:01 -0700 (PDT) X-Received: by 10.50.213.41 with SMTP id np9mr17492162igc.79.1363208221139; Wed, 13 Mar 2013 13:57:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.32.106 with HTTP; Wed, 13 Mar 2013 13:56:31 -0700 (PDT) In-Reply-To: References: <5140DDD8.40800@oracle.com> From: Brian Campbell Date: Wed, 13 Mar 2013 16:56:31 -0400 Message-ID: To: John Bradley Content-Type: multipart/alternative; boundary=f46d04462eb6c6cf9f04d7d4a5a2 X-Gm-Message-State: ALoCoQlu3+89xbJiGFAmV/l/9iBl3xeTUFjgQ9sdiijQUd1QlJmoTyonuXUTryUJzh6BFw9VxtzAX/1m0hWLhGgXRaoukxJe++3/N+R+JiV5H2r5kJAXGD2wHlEWWtoCkkXflsCWLXJP Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Support for SAML assertion reference formats in OAuth SAML Assertion profile X-BeenThere: oauth@ietf.org X-Mailman-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, 13 Mar 2013 20:57:06 -0000 --f46d04462eb6c6cf9f04d7d4a5a2 Content-Type: text/plain; charset=ISO-8859-1 I also don't think there's much value to it. Practically relative to the additional complexity it'd bring along for the ride. On Wed, Mar 13, 2013 at 4:17 PM, John Bradley wrote: > It is a direct connection and not a browser redirect. I don't think there > is much value in supporting something like artifact. > > On 2013-03-13, at 4:13 PM, prateek mishra > wrote: > > > SAML supports a couple of SAML assertion reference formats, wherein > assertions are passed by reference. > > > > One format is the artifact, which can be carried by a > thisisanartifact element > > > > Another possibility is the SAML URI binding which supports references of > the form (abcde is a SAML id) > > > > GET https:example.com/SamlService?ID=abcde HTTP/1.1 > > > > My question is whether there is value in supporting these reference > formats in the profile in place of a (verbose) SAML assertion.. > > > > - prateek > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --f46d04462eb6c6cf9f04d7d4a5a2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I also don't think there's much value to it. Pract= ically relative to the additional complexity it'd bring along for the r= ide.=A0


On Wed, Mar 13, 2013 at 4:17 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
It is a direct connection and not a browser redirect. =A0I don't think = there is much value in supporting something like artifact.

On 2013-03-13, at 4:13 PM, prateek mishra <prateek.mishra@oracle.com> wrote:

> SAML supports a couple of SAML assertion reference formats, wherein as= sertions are passed by reference.
>
> One format is the artifact, which can be carried by a <saml:artifac= t>thisisanartifact<saml:artifact> element
>
> Another possibility is the SAML URI binding which supports references = of the form (abcde is a SAML id)
>
> GET https:example.com/SamlService?ID=3Dabcde HTTP/1.1
>
> My question is whether there is value in supporting these reference fo= rmats in the profile in place of a (verbose) SAML assertion..
>
> - prateek
> _______________________________________________
> 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


--f46d04462eb6c6cf9f04d7d4a5a2-- From gffletch@aol.com Thu Mar 14 07:47: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 7A7C511E81D1 for ; Thu, 14 Mar 2013 07:47:10 -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 A3O9r5m3Nq0E for ; Thu, 14 Mar 2013 07:47:05 -0700 (PDT) Received: from imr-db03.mx.aol.com (imr-db03.mx.aol.com [205.188.91.97]) by ietfa.amsl.com (Postfix) with ESMTP id DD1ED11E81D0 for ; Thu, 14 Mar 2013 07:47:02 -0700 (PDT) Received: from mtaout-mb03.r1000.mx.aol.com (mtaout-mb03.r1000.mx.aol.com [172.29.41.67]) by imr-db03.mx.aol.com (Outbound Mail Relay) with ESMTP id 5C1ED3800014A; Thu, 14 Mar 2013 10:47:02 -0400 (EDT) Received: from palantir.local (unknown [10.181.176.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-mb03.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id E3D66E000095; Thu, 14 Mar 2013 10:47:01 -0400 (EDT) Message-ID: <5141E2E6.9020701@aol.com> Date: Thu, 14 Mar 2013 10:47:02 -0400 From: George Fletcher Organization: AOL LLC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "oauth@ietf.org WG" References: <1B4C0C9F-4B8E-4B2D-BAF7-665D3EBBE56C@ve7jtb.com> <51408B8B.9000800@mitre.org> In-Reply-To: <51408B8B.9000800@mitre.org> Content-Type: multipart/alternative; boundary="------------070900070803080507040107" x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20121107; t=1363272422; bh=mTVk9IBIyQDwswbSBA4yVS3337miTOXy3rlwiHCp2WE=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=FC+b8hEho2+5WaIJXnUhv9qH06kGARH9JLZJhRl/fFQrD/3tpHO3V5a87/YIThxqt 3n4QM33ZmRpBsbc76RiHYNDIOw5qTZxgn6Z0dFcXVnCwkTKtDs7D2S9OQ8UGmU3UdY CK3skybbOYP+pnbJQMZoMgZEKdeaL0PZ2Yqpup8M= X-AOL-SCOLL-SCORE: 0:2:485069376:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d29435141e2e541e2 X-AOL-IP: 10.181.176.202 Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readable names X-BeenThere: oauth@ietf.org X-Mailman-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, 14 Mar 2013 14:47:10 -0000 This is a multi-part message in MIME format. --------------070900070803080507040107 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit As a simplifying option... why not just require human-readable fields to require a "script-tag". This way it is always explicit what language/locale the text is for. It then becomes the responsibility of the AS to return an appropriate response if there is not a direct match between a request and the data stored at the AS (and out of scope of the spec). Thanks, George On 3/13/13 10:22 AM, Justin Richer wrote: > So with what little feedback I've gotten, I'm proposing to add text > from the proposed webfinger and OIDC drafts for the hash-based > localization of strings, with the following properties: > > * All localized versions of fields are fully optional on both client > and server > * If a localized version of a field is included, its bare-value > (perhaps internationalized) field MUST be included > * All human-readable fields are eligible for this mechanism (including > any uri's for user-facing web pages, which can be used to point to > language-specific pages) > * Clients and servers can decide to use whatever language/script they > want to for the bare-value field, and no assumptions can be made on > either side about what that is > > I think that with these constraints, we can add functionality to > address Stephen's concerns without getting too complicated or putting > too much burden of support. > > -- Justin > > On 03/11/2013 06:52 PM, Nat Sakimura wrote: >> Similar work is in progress at Webfinger. >> >> See: http://www.ietf.org/mail-archive/web/webfinger/current/msg00530.html >> >> Paul is proposing the same syntax as Connect. >> >> 2013/3/12 Richer, Justin P. > > >> >> It does presume a definition of "claim", which I suppose we could >> turn to "metadata field" for DynReg and its extensions to be >> appropriately limiting. But we also need a good definition of >> what a language-tag-less field means, and whether or not it's >> required if the other fields are present or not (which is >> something that Connect is trying to fix at the moment, as I >> recall from last week). >> >> So it turns into about a paragraph worth of text. Is that worth >> it? I'm not entirely convinced that it is, but I'm interested to >> hear what others think, particularly those who *aren't* tied into >> the OpenID Connect protocol so much. (I don't want to pick a >> solution just because it's familiar, if we need a solution at all.) >> >> -- Justin >> >> On Mar 11, 2013, at 6:35 PM, Brian Campbell >> > >> wrote: >> >>> A fair question but what would need to be pulled in is really >>> probably only a couple sentences (and reference) from >>> http://openid.net/specs/openid-connect-messages-1_0-16.html#ClaimsLanguagesAndScripts >>> (note the reference to 2.1.1.1.3 inside >>> http://openid.net/specs/openid-connect-registration-1_0-15.html >>> is broken) >>> >>> >>> On Mon, Mar 11, 2013 at 6:26 PM, Richer, Justin P. >>> > wrote: >>> >>> My concern with this is that OIDC can get away with defining >>> this multi-language structure because it defines the >>> mechanism once (in Messages) and applies it to all >>> user-readable strings throughout the whole application >>> protocol, of which there are several. Do we really want to >>> pull in that whole structure and mechanism for one field in >>> client registration? I really don't think it should be >>> something that's defined completely inside of DynReg for a >>> corner case for a single field, but I also doubt we want to >>> normatively point to OIDC Messages for this solution either. >>> >>> There are also other ways to do this: Webfinger [1] for >>> instance uses JSON structures to give language tags to field >>> values, and has a default mechanism: >>> >>> { "en_us": "my client", ... } >>> >>> The fundamental question is this: should a client be able >>> to register multiple names (in different locales) with a >>> single client_id, or should it get a different client_id for >>> each display language set? >>> >>> -- Justin >>> >>> [1] http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-11 >>> >>> On Mar 11, 2013, at 5:54 PM, John Bradley >> > >>> wrote: >>> >>>> That is what I was thinking. It would be up to the AS to >>>> determine what language and script to present based on the >>>> user preference. >>>> >>>> While a large number of clients will be native and might be >>>> able to customize themselves for a single user during >>>> registration , we don't want to forget the web server >>>> clients that are multi user. >>>> >>>> On 2013-03-11, at 10:49 PM, Brian Campbell >>>> >>> > wrote: >>>> >>>>> FWIW, the closely related OpenID Connect client >>>>> registration draft does have some support for doing this, >>>>> which could maybe be borrowed. See client_name in §2 at >>>>> http://openid.net/specs/openid-connect-registration-1_0-15.html#client-metadata >>>>> and the examples. >>>>> >>>>> "client_name": "My Example", >>>>> "client_name#ja-Jpan-JP":"???????", >>>>> >>>>> >>>>> >>>>> On Mon, Mar 11, 2013 at 5:15 PM, Richer, Justin P. >>>>> > wrote: >>>>> >>>>> It was brought up at the in-person meeting today that >>>>> we'll want to consider issues around >>>>> internationalization and localization of >>>>> human-readable fields like client_name in the client >>>>> registration. Which is to say: if a client supports >>>>> ten languages and wants to present itself in ten >>>>> languages, should it have to register itself ten times >>>>> with an AS? >>>>> >>>>> At the moment, I'm of the opinion a client with ten >>>>> languages could register itself ten times, or do >>>>> something with the context in which it runs to >>>>> determine which human-facing language to use. Keep in >>>>> mind that in some cases (such as native clients), >>>>> you'll be dynamically registering a client for each >>>>> user, in effect. In other words, I personally think >>>>> that this is a rathole that will cause more harm than >>>>> good. >>>>> >>>>> -- Justin >>>>> _______________________________________________ >>>>> OAuth mailing 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 >> >> >> >> >> -- >> 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 --------------070900070803080507040107 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit As a simplifying option... why not just require human-readable fields to require a "script-tag". This way it is always explicit what language/locale the text is for. It then becomes the responsibility of the AS to return an appropriate response if there is not a direct match between a request and the data stored at the AS (and out of scope of the spec).

Thanks,
George

On 3/13/13 10:22 AM, Justin Richer wrote:
So with what little feedback I've gotten, I'm proposing to add text from the proposed webfinger and OIDC drafts for the hash-based localization of strings, with the following properties:

* All localized versions of fields are fully optional on both client and server
* If a localized version of a field is included, its bare-value (perhaps internationalized) field MUST be included
* All human-readable fields are eligible for this mechanism (including any uri's for user-facing web pages, which can be used to point to language-specific pages)
* Clients and servers can decide to use whatever language/script they want to for the bare-value field, and no assumptions can be made on either side about what that is

I think that with these constraints, we can add functionality to address Stephen's concerns without getting too complicated or putting too much burden of support.

 -- Justin

On 03/11/2013 06:52 PM, Nat Sakimura wrote:
Similar work is in progress at Webfinger. 


Paul is proposing the same syntax as Connect. 

2013/3/12 Richer, Justin P. <jricher@mitre.org>
It does presume a definition of "claim", which I suppose we could turn to "metadata field" for DynReg and its extensions to be appropriately limiting. But we also need a good definition of what a language-tag-less field means, and whether or not it's required if the other fields are present or not (which is something that Connect is trying to fix at the moment, as I recall from last week). 

So it turns into about a paragraph worth of text. Is that worth it? I'm not entirely convinced that it is, but I'm interested to hear what others think, particularly those who *aren't* tied into the OpenID Connect protocol so much. (I don't want to pick a solution just because it's familiar, if we need a solution at all.)

 -- Justin

On Mar 11, 2013, at 6:35 PM, Brian Campbell <bcampbell@pingidentity.com>
 wrote:

A fair question but what would need to be pulled in is really probably only a couple sentences (and reference) from http://openid.net/specs/openid-connect-messages-1_0-16.html#ClaimsLanguagesAndScripts (note the reference to 2.1.1.1.3 inside http://openid.net/specs/openid-connect-registration-1_0-15.html is broken)


On Mon, Mar 11, 2013 at 6:26 PM, Richer, Justin P. <jricher@mitre.org> wrote:
My concern with this is that OIDC can get away with defining this multi-language structure because it defines the mechanism once (in Messages) and applies it to all user-readable strings throughout the whole application protocol, of which there are several. Do we really want to pull in that whole structure and mechanism for one field in client registration? I really don't think it should be something that's defined completely inside of DynReg for a corner case for a single field, but I also doubt we want to normatively point to OIDC Messages for this solution either.

There are also other ways to do this: Webfinger [1] for instance uses JSON structures to give language tags to field values, and has a default mechanism:

   { "en_us": "my client", … }

The fundamental question is  this: should a client be able to register multiple names (in different locales) with a single client_id, or should it get a different client_id for each display language set?

 -- Justin


On Mar 11, 2013, at 5:54 PM, John Bradley <ve7jtb@ve7jtb.com>
 wrote:

That is what I was thinking.   It would be up to the AS to determine what language and script to present based on the user preference.

While a large number of clients will be native and might be able to customize themselves for a single user during registration , we don't want to forget the web server clients that are multi user.

On 2013-03-11, at 10:49 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:

FWIW, the closely related OpenID Connect client registration draft does have some support for doing this, which could maybe be borrowed. See client_name in §2 at http://openid.net/specs/openid-connect-registration-1_0-15.html#client-metadata and the examples.
 
   "client_name": "My Example",
   "client_name#ja-Jpan-JP":"クライアント名",



On Mon, Mar 11, 2013 at 5:15 PM, Richer, Justin P. <jricher@mitre.org> wrote:
It was brought up at the in-person meeting today that we'll want to consider issues around internationalization and localization of human-readable fields like client_name in the client registration. Which is to say: if a client supports ten languages and wants to present itself in ten languages, should it have to register itself ten times with an AS?

At the moment, I'm of the opinion a client with ten languages could register itself ten times, or do something with the context in which it runs to determine which human-facing language to use. Keep in mind that in some cases (such as native clients), you'll be dynamically registering a client for each user, in effect. In other words, I personally think that this is a rathole that will cause more harm than good.

 -- Justin
_______________________________________________
OAuth mailing 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




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

--------------070900070803080507040107-- From jricher@mitre.org Thu Mar 14 08:04: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 1A8EA11E824C for ; Thu, 14 Mar 2013 08:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.402 X-Spam-Level: *** X-Spam-Status: No, score=3.402 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, URIBL_WS_SURBL=10] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ZTZyYuA+1ed for ; Thu, 14 Mar 2013 08:04:18 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 83CFE11E8235 for ; Thu, 14 Mar 2013 08:03:29 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id DB2191F0AA4; Thu, 14 Mar 2013 11:03:28 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 963B11F0AE2; Thu, 14 Mar 2013 11:03:28 -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, 14 Mar 2013 11:03:28 -0400 Message-ID: <5141E671.2050708@mitre.org> Date: Thu, 14 Mar 2013 11:02:09 -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: George Fletcher References: <1B4C0C9F-4B8E-4B2D-BAF7-665D3EBBE56C@ve7jtb.com> <51408B8B.9000800@mitre.org> <5141E2E6.9020701@aol.com> In-Reply-To: <5141E2E6.9020701@aol.com> Content-Type: multipart/alternative; boundary="------------080500090605050801040303" X-Originating-IP: [129.83.31.58] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readable names X-BeenThere: oauth@ietf.org X-Mailman-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, 14 Mar 2013 15:04:26 -0000 --------------080500090605050801040303 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit On the surface this does simplify things, but the issue I forsee with it is that I want to be able to call "client.getClientName()" and always get *something* out of it if there are *any* client_name fields at all. So in this world if I take a client library that assumes en-us and it talks to a server that only looks for es-cl, there's a very real chance of the client name not getting set at all. I think that's a problem. This is why I think the default field name (without the language tag) really should be required and should be left undefined as to what language and script it is. Essentially, "It's a UTF8 String, hope for the best". If you want something more specific and smart about localization, then you can support the language tags. If you just want to have a string to store and throw at the user, then you can just use the bare field name. In other words, we take what we have now (which works for a non-internationalized case where everyone just assumes a common language/script), and we augment it with features that let it be smarter if you want it to be smarter. Make the simple case simple, make the complicated case possible. -- Justin On 03/14/2013 10:47 AM, George Fletcher wrote: > As a simplifying option... why not just require human-readable fields > to require a "script-tag". This way it is always explicit what > language/locale the text is for. It then becomes the responsibility of > the AS to return an appropriate response if there is not a direct > match between a request and the data stored at the AS (and out of > scope of the spec). > > Thanks, > George > > On 3/13/13 10:22 AM, Justin Richer wrote: >> So with what little feedback I've gotten, I'm proposing to add text >> from the proposed webfinger and OIDC drafts for the hash-based >> localization of strings, with the following properties: >> >> * All localized versions of fields are fully optional on both client >> and server >> * If a localized version of a field is included, its bare-value >> (perhaps internationalized) field MUST be included >> * All human-readable fields are eligible for this mechanism >> (including any uri's for user-facing web pages, which can be used to >> point to language-specific pages) >> * Clients and servers can decide to use whatever language/script they >> want to for the bare-value field, and no assumptions can be made on >> either side about what that is >> >> I think that with these constraints, we can add functionality to >> address Stephen's concerns without getting too complicated or putting >> too much burden of support. >> >> -- Justin >> >> On 03/11/2013 06:52 PM, Nat Sakimura wrote: >>> Similar work is in progress at Webfinger. >>> >>> See: >>> http://www.ietf.org/mail-archive/web/webfinger/current/msg00530.html >>> >>> Paul is proposing the same syntax as Connect. >>> >>> 2013/3/12 Richer, Justin P. >> > >>> >>> It does presume a definition of "claim", which I suppose we >>> could turn to "metadata field" for DynReg and its extensions to >>> be appropriately limiting. But we also need a good definition of >>> what a language-tag-less field means, and whether or not it's >>> required if the other fields are present or not (which is >>> something that Connect is trying to fix at the moment, as I >>> recall from last week). >>> >>> So it turns into about a paragraph worth of text. Is that worth >>> it? I'm not entirely convinced that it is, but I'm interested to >>> hear what others think, particularly those who *aren't* tied >>> into the OpenID Connect protocol so much. (I don't want to pick >>> a solution just because it's familiar, if we need a solution at >>> all.) >>> >>> -- Justin >>> >>> On Mar 11, 2013, at 6:35 PM, Brian Campbell >>> > >>> wrote: >>> >>>> A fair question but what would need to be pulled in is really >>>> probably only a couple sentences (and reference) from >>>> http://openid.net/specs/openid-connect-messages-1_0-16.html#ClaimsLanguagesAndScripts >>>> (note the reference to 2.1.1.1.3 inside >>>> http://openid.net/specs/openid-connect-registration-1_0-15.html >>>> is broken) >>>> >>>> >>>> On Mon, Mar 11, 2013 at 6:26 PM, Richer, Justin P. >>>> > wrote: >>>> >>>> My concern with this is that OIDC can get away with >>>> defining this multi-language structure because it defines >>>> the mechanism once (in Messages) and applies it to all >>>> user-readable strings throughout the whole application >>>> protocol, of which there are several. Do we really want to >>>> pull in that whole structure and mechanism for one field in >>>> client registration? I really don't think it should be >>>> something that's defined completely inside of DynReg for a >>>> corner case for a single field, but I also doubt we want to >>>> normatively point to OIDC Messages for this solution either. >>>> >>>> There are also other ways to do this: Webfinger [1] for >>>> instance uses JSON structures to give language tags to >>>> field values, and has a default mechanism: >>>> >>>> { "en_us": "my client", ... } >>>> >>>> The fundamental question is this: should a client be able >>>> to register multiple names (in different locales) with a >>>> single client_id, or should it get a different client_id >>>> for each display language set? >>>> >>>> -- Justin >>>> >>>> [1] http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-11 >>>> >>>> On Mar 11, 2013, at 5:54 PM, John Bradley >>>> > >>>> wrote: >>>> >>>>> That is what I was thinking. It would be up to the AS to >>>>> determine what language and script to present based on the >>>>> user preference. >>>>> >>>>> While a large number of clients will be native and might >>>>> be able to customize themselves for a single user during >>>>> registration , we don't want to forget the web server >>>>> clients that are multi user. >>>>> >>>>> On 2013-03-11, at 10:49 PM, Brian Campbell >>>>> >>>> > wrote: >>>>> >>>>>> FWIW, the closely related OpenID Connect client >>>>>> registration draft does have some support for doing this, >>>>>> which could maybe be borrowed. See client_name in §2 at >>>>>> http://openid.net/specs/openid-connect-registration-1_0-15.html#client-metadata >>>>>> and the examples. >>>>>> >>>>>> "client_name": "My Example", >>>>>> "client_name#ja-Jpan-JP":"???????", >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Mar 11, 2013 at 5:15 PM, Richer, Justin P. >>>>>> > wrote: >>>>>> >>>>>> It was brought up at the in-person meeting today that >>>>>> we'll want to consider issues around >>>>>> internationalization and localization of >>>>>> human-readable fields like client_name in the client >>>>>> registration. Which is to say: if a client supports >>>>>> ten languages and wants to present itself in ten >>>>>> languages, should it have to register itself ten >>>>>> times with an AS? >>>>>> >>>>>> At the moment, I'm of the opinion a client with ten >>>>>> languages could register itself ten times, or do >>>>>> something with the context in which it runs to >>>>>> determine which human-facing language to use. Keep in >>>>>> mind that in some cases (such as native clients), >>>>>> you'll be dynamically registering a client for each >>>>>> user, in effect. In other words, I personally think >>>>>> that this is a rathole that will cause more harm than >>>>>> good. >>>>>> >>>>>> -- Justin >>>>>> _______________________________________________ >>>>>> OAuth mailing 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 >>> >>> >>> >>> >>> -- >>> 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 > --------------080500090605050801040303 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit On the surface this does simplify things, but the issue I forsee with it is that I want to be able to call "client.getClientName()" and always get *something* out of it if there are *any* client_name fields at all. So in this world if I take a client library that assumes en-us and it talks to a server that only looks for es-cl, there's a very real chance of the client name not getting set at all. I think that's a problem.

This is why I think the default field name (without the language tag) really should be required and should be left undefined as to what language and script it is. Essentially, "It's a UTF8 String, hope for the best". If you want something more specific and smart about localization, then you can support the language tags. If you just want to have a string to store and throw at the user, then you can just use the bare field name.

In other words, we take what we have now (which works for a non-internationalized case where everyone just assumes a common language/script), and we augment it with features that let it be smarter if you want it to be smarter. Make the simple case simple, make the complicated case possible.

 -- Justin

 
On 03/14/2013 10:47 AM, George Fletcher wrote:
As a simplifying option... why not just require human-readable fields to require a "script-tag". This way it is always explicit what language/locale the text is for. It then becomes the responsibility of the AS to return an appropriate response if there is not a direct match between a request and the data stored at the AS (and out of scope of the spec).

Thanks,
George

On 3/13/13 10:22 AM, Justin Richer wrote:
So with what little feedback I've gotten, I'm proposing to add text from the proposed webfinger and OIDC drafts for the hash-based localization of strings, with the following properties:

* All localized versions of fields are fully optional on both client and server
* If a localized version of a field is included, its bare-value (perhaps internationalized) field MUST be included
* All human-readable fields are eligible for this mechanism (including any uri's for user-facing web pages, which can be used to point to language-specific pages)
* Clients and servers can decide to use whatever language/script they want to for the bare-value field, and no assumptions can be made on either side about what that is

I think that with these constraints, we can add functionality to address Stephen's concerns without getting too complicated or putting too much burden of support.

 -- Justin

On 03/11/2013 06:52 PM, Nat Sakimura wrote:
Similar work is in progress at Webfinger. 


Paul is proposing the same syntax as Connect. 

2013/3/12 Richer, Justin P. <jricher@mitre.org>
It does presume a definition of "claim", which I suppose we could turn to "metadata field" for DynReg and its extensions to be appropriately limiting. But we also need a good definition of what a language-tag-less field means, and whether or not it's required if the other fields are present or not (which is something that Connect is trying to fix at the moment, as I recall from last week). 

So it turns into about a paragraph worth of text. Is that worth it? I'm not entirely convinced that it is, but I'm interested to hear what others think, particularly those who *aren't* tied into the OpenID Connect protocol so much. (I don't want to pick a solution just because it's familiar, if we need a solution at all.)

 -- Justin

On Mar 11, 2013, at 6:35 PM, Brian Campbell <bcampbell@pingidentity.com>
 wrote:

A fair question but what would need to be pulled in is really probably only a couple sentences (and reference) from http://openid.net/specs/openid-connect-messages-1_0-16.html#ClaimsLanguagesAndScripts (note the reference to 2.1.1.1.3 inside http://openid.net/specs/openid-connect-registration-1_0-15.html is broken)


On Mon, Mar 11, 2013 at 6:26 PM, Richer, Justin P. <jricher@mitre.org> wrote:
My concern with this is that OIDC can get away with defining this multi-language structure because it defines the mechanism once (in Messages) and applies it to all user-readable strings throughout the whole application protocol, of which there are several. Do we really want to pull in that whole structure and mechanism for one field in client registration? I really don't think it should be something that's defined completely inside of DynReg for a corner case for a single field, but I also doubt we want to normatively point to OIDC Messages for this solution either.

There are also other ways to do this: Webfinger [1] for instance uses JSON structures to give language tags to field values, and has a default mechanism:

   { "en_us": "my client", … }

The fundamental question is  this: should a client be able to register multiple names (in different locales) with a single client_id, or should it get a different client_id for each display language set?

 -- Justin


On Mar 11, 2013, at 5:54 PM, John Bradley <ve7jtb@ve7jtb.com>
 wrote:

That is what I was thinking.   It would be up to the AS to determine what language and script to present based on the user preference.

While a large number of clients will be native and might be able to customize themselves for a single user during registration , we don't want to forget the web server clients that are multi user.

On 2013-03-11, at 10:49 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:

FWIW, the closely related OpenID Connect client registration draft does have some support for doing this, which could maybe be borrowed. See client_name in §2 at http://openid.net/specs/openid-connect-registration-1_0-15.html#client-metadata and the examples.
 
   "client_name": "My Example",
   "client_name#ja-Jpan-JP":"クライアント名",



On Mon, Mar 11, 2013 at 5:15 PM, Richer, Justin P. <jricher@mitre.org> wrote:
It was brought up at the in-person meeting today that we'll want to consider issues around internationalization and localization of human-readable fields like client_name in the client registration. Which is to say: if a client supports ten languages and wants to present itself in ten languages, should it have to register itself ten times with an AS?

At the moment, I'm of the opinion a client with ten languages could register itself ten times, or do something with the context in which it runs to determine which human-facing language to use. Keep in mind that in some cases (such as native clients), you'll be dynamically registering a client for each user, in effect. In other words, I personally think that this is a rathole that will cause more harm than good.

 -- Justin
_______________________________________________
OAuth mailing 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




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


--------------080500090605050801040303-- From prateek.mishra@oracle.com Thu Mar 14 08:35: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 0686111E8223 for ; Thu, 14 Mar 2013 08:35:10 -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 AUwDuboYlBQT for ; Thu, 14 Mar 2013 08:35:09 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD3C11E8188 for ; Thu, 14 Mar 2013 08:35:09 -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 r2EFZ6l2015599 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 14 Mar 2013 15:35:07 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r2EFZ6uw026355 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Mar 2013 15:35:06 GMT Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r2EFZ6Nw009971; Thu, 14 Mar 2013 10:35:06 -0500 Received: from [130.129.23.121] (/130.129.23.121) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 14 Mar 2013 08:35:05 -0700 Message-ID: <5141EE22.2030306@oracle.com> Date: Thu, 14 Mar 2013 11:34:58 -0400 From: prateek mishra Organization: Oracle Corporation User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Hannes Tschofenig , "oauth@ietf.org" References: <1362079266.8952.YahooMailClassic@web141002.mail.bf1.yahoo.com> <512FCDF0.6010807@gmx.net> In-Reply-To: <512FCDF0.6010807@gmx.net> Content-Type: multipart/alternative; boundary="------------090501030807040707010408" X-Source-IP: acsinet21.oracle.com [141.146.126.237] Subject: [OAUTH-WG] comment on draft-tschofenig-auth-audience-00.txt (incorrect use of audience) X-BeenThere: oauth@ietf.org X-Mailman-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, 14 Mar 2013 15:35:16 -0000 This is a multi-part message in MIME format. --------------090501030807040707010408 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Hannes, I wanted to point out that use of the term "audience" in this document is not consistent with the SAML 2.0 specification. What you are referring to here as "audience" corresponds to which is described as [quote-saml2.0] Destination [Optional] A URI reference indicating the address to which this request has been sent. This is useful to prevent malicious forwarding of requests to unintended recipients, a protection that is required by some protocol bindings. If it is present, the actual recipient MUST check that the URI reference identifies the location at which the message was received. If it does not, the request MUST be discarded. Some protocol bindings may require the use of this attribute (see [SAMLBind]). [\quote] In contrast, is a means of /limiting the liability of the asserting party /and is described in the following manner - [quote-saml2.0] A URI reference that identifies an intended audience. The URI reference MAY identify a document that describes the terms and conditions of audience membership. It MAY also contain the unique identifier URI from a SAML name identifier that describes a system entity (see Section 8.3.6). The audience restriction condition evaluates to Valid if and only if the SAML relying party is a member of one or more of the audiences specified. The SAML asserting party cannot prevent a party to whom the assertion is disclosed from taking action on the basis of the information provided. However, the element allows the SAML asserting party to state explicitly that no warranty is provided to such a party in a machine- and human-readable form. While there can be no guarantee that a court would uphold such a warranty exclusion in every circumstance, the probability of upholding the warranty exclusion is considerably improved. [\quote] - prateek --------------090501030807040707010408 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Hannes,

I wanted to point out that use of the term "audience" in this document is not consistent with the SAML 2.0 specification.


What you are referring to here as "audience" corresponds to <saml:destination> which is described as

[quote-saml2.0]
Destination [Optional]
A URI reference indicating the address to which this request has been sent. This is useful to prevent
malicious forwarding of requests to unintended recipients, a protection that is required by some
protocol bindings. If it is present, the actual recipient MUST check that the URI reference identifies the
location at which the message was received. If it does not, the request MUST be discarded. Some
protocol bindings may require the use of this attribute (see [SAMLBind]).
[\quote]

In contrast, <saml:audience>  is a means of limiting the liability of the asserting party and is described
in the following manner -

[quote-saml2.0]
 <Audience>
A URI reference that identifies an intended audience. The URI reference MAY identify a document
that describes the terms and conditions of audience membership. It MAY also contain the unique
identifier URI from a SAML name identifier that describes a system entity (see Section 8.3.6).
The audience restriction condition evaluates to Valid if and only if the SAML relying party is a member of
one or more of the audiences specified.

The SAML asserting party cannot prevent a party to whom the assertion is disclosed from taking action on
the basis of the information provided. However, the <AudienceRestriction> element allows the
SAML asserting party to state explicitly that no warranty is provided to such a party in a machine- and
human-readable form. While there can be no guarantee that a court would uphold such a warranty
exclusion in every circumstance, the probability of upholding the warranty exclusion is considerably
improved.
[\quote]

- prateek


--------------090501030807040707010408-- From Michael.Jones@microsoft.com Thu Mar 14 08:47:32 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 C0A7111E818D for ; Thu, 14 Mar 2013 08:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.402 X-Spam-Level: ** X-Spam-Status: No, score=2.402 tagged_above=-999 required=5 tests=[AWL=5.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 9xBBU5ZRvpMQ for ; Thu, 14 Mar 2013 08:47:25 -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 0148111E81C9 for ; Thu, 14 Mar 2013 08:47:21 -0700 (PDT) Received: from BL2FFO11FD001.protection.gbl (10.173.161.200) by BL2FFO11HUB011.protection.gbl (10.173.161.117) with Microsoft SMTP Server (TLS) id 15.0.641.9; Thu, 14 Mar 2013 15:43:09 +0000 Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD001.mail.protection.outlook.com (10.173.160.101) with Microsoft SMTP Server (TLS) id 15.0.641.9 via Frontend Transport; Thu, 14 Mar 2013 15:43:09 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.132]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.02.0318.003; Thu, 14 Mar 2013 15:42:54 +0000 From: Mike Jones To: Justin Richer , George Fletcher Thread-Topic: [OAUTH-WG] Registration: Internationalization of Human-Readable names Thread-Index: AQHOH/ZlY5HOQV9nDkW4sYSziV3/rJilRaYAgAAEOYCAAAfTkA== Date: Thu, 14 Mar 2013 15:42:54 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436750F5E2@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <1B4C0C9F-4B8E-4B2D-BAF7-665D3EBBE56C@ve7jtb.com> <51408B8B.9000800@mitre.org> <5141E2E6.9020701@aol.com> <5141E671.2050708@mitre.org> In-Reply-To: <5141E671.2050708@mitre.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.34] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436750F5E2TK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(51444002)(377424002)(377454001)(164054002)(55885001)(479174001)(24454001)(199002)(189002)(46102001)(59766001)(512904001)(54316002)(20776003)(5343645001)(31966008)(5343635001)(5343655001)(53806001)(77982001)(55846006)(79102001)(15202345001)(15395725002)(16236675001)(80022001)(74662001)(47446002)(76482001)(16297215001)(49866001)(4396001)(44976002)(56776001)(54356001)(63696002)(74502001)(50986001)(47976001)(47736001)(66066001)(56816002)(16406001)(65816001)(69226001)(51856001)(33656001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB011; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0785459C39 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readable names X-BeenThere: oauth@ietf.org X-Mailman-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, 14 Mar 2013 15:47:33 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436750F5E2TK5EX14MBXC283r_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable I agree that having unadorned values likely simplifies things in many cases= , but if we do this, we should let the Client say what language/script it= =1B$B!G=1B(Bs using when providing human-readable strings or references to = them as registration parameters. For this purpose, I=1B$B!G=1B(Bd propose = that we have a parameter something like this one: registration_locale OPTIONAL or REQURED. Language and script used for human-readable values or = references to human-readable values that are supplied without language/scri= pt tags, represented as a BCP47[RFC5646] language tag value. This paramete= r is REQUIRED if any human-readable values or references to human-readable = are provided without language/script tags. -- Mike From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of J= ustin Richer Sent: Thursday, March 14, 2013 8:02 AM To: George Fletcher Cc: oauth@ietf.org WG Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readabl= e names On the surface this does simplify things, but the issue I forsee with it is= that I want to be able to call "client.getClientName()" and always get *so= mething* out of it if there are *any* client_name fields at all. So in this= world if I take a client library that assumes en-us and it talks to a serv= er that only looks for es-cl, there's a very real chance of the client name= not getting set at all. I think that's a problem. This is why I think the default field name (without the language tag) reall= y should be required and should be left undefined as to what language and s= cript it is. Essentially, "It's a UTF8 String, hope for the best". If you w= ant something more specific and smart about localization, then you can supp= ort the language tags. If you just want to have a string to store and throw= at the user, then you can just use the bare field name. In other words, we take what we have now (which works for a non-internation= alized case where everyone just assumes a common language/script), and we a= ugment it with features that let it be smarter if you want it to be smarter= . Make the simple case simple, make the complicated case possible. -- Justin On 03/14/2013 10:47 AM, George Fletcher wrote: As a simplifying option... why not just require human-readable fields to re= quire a "script-tag". This way it is always explicit what language/locale t= he text is for. It then becomes the responsibility of the AS to return an a= ppropriate response if there is not a direct match between a request and th= e data stored at the AS (and out of scope of the spec). Thanks, George On 3/13/13 10:22 AM, Justin Richer wrote: So with what little feedback I've gotten, I'm proposing to add text from th= e proposed webfinger and OIDC drafts for the hash-based localization of str= ings, with the following properties: * All localized versions of fields are fully optional on both client and se= rver * If a localized version of a field is included, its bare-value (perhaps in= ternationalized) field MUST be included * All human-readable fields are eligible for this mechanism (including any = uri's for user-facing web pages, which can be used to point to language-spe= cific pages) * Clients and servers can decide to use whatever language/script they want = to for the bare-value field, and no assumptions can be made on either side = about what that is I think that with these constraints, we can add functionality to address St= ephen's concerns without getting too complicated or putting too much burden= of support. -- Justin On 03/11/2013 06:52 PM, Nat Sakimura wrote: Similar work is in progress at Webfinger. See: http://www.ietf.org/mail-archive/web/webfinger/current/msg00530.html Paul is proposing the same syntax as Connect. 2013/3/12 Richer, Justin P. > It does presume a definition of "claim", which I suppose we could turn to "= metadata field" for DynReg and its extensions to be appropriately limiting.= But we also need a good definition of what a language-tag-less field means= , and whether or not it's required if the other fields are present or not (= which is something that Connect is trying to fix at the moment, as I recall= from last week). So it turns into about a paragraph worth of text. Is that worth it? I'm not= entirely convinced that it is, but I'm interested to hear what others thin= k, particularly those who *aren't* tied into the OpenID Connect protocol so= much. (I don't want to pick a solution just because it's familiar, if we n= eed a solution at all.) -- Justin On Mar 11, 2013, at 6:35 PM, Brian Campbell > wrote: A fair question but what would need to be pulled in is really probably only= a couple sentences (and reference) from http://openid.net/specs/openid-con= nect-messages-1_0-16.html#ClaimsLanguagesAndScripts (note the reference to = 2.1.1.1.3 inside http://openid.net/specs/openid-connect-registration-1_0-15= .html is broken) On Mon, Mar 11, 2013 at 6:26 PM, Richer, Justin P. > wrote: My concern with this is that OIDC can get away with defining this multi-lan= guage structure because it defines the mechanism once (in Messages) and app= lies it to all user-readable strings throughout the whole application proto= col, of which there are several. Do we really want to pull in that whole st= ructure and mechanism for one field in client registration? I really don't = think it should be something that's defined completely inside of DynReg for= a corner case for a single field, but I also doubt we want to normatively = point to OIDC Messages for this solution either. There are also other ways to do this: Webfinger [1] for instance uses JSON = structures to give language tags to field values, and has a default mechani= sm: { "en_us": "my client", =1B$B!D=1B(B } The fundamental question is this: should a client be able to register mult= iple names (in different locales) with a single client_id, or should it get= a different client_id for each display language set? -- Justin [1] http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-11 On Mar 11, 2013, at 5:54 PM, John Bradley > wrote: That is what I was thinking. It would be up to the AS to determine what l= anguage and script to present based on the user preference. While a large number of clients will be native and might be able to customi= ze themselves for a single user during registration , we don't want to forg= et the web server clients that are multi user. On 2013-03-11, at 10:49 PM, Brian Campbell > wrote: FWIW, the closely related OpenID Connect client registration draft does hav= e some support for doing this, which could maybe be borrowed. See client_na= me in =1B$B!x=1B(B2 at http://openid.net/specs/openid-connect-registration-= 1_0-15.html#client-metadata and the examples. "client_name": "My Example", "client_name#ja-Jpan-JP":"=1B$B%/%i%$%"%s%HL>=1B(B", On Mon, Mar 11, 2013 at 5:15 PM, Richer, Justin P. > wrote: It was brought up at the in-person meeting today that we'll want to conside= r issues around internationalization and localization of human-readable fie= lds like client_name in the client registration. Which is to say: if a clie= nt supports ten languages and wants to present itself in ten languages, sho= uld it have to register itself ten times with an AS? At the moment, I'm of the opinion a client with ten languages could registe= r itself ten times, or do something with the context in which it runs to de= termine which human-facing language to use. Keep in mind that in some cases= (such as native clients), you'll be dynamically registering a client for e= ach user, in effect. In other words, I personally think that this is a rath= ole that will cause more harm than good. -- Justin _______________________________________________ OAuth mailing 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 -- Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_4E1F6AAD24975D4BA5B16804296739436750F5E2TK5EX14MBXC283r_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable

I agree that having unado= rned values likely simplifies things in many cases, but if we do this, we s= hould let the Client say what language/script it=1B$B!G=1B(Bs using when providing human-readable strings or references to them as registratio= n parameters.  For this purpose, I=1B$B!G=1B(Bd propose that we have a= parameter something like this one:

 <= /p>

registration_locale

OPTIONAL or REQ= URED. Language and script used for human-readable values or references to h= uman-readable values that are supplied without language/script tags, represented as a BCP47[RFC5646] language tag value.  This param= eter is REQUIRED if any human-readable values or references to human-readab= le are provided without language/script tags.

 <= /p>

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

 <= /p>

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf= .org] On Behalf Of Justin Richer
Sent: Thursday, March 14, 2013 8:02 AM
To: George Fletcher
Cc: oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-= Readable names

 

On the surface this does simplify things, but the is= sue I forsee with it is that I want to be able to call "client.getClie= ntName()" and always get *something* out of it if there are *any* clie= nt_name fields at all. So in this world if I take a client library that assumes en-us and it talks to a server that onl= y looks for es-cl, there's a very real chance of the client name not gettin= g set at all. I think that's a problem.

This is why I think the default field name (without the language tag) reall= y should be required and should be left undefined as to what language and s= cript it is. Essentially, "It's a UTF8 String, hope for the best"= . If you want something more specific and smart about localization, then you can support the language tags. If you j= ust want to have a string to store and throw at the user, then you can just= use the bare field name.

In other words, we take what we have now (which works for a non-internation= alized case where everyone just assumes a common language/script), and we a= ugment it with features that let it be smarter if you want it to be smarter= . Make the simple case simple, make the complicated case possible.

 -- Justin

 

On 03/14/2013 10:47 AM, George Fletcher wrote:<= /o:p>

As a simplifying option= ... why not just require human-readable fields to require a "script-ta= g". This way it is always explicit what language/locale the text is for. It then becomes the responsibility of the AS to return an appropri= ate response if there is not a direct match between a request and the data = stored at the AS (and out of scope of the spec).

Thanks,
George

On 3/13/13 10:22 AM, Justin Richer wrote:=

So with what little f= eedback I've gotten, I'm proposing to add text from the proposed webfinger = and OIDC drafts for the hash-based localization of strings, with the follow= ing properties:

* All localized versions of fields are fully optional on both client and se= rver
* If a localized version of a field is included, its bare-value (perhaps in= ternationalized) field MUST be included
* All human-readable fields are eligible for this mechanism (including any = uri's for user-facing web pages, which can be used to point to language-spe= cific pages)
* Clients and servers can decide to use whatever language/script they want = to for the bare-value field, and no assumptions can be made on either side = about what that is

I think that with these constraints, we can add functionality to address St= ephen's concerns without getting too complicated or putting too much burden= of support.

 -- Justin

On 03/11/2013 06:52 PM, Nat Sakimura wrote:

Similar work is in progress at Webfinger. 

 

 

Paul is proposing the= same syntax as Connect. 

2013/3/12 Richer, Justin P. <jricher@mitre.org>

It does presume a definition of "claim", w= hich I suppose we could turn to "metadata field" for DynReg and i= ts extensions to be appropriately limiting. But we also need a good definit= ion of what a language-tag-less field means, and whether or not it's required if the other fields are present or not (which is some= thing that Connect is trying to fix at the moment, as I recall from last we= ek). 

 

So it turns into about a paragraph worth of text. Is= that worth it? I'm not entirely convinced that it is, but I'm interested t= o hear what others think, particularly those who *aren't* tied into the Ope= nID Connect protocol so much. (I don't want to pick a solution just because it's familiar, if we need a solution = at all.)

 

 -- Justin

 

On Mar 11, 2013, at 6:35 PM, Brian Campbell <bcampbell@pingi= dentity.com>

 wrote:



A fair question but what would need to be pulled in = is really probably only a couple sentences (and reference) from http://openid.net/specs/openid-connect-messages-1_0-16.html#ClaimsLanguages= AndScripts (note the reference to 2.1.1.1.3 inside http://openid.net/specs/openid-connect-registration-1_0-15.html is brok= en)

 

On Mon, Mar 11, 2013 at 6:26 PM, Richer, Justin P. &= lt;jricher@mitre.org= > wrote:

My concern with this is that OIDC can get away with = defining this multi-language structure because it defines the mechanism onc= e (in Messages) and applies it to all user-readable strings throughout the = whole application protocol, of which there are several. Do we really want to pull in that whole structure and m= echanism for one field in client registration? I really don't think it shou= ld be something that's defined completely inside of DynReg for a corner cas= e for a single field, but I also doubt we want to normatively point to OIDC Messages for this solution eith= er.

 

There are also other ways to do this: Webfinger [1] = for instance uses JSON structures to give language tags to field values, an= d has a default mechanism:

 

   { "en_us": "my client&qu= ot;, =1B$B!D=1B(B }

 

The fundamental question is  this: should a cli= ent be able to register multiple names (in different locales) with a single= client_id, or should it get a different client_id for each display languag= e set?

 

 -- Justin

 

 

On Mar 11, 2013, at 5:54 PM, John Bradley <ve7jtb@ve7jtb.com><= o:p>

 wrote:



That is what I was thinking.   It would be up t= o the AS to determine what language and script to present based on the user= preference.

 

While a large number of clients will be native and m= ight be able to customize themselves for a single user during registration = , we don't want to forget the web server clients that are multi user.<= /o:p>

 

On 2013-03-11, at 10:49 PM, Brian Campbell <bcampbell@pingid= entity.com> wrote:



FWIW, the closely related OpenID Connect client regi= stration draft does have some support for doing this, which could maybe be = borrowed. See client_name in =1B$B!x=1B(B2 at http://openid.net/specs/openid-connect-registration-1_0-15.html#client-meta= data and the examples.
 

   "client_name": "My Example",
   "client_name#ja-Jpan-JP":"=1B$B%/%i%$%"%s%HL>=1B(B",

 

 

On Mon, Mar 11, 2013 at 5:15 PM, Richer, Justin P. &= lt;jricher@mitre.org= > wrote:

It was brought up at the in-person meeting today tha= t we'll want to consider issues around internationalization and localizatio= n of human-readable fields like client_name in the client registration. Whi= ch is to say: if a client supports ten languages and wants to present itself in ten languages, should it have= to register itself ten times with an AS?

At the moment, I'm of the opinion a client with ten languages could registe= r itself ten times, or do something with the context in which it runs to de= termine which human-facing language to use. Keep in mind that in some cases= (such as native clients), you'll be dynamically registering a client for each user, in effect. In other wor= ds, I personally think that this is a rathole that will cause more harm tha= n good.

 -- Justin
_______________________________________________
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

 

 

 

 


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



 

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.= org/
@_nat_en





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

 

 

--_000_4E1F6AAD24975D4BA5B16804296739436750F5E2TK5EX14MBXC283r_-- From hannes.tschofenig@gmx.net Thu Mar 14 08:51: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 7F49711E810D for ; Thu, 14 Mar 2013 08:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[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 pK4m8az8s08M for ; Thu, 14 Mar 2013 08:51:47 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id A781A21F90C7 for ; Thu, 14 Mar 2013 08:51:46 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.19]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MCNfL-1UOeu03rYf-00958y for ; Thu, 14 Mar 2013 16:51:45 +0100 Received: (qmail invoked by alias); 14 Mar 2013 15:51:45 -0000 Received: from dhcp-1077.meeting.ietf.org (EHLO dhcp-1077.meeting.ietf.org) [130.129.16.119] by mail.gmx.net (mp019) with SMTP; 14 Mar 2013 16:51:45 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+1IrEv5Mm1OqZZUAP2PsB4CbHK9BOn1taF3S1mK0 mz9zSyth6v3u2A Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <5141EE22.2030306@oracle.com> Date: Thu, 14 Mar 2013 11:51:42 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1362079266.8952.YahooMailClassic@web141002.mail.bf1.yahoo.com> <512FCDF0.6010807@gmx.net> <5141EE22.2030306@oracle.com> To: prateek mishra X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] comment on draft-tschofenig-auth-audience-00.txt (incorrect use of audience) X-BeenThere: oauth@ietf.org X-Mailman-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, 14 Mar 2013 15:51:47 -0000 Hi Prateek,=20 I never had planned to make the term audience to align with the SAML = specification.=20 However, in case this could lead to confusion we could also define a = different term.=20 Btw, did you look at the JWT spec whether the audience term there is = inline with the SAML spec? Ciao Hannes On Mar 14, 2013, at 11:34 AM, prateek mishra wrote: > Hi Hannes, >=20 > I wanted to point out that use of the term "audience" in this document = is not consistent with the SAML 2.0 specification. >=20 >=20 > What you are referring to here as "audience" corresponds to = which is described as=20 >=20 > [quote-saml2.0] > Destination [Optional] > A URI reference indicating the address to which this request has been = sent. This is useful to prevent > malicious forwarding of requests to unintended recipients, a = protection that is required by some > protocol bindings. If it is present, the actual recipient MUST check = that the URI reference identifies the > location at which the message was received. If it does not, the = request MUST be discarded. Some > protocol bindings may require the use of this attribute (see = [SAMLBind]). > [\quote] >=20 > In contrast, is a means of limiting the liability of = the asserting party and is described > in the following manner -=20 >=20 > [quote-saml2.0] > > A URI reference that identifies an intended audience. The URI = reference MAY identify a document > that describes the terms and conditions of audience membership. It MAY = also contain the unique > identifier URI from a SAML name identifier that describes a system = entity (see Section 8.3.6). > The audience restriction condition evaluates to Valid if and only if = the SAML relying party is a member of > one or more of the audiences specified. >=20 > The SAML asserting party cannot prevent a party to whom the assertion = is disclosed from taking action on > the basis of the information provided. However, the = element allows the > SAML asserting party to state explicitly that no warranty is provided = to such a party in a machine- and > human-readable form. While there can be no guarantee that a court = would uphold such a warranty > exclusion in every circumstance, the probability of upholding the = warranty exclusion is considerably > improved. > [\quote] >=20 > - prateek >=20 >=20 From prateek.mishra@oracle.com Thu Mar 14 11:53:32 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 A6F9221F8E95 for ; Thu, 14 Mar 2013 11:53: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 twi0k71ZY1oN for ; Thu, 14 Mar 2013 11:53:31 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id B2AC621F8E99 for ; Thu, 14 Mar 2013 11:53:31 -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 r2EIrSDu013028 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 14 Mar 2013 18:53:29 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r2EIrRFb023106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Mar 2013 18:53:28 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r2EIrRON019740; Thu, 14 Mar 2013 13:53:27 -0500 Received: from [130.129.23.121] (/130.129.23.121) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 14 Mar 2013 11:53:27 -0700 Message-ID: <51421CA0.7010400@oracle.com> Date: Thu, 14 Mar 2013 14:53:20 -0400 From: prateek mishra Organization: Oracle Corporation User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Hannes Tschofenig , Michael.Jones@microsoft.com References: <1362079266.8952.YahooMailClassic@web141002.mail.bf1.yahoo.com> <512FCDF0.6010807@gmx.net> <5141EE22.2030306@oracle.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "oauth@ietf.org" Subject: [OAUTH-WG] the meaning of audience in SAML vs. OAuth X-BeenThere: oauth@ietf.org X-Mailman-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, 14 Mar 2013 18:53:32 -0000 Hannes - you make a good point. I believe that the usage of "audience" in http://www.ietf.org/id/draft-ietf-oauth-json-web-token-06.txt also corresponds to rather than . [quote-jwt06] The aud (audience) claim identifies the audiences that the JWT is intended for. Each principal intended to process the JWT MUST identify itself with a value in audience claim. If the principal processing the claim does not identify itself with a value in the aud claim, then the JWT MUST be rejected. In the general case, the aud value is an array of case sensitive strings, each containing a StringOrURI value. In the special case when the JWT has one audience, the aud value MAY be a single case sensitive string containing a StringOrURI value. The interpretation of audience values is generally application specific. Use of this claim is OPTIONAL. [\quote] I think this is a point of quite some confusion (a similar problem arose during the SAML assertion drafts discussion on Tuesday). To the extent that JWT re-uses concepts and names from SAML, I dont think this is the correct name with the semantics implied by the processing rules given in jwt06. - prateek > Hi Prateek, > > I never had planned to make the term audience to align with the SAML specification. > However, in case this could lead to confusion we could also define a different term. > > Btw, did you look at the JWT spec whether the audience term there is inline with the SAML spec? > > Ciao > Hannes > > On Mar 14, 2013, at 11:34 AM, prateek mishra wrote: > >> Hi Hannes, >> >> I wanted to point out that use of the term "audience" in this document is not consistent with the SAML 2.0 specification. >> >> >> What you are referring to here as "audience" corresponds to which is described as >> >> [quote-saml2.0] >> Destination [Optional] >> A URI reference indicating the address to which this request has been sent. This is useful to prevent >> malicious forwarding of requests to unintended recipients, a protection that is required by some >> protocol bindings. If it is present, the actual recipient MUST check that the URI reference identifies the >> location at which the message was received. If it does not, the request MUST be discarded. Some >> protocol bindings may require the use of this attribute (see [SAMLBind]). >> [\quote] >> >> In contrast, is a means of limiting the liability of the asserting party and is described >> in the following manner - >> >> [quote-saml2.0] >> >> A URI reference that identifies an intended audience. The URI reference MAY identify a document >> that describes the terms and conditions of audience membership. It MAY also contain the unique >> identifier URI from a SAML name identifier that describes a system entity (see Section 8.3.6). >> The audience restriction condition evaluates to Valid if and only if the SAML relying party is a member of >> one or more of the audiences specified. >> >> The SAML asserting party cannot prevent a party to whom the assertion is disclosed from taking action on >> the basis of the information provided. However, the element allows the >> SAML asserting party to state explicitly that no warranty is provided to such a party in a machine- and >> human-readable form. While there can be no guarantee that a court would uphold such a warranty >> exclusion in every circumstance, the probability of upholding the warranty exclusion is considerably >> improved. >> [\quote] >> >> - prateek >> >> From Michael.Jones@microsoft.com Thu Mar 14 11:57: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 BB84B21F8E95 for ; Thu, 14 Mar 2013 11:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.274 X-Spam-Level: X-Spam-Status: No, score=-1.274 tagged_above=-999 required=5 tests=[AWL=1.325, 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 k6CUATOYPG15 for ; Thu, 14 Mar 2013 11:57:25 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0236.outbound.protection.outlook.com [207.46.163.236]) by ietfa.amsl.com (Postfix) with ESMTP id 0833D21F8CF4 for ; Thu, 14 Mar 2013 11:57:24 -0700 (PDT) Received: from BY2FFO11FD027.protection.gbl (10.1.15.201) by BY2FFO11HUB031.protection.gbl (10.1.14.116) with Microsoft SMTP Server (TLS) id 15.0.620.12; Thu, 14 Mar 2013 18:57:22 +0000 Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD027.mail.protection.outlook.com (10.1.15.216) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Thu, 14 Mar 2013 18:57:22 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.132]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0318.003; Thu, 14 Mar 2013 18:56:47 +0000 From: Mike Jones To: prateek mishra , Hannes Tschofenig Thread-Topic: the meaning of audience in SAML vs. OAuth Thread-Index: AQHOIOU/KjjTc25PPUqM2lCcj10XjJiliUdQ Date: Thu, 14 Mar 2013 18:56:46 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943675115B6@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <1362079266.8952.YahooMailClassic@web141002.mail.bf1.yahoo.com> <512FCDF0.6010807@gmx.net> <5141EE22.2030306@oracle.com> <51421CA0.7010400@oracle.com> In-Reply-To: <51421CA0.7010400@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(24454001)(377454001)(189002)(51704002)(13464002)(65816001)(54356001)(4396001)(56816002)(33656001)(69226001)(47736001)(50466001)(31966008)(66066001)(53806001)(77982001)(46102001)(79102001)(50986001)(51856001)(56776001)(74502001)(47446002)(80022001)(46406002)(20776003)(47776003)(15202345001)(74662001)(76482001)(59766001)(23726001)(47976001)(63696002)(16406001)(5343655001)(55846006)(49866001)(44976002)(54316002)(550254004); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB031; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0785459C39 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] the meaning of audience in SAML vs. OAuth X-BeenThere: oauth@ietf.org X-Mailman-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, 14 Mar 2013 18:57:25 -0000 The JWT meaning of the term "audience" is intended to be the same as SAML. = Suggested wording clarifications would be welcomed. -- Mike -----Original Message----- From: prateek mishra [mailto:prateek.mishra@oracle.com]=20 Sent: Thursday, March 14, 2013 11:53 AM To: Hannes Tschofenig; Mike Jones Cc: oauth@ietf.org Subject: the meaning of audience in SAML vs. OAuth Hannes - you make a good point. I believe that the usage of "audience" in http://www.ietf.org/id/draft-ietf= -oauth-json-web-token-06.txt also corresponds to rather than . [quote-jwt06] The aud (audience) claim identifies the audiences that the JWT is intended = for. Each principal intended to process the JWT MUST identify itself with a= value in audience claim. If the principal processing the claim does not id= entify itself with a value in the aud claim, then the JWT MUST be rejected.= In the general case, the aud value is an array of case sensitive strings, = each containing a StringOrURI value. In the special case when the JWT has o= ne audience, the aud value MAY be a single case sensitive string containing= a StringOrURI value. The interpretation of audience values is generally ap= plication specific. Use of this claim is OPTIONAL. [\quote] I think this is a point of quite some confusion (a similar problem arose du= ring the SAML assertion drafts discussion on Tuesday). To the extent that JWT re-uses concepts and names from SAML, I dont think t= his is the correct name with the semantics implied by the processing rules = given in jwt06. - prateek > Hi Prateek, > > I never had planned to make the term audience to align with the SAML spec= ification. > However, in case this could lead to confusion we could also define a diff= erent term. > > Btw, did you look at the JWT spec whether the audience term there is inli= ne with the SAML spec? > > Ciao > Hannes > > On Mar 14, 2013, at 11:34 AM, prateek mishra wrote: > >> Hi Hannes, >> >> I wanted to point out that use of the term "audience" in this document i= s not consistent with the SAML 2.0 specification. >> >> >> What you are referring to here as "audience" corresponds to=20 >> which is described as >> >> [quote-saml2.0] >> Destination [Optional] >> A URI reference indicating the address to which this request has been=20 >> sent. This is useful to prevent malicious forwarding of requests to=20 >> unintended recipients, a protection that is required by some protocol=20 >> bindings. If it is present, the actual recipient MUST check that the=20 >> URI reference identifies the location at which the message was received.= If it does not, the request MUST be discarded. Some protocol bindings may = require the use of this attribute (see [SAMLBind]). >> [\quote] >> >> In contrast, is a means of limiting the liability of=20 >> the asserting party and is described in the following manner - >> >> [quote-saml2.0] >> >> A URI reference that identifies an intended audience. The URI=20 >> reference MAY identify a document that describes the terms and=20 >> conditions of audience membership. It MAY also contain the unique identi= fier URI from a SAML name identifier that describes a system entity (see Se= ction 8.3.6). >> The audience restriction condition evaluates to Valid if and only if=20 >> the SAML relying party is a member of one or more of the audiences speci= fied. >> >> The SAML asserting party cannot prevent a party to whom the assertion=20 >> is disclosed from taking action on the basis of the information=20 >> provided. However, the element allows the SAML=20 >> asserting party to state explicitly that no warranty is provided to=20 >> such a party in a machine- and human-readable form. While there can=20 >> be no guarantee that a court would uphold such a warranty exclusion in e= very circumstance, the probability of upholding the warranty exclusion is c= onsiderably improved. >> [\quote] >> >> - prateek >> >> From sakimura@gmail.com Thu Mar 14 13:12:52 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 B90BE11E815E for ; Thu, 14 Mar 2013 13:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_48=0.6, 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 eWYxZXYnhXDj for ; Thu, 14 Mar 2013 13:12:39 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 7037A11E8133 for ; Thu, 14 Mar 2013 13:12:38 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id ek20so2943513lab.2 for ; Thu, 14 Mar 2013 13:12:37 -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:content-transfer-encoding; bh=TTYp24dV5ijUFRiSb9LpPxkQ1Hq2giHae9H4hJ0nZWo=; b=RF3byyM0rbpVacYG+RbgLLt2/fIEiUpQrqZ92q4k+5rAyNrzhRHtc/nysS717xt4as Mvx4z1sc3D87TmjaX83onwljs9/f+hCzjGB4CGClpjcKvFf8SEifWLEPF0C7Wfp+Kiij xSblEnmTwxjOhhKjIvpiCBtTUXwluwiP4gQsUr5sZrH0TvQcn01AjylV1wpJ9ycny/N2 5S6IROp16XRSjKnGjESyihCZs9U/shY8nZyps13And84tM7fGu1UFmLsIHjRkNuy1i8t pF7QW3bk4KrmWZmaQWudDnIMeJgYW/wlQt+Q2Gb+SeDgcjGgfDre6EyGqAdgcLm1EDJ2 IZGA== MIME-Version: 1.0 X-Received: by 10.112.49.99 with SMTP id t3mr1651457lbn.108.1363291957122; Thu, 14 Mar 2013 13:12:37 -0700 (PDT) Received: by 10.112.103.202 with HTTP; Thu, 14 Mar 2013 13:12:37 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943675115B6@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <1362079266.8952.YahooMailClassic@web141002.mail.bf1.yahoo.com> <512FCDF0.6010807@gmx.net> <5141EE22.2030306@oracle.com> <51421CA0.7010400@oracle.com> <4E1F6AAD24975D4BA5B1680429673943675115B6@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Fri, 15 Mar 2013 05:12:37 +0900 Message-ID: From: Nat Sakimura To: Mike Jones Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] the meaning of audience in SAML vs. OAuth X-BeenThere: oauth@ietf.org X-Mailman-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, 14 Mar 2013 20:12:53 -0000 well.. the aud term came from googler's use of the term and not saml. I agree with Prateek that the intention of the jwt:aud is rather similar to saml:destination. JWT is imposing the processing rule on it while saml:audience is mainly concerned about the liability. Nat 2013/3/15 Mike Jones : > The JWT meaning of the term "audience" is intended to be the same as SAML= . Suggested wording clarifications would be welcomed. > > -- Mike > > -----Original Message----- > From: prateek mishra [mailto:prateek.mishra@oracle.com] > Sent: Thursday, March 14, 2013 11:53 AM > To: Hannes Tschofenig; Mike Jones > Cc: oauth@ietf.org > Subject: the meaning of audience in SAML vs. OAuth > > Hannes - you make a good point. > > I believe that the usage of "audience" in http://www.ietf.org/id/draft-ie= tf-oauth-json-web-token-06.txt > > also corresponds to rather than . > > [quote-jwt06] > The aud (audience) claim identifies the audiences that the JWT is intende= d for. Each principal intended to process the JWT MUST identify itself with= a value in audience claim. If the principal processing the claim does not = identify itself with a value in the aud claim, then the JWT MUST be rejecte= d. In the general case, the aud value is an array of case sensitive strings= , each containing a StringOrURI value. In the special case when the JWT has= one audience, the aud value MAY be a single case sensitive string containi= ng a StringOrURI value. The interpretation of audience values is generally = application specific. Use of this claim is OPTIONAL. > [\quote] > > I think this is a point of quite some confusion (a similar problem arose = during the SAML assertion drafts discussion on Tuesday). > > To the extent that JWT re-uses concepts and names from SAML, I dont think= this is the correct name with the semantics implied by the processing rule= s given in jwt06. > > - prateek > > > > > >> Hi Prateek, >> >> I never had planned to make the term audience to align with the SAML spe= cification. >> However, in case this could lead to confusion we could also define a dif= ferent term. >> >> Btw, did you look at the JWT spec whether the audience term there is inl= ine with the SAML spec? >> >> Ciao >> Hannes >> >> On Mar 14, 2013, at 11:34 AM, prateek mishra wrote: >> >>> Hi Hannes, >>> >>> I wanted to point out that use of the term "audience" in this document = is not consistent with the SAML 2.0 specification. >>> >>> >>> What you are referring to here as "audience" corresponds to >>> which is described as >>> >>> [quote-saml2.0] >>> Destination [Optional] >>> A URI reference indicating the address to which this request has been >>> sent. This is useful to prevent malicious forwarding of requests to >>> unintended recipients, a protection that is required by some protocol >>> bindings. If it is present, the actual recipient MUST check that the >>> URI reference identifies the location at which the message was received= . If it does not, the request MUST be discarded. Some protocol bindings may= require the use of this attribute (see [SAMLBind]). >>> [\quote] >>> >>> In contrast, is a means of limiting the liability of >>> the asserting party and is described in the following manner - >>> >>> [quote-saml2.0] >>> >>> A URI reference that identifies an intended audience. The URI >>> reference MAY identify a document that describes the terms and >>> conditions of audience membership. It MAY also contain the unique ident= ifier URI from a SAML name identifier that describes a system entity (see S= ection 8.3.6). >>> The audience restriction condition evaluates to Valid if and only if >>> the SAML relying party is a member of one or more of the audiences spec= ified. >>> >>> The SAML asserting party cannot prevent a party to whom the assertion >>> is disclosed from taking action on the basis of the information >>> provided. However, the element allows the SAML >>> asserting party to state explicitly that no warranty is provided to >>> such a party in a machine- and human-readable form. While there can >>> be no guarantee that a court would uphold such a warranty exclusion in = every circumstance, the probability of upholding the warranty exclusion is = considerably improved. >>> [\quote] >>> >>> - prateek >>> >>> > > _______________________________________________ > 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 From Adam.Lewis@motorolasolutions.com Thu Mar 14 14:26: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 88B5511E80E7 for ; Thu, 14 Mar 2013 14:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.466 X-Spam-Level: X-Spam-Status: No, score=-0.466 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 wEgEkK+RYSQR for ; Thu, 14 Mar 2013 14:26:45 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe010.messaging.microsoft.com [216.32.180.30]) by ietfa.amsl.com (Postfix) with ESMTP id 1F1F211E80A5 for ; Thu, 14 Mar 2013 14:26:44 -0700 (PDT) Received: from mail223-va3-R.bigfish.com (10.7.14.241) by VA3EHSOBE010.bigfish.com (10.7.40.12) with Microsoft SMTP Server id 14.1.225.23; Thu, 14 Mar 2013 21:26:44 +0000 Received: from mail223-va3 (localhost [127.0.0.1]) by mail223-va3-R.bigfish.com (Postfix) with ESMTP id 28607B002E6 for ; Thu, 14 Mar 2013 21:26:44 +0000 (UTC) X-Forefront-Antispam-Report: CIP:192.160.210.14; KIP:(null); UIP:(null); IPV:NLI; H:ct11msg02.am.mot-solutions.com; RD:ct11msg02.mot-solutions.com; EFVD:NLI X-SpamScore: -21 X-BigFish: VPS-21(zz9371Ic85fhzz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahz97hz1033IL17326ah8275dh18c673h8275bhz2fh2a8h683h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1b0ah1155h) Received-SPF: pass (mail223-va3: domain of motorolasolutions.com designates 192.160.210.14 as permitted sender) client-ip=192.160.210.14; envelope-from=Adam.Lewis@motorolasolutions.com; helo=ct11msg02.am.mot-solutions.com ; olutions.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.237.133; KIP:(null); UIP:(null); (null); H:BY2PRD0411HT005.namprd04.prod.outlook.com; R:internal; EFV:INT Received: from mail223-va3 (localhost.localdomain [127.0.0.1]) by mail223-va3 (MessageSwitch) id 1363296401203377_21415; Thu, 14 Mar 2013 21:26:41 +0000 (UTC) Received: from VA3EHSMHS004.bigfish.com (unknown [10.7.14.234]) by mail223-va3.bigfish.com (Postfix) with ESMTP id 2F3EA18004F for ; Thu, 14 Mar 2013 21:26:41 +0000 (UTC) Received: from ct11msg02.am.mot-solutions.com (192.160.210.14) by VA3EHSMHS004.bigfish.com (10.7.99.14) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 14 Mar 2013 21:26:41 +0000 Received: from ct11msg02.am.mot-solutions.com (ct11vts02.am.mot.com [10.177.16.160]) by ct11msg02.am.mot-solutions.com (8.14.3/8.14.3) with ESMTP id r2ELQrZ5006871 for ; Thu, 14 Mar 2013 17:26:53 -0400 (EDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe002.messaging.microsoft.com [216.32.180.12]) by ct11msg02.am.mot-solutions.com (8.14.3/8.14.3) with ESMTP id r2ELQrEc006867 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 14 Mar 2013 17:26:53 -0400 (EDT) Received: from mail208-va3-R.bigfish.com (10.7.14.254) by VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id 14.1.225.23; Thu, 14 Mar 2013 21:26:39 +0000 Received: from mail208-va3 (localhost [127.0.0.1]) by mail208-va3-R.bigfish.com (Postfix) with ESMTP id CD1DA7209E9 for ; Thu, 14 Mar 2013 21:26:39 +0000 (UTC) Received: from mail208-va3 (localhost.localdomain [127.0.0.1]) by mail208-va3 (MessageSwitch) id 1363296397879093_7160; Thu, 14 Mar 2013 21:26:37 +0000 (UTC) Received: from VA3EHSMHS007.bigfish.com (unknown [10.7.14.226]) by mail208-va3.bigfish.com (Postfix) with ESMTP id C875ED400F0; Thu, 14 Mar 2013 21:26:37 +0000 (UTC) Received: from BY2PRD0411HT005.namprd04.prod.outlook.com (157.56.237.133) by VA3EHSMHS007.bigfish.com (10.7.99.17) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 14 Mar 2013 21:26:36 +0000 Received: from BY2PRD0411MB441.namprd04.prod.outlook.com ([169.254.5.31]) by BY2PRD0411HT005.namprd04.prod.outlook.com ([10.255.128.40]) with mapi id 14.16.0275.006; Thu, 14 Mar 2013 21:26:31 +0000 From: Lewis Adam-CAL022 To: Mike Jones , "oauth@ietf.org WG" Thread-Topic: JWT grant_type and client_id Thread-Index: Ac4OKlgNygAJgL9ySFC/PJajtkIVLAAEbxLQBK+M0AA= Date: Thu, 14 Mar 2013 21:26:30 +0000 Message-ID: <59E470B10C4630419ED717AC79FCF9A9568A83EA@BY2PRD0411MB441.namprd04.prod.outlook.com> References: <59E470B10C4630419ED717AC79FCF9A948D552B8@BY2PRD0411MB441.namprd04.prod.outlook.com> <4E1F6AAD24975D4BA5B168042967394367472284@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394367472284@TK5EX14MBXC284.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [150.130.34.167] Content-Type: multipart/alternative; boundary="_000_59E470B10C4630419ED717AC79FCF9A9568A83EABY2PRD0411MB441_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%1294$Dn%MICROSOFT.COM$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn% X-FOPE-CONNECTOR: Id%1294$Dn%IETF.ORG$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn% X-CFilter-Loop: Reflected X-OriginatorOrg: motorolasolutions.com Subject: Re: [OAUTH-WG] JWT grant_type and client_id X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 21:26:46 -0000 --_000_59E470B10C4630419ED717AC79FCF9A9568A83EABY2PRD0411MB441_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Coming back to this ... am I correct in that client_id is not required? We= are implementing this spec and want to make sure that we are doing it righ= t. By my understanding the only two parameters that are required in the JW= T grant type are "urn:ietf:params:oauth:grant-type:jwt-bearer" and the as= sertion. Is this correct? From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Monday, February 18, 2013 6:58 PM To: Lewis Adam-CAL022; oauth@ietf.org WG Subject: RE: JWT grant_type and client_id The client_id value and the access token value are independent. -- Mike From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of L= ewis Adam-CAL022 Sent: Monday, February 18, 2013 2:50 PM To: oauth@ietf.org WG Subject: [OAUTH-WG] JWT grant_type and client_id Is there any guidance on the usage of client_id when using the JWT assertio= n profile as a grant type? draft-ietf-oauth-jwt-bearer-04 makes no mention= so I assume that it is not required ... but it would be necessary if using= in conjunction with a HOK profile where the JWT assertion is issued to - a= nd may only be used by - the intended client. Obviously this is straight f= orward enough, really I'm just looking to be sure that I'm not missing anyt= hing. tx adam --_000_59E470B10C4630419ED717AC79FCF9A9568A83EABY2PRD0411MB441_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
Coming back to this … am I correct in=
 that client_id is not required?  We are implementing this spec and wa=
nt to make sure that we are doing it right.  By my understanding the o=
nly two parameters that are required in the JWT grant type are  "=
urn:ietf:params:oauth:grant-type:jwt-bearer"  and the assertion.&=
nbsp;  Is this correct?

 

 

From: Mike Jon= es [mailto:Michael.Jones@microsoft.com]
Sent: Monday, February 18, 2013 6:58 PM
To: Lewis Adam-CAL022; oauth@ietf.org WG
Subject: RE: JWT grant_type and client_id

 

The client_id value an= d the access token value are independent.

 

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

 

From: oauth-bo= unces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Lewis Adam-CAL022
Sent: Monday, February 18, 2013 2:50 PM
To: oauth@ietf.org WG
Subject: [OAUTH-WG] JWT grant_type and client_id

 

 

Is there any guidance on the usage of c= lient_id when using the JWT assertion profile as a grant type?  draft-= ietf-oauth-jwt-bearer-04 makes no mention so I assume that it is not required … but it would be necessary if using in conjunction = with a HOK profile where the JWT assertion is issued to – and may onl= y be used by – the intended client.  Obviously this is straight = forward enough, really I’m just looking to be sure that I’m not missing anything.

 

tx

adam

--_000_59E470B10C4630419ED717AC79FCF9A9568A83EABY2PRD0411MB441_-- From bcampbell@pingidentity.com Thu Mar 14 14:44: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 DDA4511E812B for ; Thu, 14 Mar 2013 14:44:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.826 X-Spam-Level: X-Spam-Status: No, score=-5.826 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9FsuDLDCY6GU for ; Thu, 14 Mar 2013 14:44:13 -0700 (PDT) Received: from na3sys009aog101.obsmtp.com (na3sys009aog101.obsmtp.com [74.125.149.67]) by ietfa.amsl.com (Postfix) with ESMTP id F128F11E80F2 for ; Thu, 14 Mar 2013 14:44:12 -0700 (PDT) Received: from mail-ob0-f200.google.com ([209.85.214.200]) (using TLSv1) by na3sys009aob101.postini.com ([74.125.148.12]) with SMTP ID DSNKUUJErAtIVoV1/tCkaeIZzXp4aobhZnNJ@postini.com; Thu, 14 Mar 2013 14:44:13 PDT Received: by mail-ob0-f200.google.com with SMTP id un3so14025672obb.11 for ; Thu, 14 Mar 2013 14:44:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=eBhP4kTHX2WQRwK/Qb3yshnPsVSUW1XvHYf8CQhr7S8=; b=FxxXNMY7TMs8NkQbm00pNIkSnGv8leD/cykFLteRywOELfQg5GFTtXOWQBb6Jm/tXE ZHxtgc0NH1I9I/N3g6bj+TqLQ7hxX/o18YFvM7ZHvUMNnz6lQ/E8TVkE4pyqCTJxOgSg WYyVE8E1vATLpSpoe8xFKncwhZ9zr5jjw0084i7rTJ5d6lGxf+6M5ltDQfJS5PUuNyPG Llkjq+01SKkooCA0xYLB3nTVxFwze3MOpFGQrm7tBy9DCmrpYT16AiOgmrQWkDgZRkyM jqWn9gh2iC6h2+tA5wFWUKR6cokFdYT7DAE+u7PJ1Ixv65mBBSEnzu5VEBWUmOM+lvQ6 FbIQ== X-Received: by 10.50.37.162 with SMTP id z2mr3755741igj.13.1363297451974; Thu, 14 Mar 2013 14:44:11 -0700 (PDT) X-Received: by 10.50.37.162 with SMTP id z2mr3755737igj.13.1363297451907; Thu, 14 Mar 2013 14:44:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.32.106 with HTTP; Thu, 14 Mar 2013 14:43:41 -0700 (PDT) In-Reply-To: <59E470B10C4630419ED717AC79FCF9A9568A83EA@BY2PRD0411MB441.namprd04.prod.outlook.com> References: <59E470B10C4630419ED717AC79FCF9A948D552B8@BY2PRD0411MB441.namprd04.prod.outlook.com> <4E1F6AAD24975D4BA5B168042967394367472284@TK5EX14MBXC284.redmond.corp.microsoft.com> <59E470B10C4630419ED717AC79FCF9A9568A83EA@BY2PRD0411MB441.namprd04.prod.outlook.com> From: Brian Campbell Date: Thu, 14 Mar 2013 17:43:41 -0400 Message-ID: To: Lewis Adam-CAL022 Content-Type: multipart/alternative; boundary=f46d04446b2958355f04d7e96ce8 X-Gm-Message-State: ALoCoQmCM4OcZUqAizQuFxRdOD3MKzcg3Nqu0NUW9gnchfEIt6Z1FJ04OsIel8hDZcacGIwr8egouqSLWsh6DepxmuIYY5YSYcfAlhJYAEnegbuAB8gHRNbbwB1QmG9H76J8fNapsfpf Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] JWT grant_type and client_id X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 21:44:14 -0000 --f46d04446b2958355f04d7e96ce8 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Yes, that is correct. I'm working on new revisions of the drafts that will hopefully make that point more clear. On Thu, Mar 14, 2013 at 5:26 PM, Lewis Adam-CAL022 < Adam.Lewis@motorolasolutions.com> wrote: > Coming back to this =85 am I correct in that client_id is not required? = We are implementing this spec and want to make sure that we are doing it r= ight. By my understanding the only two parameters that are required in the= JWT grant type are "urn:ietf:params:oauth:grant-type:jwt-bearer" and the= assertion. Is this correct?**** > > ** ** > > ** ** > > *From:* Mike Jones [mailto:Michael.Jones@microsoft.com] > *Sent:* Monday, February 18, 2013 6:58 PM > *To:* Lewis Adam-CAL022; oauth@ietf.org WG > *Subject:* RE: JWT grant_type and client_id**** > > ** ** > > The client_id value and the access token value are independent.**** > > ** ** > > -- Mike**= * > * > > ** ** > > *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf > Of *Lewis Adam-CAL022 > *Sent:* Monday, February 18, 2013 2:50 PM > *To:* oauth@ietf.org WG > *Subject:* [OAUTH-WG] JWT grant_type and client_id**** > > ** ** > > ** ** > > Is there any guidance on the usage of client_id when using the JWT > assertion profile as a grant type? draft-ietf-oauth-jwt-bearer-04 makes = no > mention so I assume that it is not required =85 but it would be necessary= if > using in conjunction with a HOK profile where the JWT assertion is issued > to =96 and may only be used by =96 the intended client. Obviously this i= s > straight forward enough, really I=92m just looking to be sure that I=92m = not > missing anything.**** > > ** ** > > tx**** > > adam**** > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --f46d04446b2958355f04d7e96ce8 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Yes, that is correct.

I'm working o= n new revisions of the drafts that will hopefully make that point more clea= r.


O= n Thu, Mar 14, 2013 at 5:26 PM, Lewis Adam-CAL022 <Adam.Lew= is@motorolasolutions.com> wrote:
Coming back to this =85 am I correct in tha=
t client_id is not required?=A0 We are implementing this spec and want to m=
ake sure that we are doing it right.=A0 By my understanding the only two pa=
rameters that are required in the JWT grant type are =A0"urn:ietf:para=
ms:oauth:grant-type:jwt-bearer" =A0and the assertion.=A0 =A0Is this co=
rrect?

=A0

=A0

From: Mike Jon= es [mailto:Michael.Jones@microsoft.com]
Sent: Monday, February 18, 2013 6:58 PM
To: Lewis Adam-CAL022; oauth@ietf.org WG
Subject: RE: JWT grant_type and client_id

=A0

The client_id value an= d the access token value are independent.

=A0

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

=A0

From: oauth-bounces@ietf.org= [mailto:oa= uth-bounces@ietf.org] On Behalf Of Lewis Adam-CAL022
Sent: Monday, February 18, 2013 2:50 PM
To: oauth@ietf.o= rg WG
Subject: [OAUTH-WG] JWT grant_type and client_id

=A0

=A0

Is there any guidance on the usage of c= lient_id when using the JWT assertion profile as a grant type?=A0 draft-iet= f-oauth-jwt-bearer-04 makes no mention so I assume that it is not required =85 but it would be necessary if using in conjunction with= a HOK profile where the JWT assertion is issued to =96 and may only be use= d by =96 the intended client.=A0 Obviously this is straight forward enough,= really I=92m just looking to be sure that I=92m not missing anything.

=A0

tx

adam


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


--f46d04446b2958355f04d7e96ce8-- From Michael.Jones@microsoft.com Thu Mar 14 14:56:24 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 2EC1A11E80E9 for ; Thu, 14 Mar 2013 14:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FWwYiQn7UNcu for ; Thu, 14 Mar 2013 14:56:23 -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 9CC0911E80D9 for ; Thu, 14 Mar 2013 14:56:22 -0700 (PDT) Received: from BN1AFFO11FD012.protection.gbl (10.58.52.202) by BN1BFFO11HUB017.protection.gbl (10.58.53.127) with Microsoft SMTP Server (TLS) id 15.0.620.12; Thu, 14 Mar 2013 21:52:03 +0000 Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.37) by BN1AFFO11FD012.mail.protection.outlook.com (10.58.52.72) with Microsoft SMTP Server (TLS) id 15.0.641.9 via Frontend Transport; Thu, 14 Mar 2013 21:52:03 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.132]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.02.0318.003; Thu, 14 Mar 2013 21:51:43 +0000 From: Mike Jones To: "oauth@ietf.org WG" Thread-Topic: Observations from the OAuth Feature survey Thread-Index: Ac4g/hrwe23QvI6XQAy55Nm32MPKMg== Date: Thu, 14 Mar 2013 21:51:42 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394367511EAF@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.33] Content-Type: multipart/mixed; boundary="_007_4E1F6AAD24975D4BA5B168042967394367511EAFTK5EX14MBXC283r_" 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)(243025002)(16236675001)(46102001)(47736001)(54316002)(56816002)(5343635001)(512954001)(80022001)(16406001)(16297215001)(47446002)(63696002)(65816001)(74502001)(54356001)(15202345001)(51856001)(5343655001)(59766001)(53806001)(79102001)(50986001)(33656001)(55846006)(47976001)(5343665001)(76482001)(77982001)(49866001)(20776003)(74662001)(56776001)(69226001)(31966008)(562884003)(4396001)(66066001)(6606295001); DIR:OUT; SFP:; SCL:1; SRVR:BN1BFFO11HUB017; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0785459C39 Subject: [OAUTH-WG] Observations from the OAuth Feature survey X-BeenThere: oauth@ietf.org X-Mailman-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, 14 Mar 2013 21:56:24 -0000 --_007_4E1F6AAD24975D4BA5B168042967394367511EAFTK5EX14MBXC283r_ Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394367511EAFTK5EX14MBXC283r_" --_000_4E1F6AAD24975D4BA5B168042967394367511EAFTK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm giving the attached presentation on observations from the OAuth Feature= Survey to date shortly. The data collected to date is also attached, as i= s an updated version of the feature matrix, for those of you who want to ad= d your implementations to the survey. The presentation can also be downloaded from http://self-issued.info/presen= tations/Observations%20from%20the%20OAuth%20Feature%20Survey.pptx and http:= //self-issued.info/presentations/Observations%20from%20the%20OAuth%20Featur= e%20Survey.pdf. An updated version of the feature matrix can be downloaded= from http://self-issued.info/misc/OAuth%20Feature%20Matrix.xlsx. Finally,= the data collected to date can also be downloaded from http://self-issued.= info/misc/OAuth%20Feature%20Matrix%20-%20All.xlsx. -- Mike --_000_4E1F6AAD24975D4BA5B168042967394367511EAFTK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m giving the attached presentation on observ= ations from the OAuth Feature Survey to date shortly.  The data collec= ted to date is also attached, as is an updated version of the feature matri= x, for those of you who want to add your implementations to the survey.

 

The presentation can also be downloaded from http://self-issued.info/presentations/Observations%20from%20the%20OAuth%20F= eature%20Survey.pptx and http://self-issued.info/presentations/Observations%20from%20the%20OAuth%20F= eature%20Survey.pdf.  An updated version of the feature matrix can= be downloaded from http= ://self-issued.info/misc/OAuth%20Feature%20Matrix.xlsx.  Finally, = the data collected to date can also be downloaded from http://self-issued.info/misc/OAuth%20Feature%20Matrix%20-%20All.xlsx<= /a>.

 

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

 

--_000_4E1F6AAD24975D4BA5B168042967394367511EAFTK5EX14MBXC283r_-- --_007_4E1F6AAD24975D4BA5B168042967394367511EAFTK5EX14MBXC283r_ Content-Type: application/vnd.openxmlformats-officedocument.presentationml.presentation; name="Observations from the OAuth Feature Survey.pptx" Content-Description: Observations from the OAuth Feature Survey.pptx Content-Disposition: attachment; filename="Observations from the OAuth Feature Survey.pptx"; size=50297; creation-date="Thu, 14 Mar 2013 20:54:05 GMT"; modification-date="Thu, 14 Mar 2013 21:28:34 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQCWdCYL3QEAAE4OAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADM l11PwjAUhu9N/A9Lbw0r+K1heOHHlV+J+gPqdoBq1zbtAeXfezYQJ5kibgvckJTuvO/TbnvX0z17 T1UwBuel0RHrhG0WgI5NIvUgYk+PV61jFngUOhHKaIjYBDw7621vdR8nFnxA1dpHbIhoTzn38RBS 4UNjQdNM37hUIA3dgFsRv4oB8N12+5DHRiNobGGmwXrdC+iLkcLg8p3+npK8WBiw4Hx6YeYVMZlm AvkEL61xoPxCjbBWyVggrY6PdbJA1ppRhVSZX+OH0vodQmflDtnMd6iiwazujrbTyQSCe+HwVqSE zq1Fbh14WnVuFP6uVIJq+n0ZQ2LiUUoiYVEsVd+GYSqk/lzETzBeEeGN8Ei3nhcGnbrJCtp/YprR NMOxCsFuIzuxCsHe2gn2105wsBaC7O26d8b6ut3nwsueg7GEt0YI5sLLCJCyHHj+W/1lzGWWOopn BQ84UVD7vuOX9DKKPLCuxcSMcJZF00H1TVjI7ILRf5mayajpev/L1ExqVWNqJseqMTWTbNWYDuvO uxqe8aMNZDreQKaTDWTqtDcRal1JTof3/JNO/Y+D1Tfms1nJqluWTifgUMK8XSk76c8dqU1Z3XCh 5YCsO0sgKfHmeTfY+wAAAP//AwBQSwMEFAAGAAgAAAAhAGj4dKEFAQAA4gIAAAsACAJfcmVscy8u cmVscyCiBAIooAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAACskttKAzEQhu8F3yHMfTfbKiLSbG9E6J3I+gBjMrsb3RxIptK+vaHgYWEtgr2c 0z9f8s96s3ejeKeUbfAKllUNgrwOxvpewXP7sLgFkRm9wTF4UnCgDJvm8mL9RCNyGcqDjVkUFZ8V DMzxTsqsB3KYqxDJl0oXkkMuYeplRP2GPclVXd/I9FMDmomm2BoFaWuuQLSHWDb/R1s6YjTIKHVI tIipkCW25S2ixdQTKzBBP5Z0PnZUhRrkPNDqvEA87NyLRzvOoHzVqtdI/W9Ay78Dha6zmu6D3jny PGOCnHZ8M8XIMibKZexo+6kfuj4nEO2ZvCFz2jSM8ZNITi6z+QAAAP//AwBQSwMEFAAGAAgAAAAh AGNcI7TBAAAANwEAACAAAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlMS54bWwucmVsc4SPwWrDMBBE 74X8g9h7JDuHUoplX0IgkFNxPmCR1raILQmtEuq/r442BHqcHebNTtP9LrN4UWIXvIZaViDIm2Cd HzXc+8vxCwRn9Bbn4EnDSgxde/hofmjGXEI8uciiUDxrmHKO30qxmWhBliGSL84Q0oK5yDSqiOaB I6lTVX2qtGVAu2OKq9WQrrYG0a+xNP/PDsPgDJ2DeS7k85sKxbOzdMM1PHPBYhopa5Bye+etqGV5 H1TbqN3c9g8AAP//AwBQSwMEFAAGAAgAAAAhAEv1Pey/AAAANwEAACAAAABwcHQvc2xpZGVzL19y ZWxzL3NsaWRlMi54bWwucmVsc4SPwQrCMBBE74L/EPZuUj2ISFMvIgieRD9gSbZtsE1CNor9e3Os IHicHebNTn14j4N4UWIXvIa1rECQN8E632m4306rHQjO6C0OwZOGiRgOzXJRX2nAXELcu8iiUDxr 6HOOe6XY9DQiyxDJF6cNacRcZOpURPPAjtSmqrYqzRnQfDHF2WpIZ7sGcZtiaf7PDm3rDB2DeY7k 848KxYOzdMEpPHPBYuooa5Byfue52MjyPqimVl9zmw8AAAD//wMAUEsDBBQABgAIAAAAIQBL9T3s vwAAADcBAAAgAAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTQueG1sLnJlbHOEj8EKwjAQRO+C/xD2 blI9iEhTLyIInkQ/YEm2bbBNQjaK/XtzrCB4nB3mzU59eI+DeFFiF7yGtaxAkDfBOt9puN9Oqx0I zugtDsGThokYDs1yUV9pwFxC3LvIolA8a+hzjnul2PQ0IssQyRenDWnEXGTqVETzwI7Upqq2Ks0Z 0HwxxdlqSGe7BnGbYmn+zw5t6wwdg3mO5POPCsWDs3TBKTxzwWLqKGuQcn7nudjI8j6oplZfc5sP AAAA//8DAFBLAwQUAAYACAAAACEA1LeOATkBAADlBQAAHwAIAXBwdC9fcmVscy9wcmVzZW50YXRp b24ueG1sLnJlbHMgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC81EtrhDAQAOB7 of9Bcq9R99EHG/dSCnsolHb7A7I6aqgmIZNu679vcBe7K0t6Cb0oM+LMRx6zWn93bbQHg0JJRtI4 IRHIQpVC1oy8b59u7kiElsuSt0oCIz0gWefXV6tXaLl1P2EjNEauikRGGmv1A6VYNNBxjJUG6b5U ynTcutDUVPPig9dAsyRZUnNag+RnNaNNyYjZlK7/tteu89+1VVWJAh5V8dmBtBda0L2ArxejNLqi 3NRgGRlTsZMSehkxC4nAVpTwCxhCpMMr8yFuQyK0AZysxJjyIbKQCM9KpD5EGhzxzNGCmWzKIXnc mkPgZS2DsyagI2XhW5vFPyHmPkTqxki4W2v5roU327du9oz39iTpk8xDQjzndeZD3IdEWDdbT8bH ENLhOR5Oejac8x8AAAD//wMAUEsDBBQABgAIAAAAIQBL9T3svwAAADcBAAAgAAAAcHB0L3NsaWRl cy9fcmVscy9zbGlkZTUueG1sLnJlbHOEj8EKwjAQRO+C/xD2blI9iEhTLyIInkQ/YEm2bbBNQjaK /XtzrCB4nB3mzU59eI+DeFFiF7yGtaxAkDfBOt9puN9Oqx0IzugtDsGThokYDs1yUV9pwFxC3LvI olA8a+hzjnul2PQ0IssQyRenDWnEXGTqVETzwI7Upqq2Ks0Z0HwxxdlqSGe7BnGbYmn+zw5t6wwd g3mO5POPCsWDs3TBKTxzwWLqKGuQcn7nudjI8j6oplZfc5sPAAAA//8DAFBLAwQUAAYACAAAACEA S/U97L8AAAA3AQAAIAAAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGUzLnhtbC5yZWxzhI/BCsIwEETv gv8Q9m5SPYhIUy8iCJ5EP2BJtm2wTUI2iv17c6wgeJwd5s1OfXiPg3hRYhe8hrWsQJA3wTrfabjf TqsdCM7oLQ7Bk4aJGA7NclFfacBcQty7yKJQPGvoc457pdj0NCLLEMkXpw1pxFxk6lRE88CO1Kaq tirNGdB8McXZakhnuwZxm2Jp/s8ObesMHYN5juTzjwrFg7N0wSk8c8Fi6ihrkHJ+57nYyPI+qKZW X3ObDwAAAP//AwBQSwMEFAAGAAgAAAAhAIxCLatnAgAAGA0AABQAAABwcHQvcHJlc2VudGF0aW9u LnhtbOyX3Y6iMBTH7zfZdyC93TgI8iURJ9ndmEziJmZ1HqADRyVTCmkrq/P0e1qqsJpN5gG4oz2f /fHnWBfP54o5LQhZ1jwj3tOUOMDzuij5ISOvu9UkIY5UlBeU1RwycgFJnpdfvyyatBEggSuqMNTB NFymNCNHpZrUdWV+hIrKp7oBjrZ9LSqqcCkObiHoH0xfMdefTiO3oiUnNl58Jr7e78scftb5qcLy XRIBzPQhj2Ujr9maz2QbnuLfliRtYXt6k6BWNVcS6ZAlHluy4heVCsRLsZbqbscpi4z4XhAHySwK kJ1I9Q76esRdLtz/hA9TvRRdkjAaRPs62gTfzPHAPHs0zwfm4NE8bC18MEcog1vnkTZ3nQ/73H44 +Tkjcy8IplP0zy8ZiZIwMQt1aVAsMhcAPDjb9nitQNqwm6cOu+YwZyxgT09M7eCsturCYLmgKe5t NsI+/d4Ih1GtT+CT163pbujCWuY16FNRsc4IdkbZAbXNiINpdvRt+3GtiIdUzLgAXfPv4l2/Y8yt Sm6XGH3EUijXzYnnqtOAKaa7kJjJwwMT5x2E/nxQ0KgRmsqalcWqZMws9KcAP5hwWorV1LmTwp2X qepobnuaI7tvFZ8wpQ9HU6B3BqCdIZd3hlz2OLBDfG80tTx0Inz0ezRBGOuGRz4GiuUz6/l0shz5 tExDsXyCno83i71oFJD+qjQVCygcAEr8xIyHcQJpKhZQ1APy/QQFNI4gVJCmYgHFA0BxMBtntPnh 0lQsoKQHpOng/WMc0i3TVCyg+QBQFMbjkDYK0lTMTfbxionX2+EfgeVfAAAA//8DAFBLAwQUAAYA CAAAACEAke9ZESYDAAArCQAAFQAAAHBwdC9zbGlkZXMvc2xpZGUzLnhtbMRW207jMBB9X2n/wcp7 SW9AidqitlC0EgvVFsSzcSbEwrG9tlNarfbfd+wkIG7aclntSy72zHjOmZOZDA/XhSArMJYrOYo6 O+2IgGQq5fJmFF1ezFuDiFhHZUqFkjCKNmCjw/HXL0OdWJES9JY2oaMod04ncWxZDgW1O0qDxL1M mYI6fDU3cWroHUYtRNxtt/fignIZ1f5mG3+VZZzBkWJlAdJVQQwI6jBzm3Ntm2h6m2jagMUwwftR SmNExpYi9XerLwyAf5KrE6OXemHC9tlqYQhPka+ISFogLVFcb9Rm4VWiGT7ET9xvmkg0WWemGA9p gtjIehQh+Rt/RSeawNoRVi2yh1WWn79gy/LjF6zj5gDM4P5Qj6pC9BxOt4FzwZ0A0rlHVZlSdD1V 7NYSqRCnh1/BY2erJpjH7MPrnLiNRmacD1XbVZuBj8beIqeBLLeeqnTjgV/jPSzSRFi3dBsBgRBM myYYHC9Iv6BeoSBbl8uIpNy4wBGxhZsJoKjlmkY3nghBXA7EamCWUAPkGlCIpLSQDpEjhyWqA4NM F9TQH6/G93hpgpkgiCZjfKwofZ3YXkPsTEmHsiMLQRnkSqRgSPdjNPMURdJU4i0MeyYlfqCT0qmM uwpaRb7f+hTup6Xz3G+e0I4FyzIwyITYPCpBRW5g+F21PqrjMrCESybKFJLXD0DtEbESNX1/PTCo 0I1ngvsSenlbYkutlXFPlPQIxhtPeUnCJ4ben/hMtp992FUOWDJDLMMuXn0wOAEcZ2RFRYkrCvec KZkrzT/G3aRCGRbUEqduQVYZKU1/lvAfUjGQ4ejA7vaQyxYaeEfbuso5ywlOAYSMI45oxaWrwHsJ EJzJJFd326v7I80t9LhmGGJOpxa7pg4zqjR8FP2aTg/2urPBtDXt9Oet/tHBfmsy39ttzXd7/f5s OpjMese/I/Tp9BNmIMzdb83/Ay4+m9kFZ0ZZlbkdpoq4Gv6xVndgAhE4/zvt+icCZTmK+t39g/bu /mDQq4cNZhnadJMtQmjmOhPmO9Xnq1AV/F1xYGZhSeNc8H0QTR9MPHb8H/gDAAD//wMAUEsDBBQA BgAIAAAAIQDhqLmTlwMAANEKAAAVAAAAcHB0L3NsaWRlcy9zbGlkZTIueG1svFbdb9MwEH9H4n+w 8gQPWfq9NVo7rd2KkAab1k08Is+5LGaObdnuF4j/nbOTMJVRwaDwkqbOff1+d76745N1KcgSjOVK jqL2QSsiIJnKuLwfRbc3s/goItZRmVGhJIyiDdjoZPzyxbFOrcgIakub0lFUOKfTJLGsgJLaA6VB 4rdcmZI6/Gvuk8zQFVotRdJptQZJSbmMan3zO/oqzzmDM8UWJUhXGTEgqMPIbcG1bazp37GmDVg0 E7S3QhojMjYXmf+1+sYA+De5fGP0XF+Z8Pn98soQniFfEZG0RFqipP5Qi4W/EsXwJflB/b6xRNN1 bsrxMU0RG1mPIiR/45+oRFNYO8KqQ/Z4yorLn8iy4vwn0knjACP47tSjqhA9hdNp4NxwJ4C0v6Oq RCmqXij2YIlUiNPDr+Cx98vGmMfszeuCuI1GZpw3VctVHwMfjbxFTgNZbj1R2cYDv8PfcEhTYd3c bQQEQjBsmqJxfCD9gvoKBRnfziOSceMCR8SWbiqAYi3XNLrxGXWUvKGuAAMZcYrgARwjOQ5zU1sE mV1RQ693GvZAaYohYPRNqPhacbmb0W7D6FRJh/VGrgRlUCiRgSGdv+OXZ1gdTQqeQ62nUOLNPF04 lXNHcoxtzqjAbA07/RZWoZBzza4hWzB/u0YR3lg8rjio0uNt7C87rEDymQPDP2OLIEPCSy3A3/Pq em9lq8pDSAY+fMaWoibij+rjA3cFKZUBXxu5EkKtdvv7g/prD9vkEaB1nFmi8h8hEoaeATnI9up8 qrC5I6fpbqt7oPB6NiWDw96QvLrEoiqIfyhMZsgemRnskStlHl7/hyD6rSaICVCDt+xGPYAkt5be w/78h4bkxjjTchdzcHmsKGKOLS1FJ74LnvcGdsvZltVf1zsYHK6hSfh+5yN9noHadw3vebpk2/mn lXuefuP739BZJWzZicuFcBzbTYwrgcZdAmI/uWzc/tjainfffWfOcEuyJIOcSxxMdxvityaexUxJ iZ0gLsH6qt0VydNJFAZSs7Lg/nBhccTpsEksDB9FXyaT4aAzPZrEk3ZvFvfOhofx6WzQj2f9bq83 nRydTrvnXyPUafdSZiBc37fNloeHTzarkjOjrMrdAVNlUq1oiVYrMFrxsKW1W/Wqt6TYpbvDQWvQ 7x4OBvVKgFGGmdpEixCa7YsJ847qy2VoubhU4niYhiON/Qxrw4s+injsuLV9AwAA//8DAFBLAwQU AAYACAAAACEAjy1lF9YCAAA8CAAAFQAAAHBwdC9zbGlkZXMvc2xpZGUxLnhtbMxVbW/aMBD+Pmn/ wfLn0RCgjEaEqtBm2tQ3DfoDjGMaq45t2SYFTfvvOztJK1qqtd007Ute7LvzPc89vhsfb0qBKmYs VzLF8UEXIyapyrm8TfHNIuuMMLKOyJwIJVmKt8zi48nHD2OdWJEj8JY2ISkunNNJFFlasJLYA6WZ hL2VMiVx8Gtuo9yQe4haiqjX7Q6jknCJG3/zGn+1WnHKThVdl0y6OohhgjjI3BZc2zaafk00bZiF MMF7J6UJIKNzkfu31QvDmP+S1Rej5/rahO3L6togngNfGElSAi04ajYas/ArwQw+oifut20kkmxW ppyMSQLY0CbFQP7WP8GJJGzjEK0X6eMqLa722NLibI911B4AGTwc6lHViJ7D6bVwFtwJhuIHVLUp AddzRe8skgpwevg1PHpZtcE8Zh9eF8htNTBDnQnRGtN6P1DSuligNfDlNlOVbz32JbzDIkmEdXO3 FSxwApmTBOLDAyogiBcpk52bOUY5Ny7QhGzpZoIRkHPDpJtcLS0zVS0VtDKqRK5gY+DHQXmaiMs3 xgW/xuUd+ZysXYGeJLD//D1oMkbc2rB3+8/XpmLbJ6czmV8TQ76/yKsvNUmgAlC8tlLwWavpZU31 W03N10sXZNX7G7Ky62UtK7iHcElaJf5jefnKWyV4nnEhwo/vf2wmDKqISLHb1IntWHnB+Uvi1XfB 7xj6Bp3V7pSjJjqw/Ta9/3lCxNACxYNPqNeN+/9JUl/PFhkaDXeygQb5O8W+l4zHwC9LPii/nQ7Q qs8ttBIdmvba8BT/mE6Phr3ZaNqZxoOsMzg9+tw5yYaHneywPxjMpqOTWf/sJwafeJBQAzcaxtjX dqDC4rMhVnJqlFUrd0BVGdXTMNLqnhmteBiIcbeZqkF78egojnujOB42rReyDJe3zRYgtIOOCnNB 9FUVVAnz2zEDGoYlDRO76fGPJh47DMhfAAAA//8DAFBLAwQUAAYACAAAACEAGJurkBwDAACICQAA FQAAAHBwdC9zbGlkZXMvc2xpZGU0LnhtbMxW227bMAx9H7B/EPwwbA+pc2vWeEmLJl26AV0bNOkH aDJdC5UlTVLSZMP+fZRst+u9HZZheXBsiaR4DimSg71VIcgSjOVKDqPWVjMiIJlKuTwfRmfzSWMn ItZRmVKhJAyjNdhob/f1q4FOrEgJakub0GGUO6eTOLYsh4LaLaVB4l6mTEEdfprzODX0Eq0WIm43 m724oFxGlb55jr7KMs7gQLFFAdKVRgwI6tBzm3Nta2v6Oda0AYtmgvYNl3YRGZuJ1P9bPTcA/k0u D42e6akJ28fLqSE8Rb4iImmBtERxtVGJhU+JYvgS31I/ry3RZJWZYndAE8RGVsMIyV/7JyrRBFaO sHKRXa+y/OQeWZZ/vEc6rg9AD64O9ahKRHfhtGs4c+4EkNYVqlKUouqRYheWSIU4PfwSHjte1sY8 Zm9e58StNTLjvKlKrtwMfNTyFjkNZLnVSKVrD/wr/nsjNJGYPvsLpzLuSKakmzEq0GS/ib9g8ndh Yd3MrQUE8hAiTYINg6ES1GczyMbZLCIpNy7wSWzhxgIo5n1Fuds9s0BURpBNkP5KkKni0lnCLXE5 kGN0aIC0OoxqZR9kOqWGnj54jKeIJugQ4q5B4msZhYdj0aljMUbgmKlkKiiDXIkUDGl79JinNe8v jAxPMa/q4L0kKIHbv0L0NcO6ZHhhISVcMrFIIbnBccleoBAfnuelqNz/oxjPGFYnsqRiAXajBx0a inHz12Cz55yC1VgD4Z8c9Q1Zc0RjyhfgsG+Qt3ThcmX491BLyRta6A/EqQuQ7zbK7hXq/8CXqVFO MSWwd6ZlPm8U+qf5fEo87VgXOCt5D533JYn2ZOG6XR8fvYdPWnukDIZqWHdabHtHFuurDg1wYfgw +jEa9Xvt8c6oMWp1J43uQf99Y3/S225Mtjvd7ni0sz/ufPwZoU6rmzADgZDP9XCCi3cGgoIzo6zK 3BZTRVxOFrFWl2BC9HC4aDWrCQXrxDDq9LvtVqfX2u5WnQy9DAW99hYh1EMDE+YL1SfL0H1wFsJL Mg5LGqcfzwKKXot47Dhs/AIAAP//AwBQSwMEFAAGAAgAAAAhALTF7DRnAwAAiQoAABUAAABwcHQv c2xpZGVzL3NsaWRlNS54bWysVl1v2zoMfR+w/0D4eamTNO1tjSZDk7ZDgW0JbjLcZ0Vmam2yJEiK m2DYf7+UbHdIl25rm5fE1gfJc3hM8uL9ppRQoXVCq2HSO+omgIrrXKi7YfJlcdM5S8B5pnImtcJh skWXvB+9fXNhMidzoNvKZWyYFN6bLE0dL7Bk7kgbVLS30rZknl7tXZpbdk9WS5n2u93TtGRCJc19 +zf39WolOF5pvi5R+dqIRck8Re4KYVxrzfyNNWPRkZl4eyekESHjc5mHf2cWFjE8qeqDNXMzs3H7 czWzIHLiKwHFSqIlSZuN5lh8VXSMHtJH1+9aSyzbrGw5umAZYYPNMCHyt+GXLrEMNx54vch/rvJi uucsL673nE5bBxTBg9OAqkb0K5x+C2chvEToPaCqjzK6+lHzbw6UJpwBfg2Pf65aYwFzMG8K8FtD zPhgqjlXb0Y+2vOOOI1k+c1Y59sAfEn/cZFl0vm530qMhFDYLCPj9EP0SxYUiqrzZZ5ALqyPHIEr /UQiIy03NPrRrfJoSZCWLYUUfgvCwRhJinDJC4EV5hfElKdENeZR5TNm2b9PegmoWUbxEJQ2bnqs iX2a3uOW3ommkJSHmWQcCy1ztNB/HdkiJ6m0+XgOz4FPRZ/p5drrlfA1tDoFYesgGVhoYDXV8Ijq P6UTLdUG+sr2pFXUaX2mwT2G3oEojcRQVepiAmuHwHVZagXGEisS3Y6bOvlRAS9S5OJePxgGrERO rrOnPdAnArKSTX5f5HFK9fj2Ckh4CrlvnYNewZQSX0D/qHs4/79JWojjej673XH2IkTPVFKsIH7U gXnJrIcPVuTPtLBPg406dtC8WhwFWoSSbaFgFcISUYH2tHhYDU6jSbgPzr6unYflWsjQ9mFlqaXd a/uNvoEcn8Z2AFn+J0h7Ox7+rIXfqOtgJaEpV2xJXXC5BWaMFPyhOASShH8U9muaRuwd7ahBff+j o25k4gSwtmKYfB+Pz0/7k7NxZ9wb3HQGV+f/dC5vTk86NyfHg8FkfHY5Ob7+kdCd3iDjFmOkt+10 Rou/TESl4FY7vfJHVOfSerRKjSY1GE0s0nTV6zYjWsVC5en2zs9OT7rHbYuhKGP7a6MlCO3UxKX9 xMy0irWdhkHqvpO4ZIi40F/o6M8jATtNW/8DAAD//wMAUEsDBBQABgAIAAAAIQDV0ZLxvgAAADcB AAAsAAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDcueG1sLnJlbHOEj8EKwjAQ RO+C/xD2btJ6EJGmXkTw4EX0A5Zk2wbbJGSj6N+bYwXB4+wwb3aa/WsaxZMSu+A11LICQd4E63yv 4XY9rrYgOKO3OAZPGt7EsG+Xi+ZCI+YS4sFFFoXiWcOQc9wpxWagCVmGSL44XUgT5iJTryKaO/ak 1lW1UWnOgPaLKU5WQzrZGsT1HUvzf3boOmfoEMxjIp9/VCgenaUzcqZUsJh6yhqknN95LmpZ3gfV NuprbvsBAAD//wMAUEsDBBQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAcHB0L3NsaWRlTGF5b3V0 cy9fcmVscy9zbGlkZUxheW91dDgueG1sLnJlbHOEj8EKwjAQRO+C/xD2btJ6EJGmXkTw4EX0A5Zk 2wbbJGSj6N+bYwXB4+wwb3aa/WsaxZMSu+A11LICQd4E63yv4XY9rrYgOKO3OAZPGt7EsG+Xi+ZC I+YS4sFFFoXiWcOQc9wpxWagCVmGSL44XUgT5iJTryKaO/ak1lW1UWnOgPaLKU5WQzrZGsT1HUvz f3boOmfoEMxjIp9/VCgenaUzcqZUsJh6yhqknN95LmpZ3gfVNuprbvsBAAD//wMAUEsDBBQABgAI AAAAIQDV0ZLxvgAAADcBAAAsAAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDYu eG1sLnJlbHOEj8EKwjAQRO+C/xD2btJ6EJGmXkTw4EX0A5Zk2wbbJGSj6N+bYwXB4+wwb3aa/Wsa xZMSu+A11LICQd4E63yv4XY9rrYgOKO3OAZPGt7EsG+Xi+ZCI+YS4sFFFoXiWcOQc9wpxWagCVmG SL44XUgT5iJTryKaO/ak1lW1UWnOgPaLKU5WQzrZGsT1HUvzf3boOmfoEMxjIp9/VCgenaUzcqZU sJh6yhqknN95LmpZ3gfVNuprbvsBAAD//wMAUEsDBBQABgAIAAAAIQBpol8hHgEAAMcHAAAsAAAA cHB0L3NsaWRlTWFzdGVycy9fcmVscy9zbGlkZU1hc3RlcjEueG1sLnJlbHPE1d1qwyAUB/D7wd5B zv1ikrbpBzW9GYPCrkb3ABJPPliionYsbz8pDBIojkLAm4CK5/z4K+Z4+hl68o3GdkoyyJIUCMpK iU42DD4vby87INZxKXivJDIY0cKpfH46fmDPnd9k205b4qtIy6B1Th8otVWLA7eJ0ij9Sq3MwJ0f moZqXn3xBmmepgU10xpQzmqSs2BgzsL3v4zad/6/tqrrrsJXVV0HlO5OC2r7TuA7H9XV+bLcNOgY JMl03k4Hu8Tzgd6XrWLKViHZNqZsG5Jl+ZI0568Zzg7yNkNv3yzkWJTx6K3KQ7JsyYAelQUzK2LK imBmcUMLpraJmdommJp/6+M9rVkasq1j0tYh2T6mbP8no7Pfb/kLAAD//wMAUEsDBBQABgAIAAAA IQDV0ZLxvgAAADcBAAAsAAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDkueG1s LnJlbHOEj8EKwjAQRO+C/xD2btJ6EJGmXkTw4EX0A5Zk2wbbJGSj6N+bYwXB4+wwb3aa/WsaxZMS u+A11LICQd4E63yv4XY9rrYgOKO3OAZPGt7EsG+Xi+ZCI+YS4sFFFoXiWcOQc9wpxWagCVmGSL44 XUgT5iJTryKaO/ak1lW1UWnOgPaLKU5WQzrZGsT1HUvzf3boOmfoEMxjIp9/VCgenaUzcqZUsJh6 yhqknN95LmpZ3gfVNuprbvsBAAD//wMAUEsDBBQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAcHB0 L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDIueG1sLnJlbHOEj8EKwjAQRO+C/xD2btJ6 EJGmXkTw4EX0A5Zk2wbbJGSj6N+bYwXB4+wwb3aa/WsaxZMSu+A11LICQd4E63yv4XY9rrYgOKO3 OAZPGt7EsG+Xi+ZCI+YS4sFFFoXiWcOQc9wpxWagCVmGSL44XUgT5iJTryKaO/ak1lW1UWnOgPaL KU5WQzrZGsT1HUvzf3boOmfoEMxjIp9/VCgenaUzcqZUsJh6yhqknN95LmpZ3gfVNuprbvsBAAD/ /wMAUEsDBBQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9z bGlkZUxheW91dDMueG1sLnJlbHOEj8EKwjAQRO+C/xD2btJ6EJGmXkTw4EX0A5Zk2wbbJGSj6N+b YwXB4+wwb3aa/WsaxZMSu+A11LICQd4E63yv4XY9rrYgOKO3OAZPGt7EsG+Xi+ZCI+YS4sFFFoXi WcOQc9wpxWagCVmGSL44XUgT5iJTryKaO/ak1lW1UWnOgPaLKU5WQzrZGsT1HUvzf3boOmfoEMxj Ip9/VCgenaUzcqZUsJh6yhqknN95LmpZ3gfVNuprbvsBAAD//wMAUEsDBBQABgAIAAAAIQDV0ZLx vgAAADcBAAAsAAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDQueG1sLnJlbHOE j8EKwjAQRO+C/xD2btJ6EJGmXkTw4EX0A5Zk2wbbJGSj6N+bYwXB4+wwb3aa/WsaxZMSu+A11LIC Qd4E63yv4XY9rrYgOKO3OAZPGt7EsG+Xi+ZCI+YS4sFFFoXiWcOQc9wpxWagCVmGSL44XUgT5iJT ryKaO/ak1lW1UWnOgPaLKU5WQzrZGsT1HUvzf3boOmfoEMxjIp9/VCgenaUzcqZUsJh6yhqknN95 LmpZ3gfVNuprbvsBAAD//wMAUEsDBBQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAcHB0L3NsaWRl TGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDEueG1sLnJlbHOEj8EKwjAQRO+C/xD2btJ6EJGmXkTw 4EX0A5Zk2wbbJGSj6N+bYwXB4+wwb3aa/WsaxZMSu+A11LICQd4E63yv4XY9rrYgOKO3OAZPGt7E sG+Xi+ZCI+YS4sFFFoXiWcOQc9wpxWagCVmGSL44XUgT5iJTryKaO/ak1lW1UWnOgPaLKU5WQzrZ GsT1HUvzf3boOmfoEMxjIp9/VCgenaUzcqZUsJh6yhqknN95LmpZ3gfVNuprbvsBAAD//wMAUEsD BBQABgAIAAAAIQDV0ZLxvgAAADcBAAAtAAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxh eW91dDEwLnhtbC5yZWxzhI/BCsIwEETvgv8Q9m7SehCRpl5E8OBF9AOWZNsG2yRko+jfm2MFwePs MG92mv1rGsWTErvgNdSyAkHeBOt8r+F2Pa62IDijtzgGTxrexLBvl4vmQiPmEuLBRRaF4lnDkHPc KcVmoAlZhki+OF1IE+YiU68imjv2pNZVtVFpzoD2iylOVkM62RrE9R1L83926Dpn6BDMYyKff1Qo Hp2lM3KmVLCYesoapJzfeS5qWd4H1Tbqa277AQAA//8DAFBLAwQUAAYACAAAACEA1dGS8b4AAAA3 AQAALQAAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQxMS54bWwucmVsc4SPwQrC MBBE74L/EPZu0noQkaZeRPDgRfQDlmTbBtskZKPo35tjBcHj7DBvdpr9axrFkxK74DXUsgJB3gTr fK/hdj2utiA4o7c4Bk8a3sSwb5eL5kIj5hLiwUUWheJZw5Bz3CnFZqAJWYZIvjhdSBPmIlOvIpo7 9qTWVbVRac6A9ospTlZDOtkaxPUdS/N/dug6Z+gQzGMin39UKB6dpTNyplSwmHrKGqSc33kualne B9U26mtu+wEAAP//AwBQSwMEFAAGAAgAAAAhAHOEEu8UBAAAwxEAACEAAABwcHQvc2xpZGVMYXlv dXRzL3NsaWRlTGF5b3V0NC54bWzsWN1y4jYUvu9M30HjXnv9g23AE9gBHPdmN8kU9gEUWwR3ZcuV BIHtdGZfq32cfZIeyRYhhBRouMxNYuRPn3S+86NjXX1clxStCBcFqwaW98G1EKkylhfVw8D6Mkvt noWExFWOKavIwNoQYX0c/vzTVR0Lmn/CG7aUCDgqEeOBtZCyjh1HZAtSYvGB1aSCd3PGSyzhJ39w co4fgbukju+6kVPiorLa+fyU+Ww+LzKSsGxZkko2JJxQLGH/YlHUwrDVp7DVnAig0bOfb0luarBW PrLb+98tpHF8BSOeNQTTsynNUYVLGJg9MjRhlQQa/UrUM06IAlWrX3k9re+4nnGzuuOoyBVDO9Ny 2hctTP+sAAYPzt70B8OE4/Wcl8MrHIMSaD2wwGEb9Rcm4ZisJcqawexpNFvcHsBmi+sDaMcsADvY Lgq+rhuLXprjG3NmhaQEeVurGiiGqZ9Y9lWgioGdyvzGvOxmZciUzYq+XqBWdkXV4pqXWg+DF6Cp FkuuxyzfKMPv4b8exDEVcio3lGhBYNs4BnL4A/JTrKKaVPaXKUR1KSeUYIj6Vjw5nNAi+4okQyQv JPqMhSQcSW2XUJRXoI4E57SUpMrvMMe/7TEr+3AMK8OmzQ7hsZHwdSE7Rsg2mtAdxRlZMJrDJvy3 ySq+QTZgOrcgAiE8jA9e0VbJtRdlQdiFfNWh5kWuq561vibgArfTg3ELqbALQj/sRx3tQMOkBWjc bDQ56DW1Nl1RT6cNjnMyV/Kq/fu9ZlHQdgcAj/4BbLCLNQDAdg5g3V2sAQA2eIn1nu3BAAAbHsMa AGCjY1gDAGz3GNYAANs7hjUAwPaPYRuA0rpNJ+UYnU0wEwHDNm3emF0qgnRyiWfZ1WTQ/pI6cM9I 6CnJWJUjSlaEnkCvs+wM+tmi4Kez64Q4gz1lSy4XJ28+aDLyZHekxfwgO5wiF61rwX/VNa0JnKfm MDjzuNira9p/+qhQlUY/7J4Zh+paFPTeCxucCO+FLX4vbNtG6L2wndCwhaawJViSZ92aLsX/v6o1 TXAuoUfd69u0g14vcOc0xXP4glGfI396SW+cdN2unfQnqR24o2t7HEwie9LvJaOO74YTt/+X1Xbm OZgqi5KkxcOSk9ul+uaBI22vA37ZW0Nu6X5RDjuOF8Bnm9d5Oo9hK4rlssdOZLyTMqba+N1uOlRH 5Vv9M5e8cdAfS8xhBdNbH2muz/HRZRXpGkWmtMgJulmW93u6RJfQBa4FgPqgNEfO53Ok2YbvOEq9 MPR7tu8l13aQjkZ2z/Wu7agTJEkySoOxP96Gr1CWV7C7c6P2x/e/f/nx/Z8LxKwuLM0VATyqiwQd ipR/xvXtSndvcHUC8TTRQzVcloAuCvoEURzm8mX4LwAAAP//AwBQSwMEFAAGAAgAAAAhAEDDt1+J BAAAtBAAACEAAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0My54bWzMWNty4kYQfU9V/mFK eWaRhJCEyrBlwCQPXtu1eD9gkAaj2tElo4HAplK1v5V8zn7Jnh5JgB2nltgul19AzKX79OnTMy3O 3m8zyTZCVWmRDy3nnW0xkcdFkuZ3Q+vT7awTWqzSPE+4LHIxtHaist6Pfv7prIwqmVzyXbHWDDby KuJDa6V1GXW7VbwSGa/eFaXIMbcsVMY1fqq7bqL4H7Cdya5r234342luNfvVKfuL5TKNxbSI15nI dW1ECck18FertKxaa+Up1kolKpgxu+9D0rsS0VYi/k3wxGJmodpgyLFGiD2ey4TlPMPAXMTknNFC ocxsVd4qIWhdvvlVlfPyRplNV5sbxdKEjDSbrW4z0SwzP3Msw0P3wfa71hKPtkuVjc54BDbYdmgh aTv6xCYeia1mcT0YH0bj1fUja+PVxSOru60DINg7Rb7LOqJ/h+O24dymWgrm7KOql3JsvSzizxXL C8RJ4dfhxVeb1hjFTObLFaup12SqWVdPGj7a9ZXhtAW6ZyJw3Z7TM3R4nu0P7AekBEHgehhkRI3T 81076BsnrSU4qU2Xkd6Oi2RHlC7wjczxPF4VUKmmHTySlZ7rnUSe8byRDhAxLu9QRhIq4FEilh8x VH0ZWnAJnwuT+JiDAS5l47bZiXTftwiyeQRK8AEjklM9irzzaY56zPRECg5HTXR6NJFp/Jnpgokk 1ewDr7RQzFCI6gVGsq6ND2NS5MkNV5zgHVumrPAInsFCG70hhDLz3+kH33Up3JL2biSPxaqQKAbm UpColjbPT1ICsW+hbKDpVjhPEoQ7sP0A4jDJa6vkviD6tu2EQZOZushOEcSitvmYIDKuLk2BpnmC k4YeKaeL9RWOU4PkSCY4EuvpqpBpMkulpLXmNBUTqdiGS6hvS0cQ0pnmuh4JANsoAcnbLzapPLKD udqTmdirzkjXJenWSL1+ABSg+wS4TviKcAkjhQ3kvQPcgYMyPxWu/4pwCWMD1zvAdXqBQyhOo5ci MwJ4BTUQyAZv/whv6IaU5LeHl0A2eP0DXtcNQe9bxEsgG7zBEd7A651ebq+pBwLZ4A0PeAns6fX2 mngJZIN3cITX7wdvs94IZH0SH3UR5s4n9Djk9pe7CevpPQBddKYFqO71AE+55732np9yLe7d8+ZS fe49n2i0NmiWVlwu2/u+vtaoETZ00cPcMFe3aaa7aDuVtk8zt2p7F5sfhtclOnbqvf90puF4GthB ZzqYzDqefX7RGXsTvzMZhNNzKLw/sQd/WU0bmiBUnWZilt6tlbhea4tU9uN0AKRxrUe9ruPhPcXp HfgHFLLysl1Yv83OrCio+zvuwzxqUJ6bn6VWdYJ+X3MFD22OftCUGc8n5uhlGfFbRubopgS7WmeL B7yY3v+5vOA9GKYfpcb0v+ggX1K+Y3/m9Ptu2HGd6UXHm52fd0Lbuej4PW86nZ7PvLE73su3oshz oPu/qv329e9fvn395wU0axro+n0Yj/TibKQo1QdeXm/M6Yb/CqAndLgYKvHvACRDSw9LyEb7b8Po OwAAAP//AwBQSwMEFAAGAAgAAAAhACFajqJNAwAA8QoAACEAAABwcHQvc2xpZGVMYXlvdXRzL3Ns aWRlTGF5b3V0Mi54bWysVlty2jAU/e9M96Bxvx3bvEI8QAZs6E+TMIUsQLFl7EaWXElQaKcz2Va7 nKykV7JNGkJnoPDjh3x1dO+5x0fqXa9zilZEyIyzvuVduBYiLOJxxhZ9634+sbsWkgqzGFPOSN/a EGldD96/6xW+pPEnvOFLhQCDSR/3rVSpwnccGaUkx/KCF4TBt4SLHCt4FQsnFvgbYOfUabhux8lx xqxqvjhkPk+SLCIhj5Y5YaoEEYRiBfnLNCtkjVYcglYIIgHGzH6dktoUUC1/+GIhEyRW8OpZA6g7 mtEYMZzDwDxTlCBgBwWcKUAyAbKYC0J0KFt9FMWsmAoz73Y1FSiLNU4133KqD1WYeWUQBg/OzvRF jYT9dSLyQQ/7QAZa9y3o2UZfYRL2yVqhqByMXkaj9G5PbJSO90Q79QKQwXZRaHdRVvS2nEZdTkmH t62qDMUw9ROPHiViHOrU5ZflRberGkzXrOGLFJXMK81sFVd+NHzU8RI4NWSp9YjHG134A9zNIPap VDO1ocQQAmljH8DhAvRTrIVNmH0/A2HnKqAEg/Ar8tQgoFn0iBRHJM4UusFSEYFMMvAbAGQP2FHQ nAqSsHiKBf68g6zrwz6sDEnXGcJjSeG/iWzWRFZqQlOKI5JyGkMSjdNozWIQRc38GRiFBiC6olvq TmRYy9YQLF8xXLJoqIRLvaQp44imzkjE4R+lZEXoAfCG6SPg52kmDkdv6j4egT7hS6HSg5NvHQuf JXvRwUnOqu1Wre0QK/JK2IYQsNXaDf7LL2IFv/N38HxMEwtMVovd/NTGNrS5nOQfCVi+du4fXtgd hZfupR1eBRO75Q7H9qgVdOzgqhsOmw23HbhXP63KxGIoVWU5mWSLpSB3S709QOd3zOKtDZXmpo2m 6Xgt2OS85otsIRWNct7utOvuTDjXjve38RhFndqfRImyQV+XWMAKdY/O6EjnZaRTMzKjWUzQ7TJ/ 2OGlfZohl/scHKIAei81xobOLN9RZ+K1242u3fDCsd2aDId21/XGdqfZCsNwOGmNGqOtfKWunEF2 x6r2+enXh+en32fQrNk0y9MUPOqTlzkwUXGDi7uV2XPgoAl6CsxQAUdLvfdC6EuIxqiPqoM/AAAA //8DAFBLAwQUAAYACAAAACEAzG7OhDgEAABgEAAAIQAAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVM YXlvdXQxLnhtbMxY227jNhB9L9B/INRnre4XC7EXthX3JZsE6+wHMBJtC0tdStGu3aLA/lb7Ofsl nSEly8m62LQwCr84FDUcnZkzw5nJzft9ycmOibaoq7HhvLMNwqqszotqPTY+PS3M2CCtpFVOeV2x sXFgrfF+8uMPN03S8vyOHuqtJKCjahM6NjZSNolltdmGlbR9VzesgnerWpRUwqNYW7mgv4Lukluu bYdWSYvK6M6Lt5yvV6siY2mdbUtWSa1EME4l4G83RdP22pq3aGsEa0GNOv0Skjw0YK0sJGcGUWJi BxuOMQHLsyXPSUVL2HhCCbLkRc7Uq7Z5EoyhULX7WTTL5lGoE/e7R0GKHDV0Jw2re9GJqccKxGBh vTq+7jXRZL8S5eSGJuAIsh8bwNcBf+EQTdhekkxvZsNutnk4I5ttbs9IW/0HAMHxo0B1oy361hy3 N0c7wjlapUUpHL2rs88tqWqwE83X5mX3u14Z2ozqmw3RXs+kUNo6Uf1euaQ/0iq39liPzgjjILa1 R1zHs303eOmXKIpcHwXQO44f2baWOLVaq24SuZ/V+QG9+gx/FSs04a1cygNnytvgE5oAcvgBbjnF jGGV+WkJGVPKOWcUMqpjRk7mvMg+E1kTlheSfKCtZIJIFT0tqrwBEBKY71SyKn+kgn58pRmdRxP4 MrijRwhLzc8/s+T1LC23z/qb7iWIarfPmiiIbAi7ntu3E+Z4kRN2jHlxHMKd8JKxEOhSlCrGosBF ae0EnQjKeB0/vT/OMoY08R13IHBIScWdypyiyiH71ZLyNbAFkQdZDAq293DbKZZztgIScLOtIcsX BefqAa84NueC7CiHi2KPNwMwWFRS70SBfYSq7kMUVuyd6AEue/2w7PChHli6A1Q/iNAz5PrwIsgO rzfgHTm+SrPrw4sgO7z+gPcYhtcHGFF2gIMTwLEbq7S4PsCIsgMcDoBdN4bMvcoQRpQd4OgEcOR7 V5pziLIDHA+AEe2VJh2i7ACPTgCHQaTu/uuLYUSpruq+3iP6C5R7qJf/V8X3+4qfUsnII6cZ29Q8 h57Du0TlzyU0Ob9Bi035CuqSqv66MGPnqryHi6VyJPYnqoEaepazNXroqlbQX2Oz/LuTxrM0siMz Hc0Xpm9Pb82ZPw/N+ShOpxDywdwe/WF0fWMOpsqiZItivRXsYSsN5O37zZkGh+2XZzk+zBSON3Rj AAW1XLYfC3p2FnWNfeApP/4l+FlBI6MI+mVLBXyh5+g7LRow8GaOLuuRsPeIGqXI/bZ8fuUX1cvD 7NUPDv9ptICZFVSfdY3qiNWUcbnwnYULJwjc2HSd9Nb0F9OpGdvOrRl6fpqm04U/c2fH8G1xiKwA 3b+N2q9f/vzp65e/LhCzqpvWAywsccxVMyoXH2jzsFOXOMz1EE/Qy8JWA5M8NuMgOoigjv4/A5O/ AQAA//8DAFBLAwQUAAYACAAAACEAXAN7LZ0HAAAyLwAAIQAAAHBwdC9zbGlkZU1hc3RlcnMvc2xp ZGVNYXN0ZXIxLnhtbOxab27iRhT/Xql3sNyPFQv+i0EhqwChXSm7G22yBxjsAdwMtmsPlGxVae/Q G/QWbb/1KHuSvvdmbEwCu0QhUhJFisCeefNm5v3e/3D0ejUXxpLnRZwmPdN61TINnoRpFCfTnvnx ctQITKOQLImYSBPeM695Yb4+/v67o6xbiOgtKyTPDeCRFF3WM2dSZt1mswhnfM6KV2nGE5ibpPmc SXjNp80oZ78B77lo2q2W35yzODH1+nyf9elkEod8mIaLOU+kYpJzwSScv5jFWVFyy/bhluW8ADa0 euNIx3C/8EJE+D2eqs8PfGLE0Qqk1GpZ5vER69I9+UDkxpKJnjmeWmbz+KiJS4BYP+HiIrvMOcen ZPlTnl1k5zm+hO+W5znwBJamkbA5yBcZ0IQmo9cEyBTjjeXTkhPrrib5HE8E4jHghIDiNX7CItbl K2mEajBcj4az91tow9npFupmuQFcrdoUb6VudPs6dnmdy1gKbpwLFvJZKiLQFRIR3VAtAylmZ2l4 VRhJCndGUairgnBKxnh/3CqbGfI6AylJZKvp1CScLKnoC5JveehKKq7XBqUj0dht13eCTfkEtt3x cR6lZFmu04IXPMuaUZYX8ieezg186Jk5DyUpAlueFVKRliSEvjpI1pWrfhpdIxhj+AbMweJg/SzN P5mGeJMUPbNjuS7sLemFTmoaeX1mvDEjxSAFlYMVLAmBT88MZU5nScDaThYyncT6RGpL3FwU8kJe C05qAeCxLogVPuBAgqHB86Tx8QIMfi4HgjNwCFqF5PFAxOGVIVODR7E0tN0TDOAegCVKSZKsiCVP onOWsw83OGsRkWxKmQBySpF2q5NTqRPqcl2bbATovtqEAjK1ad9HqSzQHlQwEm9pdRta5Xq21/Gd x69VqBZ3UiSwOEMsSSPp+vdULJQe6VWxoVigZKS26qPckjzGHXT5godpEhmCL7nYgz3p2B3YX87i fH/upAx34D5KF7mc7X14V2nj3nCM4slW7hBGDmrSbmnSQyY3AwQJ5L4mHUnwYp/AwzIx0aZNMFKY wGByx3jhOx783TBt23KcKmA4vmfZ3uO37I14QaZaRgWKEEthoSkzMQXvL0wci/gE/TiK00L3hmNF KuJoFAtBL5jurdMguVLZkYwTqRKjtrcOpVXORMGixgdsW+1EE+BL8CDqWYct3IssfyIiypp+t4ZB f9hutRvDzmDUcFsnp42+O/Abg04wPHHsljdodf6AoEpJQwSaJuM5H8XTRc7fL1To/nbwg2OQnOSx 07RcSDktZ+014Ch4rMMah1caxyhNMb+uRzwy6PuaxwRyBQL01wXLYQdtIiowYSa1r4k4lu2WOdV2 Gwk63rO2kTLtenxWclid9EudvADL58a7xXx8QzPJ+d1XM6GoBNbblJMU/07+2/c88AEq4d+unM/d gauK4PGpZuXA+/7I8jw7aNjW8LThjk5OGkHLOm34jjscDk9Gbt/uVw68QM1LQDvQ497Fb3/5/PcP Xz7/cwCvTcWKquXhsewQhCJ/yzID6n+ImRJqeQiBPTO6gqfx1MYxKIjlCp6iK3hiYQhNB6DQD+UI zKuRisYpR6ACUlNuOQIJlBrxyhGIGmrEL0fAZmciTq4gD8Iv05ik4mc1UD5hwkKtnDN2nS7kmwgK 2RsjFGpty227geO7HShLu9iyyN9EupYHmy1Xb9BCvrSm1ZXaTlqQVcVXp4A7aUE+Fa2OhztpQXIV rfZQO2lBphWtf0sym3cDaVe07W/QAg4VLTUdNiS+ybddo+18gy/05iq+FiWnX2G8AVzZZKmJQgMv V9QiKFAJqL6nV7Q4nZLp3BDjngGe5ZKNLyAzpPYF4i1VV4Kzs6Sfg+YBrtidS/QrkMyg1QAtwPNF EkIPRHfSsrCPHTPsBoXnoc4b6UqQF8KYnh0v3kEbktKxmleDzgnwveI5tjD3TVGBCbKuJ7J0UMoW J9Cw6pk/zn9pCIkgQIbHbkxwpibC4sZEWODErnR2U6rQKoTmwy0Rz1l+1jMd1+7gxeIE3B6IqlEO lNn5Q8sfRAn7a0HVMBilkNljUq3EdJLHTJhGFstwNmLzWED/zAFbCmcsLzgcXNdN48UARmi4Z375 /JeSXw1HFa0fAsdkF45JYweOSeOrOJI52FgqKazagBX6uworO/Cg7AGXrCupp43Vn7ewsoOHsrkD YoUAadflrLEqe7s1sOyAipTnAdZtw7IfzEEeECxESIPl1sDSTdXnCtYWy0Kn+yDR7IBgIUIaLG8N FnRc2qRqazf4jCzrv39ve8GngBUCpLHya1h5lktO71litS29wHTm0RsWIqTBatfA6rQtCrgvYH2t 7bxXTn9AL4gIabCCNVgqTd9IBp+RF3yyloUIabA6NbCCwKcm4YtlPSbLQoSgiN6oj7NuKmc8r6pl qBzPFaS6hqz/iKEqwTVJ2b1Q5dqDFGa1SlY56ydZyZa/kjl8LfTU5LO9eiw7XS/y2VGwOW38IcxD dD6emgJtL5KswA4ol3vRoB2VCWVLLxoEIWtHNdB2Vav0RYN2ZOCQ0VEf4kVAO7Je32u/OGlq4leZ Zj25hMRz/Y8w/Kdv+Vv34/8BAAD//wMAUEsDBBQABgAIAAAAIQCMEm8JcAUAAJIbAAAhAAAAcHB0 L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDUueG1s7FnbcuJGEH1PVf5BpTyzoLugDFsGTF68tiuw HzBIg1FWt0gDNkmlan8r+Zz9knS3NCBua4F52KrwAkIcHfVl+qindfPxNQqVJc/yIIm7qvahpSo8 9hI/iJ+76ufJqOGqSi5Y7LMwiXlXXfFc/dj7+aebtJOH/j1bJQuhAEecd1hXnQuRdprN3JvziOUf kpTH8N8sySIm4Gf23PQz9gLcUdjUWy27GbEgVsvrszrXJ7NZ4PFh4i0iHouCJOMhE2B/Pg/SXLKl ddjSjOdAQ1dvmyRWKXgrXpLJ6+QleZz+rioEzpZwWlN74L83Dn0lZhGcGCRRyrIgT2L6J08nGeeI iZe/Zuk4fcrogoflU6YEPhKUF6rN8o8SRj9jgMFBc+fyZ8nEOq+zLOrdsA5EQ3ntqpC0FX7CRazD X4XiFSe9zVlv/ngA683vDqCb8gZgwfqmkO+08GjfHV26MwlEyBVt7VUBZXDpfeJ9yZU4AT/R/cI9 72EpydBnpE/nShl6pCpxxZ8UD4nPIaYULPHaT/wVOj6FbzrJOmEuxmIVQgrgeBlqlADW8fnstyK0 ldPgbRUOTrIOmAIfkKyQYR3wuPF5DHUQiUHIGdRJGWrRG4SB90URicL9QCifWC54pgiKQo4G3AC7 gFSWlDz2n1jGwIgtZowG68CdwUXpDxwWAT8edmMddsz5U8g8Pk9CHyzQL5EBjKcKyxXWkkzYkURg tHaWpGk5UOC0LjXLsDTNQJM2q9NsmS3NBXHBNWobbccmmyEMBRG5XywJGRGZYYXF3jwBtZgWlNXs lclWIpbdU10EsQ8Fjod49+niAVSMDCnWgpL/2VV1Ey2dSjcra4MOdVg9JaH0qhZra58VqdAOMNPY sLY1kyyow6q5+6xIVbKaG1bNcDQbwbVoCbkdAuQqaa0Krau7ZMO5tMhV0tobWl13wYR3WItcJa1T oXVMg9bhudYiV0nrbmiRs37KDsQWuUradoXWtpx3pQy5SEuqNUGKhjeBVbeWLrr7+QqHgkMCl28p 3DkqZkoVGySxgFrdEjJSDXjUygfFiY8SrO45C2eljBUSg49VChMeVJ8nmJDjMqZrjuk61ndkzGhb GhQHIuroGMlQNVF7T6qNOhWUFQAcSjGpKhmW0BorAYCVElHBkpKssRIAWFn3VSyuyjVWAgAri/ko VgIAKyv0KFYCACvL7ihWAgAra+koVgIAWxSI7AQoviSSa99+jAqiZgA+ZNHS8/eEtmTMvST2lZAv eXigQHfpqS5OoJ/Mg6w+e/nkr604o2SRiXlt482iIuvTB7OD7NCbXLQ7s6SuTXa7M7L4fFEr+uOi O0OB+2PBMmg7S42jaFOrXFvjbNNq6WAudGLHejXNAeW79mpd9dqrQb987dW6qvF/7NVsqWmHejVq jc6XtX0pI508W8qO9WsbKbv2axjz7f7n2q8dmel8d8ez21Bd+zUcoRW7wd3Y/Kj9miO1bcgE39qE 2thhni9sRb/mCxggbm9HtWJPdXQ/SnfdnX7Byc3Akn7Q/n4Gs2icLP+lDd3+0Gk5jWF7MGqYrdu7 Rt8c2I1B2x3ewtzCGrTaf6vlkNUHV0UQ8VHwvMj440KoyP72WAA2JnRr0TOamglTeM3YbDPAFGS5 bDcNk8Ji1D5KEpyxVqedziXyMxPQQe8/g7Q3Rp+n5OiyEWnLiIzDwOfKwyKa7sSFJhHvXbfwlgeo D4bmjXHKKaFZL9++PdIsS3cbuja8a5ij29uG29LuGrZhDofD25HZ1/vr5Zuj5zFYd+qq/fb1n1++ ff33AmuW5tTF2x44xFdCJBVh9omlj0valMKbMFixAzqVwrsviAtCNxDkkO/Sev8BAAD//wMAUEsD BBQABgAIAAAAIQAuZXpP2AIAABQIAAAhAAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDYu eG1srFXtbtowFP0/ae9geb/TfBAojYAKCOxPW9BoH8BNHBLVsTPbMNg0qa+1PU6fZNdO0nZdJ3Va /oBj33t8z7nH9uj8UDK0p1IVgo+xf+JhRHki0oJvx/jmeukMMVKa8JQwwekYH6nC55P370ZVpFh6 QY5ipxFgcBWRMc61riLXVUlOS6JOREU5rGVClkTDp9y6qSRfALtkbuB5A7ckBcdNvnxLvsiyIqGx SHYl5boGkZQRDfWrvKhUi1a9Ba2SVAGMzf69JH2sgK0uNKMrzo4Y2VC5h0kfT4B9smEp4qSEiWsT hWyYWVHVtaTUjPj+o6w21VrahKv9WqIiNQBNInabhSbMfnIIg4H7In3bIpHokMlyMiIRaIEOYwwt O5pfSCIRPWiU1JPJ02ySr16JTfLFK9FuuwFU8LipYVUz+pNO0NKpdfAfWdWhBFIvRHKnEBfA09Cv 6SVX+xbMcDbwVY6eCd/E1YtWjzZegaZWLH2YifRoiN/Cv50kEVN6o4+MWkGgbBIBOPyA/IwYX1Pu 3GzA16WeM0rA9414ejJnRXKHtEA0LTS6JEpTiawL4BQA5AjU0dCcBpLydE0k+fQC2fAjEewMRbcV wrCW8O9C9lohY6IpWjOS0FywFCoIutA01UD5KxwLwjIMRgSX+Ja4ldY04L80zuA8GHd/8+PhLD71 Tp34bL50Qm+6cGbhfODMz4bxtBd4/bl39h03jU6Bqi5Kuiy2O0lXO43f1qraAKYZPdcP4R7we0+9 gVIMSrfdCdvuLIUwrnjen14X/cm0rBv0eUck7ND2qD0vHZyDbhXpt4psWJFSdLUrb1/oEnahC7wz AP2qNPZcdGzf2WDp9/vB0An8eOGEy+nUGXr+whn0wjiOp8twFswe7asMcw7V/atrH+5/fHi4/9mB Z+3FUr84MDTPkn1UmLwk1Wpvbz54i8FPcztVwevb3L9PIQajfc0nvwAAAP//AwBQSwMEFAAGAAgA AAAhAJMRAz+pAgAAwgYAACEAAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0Ny54bWysVe1u 2jAU/T9p72B5v9N8QCmNgIoQsj9di0b7ALeJQ6I6TmYbBpsm9bW2x+mT7Noh7cY6qdP4A87Nvcf3 nHPtjC62FScbJlVZizH1TzxKmEjrrBSrMb29SZwhJUqDyIDXgo3pjil6MXn7ZtSEimeXsKvXmiCG UCGMaaF1E7quSgtWgTqpGybwXV7LCjQ+ypWbSfiM2BV3A88buBWUgu7r5Wvq6zwvUxbX6bpiQrcg knHQ2L8qykZ1aM1r0BrJFMLY6t9b0rsG2d5xEPeU2DS5wYBPJ8g8XfKMCKgwENkME1TNjWTMrMTm vWyWzULa3KvNQpIyM7X7GuruX+zT7KPANFy4B+WrDgnCbS6ryQhClIBsxxSd2plfLIKQbTVJ22D6 HE2L6xdy02L+QrbbbYAdPG1qWLWM/qQTdHRi0IwsOKSsqHnGJPGfCLZVgCiXdXqviKiRslGiZZpe bTpcQ9/s1BSklT7TOHhf0ETgOUX9kJxvyVqFTLJddPUK5bY66m1UZzujyR3+2yCEXOml3nFmtUJG EObooDHlqx8Po/jMO3Pi81ni9L3p3In6s4EzOx/G017gnc6882+0awqp6rJiSblaS3a91jgOEEo0 GMcADwwTzu0S+670jDPAA7W3p20OQj3puX4fp9bvjVBwjSRsK9ZCkS1AwscDMKMUhNgz0u244bL1 5e/u9Dp3krrW6Mmv/gTH8CfXsjXo0xok7tB51HnbGvpfHrGjKtLvFFnyMmPkal3dHejSO4YueCsi 9IvSWN2tIscb32iQ+KenwdAJ/Hju9JPp1Bl6/twZ9PpxHE+TfhRET+OrDHOB3f3r1D4+fH/3+PDj CDNrR7e9KHFpLlJ7F3L5AZrrDZ5qCPHLgfM0s6EGvxX7u+I5xWB0357JTwAAAP//AwBQSwMEFAAG AAgAAAAhAK+u3U+yAwAACAwAACIAAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0MTEueG1s tFbNkto4EL6nat9B5T07/sE24BpIAR72ksxMBZK7YouxK7LklQSBpLYqr7V5nDxJWrLFZBhSgR32 YozV/an7+7pbunq1rSnaECErzkZO8NJ3EGE5Lyp2P3LeLefuwEFSYVZgyhkZOTsinVfjP15cNamk xWu842uFAIPJFI+cUqkm9TyZl6TG8iVvCIO1FRc1VvBX3HuFwJ8Au6Ze6PuJV+OKOZ2/OMWfr1ZV TjKer2vCVAsiCMUK4pdl1UiL1pyC1ggiAcZ4Pw5J7RrIFohRy0pRMmHFcusgYy82sBI4Y6AgX9AC MVzDh/dgWuWYImOPgDG0JFtlzGSzFIRoB7b5SzSL5k4Y75vNnUBVodE6FMfrFjoz85eBGbx4B+73 Fgmn25Wox1c4BXbQduSAiDv9BCecQhAobz/mD1/z8vaIbV5eH7H27AYQwX5T0L9pM3qaTmjTOSAl 2KfX+mDAeM3zjxIxDglrHto885uNRdXJ632aErWaKK2Hg7ioQLlWos6rNTU0WW9pqLbx7wlKknAY +S1NYT9KeoPHXIV+3DfrmrF4EAdxGJtNLBJs0kI3qdpOebHTTH+AXxBUF83IIVgn38JSqRZqR4nR A1jDKaQEDzCmWDcaYe67BTRarWaUYGjETjs1ntEq/4gUR6SoFHqDpSICGQqgLQHyCsRRUBsdJGHF HRb47QGyZhWnsDPEbeM1KWhmf61j76mOupruKM5JyWkBoYQ6Q2gEK9h/klQTd6AotAXUrK2H05WN 4j4MFlP/x4RN/GA40Ov/l7BQb4hu6F7BZwqt6TY6y0dCt2IaReFhtzRsnVFbC5JzGFOUbAg9Ad5I fQb8sqzE6ei9tlVO5mvO10KVJwcfnQtfrY6iwzy9aItFtsUyrMijzjKEPLezCgVT5TMchZiunK6n zGwxU1JPVvPy87g0/WyHhB1qZnI9HWMrOP70+fUlyAbTrO/33Ww4m7uRP7l2p9EscWfDQTbpwTid +cN/nG6CF5Cqqmoyr+7Xgtyu9SF5yjSEQjdxqHHPCyI4+4PeQ9lCKBrlsurEVp0553rw/jz5TEU9 V5+VEq1Af6+xgB2sRr8ZfOdodFlGEsvIglYFQTfr+sMBL+agfC4vcLcE6KPUmDF04fKdJvMgjsOB GwbZtRvNJxN34AfXbtKLsiybzKNpON2Xr9SZM4ju3Kr9/vXfP79//XaBmjVnd3unhFd9CzWHMBVv cHO7MTMU7t9QTzPzqYEbN5SMNn0w0Rj2Bj/+AQAA//8DAFBLAwQUAAYACAAAACEAgTbFA2QDAAAo CwAAIgAAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQxMC54bWysVtty2jAQfe9M/0HjPju2 uYV4gAxg6EsuTCF9V2wZayJbriQotNOZ/Fb7OfmSrmRESkpmIOHFGHn3aPfs7pE6l6ucoSURkvKi 6wRnvoNIEfOEFvOuczcbu20HSYWLBDNekK6zJtK57H380ClDyZIrvOYLhQCjkCHuOplSZeh5Ms5I juUZL0kB31Iucqzgr5h7icDfATtnXs33W16OaeFs/MUh/jxNaUwiHi9yUqgKRBCGFcQvM1pKi1Ye glYKIgHGeO+GpNYlZAvEqNnKQcZOLGElcHqQejxlCSpwDgszqhhBQBD6CsY0xgzNyEoZM1nOBCHa oVh+FuW0nAjjfbOcCEQTjbZBcbzNh42Z+VuAGbx4L9znFgmHq1TkvQ4OgRW06jpQvLV+ghMOIQgU V4vx82qc3e6xjbPRHmvPbgARbDeFupdVRv+nU7PpVKQE26wqUwyuVzx+kKjgkKdOv0ovvllaMJ2z hi8zVJVAaX43dtVHw4e1l8CpIUutBjxZ68Tv4dcs4pBJNVVrRgwhEDYOARweQD/DusNJ4d5NocNz NWQEwwRsyFO9IaPxA1IckYQqdI2lIgKZYGAeALID7CgozgaSFMkEC/zlBbLOD4ewMwRtI4TXisLX iaxbInd6Ck0YjknGWQKh1E5BrqbKQVxQGIKq2x3oS2gaW5ljGNcyAigE66B1dPv4h3IhtmRbot9Z D93kphxypx4V54Z4eNgtTVJHtMCUxBzmmpElYQfAm4ocAT/LqDgcvV4xejBfY74QKjs4+Max8DTd iw66c9JJaNhJiLAiOwNgCAEpttrxJnVJFAz/DzgqMEtt6xsJMCKjpehdapPCMaF1/mcQtQfRuX/u RhfDsdvw+yN30Bi23OFFO+rXa35z6F/8cjaSl0CqiuZkTOcLQW4X+jA5RLQqKdSyVPeCBpyNQf25 bSEUjXLa6jRtdcaca338V6BMR723PqkSVYG+LbCAHWyN3qJPryjSaRlpWUamjCYE3Szy+xe8NE8h 3HD3Aui91BgZOnH7DlrjoNmstd1aEI3cxrjfd9t+MHJb9UYURf1xY1AbbNtX6swLiO7Yrn16/P3p 6fHPCXrWHLHV3Qte9W3NXK+YuMbl7dJoKNxPoZ+GZqmEG6k+qcH02URj2Btu7y8AAAD//wMAUEsD BBQABgAIAAAAIQDvjMzfrQQAAIwRAAAhAAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDku eG1srFjbkto4EH3fqv0HlffZAfmOayDFZdiXyQwVyAcIW4Arvq0tCGRrq/Jbu5+TL0m3bAGeMDsM 8QsY0zpSd58+3fbd+30Skx0vyihL+xp919UIT4MsjNJ1X/u0mOqeRkrB0pDFWcr72oGX2vvB77/d 5X4Zhw/skG0FAYy09Flf2wiR+51OGWx4wsp3Wc5T+G+VFQkT8LNYd8KCfQHsJO4Y3a7TSViUavX6 4pr12WoVBXySBduEp6ICKXjMBJy/3ER5qdDya9DygpcAI1c3jyQOOXibR8FirxFpVuzgBtUG4Hkw j0OSsgRuzKJAbAtOvkRiQ8Ysx3NImzJfFJyjdbr7s8jn+ayQSx93s4JEIULVEFqn/qM2kz9TMIOL zrPla4XE/P2qSAZ3zIeIkH1fg8Qd8BMWMZ/vBQmqm8HpbrB5umAbbO4vWHfUBnCC46aQ87zy6Gd3 DOXOIhIxJ/ToVWXKYOlDFnwuSZqBn+h+5V7wuFNg6DPC5xtShV8gVG1X/SnjoexLGVN10GMkqNsz DA94C55bHrCs+ywqtuU5FtwkGBvbcVzTk5soJNikgs59sR9l4QFDuoRvyBxLg00GTF3iCubHpZiL Qwx5hutdTOFEhMVrKKUYWMD8kK8+wq3ya18DvsOWS+X50R6S3MSBEDMfAgEfsDRmWIk81T/NoRIT MY45A/jaJTEYx1HwmYiM8DAS5AMrBS+IDBzULZwM0YXcQ0LyNJyxguGhzpExF8yHncF35bMMA+bj 5aSbKumqDGYxC/gmi0M4hIEhgmJRCb6JAlCBGpQLcFkR5jYiONRwXbtKmqqOBg8sSpEs1xLhxewn rHiQ1RilIUgLXmIql9tH0E+56owTJpCi3rFmD9rCpYFEqqAs20Urcg2ecfKgBqnxzBNej1qS/Ffh oWXFDcBDkBrPOuFR06VYYtcdEIvgCIgoNaB9BuhB9d4GiCg1oHMCBDWAA950QkSpAd0zQNeSmbvB ZUSpAb0TIKJdn5RGDBGlBuydATq2e2NSEOWyJrWrHZbSjgXW47lwmMiQXxUO1GsQTBDeDYtXtYZI SZI9RPqIzXUu3VWKr1rAxWZim9Aqql5xarENEfG60FqqTRTS/zQTqQaXOsibNIQ2ahQ7UE2HGzWE NjQJQWq8GzWENujagob0WpaQBl4LCtLAa0FAGngt6EcDrwX5aOC9rB5AJAJN5Di6SFrdPuGgaMgB p2xMOLdMMbZSogkTvKFEVhtKFIqfdIhWTRD156IQSf1Tc5iaPRtyIX/ISXEFzyL4PPE3nXijidt1 9UlvPNWt7vBeH1ljRx/3vMkQOow97vb+0erROgRXRZTwabSGx5enrdCwyl9PB2RRbi0GZoda8PxF zVP84SiI0m6fcFR2plmGs+15p5AD3a92ipUoqgT9tWUF7KDmzVcGzrfkqN2IuCoi8zgKOXncJstn cXHa4C083wP0xdC80kffEpojfUfOlNq24ekGndzr1nQ41L0uvdcd05pMJsOpNTJGR/qW6HkKp3sr a79/+/eP79/+a4GzsrFXz/hwia8E5NASFx9Y/rST6gbvQIBPY3krh7ceEBc0PZkghnqLMvgBAAD/ /wMAUEsDBBQABgAIAAAAIQD8flBv7wQAAB0SAAAhAAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxh eW91dDgueG1szFjLktpGFN2nKv/QpawxtF4I1YBrgCGb8cxUwB/QSM1IcesRqcGQVKr8W8nn+Ety b0sNAmMjZmaRDQhx+vR9ntvSzfttIsiGF2WcpUODvusZhKdBFsbp89D4uJh1PIOUkqUhE1nKh8aO l8b70c8/3eR+KcJ7tsvWkgBHWvpsaERS5n63WwYRT1j5Lst5Cv+tsiJhEn4Wz92wYJ+BOxFds9dz uwmLU6NeX7RZn61WccCnWbBOeCorkoILJsH+MorzUrPlbdjygpdAo1YfmyR3OXibLX9fbA2iYMUG blBjBJ4HcxGSlCVwY5KlEhjI51hGZMJytENhynxRcI7odPNrkc/zp0Itfdg8FSQOkaqmMLr1HzVM /UwBBhfdk+XPmon521WRjG6YDxEh26EBidvhJyxiPt9KElQ3g8PdIHo8gw2iuzPort4ALNhvCjnP K4++dcfU7ixiKTihe68qKIOl91nwqSRpBn6i+5V7wcNGk6HPSJ9HpAq/RKoaV/2p4qHxpYqpNnQf CdvpQ22pcJh9q+ecxMTq9TyLWgbByFDqmjWi6XHFnPtyO87CHUZ0Cd+QOJYGUQaFuqziLEo5lzsB aWa+2AgKBhEmnqGTBBQB80O++g1ulX8ODTAJbFpqx/d4yDFcN3ggwsyHOMAHLBUMG5GnnY9zaMRE TgRnQF/7JEcTEQefiMwID2NJPrBS8oKouEHbgmXILtUeipKn4RMrGBrVZMZUMB92hvhqn+Gyyvb3 cw5BPO6CJ8ECHmUiBCPM11VAHEL96iJpn3zL6TuYUGyGc9l3KKWAqLLveI5FoRQq96uGUm5Xdagj obOvWquZqjrlJ5m2sPoqygYALs26XptV4TWxGgBY6wzWbmI1ALD2GSxW294GDQCscwmrAYB1L2E1 ALD9S1gNAKx3CasBgB1cwlaAcz0EKwkw7JvllT2FmqpaqjzqqapvVPPAh95SFe4VbTznQZaGRPAN Fy3oVW9dQb+I4qI9u2qIK9hn2bqA6dfWeBsL8xr6eHWWHcbcm6qZrdVsgaluSpkKCIx9PapeNMxw goCEwyiImFgZcAYAgVOJVEMNJUddzFXFo/jirR9NN2pbDq36/DDyj8ab7Q5oz321wJGEFffqiBGn IZx28BJNW64f4FCostnQNHqkUzgTEQudiPJWU+kZ3YrvSE9PNLLmG1AbdyWt+I608URHaz5q9anb lnDwA63VfJ7podS3MvCI70SPaz7T9MC8l/CdaLbm69tqbF1v34mu13xI1johR/6eaL/mc53+y/Lx /5gP0Nn6NKEOGHjM/f65ytFKNGWSHymR0s7XKlEov9EhWp0W8GnjrBBBjx88OHseUiqgzq4reDjC B5y/6NQbT/u9fmc6mMw6du/2rjO2J25nMvCmt1AhzqQ3+Nuoz/ohuCrjhM/i53XBH9dSKczlIzBo itpajqwuteGBkFqHAQqmoPa87ZxwdXZmWYan7eakcHC2vTY/K1lUCfpjzQrYoZ4V9MJp+JocvW1E +joicxGHnDysk+VJXNy3iAu8cADqs6G5MEevCc2+fMfujDqO6XVMOr3r2LPb247Xo3cd17Kn0+nt zB6b4335luh5CtZhvV1TtV+//PPL1y//vkHNKmGpXjrAJb6jUKUoig8sf9yoIQwvZaCeJupWDq9h IC4IPUCQQ7/WGf0HAAD//wMAUEsDBBQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAcHB0L3NsaWRl TGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDUueG1sLnJlbHOEj8EKwjAQRO+C/xD2btJ6EJGmXkTw 4EX0A5Zk2wbbJGSj6N+bYwXB4+wwb3aa/WsaxZMSu+A11LICQd4E63yv4XY9rrYgOKO3OAZPGt7E sG+Xi+ZCI+YS4sFFFoXiWcOQc9wpxWagCVmGSL44XUgT5iJTryKaO/ak1lW1UWnOgPaLKU5WQzrZ GsT1HUvzf3boOmfoEMxjIp9/VCgenaUzcqZUsJh6yhqknN95LmpZ3gfVNuprbvsBAAD//wMAUEsD BBQABgAIAAAAIQD5zwk5gwYAAFwbAAAUAAAAcHB0L3RoZW1lL3RoZW1lMS54bWzsWU9v2zYUvw/Y dyB0b2MndhoHdYrYsZutTRvEboceaYmWWFOiQNJJfRva44ABw7phlwG77TBsK9ACu3SfJluHrQP6 FfZISrIYy0jSBtuwxYdEIn98/9/jI3X9xqOYoUMiJOVJ26tfrXmIJD4PaBK2vXvD/pUND0mFkwAz npC2NyPSu7H1/nvX8aaKSEwQrE/kJm57kVLp5sqK9GEYy6s8JQnMjbmIsYJXEa4EAh8B3ZitrNZq 6ysxpomHEhwD2bvjMfUJGmqS3lZOvMfgNVFSD/hMDDRp4qww2GBS1wg5k10m0CFmbQ/4BPxoSB4p DzEsFUy0vZr5eStb11fwZraIqSVrS+v65petyxYEk1XDU4Sjgmm932hd2ynoGwBTi7her9ft1Qt6 BoB9HzS1spRpNvob9U5OswSyj4u0u7VmreHiS/TXFmRudTqdZiuTxRI1IPvYWMBv1NYb26sO3oAs vrmAb3S2u911B29AFr++gO9fa603XLwBRYwmkwW0dmi/n1EvIGPOdivhGwDfqGXwOQqioYguzWLM E7Us1mL8kIs+ADSQYUUTpGYpGWMforiLGR0JqhngTYJLM3bIlwtDmheSvqCpansfphgyYk7vzcvv 37x8jt68fHb8+MXx45+Onzw5fvyjpeUs3MVJWF74+tvP/vz6Y/TH829eP/2iGi/L+F9/+OSXnz+v BkIGzSV69eWz3148e/XVp79/97QCvi3wqAwf0phIdIccoQMeg27GMK7kZCTOt2IYYVpesZ2EEidY c6mg31ORg74zwwxX4DrEteB9ARWkCnhz+tAReBCJqcpc7mh2K4od4B7nrMNFpRVuaV4lMw+nSVjN XEzLuAOMD6t4d3Hi+Lc3TaF00iqS3Yg4Yu4znCgckoQopOf4hJAKez2g1LHrHvUFl3ys0AOKOphW mmRIR040zRft0hj8MqsSEPzt2GbvPupwVqX1Djl0kZAVmFUIPyTMMeNNPFU4riI5xDErG/w2VlGV kIOZ8Mu4nlTg6ZAwjnoBkbJqzV0B+pacfguqR7Xb99gsdpFC0UkVzduY8zJyh0+6EY7TKuyAJlEZ +4GcQIhitM9VFXyPuxmi38EPOFnq7vuUOO4+vRrco6Ej0jxA9MxUaF9CtXaKcEyTy4p85oq8LWhl SuyeqMPLcCerb5eLgP77i+8Onib7BOJ9cQe6rL2Xtdf7z9feZfl81oo7L7JQf3WfYxtk0y7HS7vl MWVsoGaM3JamYZawYQR9GNTrzEmRFKenNILHrMA7uFBgswYJrj6iKhpEOIVmu+5pIqHMSIcSpVzC Ic8MV9LWeGjYlT0iNvXhwdYDidUeD+zwmh7OzwgFGbPthOYgmjNa0wTOymztWkYU1H4bZnUt1Jm5 1Y1optQ53AqVwYeLqsFgYU3oRBD0L2DldTira9ZwSMGMBNrudhPO3WK8cJEukhEOSOYjrfeij+rG SXmsmFsBiJ0KH+kD3ylWK3FrabLvwO0sTiqzayxhl3vvXbyUR/DcSzpvT6QjS8rJyRJ01PZazdWm h3yctr0xnG/hMU7B61I3f5iFcEnkK2HD/tRkNlk+92YrV8xNgjpcWVi7Lyjs1IFUSLWDZWRDw0xl IcASzcnKv9oEs16UAjbS30KKtQ0Ihn9MCrCj61oyHhNflZ1dGtG2s69ZKeVTRcQgCo7QiE3FAQb3 61AFfQIq4ZrCVAT9Andq2tpmyi3OWdKVb7IMzo5jlkY4K7c6RfNMtnCTx4UM5q0kHuhWKbtR7vyq mJS/IFXKYfw/U0XvJ3BlsBZoD/hwpSsw0vna9rhQEYcqlEbU7wtoHEztgGiBe1mYhqCCi2XzX5BD /d/mnKVh0hpOfuqAhkhQ2I9UJAjZh7Jkou8UYvVs77IkWUbIRFRJXJlasUfkkLChroHrem/3UASh bqpJVgYM7mT8ue9ZBo1C3eSU882pIcXea3Pg7+58bDKDUm4dNg1Nbv9CxIpd1a43y/O9t6yInpi3 WY08K4BZaStoZWn/liKcc6u1FWtB49VmLhx4cVFjGCwaohQufpD+A/sfFT6zXyn0hjrkB1BbEXx0 0MQgbCCqr9jGA+kCaQdH0DjZQRtMmpQ1bdY6aavlm/UFd7oF3xPG1pKdxd/nNHbRnLnsnFy8SGNn FnZsbceWmho8ezJFYWicH2SMY8znrfIXKD56CI7egbv+KVPSBBN8XxIYWs+ByQNIfsvRLN36CwAA //8DAFBLAwQKAAAAAAAAACEAu2SW8wBAAAAAQAAAFwAAAGRvY1Byb3BzL3RodW1ibmFpbC5qcGVn /9j/4AAQSkZJRgABAQEAeAB4AAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/2wBDAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/wAARCADAAQADASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD+/iii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAr8zPjL8UvjX8a/wBt3/hh/wCD Xxn1r9mrwz8Nv2cPD37Sfxq+MHgHwj8NvGHxp164+JHj/wAX/D34U/Df4YJ8bfAHxV+D3hXQrWf4 d+NPE3xS8ReKfhf461zVbO48H+HPBQ8J3Uuv+IoP0zr4b+Pn7KnxO8U/HXwb+1L+zH8cvDPwF+PO i+ALr4NeO2+JPwZn+Pfwd+MPwbfU9W8VaD4Z8c/D7Qvin8CfHNp4p+HnjrVbvxT8OPGvhD4x+Gv7 GTXfGugeI/D/AIv0fxSsGk52f1zL51Izng6dTMHjadOfJOankWbUctek6cpQoZ7VynFVoKouahQq KUMRT58LX0uvquNjBwhi508EsHVqR5qdNwzjLauYqUfZ1Vz4jJKeaYTDydKXJisRQqRqYacYYvD/ AJd/tHftL/tM/s+eEv24f2a/id8b/iN8WNV/Z7T9gr9oD4TftH+HPCekeEPj74m+DXx+/aqg8FeL Phn478Mfs3+GPBegeK/HOgX3w18ZeGNNl+Enwo8Hr8Rfh/4n0fw3f+DdT8TjV73xJ93ar/wVO+FH gjwx8bb340fAz9pD4CfEj4I6R8GvEN78CvihpHwWb4j+PfDn7RHjiX4W/A/xF4D8RfD/AOOPjz4H DRPH3xVtb/4b3Go+OvjF4Gg+G3iawnl+MbfDnw9NY67d8v4m/wCCZnif4k/DL9pX/haX7T2q6v8A tRftV658Brvx7+0L4N+E+geFfCvw98Kfs3fE61+Ifwk+HfwL+BviTxR8QdP8K+E/CTP4knsm+Jnj z4x69qnjbxn4j8XeMta8W6PJp3gjT9HTf2Ev2iLzWv2i/i98Tv2if2cPi9+0V8ffg/8ADL9m2S88 afsYeLrv9lfR/wBnjwDrHjfW9b8EeJf2ZJf2wLnxH8QfEPxKvfid49bxp4g1H4/6R4VmhvNAsNP+ HVlpOla3pvipxVRSmpuM4Wp+0nTcaNSdJ4SSoxwH7idOnmFGpTwGBzDF5jSr4aNCGZZtRw2d4+pR w2IpewtXmlOHPjKFTD0ajlWcIxnlEMzeIaqU4xwOL5+IcflmGwtaNelV/sfL5yyjA0K8Kntfiz9t 5vhz8MfCfjL4pfssftLfDr4mfEz4tWHwU+Df7MuqXX7M3iz44/GDxxqej3fiO0j8IX3wv/aT8ffA nRNEj8NaL4t8R6tr/wAS/jd4B0vw1oXgvxFqnie40a1GjSax5d4g/wCCpPwu8K+EfDd94g+AP7UF j8Xde/agtf2Or/8AZjtfCXws1744+Efj3rvwq8Q/GjwN4e8Sy+GvjHrPwabwv8QPh5pGieIdA+Jv hz4weIvhpo+l+NtA1rx94t8GeH9F+ImseBfmS7/4Im+Dde/Z3j+EXivxb8ANV1vQP2prD9q34cfD y1/ZC0w/8E+/hz4js/Aknwy1D4YeH/2CvFnxl8Z2Vn8G/GfhnU/FPinxx4W0j47aJrN98avFut/F 3wt4m8HatLFpcfsvw1/4JfWXgrR/2e7WJv2M/hJf/Ar9snSv2r7uw/Yn/YXi/ZK+HvxHttG+B/xG +Dtl4R8UeBV/aG+Lkx8YB/iPe6zL8UZfE+oRnRtH0rwnD4DgKS+IJN6Spzrctabp0KmN4dhKdGLj OhgMRV4V/t2rS53ilLFZfh8TxdGs6tOtTxuJwOV18soUqNOWCzjKT5KcnTj7WpDLuIKkI1pfxs1o 0OJ/7DozdL2MVgsZWpcKShCDo1sJLE5lSx+Nr0mq+D9Ri/4KX/CzT/hZ+0b4/wDH3wc+P/wr8afs w/ET4e/Cfx7+z7410r4SXnxo174hfGDSvh5ffB7w78PR4D+MXjb4UeLh8U9U+J3hvwn4O123+Ktt 4Zn8Tw67aarrWk6fod/qcfY+M/27dH+HnxY8I+A/Gv7N37Tvhf4a+NvjF4f+AGiftN+IPDXwp0L4 KyfF3xXLdaV4Z8Mt4d1n4xWH7SNxo3iHxlbweBdA+Jemfs/ah8Jtc13UtL1fSPHl74FvY/GA4/4w /wDBPTRviv8AtsfCb9rMfEiTQPCfhZfA2q/GP4GN4Nj1rSPjr44+BsXxLuf2aPGOpeKZ/FFnF4Tu vgz4k+LHiXxT9ng8Ia/deK9V0XwAZNV0OPwbbfbfi/Xf+CJQ8R/tIWHx41r4wfAjWr3Qv20PDP7Y uifE3xJ+xdovif8AbfvP+Ee+JGm+OLb4AeLv20Ne+N1/qmp/AzQtDhu/AHw/8PeEfhN4B1fwX4U0 f4d6FLrXiHwp4S1/wr47nBv22LylY1QwmFq4pU81nSU6qw+BoZjw9ltbEcnPVrfXcwwM+KeIcHRw 08Xh8BTpZFh8XLF4r6/k1aMYnSwmarBt4nFUsFVnlcqnLT+sY/FZbm2No4eScadKNHKsxoZHk88R WdF5h9czOqqNGhHDZphaWp/8FJ/2iPH37N//AAUT8X+K/hd8ZP2OT+yx+0Pr3wy8FfHzQfAH7LXx nNjoHhXx98HtLXwPf/C6/wD2tPGC+Lfi/qWleMNVXxNrc1l4W+Etl4Y1i01Twt4luvGejv4dn+3v jh/wUs+GfwU8TfGayh+CX7R3xf8Ahz+zC3h9f2sfjr8HPC3w2174X/s1HWtE0vxnqcXjiw8UfFfw b8WfH994E+Gut6L8UviPo/7PPwu+NWt+CfA2r6bea1psGr3tvosnlPjj/gmh8QvF/gb9vX4LwftI +FNO+CX7afxVufjjo+j3XwC1PUvid8I/iZruqfCjUvFi3PxDt/jrpHhj4h+Ar8/DS5XQfDH/AAqz wT4j0GXxCkt9478RQ6P9k1O/8Yv+CcPxP8beJv2vfD/wy/ai0X4Z/s3ft+3uman+1T8LNe+AUXxH +KC6nqHwy8N/A34qXX7PXxsHxb8GaJ8Kl+Kvwc8FeEvDl/b/ABK+DXx/i8IeJbHVPGHgwaQdWTRd O5qP1hYPKItUvrdLhLKXivrEpujW4wo4HJ8Nj6Gb1KPPXWU1K0c4r1cRk3PiJVKWXVKXPVxWZVJ6 UlS/tHNpYh1v7PqcR46phlhuV1ocNVsxzKth1k8a8vZxzSjg55VTpUc4jHBpvMoSqRp0MuhLf+Mf /BVj4Q/B3xP8atOf4F/tOfEb4f8A7Ndt8Odf/aE+O/w48I/DC7+DPwn+H/xP8IeE/HXh/wCJN/r3 i74v+DfEvjzw5p/hfxTJrPirQvg/4R+I/wASPC2keHtW17WfAlr4e1Lwdq/ir2ez/bZsfFH7Rvjb 9nX4U/s7/Hz4xy/CbxH8PfCfxt+LfgzUP2cfD3wy+Dmt/Enwro/j3RIvFelfFv8AaG+Gfxr8R2Nt 4C8RaB4vu9b+Ffwe+ImiX1hqbaR4a1HX/Fmj+IvDujeR/Fb/AIJu6X8Q/g1/wUK+DOh/FM+DtF/b n+HXhj4c6ReN4In8RN8GNL8K/s/eGfgNp8zQXPjjT7n4jH7J4ai8QlLjUvB85Nx/ZUt5PJE2rz4P x4/4J3+O/wBoL9o74ZfGbxR8Rv2X/DGl/CHxb8L9Y8A/EHwD+xv4h8P/ALefhnwd8NtZtPFN18Lt B/bcuf2ptUttE8BfEPXm8S6L8Q/Dum/s+QaF4j+F3jrxn4Dn0db/AF688Xv20VQ+t4KnKVV4OWLh 9YxGIjBVaeHr4ihGVTF0cNKXtqOCwrqylgcA6OKxFZzrQzZwo0sDi8ZOt9QhOSpf2hLLcUqtDDuf s4ZjQoYCphvYVsReMY4/FVcyo+3q08RSwmHwuDjUwE6tStjKvC/8FQ/iH8Vj8Y/2AP2ffCfw1/a0 8TfDT40fH/xVJ8WNR/ZV+N3gf9n/AMVeM9F8HfAL40+J9M+F1r8Tl/am/Zt+LXhd7DxFpGhfFbxR J4e1nSfD+veDfBGoeG08Q614k1Gx8C656XYf8FTPg9Bofxq8Rj4H/tRW/wALP2ffip47/Zu1b4qa n4Y+H1zo3xC/aP8AAfxet/gVoXwF+EWg3Xxgu/jN8XPH/wAU/Gt9oNv8P/FGh/D2/wDhreza6mke O/iV4P8AHGh+NfDPhr66+L/wC/4Wt8XP2WPin/wln9g/8Mz/ABO8cfEf+wv7C/tT/hNf+Ez+CHxL +Df9jf2n/bOnf8I3/Zv/AAsT/hI/7R/s7Xvtn9j/ANj/AGG1/tD+1LL5H1b/AIJq22q/sy/Gr4CJ 8bNW0fxV4+/bM+IH7cfwv+LGj+BdLM3wk+MGp/tMr+1N8KodQ8Ea3r2uaP8AEfw78PvHVhomj+Kt N1DUfDqfEfwzbatb2h8B6jqlnqOi4Yf3Kiw9X2iwNT6xjMVXoKl9cnisRmvDOA5aUJcmHq1sDwzL iDF5XGvClQnmGXYGlmOKq0a1TD43et+9Ua0fZ/Wqf9n4HCwqqp9Uo4OnhOLMdiqtb2X79Qxeey4b w+Z1qTr43+zsTW/s6hzYOk8HB4r/AOCr3wl+F3g/44az8dfgB+1R8DfiF+z/AHHwDvfGvwE8W+C/ hf45+L2t+A/2lPido/we+FvxR+Gg+A/xi+MHwz+KHg+/+IF9rfh7WNL8C/ErXPiLomqeDfEOj3vg NdcvfB+l+KuL17/gsR8P/Bc3xvtPiF+xx+3F8P7z9ly98Iah+1HH4g8F/s+3+nfAL4V+PtE0LxD4 R+OfifxV4S/aT8TeDPHnw81TR9U1q+vdA+BniP4tfGbwvbeBfGtz4x+E/h620/TZtXk8f/8ABMr4 ifHiz+MPjL9of9pTwj4p/aA+LF1+yR4dg8cfC39n7Vvhd8J/Avwe/ZH/AGjdF/aV8PeAPDfwg8Q/ Hv4q+KtQ8ReOvGn/AAmQ8WfEDxT8a9ektf8AhItGPh3wzpOk+GJtB8Q+ifHz/gnP/wALx0j/AIKW 6V/wuL/hF/8Ah4j8E/h38HfP/wCFe/21/wAKf/4QH4b+MPh9/wAJF5X/AAnGk/8ACwP7W/4Sv+1/ 7I8zwT9h+wfYP7TvPtX222uk7U4VKypSr/W8VCrh6PtVhfqdKGDqZbWp1JtV3UxFq1HN6cnH/aJY 2nl31bDxy7MJXTVCdeFFyrUcJUxWHhPF1lCeKoYeeDwkMdV9jQ5qE4UcfPNJ5dFRqVp4ank9XGwl OlmWCx3e/wDBSn9q74k/sbfsafEv9o34OfC2b4weMPCR8JDS9FP/AAi8nh/TLLxD4m0jSbnxL4qt fEnxR+El1e6Bb2199gS38LeI73xINa1XRrhdDu9Fg1u7sPkXxt+3B8Wfhl+2jrep6n+yz+2x4vsL 79gXwV8TtU/ZV8E3fwJ8ReIvhZPoHxu+Odt4x+IHi+5l/aUsv2XrfxNd+H9G8NabY6f4L+Nfiv4m +PrG50rSvB/h3xQvhfxXbeE/0L/a9/Zli/au/ZR+LH7Mb+N7n4fz/EbwVa+HdL8fWugW/iRvDGva Nf6Vrnh3X7nwvdalpUXiDTrPXtE0641bw+Nc0afVtLF5ptrr2j3NxDqtrxXhP9ln4jyfFHxR8a/i 58YfBfjH4j+OP2UtG/Zp8VH4d/BzW/hl4LkvtF+IHxM8Zw+PdB8O+I/jP8Wtb0m2nsfH9po03hC/ 8X67ILzRLnWI/FSQaxFouj+filjKOLp4nAqOIeDeeYjDxxDiqVWrW4I4wy/LsJKnGdHnwtfPK+TQ xbrOGJo1MbRxGFxeGo4bEYjAxgHGthI08zisPLGYfIaWLp4dyk8PUocX8LZhmtf2n71qtQyinmks H9WnUoV6eBxFDF0K9XEYSljuC1v/AIKVfDTU4vh4n7O/wT/aF/bG1f4g/s7+EP2rjoH7POj/AAjs NS8G/AP4ipN/wrnxt4uu/wBoL4yfAbQP7Q+IE+n6/a+Efh94V1rxT8TdVk8MeIbhfBkWn6eL2b7Z +FHxR8DfG74ZeAPjF8Mddj8TfDv4n+EPD/jvwT4gitb2wGr+GfFGmW2saPfPp+p21nqenTzWV3C1 xp2pWdpqNhcebZ31rb3cM0KfidrP/BDXwSNC/Zgn0/Uv2PPi/wDEH4Cfsa/Bn9jPxRqP7cf7Amhf te/DLxj4Y+BttKfCPxD+Hfw6n+PXwn8UfBLx3d3+seK08RDTviv4y8Oa/oGr6VpWq6Ld6r4W0rxH X7S/Bj4dWXwj+E3w6+GWn6N8M/D9v4G8H6D4bOj/AAY+G0Xwd+E1lc6Zp8MF8nw6+FMHiLxfH8O/ B8l6txPoPg7/AISzxPJoGnyw6dN4h1maB9RufbxEcFGeaLD1JzpwzjGQyyU1JTq5VDMs5p4SvP3I rlrZVSyKsqdWFHF0cZWzGVb2lOvQweU8dJ4lxwHtYxT/ALMwcsa1yprMZ5blE8bTlFTqRbo5tLOq VGph5LDywEMDBwlXp1MXjPTKKKK4jpCiiigAooooAKKKKACiiigAooooAK8O/aG/aI+Gf7MPw3n+ JvxRvtYXTJvEHhrwV4W8NeFNA1Pxd48+InxE8caxbeHfAvw3+Hng7RILnV/FPjTxhr95babpOm2k SWtpGbvXNev9G8M6RrWt6b7jX5sf8FJvh78QtV0L9lj4/fDzwN43+LE37Gf7V3hL9pPxn8Ivhrb2 WpfEP4gfDax+GvxV+F3jmH4feHdQv9Mi8X+OvCWi/E+bx34f8FWl4Ne8br4avvBvhS2v/Fev6JZT 5zf73A051HQoYjNsmweNxScI/Ustx2bYLB5nmHtK0Z0KP9n5fXxON+sYmFTCYf2Ht8VTqYenVhLS Cbp4ucYOtWoZbmmKwmGUKlR43H4PLcVisvy9U6LjWnLMcdRw+BjChJV5PEKNFqq4nffDb9ujT/Ef xs8I/s+fGj9mv9pD9kb4nfE7QvEWvfBux+P0XwB17w58Yl8F2r6j460PwV46/Zn+P37RPgmy8YeD 9F+z+IdS8F+O9f8ABninVfDlxNrvhPSfEel6J4lutE6HQf24vhB4j/bK8UfsR6dpHj4/EXwr4G1P xbdePpNF0U/B7UfEPh+y+HGu+K/hFpfiuDxJPrT/ABd8J+C/i/8ADL4ga54VvvCthZr4M8Y2Gqad rWo3FlrdjpfxT8VviXeftkftJfse+NfhP8Cv2l7T4QfsT/EH4lftRfGH4m/GL9lz49/s76nqF+f2 efjP8JvA3wZ+DPw5/aB+HHw3+L3xa+IHi3VviDJ4i1aXwF4A1nwboug+HItH1PxbbeMPE/hnQb34 n039nP8A4KLeAfgX8BP25fEeqeAdU8aeFP2pYP8AgoH8SP2VPAf7JPxnu/2vrXSP2ldSu/DXxz+A mofFHSf2mPEenfELXfhT+zx8SbvwPaeEdI/ZQ0zVNfn+Dfgvw9ZadZ63pcGrTdGGXtcVho4iCoUI Shh8XPlqU1CebYyGAyPHYmnVk8RRwMKUc8zPG1sNCunT4ewlX2VHAcRYWdPHELlp1VhKn1vEVaVK thqEJQ9oq2Do4zEZpl+HnyfV8TiJToZDg4qtOgqMuLJw9rLE5DiYy/p2r4p+Ln7cHw28EfBr4v8A xa+HNv8A8LXk+B/x98Gfs4fEHw55uveBf7H+JPiD4n/DD4eeItK/tjXfCV2uof8ACJWvxQ0nxD9u 0TTdW0HXvI/smx1yGSW5vdP/AB2+LNh8UE8M+Kf2WNO/Zx/af8RfEf8A4fXfBH9p2717Qv2fPihe fBy2/Zx139un4PfHaP4wQfHKfw7a/CTxDpGj+FdVttM8YeCvCPi/xD8WvA+r2niXU/GPw70PwL4G 8d+MvDPl7/sZ/Djwj8N/+Cp/wQ8B/sR+Lfht8bPH/wC3J4H8VeHPGfwj/ZQ+Ifw5bxx+yZ4m+P8A +yj4r022+FP7T/wt+H+ieHdU0Tw49r4s8V3ngf4f/FRfGXwx1PQ/EnjC+8O+GLrQr/WbTlwTr4zD YPFSh7D65k08fTwkuZVlj6WG8MMwqYSVWUHz06C4z4jynHU4YeGJo1eFsyzHmpzy7HZSrxjjhqsa dNuvTjnuGwVTFRip0ZZVXxnHWBhjlGM0qX1uHDnDuaZfWlWqYfE0eJ8twUeanmOAzWf9V9fBPif9 ujUrT9oz4ofs1/DD9jv9qf4/+I/gvZ/Cu++J3jf4Yat+yH4d+H/hWL4waRqOu+E1eX47ftYfBjxv rUkWlaTqd1q48N+B9ZWz+xtBA95cTWsU/iv7G/7Neifsu/t6ftueCvgn8D4fgX+yx4l+Bf7GPjLw ZoPgTwDL4F+B+t/G19S/aV8M/F/XvCcGl6ZYeC774jXHhHw58G4Pifc6KZNeuoYfBuqeLvNvNSsr 285fwR+zb8c/E/8AwUy/bq+KmmfHT9pz9nP4cXum/sUvpFp8P/AH7Pk/wx/aA/4RTwD4zXxRpd/4 p+PH7Nfxd8QajD4dmaPw34g/4U9468D6ho8Wvyx393a64+j6jYdFRKGIwHLJzo1K0XV54qNJQ9lX U44qMJzxCoKrBa4OX1qX7mSUISqwjlVlOMsbh7JVKSoxhUpuUpz+tYDCZjRlhJTisOsTCli4Ua0c WnhadeliqPNUlCjUn+xFFfyYaJ+zH8ZH/bG8Zax8aLy2+GP7S3/DwnVPiT8Of2lNK/4I8/tt/tM/ HS/+CFx8YdP1P4T+DPDv/BTr4P8Axquv2f8A4e/ALxd8Ap7H4F+Nfhx4z8G+DfB3wp8Dah488P8A xH8BxTQ3njTWo/ir4O+OXjX9uzwL8UPDn7IB+Hfxk8Gf8FNPh2niHxlo/wDwT0/as8e/tBwfsw2n xOt/Amv/ABUvf+Ctfi34oxfBDxD8AfiT8MtdeTUv2a/hd4D8Qaf8K/hn4yk+Gl54Y0fwr8NvHXjj w7OXp4+fD9LSjUzuWGjVV5VaeX/WcRwxhG6lWEVTrPBV+I5xzXDxdPH5ZSyrGYnF4OGFp4ithdMw /wBhp5/VTVaGTU8b7DX2cszr4OhxDiaaoQknOnhMxw+RU6mV5hKM8Nj5ZhQoYdzxFXAUsx/qE+Gf xl+G3xhk+I0Pw58R/wDCRSfCX4n+Jfg18QV/sfXtI/4R/wCJPhC00i+8ReHM67pemLqv9nWuvaTL /bGiHUtBu/teyx1S5kguUh9Pr+WTTP2SvBXwq+Hn/BWDwN8Lf2GNb8EfH22/bDsPj74U1r4bfse6 54a/4Wz+yX4U+Lf7M3xssvCPwX+OHh74dab8O/ircmPwj4xv9A/Z78G/EXVPG6+OLK+sV8BWmuyu XX9rTwh8TP2uvGn/AAUR8efDz9nj9raz+Gfxb8F/8EW/Bfw81vxD8Dvjv8DfHXxEsvhL+3x8TfEP xr1nwP4Z1rQ/BXx18ESfDDQdbuNQ8R32veG/h7458K6Np8PxR0+ztvh1rXgP4heJZwfPisJkNTk5 a+ZZXwlicde6w+ExWf4PLPrrU7N06eDzHFZhh5YSs3icPUyzHYOpWxE8BicY75VGtnSqylDD5fxB jcswkuRe2xWAp8S4bKcLiFCVSFOrW/snGUM5Toz9ljcH7DGwjgsLj4LDf1NV578W/ip4G+Bvws+I /wAaPibrP/CO/Dn4T+B/FPxF8da6LK/1N9I8JeDdFvfEGv6hFpml215qmpT22mafcywadplnd6jf zLHaWNrcXU0UT/zcft3/ALE2h+Cf2oPDvhqw/Zx+AumfsHWv7Llr4U+Cfw8l/wCCR37QX/BST4Mf DH446n8UvHWv/HPVfCX7Pv7FnxM+F+q/s7fFfx7oGu/DnWD8dta8C61N4ztNA1LRtE8f+F9b0fVN L8TftL8OfDUvhT/gnh4P8HfGG3+J37a9rpv7MOk+F/iLa658Hdd8D/F79ojw1N4Fi0jxDB4m+BXx v8TWfjDSfHHjDw3Pcx+J/hz8RvEX/Cc3GrTajomsJc+Kbl9OlyqudXJ8xxuGq08PiaMsTQwyxWlG nOFXN8PTr4+pT9ssCl/Z2HxvsK8PaVsBj6OKwyr0ISm9KSp0s1wWFxVOriMJP6tWxU8Hf21WjWoZ VipUstjUpxjjasI47FYHEVKb9lhM0wM8HN1KrqRoem/s3/tF61+0DpF/qmv/ALNf7RX7N08WkeF/ EuiaV8fdK+E4l8W+FfGFre3Oja7oGufBL4u/GvwbBcxPp13ba94I8SeJ/D/xN8KP/Z114o8D6Ppe v+HdQ1b6Xr+XP/hV3xqHwc/bB+HP7LWj/tyfEr9gP4e+Cv2T/iF8EfhN+1b8J/jtoPxt8F/FD4Of tB+H/iN8Xfg/+y7pv7U3hPwV+118TvhhpvwL8DeGrnwv4Y+Idl4y0hfHcmmfDz4GeLtRuX8SeEtD o/taeEPiZ+1140/4KI+PPh5+zx+1tZ/DP4t+C/8Agi34L+Hmt+Ifgd8d/gb46+Ill8Jf2+Pib4h+ Nes+B/DOtaH4K+OvgiT4YaDrdxqHiO+17w38PfHPhXRtPh+KOn2dt8Ota8B/ELxL31IwrYigsLSr UKOIxGApRp41OnicHh8bjqeX0q+YqPPTp1ZS9viqbpTdDMMJQlmOA5MBVSw/Nh41FSxMsZUpOWGr 5dQnWwadXB4qpjcRktLGf2ZUrSoSxEcvhm9SrVw1VLFYOeCrZbjqrrUK2Yz/AKmqK/ne/a4/ZJ8W fsi/EzUNH/4Jyfs9N8L/AAP/AMFAPgZZ/sW+PYv2ZfhTJo3hD9nn4sH4jQH4fftW+KfDvw90ew8M eCdB8IfCj4rftC6n4w+Iepf2Mt/4m8KfDrSL/U7nWNX0wt8XftN/sSeJvCn7Qf7Qfw+8UaDpXgD4 eaX4O/Z88Ff8E+/jbpv/AASD/bT/AOCkfxL/AGb/AIUfDP4K+EfCehT/ALKvxx/ZB+MPh/Tv2NfH nws+M/h7xX43fwzrPw68Pa9r3ijUNB+IN1rfxE8N38GmeHuejKNedPlVRQq1a1CnFxprFSxGExla hisHDDyqxhUx1TB1cmzjK6FHEVaeOyzMcZUrV8BiMnxGHraunJSlDmpXhCNVz5qkqSoV6GXSwuJm 6dGdaGGeMq5zluKqToJ4fGZNGNCGMp5lhpw/ryor+aT9ob4SfEDQP22pP+CeOi6Hr/iH4M/8FU/E Xwp/a2+L3xA0nSFsfDPg7/hlyPwna/tv6R4l8P3er3F34d0z9pnR/Bf7OXhTT4bQXFqniX4s+OYd RVrkRz6p/S0qqiqqqFVQFVVAVVUDAVQMAAAYAAwBwKuEefCUcXGScK1bFYWPu1Ie1rZa6eDzPEYa NanSrTyynncM0yrAYvEUMJiMf/ZOIxc8Bg6dWjCXOqkvbyoShyzWHw2MdqlKsqdDMYyxWXUa1XDz rYZZhPLZYXG4/CUMRiaeBeNoUY4rFKXthaKKKg1CiiigAooooAKKKKACiiigAooooAKKKKACiiig AooooAKKKKACiiigAooooAKKKKACiiigAooooA8xf4N/DeT4yQftAy+G/O+Ltp8Nbn4QWXi2fV9d n/s/4d33ie28Zaj4f03QZdUfwzpp1XxHY6bqGsaxY6Lb69q40nRrLUtUutP0fS7S09Ooooj7tOnS j7tKl7b2VKOlOl9YxNfG4j2cF7sPb4zFYnF1uVL2uJxFevPmq1ak5D1nUqvWpV9l7Wo9Z1PYYejh KHtJ/FP2OEw2HwtLmb9nh6FGjC1OlCMSiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK KKAMbxHd3Fh4e16+tJPKurLRtUu7aXYknlXFtYzzQybJVeN9kiK2yRHRsYdWUkH+ZvwB/wAFGf2u db/Zj/Ze+G938a9L1j9rfTvHH7M3xf8A2mfiO3gH4caXqfiH9kr46+O/gVc+CpbXwJa+DrjwNot3 8R2/aN8OfBRPE2jaB4c/tGf4NfHPXvB8+h+KdBVdN/p5mhiuIZbe4ijngnjeGeCZFlhmhlUpJFLG 4ZJI5EZkdHUq6kqwIJFeVWvwE+BdlbfY7P4L/Ca0tP8AhHfhv4Q+y2vw58HwW3/CJ/BvWLvxD8If C/kRaOkX/CO/CvX7++1z4b6Lt/s3wPrF7d6n4YttLvbiad3hX7HE16tb9/RqVMknToSS/cyyvE5l i686cndJ4yrWy7D4vD1YV8FmGXUcZg8ZhpVZ4DF4B1bVKFOnG9OUJYr2ko2Tr08XDDYSdGdRL2lO NLByzCvhq1B08Vhcz+oYrDYij7Kt7T8oIv8Agov468O/Gf4LeDV07XfE9t8Z/iz+3j8DPD+i/EHW PDWgeAbHx18E/wBurw98DPA/iD4g/HHwX8DbDT/hj4Vg8H2/iTwh8I/C+p+HNa8UeP8Axn4q+G/w k1HWvir8UdYT4kXPvH7L3/BRXxJ+0x+0p47+EWn/ALNfxD8OfB/Q774x6L4O+Pkvgv8Aamh0HWNe +CnxDHw317T/ABdr3j79kT4Zfs2adH4p1ew8S3fgaT4O/tU/H6/1Kz0GS38QaV4X1V9Q07SPui++ AvwM1PTdU0bUvgv8J9Q0fXIvG0GtaVffDnwfd6brEHxK8YW/xC+I0OqWNxo8lrqEXj/x9a2vjjxt HdxTJ4q8YW1v4m10X+tQx3q4Hhb9lr9mTwP8XvFH7QXgr9nP4EeD/j144g1C28a/G7wt8Ifh/wCH /i94wttXnsbnVrfxR8SdJ8PWnjPxBBqdzpemXGoRatrV3Hez6dYy3KyyWlu0bw7jTp4KjXTqqjSz 36xW0VSrWxmLqYnJ4JKMZzp5eqlSE61Wu5+znTwsaNTC4XDU4LGfvcXmdfCf7NRxWYYevg8NL31h cJHF4meIoqT9ymp4CWCwsKMKU0q2GrYv6xCpipqPyx8fP2sPiX8E/jh8U/Cvhrwzp/xQln8C/sP+ Gfg58M9e8S6f8M/CR+MH7Snx3/aM+F9/rXjX4q2ngjxx4j8L+EpbHwb4Qm1i7h8LePLu1Tw9HY+C /BOp+J/ETWGr+HeKP+CmXx50u3Ph3w1+yP8ADnxN8U/AfhP9rPxn8fNDuf2qdZ0L4b+DtK/Y/wDE nw50Tx1afCb4j/8ADMuq+IPi/q3i20+J2g3Hgm38Q/DD4P2KazZa74d8bal4Mn0xr2X9ET+yh+y0 dB+MHhY/s1fAE+GP2hddu/FHx98OH4N/Ds6D8cfE2oXJvL/xF8YNIPhz+z/iXrt7eM13d6v40t9a 1C5uWM81w8pLVt+F/wBnX9n3wP4Z0LwV4K+BXwc8IeDfC/grxT8NfDPhLwv8MfBPh/wz4d+HXjm/ s9V8beAdC0HSdEtNK0jwV4w1TTtP1LxT4V0+0t9C8QX9jZ3mrWF3cW0MiY0/axnKdRwqL2GKdOjy 8tNYmtllOGDhUnDlqzw2X5vTrVq81KFfNcHjaUILKJZVKnnOs5Up4mE1GUMM54SFeMWvayoYebo4 mtSvenSxWYYT2FalBxlQy3G4bEe2WdRzT2uWfAug/wDBTHxD4z/bBuP2dPAX7LnxQ8Y/DPSPEtp4 A8UfGXSPBn7TN1L4c8dX/wAGdL+MdsNR1Ww/ZQ1D9kDTPBUdt4k8KeENR1rxL+2/4c8c6d4k1rdN 8MTpC6bqWsfRv7Fn7TnxA/aV8KeO7v4s/Cvwn8DPiT4B8ZDwxr/wl0jxl8Z/E/irw5azaXa3ljqH jCz+OH7L37K2v2Y1W8/te18PeIPBPhj4h/CPxtp+jza98Ovi34z003L2Po2tfsgfsl+JPijY/HHx F+y5+zrr/wAatM0QeGdN+L+tfBL4aap8UdP8NroN54VXw/Y/EC+8Mz+LLTRF8L6jqHhsaVb6tHYD Qb680cW/9nXM1u/U/BX9nn4A/s2eGNQ8E/s6fA34PfALwZq2uXHibVPCPwV+Gfgv4V+GNS8SXVjp +mXXiDUNA8C6JoWlXmuXOm6Tpen3GrXFpJfzWOm6faSXDQWdvHH0UnSjCqqkZSm8MqdOd+ZfWaeK ptYiMY+x9jGvhFXdajU+uqnOphsNRknhK+YZjyONf9z+8g7VISrJQ5f3f1fERqUYtyqe0ksRLCuN ZfV+dUa9R0accTTwuE9hooorM2CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi iigAr8xv+Cl3xx+PnwNsf2Wdc+A/iybQDdftAavrvxa8N2/g/wANeMLn4q/BX4R/Ab4yfHL4i/Ci xh17SdR1DRNY8b6H8NJtK8PeIfCV1o/iXSvEL6VNBe3Nh/aGkan+nNc9rfhHwp4mvNA1HxH4Y8Pe INQ8Kahe6v4Wvtb0XTdVvPDWq6loWreF9R1PQLm/tp5tH1C/8M69rnh29vdOe2ubrQtZ1bSJ5ZNP 1G8t5on7VJToOmq9GpSxGH9vGVTDvEYerCvQjiqMZRWIwsqtOEcVhajdHF4d1MNXhUo1alOVwdO8 41lUdKrRxFCboyjCtGOIoVKDqUKs4VFRxFP2ntKFdQlOhVjCtTXPCLX4Z6D/AMFJvi9f/Er9rT41 eCdc8BfGL9m1vhl8BfEP7Gfw2kk8dWui+O7HW/jf8T/gL4i8daH4q/Z2/Zh/aZ/aD8ea18YPFvgX XNc+HnhvwV8LPixpus+DtP8AAl3oOm+Hodd8U+IYfoP4Qf8ABSn4ifF+y+A0um/sz6foV5488Ift VfEL41Wvif4jfFjwbd/Cnwj+yN8a/D3wW+IEPgfwd8Rv2WPAvxg+IfjjxJqPiWz1zwV4G+J/wq/Z z1CS1tNQ0zxfd+D9TSyiv/vHX/2WP2YvFfgW4+F/in9nH4DeJfhpd+B/B3wyu/h3r/wg+H2s+Bbn 4bfDrVW134ffD248Jaj4eudAm8D+Bdcd9Z8HeE5NPbQfDGqs2o6JYWN2xmPRfDz4D/A74RWHhTSv hP8ABn4UfDDS/Aeg6/4V8D6b8PPh34Q8FWHgzwv4r1jTfEPinw34Us/Dej6Zb+HdB8S+ING0jXNf 0fSI7PT9Y1jStN1PUbe5vbG1nitRUaToxqTfsJY2GEr14Qq1q1CeEziOAqZmqcsMq2Ip5hicqxmO WGnhoV6eFr4TBvL8L7KiKclKtKvype3xGDniKFK9GhRw9PAZdhsXRy9SeIdByr4fFzwcsQsVOn7R YnMp5ri8RXnH8x/Fn7YH7dniDwz+w748+H3wH+AGjap+098axH4P+GA/ao1vWPCnxA+B/iH9k74v /GTRL34wfFi6/Y7uNW+DnibQ9Q8P6Hr17ofwc8EfG63vtY0Kz8PWfj/U/DGuarqUP3L4d+J/jz9o H9kPw/8AFv4a31j8D/HvxI+FekeL7KfX9EtvirD8O9SvrG3vPElhZ2aap4Q0zxTqWlRR6vpvhXX9 SWLRBqq6R4l1/wAF65pcF/4J1Hsfh1+yv+zB8H7mW8+Ev7OHwG+F15P441L4mzXfw6+D/wAPfBNz N8SdZ0HU/CusfEGWfw14d0yWTxxqvhjWtY8Oal4sdjr19oOrano91fy6ff3VvL1fij4J/Bnxv8ML 34I+NPhH8MfF/wAGNS0y20TUfhF4o8A+Fdf+GF/o1ldwX9npN74B1XSbvwpdaZaX1ra3ttYT6S9r Bd20FzFEk0MbrjmdN4rBZhh8Fz4SpjKTWGqyxFSVfLpywcaHJSxeHhhZV1DEc2IqYmWGo1K9aKnh 6OW0KjwVN4KTo4jAVcVKNdYWNOGJ5MPCNLHOGOxGIliKmEqzrwpOWHnSoU8Mq9SMKSdHE4jHyp08 U/xO/aC/4KCfH/4cfsE/seeONNvPjXB8Sfip+y/8N/j38WP2ifh7+yB8VPj9osF/pfg/wDrWpeCp rf4P/Az4jfCT4b+KPjJ4s8QOuo6j480Twv4W8PfDPT/H3/CHDRvGl34E1PR/258aaw2pfCfxN4h0 XxunwnF94C1XW7D4jeL/AA4LH/hXFtcaDNfp4x8R+FfHqaDHps3hS2Y6xqWjeNrfTYdNmsZbXxPY xRW99Z1keCP2fvgL8M/henwQ+G/wR+EXw++C8aalHH8IfBHw28G+FPheiazqE2rawieANB0Ww8KK mq6pc3Gpako0kC+1Cea8uhLcSvI2Fpn7NXwhh0n496F4o8K6d8TdE/ac8Zaz4y+NuhfE/StA8ZeH PHbat4M8LfDaHwxrXha/0dfDN94O0j4b+CPCPgWx0G90e6S90PQoJvEU+ua3favrGo9mY1IYuebv D0o4ZYupmeOwPKnRp0a2LxNKOGy2UMPONShhsPgp8tKvga2HpUpZc6lPAQxebYjE0ccHB0HgvbVJ 1YUI4PC1ovlr1alOhCcqmN9pXioVKlWpCUqtPFRxVac8ZSoyxFTC4JX/ADT8JeOP2qPFWmfBD4M3 v7XPxX8LeGPj58ePjenwm/az1f4W/su6N+0t8QPgf8NfhZZ+NPBumQeGtZ+Dh/Z2t/EXxG8WW/jz xJ4X8Q237Lgu9a/Zr8E2WoP4V0TxjrFz8Rbfe+Ev7Qn7TPjE/wDBMLxjq3xs8L614H+NnjP4o/Cj 4raX4a+F+gWDfGzUPA3wd/aW17TPi3P4uvrrUF0DQPFd18JfAvjbw94W+HHhrwPFZ3uqa+134i8R eE9Y0fwx4f8AtGz/AGAv2ENO+FmsfAzT/wBij9kiw+CfiHxVZ+Otf+D1n+zf8HLX4Wa5430+0hsL DxjrHw+g8Gp4S1PxVY2Ntb2Vn4hvdIn1e2tIIbaG8SGJEXq/Gf7Hv7JHxH8VfDjx18Q/2Wv2c/Hn jf4O2Wg6Z8I/GPjP4I/DPxR4q+Fmm+Fb9NV8L6f8OPEOueGL7V/BFl4b1SKPUtBtPDN5pkGj38aX mnx29wiyCYuKrU9ZOhCeWU5TnClOvUo4TKI5fiMVVhCNHDyxleqpVa9CjDDYPG4urPOHHBYqGGwt CPZ1HTxHNO9Wths0UVCVSnSo4rG5hUxdCNFudSrTw2GVSP1apOVXF4PDUYZQqmKwkp1z5H+FXjf9 obwp/wAFB/Efwq+InxI/aLvPg349+Hnxp8UfDrwr+0T4V/ZAn8NeKtc8F+OfhZLZ6x+yz4p/ZL8H 6f4/0D4afD7wx431Hw/400f9tnVtK+KnieTxB8Or74faf4ql0D4qa5pn6iV4R8Mv2Wv2ZPgp418c /En4Nfs5/Aj4SfEX4n3F3efErx98MvhD8P8AwF41+Id3f6tca9fXXjnxT4V8PaVrvi24vddurrWr ufX7/UJLnVrm41GZnvJpJm93rOn7mCy7Dy96thMJKhiKr96derLGYvEKpVru1TFVFRr0qMsRVjTc vZKFKjh8NChh6W9R8+KxlZLlhiMR7WnTVo06cFRo0lGjQS5cLBunKboRq10qk6lX2zdVxgUUUUCC iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA/CvX/+Chf7TWu/FT4K fDXwnqvw4+HkfxC+LP8AwUF8Gaxrdn+wj+11+2nPcaT+yh+2no/7Nfw2sp9C/Z0+NHgy5+D9rr/g /Vm1v4h/Gb4mXV38MdL8S20cv2Pwvpl9BpaVvGv7Wn/BQ/4WeHv20PEPjP4v/si+I7H9mj9or9nf 9m3w8Ph3/wAE9P2qfFfiTVdR+PCfsheJrj4jS/DfwR+3h8RPHnxBPhLwt+0f4g0Cw+Dfw90qPxZ4 28SeHNF1rS/F2nx31x4Ok/QjxV/wT4/Ze8V6n4X1w6J8XvBWueD/ABH8bPFOia38HP2p/wBqn4D6 0dU/aM+J8Pxm+M8Otat8FPjR4A1HxRoPjf4mW1t4quPCnie51jwto9zbW1j4d0bSNJt4dPT2e5/Z y+DV5P8AEK5ufBxln+Knxb+GXx18eyt4j8WBtf8Air8HLP4VWHw48VNt10DTT4dtPgl8MYjoujjT /DusHwz5mv6RqkuteIX1Z4ZQhTwir3lUg8RHGNc9WnWjV4oyrGQqJOtRqe0hwtTzfKuSlUwsIYmt g6lB0sR7TNKXTVq0XmWY16dN/wBn1sdLE4Cg/Zwq4ahTxuLrYbDNKFWkqaoVqUasZ/WVVlF0cR9b wtHC0qXjt58dPiJ4R/YW8VftCaxq/g/xd8TPDHwU8dfEK11Lxl8IfiF+xP4M1zxJomma5qHhy18S fCD9pz4hTeP/AIJ2FxPa6ZpupaV8VviXpUwk83Ub/wASeGdM1GG40v8ANXUP+Cmf7RehfCvSdJvN X8Aa78X/ABr+1Rb/AAU8MeP9H/4J5ft4t4g8K/Dm2/Z9m+O+veMvHn/BMPwp46+JP7Z+n+IxdaB4 i8CeEtN8T/Ez4baL4v8AD95pnx6ttUsvhjDo0fjr9wfib8NvBXxi+H3jD4W/EbRj4g8D+PNA1Dw1 4m0mPUtX0S6udL1KBoZX07XvD1/pXiLw9q9oxS80bxH4d1bSfEPh/Vbez1nQtU07VrGzvYPlO3/4 Jyfsp23g/VfCK6H8aJrvWPHemfEq8+Kd9+1t+1xqP7R8fjHRfC1x4H0rUNM/aq1D45XP7S+iWNh4 KvtV8H23h7RvixYeG4/C2veJPD40j+yfEmvWmozUcpYjGVVGKhXWBVKlKUlGPss2o4zFKUaEaEKD ngqdTCwqYKOHdaNerQqxhSWHnh+enywoYKnrKph/ryqVGm+Z1ct9hhKn76pWliJUsZGNT2eMlXo0 ozqYicMZXUIH0F+z38RIviz8Efhf8RovG3h74jP4t8H6Tqt7408LfDvxj8IND13Vmg8jWZ7X4S/E PxF4t+IHwunttWhvbHUvhz478Sav4z8Eana3nhnxTdtrul36J7HXG/Dv4feDvhP4G8KfDX4faHB4 b8FeCND0/wAOeGtFgnvbwWOl6bAsEC3Go6nc3uq6tfz7WudT1nWL6/1nWdRmutU1e/vtSu7q7m7K tq84Tr1p0k1TnVqSpqUacJKEptwUoUYwoxai1eNKEKcXpCMYpJY0FUjRoxq8vtY0qcanJKpOHtFB KfLOq3VlHmvyyqN1JKzm3JsKKKKyNQooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA/ /9n/2QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFBLAwQUAAYACAAAACEADy2vrlEBAACLAgAAEQAAAHBw dC9wcmVzUHJvcHMueG1srJDNasMwEITvhb6D0V2RLDt2bGIHO3ah0EMO7QMIW04E1g+S8lNK373C cUtDLzn0tssys9/MenMRY3BixnIlCxAuMAiY7FTP5b4Ab69PcAUC66js6agkK8A7s2BTPj6sda4N s0w66rx0ZwJvJG1OC3BwTucI2e7ABLULpZn0t0EZQZ1fzR71hp79AzEignGCBOUSzHpzj14NA+9Y o7qj8ABXE8PGicQeuLbfbvoet985bpBKH5Jd3It18xQcDS/AR5sm2zaLK5jgaAvjMCawztoaJk0Y pRiHuCLpJ/CaMM57bjtq+mdB96ztuWuoo3NUf/6DJ3hnlFWDW3RKoGtOpNWZGa34FDXEc18nOhYA A1Su0YR5y9hEYYUTUsE0W1UwjkgGq7ppYF1Xq2WSELwM8Q8jG+hxdBNjo/k/4hFyA3gFnfr04+/e d6b8AgAA//8DAFBLAwQUAAYACAAAACEA2P2Nj6wAAAC2AAAAEwAAAHBwdC90YWJsZVN0eWxlcy54 bWwMzEkOgjAYQOG9iXdo/n0tQ1EkFMIgK3fqASqUIelAaKMS491l+fKSL80/SqKXWOxkNAP/4AES ujXdpAcGj3uDY0DWcd1xabRgsAoLebbfpTxxT3lzqxRX69CmaJtwBqNzc0KIbUehuD2YWejt9WZR 3G25DKRb+HvTlSSB5x2J4pMG1ImewTeqgiCitMCny+WIaUgDXHo0xnFU1tW5qf0qLH5Asj8AAAD/ /wMAUEsDBBQABgAIAAAAIQDS96XuggEAAEEDAAARAAAAcHB0L3ZpZXdQcm9wcy54bWyMUk1vwiAY vi/ZfyDcta3Zam2sXpadPCzR7U4orSQUCGCt/vq9FDvr9ODt/Xw+Xliuu0aglhnLlSxwMo0xYpKq ksu6wN+7z0mGkXVElkQoyQp8YhavV68vS523nB2/DAIAaXNS4L1zOo8iS/esIXaqNJPQq5RpiIPU 1FFpyBGAGxHN4jiNGsIlvuybZ/ZVVXHKPhQ9NEy6AGKYIA7E2z3XdkDTz6BpwyzA9Ns3klZgTnrZ 4qe36HOYdcqwcsMqh+wZTvWezmIcjXs7pfvW4i1N+1Z0j2MFL9kVlm5FOcpCiFpitpQIOHeCPYH1 yWpJctsheKV5ilEJvbgngerpvgrUly2dK8NrLlFX4EmWLjA6QbBIvHaYolf6+gDaNtZ5yj5GsAkX gmMqc8ZIK1vgWRK8DSOhmGWD4SuIBx/Z84puzUvlmN2xzl0ljNT8M+3dPnD9r+xJwrHGtmETPA8K /zhg+IGE2vByqwmFj4oo3GwO7wwAFBBCGO7Whq/xCwAA//8DAFBLAwQUAAYACAAAACEAjtrv230B AADAAgAAEQAIAWRvY1Byb3BzL2NvcmUueG1sIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAfFJba8IwFH4f7D+EvNe0VpyUWtkFH8Zkg3Vs7C1Ljhps0pIcb/9+SdVO2Rj0Jfku+c53 mk92uiIbsE7VZkyTXkwJGFFLZRZj+lZOoxElDrmRvKoNjOkeHJ0U11e5aDJRW3ixdQMWFTjinYzL RDOmS8QmY8yJJWjuep5hPDivreboj3bBGi5WfAGsH8dDpgG55MhZMIyazpEeLaXoLJu1rVoDKRhU oMGgY0kvYT9cBKvdn4IWOWNqhfvGz3SMe+4txQHs2DunOuJ2u+1t0zaGz5+wj9nTaztqpEzoSgAt cikyVFhB8fzlwG44+oIdmdtaE1wCeb5d45JMgePaAplxtGqXs04U5MJ6tLbFTK2APPr2XUs4XYcN VNzhzC9rrkDe7S+Yv9EgsLBRYdXFTc7Oj/69tp3DoyCJnzc7tHNC3tP7h3JKi7CyKB5FybCM46z9 PkOwC32Y/3Chj/H+dUzSKE6jZFD2k6w/ytLBmePJoGgTX/5zxTcAAAD//wMAUEsDBBQABgAIAAAA IQDKVLK+awIAAEUFAAAQAAgBZG9jUHJvcHMvYXBwLnhtbCCiBAEooAABAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAJxU32/aMBB+n7T/wcrT9tAGWlZVyLhidIxJa0Ei7Z5NfCHWHDvymbTsr9/F KRRWNGnz0/3yd3efz8dvnivDGvConR0l/fNewsDmTmm7HiUP2fTsOmEYpFXSOAujZAuY3Ij37/jC uxp80ICMICyOkjKEepimmJdQSTwntyVP4XwlA6l+nbqi0DncunxTgQ3pRa93lcJzAKtAndV7wKRD HDbhf0GVy9v68DHb1lSw4JkL0mS6AnF5wdNXjf9wXqHoX/d52ol8XNdG5zIQIeJO596hKwKbx9LZ wj2BXzhtA08PA4kOQOopXpvGlsXcnmHuASxblu6JfRgMLz/y9EQgX0gv117WJYoBFXKg8qXRClB8 4umLxO9dIEOPp53AZ1opsC9eMh/p/O5uYnQd43ciX+bSwIT4EYU0CAS9N/AZyPbtF1J7FLwJwwby 4DxD/Ytef5CwlURoWR0ljfRa2kDstmGdEmVTY/AiozEgbPJ1ehQPww5lPRDUOMWS8NfADit2yzId DOA/pCAWT6VojV2blPuYgC7FvKAnCSf4uDrkI5bWsdFV+TIzb4jYUzJfIfgmzgyywruKhRLYfLwJ JZuCDBsPbLnxDWwPm9xfv5VBsq+S7nhQLDhGhiPG95FjYyI01pAjkwS7AnpltkFQJ6EfEJgr2Jf2 c7argQafZh6ZxohzTxN+8t43GyD+Y7nSRodte+FzTDXOSw3Ncboj4v+geuKqWtotvche+q7tT3yo M9f2uZvdYyNfltSdohWz878a+IzG1psWZFJKuwa1i3nraLfAY7cVRX9w3qMTP/zO1v7j3f4TvwEA AP//AwBQSwECLQAUAAYACAAAACEAlnQmC90BAABODgAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRl bnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQBo+HShBQEAAOICAAALAAAAAAAAAAAAAAAAABYE AABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQBjXCO0wQAAADcBAAAgAAAAAAAAAAAAAAAAAEwH AABwcHQvc2xpZGVzL19yZWxzL3NsaWRlMS54bWwucmVsc1BLAQItABQABgAIAAAAIQBL9T3svwAA ADcBAAAgAAAAAAAAAAAAAAAAAEsIAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlMi54bWwucmVsc1BL AQItABQABgAIAAAAIQBL9T3svwAAADcBAAAgAAAAAAAAAAAAAAAAAEgJAABwcHQvc2xpZGVzL19y ZWxzL3NsaWRlNC54bWwucmVsc1BLAQItABQABgAIAAAAIQDUt44BOQEAAOUFAAAfAAAAAAAAAAAA AAAAAEUKAABwcHQvX3JlbHMvcHJlc2VudGF0aW9uLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAEv1 Pey/AAAANwEAACAAAAAAAAAAAAAAAAAAwwwAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGU1LnhtbC5y ZWxzUEsBAi0AFAAGAAgAAAAhAEv1Pey/AAAANwEAACAAAAAAAAAAAAAAAAAAwA0AAHBwdC9zbGlk ZXMvX3JlbHMvc2xpZGUzLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAIxCLatnAgAAGA0AABQAAAAA AAAAAAAAAAAAvQ4AAHBwdC9wcmVzZW50YXRpb24ueG1sUEsBAi0AFAAGAAgAAAAhAJHvWREmAwAA KwkAABUAAAAAAAAAAAAAAAAAVhEAAHBwdC9zbGlkZXMvc2xpZGUzLnhtbFBLAQItABQABgAIAAAA IQDhqLmTlwMAANEKAAAVAAAAAAAAAAAAAAAAAK8UAABwcHQvc2xpZGVzL3NsaWRlMi54bWxQSwEC LQAUAAYACAAAACEAjy1lF9YCAAA8CAAAFQAAAAAAAAAAAAAAAAB5GAAAcHB0L3NsaWRlcy9zbGlk ZTEueG1sUEsBAi0AFAAGAAgAAAAhABibq5AcAwAAiAkAABUAAAAAAAAAAAAAAAAAghsAAHBwdC9z bGlkZXMvc2xpZGU0LnhtbFBLAQItABQABgAIAAAAIQC0xew0ZwMAAIkKAAAVAAAAAAAAAAAAAAAA ANEeAABwcHQvc2xpZGVzL3NsaWRlNS54bWxQSwECLQAUAAYACAAAACEA1dGS8b4AAAA3AQAALAAA AAAAAAAAAAAAAABrIgAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDcueG1sLnJl bHNQSwECLQAUAAYACAAAACEA1dGS8b4AAAA3AQAALAAAAAAAAAAAAAAAAABzIwAAcHB0L3NsaWRl TGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDgueG1sLnJlbHNQSwECLQAUAAYACAAAACEA1dGS8b4A AAA3AQAALAAAAAAAAAAAAAAAAAB7JAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91 dDYueG1sLnJlbHNQSwECLQAUAAYACAAAACEAaaJfIR4BAADHBwAALAAAAAAAAAAAAAAAAACDJQAA cHB0L3NsaWRlTWFzdGVycy9fcmVscy9zbGlkZU1hc3RlcjEueG1sLnJlbHNQSwECLQAUAAYACAAA ACEA1dGS8b4AAAA3AQAALAAAAAAAAAAAAAAAAADrJgAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9z bGlkZUxheW91dDkueG1sLnJlbHNQSwECLQAUAAYACAAAACEA1dGS8b4AAAA3AQAALAAAAAAAAAAA AAAAAADzJwAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDIueG1sLnJlbHNQSwEC LQAUAAYACAAAACEA1dGS8b4AAAA3AQAALAAAAAAAAAAAAAAAAAD7KAAAcHB0L3NsaWRlTGF5b3V0 cy9fcmVscy9zbGlkZUxheW91dDMueG1sLnJlbHNQSwECLQAUAAYACAAAACEA1dGS8b4AAAA3AQAA LAAAAAAAAAAAAAAAAAADKgAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDQueG1s LnJlbHNQSwECLQAUAAYACAAAACEA1dGS8b4AAAA3AQAALAAAAAAAAAAAAAAAAAALKwAAcHB0L3Ns aWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDEueG1sLnJlbHNQSwECLQAUAAYACAAAACEA1dGS 8b4AAAA3AQAALQAAAAAAAAAAAAAAAAATLAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxh eW91dDEwLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhANXRkvG+AAAANwEAAC0AAAAAAAAAAAAAAAAA HC0AAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQxMS54bWwucmVsc1BLAQItABQA BgAIAAAAIQBzhBLvFAQAAMMRAAAhAAAAAAAAAAAAAAAAACUuAABwcHQvc2xpZGVMYXlvdXRzL3Ns aWRlTGF5b3V0NC54bWxQSwECLQAUAAYACAAAACEAQMO3X4kEAAC0EAAAIQAAAAAAAAAAAAAAAAB4 MgAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDMueG1sUEsBAi0AFAAGAAgAAAAhACFajqJN AwAA8QoAACEAAAAAAAAAAAAAAAAAQDcAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQyLnht bFBLAQItABQABgAIAAAAIQDMbs6EOAQAAGAQAAAhAAAAAAAAAAAAAAAAAMw6AABwcHQvc2xpZGVM YXlvdXRzL3NsaWRlTGF5b3V0MS54bWxQSwECLQAUAAYACAAAACEAXAN7LZ0HAAAyLwAAIQAAAAAA AAAAAAAAAABDPwAAcHB0L3NsaWRlTWFzdGVycy9zbGlkZU1hc3RlcjEueG1sUEsBAi0AFAAGAAgA AAAhAIwSbwlwBQAAkhsAACEAAAAAAAAAAAAAAAAAH0cAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVM YXlvdXQ1LnhtbFBLAQItABQABgAIAAAAIQAuZXpP2AIAABQIAAAhAAAAAAAAAAAAAAAAAM5MAABw cHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0Ni54bWxQSwECLQAUAAYACAAAACEAkxEDP6kCAADC BgAAIQAAAAAAAAAAAAAAAADlTwAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDcueG1sUEsB Ai0AFAAGAAgAAAAhAK+u3U+yAwAACAwAACIAAAAAAAAAAAAAAAAAzVIAAHBwdC9zbGlkZUxheW91 dHMvc2xpZGVMYXlvdXQxMS54bWxQSwECLQAUAAYACAAAACEAgTbFA2QDAAAoCwAAIgAAAAAAAAAA AAAAAAC/VgAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDEwLnhtbFBLAQItABQABgAIAAAA IQDvjMzfrQQAAIwRAAAhAAAAAAAAAAAAAAAAAGNaAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5 b3V0OS54bWxQSwECLQAUAAYACAAAACEA/H5Qb+8EAAAdEgAAIQAAAAAAAAAAAAAAAABPXwAAcHB0 L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDgueG1sUEsBAi0AFAAGAAgAAAAhANXRkvG+AAAANwEA ACwAAAAAAAAAAAAAAAAAfWQAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ1Lnht bC5yZWxzUEsBAi0AFAAGAAgAAAAhAPnPCTmDBgAAXBsAABQAAAAAAAAAAAAAAAAAhWUAAHBwdC90 aGVtZS90aGVtZTEueG1sUEsBAi0ACgAAAAAAAAAhALtklvMAQAAAAEAAABcAAAAAAAAAAAAAAAAA OmwAAGRvY1Byb3BzL3RodW1ibmFpbC5qcGVnUEsBAi0AFAAGAAgAAAAhAA8tr65RAQAAiwIAABEA AAAAAAAAAAAAAAAAb6wAAHBwdC9wcmVzUHJvcHMueG1sUEsBAi0AFAAGAAgAAAAhANj9jY+sAAAA tgAAABMAAAAAAAAAAAAAAAAA760AAHBwdC90YWJsZVN0eWxlcy54bWxQSwECLQAUAAYACAAAACEA 0vel7oIBAABBAwAAEQAAAAAAAAAAAAAAAADMrgAAcHB0L3ZpZXdQcm9wcy54bWxQSwECLQAUAAYA CAAAACEAjtrv230BAADAAgAAEQAAAAAAAAAAAAAAAAB9sAAAZG9jUHJvcHMvY29yZS54bWxQSwEC LQAUAAYACAAAACEAylSyvmsCAABFBQAAEAAAAAAAAAAAAAAAAAAxswAAZG9jUHJvcHMvYXBwLnht bFBLBQYAAAAALQAtAJENAADStgAAAAA= --_007_4E1F6AAD24975D4BA5B168042967394367511EAFTK5EX14MBXC283r_ Content-Type: application/pdf; name="Observations from the OAuth Feature Survey.pdf" Content-Description: Observations from the OAuth Feature Survey.pdf Content-Disposition: attachment; filename="Observations from the OAuth Feature Survey.pdf"; size=146750; creation-date="Thu, 14 Mar 2013 21:32:39 GMT"; modification-date="Thu, 14 Mar 2013 21:32:40 GMT" Content-Transfer-Encoding: base64 JVBERi0xLjUNCiW1tbW1DQoxIDAgb2JqDQo8PC9UeXBlL0NhdGFsb2cvUGFnZXMgMiAwIFIvTGFu Zyhlbi1VUykgL1N0cnVjdFRyZWVSb290IDIzIDAgUi9NYXJrSW5mbzw8L01hcmtlZCB0cnVlPj4+ Pg0KZW5kb2JqDQoyIDAgb2JqDQo8PC9UeXBlL1BhZ2VzL0NvdW50IDUvS2lkc1sgMyAwIFIgOCAw IFIgMTUgMCBSIDE4IDAgUiAyMCAwIFJdID4+DQplbmRvYmoNCjMgMCBvYmoNCjw8L1R5cGUvUGFn ZS9QYXJlbnQgMiAwIFIvUmVzb3VyY2VzPDwvRm9udDw8L0YxIDUgMCBSPj4vRXh0R1N0YXRlPDwv R1M3IDcgMCBSPj4vUHJvY1NldFsvUERGL1RleHQvSW1hZ2VCL0ltYWdlQy9JbWFnZUldID4+L01l ZGlhQm94WyAwIDAgNzIwIDU0MF0gL0NvbnRlbnRzIDQgMCBSL0dyb3VwPDwvVHlwZS9Hcm91cC9T L1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0I+Pi9UYWJzL1MvU3RydWN0UGFyZW50cyAwPj4NCmVu ZG9iag0KNCAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAzNzA+Pg0Kc3RyZWFt DQp4nH2RS2vCQBSF94H8h7uckTq5d2YymYAI9YkFscVAF9KFLfFBUWkSC/33nRQjRhuXA/ec78sJ BM/Q6QTT/mQA2O1Cb9CHL99DQIGIJCVGEEmEUCNkqe+9tmDvewTr8w2iIdS1o1XL9158D4bTPsAF gE6AXuJ7wYhAa+GSyaosdG1AQGEsKAYlQxFHkOxKikMF43kE67x8jX1vwWbvXLM8zXg7Zt+cFFty y4rtYZ/DKuMUs8MOik3K3yB58r2hw5XIChIaFDXGgkHDKRklbAQyUoKq2xknYo/HYtMUkjYWaOqh ESfJ0iWPWHHMSuMUeMjmx+oTiKXu/dNkHBpB9cJL+M3Q8mpoJa+HltaWjYhCqVPjdPvJlXViTwfe lmyf5g02WpGwth6+q6MudM4CoRVSuh+uhQwrg6WbxrCPDZB+cP2kmgzMn0EtfNdA/zOIqS+iyK3r OtENo0+dk2HCFRsBbytmTZMMGhHLevBG5hdx3bAWDQplbmRzdHJlYW0NCmVuZG9iag0KNSAwIG9i ag0KPDwvVHlwZS9Gb250L1N1YnR5cGUvVHJ1ZVR5cGUvTmFtZS9GMS9CYXNlRm9udC9BQkNERUUr Q2FsaWJyaS9FbmNvZGluZy9XaW5BbnNpRW5jb2RpbmcvRm9udERlc2NyaXB0b3IgNiAwIFIvRmly c3RDaGFyIDMyL0xhc3RDaGFyIDEyMi9XaWR0aHMgMTM2IDAgUj4+DQplbmRvYmoNCjYgMCBvYmoN Cjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5hbWUvQUJDREVFK0NhbGlicmkvRmxhZ3MgMzIv SXRhbGljQW5nbGUgMC9Bc2NlbnQgNzUwL0Rlc2NlbnQgLTI1MC9DYXBIZWlnaHQgNzUwL0F2Z1dp ZHRoIDUyMS9NYXhXaWR0aCAxNzQzL0ZvbnRXZWlnaHQgNDAwL1hIZWlnaHQgMjUwL1N0ZW1WIDUy L0ZvbnRCQm94WyAtNTAzIC0yNTAgMTI0MCA3NTBdIC9Gb250RmlsZTIgMTM3IDAgUj4+DQplbmRv YmoNCjcgMCBvYmoNCjw8L1R5cGUvRXh0R1N0YXRlL0JNL05vcm1hbC9DQSAxPj4NCmVuZG9iag0K OCAwIG9iag0KPDwvVHlwZS9QYWdlL1BhcmVudCAyIDAgUi9SZXNvdXJjZXM8PC9Gb250PDwvRjEg NSAwIFIvRjIgMTAgMCBSPj4vRXh0R1N0YXRlPDwvR1M3IDcgMCBSPj4vUHJvY1NldFsvUERGL1Rl eHQvSW1hZ2VCL0ltYWdlQy9JbWFnZUldID4+L01lZGlhQm94WyAwIDAgNzIwIDU0MF0gL0NvbnRl bnRzIDkgMCBSL0dyb3VwPDwvVHlwZS9Hcm91cC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0I+ Pi9UYWJzL1MvU3RydWN0UGFyZW50cyAxPj4NCmVuZG9iag0KOSAwIG9iag0KPDwvRmlsdGVyL0Zs YXRlRGVjb2RlL0xlbmd0aCAxMDE4Pj4NCnN0cmVhbQ0KeJydV1tv2zYUfjfg/3AeqQJheKc4BAEW pwk2oNilHvqQDoPqyI5WW8ostUX763coZYXomArnF9mSzoXfdz4eHsH5r3Bxcf5m8dM1sMtLuLpe wD/zGQNGGWNcCGbBCgZaMdiX89m7V1DPZxw2320YM5ypwGj9aj77bT6D128WAKME/CnB1XI+O7/h oBRlRsFy7SNiOODAdU61AzX8LHc+DeY6v31rYdP6u9v57I5cF5khXcY5KeC2yHLSPZT7jAtS3kMm hzcNoJUa/pfZn7D8eT57jZl99v/SacOpHme7IzAyfYZABAgESBasXkmKz/Kc2nyIdsFYbi/D3B75 gZ9lVAgVeAYQM01WD8U+E4wUqy5zBMFKUn2r8FpvAA0dVLvHbYn3u7LOOHvyzCzpqqZuY/ClozIP 807ilwf4hXlWQesGLNp85xRZuOJHWDjizRn3Sxl7k3dV9+Ap2DV4wSpLUoInoYF1JixpttsGFfAl glFyRZUOI05iVCk1FqgbfVKNR56EOw59YbkLCtt6kF21aj3sZg0V6rgvrzpeXlh5OrZb9C0xTL8P InQY1LoLAUzToRPoELk+kY6xJ1k0CPAz1nJgod78EAHB0UuGvpMYTLJshZZU2lNlO/Ymv98gkgUg JGOVA1+V9+QXLNmPn7ye8db/afbVt4xbrKXrawm+sDeoCEOKXdnr2vey/cf3WbSHacoPck+yYY+w cZwMIShPIOM4FyNnz4X1XEjkQjPwCvZcGE9BdiaI50ORq7IYtvceEPgyyw1pPmYSH9R+I/zRFpu+ mcepYBLbeZB5kok8lQnuGHWnMjF2Jvf7odqKrLuYurGSPMxJzmK2eIAxE9pWvk9065iHw0aYp0UX TCGfgWlToGhj5sbQnCeGtopaGdq2xW4rYm1cWi/vpNhSYXs4WMeHXlvCt5bjToprKg4STIrHJYtH O2pPFs/I+f+IZ+z2knjGtmniSYn+JJ6xaYp4kkI/iWds+/eXGCWS5VTKtMiSGyoOVv2idGSOTgcJ JqXDWfKBxAXOpurUA2nsPck+N6qXwtg+KhvLqQtiwxl+CgiG49XqjnyObWEvHhcgwsfeY0pB+cGi dp+2XeVHoYiLE70yUnBIxqjRoe1w/rSPOFTFUkiEYWxaCuX3gAttu6+PZWwgV7gj88TlK4Ny08/K wJXqSeV/segp6foW8awO05rlqf3OYadWCZI9qtixM3m7whGhQbr8J859iSPSuqr9Jx4OCx+wT32F 4X1dxcZdaXtCg6hRPdie0MB2hYNIU9d+qo5VQVGp0xIoK/wRE9juyrbF2cZPNoxEdaGtpLlIy6Jz JDKoQq8LJkT+gjAMfhTwIEtMGP8CjzdNgA0KZW5kc3RyZWFtDQplbmRvYmoNCjEwIDAgb2JqDQo8 PC9UeXBlL0ZvbnQvU3VidHlwZS9UeXBlMC9CYXNlRm9udC9BcmlhbC9FbmNvZGluZy9JZGVudGl0 eS1IL0Rlc2NlbmRhbnRGb250cyAxMSAwIFIvVG9Vbmljb2RlIDEzOCAwIFI+Pg0KZW5kb2JqDQox MSAwIG9iag0KWyAxMiAwIFJdIA0KZW5kb2JqDQoxMiAwIG9iag0KPDwvQmFzZUZvbnQvQXJpYWwv U3VidHlwZS9DSURGb250VHlwZTIvVHlwZS9Gb250L0NJRFRvR0lETWFwL0lkZW50aXR5L0RXIDEw MDAvQ0lEU3lzdGVtSW5mbyAxMyAwIFIvRm9udERlc2NyaXB0b3IgMTQgMCBSL1cgMTQwIDAgUj4+ DQplbmRvYmoNCjEzIDAgb2JqDQo8PC9PcmRlcmluZyhJZGVudGl0eSkgL1JlZ2lzdHJ5KEFkb2Jl KSAvU3VwcGxlbWVudCAwPj4NCmVuZG9iag0KMTQgMCBvYmoNCjw8L1R5cGUvRm9udERlc2NyaXB0 b3IvRm9udE5hbWUvQXJpYWwvRmxhZ3MgMzIvSXRhbGljQW5nbGUgMC9Bc2NlbnQgOTA1L0Rlc2Nl bnQgLTIxMC9DYXBIZWlnaHQgNzI4L0F2Z1dpZHRoIDQ0MS9NYXhXaWR0aCAyNjY1L0ZvbnRXZWln aHQgNDAwL1hIZWlnaHQgMjUwL0xlYWRpbmcgMzMvU3RlbVYgNDQvRm9udEJCb3hbIC02NjUgLTIx MCAyMDAwIDcyOF0gL0ZvbnRGaWxlMiAxMzkgMCBSPj4NCmVuZG9iag0KMTUgMCBvYmoNCjw8L1R5 cGUvUGFnZS9QYXJlbnQgMiAwIFIvUmVzb3VyY2VzPDwvRXh0R1N0YXRlPDwvR1MxNyAxNyAwIFIv R1M3IDcgMCBSPj4vRm9udDw8L0YxIDUgMCBSL0YyIDEwIDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0 L0ltYWdlQi9JbWFnZUMvSW1hZ2VJXSA+Pi9NZWRpYUJveFsgMCAwIDcyMCA1NDBdIC9Db250ZW50 cyAxNiAwIFIvR3JvdXA8PC9UeXBlL0dyb3VwL1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQj4+ L1RhYnMvUy9TdHJ1Y3RQYXJlbnRzIDI+Pg0KZW5kb2JqDQoxNiAwIG9iag0KPDwvRmlsdGVyL0Zs YXRlRGVjb2RlL0xlbmd0aCA3MTg+Pg0Kc3RyZWFtDQp4nJ2VWW/TQBDH3y3lO8zjbqVs97YXVZVI WiqQKoGI1IeKB+M4hwhx6gPot2fWKcXbOibkzcdcv//M7ML5R7i4OL+dvr8CfnkJk6spPIwiDpxx zoWUPIZYcjCaQ5mPorsz2I6i85vPIoZlNYoELJ+tObeC68B8cTaKPo0iuL6dAnRSiadUkxkGeydA a8athtnCR8RwIEAIybgCbRJmHMy++zTLNvU+M4ebUXRP3m42VBOgY03qVQ7VLs8qSEsqLMnha77e LqGp8jn9ArMPo+ga8/mcf5JYnjDuuknuMdZf21eFy6BwCQqLDOvWiuHnhDOV7ANecJ7El2F+z/za NeZMSh04k0lTU0UA2WhMHiGlY0mQTu7p8NcTIMzXCyoUWVCZkHxvsaUJqTdo83gA3wjH4jDfIL3q obd9+EozGf8b3/bzd7zJlceyIVaWV16Tlj7bNNj/ef7mAKKSMZMujDnIqF8wor+zYZmuLVM6yZx7 hpyIHsjXzoILFieBM5n6Hq2xXdi/GkfZkPpxh1R5hS8JqZod/t8VZU2FIAdnWeEQWxVGHiQ1R5Ma yaw5lbTjTG5KKhVJ28F8CarJwKJKp30bg2CDcPZoODxnlDoVruNM7todxU0t/XTSsSNVhh+K3VMf /amkcG8rP9C1f069/Tpr4X9QoUm6adC4oGNFSm+H81A2Wd2gZ3y481Y6ZmRYzKA48bHiiBi3VJwo Tte5R5w085i4yxXU1JLiG5UOl9trpZ61Kvzopw9N3ipYtKLI40Qx2tcVFDEoSnK0KEowa08VpePc I0rppyCnjizwyeBirFo5avzSL5A/CZudXyJ/PrjDehiFJYXFD+vhjrvqEsuM1idedV1nVGOdrSD3 XL/a+7wl3FZrD7eFXeHvvjWekpzU1V4w0+rgL0Nq2uMD0u28XadVgRY/D82GUCwJkwP9jyZqw6Tt 82xF/A3vgPvUDQplbmRzdHJlYW0NCmVuZG9iag0KMTcgMCBvYmoNCjw8L1R5cGUvRXh0R1N0YXRl L0JNL05vcm1hbC9jYSAxPj4NCmVuZG9iag0KMTggMCBvYmoNCjw8L1R5cGUvUGFnZS9QYXJlbnQg MiAwIFIvUmVzb3VyY2VzPDwvRm9udDw8L0YxIDUgMCBSL0YyIDEwIDAgUj4+L0V4dEdTdGF0ZTw8 L0dTNyA3IDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0L0ltYWdlQi9JbWFnZUMvSW1hZ2VJXSA+Pi9N ZWRpYUJveFsgMCAwIDcyMCA1NDBdIC9Db250ZW50cyAxOSAwIFIvR3JvdXA8PC9UeXBlL0dyb3Vw L1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQj4+L1RhYnMvUy9TdHJ1Y3RQYXJlbnRzIDM+Pg0K ZW5kb2JqDQoxOSAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA2NjY+Pg0Kc3Ry ZWFtDQp4nL2VTW/TQBCG75b8H+aEditls1/2elHUQ9tQQCoKNIhDyyFKt21EY6exgwq/nlmnQV5q u1EOXCJ5Ml/PO7uzMJzAaDS8OP1wBvz4GE7OTuExjjhwxjkXUnIDRnJINIe1i6NvR5DHkYC7vz6c p4LrwOn2KI4+xxGML04BGgXEc4GTaRwN3wlQltlMw/TWZ8R0IMAIJoQEneBfAqZLXwZrDc8vDdyV /us8jq7I19IBVaS4hTEdKPJU0Yy4vFwUOfjvCZWCFIscrVUJVJNFCdW9g0/Fekm/w/RjHI2xB9/H rnCqM5bZZuErAg3fFzAygJGgJOMhi1YMzRlnKtsmHHGemeOwfq3Di1DDmZQ6CCbjJ49WUaFqVKSq aVOy8qQWSVERNCRkU7obWOTzB/TZ3Li3Hcg61SyxYZFeZPUPsjQv52e3jeNo8eTsqE9EC3VLtOCC mSyIJpdzakixcvVgf1KRkNnDBkld2YEltWGpCJP0YukWrLSNStqMmeR1qrQNqhlMztdUKjKrD2g9 surXCofVzaQUS22Yo5cp2ZspyZhWhzI1gskXPxtXroq8dNuTaF/FMhlTKkzTi5XujSUyxu2hWI3g Z6zHjWcq/eWrarLVbDvCpbdXeP3cmgpLcNsMNLkmMzqQZFPd+yW1XvymkqPJkAo31E6bN1D5k/2D SgzOr2nXYsKebNhSr0RmX4mEMczscUdbJWoGt07+/+mDyqRhP736ZHvrowzT8lB9GsFksq7fI/9I FXOakuKhXmYuv/G3w29vIf36bgdUImXWhBl7Ce2+hNYw/3QfRtgMJu+ndIBXYzqpl9kMB+sQSuA8 5zj6cLLoV87v3bJzK2jc3CIJC0CH73MzSYq/Xb79jw2qq9sia1n/AGDz6MQNCmVuZHN0cmVhbQ0K ZW5kb2JqDQoyMCAwIG9iag0KPDwvVHlwZS9QYWdlL1BhcmVudCAyIDAgUi9SZXNvdXJjZXM8PC9F eHRHU3RhdGU8PC9HUzE3IDE3IDAgUi9HUzcgNyAwIFI+Pi9Gb250PDwvRjEgNSAwIFIvRjIgMTAg MCBSPj4vUHJvY1NldFsvUERGL1RleHQvSW1hZ2VCL0ltYWdlQy9JbWFnZUldID4+L01lZGlhQm94 WyAwIDAgNzIwIDU0MF0gL0NvbnRlbnRzIDIxIDAgUi9Hcm91cDw8L1R5cGUvR3JvdXAvUy9UcmFu c3BhcmVuY3kvQ1MvRGV2aWNlUkdCPj4vVGFicy9TL1N0cnVjdFBhcmVudHMgND4+DQplbmRvYmoN CjIxIDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDgxMT4+DQpzdHJlYW0NCnic nZZNb9pAEIbvSP4Pc1xHzWa/7a2iSCFJo1SKkipIOUQ9OGDALbYphkb59521E+QFTBEXPsy+M/PM 7MwAZ49wfn52f3V3DeziAvrXV/An6DFglDHGhWARRIKBVgwWadB7PoEi6J3dPvEIJlXQ4zBZn2bM cKa84+OToPcj6MHN/RVAyxX/cNUfoLFvHJSizCgYjJ1FNAccDKciEqB0TLWFQe7cTGrXjWcGt0Hv hdwVoSXLkHOSLkJuSDl37xFJXrNZtnwPFYEMXyrop1kxgcshfplmaWjI31o0Cn/C4HvQu8FIXDRr 9+g3km33LwRaZ7eQhIckQArKfCIlKT6OGZVxY/CcsTi68P27bGxLI0aFUJ6YDELLSAnhqSTJ0CFp h8RICh1IgmMA1jeSFU6C+ZPr/HWoJYtorH31F/QuSJbPZ5jVNE+LMG5sJWFEllkoSVlUeCYmq2or rE9SsxtVcWr1h58h2i3zvCxgXhe3HGczxE2rLtLY1rG2bewtnjyseMJqGkdHFq8txuIpTt4wS1hA ReZN6h0V5rGC9G82cp/qfH7tKkhD55ndC6k2IEVErfEjtU2kWq0vPWL2+Q7MbTFnnEaxJyYPc2RQ BJ2Hp5ZclUWRDpf4uUYWbI1c/1yO4cHl4XK1nOID7E5MZQe85pZaP9L98PpgeK6o0MfCt8Sf8DdY 5afHu86m5E7hCbsbOHIzyTt72nVWmMPt4p3dtPuUJ4umUrcLN0BHXWKJgzracOQXt0OopKZ6T4Rb JTSHNSk3lnJ5ZJO2xWQwdTNRuuupSZ6E3JJ3mCbu0cekfU3TAsqlO4fAXeNISeta1LO9lzTaQWp2 oQpJmfg/6u4R21aThwZC4KZ0Y8mBCwduya9VFXJFlvC6chN9NnLXAVcpdqgh41qT5G77vLkpvfgN IdfNxB51ld5wQ7XxA9ibkPjQ7o3xMip1ZPe2xeTZYbpBtBuBG0n1hsQtU4kL0Nbps927VChDmfbF nc2pBdXSP5sM3dafZnV3KXcZFf7hmeF9xNK910s5mddLORtiNM02LgusntvGGOOqWhfRkmzZVSYZ U9UdZV2lf6M8I+4NCmVuZHN0cmVhbQ0KZW5kb2JqDQoyMiAwIG9iag0KPDwvVGl0bGUoT2JzZXJ2 YXRpb25zIGZyb20gdGhlIE9BdXRoIEZlYXR1cmUgTWF0cml4KSAvQXV0aG9yKE1pa2UgSm9uZXMp IC9DcmVhdGlvbkRhdGUoRDoyMDEzMDMxNDE0MzI0MC0wNycwMCcpIC9Nb2REYXRlKEQ6MjAxMzAz MTQxNDMyNDAtMDcnMDAnKSAvUHJvZHVjZXIo/v8ATQBpAGMAcgBvAHMAbwBmAHQArgAgAFAAbwB3 AGUAcgBQAG8AaQBuAHQArgAgADIAMAAxADApIC9DcmVhdG9yKP7/AE0AaQBjAHIAbwBzAG8AZgB0 AK4AIABQAG8AdwBlAHIAUABvAGkAbgB0AK4AIAAyADAAMQAwKSA+Pg0KZW5kb2JqDQoyOSAwIG9i ag0KPDwvVHlwZS9PYmpTdG0vTiAxMTIvRmlyc3QgOTExL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5n dGggMTYwMj4+DQpzdHJlYW0NCnicnVnbbts4EH0v0H/gH5jDO4GiwO62RYteEDQF+lDsg5to06CJ XbgO0P79nhFHdpqIZKIXU5J55szlcCRRJiqtLClPympF2iprFQWvrFOGgrJemRCVNZiUcKhsdspG 5UJSTgOWcUX5SMo5FYB1VoWE/6KKzmOaSlorHCUPUFaZMCWpDDgoSRuvPPMm2HKKCKY9HKBslA+K DCDeK7LaKZ8wBrgaFTm4FoBz0SqfFXmTVDAYk1eYQsGRCrAXMq7DXoRxj/8TwVGMWRuFKZQTIgrK aPgUMJIxKmSMEdEgXmMQh8WYtYpGGYuAIlLi4A+mGAcnIuZ5JCdGjLiIUExAwiLscCoScJETQcok 8CbgEnAJdjPigAsmMw5J1yhChEuacQk5B3ni9JuskGNrcBJRMIsKjUVC3HDNehQuo3YeyULqbNC4 DlwAKMNeRByEQtgIloyaJTdmH8XTnH6YzpxXhOU0fGIhOA1y0gGJQjSkUU1KmWuFFCJfpFFRi8tE qLDldOsMGRhYJqTXIRHE+fYoKurgPDzJsBJBBxW5iAhg0CUEQYQLWXPpWSdce7jhNUwTDHqNrJNh wbEvxrLy+AAyYY0QlOmt5gMIygaWDhTmDB9AUg7JhpigJegTaoK4RstQV4C82agfc8RLIaJCBOH7 5PgAqAyPybLUWFzQfNCGg4No+AyyxQHXFaOBDg2vBa47qhR43bC6oBOLMTIqQl1IXyZeLIiDMDEj g8+erU54lWn1cXW6Ov2x3qw+/f4xrE73u5uz/cur4Xp1cqHs+P9bpZ8/f/pkhCCiAnlN9wBvvyj6 Vx1wB8yB5tPwa/91+2sOiHRgzhwaGSvokzmceTzEPh7iFoc1QrjHjYOvBWnsVImry/NhNtBYTOgy mGq6ejVN92uaH1LTNE/TCN7po5N/ot0U7ru/t+e/G3W9A5uK9O7NLJ+r8oUen52F+TZfrPIdHJ3F hSou9fx0S/KSa3xe9/j8Aj5PVb5u3cMsrMNXrbv3Pb64hK9aPx97fGkJX6ry5R5fXsAXqus2UI+P 9BJCUyXsCoZm21OPsN4pmiu36FdkJdWWIkhuxONZ09QyXVqitBxpBLI+JZrFbbiK7t91rNx1Soiu urDDtNBqdx3y9247YWp2zdtOAd4nagQcbvW7O/B4KG/nxnMXd6jdrJ6irTO6B956Hsno64zdJuTm caHNmOqM3TbklzAmXWVM3UYUFjGaOmO3E8VFjK7O2L15pUWMoV7HZocqupJiSwUkLeLrfBhdOeYl CyA15KibYZgSRnkkL8kSJxd3nEhVeL/HhuJCaYfi/Hwmp2VWbbL3n+3z1PDaTTbNEzVCzrdb3p/w 3H3aNvO49uN2jnXGbgOy87jUZOSNjBolb2U8sM0+ktM0OLtNyC/jdA3ObhsKyzhDg7PbM+IyztTg 7GooLeKkhoaoq6G8jLOuoeMim6UrzV3EPQluEsFUmClZUwDzRK5JVJperhfkQU3IV+H9vpvLw3Xp kOJupUwHW5XGa/S9xsu7ig/ovAU5Q9WImncuD77eNWC6r/SmwnzQ/7ymDDVIu4/VdiGpbZB2G5Or AF2HNDRIu53JLyRNddJjluahsjhNSxbd7haWVcjqOqnttre4kNQ0SLsvXKkCtB1Sv7hC1jWgqV1c LcU1MjoZpQNb6dS2sVIe1lRy1UC/l/JXlXJDCDLW5HwL/Gk3DB+32/3q4/ZqeL/+oWSNnKx3w2b8 V8ka565VDFt5WC6ST9Nt6BD8AfoBob4dfisvvK9AtNnuh9UH/nm5OT+eTFk5Hc72q9fD+nzYlWPG TMdvNleXm+H025rd5wt/bWBhvb/cbuR8t7/8b42D8ezzdvf963b7ffVie3ZzDZ/GKz+/DcOendyv 3q/Pdttb5/98w++t8xeX66vtxa0LJffHuYUH0y526+vVq8uLm90gsX64uf75BRkpPUURfw7iA8Pf g8Ys8gchPnDjF6Exd4w9fmYof89/vuB5sjFUtvhl5102xGW/WbaBZXdWNk1lL1O2GGXj77Adx4an t6Fio2ysyG6HbEHIvoC8rMsbtLzWHl4L2dR0gy828vToIgtKy4LSolwtytWSNJJ507MUWzzKXIwZ WX1GnpNEpTRlXj7XSMM69pCnT/4HLlPSRQ0KZW5kc3RyZWFtDQplbmRvYmoNCjEzNiAwIG9iag0K WyAyMjYgMCAwIDAgMCAwIDY4MiAwIDMwMyAzMDMgMCAwIDI1MCAzMDYgMjUyIDAgNTA3IDUwNyA1 MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDI2OCAwIDAgMCAwIDAgMCA1NzkgNTQ0IDUz MyA2MTUgNDg4IDQ1OSA2MzEgNjIzIDI1MiAzMTkgMCAwIDg1NSA2NDYgNjYyIDUxNyAwIDU0MyA0 NTkgNDg3IDY0MiAwIDg5MCAwIDAgMCAwIDAgMCAwIDQ5OCAwIDQ3OSA1MjUgNDIzIDUyNSA0OTgg MzA1IDQ3MSA1MjUgMjMwIDIzOSA0NTUgMjMwIDc5OSA1MjUgNTI3IDUyNSA1MjUgMzQ5IDM5MSAz MzUgNTI1IDQ1MiA3MTUgNDMzIDQ1MyAzOTVdIA0KZW5kb2JqDQoxMzcgMCBvYmoNCjw8L0ZpbHRl ci9GbGF0ZURlY29kZS9MZW5ndGggOTMwMjcvTGVuZ3RoMSAxOTY0ODg+Pg0Kc3RyZWFtDQp4nOx7 B3xUVdr+OffOZCZTMjPJTNokmUmGTAgJCZ1QJAMp9JIykAQCCQlNpYWOgNg1iA1U7L2COhlEglhQ sTdULKur4lrWXQVxLbsiSb7n3HcOBHT94X//++23v19O8tznOe8p95z3nnPuOzBhnDHmwkXHJhVX jB7584rvuzHlMxjdF5eMKK58Lu+VTYx9vo+x+LdKRowriv3phv2MfYRyw76RxSWlf37mu6NMOWBn TD00ctLEinmNQ85l7OidjN9oGVkRHPHsR592MGVLiLGR0ydW5Pf56bP3vmSMv4cO6hrm1y/6+IIP 3mCs+5kYQG7D8qXe0A1732Ssei9j+pTZi+bM//HH8RbGcrcwFp08p37JIpbCfIx9eBjt7XPOXDX7 8D0vL2Rs+gHGRufNnVXf+EVm+2nofxrKB8yFwfqAoQD5zch3mzt/6Uqj3v0iYwps/j5nzGpa8MUt XzUz9lwV+q87c2FD/WeD3lYYuxfzSSudX79yUXrvzGi0b0V774L6+bP8y8u+Z+x15GPiFy1csrTD zS7EePaJ8kVNsxad8ZDSzlj/h3E7OxO+1d/cWnruHdtm2Ib+wJKMTKTdX615RfCzGVtW/3ykbUP0 14ZHkI1mCqOEdlGsnfG9plt/PnLk1uivtZ46JfXvwmLLYOuYno1mKlraWT6bxZjjCu2+nKm6HH4F So366/R90WUasbqPXagwI1NsekVRdKqi+4QpHQG2rUMbAdL4Cq+XBTAdO43BcLPi9zJ+i3bfnfoY MVP0HnN8NPx1PL3bxHP5fUlXw7bpiln9r5Z9zbadMOMvT8z/s6Q+wLbpLWzqL/o7ery9oju1vrS6 G5nhVOpFvYv79vj1fvXjWMOp3k8kXcbxfnRVJ/nhATby19qoXzDbCffMYPf/nnsa0thpv6d+V+pK Iqlvs2m/t42uH7tOnclqTrFu3Qn3+5nVnko7ZTHL/L3j+t9M6l7W/1TqCV9Jzd9hF/yee/C/drx9 7H53nNDPdb9WP6qRXdf5fr8YS8GpPbNj9SN9iWeovHRiv2o6KzuVPpQHWfrvuee/kjDOzadaV72J Zehbf/kM1RUsW72FZfzCns2q/9XxdaWu1JW6Ulf670nKDdx0qnV5B+uhtenGdit6du2/b1THk7KE lfxWuXq046cT6s9nFwCr/51jUvuzDfpl/847/O8lfE4+I8Ll/+FxjAIeBJqAOUAvYJYYH9Agxvef HmNX6kpdqSt1pa7UlbpSV+pKXakrdaWu1JW6UlfqSl2pK3Wl/9qkRpBC32jjechBqclMx2NhyGBe ptO+B2eF9rNslscGszFsEguyKWwGW81uZQ947R0dWm9W1Paz7iyX9WLD2XhWrtWpP1aHd/yAvpvU yZ1GkKq6GetoUJ79dGbkW3VpkWsGG8BGsQlabtLxEatj1GvVIHqpUr9WD6qH1G/Uw+q36t/U79Tv 1R/UKRivg8WyRMzJz7IwlnyMuJiVsLEYTQ2bzhrZXK5wG7fzZJ7Gu/NJvIbX8nn8TL6QL+PL+Vp+ Cd/AL+VX8Ov5Dr6HP8Wf48/zV1gU/1obwbcnf/sPeSXyXUGF/Xbix+cQmc4WYJ16tqa1WYF/fV6d 06/NUSQ5TyZnCrX0pEe+GsP4f5n//+2k/n/trWv1n/T0AyMbZ0yvnTa1proqWFlRXjZp4oTx48aO GT1qZGlJcdGI4YHCYacNHTJ4UMHAAf3z83rmdvdndvNleBKdDrvNajZFGw1Rep2qcJZb4iut84b8 dSGd3zdqVE+R99XDUN/JUBfywlR6Yp2Qt06r5j2xZgA1Z59UM0A1A8dqcrt3KBvaM9db4vOGXi32 eVt5TVkV9MZiX7U3dFDT4zWt82sZKzLp6WjhLUmcW+wN8TpvSah0+dzmkrpi9NdiNhX5imaZeuay FpMZ0gwV6u5b1MK7D+OaULqXDG5RmNEqbhtSM0vqG0OTyqpKit3p6dWajRVpfYWiikIGrS/vPDFm tsHbkrun+dJWO5tZl2Np9DXWT6sKqfVo1KyWNDdfFHLkhLJ9xaHs1Z8lYsqzQrm+4pJQjg+djS0/ dgMe0mfafd7mHxgG7zv49YmW+oglKtP+AxNSTPGYm1AuNcPYMELMLz1djGVDa4DNRCa0vqyK8l42 0x1mgfyc6pBSJ0r2yBJXUJSslyXHmtf50sWjKqmL/C6fmxhaP9PbMxfe134z8Ytyb0j1181smCu4 flazr7iY/FZZFQoUQwTqI3MtaemVj/r1dZjEPOGGsqpQvm9RyOkbQRVg8IpnMK+iSmsSaRZyFoVY XUOkVSi/pFiMy1vSXFdMAxR9+cqqdrG+HQda+nnd2/uyfqxajCMUX4SH4i9prmqcHfLUuRuxPmd7 q9zpoUA13Fftq5pVLZ6Szx7KPoDbpWt31FphbifVlpXFzA2ZRm+V4larxdOCwVuKi2/EUBTY8bi0 rHiiI4Z6q7ibyWq4S6SGUCf0g4yaWTRKFKmiadEod3p1OqXfGJI7MiZ9ZsjYqS87DMfGRPf5p0Oj 2mJA2d6SWcWdBnhCp/rIACO9/fo4FeGLyI3Rwige5yhZpGZi58KmoBvNJJ5iojfEJnmrfLN81T6s ocCkKjE34Wvt+Y6t8I0tq6nSnnZklVSekKPyAsqFWDqKZUYpwhoszXHLx6rlR2r5Y9lRJxWPlsXe ZqNvbEWz6NwX6ZB5sYMw6Sj/6PoNBbH9sDVLcbr5Sut9Xru3tLm+tWP9zOaWQKB5UUnd3MGiD9/o xmZfRdVQtzbW8qq17tXiVrFsLB9bOaJnLs6eES0+fnFZS4BfXFFTtcvOmPfiyqqwwpWiuhHVLd1Q VrXLy1hAsyrCKowi4xUZ0VM5MkatvntXgLH1WqlOM2j5hlbONJtR2jhraFXIZpc2BTYd2QKaTSQ8 pMS5cDGO2xJvo3g8a6rnNtdVi83F4vEo8ctD3DeMhRTfsBauRFlCJt+sESGzb4SwFwp7IdmjhN2A hcHjOZwjzqTmOh/OKSyoKubmtBRV0aW3taOjsir9VffB6nQstWlATVUoOgdnvz5zDOqNFKiDeWRo fUO9GAcLVom2hszRDdVYtrJDVBkdikYP0ZEeUKNUayOWIxo14NngAWrt1yMTWl8dqs4RN62aV60t Z3uIjfINxmOnPvV+caP86uZYXx9tb2IrmDIvEhSNsbGKKrK4kcXNqslJBgtG3uBDUUOdF97WsYYK LHU6S01usszCkajzz9JgckcKmZiWmmm2mkLReegQv0Kb88SW1Gcaqqtp8FruokgF3NseMmNE/k6u jDSAd1A0WowFvxdhqKLqU6KbslZW7luJk0UMWuvJgOKQNXN0PQ5/am+GxVcgGxvFGWGO9LGXrAYx cwv8rmZWtnbc41uV3in1zPWJl4NYmMy9CwubVTefbAhNzemZazzZatXMzc1G6683IH8ZrcdYGL0l eGswFo5Wva3K+Q9HJ/IxEOdJca4U50ixXoqzpVgnxVop1khxlhSrpVglxUopVkixXIplUiyVYokU i6VYJMVCKRZIMV+KM6U4Q4rTpZgnxVwp5kgxW4pZUjRK0SDFTCnqpaiTYoYU06WolWKaFFOlqJGi WooqKaZIMVmKoBSVUlRIUS5FmRSTpJgoxQQpxksxToqxUoyRYrQUo6QYKUWpFCVSFEtRJMUIKYZL EZCiUIphUpwmxVAphkgxWIpBUhRIMVCKAVL0l6KfFH2l6CNFbyl6SZEvRZ4UPaXIlSJHih5SZEvR XYosKfxSZErRTQqfFBlSpEvhlcIjRZoUqVKkSOGWIlmKJCkSpUiQIl4KlxROKeKkiJXCIYVdCpsU MVJYpbBIYZbCJEW0FEYpDFJESaGXQieFKoUiBZeCRQTvkKJdijYpjkrxsxRHpPhJin9I8XcpfpTi Bym+l+I7Kf4mxbdSHJbiGykOSXFQiq+l+EqKv0rxFym+lOLPUnwhxedSfCbFp1L8SYpPpDggxcdS fCTFh1L8UYoPpHhfij9I8Z4U70rxjhRvS7FfirekeFOKN6TYJ8XrUrwmxatSvCLFy1K8JMWLUrwg xfNSPCfFs1LsleIZKZ6W4ikp9kjxpBRPSPG4FI9JsVuKR6XYJUWrFDuleESKHVI8LMV2KcJStEgR kuIhKR6U4gEptkmxVYr7pbhPinuluEeKu6W4S4o7pbhDituluE2KW6W4RYqbpbhJihuluEGK66W4 TootUlwrxTVSXC3FZik2SXGVFFdKcYUUl0txmRQbpbhUig1SNEtxiRQXS3GRFBdKcYEUMuzhMuzh MuzhMuzhMuzhMuzhMuzhMuzhMuzhMuzhMuzhMuzhMuzhMuzhMuzhMuzhMuzhMuzhTVLI+IfL+IfL +IfL+IfL+IfL+IfL+IfL+IfL+IfL+IfL+IfL+IfL+IfL+IfL+IfL+IfL+IfL+IfL+IfL+IfL+IfL +IfL+IfL+IfL+IfL+IfL+IfL+IfL+IfL+IfL+IfL+IfLsIfLsIfLsIfLaIfLaIfLaIfLaIfLaIfL aIfLaIfLaIfLaIcXbRcCUXM4bZgHMXM4zQU6l3LnhNMGg9ZT7myideE0C2gt5dYQnUW0mmhVOHU4 aGU4tQi0gmg50TIqW0q5JURNZFwcTh0BWkS0kGgBVZlPdCbRGeGUEtDpRPOI5hLNIZodTikGzaJc I1ED0UyieqI6ohlE06ldLeWmEU0lqiGqJqoimkI0mShIVElUQVROVEY0iWgi0QSi8UTjiMYSjQm7 R4NGE40Ku8eARhKVht1jQSVh9zhQMVER0QgqG07tAkSF1G4Y0WlEQ6nmEKLB1HwQUQHRQKIBRP2p s35EfamXPkS9iXpRZ/lEedSuJ1EuUQ5RD6Jsou5EWdS1nyiT+uxG5CPKoK7TibzUzkOURpRKlELk JkoOJ08AJRElhpMnghKI4snoInKSMY4olshBZXYiGxljiKxEFiozE5mIoqnMSGQgigonTQLpw0ll IB2RSkaFcpyIacQ7iNq1KryNckeJfiY6QmU/Ue4fRH8n+pHoh3BiJej7cGIF6DvK/Y3oW6LDVPYN 5Q4RHST6msq+IvorGf9C9CXRn4m+oCqfU+4zyn1KuT8RfUJ0gMo+JvqIjB8S/ZHoA6L3qcofKPce 0bvhhCmgd8IJk0FvE+0n41tEbxK9QbSPqrxO9BoZXyV6hehlopeoyotEL5DxeaLniJ4l2kv0DNV8 mnJPEe0hepLKniB6nIyPEe0mepRoF1Er1dxJuUeIdhA9TLQ9HF8ICofjp4JaiEJEDxE9SPQA0Tai rUT3h+NxXvP7qJd7ie6hsruJ7iK6k+gOotuJbiO6legW6uxm6uUmohup7Aai64muI9pCDa6l3DVE VxNtprJN1MtVRFdS2RVElxNdRrSR6FKquYFyzUSXEF1MdBHRhWFXPeiCsGsm6Hyi88Ku2aBzic4J u4Kg9WEXDmN+dtg1ALSOaC01X0PtziJaHXY1glZR85VEK4iWEy0jWkq0hLpuouaLiRaFXQ2ghdTZ Aqo5n+hMojOITieaR+3mEs2hkc2m5rOIGqlmA9FMonqiOqIZRNNp0rU0smlEU2nSNdR1Nd2oimgK DXcy3ShIvVQSVRCVE5WFnQHQpLBT3GFi2CmW94Sw8zzQ+LCzJ2gcVRlLNCbsRFzAR1NuFNFIMpaG netAJWHnRaDisPNsUFHYuR40IhxbChpOFCAqJBoWjsX7nZ9GuaFhRzVoCNHgsEMsjUFEBWHHSNDA sKMKNCDsqAH1p7J+RH3DjlxQH6rZO+wQE+sVdoi9mU+UR8170h1yiXKosx5E2dRZd6IsIj9RZtgh vNSNyEd9ZlCf6dSZl3rxEKVRu1SiFCI3UTJRUtheC0oM26eDEsL2GaB4IheRkyiOKJYaOKiBnYw2 ohgiK5GFapqppomM0URGIgNRFNXUU00dGVUihYgTsUCHbaZHoN3W4GmzNXqOQv8MHAF+gu0fsP0d +BH4Afge9u+Av6HsW+QPA98Ah4CDsH8NfIWyvyL/F+BL4M/AFzFzPJ/HzPV8BnwK/An4BLYD4I+B j4APkf8j+APgfeAPwHvWMzzvWnt73gG/bT3Ts9/q97wFvAn9hjXHsw94HXgN5a/C9op1vudl6Jeg X4R+wXq653nrPM9z1rmeZ61zPHvR9hn09zTwFBDo2IPrk8ATwOOWxZ7HLE2e3ZYlnkctSz27gFZg J+yPADtQ9jDKtsMWBlqAEPCQeZXnQfNqzwPmNZ5t5rWereZ1nvuB+4B7gXuAu4G7zD09d4LvAG5H m9vAt5rP8NwCfTP0TcCN0Degr+vR13Xoawts1wLXAFcDm4FNwFVodyX6u8I0wXO5aaLnMtMcz0bT XZ5LTfd4LlAzPeerBZ7zeIHn3OD64Dlb1wfPDq4Nrtu6Nmhey81r3WvHrj1r7da1H6wNxEaZ1gRX B8/aujq4KrgiuHLriuCjyoVstnJBYGhw+dZlQd0y57Kly9Tvl/Gty3jxMt5rGVfYMvsy7zLVsjTY FFyytSnImiY1rW8KNemGhJoONCmsiZtaO/Zsb3KnlYIDa5qs9tLFwYXBRVsXBhfMnh88HQOcVzAn OHfrnODsgsbgrK2NwYaCmcH6grrgjILa4PSttcFpBTXBqVtrgtUFVcEpqD+5oDIY3FoZrCgoC5Zv LQtOLJgQnAD7+IKxwXFbxwbHFIwKjt46KjiyoDRYgsmzFHuKN0W1iwFMSMFImJuP6OUOuA+4D7t1 zB1y73GrsbZkT7KSbUviRROT+MKks5MuT1Jtia8nKoHE7NxSW8LrCR8nfJOgiwskZOeVsnh7vDde dYm5xY+vLNW4sJi4d39truPjff5Sm4vbXB6XUuJxceY44DjsUF1P2l+3KzYbt9k6bErAhuq2GE+M Ii4dMWogpvfAUpvVY1XEpcOqxgessIgesyyTKkttZo9ZCRaaJ5qVgLmwqDRg7tmrlKncyznjdpBq FKPgLk8p9vX2eK7neJ+3VFbk5IxtNbLysSHjpKkhfnEos0JcA2U1oaiLQyxYM7WqhfPLqlu4UlQZ cor/sdXyF2zcyEakjg2lVlSFbk2tHhtaDxEQogOCpbbEsxHVOdOXLFuSk7N0Oi7TlyzN0X6R48tE LkcYxe+SpciLn2VanuX8ZqJqoBlLkJZK49LfbvV/PfH/9AD++1MLE18yGN6hnM8alfOAc4FzgPXA 2cA6YC2wBjgLWA2sAlYCK4DlwDJgKbAEWAwsAhYCC4D5wJnAGcDpwDxgLjAHmA3MAhqBBmAmUA/U ATOA6UAtMA2YCtQA1UAVMAWYDASBSqACKAfKgEnARGACMB4YB4wFxgCjgVHASKAUKAGKgSJgBDAc CACFwDDgNGAoMAQYDAwCCoCBwACgP9AP6Av0AXoDvYB8IA/oCeQCOUAPIBvoDmQBfiAT6Ab4gAwg HfACHiANSAVSADeQDCQBiUACEA+4ACcQB8QCDsAO2IAYwApYADNgAqIBI2AAogA9oBvegasKKAAH GGvksPF2oA04CvwMHAF+Av4B/B34EfgB+B74Dvgb8C1wGPgGOAQcBL4GvgL+CvwF+BL4M/AF8Dnw GfAp8CfgE+AA8DHwEfAh8EfgA+B94A/Ae8C7wDvA28B+4C3gTeANYB/wOvAa8CrwCvAy8BLwIvAC 8DzwHPAssBd4BngaeArYAzwJPAE8DjwG7AYeBXYBrcBO4BFgB/AwsB0IAy1ACHgIeBB4ANgGbAXu B+4D7gXuAe4G7gLuBO4AbgduA24FbgFuBm4CbgRuAK4HrgO2ANcC1wBXA5uBTcBVwJXAFcDlwGXA RuBSYAPQDFwCXAxcBFwIXMAah6/n2P8c+59j/3Psf479z7H/OfY/x/7n2P8c+59j/3Psf479z7H/ OfY/x/7n2P8c+583ATgDOM4AjjOA4wzgOAM4zgCOM4DjDOA4AzjOAI4zgOMM4DgDOM4AjjOA4wzg OAM4zgCOM4DjDOA4AzjOAI4zgOMM4DgDOM4AjjOA4wzgOAM4zgCOM4DjDODY/xz7n2P/c+x9jr3P sfc59j7H3ufY+xx7n2Pvc+x9jr3/nz6H/8tT9X96AP/lKXHGdMYMNzPWvumEb5RPYqezJWw9fi5k G9km9iT7gM1k50Fdx25ld7P7WIg9xV5k7/7L313vlNpX6eczi7qTRbE4xjqOdBxsvxto1cd0smxC Lk7nPW7psHccOsl2qH1Th729NSqWmbS2VuVNWL/jbR1H8H5FvmOAyCsXQdu0Ft8abm5/qP2ek3xQ xmrYVDaN1bI6Vo/5i79QmAfPnMHOZPPZAi23AGVzcJ2NnPj+PM4STR+vtZAtAprYUraMLcfPIugl kZwoW6zll7EV+FnJVrHV7Cy2hq2NXFdoljUoWa3lVwLr2Nl4MuewczUlmSznsfPZBXhqF7GL2SW/ mbvkmGpmG9ileM6Xscv/qd54Qu4K/FzJrsJ62MyuZtewLVgXN7AbT7Jeq9mvZzezW7BmRNnVsNyi KVH6GHuO7WAPsofYI5ovG+A18oj0y2zNh4vggzWY4XmdRkz+W3HMW+swdzG35shMV8J+bqcWyyN+ FDXPQ03qhZ6D6GXtSZ64AnMgfXxGlLtam/9xa2ev/JZV+uPGTp65QcsJdbL1n+lr2E3YgbfhKrwq 1O3QpG7RdGf7zcfq3qrl72B3srvwLO7RlGSy3A19D7sXe/t+tpVtw89x3VkRP8ge0J5ciLWwMNvO HsaTfITtZK2a/bfKfs2+PWIPH7PsYo+y3VghT7A9OGmexo+0PA7bkxHrXs1G+afZM8iLWpR7jj2P E+ol9jJ7hb3OnkXuNe36AnL72JvsLfYut0K9wf6Caxvbp/+MxbDhjOkfhZ9vZNPxo8eptER9E6eI ygxsEBvPJrCpjzErXvfxbDDfscNVXGzsaXgCr3KFeREMGBnnRQGbTrHuTE4u9O3sH7VRdYxu5T0f LjRsRJhb2PZR22v5bR8djB2Uf5Dnf/jJR5/Yv33NMSi/7yf7P+ndizvSHRqcMYrB4IzyZeQp/bP8 A/r27TNM6d/P78uIUTRbvwEDh6l9+6QpqlNahikiz9U3j9aoE9uilHW+wsl99WnJNqc1Sq+kJMb2 HJppr5iaOTQv1aAaolS90dB94IiMsWeWZLxvcKS64lNjjcbY1HhXqsPQ9oE+5sjf9DE/F+nO/Hmz GjVkWmE3dYvJqOiiolrTEpN6DEkfPdkWZ9eZ4+yOeKMh1mHpXjyt7UJXiugjxeWivtrGwy2+jiO6 dXqn9jdJN+1i3Tq+fNhi5+N8rRHhb+04/LAZwiyFCSKQLFSmXVyt2tWiXQPdeaYozjXz8d18/szv LWZLYkaqz2Tl8ToLs9gtykO+J32v+1SfxWeJTS2PDeqDrLCwMHbQoPz82lpHwiAHpKOv/WAfR194 PKeWXoUsJyczPj5Kc3mWmq7GqL4Mv3/AQE5+TjD41HTdMiO3Z3o8mXHRuoVtX5yumuJ8KamZNm7k YZ01KSvN2yM5RncW/5g/fVq8O0anGizRfEj7i9HWaJ0+xh2vC5tjjKpqtJk3tp0l/gpsm/jjLayu NJbDCtgLgWRPop2P99ht4mLFJdGCixdzFf9HHOie7Aqg3BVAuctlzhWVc0XlXFE5V1TOFZVzH8Vn QtaxZwc08/eFp7ejJvjwdluErRr/uN2i8ZfbzYIVe8B6q3mPWTEnZ33fu7ehm/av0mX9Wrm5xVDJ Cg8Waut2EM+v/URzWp/9OSRgzskZRBpOdcbofOkZ/v6OfgP6psN7LrGe01TeL0/x+RxiMccdlzru KZjYsHh0+4MJ2dkJ3L90c0Of+JzhPfpPK+ne3pZcUDMmvLeofEDShMyRZ5S9dmRIVZGfLzltTvmw Hi5Plu7cLE9u5erxeZUjC2JN/csXKDx/XP+U9lrfkIltHw6uGuppL0gZWM44q+84rLPo07CLZ25P YUNyIl7JiXgF/LXwCviQ8EpOxCs5T+AzdgxL5Pksnfl5bjiuQreb92D9WS+e1xI9GVt6/0EBnk/T t7+zt3evTGdMVKdtGeWKbFOxgV3ONEXMWywrnUXRG52BGWeNXvfy5eMrrnnj7ILTa0rdRr2qM5qN MX0mLp44eWPjwP4NV0wdv6Ssn81gilJ32hNjY5zZWe7KO7+96bajD01zeXu4Y+KSY50pcdFZ+Vkl Fz615qzHzx7uz/dHOdKwA8UquxyrLJZ52IpAamE6jxMrJ06snDgn5hwXiwnHJWK2cbvFymHJ5Jvk iG+SIysmObJikiO+Sd6Nz/3R8I0lHFPmbuX+Fj2tEumL/XJF1IoT7YQlYei0AC6ffNfhu9sPaY8/ 894vbyrb0W/h/Rc+1LLm/qZByvX3/nxXOT3oKXd8ed28HeePOeoYtv4p8fepmJm6BjPLZctbkrMi TzQrMuqsyKizIqPOiow6q1VxBKKj47xxXgw+uZUbA9b1fr7Hz/f5ud8flST+g8ZalgVqiTq26msX N2Fa+doxYo+sfu05K79Y6b50x0lSXaMzWY1tm8QMldlGq1Gvx6U9ioeNOBp00dATFG60mnQjY92x RpqtMdbtjHU7jO2nR9tT4mKT7Yb23kaHW5t3xxG1EvPOYtNaDHGRecdF5h0XmXdcZN5xkXnHYd47 rKksLdWAqW2Pi0uKauXdt2eUJYkDMvJGyt/rGHRsdvwXk5FvGzldtRITM7TDewYMXtMBo9ObnJjh NGKqpZp1b1wKZjHKYHe74tyO6LbPDVaDXo+L7kExy1Qxo6kdh3Qr9V5WyG4PpKak2BLFCk0UKzRR nG2JJotQmEWieHpW9mQW92YFsuqy1CxbZP62yPxtkZ1si+xkW2T+NvHt8Px+vF9iKzc9nJExKH/Y bm7CO97Es8ODKpytPLclf7J43tjNDnJH5JzbX1u799hBF/HLCbt5wECHWAVit2vecogT8Pj+1+lW 6owWg6Vg+nk1Z9y/vLBk9X2zhp7Vv32/w6GLxjviBnN8rCl28LSZjb2v+fqOybX3HbxizLmzSpJN uulxqXFGf55/QvMTC9fsOb84NZWvyugGNxqN9pTY9rhkf2pGoqV22+HN1x8J1Sf7spMzaH3oJuGd m89aHy7szX2WiIssERdZIkvEElkiloiLLMK5KQndzML7ZuF9s/C+WXjfLM4Hs3hHJLCACy+WQJy4 2B18HAugnCWI/7RAgeBHUJbQoxwvkNyAbY+F77Nwy4lvY2yog4Ucb439wq2RJXd8Y9VmHltqnVcd nZou2KTUTTI60xOTvU5j23aoJLHyjM6MxKR0p1EZr61FqGR4H0vOYlSGtT0tte59qdqOKFFSR/YX r4L/XGzSzsKEiQkPJags4kIWcSGLuJBFXMgiLmSP4kw0dezZCU+Y7OXadDHNYwdh5i8mw6vkuKNd 6QlJnUd7fIRiVIaOQ/wzjKo7q9qF1/upDycVw3Hw8akxvvLo3bwPPiYn4t2lj7y7sOlzOr25xeii ZDipxZ3HR/pZSvHC8pSBeRlmg15R8YYyJvnyPBm9vHaaQlw0Lx2/vqZ3tM1hsTiSYuMRS9pibY68 suHqzWI+YheQf6NycH4NZdsC9rphi4Yp1l69EvLzTXmJicmtp/jyEWs1rVtvi8UkVqtJrFaTWK0m sVpNYrWaxOQRBwWShCe6DSgzJyZY8xN750V5upd5gnIxFsYiKOwLP8hoBpGh/ZhyDDotv29fESt2 enY+LuJDRIrcd8KZqIWKvK8IGjWPReUYnZ6khPQ4o9LeVzW7Up2uNKdZaR/JsTKTEr1xhlz3XG+v bonRfIWeX2hO9viT5tvccZbjS2DOz5sNJoOqw6sfwfh1x+x39+hmSe7uPjpFvTutR5I5Oi7VFdn5 6/QOdhq7YHuWzeaMOFNjW4StGh8WznRGnOnUnJlmysvrI5zZJ9EmLqjYx24RClX6iCp2llZQbsqz ZemSxHtDvB419wnn/cJ3+X0jL0jylN+f5YuPd/2Kv9LUhL5+//F1pltndSVbByZn+Xyu9rne4SmK ohjjPImJnlhjbnJ5apYn1cEHpw7o0zuR47UZ50mK98YaRzrx6cOc2idLOTBo7ZBR14w5+t2xF839 3TNMCdmethf6NdTV5k/cOlF5ArE53rxYjuLvPTsO6r7Up2NjZLE1gWSn8IFTLCinCI+cIjxyJpKb +gaivawXW4/oPS3i3LTISk2LvHjSIi+etIhz03YjhDSxJLxmbBW+Vp6jbb3OYVLtSfvv2Mc5LUrq FDPqvhyz6aPNV729oXjM5o82X75/Y8mOrKlbFi3aMiPbX3Nt0+Lrp3dXrrnpaMuMKXf/eOt1Rx6a Mfmu7+5b8PiGCZWX7p7TtGfD+MrLHxMRIeKH57H/Ulg2W9nSLSoykajIRKIiWy4qsuWiIhOJEksg wZEq3JMq3JNqt1j5uFTxmSNVfMGVOTLxbt0eFWXBNM3bXWWWTqEFLRD7idGF7+SQQtcpMFSfD6x4 YOWm6Lj0JHEs9kjmrh7j580fl71jyJTa3FtumDCntJu6qf7GBUPb847tCzxqQ0LhtFVTJp7eL6bt p+4jGxjNWGfGjAewYnZlIM2e5xhoxKgHilkM1GYxUMxqoHjKA/GUd2aLT1rZhQ7hCihHxDWOiGsc Edc4Iq5xiC++puTZEU0+suh/2Pvy8DiqK9+6VdX7VlW97/umVqu1tJbW1qVdrcWyLMuSF8m7jY3x gm02O2DWGQI89uSD8CUkLw+yDeB4k03yxXxDwpCMGZIBQ2aAx7yEAZw4CSQvrOp+51ZVt1qyPJm8 5a8nHetW9e2u6rrnnnPuOb9zrswjnre2AQdO+EetkpERfEgcOl0SOWUkLRECzyrqEpZYrB5KCqCs RosFpSPRSKToOmvkppDH4Tdp6GvNyfaVLfuLzAJX2ljT4Rjcvywa7FyX8aWTMdMBvTI/273cnq27 /1vdmzu9YGTAJKtAxWvSE9ng7C9LTATHTEbpmlbt6erYPtJs0idal9XkfxVyU7cP7bAq5Pkhf8ty sDZ9hYvUZtCbHPHuaaIDAnoDhOgdEos6JNZ1SLamQ2JVxwxZySdqeaMJDdXysC6FakO1WqcNX+vE BtzJMLiBS5x4OpxnyBpsxY85hWXt7DG7dDSJx5MG7IJoq55FUaIRnLkIr2F9jaiR12jREIurLtT4 rJFtZC2t4Pme6HDK4mOWGRSX9BCm4CKL/fpEYoq5yGBRnfNJOPGNBQpKz1sg06UFc2GgJ6c2d137 9amOPRMtVg0sfkp93fJ9A01TXaHaFTt2X7GirmXH/SsTE8OtRjlNUnKNQpPqnmpuWJ521I7t3L1z rA5dufa/QDjsC9jCXoubUwRiQU/j8rrGZS01de0r942M3rQqabB7jRrWZuQg/nMF3e7qznDDstba uraxfTBHBtD110DyA8TWUzYe+9Is5tpx7Cz8pxUfL6Rs4ewJLPlyDocNbkm3a8G5+UBgzo8TzPOJ UtAw574VzZkQL7wmBDsPFT0eOJOCIeo2IRQSYoXPvloSxE1K1mU0inAS9oG+A5b6evCBEsQjvHtD Evmw1vqwFvuw6Pjw2u/DUoN3NvJsuacKkkZYpAFbpAFbpAFbpAFbpAFbzpAM9uKwP4vLn3gV3EId WcGscM7JjeC+ShY8MSciU+hSf9W00JWir+85MnPwymdu7BbDJaOycuxgbvDgaEJgjR88qbeuOX2k s/36k9dSwSI7Pv9wzR2rk5WTt0xQ1nLPsA38qbeBK63E9mORVlQ7U/iY78JCH4bpUeKTWAqFGaEn jAI2fBIPIJsPnyRrULIaJUMoGUSNKypWBKs1VLmrDqt7FkYFPxgskyhc8n+o4lkk0tBQ5v+UnVks coXsVppxxT3ehEtP5z8gP6X0jrjPX+kyUPnvyBEb8XlDRgWJggiZKJUp7HH5TSoKxUnkpuTGoNsT ZJAsomfxms3qqZ9/niqe09+1OvQ0pdRrPnuebtYYsJNp0Hz2E7pFDecyvcOK7f86sFRZ6qdEHcET z/A+Q6e3M9VJaVTWtBamPY1lJ43FJs1gM5SeQR/xEF5HDQTSEli6iGbJijVLHlSzJCn4KJi95hlS yZtY64+JNJMmW86mEQGxZrqqo2IGOXnDywEUCNDuC1UDbW9oh2kiVcQVhFBzat/0VNEdeD4xPZWR MIZaWBymwe/EuCR4SPXyOVSprl7yDaQeWpArhWh4LDgkpbKMy+nw6lvuH+3bP5psP/CtHYctNcsy bRtzNVoluD8KZ+eqbemNf7sy8s17urd0elcv79jTZtNqYf3Wrsn2hnu3dQztHQj3ppfXO91Bt5Kx G+xuR9BtrBy/ceXz1mQ23jvW2Q3cfQS4+6psH1GB/c4ToBhqf4OkUQ2ShjVI/MKvBX41zKCPeac5 gZ2rhA8jb5j/CazPCUYA5Eg1ryLM6oZ6Py2rnkGyk5EBZy8zlIHTo7JhQQOBhdZMyfec41lJB6Pm S5VRFM6ia6VgLRbB2Xi1bvN9U4lcb29UyTnN4EzKFUafzQ6eZWywvz+26a6J2FPm9Cre1873RLsP d7VPNtrRuwefva2XjTTHd4M+0jToo6xJKQY6ytl34k1BZtmtzxzsuWVLG1fRWZt/ZGyidfMh0Ng1 wDEf9SJRT9x51CWsZmIw97YUxL13HIcsi0Bav5sPZRUuiBAXqeF1KT3S29/18mpdvxcib/K4cYD6 TQ229Spdf03lDJIfVQ3jmC9xUWhK8MbzJTBrAWgpF5cyeTlkSflImcLeOjiZ2vilrfUd+x5ZnRjt rrep5CSnM0Rbx5uvvcnPT7VmVmUTWhy4fIO1szp72M3xh44dvP1HN7QwjoBNb7RxUa8/5j/11MSt k4lQIqg0urGebgC+PCa7iogQGeIu3pttQRpnBmtnBlv2DPYMMlg6MlhYMs8i/P8LpUSupSRmpSRm pSSNTUnMSmGBUhv9vZpM1EnrK3BZtW0AVJ0+ph+WDeHFTBCn7AL0UpCnUuhXroLgmpWkiopEyh31 RuoxBesy4YRI3yNrN989EavddP/6kVt5hcmLZUr1RNcXurMgQSBRHf42vjdqLwrQtcOrhm89uunA s7f19XSRmmIMM9sDsrPpMN99y1aQpa4azK0p4NYjYNUSRJp4iq9INWQb9jRQRqxNRh+GAo3+SuxH VWJuiUkCwb6BLHxyojvxzQSJ4e8TWNvStCR8tCRjwmuNcBQNHI355/dXvnCEvo8mz9LoZRrRtCv1 RmTAdmGDfq+e1KsuuAQBmyrHTEWlfDMhCpuQKRAUVB70l4mVeb7wkeZog8BQBfVI1D77fU/v3lF+ Sy6lVWjkFEkpNA2r9vF7nry6uXXf45t3Prwh+QR1/bVt69oDECpG/YPXraoyO8wKvZ3TGQ1ajd1m bL9h5oYDp2/u6d7/lUnjLQ9VDW1txCtnuPApeYfsOlg5t3zfwmAFFBTPKVktZ9FaOSVz5pSEyYk3 kFVXhGcKL/McxsDC6osNfY7Ixep+3xDTL3j8tTjCSzxf94GoY3XPL0AOzeK45eUef1BCEeuKyCF5 By1TyhVmT9wZTvv0Lyo1KhlneFEJpsnmMypvYhhsam4K9l81EOwMaZWUzGC06mUqjcpWN9q8ScE6 jCHf579RarBN0igpsy9kdLCKqem/WRXXGbRGJ85D1ecfpO6k/oFoJ5YR64mXeTOX7MNa1qeEIff5 GCMa6qvLgleBWZCV9AuOb5/Eb2UVI3DK6wwcGhpx0oZqqk6hwNLDCPw6y+vgJFmncDoVdUka85hP YyZP4q+Y9DFw2WRFmNfAMWyoVlBNA/+iHXvPbN7QRL3f2l/h6/xl08DaX/pGJCg+K4Kz50XTn6g7 h5lrBS8d++ksdDLnEvAvUWww14HHFou4FESicrBnFqsUVRVlrhGW13SD0IqaDYEXSkdKyylOWUWi UT0lvaLuNBpuDrpqp44sa9zs5KwdDb/p2ruiKn3lE/uuemRTJeOv8dWkasPeUHrdzUPxPi9iWDaf 3zpV3Zeybl1b05+yjq0ffd8Xt6luu2Zwa7uTOhD0hiZSy64bq3RbuCpPsIpUk/621S3te8drwvzq tL+9qc5uH6ps2xAJT3UO37AyqVL68x+s2+5rysVWb/M29s9ON2dJpT0Zj5k7utzV7Vi+HwHv/3FY mWuJ649n06hiLhkgCXZZlkDKGsCybPWIkK8A/gq4r2A2NPg9tYj2eirsEOzKTyUHQr32IcF8CkFu CU0UF+PMfMhTWE0UiwC6outoph5XcuKaa6vKVbcf7oaXAkxWXIr77sutOTTktxflmTQMT3eHJsdn 7yr2lK+/g7m2bXduxJby9sKnaFSWIsyEn7j7VDY4EtwTpCySLzfP+zcKx7cXRAliVPAsuY9wEWaR U2bpKrP0rrnIUjOw6aTai7O0eCvVcTuTE/hz/mJCsobSyrI4HmzEyy4WRpBC1L6QAcbKluYE/i2x gLqtiKyi6uaKeAZ+YcSFV/MPoi0w4hBRTdxxbKQW580FZwGOH+LnDhcNO06o4wGE8a7yhJaQPlcG JYvjKmHKYPt4td1O1FbhMVbBGI/FvDkTrKRHZYKWwkjZurqiPyuOFsYqmxc8W+ZHRPOGPerht/T5 kjYVjSiFSiEPWv0pj75o9DAPKhItLRWGLYdWJpRqHcvpcH5MZkr256jvXsoOUQ8Ogx6kiYd5bbYB xWtQDc+hYXCPXhYGVyMtfzV49FrhKCx/Nc+SUYidtRIPLp85AdVwWJJJArNEVBFLQCOL5Vy9bFE9 uAyoBzhb4N0La0Lt20UpKIlBFC2iHFI4BUuFAiGLhTqsNAYczqDNIM/ftlA+0EolZw/Y7AGzSmfI n0G7dRoB5qEUOhX6MK+7VE0+/wW6Rq1TUbCoqrQ2Jn8mH2bNku1A7cAzM8ELWZA9QhZk8TTDnIyg j4+rmV5hxJIALJ71uESy7Zc+mvQUspfBx1lOXOCdHE4BCpnqiBDNRoVQdu8K1HtptlNEn8qyohdK 9s3jsWCc1lMr5gqErIGQMBDMnBrk+9RyjBcsb780eSze9pIk87PoYzCyDJJ/f3AAnG85r+sYaO9N NuWSQ/ay+S+HfTMSBshmigkYbC2FLTX/kcm8nA01S+G3JCyyl0VTalSaKrurMvt7sPZY/UaFpbKr KnOgZFnlnMtqcTOKoXtzTau7q5nk6GBfaOKanHfOxgYzC2zspT3UbeCYUJRKo7x2fMSR6ojVdFcY wfgOFdcgmMFa4iHeIM4gbqTlaOEsXSZ3jYNFj4ZhiquSkJwsy0uij09JCxNelnh1cqDCHsoVWY+9 hrk8FzOP2/+J5cn8l5anEhO/PPwXlqd5jAIGbcCrE44G3wIO4fzDt3hXNo5iHIqzKKJDES2KKFFE gSoENGSRnMPbi+YcsLPuSamRuiyZ4ZufzDhDqjGuespADO+FabLjvaSGgSBEjlJ4jSNEiWWpUopi qvjzl3IV1FvN+//u6j3/bXdDZv/39sOx8Sln+86R3I5uvzO7c6R/Z7cPvbP79B2DnTcevxqOA3A8 nLtlUya9/pbhgVs2ZtLTt2BsIf8Q9SrwBmMLRzC24G9QS1KilqREXbQ+amn0asGJMYuwggAwCOiy iDAsiivkmJHL4gqLwQqLyMjlYYUHpmPdHXyoTFhMZieniA8NjyY3fRHDCnUCrNAb7b6hq311owO9 f80Pbu1jAulgvr1oC+n3QWYoCqTn+or2uHnotqcP9ty8pdUY76rJPzo22brlsBA/A7cek7h1B+8E dnk1CawwCbW2CLEIRi6BY+cKok4Um7LasAtSbVixZqxYGwaxszmc07QlvDRThWNnx0ATjp2ZYbzm Lx47z+NZPSsihUV5sdZfPnZWYTXzmhTxgf5cFLOodvP962O9PX0VuLzQ5GIVl8TP+eNFTqFz8UzQ UIyh2XBL/Koi6/L/UwyiRUAGgmjBOpFPCsjg5uN761HEIAnVXNmIJFwGSeoMWLi4MlAZSxnhAJkL 86rEQMRg9uXM2OoI5l5Y8BMlX7g8AFzM0AhCJCefJOUqpdLqDpnt1fXNwYVmJtzRnHHr/CG3lqYQ tcniYVUqldJUNdQ4+8ylhubWhu6ogVKq1Sq9UD00WrhIvgQjzhEv8drUYHZwZPCmwacHZWWJmz9L CRtBKDowPGVckNAREjnoDd4rZm+EvA0WMSl5g0NkbHOcZ9CfhRS8GrtFWl5wleBlBO6X1T6tJbVV bzaqf8MuZzewe1lKTNL8K87QDFjeE5WxlJ6RkjNTGG4vS87M+dJ/bXKGfKlu+pZl1RM91RY1jZMv ieyqporuWmeUXz4+ykfjKw6tCPU3x80KCrwjtVwVaMilKvi4OcavGB/jo0jfswvm22o3hbxG8D+d PicXbAhH0jFvING+qrV+Y65Sy5kZrcHCsHZGYbFbjMFqV7Q+5gtUtK7Ec+Ev/J68iv47oplYdzxO sMGkxPOkNBdJaS6SkkImJalMYiHUWnXJi8F+t+6itb8Ge98K0Wyfw2JXJ6FX554XoT16cYBhPgxh KcIx5FVKxhevsvZu4d03GjicoflC0VF7F2PHnOHdxj5ryGVSylQyeq07wOhV8vDg/mWkXkQYzhcT 7OdFDCKvnlqvUqtkehse90MY56N+AD7BA7wXPAFNFEtQFEtQFCdmo4KRijKCy4U+OSlqmlfiilfi Chw/FnQTnxwTymQlZfVKMurFsYrKmMxFNTJ7Dhwz2RzYh/WzaK9KIrUo2LcgkdPQOAf7Pabg3Gar m5UPf0lY+hUmMUaxpvqr2w/1KExe0FxOVfIIrh1f1rr9zk1koKids38aWd8VnhwnDxZ7MH8C4DMd Av5UEr86TQQLsJphR9cr5HLCXuQRTzzIIo3TLB1Nc+6vcORK+enCH/hGnNwGr4JFUQbFZCgQg462 AAoFkB+fZv0o5Ec+odeHQj4UNaBr/MiPQS4Va+73+0Br4dV7vApE0Y8RRvwKz4Qf318LF/pjOb/G kdOIBlBIkSVwdfWU4DkkxH8I+w8i33E2KSHUu5dKasqWCKO10SgVuh9CJEXmz9E6R8zjidn1dP4l WoaLP6zuoFFF52nqM1Jt9DutHlZBfY1WqbWKz7+N661ppV5NTWg5FQUxIQmNatah1ZL/rtIqKVKp wdyuhxjjNuB2D/HWaaIPzFMbDK0Jg1/xJtSIj+EqFPGjiA9FvCjiQRE3irpQjEZxCjW3oJZm1JJE rfh/bjCjYUaCD/CRV4O4Mj64A2OQuvGR1+KFBHcbOnLC5zAzs8wIs4e5iaEZnrP0M3W5cK75vkpU id+rxFaTMVr6t1deW0n2QK91SIWZ/Crm5NTz2ew54KTI75RoDwnBSyv5ayKj5SU+U1FFWe5uEZaX ncpuo2X5jyidNebxVti11A9J8mlK54h7vFF4lf9ERkN0YXUFOCX1S5J8gVRxIPZeTkm+RqLzpMro d9jceFoUJsPcpJD3qFSz++emyGBSqDQwQxCpzjpUKpghHRheXJ5nK74ilWo8X3HQjkGYrxRxx2mi BhjDYnwf240qbDFaqpAN5PEkzufZkFWyDZZilwWpsLRW4LgVX9NKoKYgatAgjQ+HF3hWNJqa6ngu qGHdObYUQmSyLIdE+JrAjMXCK8pvImwxFbcOzO0cmMuIGo3FNCiiupTGqNcTNGvo11+jNeaAyx1m kQrZ8h8pkTHqcwdNavrcy7Sa9TrdYY5U5T+p1Bu1MojOFWhr/itwoGRaox6dQk/qjTqakqsV+aNo RI5rxDQmQ34aWw/wAg8Df0LEitOEE8ZajzXfieJOZBOCZxuK6Bv0ZFSFHHhJbnYgexNmnB15c3a1 MacepEeIQSloxdnfhKi0WHn9lDjURmMkApKTLmV9jQKqYzEpyLrr5DW1Dh9Lyg+rGCr/IyUT8ngC JpUMIepjORvwuUKsPH+CYWVakx5laE5NrTPb9DJKadDNVpHnjRoZrBMcjGQ1OLWvUaeIBNFymmBg JBZcqxMRKnZS8H5a1a0iVWEWgpZj9n5DVAhe4MEx+F4LvsI5sDtSiIcLdAWkF80r1RVKaxA+JV+T K/XK2fNmJ5ZHdE/+JsZIq3QqktawWgXuyx9ETyh1Knmv0ckqXP6A3mKxM+ROf5iD13K9hfXpbVYH M/slBQOeFonUhT+jN2TThJmIE/oTsrBzmOkFpr75UlmlFxUpAWALtvL8UIG30rg4BYuU5qDLGTQr 9Sp7zOuNgz7Y4l5vzK5CB4teL3VGy2llci2r/SzjTzg1GmfC70/aNRp7EvhUkX8L7SfeJpyE+vsa q4tgXjknlh0pFKINaDSWvne/XG9l75TpjHYja1Uj+naNLeSwh6yae73pqqT9JYVaKaglMh5x+hi5 nPHhyOPZwkfoHuphIYZ1HiVMM+ShU2pPECJwQz+RPZc9h12S2ktL3NiFw74Hj9EXw2OM+fAYF76m fL5KPL5KXyCJj8nZmF/sgAGDaXcksY34MjzPbhixhrAexYUuZ0/ighYVBcoMj5J4Dg+/DHHcnWpv rcK/V/WlqnrgF9+jBx0nq8g2wkDojxMKzUWawIVsUkbBL14rSE4Vx+anOfhB3wD5kKFPoh5vJOKR sw4CFT7JP0gTBRuhIwwnCIX6fRpjpJfexkITDPt5G8txLPX3DJs/H/R5goGAD57j9vyT6I+yu4gg EeDNFDZxFHauKUENKLNXczuRTQF/xRIlOXhznLW0mamKEqReNOTo9+un1q+VIb3bzjmMWqphRZPL m1lRh1SMy2J1MaRs04v51edfy6/5mZbVyEi5Urbt56+/uW/fG7/8xXZaLgdzw2DO3ABP9C48kZ+o O01wou/BSb4rPp7AT8YJ5VkaIToSnzBRW6qiUhTtZANXnyajkhZYLRx619U02kBpjQ7O4dYh2brp 6WmaZFxWs4tVktsPkvZ9b77+820ypZyUgWL+FD352nn05IsqRg1PJ6fP5UdAGu+itpGPyg4WNc8Z 6WP6QPPOlQsgVQQuFvRYzOStcsbKcTaD3Ko2+a02v0mF8n8zr686Qt1RCjj/qXiWr5nfxzAEDeHP 72Re2QCxkrhC2IGa4tW5/WnPdfY1CsPuGUSdWDYcjxsyM0h+ont4y28NvcU9J0JIXVNtxNMnzmLd 3GYqaztVP+fDi33gmgppLnFVFw40MgmYYLFahCoG2VUUfADt8vDbc7FMmKmYeuCKyZvHE5GVt04F lk+srQQ/VqtgvHaL1wTrd40n2ZXyqtWcBriu9TlM1fx4pmJqx/6u7L4NQ/XgDhm8SW9uc6vTXNVb U59LWQ4Eu7d1xZf18c709g2rw7VdcS7/b2i8cfPURGXD5FBPsH3fRF2kd3Nby6Z1a2vjq9dMxJw9 w8vjIbVORZMKg87etGv7dCxU7dGSSpvd7jGolfpga1WgOW61xNtHNlGks6mtNxHv4fmQuz5ucyZb Z2PpVdkg645bkxs3bazyZbM8dTtIw5UQbfxQ5iPSRD/xyGliADwGq4Ec3jCAEgezaFsWdWVROotC WZSdIbt4k9bl0t5Qj3bWo8F61FyPEvWoHt44uZdAWB2xIyfW3L93Cm5DVGsRBLWfQoxLDmubC9XV ssgMIr5vXN09g8xHZetLO+dAAaZeAZ9h6t8Ej4zDZT7CGd7xkCgLX+mF4apiAbpUxNh+mN71xL7R w+vawgxXNXLtE7vDQ3ylXkGTSKFRaSINw3VTd4zHKUfH8KqaHfetjjxlbVjTGR7oyTr82eksP93u Rv91/GvX52IDu774zemx73z1ru2tKgOn0RmMes7BKPWsfujIt9cZPDZDZuudG5rXd4Z0Vi9381M7 ktWjW3HueAXw9ozMT+Diyz50y2miAYdgLC7wgRNsBupnpJ76Yk+62JMu9ggAFDsHROWEwk6Yohyq Ln6muhjclfcISZrqGdLO200xwR7GhNBROselybEZ0sY7PIagx4Pr2k1C4zF51E3CZ5pweGN2g8Mv XCh14gubzpBdoL2vHMOTPDfppcpTqWbnrJQROSuUDnRi31KN79FZDTftLD50Z/GhO6WH7sSixqqx /6Wub5MlZ+2re2ZLwpIpbRp5RQyU5pWjwoEpwyax9JT+FFf5Anup2aDSpYoea0MD3oZZzGk3UGda 9z1x5Zav7m6ODe7uaV3H+2s2P7Jt071Tlbigp2/PYPR1d9NY/a49zsxE69ZdFYGe7d3Z9W3e2287 cisaWnnrmqqKFdcNt21bNRjw9oyua+i+drIuNbo7Wze9MucLDoyvJ9dXdFfbN41Hu1oz3vSNs9+o Guxo83vbO3OVG3deCXraD7L0glCHnyAu8PYFIHi4CIIncSwUxtKRRGXwNs7pmDCCYMKTZ8LbYU3P kuAMED4RPPFJwuWTUE6fBCPA8T3sHUDEi/9XEF6lxiX+PEEJO5FVuJZIPaImCSEOFraZiAJxVtB4 Qk2ok5VO/IccDWO4/r1Y3o+jBWG2cJAAil6eexCm7D9A0ukyQJSmXkhd9czNNzy5LVG965kjh+D4 jN6ZaB2uHt/ZZvF0bO1vGm8D/4j84sN/Prpx4tsfPf7QR8LxexsfvWa80b787h/suv9nR5pDXdNX 3w7m6ylQ26/JrEQV8Q4fCnlQyI1CLhR0opADhewIBwdWFBd4z+GIqFqo4cDsrkYEZi0Rl9CouMTQ uITLxCWGxqWQK443DOg9NnyRTYNbDSvpERwFvWIlPSrrPysV1gPr4YrHWcQauRmUPRZcEWdmkELc lFmbnT0nYIH45xwurylWIYvKMBf3Tknef7EMGTx1uRjvNoalXBkrIAxfk6t1itl1Cq1GLlfplEj/ Ka6koeQaFaqgtZyNs/k4+QXwwWXdGO1TMA4j52BV1OsPq2mdx8raGK38RxRNI1qhkX92rwqcP+D2 1cDtx0Cm24mHeF28ASU8KO7GGAI/U1yGeGTBUmwRLI/FJ8SqZPJkXRiIyEi8zpwhbyI0InM0GDHQ 4AwY25Tx+TIgfFUn6yzyqjEG3IhYkUMicpoSjQkYkHOlzasCjwRsYB5zcLi/oKxUXrIdCqGA+zGZ yqCardebDQpKbdB+NrEjw7nql6eFolIITmlSprS1rL6yZfqeqSpL3x17zpF1SoNGNoCr0xWMx2Ly WK06pF73wHWbEonh5kAgFlByHrPBwujNoaCtft0NPe2H7n366vMqTkCrt4NNeAD4N4lkp4k1wDIX ZtkaVKMEptRgxa8R+FaD+VYzQ9bz6mVjkWXLbEY0zGOsKgIfiWAIhYfeCE/pnUqmiE4LVzp9QkGX KLJO4PwJARYQqjCxfusl0dRL0q7HE2eEadC34GR/Cy8Eoy1IEF1JhMUVoIVtYS0NM0gDHt9Y5R99 PlkObzzQlDYepC5mmNLeAzDdKdHeS7ZeKGrCCWIuM2fn57boNZRh3OImKxHZLfYsNolmWAEeaD/w nSs79k02G5RySq9T1Y/t6e7c0h1IjF0/fAjmSiHX6FX7Onfkoo70aH3zxqFaNUYdIBYwNo/v4df8 7dqkr31NS9ee5Ul09ep7tzWa3V693uQ2h1y+sC/QPl7bOMkHQD3MRrtBEeBXN8ZyDd5gLCgzOC0G K6s3wjxXrTzY17ZjNKMhFfXLse2vLnxK/bPMRFSAXfqMb8aAWxJFK1EoikIRFHahiBMFBQMVtqGw FUUsKGJGEROKMAimOCRDIRolnEiwVpxorZIWG5xYfIxU0yPW8rx9Ctf6uKqqmJnC57wbPsFg9WOw RDAYhmbwIsLgMIvBO9yjBC3aKhoWgGJpJK/GtZF0dSrqrBImmE74GUbtX6EeF5BP0Lq6i7W1EmKU kNB4vD3unHCc08AFP2h+QWBJNdGcrbKgIPJT/2ziHijuIpy9oGV0EK2pFegXMqOn0gMOO/MAa85/ ncyvRU+ivf5I/g9FCBoxcsZjM3rsVh3FYeRABjHr5z8Jku/PNmON2woa9yWZHizWc7wu2oiiDUIK mhIs1knRYDVKVqlR+KMdePsU3iISA9bHoDeG9SKmH6ndU3tTLVW7+IaxM2SdsItVWktPCHUzxhmc kMZ1aUZbA949rK1s/pMP187LKkdt81Rn6iJWnVQCMecljXl+6hVReUTmYu4uuqFVdIGC87btQyAu FaFRX+o9cnRX666VDQa5sMtVoa7o29HftXe0Kjp6eFXbZMRl87rJNqVBLTNxeXcwV73niT0Z9PgV 39jTzNptei3r4Fgnq7S7Hb7u7QPt67NerSNMGvw+FRjBUCz/sIys3/jFQqEYl5By6qcE5vxm0IGn gfNe4rXTBAu2S8360RDLMNJGs/kb0N6T1smPBVk8IAD7zEzxKoYRIWjhKka6Snhbg3MHBxmsOHIp beAvzqwflTm2rwsOrVlakcvq3IR7wvHtE3CNWcbOoOQxx6imtCFIWJKFWUhIOH8R7p9D+gWItByJ o56mZCp5vkpmsIYcgQhLytGF2QeNRplaryI/1Js1cvp5zu206z97SWtQUXKdUUcPxEJGWFfknAu4 KUUiwE38/3+TwusnYOWoJjqJH/LGeBWqkKG4gNlXRFBEjbqxqfDhYXfDcqIrriTuG2pQpiZXs6OG StSgGrxdTUXo9T5iL0GKYYAYDhzHEtuC1w24tAX7Kxy+/GALamjpbdnWQoVaUMsMmeD1qTAK8x/6 fIqGP1WMgRQrjypWlQWFQjgolOFPSRFhbbkMC1JML0xsNpYXokvbJuf+HgH1hKl69NC39yZGOypN wCyNUhNrW1G38a7JSrL+oQ27Hlwdrd35zatHv7COj7JPBzo3ZDvWtbjsTWs6B+8mz6z83tfuuqJF w3Cc12Fx6GUGzjB44xPrvNUt2+4eW/WVa3rjw1d98eu9R57eVZ0a2VLfsqk7nBT/atrXRUKpy9I7 5KYy+ieRqMFF6Di9tkSfYZL1LkrfvZTkk/I/zpHiysvQrzEp7xVJtbGM/kEk9dhl6NdLdDnSPHg5 0lZqZy4l3YhEf7iU9Pv/75JhwyL0a0zM1GXo15jYGwV6bo64bxjr5tFzi5NpEugD806RLNWL0Pf+ d8jauij90fazItnX2s8WyeFdoiX6/5S2LEoPA73pKPz15AwsoC6J7na+8deRK+D61f97ct/vvt9z 6v+MvDt9ft9z/hOBG4KpYGPwfPCt0JeXaImWaImWaImWaImWaImWaImWaImWaImWaImWaImWaIn+ GhLyyIggVOsIhO6RE4SSWkbQBFf4ANqo0DYTVmgHC+9Du6WwAdorCm9De6DwDEGjRwv/CO3Zwr9A +0LhNYKmxgkDtJOEFtqr4Q4sQRd+C+2WwsvQHii8R7AohnvgWtyeFdqf4E/CHeCcGi/8muDg238H bTPch4Nvx+dbCDXBwbsfETa45/+AtrlwAdot8Gw2uPOHhA3efRHaSfguF3zmArQcfKML7obbQXhy FzEN3+JCZOEtaBn4LhdywN1cyFP4V2hjhbPQfkE4v0vofxRfC88J90TPCVe9gM9hdO8QEfiWe6Dl 4AkjwjNH4KkehHZQOJ8u/IqIwHe9CC3+rgh812+h9cCdI/AtuOcuoee+wptEBJ4/De1kIUtEYVx/ hvYAjDcK3/4raJ+DEUWBVx9C+wLcoRm+/U2iGa56B9pJ+MZB6Hkf2mboGYQ7vAjtAbhqEK76E7T/ CPcchM+/DO0k3GECPr8D2ubCAWi3wHdNwNO+Ai1TeBVaB4x3Ap72NWhjMBcT8Mz4/C6h/z7g5wR6 VOh/AbdwZxLayfxn0F5d+HtijcCZNcCZi9AOwkjXAE/egXaLcH4Avwv3fwPaLxTOQ3u28O/QPlf4 79C+gFuQJTUxDc/5AbTN8ITTcO2H0B7APfD596F9rvB7aF8ovEtMw/d+BLJCg6xugW8/D2208GNo /xdxXwMfVXXtu/ecyXwnDBExUAoTQAwfDRFRuQExYLAICGMslmLVDMkkGcnHMJmEBAkcI2CAPBp9 qJRrW6SWeq3XevVKbWvtBLgJ1VwLGJQStAFBKw0QEWIeL+Xc/1rnzEcAW3rv6++d1bVmf6699n+v tfceQ89ka7+FnKu1QD4IHApBw0Qh5ku/ROnW6Pckh2r0S5bDNfotSa9Gv2JZpdFvZVazrOPy9Zze yC0bOd2k0e9cvs7piEa/9Nms0e+Atmj065+tGv3uZ5sWEoXAJxPy29oKyEXazZAhjF4Ca9+DzNYO iRL2/xLUHhFhlP8YMhUrGMYsSGZrL0DO5TTNIgz7fwnp1l6FHKq9ATlcex3Sq70NWaXtgaxmWQer wrCf0hu5ZSOnm7RfQL7O6QhWNgyb3xFhWJIBuUibBBnSXpAmRMc5yK3aKUi0hGzWzkK2cEmrdlgO QJszkE1aD+RW7UvICKebWbZoH0C2crpNOy7dsP8MZB3kcPQ9DblVOw9JvYZzr+HodRSyVfsCsk3r khnodQjSrb0HOVR7B3K49p+QGVzr1fZA1mkHITdybZN2AjIikiGbhQWyVTggWRtmWg+5SKuBDGm/ g1wthksvRjkM6casvRjlFORw2OmVXnENZB3m7oV+Kt8KC73Y/a6TixmlxYzSYkZpMaO0mFFazCiV QvOHkG5tH+RQbS/kcO0tyDrt15AbuaQJ7Uuhpwfyde0TWQrbXpNVrL+K9Vex/irWX8X6q1h/Nbep 5jbV3Kaa21Rzm2puU4fyLyGbtV7IFuBZh/LzkG3Aqg6YdMj1vJrreTXX82qu53VZz+uynldzPa/m el7NjUDGIRsxu/ch3doxyKEob8TsTkB6OV2n/RFyI6ex70FGgGcj1sUJSevSiNG9kPA9yBBWswmW nILcqn0GGQHaTWxDE2w4CdkKa5tgw2m5FaN/CulmORTtt2L0k5B1WOutGJdKtmofy63Q3CwjaH8M ktpHaH+GHM4yA/ZE2OYI+p6C3MjlTcAhgn3PARkRLshmlq0s27BSEdjvg1ykLYIMaftlM0b5DNIN Dc0Y5TTkcJYZ8MZmjEJpGqUZo1C6ieVWnKzNPEozRrFBtnK6DevSzCg1YxSsIkY5KFswSgekWzsA OVRrhxyuvQ1ZB69ugWYqaYJvtECzBfJ12NOCvrtkK/oehXTD/lb0/RPkcGDSCgsdkF4ur+PyjSzJ P1sZh1a2sJUtbOUVbGULW2FhOeQirRYyhGhto5MX0s3pobCzDaOQzMBqtmGUM5B1XLuRy5uwdm2w k2ojwKSNzkHIVu004s1MNwachIMhC7VHIMPaw8pCrO9BnBxm4YJM1Q5D3sAyW1wDif0TslArhiyB nkXoFVQWwYZDkF5oWwQN7ZAR7TXIZu1NyFZOtwmHsghz+Z4Sov0KMsKyBfpDdIdRVlEUQAbE7bhf fcM0UtD/e4ueQpYK37pSOKfwv59MUcxGWhFZSqqRNie0ScK9ZqaRtiSUW8UFZbGRtolxyj4jbRce 87eMtMO0LdbeKe4zh420S4wzv22kk01bzOeMdIootTbSvZCfSdZeIy2F1TbOSJuE1b7CSCsizf6o kTYntEkSLvv3jbQlodwq6uw/MdI2ca2900jbhdsx0kg7pDfW3inGOyYZaZe41vGAkU6W8xwhI50i bnG+BUuk2W7grKd1nPW0jrOe1nHW0+aENjrOetqSUK7jrKd1nPW0jrOe1nHW0zrOelrHWU/rOOtp Hed/ER4xSWSBpiB1N/86a0hUiEpwEU55j7iDf9VW/21bH0oCSJWLTNTMEKUgj8hDWTFuEGH0opwf n360roYsRMs70K8UbZagLIAWAW7nA5dBVyG3LUeuEmXlXKf3D8ACD9iHdgFoqEVuOVJhjOXh39Jd gnQp2nrY5ir0LuTf6i1mLRWG1jBalBljUgsP5ljBY/r5N3lpLnfxXItQ4uPfig3xLDz86eNZ0rj6 PApQM4E1l3FJKWv0ASO9PDpKGfSUMmJBw8pylJTxqLpOmmc4wQIaMchzif6WsI62bjuNVAEEPPwr usWMQoB/N5d+jzjMOZpxOLYeOmb6KB62vdyYVwVju4Rbxi1OnBGhVsP99FkvRT6T/SFxNW9gbWWs oZZxqDJWPhFvWjF9/n62n+avr0uIvYE+9RFprT3QEYzNRrex2GhTidwKQ3sYs9BXqDq2Sj72ER9K y/rNK+rNBbDEx+MXGONnsscW81pRzeUxkH3ZrLNjUXOzuM/wooDhbzdD4y2ovbLX+w3/1WfjM+wv 5lrdHr+BGNlYyJ5LVi3lNYv2uXJt0d8VwXFv0ddmIXIBtoHGv5e9PdxvHScaFlQkzKDAiLswz9LP vjwPJQUig9d4LNoUsv5vslV63zAoCBQngpYzZXKM97c8k7WXoU0YvkX2F/MMgtBQi1JawSKeC0VO f63R8iL+Re8Q+29U33fYZt1ra9nbKtnCMMdVJe8Dem8Pz4Fi0s8eFeAxdISWcN8oerOA3zzsiHrf UEKNHs+FjEk8Rpcbv4Rd8hXj6nlqWwAvqmIMC2M+X8j1QfbY2gQ/D/JMyw1P13X5WVLkXjpvqtd3 iAz0GsveWYZ5+WMxe7lV5ZdpvnqM4tqju7TH2Gd17ynot99dPve4v/a3a2oCAjQTfS76rh/1+lDs BCnkPbSc91LfV85Ux9nXD1O/4f2XxgChSp5XxT0LeT+i2fhjeqhlKe9pf22F/l/FRTwmJrI1FAP6 SZTJaxUUNf/imZSVNcVzd6AgVFFZURT23FERClaEfOFARXmmZ0ZpqScvUFwSrvTk+Sv9oWp/YeYd vtLAklDAE6j0+DxlFYX+ULmn0lde6UF9oMhT5CsLlNZ6lgfCJZ7KqiXhUr8nVFFVXhgoL670VKBp 2F+GnuWFnoKKULk/VJnpuSvsKfL7wlUhf6Un5PeVegJhjFFQOcFTWeaDBQW+INLUpayqNBwIQmV5 VZk/hJaV/jArqPQEQxWwm8yG9tLSiuWeEhjuCZQFfQVhT6DcE6Z5wDJ08ZQGyjFWRZFnSaCYFesD hf01YXQOLPVneoxp3lDpKfOV13oKqjB53e5wCcb3L/eEfJhLKIBpo6OvzFMVpGGgsRgllYEVaB6u wISqaUo+z3JfqEwfi2AuKPGFYJg/lJnnL64q9YViK5AdHTqblubm+wARJuW5OfOWSQnQ+4EvhvFB f3GA7PDDsJCv0F/mCy31VFBNQrboygvMsGA2C8sDYfS/N+wL63OcCAUVPEAB1i4cCvgrM+dVFWT4 Ksd6Cv2eb4YqUBsOB7MnTly+fHlmWVR5ZkFF2cRwbbCiOOQLltROLAgXVZSHK42mlC7yYQJLqd13 KqoAba2nqtIPIzAlqvb4sJL+UFkgTAYtqWXzZi2cNwO1Ic5gnQur9BVdXhIoKEnoi89AeUFpVSFh UeEpDFQGSzEAYR4MBdCgAK385eFMT3TsinI4REZgrMdftoQ6xVWVRxtf0SJuTi4N+CsBT4Hud7HR GVdD11Q2ICOAUeD6BH2IAqSwYnl5aYUvcVDY7NMtBfCxFaioCgerwoC9OlDgpzYl/tLgJRO6mrXg lZhY6C/yIYgyfZXBmtj3QXpX0TpxpUeiBb5RiGuEVdPEAHx30b9FCXwbF3KY/t/t/8pjVs67XBJt TLlX2z45mdor+VfbfsAAam9eebXt3W5qn7TlatsPHEjtLf9+te2vuQbt8SnoW6WZ29O36hksB4pk kSqGijTcl4eJyWIMym8Q8/Ft4X7s0SXY8atErqjHLeJ7Yq54Vnwb38sWi53iQbEbO/g+tPgQu/dJ aRKaHCAd0i2vk0PlSDlcTpQZMlt65TflYvkt+YD0yYAsp/+SJyvkBlkln5HVcjty/yrXyzfkRvkf slEekE3yQ7lV/km+Ls/JiNRks8khW0xfk62mMbLNdJMyxzRdWWiaq3zbdK+yyPSgEjIVKitMDyur TEFltWm18oxpk7LF9LTSZfqxcsr0inLa9BvljOltpdv0gfK56bhy1vS58oXponJOcSrnlTSs6/X9 sVHG/jeweQbYPA9s/g3YvAVs3gE2h9DiBLCh/w5sBTapwMYDbMYDm38CNrnAJg/YPARsyoDNCmCz Htg8A2x+AmxeATa/pv+WCGzeAzadwObPwKZHvm5SZMSUAmyGAJtxwOZmYDMT2NwNbO4HNgXAphzY hIHNCmCjApsmYLMN2LwAbHYCm93AZh+w+RDYnAQ2XypnFbPyhTIQ2AwHNuOBxZT+2Fh8CdhcB2yu BzY3AZsZwGYBsHkA2CwFNrXA5nFg8xSweQnY/ArY7AU27wOb48DmrCiBurBMATbXA5sbgU0OsJkH bO4HNsXAphrYrAU2m4HNdmDzGrDZBWz2o+Y4sOkGNn1yo8kpG01DZRP8Y6tpErDJATbzgM0iYLMU 2CwHNuuAzZPA5jlg8yKw2QlsfgNsdgOb3wGbDmBzCtj0KF1KknJKuUY5raQrZ5SJSrdym/K5MhfY fAfYFAObKmDzGLB5oj829rMJ2AwBNhnA5lZgcyewWUh/twI2dO+pBzZPAJttwOaXwGYvsDkKbLqB jSYKZQqw+TqwmQBsZgGbe4CND9iUAZs6YLMe2Hwf2LwAbN4ANi3A5gNg8ymw+VJWI17qTIPletNI YHMjsMkBNvOAzSJgUwRsQsBmFbB5Atj8ANi8BGzeADZ7gc1+YPMhsDkObE4Cm25ltaIozyiDlS3K CGCTDWzuAjaLgE0xsKkGNmuBzWZg82Ng8yqwaQY2+/pjk7wrAZuvAZvxwGYq/eUR2NwPbJYCm3XA 5jlg82/AphnYHEEt/d0tVSyWI8WDchKwmQls8oBNGbBpADZPAZsdwOY1YEN/2dgPbI4Bm7PyAcRI wJQqS02jZQXio8p0J7C5H9iUAJsqYLMW2DwFbLYDm58Dm7eAzTvA5hCwOQVsLsg2xaHMUa5TFioZ yreVGzHr6UpImaWsgD+sUu4BNn5gUwts6oHNj4DNz4HNb4HN74HNH4HNGWCjKV+YByjnzCOU8+aJ 2Hpv749NqkzA5uvAJhPYzAU2JcCmFthsADY/BTZ7gM1BYPOJmCUVMVd6gM1twGY+sFkKbFYCm/8F bF6kvzgBm4PA5lNgc17S++UyTNdKr+kGudg0BdjMATbfBTbLgM1jwOYpYPMSsPkVsNkLbP4AbE4C m165VbHI15XBMqKMls3KVNmi5MlWJR/Y1AGbjcDmB8Dmp8DmdWDzJrDZBWwQU8pHwOYLYPMXpcs8 TDll/oZy2jxdOWNeoHSb85XPzXXKWfMmYPMjYPMKsIHfmA/QeW6z4n9ud0ZG7sr6eluStFk7m5q6 GxoauiljCTaoeBqCNou02bob1uBBjRk13aqK/6n9Mio3m5Krqs+uyZ3CGXToo142KW1m1XhsirCZ PfoTsdmkzbF790/wfP/73GfPnuef37y5sZEzNWv4qWFz2DBSQIZypqmhgS3Ib1JzPO6mfFuSsFl6 Dd1RC3QFTmFzrvGs8czJmZNzD8ijelRLkrRYu201DQ08gBXzaCC1FrO0JAXJ1iCX26gJGnH7YEOv qtbYzJhEVk53Dj1oZLHUNDXlq0EdOWh6ZS910Scu9Ik7FM2meERs6mS5qjZti2zb1tQPIYtNWhw7 f7ceDw+p6zJGx0NWWay6rQyHxaobaLNZFGkxd+paMAtLUI1kuTutZmE168ZmsRpqvaXEkiQsSQ0N Xq/HY7ELi71BbVAXYgcdCdLrUONtsMWb5eTQAEmdSKidCTYLVTEJqaDUIqVFUek+pEo8iooIMps7 pUVolj6HCT3QiJ+cHM5Sgh5VVRRpS9q2bZvNioXLmj07K6+xMcRLyrPmeSOTv43x6zVqbDa3JyeW CdpsRrOsLK+3qdft1n2CfDVaMyWH11nP9NrcbppXdJxgrCbIiLo7/0qQwMOs5PCqajj8PyhI7NLm bFab1e2gzSBaqP7BAsjsU3Lr8UBrLD7+B8Hi+ivBYk+SdquaGC0WPVq4whYLF6rIb+qmCrOwI1yu FC9RZV8RMOZ4wNjN0o6AMSLGLqU9Btf/KGQo2l+JXBIyHOA5V44Zy1+JGUs8ZixXiJlEq68yaJwm dIkGDYKF89Go0cPGTmFjt0q7ncJmyZMcN1j3eNwgE48bronGjZ4x4gaZeNwgE48b8vRY3FBNLG70 cYKxmmjc2O3CbreJQSACZ4ZYzctqt0i7jfT0wtV6yWjbtJk8tZnTeAq9a8iN61FHntGr6oETz/Wy FmpJ/TbV1xv9qNNFEv09g1wvyW08nXaHtLsieJ7LeS7nSaZGkN0m7Y7m5557Yv36tWsf49y0mY/S A+VkMBsbM59zDYh1NoqOScbPbhV268XoWDGjOCjtTmlPppjaYETVjSpFlTVJWgn/GriWwyIdNgzx xh6o3/MGVelHcEOQq8xmc7gRVY1hq0Va6WzsU9WVDrNwJMVCKwctrdaVtBgqGtT00wl7GRojvFSX otnj8YUIcyRJB8ViA4VYU4NDSkccSNVql1bXa6KNtx+d2BBDd9SoNfqwRvmeNyiQKWvYjllYzdJq RJxKado98mlxaKmiM8lifawOEyaYKJwQT1aHsDpzc3JzxqlEA3GZ06tR6fU2OBKawj9Zf7ebgq/b IU2OpFjwqWaTMJkphKxSWjFPCj/VJKUJaalIc1KntIqL1ovJinQkeRIi0MMllNAfVJnN0mFpwuOw SYdjSm4uTq8Na9bVGg5ixCHnjDj09Bp1NoqknHhOdyW4mTUtI2P27IY+my3q+4hFm6EFwahHI7fs M5MWBGRsvGCsTo9HBKTDLhwIyHhIrkZQ8j5rlQ47+zSFXh9NwT59hj7bGdN5Rn31HA2PopY8qi8a h33sMrGwVLkx9/3eo48afamfxr0vcSh2XXcsNh1O6UiO5EfysZlte8LzBEJlg4dChrVQdOrh6bBL h3O6YXv0mSGmCzaN5qGHamxaiNU1a+rZUoqnfDeh6LAKhy0WrO6YpXrQky0pazzRQzAhYHUvN6+E Vzot0knBlRixViNiuc585ZB1moWTQjYWs1bUraK4UXHFWNlf7d8MWmeSdFLQRqPWKaUzAeR/UNjS VGt43+v+R4etU5qc0bC9yri1iYs2LUWRzoS4pXjlonjgGpHr5Mh12qXTOQVf+3LFbJEl7hHrxVpR D65R2bGM7yIEU5LJYfPE4tioNZv5SO2LZWuAmbEDp8VCmbMrYX1C7bQcY631bCyYc2Lj1qyJ1dYY y2HrdjqE00H/OpkoHZSjrlahKkfNcVql03B9DmmnDfnhPh2KHN9wyjt61+lBXb+ul12OgtqI6nie hcrYjBD5ao7ACojv6XrUfHWE4Kq4t2kJnnepJ7Lfu+MB70yWzgGRtEjatoxtGU2zm2bTJrnWttZW b2OtEXUbqAnUoK4B1YMe1W0ZJgr6bQAzkB8mjGnz7YEHjOb1HaCep1WzBqZn2Qh9p1U4E/YA9yVz Sdxb2NZ6WDbLrVMGGb3NnePOMb6pYkvAwris0mXXg5cO/j1v9PuSwLUmPNl3Uu2d2cbXAdoWUJsk XElT4vsCLaMtvjHUr7xEeX29vqHGcEhWNEfi3uCJuCzSZUvYHNa4pHQlrolqc0pbyi8jLZ41CcTf J6KD9Pty4YzX8B7B+ehsMDH+imFsEqpxH6QdFxsu9l9LTk6vPrUprFUfADDgO5YN6nMzMnDzTPz6 Ed0rWBXfp7FZOBObI1CiN1KEjNrrkiaXJTa9xP3CJk22JFW/ZydsGEnRDWOAIl20YUR3DKQ8XMap 6I7BW4bLSluGyyFdLn3LyBUZ2DS88FTaNO4Q0yLsfDpsUeSc9ixvk+FrFzlfswaYmWnfiOexcZhM cE6KWdegQaNzc9do2Cy4Xt85TFxPeX3riOu/aDJHd4/Y+Lm6iNtDC2XudTmFy5kiUsTXmG5Ub1Tz I6tx/tIR7LJJl6OvpaVlT1/L7t27W/pcdhSMEEE1X0QSKB8lIwTjcFHsxlfUSMLTrO5WLwp22ouU 7+PSi/GCi3o77j5CDebouluN7vmRYGSEypVxnVriABGXCWvdrwAhZEmLPVuCrhTpcncO6xzWPW3f hEOlh0r3zmtr29PY2rjbtdvFujsj3ZF9kUOgNlALaFdkd6Q54nJKV/IIscxAJEr5kWURzFjHh6HR ByZ8+kSL2M3UIiit55pVnvG0okiks2ZYisXSVuOyCZddi9uZdsks449PvV24BkjXwGZLs2X3uoLG gsaitqK2Ww5NXjStJi0rLYu/ZqxssVhWtbS8W51sk8kO6nfkk930fHJE/4ZVxMqKpnG9gmdqMdcX T6UvO7CtpQWLsWRaskUmW6bl5+f35huPi+pXwxNaVkZWoceqS4fYvTvZJJPNkYgQMavdZi05KStL iKz405lslcl2qm1pO9TdfaitrcXomPDYXdI+4Ejnp1kt/Yi/kcXG07+fFXG6aJoroe6TI7QUVBCb H+bKl+JDndEh6BtczR5aC1djDd2eLPHpTmHdxjgAh77D0n95KRBEt4CGgewp+B85UEFa8ZbCLZNf mdadlp+Wj8u13ba7qGha2rSiot2uK/dNA2UJNqLPlZaWBYfqSzaZkhPcGDgmKdKUBHsiKo4LexKB KwhfOjuQk2aZZOmWdnHRrqluM9YsixpHAyc/P4sLOWU8VJ+E1bW10ZPslMnJ04VuWpGYJqZESuH5 FMEFkWl6+BsIR0F2OabUHIr6q8YFK1uArsXiwiziBZZpFpS2rOSISBHDxWDMfAwGuRPxoKkWQcSt VxHiK43WVDCc0WiJj6hBu8UFmNKysmI2FbFhRgtOF9xOVvTqf6F1iO2mRUIpqA2VikHFIf9SkV3q C5eLeaiR9+bN9GABhKbx3wEsIhnfhfScFFZshtdyuV5iwnelATB/sFDu8npni9F5C+72iKxv5c31 4Eagt6G/kbvFdZxTMMLAmHZcdnAvG2LksC+Ja8RQ8bWCYGVQPM/yRZavsNzJ8k2Wu5b6Q+ViL8t3 WbazPMyyk+UnLLvo33iIsySlheVQlpksZ7K8j+XDZUvLlspVLNex3MTyaZY/ZLmD5cuxv3T/LSmv UtqApAIMLEAYIQJc/v+VmbAOyX/3J7kx/RtR+leE9eJJsV28KnaJA+IY/c1Z2HmmNmO2XYL+fbaC foMQ7pL+ziKz9c+GdfrnD3oT+sDfTm/vl5euvv75lDH98wNT++ev2do/f/3F/vmMS+rHDe2fn4wN yZSYP5dQbxHym9P65+dtwKcDPp0hvPRv2tGnHlBlmbxitel50wdim/ID5Qei3Rw2PycOJr1naZCK 416HT/7S8Ti+FOx1uV2zTHe47nf90FSbXJj8sOk3yauTG017UkwpNtOBlC9TvjT9QUi1h7CxvJ+8 84q0D3Q4+XgCnTRo3xXoXMrIGGWAskG5oIeZtlxKyftStqf8u/tpg7Yl0ItEdCW9AjkGemO0YeDm GPXolDrsCpQJmjxoawI9rxPXXEKDXh20N0bvXtsJ+oRosPlKlJo5OHVwxnUbEmgz064r0r7rLkQp bVDa0BjlGjTniuRlus/47E+qIaldC1N7jPTeH6V1Dxk3pHDID4e8QHSp9iEvX4l07UPeGHLMoHNx olGGXOCxVOKvzxuVHaN5o/JiVGjQwyB11MP008ajc67PvD531MOQmdfvGrP3hveZzmUsBgXHjgFN GHtsbC/42NiL4/aO/yHR2GPj3xx/cvzJCeYJKRMGTfgVqD1zOsibuXjiswa9daN605ib/jT5yVsm g6bfmnbr4ltrprxq0JtTWqa0Z48DTcleN/XIbRamptt2MfVNv2X6SwbtvK0P+Zemd3Ou+3bT7abp L90+IWdTzpszMmctAn30zZLbmvTW+OzWW901ndrdNW/OyDlZc6bPeWHuGCbv3IeZauaum/ssZM3c t0Gd81bMU+d9dHcQ9PT8fLTyzn93/rtz34Y8QinQsfld8y8sUJl2LGhj+mhBF/ijBT1e84Ie1Hd5 F3uPeI/dEwY9medBux0LevSavBULevKO551e6L2vZdGiB1IfGPbAmGJz8eLiQ8UXop8lE0CvlrvL RwZrgvXBSPBYsCvYs8y8bNKy3GVFy4LLVixrWPb0speW7Vy2Z9mBUDD0ZOiF0NlKUZlaObtySeWb le+HJ4eXhJ+tuq+qoeqtqnPVluoJ1XdWv1T9yfLc5RdqhtXcWZNfE6p5tublmkO1I2u/W7uz9lDt hRWuFYNXTFkxc0Xhih0rDj0y7pHcRx58ZMsjLz5y5JGelTkrV6x8s85Sl1MXqnulrqWub9XQVSWr dqzqWp29umb1y6r3K/aqnZfuR/13G7U6TrSP8H/3MEjfQb4i9uZcGnH940T39CvuOtGdJ4H67x1q S5xod1Db46TvC7SHul9Ma7luM/bhw9O7sWvyHsyf2G8HerG/bknZ7n46eV9sz0TbgT2jCqlv8s6U LfG9U0cJu3Mu7796q5Ep26PoUSntxdz2MNVzewNB6N2ZfBw7+Xb0OMza9sG6p/F5mCl+Opy85FTI TTgH4ifBdrL7st3/xct2f4ex52/g/Z53edaD3im5SG+J7oRYjxeM9cLepO8/+v5mrCP2ROyAtGqF sd0xuqLY49LmqMeoR3yNR+Wpx9Rj0EatzqHOO+TYqLzLfQL7YHvCjnqFfTZxX718TzV27hb2Jn0X nRfdP2lfRwlGVbuGvICSvDTvLZPnvzvYrJ9j/Ikz67oL13bCq1Kjp0/0VEkdNtgcP4F0r6SzjVub qQX67hqcSjVUQq2oPHVY8r6op6YNTR2GEzCV+lNaL42fo4knKdnCp6ZxbiacnKnQcOk5ubnf6bjP OBkHRa1H/QV9dBp/rvfazrRc2NMPfUKNMMZKJURsFGM9EglN3VNGFQLvObSahESad9BWXu8XaG0S ojp7yMuYa/SEbde1ql1pqtqlE41An6PyaFUopXsafapd12eOnqSzfsKNnsSnUgLRCaefbnw+/jeJ z9QEurwFn7QJZJy4Mbq8B520fx/xWXzVFDuxv4IuRYoodo5/BfHJftXEt42rpEvR4TtKAl2OH99d Eoj8Xl/pv48u1/y3rbs60nGmu0vK9tssc0be1pd8mG49TE1cYqGbDuea5oykO5BRB8INagrdmvRS 2vspRcS3o0V8s6I7VPf0br4f4XaE1K7bmvh2osZuMUQ7FqjzjyxQ6QbDuR3GPUdP78At6BiV0I2G +s03iG88Yb4boS3X7iA55GW03kG3KewWY+Yf4XtXjUFeLhlDty7OeecfoX3JqAPh5paFuxrd0Kjf Ok6B+J4W5Psc2vJNLXZfm+u93cSI9BEW94R1JG6z8HxgsW7p3LdZN420jnWx3v6RePmKJvrBDe/r OWGhd/Eod2tv0nt46C089A4e5S1xq6D3dezjd9ZQqovfMiL5bTomemsOvzPHKX6m9Yk9Wp/MF9dI n8iTS8QQWSDSZaEYKJfyu3km09tplFLtt0LyW2nMaOtC24Fo60JbB+s7wW+jscsHxTDUj0L9QtR/ HfWjoOt66EpH73+GPR/ROxa0V2HvQGUl7KjTfgF7s5WPtWeU4yJLOSEmKZ+K8cpn2n7lJL7tkvZ9 /O4aM71tht41A2s289tmasQAMUe4wdlirJgKLtT2Cz+4CFypfSrC2jlRBa4GLwfXgGuFS6zQDohH wCvBdeBV4MfQfw14LXgd+HFwA3g9eAN4I7gR/EsxU/wK3Iv0RbAmxkoBlmCvmCrvAeeB7wV/CxwQ C2SLGIEZB5T7xDTlfmFTHgKXigZ664jyqPAoj4nh5h9pB8zbwM+BD4ix5vfA7eCD4PfBH4APgf8A PgzuAB8BfyjGJrm1/Umd2oGkPwtXUhfSp8Dd2gFLkphjGYvPm8RYyy34LNX2W8rA5eAKcJX2qaUa DGwswMYCbCwrwMDG8nMx1fIK+BfgL8VU6zgxwjoe/JAYa80HLwEvA4fAtWAV/CgYGFmbwE+AfwR+ Tsy0/gyfp8Cnwd3gz8FnwV+CgaGtAFwI9oOrxAi7EFPtg8QI9t1P+I1AlPqM3/VzLbz2NXjta/C2 MfC2GfC2enjbvfC2JfC2u+BtOfReHnr7jnKftonev0Nv34HfPEXv31He0nYoH8PPTghF+QQ++Jm4 n/3sOL+FZ2AsKh4UExP0z4b+auifBf23ovVi6N4M3b9Ar5ug+2no/mfoexP67hMp0HIGWs5Aixta boCWcmiZCC0ToWU8tNB7nj6it+5AE70faBK9dYdn+jukfi7SoOO30PFb6MiQD2m/gp6J0PMQ9EyG nnuh53YZ0H4PXRPlFu0N9Pw19JmhrxqWFUHnNbDsMWjbqBzTzsG6t5U/IVo/E99QThoROxBax0Fr AFpvhdZZ0DoaGjOg7T16hwci727McqFwGjvMX7CT0M7yffGY1iXWgNeC14EfBzeA14M3gOldV43g t7Ve8Q64Dfyf4HfBvwfvA+8HHwC/B24HHwQfAn+oaeIj8B/BneCj4GPgj7V3xHHwCfBZrUN8gTg/ Bz4P7gF/Ce7F7vZ/UH8B/H/BfeC/gC/CFk3rkgIseVf8WFkMD/uudkZ5EJ/52hnzAa3L/B64HXwQ /D74A/Ah8B/Ah8Ed4CPgD8F/0nrNn4FPgv8M7gKfAp8GnwF3gz8HnwV/AT4Hhi3mi2BNeycpVXvH mqP1WmeB54Dngudrn1q/hc+F4MWovx/8IPghrcuaD14CXoq6ZfgMgcNILwfXgGuRX4lPFZ+Pgtch /TgY62D9Hj6b8PkE+H8jvRn8FPhp8DPQ/yOUb0f6eaR/hvTPkf41GGtkxRpZsUZWrJG1Q9OsR8BY IyvWyIo1snaiz1HwMTDWyPqZ1mE9Cf4z5tIFPqXts54Gn0FdN3R/Dj4LPoc81s7ag88vkcca2QrA hWA/1sskNolBfHIpYhN8dyF8mE6vJOT+Fbk5yN0FL9+j/F6MFxKlPSIXntkBz+yAZ3bAMzvgmR3w zA54Zgc8swOe2QHP7EDrT+FpvfC0XnhaLzytF57WC0/rhRd1wWN64DE98JgeeEwPxqO3/HQoD4gk xQdeAg8q0D6G13TAazrgNR3wmg54TQe8pgNe0wGv6YDXdMBrOuA1HfCaDqxkD1ayByvZg1XswCp2 YOV6sGodWLUOrFYPVqoHK9WBVenAanQA9V6g3gvUe4F6L1DvBapdQLULiPYA0R4g2gMUO4BiD1Ds AIodQLGDI/awsALLGYhkG87e3+DsfV3Zh7N2P04hnDaM70nMcD9meJTxXYkcvV9vGPCth4YPxCKc k+k4J9NxTqbjnEzHOZmOczId52Q6zsl0nJPpOCfTMdItOCtH46wcjZhtR8y2I2bbEbNHEbPnEbPn EbPnEbPnEbPncZ6mImZPIGZPIGZPIGZPIGax3mIuzs3JiNOjiNM/Ik6PIk7/qCwRY5QCcKlYg3N0 BM7REThHv4azMx1nZzrOznScnek4O9Nxdqbj7EzH2ZmOszMdZ2c6zs50nJ3piMUTiMUTiMUTiMV2 xN55xFw7Yq4dMXcCZ1w6zrh0nG/pON/Sca6lI1ZO4GxLx9k2GrFyAudbOvy/Hf7fDv9vh/+3w/+P wv+Pwv/Pw//P4/xLxfmXCv8/AZ9vh8+fh8+fwBmYjvMvHedfOs6/dPJ37SywPov72SZtLVZgNvbz o9jPq7ASs7ESP0FtI7x9lnIAN6l27aJyUCzh1etA68NodQgn5iZtFXJL0PcA+r6H0hz03YS+reg7 B33b0e87wmLE0bfR8iBatqPlHL5fkc/8lDX5UX876t9F/fuonwpN61H7CjTNhKa3oSmL2/+B74kf sewRDjlAjJCLwaXgMnAFOAheBg6Bw+ANOOkH0rva6L1s9FY2eicb3422ieuUX/8Xb/ceH3dd53v8 l5k0SZMJl1JaoCCUS7nIRe5yEUW0gkoRXVnEFbO7ggYRWbCAuoXWIKwClotAESq4VGjRtkosiNhQ oKVtSkp6yaVpadKmQ5LpJE3SzGSagt99zmzkoOecxzn/nPPHy7n+5vf5vN+fz+f7/Q3pGJ0Zf5X/ 26OjrNpfskscZ+U+xC7xqHi3ydAjgpTndkZnWs9vCq86YoI95ZH5Nd3x10eXWMGuUvNfjS6JX13Y fV0S7SOySSKbJLJJIpskskkimySySSKbJLJJIpvkyPGOvMGR4x15Q+HISkdWOrLSkZWOrHRkpSMr HVnpyEpHVjpyiiNPdeQUR55aODLhyIQjE45MODLhyIQjE45MODLhyMTokWeMHnmGTL4aneDeCQWN awt7hOH8L7blfzcJl+OL+BL+ISq3dyu3dyu3dyu3dysfm//vtMX5X13L/4LY6E5jecGjbdHGouPC 9qLjcQI+jBNxEk7GKfgITsVpOB1n4EychbPxUZyDc3EezsfHcAE+jk/gQnwSF+FT+DSm4jO4GJfg s/gcPo9LMQ2X4Rd4HE/gl3gST+FX+E88jXn4NZ7Bs5iPBXgOv8FvsRCLsBi/w+/xPGrxByyxW1vm 9tXQVvQaXsdyrMAbnl8ZmopWYTXqsQb5X39rwFq8ZQdxlauVq0Nj8Qo7iTewEquwGvVYgzfREJqK 1+Kt0DRm/7B9zHgciAmYiINwcNheMhuPgQYlvwzvlDwTdpU8i/lYgOfwB8+/7tZus2SF+42hqWSD 97e6nw3bSw/Dh3A4jsDksKv0SByFo3EMpoSm0mNxXGgrPR5qoVQtlPK99DSPT/faeeGd0vPdfjHs KouF7WVxFGMMSlCKMoxFOSqQQCX2wb7YD/ItG4cDIO8yeZfJu0zeZfIuk3fZIZiEQyH+MvGXib9M /GWTcSSOwtE4BlPEdFp4p+x0nBOays7FeZ77BKbiM/i69/2L22u99k3v+xaqcR2me20GbscdmInZ nn/a+5/1/vmhrWyBx89h0HOZsH1sEeQ69oDQNFYeYw8M74w9Qg39sPALg9Qpok4RdYqoU0SdIuoU OaKIOkXUKaJM4XcI98c4HIDxOBATMBEH4WDkf6kw/zuFh+MITMaROApH4xhMwbH5X7h0lX08TsCH cSJOwsk4BR/BqTgNp+MMnImzcDY+inNwLs7D+fgYLsDH8QlciE/iInwKn8ZUfAYX4xJ8Fp/D56P8 /91xRdE0XIb8byxeji/iS/gHfFncV+AfcSW+gvzvI96OOzATs/Aj1OBO/Bh34W78B/K/15j/tcYH 8CAews/xMB7Bo8j/fuHjeAK/xJN4Cr/Cf+JpzMOv8QysgEXzsQDP4Tf4LRZiEczaIrO26Pd4HrX4 Q/63IvO/24jX8DqWY0X+VxOxCqtRjzX4+yny5fDP+d+StA7sa/Kfbx3Y1/Q/P//LksUmXrGJV2zi FZt4xSZesYlXbOIVm3jFJl6xiVds4hWbeMWLXKMsxu/wezyPWvwBS/DH0Fv8Ev6El/FnLEUdXsEy vIrX8DqWoyFKFK/FW1FizP5R+ZjxUcWYAzEBE3EQDo4qSu4NvSX3hXTJbPcfcX9O6Cp5zJrEg8I0 e8prcin5tdfEXCLmEjGXmNIli8OOkt/hea/VIj/lXvD+Fz33ktf/hJc9/jPEWSLOwvRb6XG919a4 fdNzDViLt9AYJUo2OLdruxLXdiXNnmsJw4VJ2SY213MlXY51zVKSdt/uusTuumQXXLOUuGYpcc1S shtDyCArt+Gwo3Sf0Fu6L/bD/jgoDJcejEMwCYfisKi89EM4HEdgSpQoPRbH4Xic6rnT3J4Oq2yp 1fW/p26UKItFFWVxFGMMSpD/i+oyjEU5KpBAJfbBvtgP+2McDsD4qLzsQEzARByEg3EIJuFQiLNM nGXiLBNn2WQciaNwNI7BsaG37MOu0U7ESTjZYzuFslPd/+skPsP9s3A2Popz5HEuPu/+pXCdW3aZ 474Qlpddji/iK2G47OvivNb7/n5Ku94tc71bditmiOF23IGZ3v8T59b/han9iNs5Pvcx/AKP41mf Nx9/neK/8RwPyzKO3RuGx0Zhx9ii/L/ZCemx9Bxb7nZ/zx8QJQqT3Qo1dqLnDsLBMI/HHpr/XjLf 6aP7qhn5X2Ut7NFee//5G/K/hlr4HiW/3+qLxsQuDv8UvzS8bndanv9uy2u90Ymxj4RU7AycjY/j 4rAudklYE/scLrUr/3LYanexxe5iS/mVYU35Vbg7pMr/Az/BT3EP7sV9cC1XPhv34wE8iIfwczyM R/Ao5uAx/AKP4wnMxS/xJJ7Cr/CfeBrzQirx4ZCK4iLNxq50TXyTa+jzxJ8RfyZ2bkiKPxO7yO1P wrbYT127fDU6yfw6yTvXlH8pJMv/AVfgn/CvYVv5dbgeN+BGfA93h4zcMnLLyC0jt4zcMnLLyC0j t4zcMnLLyC0jt4zcMnLLyC0jt4zcMnLLyC0jt4zcMnLLyC0jt4zcMnLLyC0jt4zcMhWfDdsqPofP 41JMw2X4Ai4P2+Se4eHZoYVDb8YKPoZVhW8OD5f7fHnPj301LIp9A9/BT8IyGuR/FbhN7vPlPl/u 8+U+X+7L5L5M7svkvkzuy+S+rPy2sKj8+/ghZuHHYZG4lolrmbiWiWuZuJaJa5m4lolrWXQhB6o5 UC22Tg5Ui29YBQ2poCFxtoukVSSt8S//ZSh+5V8yVpdKzpxidankzimj1/jLVdeQ6hoSXavoWkXX KrpW0bWKrpUz1Zyp5kw1Z6o5U82Zas5Uc6aaM9WcqeZMNWeqOVPNmWrOVHOmmjPVnKnmTDVnqjlT zZlqzlRzppoz1Zyp5kw1Z6o5U82Zagq0UqCVAq0UaKVAKwVaKdBKgVbOVEcXUaGKClW8WE2FKn6s jl0cHSb7abKfNvp96z2j19MnUGECFU6nwgQqnD76LfFXeLWaV6t5tZpXq6kxjRrTqDGNGtOoMY0a 06hRRY0qalRRo4oaVdSookYVNaqoUUWNKmpUUaOKGlXUqKJGFTWqqFFFjSpqVFGjihpV1KiiRhU1 qqhRRY0qalRRo4oaVdSoosY0akyjxjRqTKPGNGpMo8Y0akyjRlVUqhaGZJyQ8QMyvkXG42R4uwxv jQ6m0XL6LKdNM22a6TCOBuO8+pD8l8t/ufyXy3+5/Jvl3yz/Zvk3y79Z/s3iaBZHsziaxdEsjmZx NIujWRzNeqU6PPt3824oOil2uRl3JarNuevMuG/jevhsEXe8P+tmmBl3hDUVPwypin/HDNyOOzAT s/Aj1OBO/Bh3wWysMBsrzMYKs7HCbKwwGyvMxgqzscJsrDAbK8zFCnOxwlysMBcrzMUKc7HCXKww F/cZi3JUmHn5yZ4qxJ7R40k9ntTjSbrlr9OneHW93k3q3aTeTerdpN5Nij0j9ozYM2LPiD0j9ozY M2LPiD0j9ozYM2LPiD0j9ozYM2LPiD0j9ozYM2LPiD0j9ozYM2LPiD0j9ozYM2LPiD0j9ozYM2LP iD0/s64Mm6j9JoVffX9m5TNqj06TUa3Xt3t9mBvvcuNdbrzrve3eW+a9FTqlXKYn65Ry2Z48+h3Q Gxx6l0PvyrJWlrWyrJVlrSxrZVkry1pZ1sqyVpa1sqyVZa0sa2VZK8taWdbKslaWtbKslWWtLGtl WSvLWlnWyrJWlrWyrJVlrSxrZVkry1pZ1sqyNjpTJjW8WcWbVbHq6FD+rJLBv+qAPTogK5M7ZTJx 9JuZiflvZmTyaP7bLN6t4t0q3q3i3SrerZJVjaxqZFUjqxpZ1ciqRlY1sqqRVY2samRVI6saWdXI qkZWNbKqkVWNrGpkVSOrGlnVyKpGVjWyqpFVjaxqZFUjqxpZ1ciqRlY1sqqRVY0+vrLQxx+VxVuj /81pqqgfEvXzUYV8G+TbINcGeR0opwO98rB8GuTTIJ8G+TTIpyEqiU3n6y1hT+zW8E7sTnVxX+iL PZz/pt2zI7E7QzYq8r97ouO9Ixu7TUV8H3eGpthdUVnsbkffG7pjj+R/2zrsjT0W9lbY31bY31Yc hg/hcByByTgS3/Cea3AtvolvoRrX4du4Ht/BDfgubsS/4SbcjO9hOm7BrbgN38cPwt5CPiMi7YzN CF1y2RH7edgVc6UXXRW7SbXfjOmevU2W38cdoTE2E7PwI9wZHRi7KyyOzfa++0NH7AE8iIcwJ7wk v5cqYuHNijiKMQYlKEUZxqIcFUigEvtgX+yH/TEOB2A8DsQETMRBOBiHYFLoo2EfDfto2EfDPhr2 0bCPhn0V54bGivNwPj6GC/BxfAIX4pO4CJ/CpzEVn8HFuATfkMc1uBbfxLdQjevwbVyP7+AGfBc3 4t9wE27G9zAdt+BW3Ibv4wfhpahY5Wyl4gYqbos9EgbU0p1hUJ0MR1/gQo4LOQ6McCBfYdusOFkr TtY7slTOUTlnhclaYbJWmKwVJmuFyVphstTPUT9H/Rz1c9TPUT9H/Rz1c9TPUT9H/Rz1c9TPUT9H /Rz1c9TPUT9H/Rz1c9TPUT9H/Rz1c9TPUX+E+iPUH6H+CPVHqD9C/RHqj1jlsla5rFUua5XLWuWy VrmsVS5rlctSN0fdHHVz1M1RN0fdHHVz1M1RN0fdHHVz1M1RN0fdHHVz1M1RN0fdHHVz1M1RN0fd HHVzeu4W1Z3vxRk0vV113xntQ+1Oam+n9q7oRhrX0bhOpXd75ypad9K6M/YDj2eEHkcNqvy0yk+r /LTKT/PhPT7U8aGODwOxn4WVOqBFB7TogBYd0KKX3jQb3uBRE4+aeFTHozoe1fGojkd1PKrjUR2P 6nhUx6M6HtXxqI5HdTyq41Edj+p4VMejOh7V8aiOR3U8quNRHY/qeFTHozoe1fGojkd1PKrjUR2P OnnUyaNOHnXyqJNHnTzq5FGnDknrkLQOSeuQtA5J65C0DknrkLQOSeuQtA5J65C0DknrkLQOSeuQ NI/reFzH4zoe1/G4jsd1PK7jcR2Pm3jcxOMmHjfxuInHTTxu4nETj5t43MTjJh438biJx008buJx E4+beNzE4yYeN/G4icdNPG6KqjmY5GCSg7v5/RoXd3GujXM7OdfHuT7O9XGuj/8J/j/PvTT30rF7 PHcfp2eHhRzs5mA3B7s52M3BXg4OqJOlXGznYjsX01xMczHNxTQX01xMczHJxSQXk1xMcjHJxSQX k1xMcjHJxSQXk1xMcjHJxSQXk1xMcjHJxSQXk1xMcjHJxSQXk1xMcjHJpT4u9XGpj0t9XOrjUh+X +rjUx6U+LvVxqY9LfVzq41Ifl/q41MelNJfSXEpzKc2lNJfSXEpzKc2ldi61c6mdS+1caudSO5fa udTOpXYutXOpnUvtXGrnUjuX2rnUzqV2LrVzqZ1L7Vxq51I7l9qjj3Apy6VsoRv/24UhLgxwYYAD WQ7kr5sGqDtA3QHqDlB3gLoD1M1SN0vdLHWz1M1SN0vdLHWz1M1SN0vdLHWz1M1SN0vdLHWz1M1S N0vdLHWz1M1SN0vdLHWz1M1SZ4A6A9QZoM4AdQaoM0CdAeoMRCeYDO+aDO/q/rT1vDx2jyzulUUh evcfwRzr/WPW7Ul2dYfiMHwIh+MITMaR+Ib3XINr8U18C3aQtB6m9TCth2k9TOthWg/TepjWw7Qe pvUwrYdpPUzrYVoP03qY1sO0Ho6+RetuWneLOC3itC5I6YKULkjpglRB/792AN3/p8q3g4/lv9n4 31d7Nz+6+dHNj25+dPOjmx/d/OjmRzc/uvnRzY9ufnTzo5sf3fzo5kc3P7r50c2Pbn5086ObH938 6OZHNwXTFExTME3BNAXTFExTME3BtG5I6YaUbkjphpRuSOmGlG5I6YaUbkjphpRuSOmGlG5I6YaU bkjphtT/RTekOJTiUIpDKQ6lOJTiUIpDKQ6lOJTiUIpDKQ6lOJTiUIpDKQ6lOJTiUIpDKQ6lOJTi UKqwxvcX/ivkWbxK8ypt2qRNmyTt07TPa5ymcZrGaRqnaZymcZrGaRqnaZymcZrGaRqnaZymcZrG aRqnaZymcZrGaRqnaZymcZrGaRqnaZzPMS3HtBzTckzLMS3HtBzTckzLMS3HtBzTckzLMS3HtBzT ckxX5GthOm7BrVBvckzLMR3tZxZn/rZnVNo9hU7PmqnZ/1OP2LvfYo/qylS3JXRbiW7bptMO1Gnl 0bT3J8p0q/EM3O66/E7n+knoV9n93p3Tm/1W5yFHnUzhLIWHPrBr6lfd/aq7X3X3q+5+1d3//2na 9Ku+ftXXr/r6VV+/6utXff2qr///6a4of7WSo9TK969bhqL46HM5Lu2NvkzbetrW86+Xf720zV/Z tHFiDH276NtVmH+zPf65a4SH7ZTmeO6x0EXXLrp20bWLrl107aJrF13r6VpP13q61tO1nq71dK2n az1d6+laT9d6utbTtZ6u9XStp2s9XevpWk/XerrW07WervV0radrPV3r1VSvmupVU71qqldN9aqp XjXVq6Z66d5F9y66d9G9i+5ddO+iexfdu+jeRfcuunfRvYvuXXTvonsX3bvo3kX3Lrp30b2L7l10 76J7F927KvJ5TsctuBW34fv4QegqaLxntBNy0QGxJdGE2Kt2nK+py9fDzNjKMD+22z4jE2bH9oTG uMkZP8nV6ylhcfyMkHz/r5WviPaL/2Ph/68r/zeF3YnNYS3H5vncRXhNB7weNsaWq/QVWOmcq9yu CZtja13pbnS2JrfN6I7Gxnp0asYeN2snNIyRMBCPQke8FGU42NX/KaEzfmrYHT8Np+PMkI2fF7Yn qkI6cU1oSHwbZkTiu25vDJsT/wYzIfFDtzPc3g576EQNrJiJ+6ArE7O9/pDnzL7Eox7PwRM+Y17Y k1jg8xfjd2F34vd43nO1Hr/kVk6JRs+tw3q0eNyKze5vQYf39YaOxG4Mh47K8aGv8kBMgKvDSleH lUd7/rrQUGlPXymuyrvDUOV9YXflw3gMT4e+6LOjqrbxKUfVFqr2UrWXqu9SdQdVW6naQtXdVG2h ags1s9QcpOYgJQcpOUjJQSruoWKGihkqZijYS8E2CrZQsIWCbRRsoWArBVsp2EbB1r9TsI2CvRTs pWAvBVsp2EbBNgr2UrCXgi3U66VeL/Uy1MtQrpdiGYplKJahVIZSGUr1UmqQUoOUGqTUIKUGKTVI qUFKDVJqkFIto0q1UaqXUhlKZSiVodRgdGTsufDD2JLwO0rVqcG9FHqGKjtjW8M31dn0WE94UnVf ERuy094TLlBnb8TjYXm8JPwsngg3qPam+PgwOX54dG38mPA9lX9k/OTwSao9rfqnqrnH4xeE2+MX hq+O/nVWe/wfw1PxK8N18eqwNP/3S7L6k5n0qlXidawMbzvjO/zY6oxJZ+jxqf0+cbtP3KWXztNL H3NF+BzHXg3rHJXvlzcLPdIdfcjR6x252pE7xJYUW4VP2FjohzPCRke+GlY76h1HveCIAxyxzfna C/3rqrrQw4fr05M8PiVsdVSHKJdHh6ms3YUjl6usFVilYtY4eq2q2mgX2eS2OexQHTtUxw6VsUNl bFMZ21TFNlWxW1XsVhW7VUROReRURE5FbFMJOZWQUwk7OLeDc7u5lp/83dE+4ikR+Tzne855/yjX l7AqjNB1Cz2TidtC1ucP+vxBnz+YeMzjX4aszxmMih01JPKbHLE9X/d2ws+ZJUvk8npo9Ozm2Dpz JK/h1pCi2zqf2+JzW6IrnXW2d8/UU52FavljmOHsMxw5QIkRSoz4hE5KBEoMjfbVECWGYq1hkU+s VUmNsbTqKcf4cE18Ajcm4iAcFW6OH41jws74cXw+Hidxj+7xj3v9wsLfLp8qmlP1Xid1h6g7pPc6 KTxE4UDhoPc6qTCD0oESsykxmxKz9V8ntUeoPULtEWoH/dep/zqpPkL1EWrNoPwQxWYkFppEi/By uDmx3O2baMBabEIb3vZau9ttPmN7uLkyCm9UjgmLKktQiskeT8F1JtSsMFsPdnJzpPKRsL3yUczB LzA3LIoqVOSgatzO6dNNn/dMn/dMn/e4frZOf0+nv6fT39PV70WH8iPvZZb2/bTvd1SJGTVgRg2Y UQNyH5L7kNyH5N0v735598u1X6795suA+TJgtgyYLQNmy4D6HjBbBsQ6JM5+s2LArBgwKwaKyp1x lgp4hPvLuP8g9x+MLeVoHV4NK2PLrYorsDI8rQr2xtZ7fqPaag3TY5vCn2Nt2IwteBtbw92xdrfb 0ekzd7hNogvd0SzVUhtLub8TaZXX67YPu8LNsX4MuD+I3aHabGo0uVtN7lYdfIUZtTa212vv4r2w NPYXt8EqXIQY8vOrWLWNcb/EnCoPM+MV7ifCdwrzbF+3+2F/jMP4cJ5qvVi1XqxaL7a23hU/JNwa n+S1Q3F49JX4ZLdH4igz72gcE/4pPsXjY3Gcx8fjBPdPxEnhIjPyn02WhVybxbVZXJul2i81L++L n+U9Z+Oj4Ufxc9yei/PCHfHz3X4MF4Sv6YqL459w/8Jwk864YvQvZhfqkFvjV0UHxa9GdXjLfP1t ojo0Jq7DjWGvLtmrQx7UIXtVySxVMkuVzErM8vqP8B/4CX6Ke6MJifvwM8z2/oc99wge9XgOHvM5 j3v8S7dPhu8kfoWnMS/clfh1uNVqdkfiOY9/g99iYZiqq6Za4e5QgbNU4Cz7g7uscnck/hB+lFiC F7zvJc+97H1/dn8p6jy/3OOVnl/lc+s9twZveq4Ba9Hos9ZhPTZ4f4v3tmKT19pgeqvuWbp2amJr +LPOnWoVvUP3Xqx7pyY6PacGE2ow8Q7UYaIbPWFZQh0m1GEiDTWY2IV+DJgAg8i6nwtLE3sw4v57 UHMJNWcqzKxUd5XqrjIellYWux0TppsS002J6ZVlHo81PcqhBisTYVllJfZxf1/s5/n9MQ4HeH58 aLXSt1rpWysn+ryDvOdgHIJJOBSHee/hXj8Ck53/SM+ZsKbRzMo7QqMOn1V5dzShkteVvK7kdeU9 uBf3ee2hcKvOn2VSTTWppppUU02BWabV1MrHfc5ccT/pM5/2+fM8/jWewbPh5miyKXGTKfH7wsr8 WmE9X2ESdOn42Tr7azp7ia5drGtXW3MzOvYVHdupK9fpxnpduFQXbtB1n9ZZV+ukxTrmPh2zQsd0 6ZKHdckGXVCn+n+t+i9T/ctUf/5fKpyl4t+K/sW8WiCS31qx1scWW6WWmAl/9NxLeM0697rXlodm 07PZyrXMzOq1ci2xBvaKtsfqtcTqtcT8mifyFeZUj8jXmkXLRd1q3mw3b7aLvMu83ijyXWb2RjN7 o3myXPQLzYKFZsFCUe4V5Rfzex6r1/rEP5u014QlVrAlVrD1VrAlerNXb/ZawdbrzwX6s1d/LtCf C/TnAivY+sSdjvsx7sG9odlUbzbVm/Vmr9VsvdVsvQnfbMI3680FVrMlenOBXlqo7heq84Vqusd6 stF6slHd9lhTNqrVHnW6XF3OU5fz1OU8tdij1rarte1qbbva6lFbPepqu7rarq6WW4s2qqnlVrgl amqBFW69laNZfcxTHz3qY7sd5FJ1UIdX7dBWhj9SeofVYZ1a+KRpvsU036Ie1lC1g6qNVG1UEy+a 3Fspu8qk3kLZVZRdpTZ2qo13TOMNpvEG03iDGjlRjQybsm2mbJta2aROkiZrg8naYLI2qJkm03ST Kdpqcm4wEdeZiOuovoPqO6i9wwRcZwKuMwHXmYDrTMB1lN1h6q0z9daZdOtMtFZTrM0UazPFWk2x BlOswQRrNcE2mWCbTKtNplWb6dRmOrWZTm2mU4Pp1GA6NZhOm0ylNlOpbXQqNZhGbaZRq2m0gTur TJYtJssWLq3i0CrTZavpstUE2WpabDEttpgMW0yGLSbDFk41cqqRU42mwlYTYAunGjnVqPO3cGqV zl+n49fp+HU6fp2OX6fj1+n4Bt3eoNvbdHubbm/T7Q26vU23b+Fioy7fosu36PItunyLa+Juu+P8 vvqM8G50pi7LX2d9W0fN0VFzdNRrfJ6pa/bw9Rm+1vK1Vrek+NrJ10U8XcTTRToipwtyvJjJi5k6 IMePmSo+p8rnqPI5qnwOL2aq8pwqz6nyOap8jmreQ69FdFqkmvfQahGtOmnVqar30KtTJe+hTy19 aulTS59O1bxHNe+hUS2NaumzSPXmVO8clbtHzrVyfD3cp2KHZbDUo91iz4Tn1ObW6BCZ7fYoKbMe mfXIrF9WDeZASmYNMmsQ3W7RNYiuQXS7Rdcgqt0i2i2iHhH1iKhHNLtFs1s0PaLpEU2DKPLXsj3R 4c6UcaZNzpR0pqQzddMwf43a6GxDztbobI3OlnG2RmdrdLaMszXSYpAWg86aocWgM2ecOenMSWdO 0mLQ2TPOnnH2pLMnnb3R2fPXh0nXCFvNy93hLVm/5cxDzrjFLHvJxG0xcfPXBy8WJm6Jdw2NXkOl Rv8N0ynxK6PTCsp1eGWLVzoKj/LXdnsLOo4ZPWrQo7TPb/b5A3bDrfa0aQqPyLOcEhHG2JOWoBST PZ6CuaHfZ2wtOLPOuzdbRfIxDkVTfMYKr/yRfoM+60/e8c5fr+8L601kvpSiDOXhT7K6XDb/SsdB Om6l41Y65q+vt9JvUAx/EsMKMawQwwpa/u119yQc+oHr78nef7RenOJ2rvc/6bn8NXeRnPuiieIb ENOAmHaKaefoNzi7RN8jrl3i2iWOXeLYJYZdzj3g3APOPeC8O513p/PudL6dzrfTuXY5z4Bz7IyO 9ukvy/4Nma/6wJTdSOeFzpQtTNXywl+K/HjUy02yr87/Rc9fp4+MVznry876srO+/L+cPPlJM9n7 8lNmitv8xJjrvX8/McYWVtHd9gF7XFuX8PXL4cbRv+54y5m/UviL0dPEvdU7X+Rag+uCZvG/QqXF H5gg+ZWhlVJzeZ1fd9+h1lxqzZXPKz71Hp+2iIsN9m7NFJxLwbmcbKDiXB3RqiNaOdogv1d0Rasc t8pxqxy3crXBHqzZHqzZfqv57yZHK5cbuNzw/uSY7DOODnPl/oq8t3K5oTA9JlF9M9U3F76NyJgi e8Lrou6l/GYR94o4/x1OL7U3U3uzKHtF2EvlzVTeTOXNVN5M5c1U3kzhzc7US+HN1N1M3c3U3Uzd zboqY+qOWP1UjwrLhFeimFVwxE5pTxS3G1np0YBHXdFkj/pcw+TsT/rsT/qslMNWymEr5fDod4Qp e5Z++/icFS9lpUtZ6YatdMP26zmrXcoePWdf0WdPnrO6DVvdhq1uw/bdOfvunJVt2Mo2bN/RZ2VL 2Xv0WWmGrTTDVpfhaKy1fI9InrB291mz8/u6d5y1j4NPc/DpwlQZa7Ufio83SU4KaRn0eFc6fma0 rwnjmic61Xlao2Kfs8Pn5L9zzeUzkHGi8A1CKv9+SozXT2eGnOfz38p6h+O2Rwd6lM9+SPZDsh8q ZH6VvcLVoekDmQ/JfKiQdaPbdViPzdgC2clsSGZDMhuKjnC2tfTN0LeFvi0fvDJ37rSzJGmbcYak MyTfvxp/vvCNX5K2Gdq20DbzN1foLR63Fr4FLFyp07bF2ZO0bfng1XpUJPNMdHS80r3x4Um7pT67 pT67pT4xvSCmF6iVsWPqsWPKf7vWS6eddkZ9HHiXA7/hwG9cR45zHZn/68j8rqfHrqdHXC/Y3fTY 3fTY3fTY3fTYzfTYzfSI5wU7mR67mD4xvWBH0WNH0WNH0WM30ROViub3zrzbGXPOuNvZ9jjbGmdb Ex3l1W106xLjJjFu8s7s6HfY/8OhM+3szlPXF9JhXuii4QgNR9536XnP1Xr8ktuX7bRWuv2gay0e t+Kv7r3tPR3evz1s+hsXJ1Ctg2odVOugVAelOsTdPvqdVAdFOijSQY0OanRQo4MaHdTooEYHJToo 0UGFDip0UKGDCh3RIfJ8W45vy/FtOe6S40Y5bpDjBjlusFPNV90G+Wywq0zZVabk8radZb4CN8hl g1w22Emm5LFBHhvk8bYc3pbDBjlskMOGwr+iPCr+9eioaE70jfBYdA2uxc3hqegH4YHoh/h3zMDt 6Axzoh1IYtB79oT7oxHsxbt4L9xfdFxoLDoeJ+DDOBEn4WScgo/gVJyG03EGzsRZOBsfxTk4F+fh fHwMF+Dj+AQuxCdxET6FT2MqPoOLcQk+i8/h87gU03AZqqOJRcvCK0WvhheLXsPrWI4VWBmWFq3C atRjTVha/GR4oPgp/AoNHq/FW5Br8V8Qwv1j9guPjRkX5oyxyx5jlz3GLnvMRByEg9ERHhiT9p5e 9IcHSo7HWbg+PFbyHdyA72J6eKrkFtC9ZHZoLGkMS0tc8ZROCUtLj8Vx4cXS43EaTvf4fFwV5pR+ FVeH+0sfxTx0eLwN28Gz0p7wVGkKu7w25HE23F8WC41lcRRjDEpgp1hmp1g2FuWoQAKV2Af7Yj/s j3E4AOeEpWXn4uvuX+t2pttn3c4PL5ZlQuNYnzX2APvjr0XjwtroAJh+0YGYgIk4FsfheJyAD+Nz +DwuxTRchi/gcnwRX8IV+Aq+EZ5QuU+o3CdU7u3R98LcaDpuwa24DT8I81XzfNU8XzXPV83zi38a 1hbfg3txH36G2bgfD+BBPISf42E8gicd9xR+FeZz/YkxLWHtmC14G+3o8Pw7bruQ9nov+j33Xlhb UoJSjEU5DsLBOAZTQIcSOqiO+SVnuD3L7XluP4Ov4Wp8HVW4Pjyhcp5QOU+onCdUzu0q5/YS+ZbI VwXNL/tuXpvogdAYPYiH8HM8jEfwDJ7FfCzAc6jHGryJBqzFW2jEOqzHBmxEE1rRGZ43E543E543 E1ZHuzGEDLIYxp6w2JxYbE4sNicWmxOLi7tDY3EPUtiJNFydFPdhF/oxgEG4YikeQv64vyCExfrt +VKzoFTvl+r1Ur1eqs9L/4u4MwGPosj7cHVVT3dPT0+4Qrjvy2M9cF1d8YjrRtcDUFZRFARccBFM lFsgBMQLBOVUTgUVRBQFNF4c4sF6rorAAMNAkJsQYkeRO2Hqe7uJ++mqq7vfPs+XPK/dXV1XV1fV //fLLjPt9cf2DRw7wi3k6Qxd9WL7Tq4HwiC4B4bAcHgIRgPrzWaMbMbIZoxsxoj1tNh+huM8jos5 LgfGwWYcbMbBZhxYa6+w1l5hrb3CWnuFtfYxa+1jez+UQhllD5LOeLDuFhtnClNUExGwgu+gCb5b AqIQfHp3DLzw+4iriQxoI7LEhdBT5zPH85nj+czxQczxPszxPszxPszxPszxPmIoNQzTeczzPOZ5 HvM8j3meJ+4XVcQD8CA8BKNhDDwMY2EcPAJLRUOxDHbqYbzRYbzRYbzRx3ijC3ijC3ijC3ijC3ij C0TwCdLHdAFvtYC3WsBbLeCtFhgz9XpjFjwBs2EOPAVPwzMwF+bBszAfnoMF8Dy8AAvhRXgJFsFi WAIvwytQCK/q9fJsUUW2FlnyXI7ZcKXOl1fpAfIa6MB1bz1K9tG58k7I1blotmtUZz0Q3XaN6sZx oP5EDdJr1BciotaITLUO1bseV75BuGqnXqB2oUV2i1PUHo57g88G4rhfVDcHimrmIBgM98AQGArD IB+GQwGMgJEwR+exX+SxX+SZa0UVcx0kYD1sgI2QhE2Qgs2wBYqA8WS2FzDbC9hr8iPV9Hpm/TD2 mLzIfuGyv+Szv+Szv+RFykU1SwFzy6oONaAZnKrzrNM4tobfiiz2lDzrfM5zdT77Rz77Rz77Rz77 xyD2j0HsH33YP/pYzCVrGDCXrBl6vTUz/Bf06+0G0BAaQWNoDe31AlbaMFbaMFZagd1PVLH7w70w CibBNNLncHxaNGQ1FdgLOd9G/u2wA5hzrJzHWDmPsXIWsHIW2F+JqO1DGfkPcp/5xwoqsI+IKk6m Xu/UhCyoBbWhDtSFelAf6KtDXx366tBXpwk0hWbQHFpAD+rqCbdDAdcjYKReHzX0ereTHuDeAgU6 1x0JrBuXdeOyblzWjcu6cVk37qMwHibAROB53ckwBR6Dx2EqTIPpMANmwix4Ap6E2cD4uE/B0/AM zIV5okosH4ZDAYyAkcDYxhjb2H3A+o6xvmOs7xjrO0Y/Y/QzRj9j9DNGP2P0M0Y/Y/QzRj9j9DNG H2P0MUYfY/QxRh9j9DFGH2P00TtdVMmIggsx9gepVrNSdrIbBWfBZ4/Ukvewm3nhtwtYYIMDUXAh Bl74CfYeu5mHAkihAFIogBQKIIUCSKEAUiiAFAoghQJIoQBSKIAUO18Ndr4aKIESlEAJSqAEJVCC EihBCZSgBEpQAiUogRKUQAlKoIRdshe7ZC92yV7iDu2L3tAH7oRcyIO74G7oC/2gPwzQvdlR+7Kj 9mVH7cuO2pcdtS+7aQ67aQ67aQ67aQ67aQ67qctu6rKbuuymLrupy27qspu67KYuu6nLbuoSd7cQ d7cQd7cQd7cQd7cQd7cQd7eI4O8dC+B5eAGWijrsvHWIvz7x1yf++sRfn/jrE3994q9P/PWJvz7x 1yf++sRfn/jrs1v3Y7fux27dT+zFyxbDPiiB/VAKX4EPZfA1fAMH9DR29vns7PPZ2eezs89nZ5/P rj6UXX0ou/pQdvWh7OpD0fRJNH0STZ9E0yfR9Ek0fRJNn0TTJ9H0STR9Ek2fRNMn0fRJNH0STZ9E 0yfR9Ek0fRJNn0TTJ9H0STR9Ek2fRNMn0fRJNH0STZ9E0yfR9Ek0fRJNn0TTJ9H0STR9Ek2fRNMn 0fRJNH0STZ9E0yeN60SW0QH+DNfDDTBTJ4hECSJRgkiUIBIliEQJIlGCSJQgEiWIRAkiUYJIlCAS JYhECSJRgkiUIBIliEQJIlGCSJQgEiWIRAkiUYJIlCASJYhECbxEIV5iBV5iBV5iBV5iBV5iBV6i EC9RiJcoxEsU4iUKjU+Fa3wGn8Nq4RLFPKKYRxTzZJvg36hy/CPHK/VIoll7oln7MJp11qWyJ/Qm un0vqsk8XUpku5jI1ofIdjGRrQ9efIIaoF9Sy/V7aqXIUO8S/Vbj59fg09eJWkS5EqKcUhvx9ycj XYRI1zz8jMkS0vcTeQYKjyjnEeU8opxHlPOIch5RziPKeUQ5jyjnEeU8opyHki5BSZegpEtQ0iUo 6RKUdAlKugQlXYKSLkFJl6CkS1DSJSjpEnOa9s3pMANmwix4Ap6E2TBH5xA5c4icOfiuQnxXIb6r kCjqEkVdoqhLFHWJoi5R1CWKukRRlyjqEkVdoqhLFHXRmT4600dn+uhMH53pozN9dKaPzvTRmT46 00dn+uhMH53pm4d0qXkYjsBROAbHoRwqgDVBZB5KZB5KZO5FZE4Qmfvh/5L4vyT+L4n/S+L/kvi/ JC4hhUtI4RJKcAkpInhOZJf2cQopnEKKSN6LSN4rQp8i9ImInkNE93ANqUiaa619S4ABEpTwiPQe jiKFo0jhKFI4ihSR3yPyeziLFM4iZdUnbwNoRloLrlsCey0uI4UyyEEZeNbZ3GcOog5q4DpSKIQc FIKH80jhPFI4jxTOI4XzSOE8UiiHXiiHXiiHXiiHXhb7qMU+arGPWgNgIAzSvVETvVETfVETfVER OfjZJEoigZJIWLPDT2TKspbAq+GnMmVZ73P8QheiMhIW7xLfm7SOiCwURwLFkUBxJFAcCbxwIV64 EC+8Ai+8AgWSwA+vwA8X2hcKF09ciC/w8QU+vsDHF/j4gi2olPn4Ah9f4KNW+qFW+tlddKl9K3TV Q/EHvp3LOWvKvgvuhr7Qjzr7A8+Fd9iCd/DxDj7ewUfhuCgcFw/h4yF8eyz5x4WfKuijelz8hI+f 8PETPn7CRwUNRQW5qKA6+AofJTQUJeTiLXy8hY+38PEWPt7Cx1v4KKR+KKR+KKR+KKR+9i7q3g17 gL3eZq9HNU1DNU1DNc1HNc1HLQ1FLfVDLc1HLQ1FLbl4/SReP4nXT+L1k3j9JF4/iddP4vWTeP0k Xj+J10/i9ZN4/SReP4nXT+L1k3j9JF4/iepKoLoSqK4EqiuB6kqguhKorgSqK4HqSqC6EqiuBKor gepKoLoSqK4EqiuB6kqguhLOOfTpt3CBLnTaQDfq7sF1T7gd/kpaL453QG/oA3frEhRaAoWWQKEl nHspM4H058i7QK9wnuf8BTikk1EhslBwiSjPFq2hC6M1heter3e6N8CN0Em3R9m1d7twPkSXukMh H75TeqM4fxBGCw/F56H4PBSfh+LzUHweis9D8XkoPg/F56H4PBSfh+LzUHweis9D8XkoPg/F56H4 PBSfh+LzUHweis9D8XkoPg/F56H4PBSfh+LzUHze/6Pi836g+GqK8foio6toZ3QX1xu3iSHGX8Tl Rg9xkdFT3CSvFJ1kb3Gj6qgvU530H9QyPV+t1O3UDv0x2jBTscOpPXqSKtYfqn2inirBb+3Xh0Uj MT69SizUa8Xf9Fpqv6Ty02DPo/bTqf10ar/U6K0PE1t30wpuDlfWUbehlYtpZZBaoZert2BlulS9 o18jxm1U7+n31So9ntYfoOWjarfeS+ttaH0CrStan03rq4SjPtfz1Bf0CSev1uoeap1eqhKU2qA3 ExWL0KkL9Qf07QNy3kzs/Jzc08idr9am0+R+mtxXEUdfo8Q9lJgZfrbjWfS2gGjegOh9lWxHJO+t e8u7hJIvoJNX6b/ID/V0uVX8Th4iImeKKuos/axaITyi9Fk8wcu09CF+VKm1eM31+lWidITa0zxR gkidXxmpVaUnVTzZXrWPpyohfb/+yrhJmHqpiIAFNjgQBRdi4EEcMqCKXi6qQhu9WVwI9+sl4gF4 EB6C0TAGHoaxMA4egfGM4VK9RizTawypNxsKTIiABTY4EAUXYhCHqlANqkMNyISakAW1oDbUgYbQ CBpDE2gKzaA5tICW0Aqu00VGB/gzXA83QAGMgJFwL4yC++B+eAAehIdgNIyBiXqTMQkmwxR4DB6H qTBNb5Jn6yXyXMiGDvpN+bBOybE6xSzvyFspZZ5VMMeW8CZKmWPXMscq1OF0sTrCijiqbXUsfUQd T29W5dpSFem96oTOVmnSta5jRtLFpqUvM21tm076iBlNbzZdbZmx9F7T09lmnPQM8g3US81BMBju gSEwFIZBPgyHAhgBI+EZvdmcC/PgWZgPz8ECeB5egIXwIrwEi2AxLIGX4RUohFfhNXhTF5lLYRks hxXwFqyEt+EdeBfeg1XwN1irl5jrIAHrYQNshCRsghRshi1QpJdEyvVSSwHz14ro5VZ1jjWgGZwG reG3erN1PsdHdJE1FaZzzXNaz3LO81g8j8XzWDyPtZi0JfAKFMIbsJT0ZbAcVgB9t+i79Qnnf4dP Of8MPofVsAE26k1Wint7YT98AwfgWzgIh+CILrIzoApUhWpQW2+y60BdqAf14Vy92T4f+ukldn+4 F0bBJJgDT+s19kKOR/QSp5Uuck7Xm50zOZ7NsT1cy/nNepPTg/s94XZ4mPTppM+AmTALFkK53hQV uihajSPrK8q6itaF+nqz20On3D6QC3dBXxgIrHeX9e6y3l3Wu8t6d1nv7qMwHibARKC/7mSYAo/B 4zAVpsF0mAEzYRY8AU/CbOAZ3afgaXgG5sI8vSR2tU7FroG20A7aw7VwHXSAfP1mbDgUwAgYCffC KLgP7ocH4EF4CEbDGHgYxsI4eAQehfEwASbCZJgCj8HjMBWmwXSYod/0TtdLMqL6zQwXYvpNYRIr lrDzl6j14kz25QrxuBimZ4l8GA4FMAKO6RT+OYV/TuGfU/jnFP7Zxz/7+Gcf/+zjn338s49/9vHP Pv7Zxz/7+Gcf/+zjn338s49/9vHPPv7Zxz/7+Gcf/+zjn338s49/9vHPPv7Zxz/7+Gcf/+zjn338 s49/9vHPPv7Zxz/7+Gcf/+zjn338s49/9vHPfvApXMYH9PNDXYpnLcWzluJZS/GspfjQ6fjQ6fjO dfjOdfjOdXKeLg7//5En/19H2+URvZ1oliSKzVKrRSPi5TYi2CN4uFl4uFl4uFl4uFI8XCkeLvBP KfxTCv+UwjP5eCYfz+TjmXw8k49n8vFIs/BBs/Aps/Aks/AQs/AQPh6hFG/g4wNK8QGl9mk6ZZ8e fh5nKdo/0PIpdHYKbZ1CC6fQwCn0r4/+9dG/PvrXR//66F8f/eujf330r4/+9dG/PvrXR//66F8f /eujf330r4/+9dGrpejVUvSqj0YtdQZR972cPxd8apr20Zs+erM0msl66qSnozGnoynXoSnXeQW6 2BsBI3VxPFNvj9eELGgEjWEU6XP1diGJKi8S19Fxapm4QC0Xt6q3xbnqHVGb8X1DvYeSWiVaqc9F e8a6Pb4+gmK4BG9fXSXEOYz7lyiHhuicHaTuFKehF9qjF1qqYnEF9b5X+bfs02npXb2Q/FPCNpdw rw+qYrnIIO1jrlYHn0v548/SNXqL7J/+PF3605rVcRGttiUeXkUfTqa0JloeIfUyouVyomVJ+BnF +4NvoyS1PleXhH9TrEXeFvQh+C6CPeIMcpzJ1WqRzRNmcq8hzxp86lsn/ZkaKNrQ//fMi9FrkpSP uPo7uYlNaMIyroq4yhVxro5z9ZFoJUyRLSJggQ0ORMGFGHgQhwxa7ChqqlvQeF0hl2dajg58B535 rl5jDhTZ5iAYDPfAEBgKwyAfhkMBjICRIhsvn41nz8azZ+PRs/Ho2XjybPx3Nt47G7+dHX7/RRx1 e5CWiniKPept3mTwbSbv6tdRt/t59oGMyTL69Ra5eFqePS6qG1+IZsYacTYj05Vx+KO6hVydRWfV NfyMuc4qV78bfCqRGqx3qKniPDVNnE87Pm+6BUpmkXmBOMdsI85mtDqLhpRoSDvn8jYHisa09FXQ fthSvPJ7TT5UXSh9K/m7c7yN40Bm2Bd6Exq5FH18LJw/G4RDKSWs4JtQyJ1FzixyRsnpk6NMZImd 7KJoKLEb3dSfloJ3OlivQ3eX8tarsOOuCetL8AbXU4o6A0Ucqa4r8PAVePgKPHIFHrkCj1yBR67A +1bQZkddHPyLJ2o8jZVih7Wt1wdFrR+02YU9qzvk8WwDUeKr9Tf0rozn8JlxNWn7EKXep90Y7R79 xXZjtLsj+G4WaqtOuxFqPESNpdR4kBqj1PZN5VNUsM46khp8XmAXlHx36M+dgaIOJaP02KLkYUpW UDJOX9LBqFGynFWxU/xJ7ILdcIyZfRzKoQJOsDt0xLl00merLuwWt4puqjvH2zjm4X3605/Beq4a zryYKn7PfLiIEf+CFtuE72atfjJsLaE3sOYycTnHK+fIOSZ1m2nQolWkuviTfQt0hq6ilT0N5sE2 rrfDDqCfdhlpBzkepm/B5z+W0bNjPPMxenYaz32Mnp3Gc9fluYMdw+F5XZ51r9ooqoazbgUl3qPE LkrUpcQuStSlxO/JXZU+7wln3lpdTr+PUnJXWCoRfi/BLbTXmZnclWM3joPYFXeIpux4ZewxLjtj HXbGaux3K8Jv1AneX4pcipQy3kNHzjqFayP4NLwsNYBZdQ/xbg/9LqbFfdoP59s2yu2inEvtDjVL 7qREHdFTfyNuh7/CAN5+R97nLfSrKwxiZga5dzJL9jDSe+nTPvxlCbXsJ05eLGpFqupvIqXwlf7G yoU8uAvuhkEwmHozKr8TKEnNKWpOqQE81SD2/B28x53Mol2soPBp2YeLGaN9+tPQi9eif+X0r5z+ lVc+ffA35a3UspVaJLWcRh+rUssRaklTS/BJ8w41bA++j4j+ldO/cvpXTv/K6V85/Sunf+XiDNFT tBW3w19hmMgR+TAcCmCEyKHFKrT4G/asCCPcgT0rwih3YM96jpF+hZF+i3n6IfP0KuZpW/WCnsQz /Z0I0fJkb4hbQW+KURMXiDbM0TbmxTppzhE55lPwtMiJVBVtI9s4lnL8Cr4WOdapcB7kirZWHtwF d0PQP4deHa6cN7Jy3sjwXQUjuE/vDf8asYh+z6/MlVWZK4t+++Q8J/wLxD69jpmRm16FF/wK77cN r/cV3m6beUp6N3MtN+2TWkZKmXmKvoRac9Nb1WHGuZzSFewNJ/TnZkQfwRceNWP6IDk/J+cVYdl3 ubuGlDWkuGFZXx2nvXJG5YRej8dMm1FhUTZNrvV4yTQ5s9mXctN7aCWNSz1Iz0rVMY7ltFrBzDxZ soJW07jTg/S41HQ4uvQiRvrJmip4gkPMulx87RFhUEsZtaSpRVNDcdi2JQxKl1E6TWlNyeLKPpwa jFN6In3YQelmlN5M6cPqOCs26H0F8/gEMy6NTtD6BH3ZQW3NqG0ztR02ozoRPlWM9+yJqjjlEmo+ QZ9eCqKoltR4lH4UqbSQlDpK20VmnPNTdJMgR3o1OfbSXjBSKXLspc5glFLU8TWj+0/vi7df+Z4o /QvvJ8wbvhfy/sL74Bn/j++B/fTfHH92mf/yuPOMPzPe4Z2fHGeRYWaKqFmT/tUWrlmX2upRpj6a oQHnDbnXiHtNudec6xbca8m9VsQD08yihXrcbcyxBe/EMzO5wkOYtWi/Li3Uo6WgroakNyK9CenN SW9BOvXwFoLcQcv1KnMELQV1Vadfkru7zSxSakFt0ZD+VSfnbupsSP8k/ZOU2m025n4TaEp6c/K0 IK0l562CbyWnliL6GjyhNOvQ17oiUllLULqI/gdPKM1m3GvOvZOlJc+bCTWZe1n0uTb11uVZ6vH2 69NWg+C5uN+I+42535T7zUlrwf2W3G/F8/EUvJua1JtFai2orTfQhzSjs8Osz7tswDM3JE8j8jTm fhNoSp5m5GlOnpbkaUVkC96TF45rbZFJP4IRO0o/MulHjH544dg25bp5OIJH6UMmfYgFb0Wo8Nnr Vo7zyd4Ho6fC5z5Zoqyy11JU+U/nBKvWZ/z+aV6w2s8S8X93blDqbGH/3PzgbgtR4781R6jtNzz1 fzhPKH2KqPZ/nSvUckHwRP+d+cKb+CR8j//RnAljQ/zfnTfhrn6KOpzex07anR2nPrtaO3U8Xcau drmqSJew+/RkV2vMrtbGjKT3saN2Zzeqz67Wzoymy9jVLjdj6RJ2pp7sao3Z1dqYmenDjMgZjMip jMipZm2u6+jfMCIZ9Ko1o9KSUWlhNiS9Efkak6cJNOW6Gfmak68F+VqSrxWzJopz8/Bc2Sr4Xp9V ogZqNxOl2xxV8Xu0wvuovSrhdwstM7qKC43u4grjNjHO+AvHHjj3jvoJdSNe5Ca9DOXxRPhNdaf+ i1zvh7mC70DaGKZ+d7XkH1cSJ7/SeEcvCc+Cb7fbwVkVXPIZQog2eNLTxB/4PVtcI64XrcWN4iZS b0bLXSTuEI+Iq8V48YK4WywTK7l6h99J4hOxQUwWSX7niCLcyVNiLzU+b9Qz6om1RkPjDLHOaGu0 EzuNa40bxG7jFqOL2G90M7oJ37jN6CnKjFzjLvGtMciYLg4bM/mtazzBbz1jNr/1jeeNF4wGxjvG aqORPFueY5wlz5XnG+fINrKNcZ68RGYb58s/yhzjAnmFvMK4UF4przEuku1kO+NS2UFeb/xB3ig7 GTmys+xs/El2k92MK2VPebtxlewlexnXyN7yLqOt7C8HG3+WQ+Ro4yb5sHzU6CUnyKlGrpwuZxgD 5Tz5sjFYFsr3jQfkh3KDMU0m5U7jOblP7jcKZZn82nhdHpBHjDflMVlurJRaCeNdJZUyVilbxY33 VRVV3fhUZapM4wuVpeoaa1QT1dTYoJqrFkZStVKnGin1G3WGUaTOUmcZX6rW6hxjmzpXnWfsUG3U hcZudbG6xNirLlWXGvvUZeoyo0TlqBxjv2qnrjVK1Q2qk1GmblE9jIMqV+UZadVf3SOFGq6GS0uN UCOkraaqadJRi9Qi6apX1asypt5Qb0hPLVWrZFx9rjbK2mqH2i+bqsNKy9+YETNDnmdmmqfIS82L zYtlR3OgOVreaI41X5N9zDfNlXKq+Zm5Wj5prjV3y6fMYlPLVyNuxJWfRryIJz+LVI1Ul59H1kU2 yTWRLZFtMhnZGdkpiyJ7Invk1khxZJ/8MrI/8rXcHjkQOSD3Rg5FjsjiyLHIMbk/Uh4pl6WRE1ZE fmXZVoY8bFW1qsq0Vd2qKbVV22qolNXE+q1yrd9Zv1MNrPOtP6mG1rVWR3WWdat1nzrPesB6SHWx HrbGqW7WBGuC+os1yZqseliPW4+r261p1hPqr9ZT1lMq15przVV51rPWs+oua6FVqO62XrdWqCHW 29Z7aqT1gfWhut/62FqvHrQ2Wkk12UpZKfWYtdX6Uj1u7bVK1DTrG6tCzbKFLdVztm03Vi/YLe1z 1d/sC+yL1Tr7UvtSlbT/aP9JbbKvtturrXYHu4Paad9g36B22TfaN6rd9i12N7XH7mH3VKV2b7u3 8u077SGqzB5mj1An7HvtUaa0H7JHm6Y91h5nWvYEe7rp2DPtmWZ1+wn7CbOGPdueY2ba8+x5Zpa9 0F5u1rJX2R+bp9hr7A3mWfZm+4D5O/ugfdxsZ1fY2rzBaem0NDs5pzinmTc7ZzpnmV2cc51zza7O BU4bs5tzkXOxeZtzqXOp2cO50rna7Om0ddqavZz2zrXmHc71Tkezj3Ozc7OZ5/Rwepl3OXc7/cwB zjBnmDnYKXAKzHuce537zCHOaOdhM98Z5zxijnAmOBPMe53JzmRzlDPVmWXe5zznLDDHOAudheZY Z5GzyBznHHC+NR9xDjmHzPHOUeeoOSHKxmdOjJpR05wctaOuOSXqRWuZ06J1onXMudF60YbmvGjj aGNzgXu9e4v5vNvd7W6+7PZ0e5qvuHe4vc1C9073TvM1N8+9y3zd7ev2Nd90B7uDzaXuMHeYucwd 7o40l7uj3RfNt9133I/M3e56d4vpu1vd3eZh91isrpmONYtNjDSOTY49HRkfez22MjI7tjp2IPKc Z3u1I3/3TvcujxR5nbw7Ike9O72+VtTr7w20qniDvSFWdW+YN8yq6Q33HrSyvDHeeKuxN9GbaLXy JnuPWad4U72nrNO9Z7xnrPO8ed6L1vneYu9V61LvDW+5dYX3lveWdY33tve21dZ71/vIaud96q21 OnoJL2F18TZ4SetWL+V9aXX3tntfW3/1vvWOWoO9416FNdxLx4U1Mi7j0rovbsYt6/64E49bD8Wr xrOsR+K147WtKfG68frWY/GG8ebWtHjLeEtrdnxkfKQ1Jz4q/qD1VHxM/FHr2fik+BRrYfzx+FRr UXxGfIa1JD4rPst6Of5k/Gnrlfjc+HPWGxkyI8NakVE9o5b1cUa9jAbW6owjGcettUK66HchvMuq XSdOEY3Ff+lHL9M79R5xti7mfPNP5kjrWXoxv2V6LFfX6c6UeZ+z4sr7xbqE/26vvDr8o/LB3RJ9 kN//vWf/RDvfwmO/2N98eOsHKVtpISto5Wd/cF7k26TLOfeI5F1EnOudP+zjd0/zE21+qrdpX39G DTt42r2/1Mdf8eNQ69TK2nfpUv2+3l15deBHre+HIv2lXqeP6qtFlLE7TTT53v30LzWmD/HuDlLD //ac8UexnLz7rH5WePCPd/hPpb+C3TpFHVu5jKCzWopLOGsU3v2b/lxvYP4wd/DtP93+C/oZPZvj GMjWZ+pBeiBn3xvH756es9IflU7rD/ReZtAH+u/0g/cQjN4PS/0j76e/MBQCnypERng2vjLFp+7P vpub358VlSkHefIDjP1m/S16vwpJ5/IW/tG63h++of3f5f5R+VK9jzXmfzfiwV9Gw+OW7+f5pX5X 5kv94KrfD64++nV18NM6zF850/RG3p+jN/5Cy0e+t7Zbi9//Qu4X9YJgResPfnWfflh+TzA7gjn7 ozvrf0Vpnkw/FJ69/s/rWf/lV5RnjuhXw31ra/De/t0f/Xy4mz7PuP74x/lVNZTpZeGu+SvnxU/U cODXz6qfKF25w+q1/1HpJeF/NwY7x3/957e/ov09J2OZLmcefftvt+D9y7ut4M9hK99FvO0nfyvv N/qJMqfy24jfU3/Qy/mVx9Unf/9F+dY/Wb5ydJklh9idDv1ch9k/v9LfsINtC9dUMKuPhulTwtsN 9Tt6pU4EEf1nyld873ycqMP+f5O4NlghlWlFxIblP96L/1Gm/HvnE4k8VcRVojvniyrTdjJ6a34+ qn7XfjijZ1A+yu7Tv3InD9Jf0YuF0m/8bPl/noUR1FMv0h+tvP+R/pDx/6Ty6sf79/HvnY+ldB3R TgRKKLsy7S29lBpe+tn2d/10epo3FuyPuoNur3vqaytzz/lR+fvYxZ7VL+kvdOJ7yVLcKu4Xj3A2 XkwI/s2MeJGZu0i8gTpcLlaKc8K/KpwnVokN4nyxSewW14i9hiE6Gd2N7mIAjv7PYmDg5cXgwMWL e2QfmSeG4seTokBuljvFCFksi8VoWSL3izGBNxdj5WF5RDwiy2W5GB94czEh8OZiEt48JqaoRqqR mK66qFvFDNVd3SZmma+br4vA1WoxO1I9Ul18ar1mvSY+s96yVorPrc3WFvGFpS0t1gaeTqwLPJ1I 2tfZHURR4OnEl3i6m8S2wNOJHYGnE8WBpxMlgacT+wNPJ44Fnk6k8XTjDIGbm2RY9hR7uhENPJ1R JfB0RtXA0xnV7Ln2PKNG4OmMmoGnM1ri6Q4YZ+DmtHGto5yI0dlxHNfo6nhOhnGbU82pYfR0ajq1 jF5OXae+0cdp6DQ28pxmTgujr3OJk20MwLXdbgzCnY0xhuDOxhnDAv9l5AeeyBgeeCKjIJYfm2iM CpyOMc2r6tU2lnsvei8af/N2el8b7wdew1gXeA1jU+A1jC2B1zC+DLyGsS3wGsbOwGsY+wKvYXwd eA3jm8BrGAcDr2GUBz7CqAh8hHEi8BFSZkQzYtLOqJlRS7oZRzOOy+B/U9gYzhgjnDGSGTMVRzFN zGROzxLzSHmWX1vMFy8QpRYyn6xwPlnMpxWsureYVW44q1xm1cekfyISIibW8yuZZRtQ1ZvEFtRV kdjBGtvJnGsi9opvWPEH+G0qvhVHRDNxlN/m4pg4IVqINDOyWjgjG4QzUoUz0gtnpMeMzBVVZR7z 0gvnZXXmZZHIklvlVlFDfim3i1pyh9whasudzNf64XytF87X2uF8rRnO17rhfK0htdSihkL+i0xm reS//IiazF2bc16+qKOizOPMcB7XYx53ES3VrczmVszm7pzfxpxuFc7pBszpImGYW83dQpp7zL3C MotNX8TMMvOgaGgeMg+LKuYRs0I0Mk8w+1uEs79JOPsbhLO/QTj7G4SzvwGz/48i086xc0TMvty+ XJj2FayHCOvhalKusa8hpa3dVth2O7udcOz2rJNmrJPrKNuB1RINV0ss+AuIiNs3sWYyWDOdRRO7 i32rqGJ3tbuKFnY3VlG1cBVVC1eRwSq6k1K5dl/y9LP7kzLAHiCkPdAeRCuD7cHUfA8rLcZKy6fU cHs46QV2AflHsPbi4dozgr+nkGeM/TDtjrXHcXeCPYGUifZESk2yJ5Fnij2VlGn2NHoy3Z5OCutT uMH6pJ7Z9mxKzbHnkD7Xnks98+x55FxoLyTlRXsRZRfbixmHJfarjMxr9lL6+T/UfQl8FEX+/be7 p4+Z1CQhCSEXAcIVIMYQQsCQICCigquIeCwqOXRBI5lMEI+MZAbQILKoiIqoiFzrKrrIoiIiP2RZ RFQWERARuUVAREREQET6/+o7kzERFAKs7r/zqTc11VXVNTPdr963j5cF5gJ8J2+Zb2FU/zbfwWiX me+hz49M7Jnmxyb2SfMTcwN6+8zcQk3Nrebn+E52mLuxrS/NPZRmfmXuxTf5tbmPWpjfmN9gi/vN AxjzQfMgan5vfo+1h8xDKD9sHsZIjpg/oP+j5lH0/KP5I3o+Zh6jWPMn8yds/bh5HG1t05b/X9XS qbFkEyDYBAg2AYJNgGATINgECDYBgk2AYBNSwCYPAMdYY0iVnEIOySmkSE4hAU4ZDqxyBShaMgtp YJZ1JCI+iVhP7ohPIw5QtGQZ0iTLUCJY5nOKFTvEDooTX4gvyC12ip0UL3aJXVi7W+ymBPGl+JJS xB7xNfL7xD7U/0Z8gzr7xX7U+U58h/xB8T0liUPiEOocFkdQ56g4irU/imMUIY4LmxLcMrSOlfwF dLgdQN1tUAxYzKJGbqfbRQ3dEe4I1BRuN6WA12JREueOpyTJbhQPdksCJrtTUCfV3YTi3E3dTdFP M3ca8s3dzVG/hbsF8uA+lIP7UPKsewq28px7KlpNc09DzzPcM9Hn39x/p4aSDUmTbEjRkg0pGoz1 zxAbjsefxmyogw0nIf8MeFBjHjTAgi8jP5vmA98k7G1gw8XILwEHavQOeFADD34MxlwHftX4/L3F PKgxDzZkHoxnHnQxDzZiHkxgHkxkHkxiHhRKlBJFbmWAMgA4RCkDlitDgcOUYcCxylhygyWvIpVZ 0gmWvAUoWTKCWdLJLBnJnBin7lX3UgPmwRjmwVj1J/UnimIGjNYcmoNiwH0W8i7NRQ20AdoAStFu 4DvZJPc1Zu5rog3UBqK8kO9ukzzYmHmwiVai3UzJYR7cRRoY8CBZ4L5j5GLWS2LWi5dnbXF8dje7 4+jtYfYgjTnOMi8BxznAcX2Ql+ymMbsZzG4J5pXmlSiR7KaZV5tXA/ub16Cm5DgHs1s8s5uL2S0J 7FZEwiwxS4A3mzej/l/MvwAHm4OBkuksZjpXiOmGmcNQcieYzmCOs8xKsxJtfaYP9WuYLoB8kONG mfchL5nOYqbTmOlc5jhzHFo9ZD6MEsl6FrOeCLHeBHMCyiX3Wcx9Scx6GrOew3wWrKeFWG+qORX5 aeY0MNp0czrqSx7UmAeTavGgxjxogQcXIB/kvoXmv5D/t7kKKLnPAvdtQF6yXkNmvXhmPRezXiNm vQRmvURmvSRmPWF+Z36HVpL74pn7Epj7kkLcdwwcpzHHCUuxFNKCbOW6x1VJTte9rnuBVa4qinAF wE0RrpGukSipdlWTk3lKjZgQ8RSpzDhx4mtwTbT4VhygGOaXaGaWODDLYeSPiB8oCpxyHMe55JQG bs2tURTYxKRI5pEY5pE4MEgM8pJBYt2N3I1QR3JHnLuxuzHKm4S4oxl6kNwRw9wRzdzRgLkjBtzx LPp8zv0cWs1wz0D9mWCNGGYNldTs/fLMa6edF+VSb7r+13T+/x+Lvdv+UqbQu60ni7vkeR4+11ff vnfIM1wceS/m95/VbJNxVSj63CvjT45FN9jb7V11z+icers1Z+hsb/1HeG4Xuw8iT/n6q7H3CS12 I9J+98zPy4T72fvLd/a3jKFyxIoH8c1ut/chhc/s1YpE42q13oBa60me92iEXOgMY010/TstrvBo am9X0J+57KuTnV2w95x4bs4+YG+zP8WaE65CnOlSc5a87jt5/IT26lrnCzB2LZzf+2u/sr3lxLOa 52o5+RWcU7aaaU/j12N8Nny5TPL8kP0icu+F6tTsWfII/t7+sKa8XtvZwfvo9p/fy7Ng9qZaNR7i 80HyXPkWzu3AaGozVOj7Pd3fl89abz91vfov2NNq9Wsfso8hHZXnuuyf6tT7retS/2PL73zMn8Zi Tz6Lxn1P0t92Ssc+mHoWvf72kk7MrZJPmVNPuoAbTvsa4tnPFb/or86oah97p9l+rr3InhO6PhBn P2cv4tLP5exee/Y+I/2wHty4lfXDLtYmzGZyTrK34vWlUK19fL3tfaR38Ler7plrZrJEqjk3uxRz wXv2R0iTUdrbXmN/wOVrgyqCr2j/uf4jPWHkX9Z5x3Oo/c9aJaX2DLvMflCe5beHhku7oGy+PO5O vOpI8prriddC99iL8Vk2nLsjtWZ/kPMYGKxGF75HoeuztccAXg5fG5HXWE7R83/O1RjPdMG35ObX R+X15hPWDrOX1qkbfN2E2e1zuYecwfY+lns96y3+nmQO89vW0LcGtG+zV/LvfZi0k8xhbso6oc99 OA6+Dl1d0sAcNVedDgfXnv389vN16LrXK2tUitRePG/vwN++E7TnFtaeJznacTSfY+462fILPltz wvpjvywJlVecvJzqcx293os9qJ4NgvdYjLGr+fUbZoBXZULuBXteMMfravQZX+/EL/XmGYxurj0f jPl66N1SexbJ+4PekHkkMCdYbClYokYFfwP2/SDEE8HrZ5En9Pmu/br9dqjPOPkuVF6HHWy7/qPl djhK7U/D72pil20yVxNXBpU4M9p7cv8I3iMSOn4OMCPfZPfld2+TvJrnRbobufH2JMx1d4d6qXVv C76Bt2zfGYy22K6yp9tlyC3BUT3dHsz88BBmo+n4nt+2J9u3Ym79Rl4D5E+2wJ5tTw1uOTRrJNlL ftHnLnsdosrgkdsxnAvpTvuHYDp9xVyn74N8vIfvCqo7S/E8HY58Wflu5fseat9xkVn3jpXfa6l7 FZfvYPr61CPhT3TC/Ve/x1I3kpXfKvbh707Fn/zrnLNItz5Lbf2Bo0FGWZ/g9VeudIdr7jn78drP 2sPt++0nOf8h9vdp8k6Z0DwU1Ivf268hLTq77XBPWcE7Wc6qj8/tnZgJeX7Eb7oT+2FYcwd/dXs/ NMf+kynAem/rDDR3rdYfBH9VjEXy4H9C77aEjp/QqP+Y4/lkiz3I/ou90J5HKr+rsu8CWxcFFYH9 hn0E78bZFfYFdnPwaI59t33bWWwrqB+bntV4Q5wUjGnD9xtOq7v2XC72zHPQh9x71wVZHfr2hF+f 12+3V/88C/+xC0bzGY45PueJfVhGiuFIJah0sfZdpF+5V/X3XjDeh2sfudBXC/7I8fz6gqNtmNRO wTtd7Tugjtbi6Auue5vxM/tN+wb7QeQesTcGy85wW++e/XjrucWDte/z+t9dwhr3wNnfXXmye93P 5RJUh9DfX2DWOwdnLE51j/Jvtj3NPcp+hc/tf3XmW6q1JJ6TXk5rgRY6a+VqP3ouRnKKbYSYDur2 rM/Ln6Nf6VRb+RzK9r98pJy7Barn4Dn7ZmLOYhzn4nj/Ha9HnMneCN2zPdgy9GRHzXmRlXydYeVv NvaE6s6p/3Z/7+VMnoE4oY9fvRryG234bL08UxSMhINndMLXgl2/FR/zud1EKiOj/tvl9mfwlJe9 i+eOn58lqzknd7qxXQRdUv+t/qFL/Jk2rP+VJ5J3Ncjr0uHI3n6L8Wvw8ymvRvyvLdD93//6MxO1 6h3574/l9JbTY8gzndVP+qzUKbfFdxD8/OwgX7EI71mukzaqqSvPVaXQDTjm/oClrnYPsgaip1Pw LF+J+QPO99nfnsO+tlHojPJJnzhqw085ySvoH55k7an6ls9RbatpWZPjM/zbQiU12+zC2/rFuGq9 e+DnPmvGIp/XOmFU8qms9vIqzZlE7fZk+3l7Qfg5sFBOKoLQOc0Pw+Nof8J4n6//9uq0P4M7hezV fFXi/fB7vgcIetM47St9p/H03q9s+6TPJp+izU4+ayVncuYCfrcUx16QGVy/pS95Romirqf3vOZJ 2p/J/Q9r5POWnA4F3zOGzpr/NjuEPktK3fuNsH99a3/EaTI1gib9MnQ1aWvwmOZ9rbT+Iz3F5whe YasVrdtF9t323+0p7BsQvqfH7mPPrWfPS38fxSzH+OvbsY+f7Kpy8IriL8q+PfVVnDNd+B6ZEDPb B6AnDkAfrbc3/MxE9l6UyWvGne1r+f2r2APW2TfZ78j39tv24/Yyecac1z1Wp+9NNeX1GtGVdpk9 0u4desc57IGDOf+8PcMeiv1gMtTaAsy8ssY8+3X7tdCsLc/Ox1MWX3O+xx7CZcH7EadAVz8rfw/p khC+C6jOuSD7h5qn+es13qfsFxGrPR16t5K3PZl5fiV/B/Lq6xz7oP0vrhB8aj90h0FoL+5Y/63+ Uct/5WnsE7eyrYaxgted/6jlTK5T4Zf+mmqddQg7JJzO3BNL8v6dqzmfQjmIPZty2y+gOr7g2SSZ Otgf4wiVf5vszfYFOF4Gk7CD83ooTsXRGYypGoXezw1dqVAp/MQ0l7/8G5+D762wfZjnQmcg7e52 IVIfexDF2sE5uMZDowrpYruLfY0derLBXm5v5Lsl5BG7B3PStlD82o7SeeZsx7V+++zGycc1zZ4B fDH8foGM5ercWdE/lLmB+lFnymafmJa8pvZndx1fbUccP8wz5UL7dvtVOYfZfvs+mUOvY+tsNngP 2O1nMN4hdjk+fzm/sZAbwrx5H8/UH+G33HU8+CT9G+wKUrPwN2vfEerjNGK8k277y1PXOaHNXr4j QOoE3pt4b16K9w5eLX5T78hWUZSP0au05hQ+dgNCPnaj6DJFVRrSLexOdw+7041hd7qxygDlJhqv 3KbcRo+zL90Typ3KWJqkjFOepNnSnY4WSHc6eku609FC6U5H/6f8S/mQ3laz1Pa0Us1Rc2mVdKej NeqF6oW0VrrT0cfqZWof+kQdqt5BG9R71EraqI5XH6PN6kx1Jm1X/67Ops/Veeob9JX6pvomfa0u VBfRPnWp+g59q76nvkffqf9RV9JBdZX6ER1S16hr6Ii6Tl1HP2hCc9NRLVqLoWPSYY5sdpgjdpjT tRZaC8VkhzmLXeUitFwtV3Gzq1wku8pFs6tcDPvJxWoDtBuUOG2gVqjEy2fllATp+qYkSdc3JdPx hmORMkC6vikl0ulN+Yt0elMG6dF6A2WwHqcnKrdJvzelXN+ob1Pukn5vynDp96ZUSb83xS/93pQR 0u9NGa1/r/+oPCA93pSHpceb8qT0eFOekx5vylTp8abMlB5vykvS401ZJD3elLelx5uyyrjJGK18 It3dVEW6u6kO6e6m6tLdTTWlu5tqGVONGWqk9HVTY6Svmxorfd3UFOnrpjaXvm5qa+M9Y73aRjq6 qRdIRzc1z9hlfKXmS0c3tbt0dFP/JB3d1L7S0U0tlY5uaqV8Pk71W6qlqgHLsEx1hBVhRaijrCgr Wr3PirPi1GorwUpUR1uNrcbqGKuZlaY+KB3X1L9KxzV1nHRcUx+x2lvt1Uel75o6QfquqY9J3zX1 Caub1V19UvquqU9J3zV1svRdU5+Vvmvqc9J3TZ1uDbIGqzOk75r6N2uYNUx9QbqvqS9K9zV1lnRf U1+yHrQeVGdb46xx6ivWI9Z4dY50X1PnSvc19VXpvqa+Kd3X1LesV61F6kJrsbVGXW6tsz5RN1qf Wp+pm61N1i51m/Wl9Z26V7qyqYelK5t6xLKdivqDdGVTj0lXNvUn6cqmKc5EZ6rmln5sWqwzzZmu xTnbOTO1ZGe2M1tr4uzo7Kg1dXZydtGaOQucPbRWzp7OnlqGs5fzUu08Z29nHy3L+SfnlVq28zrn 9VpHp8c5VOvkaupqoeVLdzetu3R30y6Tbm1ab+nWpnmlW5tWKd3atJHSrU17MKJ/xM3aS/KpPe0t 6dam/VuYIkpbIX3atI/FDeJWbb/0adOOS582h0P6tDlM6dPmcEmfNkeE9GlzNJQ+bY4U6dPmaCx9 2hxNpU+bo52YKV5yZEifNkeO9Glz5EmfNseF0qfN0U36tDm6S582x2XSp83RV/q0Oa6SPm2O/mKb 2O4YIF3WHDdKlzXHTdJlzVEiXdYct0qXNcft0mXNURapRloOT6SIjHTcGRkTGee4RzqrOe6NPBx5 2OGPoijFESBV2Q7Wi0TEF0XRpFAD/GkUg3nYQQmYu3XM6i1R3gp/JrXGLGhRBljSCT7sQgJ8KP/P Q1f+DxiSMSOZMaPAmNei1XX4awDevAk9DqSbqRvdAg7tDg4dCuVwB/560DC6hxpSJf7iyUd+bDkA hk0AwwpKVNxKJCXxE8LJSjQ49zxwbmuUpCvplKW0UdqivJ3SDvkMcHEic3F7cPGVwL5g5IvZLzRR uQm8nM28nM283AG8PBzlVcoDlKOMUcagzwfB1Mlg6kcoVxmvPEGdlIlg7fbM2u2Ztdsza2eBtV9E fha4Owvc/Q7mg2XKMuqivKt8QPnKCrB5AbO5CjbPAXYEpxvM6dHM6SpzejRzehxz+kXM6eczp3dm Tk8Bp79ITdRZ6ixqrL6k/oOaqbPB8mnM8mnM8k3B8guB/weuT2Wub8Fc3xhc/x/gSjB+UzD+KuBH 4P1U5v1U5v3m4H1BLTU32L8Vs386s39rsH8CtdUStURqpyVpSdRTzgTIYyagNpgJWgPTtTZohfmA MuR8gFZ5Wh6wi9YFawu0AmBXrSvqYG4AYm5AiXzW+hJ+1vpSfr76En6++lJ+proX5okAdXWMcDxA CmaL8RTleNQxkS5wPOmYRLGOpxxTKM/xnGMaNXJMd/yDEh2zHa9TEmaUNyhbuolSjpxXKF/OKyTk vAKM1qOpu95Ab0Dt5exC2Zhd1pKmf6x/TE31dfo6itI/0T8hh75e/5R0zDobUbJJ34SSzfpmMvUt +hay9K36Vmqob9O3UYSck8gt5yTU3K3vpgb6l/qXFIOZ6StS9L3619jiPv0bitX36/upkZyrsMXv 9e8pQT+kH6IC/bB+GGM7oh/BeH7Qf0D+qH4U+R/1H6mr/pP+E3o+bqgUa2iGg7oauqGTghnOJEwW hkVuw2m4KMqIMCJIM4QhKMFwG24qMCKNSNTBLCj/q7sRi7ZxRkO0TTASUT/JSKYYI8VojJ5TjVSS DqjNgGlGGnpobjRH/RZGC9RvaaSjfhujDTUy2hptUd7OaEcOI8PIoEjjPCMT/Z9vnI+2WUYWemtv tEedbCMbbTsYHUjIGRfb6mR0QnlnIw81uxhd0EO+0Y10o7txMWr2MnqRaVxiXIIxX2lchc/Vz7gG /d9kFGHrxUYJtnKzMQj9DDZup27GEKOcuhteYxi2eKdxF/Uw7jbAHkal4aN4417jXox2uOHHZwkY I9DPSGMkehhljEIP9xn3UYRxv3E/tlJtVKPOaGM0tgIFQMlSAVAWFMCjlGNMMCZQB6kDKBE64Ems nWRMoiTjKQM8YDxjPEP5xmRjMr7tqcZU4DRjOmVLD1jUh1ZADy8ZLwFfNrCXGrON2Wj7ijGHLjb+ afwTPc81XsXaecY8tH3DeAPl840FqPmWsRA13zYWY+2/jCWUC4WxDOXvGu9SJnTGe6j/vvE+Sj4w PkDNFcaHqLnKWIXxfGSsRp01xhqMcK3xMca8zlhH5xmfGJ9QJ2O9sR5toVHQarOxGT1vMbag1S5j F3rbbexB/a+Mr1D/W+N71DlkHMK3cdg4jLEdMY5RotQx1AE6xo18pNmAcswYM5aSzTizEeWaCWYK dTIbm02pPVROa8o30802dJnZ1mxHXcwMMwMl55nnU4GZZWahh/Zme9TMNrNRp4PZAWtzTMSO0EYX UEczz8zDtrqYXVA/38zH2gKzANuSngKK1EyULTUTEJoJCM0EhGYCQjMBoZmA0ExAaCZKkpqJkqVm AkIz0XlSMyEPzUT5UjNRovSqpUyru9UdraCcUALlhDpQTkAoJ8qVyok6QTkhErAGW4OpAPqpnKIs r1WBOlBRaAsVhXKoKNQcYY1APyOtkciPskahHIoK44GiQv1HrEcoxxpvjUcr6CrqAF01ESVPWtjr rEnWM8j/3fo7tvWC9QJdJpUWSqC0yCWVFhBKCwilBYTSAn5pfUsXWgesA9jKd9Z36Aeqi7Kk6kLe tmz5v7ecRBc7FadCiVKBUTIUmAm0nBZ1dGKhLKfL6UJeOCOBUU7Mv85oZzTlOhs4Y1AS64ylfGec M446OBs6G1KBM97ZCOWJzkTKcSY5k+g8Z7IzGfkUZwq20tjZGGtTnakogbZDHtoOI4G2A0LbAaHt gNB2QGg7ILQdENoOCG0HhLYDQtsBoe3IJbUdXQhtdzVFu/q7+pPhusZ1DfLXuq5F/jrXdchf7xpA cVL5oeQB10xSXX9zvYw89B/y0H+oA/2HOj9EKKRGqBFJdJFUgdQ56N0gVSCpUgUCoQKBN4gbqLG4 UdxITcVN4iZqIAaKgdREFIpCai6KRBGliWJRTJooEX9BfpAYhPqDxWDUuVXcijq3i9uRHyLKqIXw CA/qlAsv6gwVQ7H2DjGMUqEs70b5PeIelENfAoeL4cAq4acUERAjqJkYKUah5n3iPtS8X1Rji2PE X1EyTjyMnqFBsZUJYgLwMfE46kwUT2LMk8Qk9POUeBr5Z8QzqD9ZTEb+WfEs+pwipmDtc+I5ai2m iqnURipXSodynUntxN/E36ineF68iPwsMQt1XhIvYe0r4hXgHPFPyhBzxVysfVW8hrVviPnUVrwp FqDkLfEWSqB3gdC7wH+JJdRS/FssRZ13xDJqJd4V76LmcrEcW1khPkTJKrEafUINo/91Yh3wE7Ee dTaIz7B2o9iIfjaJzchvEVsoByp5G3rbLrZTa6mVKRVaeRSluO9z309p7mo3viXo5jGU4X7Qje/K Pc49jpq4H3I/hJJH3ROonfsx92PUU+pplEBPU4bU0xQn9TSpUk8DoaeB0NMUJ/U0ZUPZdWM93Yv1 tMpKOqibaxSz1MeRrI8j6c/4i2RlfCkr496sjGNYGV/OyjielXEjVsYJrIwTa/n36OzfY7F/j87+ PTr797jYv0dn/x6d/Xvc7N+js3+Pzv49Ovv3RLF/j87+PVHs36Ozf89l7N/Th/17Ytm/50/s33MF +/dcyf49fdm/JwlKPQK62a24WaMnUkclSUmChpZKvTOU+pWUx1r8auUa5c8ol1q8izJIGQSFfady J/AuxQfdPByKvBMU+RgqgBZ/EPm/Kn9FfanIO0GRP0ndoMUnU3eo8NeAryuvUw9lnvI21koVfh2r 8ItYhfdkFX4xVHgWaazCtVr6W4P+voj192XQ331YhUuHIQc7DDVgh6EG7DDUkB2GGrBGv4o1+gXq g+pY6iqd/al/SKlLXd5OfUV9hdqo86HLm7Mib8mKvLX6gfoB9LfU4s3U1epqlH8M/d2MXYsaq5+q m6DIt6hbgNLBKINd3dqqO9QvULJL3QWU3m6p7GzUQv1a3Ye89DdqpX6rHkBeuhylqz+qx5CXXkdN 1OOqTanseJSmKZqKvPQ9aqXpmo68dD9KY/ejFlqEFoGSKKj/TNb92az7c1j399OStRSUS/WfqTWH +j9fawX1n8nqP0trq7VFPkPLALbXOlAHRAKdkO+sdabztAsQD2RyPNBey0c8kKldqF2I/mU8kMmR wDUcCVzLkcA1HAlcyzFAL6j/iRQJ3T+FYljxJ7DiT2bF39kxD4q/CxT/UipwvONYQT1Y9/es5cmk sydTFHsyxbInU1+OBHpzJNCd/Zn6cDyQh3hgDRkcA5j6p4gBDI4BTI4BIln9m6z+E/Qd+g6o/J36 LpRI3W+w4m/Eir83K/4YVvwJrPgT9YP6QaDU9L1Y05us6WNY0/diTa8aBjS9yWreZDWfyKq9F+t1 k5V6DCv1RFbnvViXm6zLE1iX94IWR9xrZEKRG6zFY1iL9wqp8BwjB/VzjVzUl1q8F6vwoOY2WWeb rK0vZW3dm7V1DGvry1lbx7O2bsTaOoG1dSKr50RjnDEOmvIh4yGoSame81gx5xsTjYkol4q5Iyvm 7sYUYwp0pNTKucZ0aOV81srJrJULjOeNWdDxL0ElJ7NKvpr1cYHxmvEaWkmVnMsq+Wqo5Plo+ya0 cjJr5c6slQuMfxtL0cM7xjuoL7VyLqvkZFbJnVklF7BK7mmshkrOZ5XcnVVyLqvkAlbJ3VglX8wq uaOxydiEtVIfB5VxR2OvsR8lUh93Zn2cx/r4auO4cRwKVSrjfFbGBVDGjZCXmrgba+LuZjOzJfVg ZdyTlfF1rIwvYh3cnXXwdayDe7IOTjY7mZ2AUgFfzAq4p3mheSH6lI5iUewlprOXWBS7iEWxi5jO LmIudhG7gl3EdHYR081+Zj9sXXqJ6ewlFsUuYn3YRSyWXcT6sotYEruIJbGLmM4uYjq7iOnsIhbF LmKxtVzEothFzMUuYlHsIpbELmI6u4hFsYuYXstFTGcXsSh2EdPZRSyWXcSS2EVMZxexKHYRS6rl Iqazi1gUu4j1ZRcxnf3D9Fr+YTr7h7nZPyyK/cN09g/rW8s/TGf/sCj2D9PZPyyK/cN09g/T2T8s iv3DdPYPu4z9w/qwf1gs+4f9if3DrmD/sCvZP6wv+4clsX+Yzv5hfdg/7Ar2D+tbyz9MZ/+wJPYP 0xHDxFIeIpaW1J3jkx5Wa6s1YoN0Kx1av53VjjpbGdZ5iDcyrUyUZ1lZobgl18q2OtDFHL3kWrlW Z6CMYXpaXawu6EfGMD2sXtYlwEutPujtcutPqHOFdQV1tK5EJFNg9bX6IUK4zroOa2U8080qtAox nhKrBK2CTowywumJCKcU25IRTqRVYQ1FP3dYd6DVndaddJF1t3U3SqqsAD6FjHPyOLZJZufGXI5w 8q2HrYeBMs65mOOcfOsJCyzBcU4uRzgF1nPWcyiZYc3A1mW005OjneusF61ZaCVjngLrH9Y/UOcV aw7wVUQ+EdZm63PgF4h5IjjmuYRjnh7WQesgepYxT571o/UjPp2MeSI45rmaY57uHPPkc7STy9FO Hkc7uU43Ipx8RDgNqBtHOD05wrmII5yLEeHEIwpq5ExAzUREOJ05tknmeKYH4pnW2EpbxDMRiGdy gLnOPGABYpgIjmEiEMNcCZTRSwRHLxEcvVyC6KV/KGKRscr1iEMGcMRyo+tGlNzsupm6ukpdpcAh riFAj8sD9Lq8wGGuYUDpRdeAvegasBddQ/aia8hedA3Yi64BRz4axzZXRSRHpNEFEb0jrqKuEbdE +Kg/O9U5ONpxIMJphyhCxjDtOIZpI/6CGKaZuE2UQqnLuKUZRyztELGUI+8VFYgc7hJ3oUTGKs3F veJelFSJAKIUGZ+05PikHccnbRCfjEXJXxGltOEopbV4RDyC+jI+aSeeEBOx9knEJ60RnzyF3mR8 0pLjk2Bk0pwjk0wxTUwDzhAzgDIyyeHIpJ94EZFJe0QmL6P8H2I2ZXFk0p4jkw4cmeQgMnkVJa+J 1+k8MU/MQ803xZsol/HJ+WIh4pNMsUgswtqliEyyOCbJ4Zikn3hffIC1K8RKlMvIpINYI9agpoxJ csSnYgPKP0NM0gExySb0thmRSSpHJlliq9iK7cr4JJvjk/PF5wIaj90BM9iPtK3YI/aiRDoFpol9 Yj/y0i+wFfsFprFfYAb7BaaxX2AT9iNNFT+Jn4DSOzBD2AIKkB0EW0CYQwGyj2AT9iZNZTfBxuxN msqegq3YUzCDvUnbuiPdUSiX/oKt3LHuWJRIl8F0dhls4k5wJ2Gt9BrMYK/BVuw1mM5egy3cae40 rJWOg63YcTCNHQdbuEvdpdSMI7GWiMRGciSG/cH9gPsBRGhjEH215OirA8dd/RB3PYH8RPckyuLo q4P7affTyEvnwlbsXNiYnQsz2LkwnZ0LW7FzoYOU5AMpIyB+hTaWthAVDUAqQhqENARpKNI94VfF OwuvfqT7kcYijUeaiDQZaTrSC0izkV5DWoC0GGkZ0gqk1UjrkTaTOuJ9TlS0g5M6YhXSOuT3IO1H OoR0jKhYRbKQIpHikJKQmgbHUNzqV14zgn0VZ4eSbNMZqSuvo+KeSL2D4+U204Ofsbgv0rVINwbL Q6/qiI2cFO8cpHnIbw+XBdNupH2h/Dqkg6H80WAaSaFkIAmkGKQEpNRg3ZEtuD4VlyDdGvyeij3h 7zxYty3Xo+JhSD6kEUijQ59hXHB7I7NCn3UC0iSkKaH1M0Prc0MpH2X4HYvl51mItCT8WYKfeR7S QqQlSMuRViKtRdqAtBVpZ+h1b63XmvoHkI6EXjeE2h2ptf44UYkDyYUUjRSPlPLzq/z9StKQ0k/7 VR3Z4+ffSn62kszQb13flFQ38f49Nrgd3q+SgvV4u7VTDlLez6/hPoL9qiMvRXk3pF6h/Q/rSi7/ +bWkH9L1jgYDt5b1rlpVdH85MRqMAji2PAY4vjwBOLE8FTi5vAVwennbqlWyVeDGohfKswIlA3eW 9a1aN3Bv2bVVG4tml+cy5ofzr5X3qNoo1wZuHXig7Maq7UULyi+t2h7Mh/BIWUnV7qLF5Vcw9gcu 4/wyzq8oHwBcXV4EXF8+CLi5fEjVbtkq4AHeivzxMk/VvqId5UOBe8rvAe4v91ftk+WBYYWOsmFV B4sOld8PPFY+NuArdJX5qo4Wq+XjGScyTgZaxT2BkeXTgXHlLwCTymcDm5a/VnVUtgqMKG5VvsA/ uTC6bIQf32z5Yj8VxpeN9hsSA6MLU8rG+UVxdvkyYOfyFX4hSwLjguUhTCub4I8pTC+b5E8o7lq+ Oow9y9f7E2R5YEIIM8um+FOLe5dvZtwB7Mv5a8v3AG8s3w8sKT8EvLX8WBg9XjUwqXiY1wpMKcwp m+lvUezzRvpbcG9tQyUjvHE1KEsCMwvzymb5s4pHe5MYm9bkZXlgVmG3sjn+3OJx3lb+XJkPzCns 5s1AvlfZPH9+8QRvNmPncH6StytwircncKa3N3CWty9wjvdazt/oz5dtA/MKLy9b6O9R2K9sif/S 4nnekjAu9JYEFhYv8d7qv7Tw+rLl/isKB5at5DF4GIeF88u9PozklrK1/v7FK70jwrjWO9rfv7C0 bIN/wG2LK0cwjmYcB1xWOQG4onIScHXlFOD6ypnAzZWz/ANkq2rfbTsq51SPKPSWbfUXFd5VttM/ 6LY9lfOA+ysXMsr8ocol/kFybfXowuFle/3Gbccql/uNUrVsb/W4IBaOKjvgH1JqVa5kXAuM5Hwk 5+MqNwCTKrcCm1buBLaq3OsfIltVTwAeQX5M2XH/0NKMygPA7MojwM6VKJHl1ZMKH/Y4/PeUdvVJ 7OlzVU8pfNzj8vtLe/uiJZaO5nw8sK8vBXitLw14oy8dWOLLBN7qy/H7ZavqmaUeX171rMKnC7f7 7y8d5uvmv79wqifaP1biyBaFz3vi/eNLfb5ewBG+y/3jZUn1nGB5CF/2pPgnFs71pPknl4729Qvj ON/1OHZQXj0vhPM96f7ppRN8AxlvCecn+UqBU3xe4EzfXcBZvuHAOb5RwHm+MdULSxf6Hg6UFC7y ZPpfKF3ie7x6Cfc2O1Sy3Pc0cKVEWVK9vHCpJ8f/Wula31TG52vysrx6ZeH7njz/gtINvpf9C2S+ em3pVt/c6g2Fqzzd/ItLd+KbB/rmh/N7fYuAB3xLgUd87wOP+1b5F9/u8K0Dunwb/Ytl2+qthes8 vfzLCjd6LvevuD3at/0XGO/b7V9RuN3Tz7+6cLfnev/621N8+xgPhvNpvqP+9YX7PAP9m29Pv5fC mHmv4d9ceNBzi39H8QbvOMYJwK2c3+mdBNzrnQI84J0JPOKdBTzunePfIVsFlpQ4vPMCywuPekr9 e4rI4/XvL3F5FwKjGeMZU7xL/Pvl2sDKIsNzl/9QkeFdLlHmS9K8KwORRcIz3H+sJN27lnHDL/KZ 3q3AHO9OYJ53L7Cb94D/mGwVWFsU4xkVUIsSPGMCVkkv7xHg5d7jwH4VDuD1Fa6AVZTqeTgQWTKQ 8ZaK6MCGohaexwNxJaUV8YwpjGmBuKIWFenIeysygXdV5ACHV+TJctTfWjKqohtKxlT0Cuwsaut5 OpBU8nDF5cDHK/oFkoqyPFP9qyUG9pY8XXF94EBRrud51J9aMRA95FbcIhElW4PlIcz3vBxoWtTD Mxdje76iFPgy49wKL74ZWX6kZH7FXZg9OV90qWd+oFXJoorhjKPCuLRiDPD9ioeBqyoeB66reBq4 sWIqcHvF84HjJbsrXh7hQD+LAhlFqRVzgT08S4FXeN7HOPdVzAcelMglW4v6e1YFskv+H3vfH9RG duf5upGFxsNoGIZhWIYQhiEMIcQhxCEcS4hDGMIwDGEJYb2EYA39U90tIbVaLdkIISRZdoiPYrxe 4vURx8f6fJTjUI6LcxzOcYjPx3pZilDE62NdPop4KYdwFOEcwvocyrnve5IY/CMZb9X+t1vf+ny7 3f30+v34vO+P5277gfPKoxpfD0Da6rzWnccYnZOBZEuL/WZ3KZPknOkuxeeBNEuLE65YLPbbpF9R fSd+zqQ4l0CnO1dBZznXQec6H4AuUBHoItUIfce/vW/h7Xe6KyyKfam7iilRkx7T5WpKd5VFta92 11q89vXuBqbScRRrNX1L16hZ3Q0Wv/1BdzNTr+aCbiK6RS0AbVGLApk4JgnkMLxaAvEJxAaBfEZR y7uWGFWtBO1Va6IePLAL+8HAbsav1vuzmLDa5M/CnihQxvSqLdgrqRbQ4GsCe5h+lfeXMAOqAv4F 1kugmhlUVf8i5m2gjhlSvf5NZlj1gx5Rw1GOBRrx/Ab2MqNqb3eepUbtBw3jEGhjxtQBPCbqIOho T8fVIdAT6nB3A/E4d+XdnUngfbDlX5HLOlP8irynMx10dWdWzD7fw1bu4H25rjPXP7TvUmcBaGxn HsqNnUXY5nSWgAZLEjHIezvLwXq0dVb65wjzF5gpdSTAMrPqaEBi5tSxgIOZV8cDOrOoTnTdZpbV qa47zJo6G/BBmTkos6HOB4LMproYOMzS6nKgjzWpa4FjrFnd6FrdV6du+ivZVBcdOMFmuEyBU/v2 usz+ejbblRo4sy/flRE4t2+XK9ufxea58rqvs4WuwsAFtthVHLgUjTfYUldp4Apb4aromsERReAa W+WqCkyyta5aPAuuhrhnZxtczUS3gm6Gts2wra72wE223SUGbrOiyx64w9pdWmCJ1VwHAqvsAVcg sB6Nad+jXRGI4qJxFIlS2IDrCMSuJG5kI66joI+4jkMUh7nx4L12F2j2qOt0D2KPu872GNmTrvM9 SexpXHKfwXWxa50967rckxKN3CyDrqtdM+x513VY4yRGZS+6pruW3stw3eh6wF523YKni64FGIer rrugr7tW/LnstOsexGBnXfehPTdcD0Hf0gyBPsuGthPqX9CSe9LZu1paYAaPQE8Wu6JlRrndk8ve 03Kgnvtavr+Efajt6ingDNrunqJohMnt1Mp6SrhkbU9POV4XPZVcmlYNUTrE6j01Uc1lanXRCLyn fptuIrqFPMVCNM/laI1dS1y+trdrldultXWt44i6R+F2a2zsXCXai9dXjz82khAP94SJ7sWt6unn yjSppz96TvQAt0dz+FO4ak2HeBii4p5Brk7zRWPgnqFtehgiVc2fyzVqQdB7scZRa89IVHNt2uFo pNozyrFan7+Ik7RjoOE6XHFoJ6JRa2DPB7pnDK/6nnGiJ6Ka07VTEItCRNozxfm0MxB5QlzaM8sF tXP+eu6wdgG0Q7sEMee0dgViSzwvc1HN9WnXeubbc7RJWN3YMpu5Y9oMeM8c7Sacn9Bu9yxasrQ7 2CNoSz3L3Clttfsed0Zb71njzmkPeja4C27Us8ldchuDdMy2E+ttaXEnBU3cFXcKWGOvOz1ojlpC 7po7K5jKTbpzgxncjLM6mM3ddBcE86IxQLvkLgJfQLwMdxvb7aiP5u64S4KF3JK7PFjMrWJvy627 K8HrgdUKlrbPuGuCpdwDx41gRfsxd313Bo/cTcGMmF8+427pNvNGtwXHEm7ev8gnuRXs092qf5NP cXu7U/l0tx+ee9sdxv7LDTaQz3L3w/Vc90B3KlPkHox7Cr7APRSs4ovcw9A2iCV6UvgS90hgBvcu WMuXu0ejlrb7Bl/pHoN6atzj4AXA5wYb+Hr7hWAz9lPBVr7JPRFs51vcU0GRt7hng3Y8bkGN1HOA 591zwQCvuOchxwEbHoxEox2sA21RHY9q7HrwCNbRK8GjRB/HbQieJPo0r7oXu2ne617uNvF+HI3g yCTQxofda9Fz8Heg4VfgC4JnsdUNnuV73RvRuCJ4PqahF4FGvt+9Cf6CnJN+neUHdLo7mx/UTRBR QFwRvMgP6eZoFAGt2tLB4+1n9NTuQn5YzwA9omdHPT7UAzp4mR/V86JePniVH9MLu4v5cb0YNFyH KxN6adTLB69v09PYTwVvEH2c6Fv8lF4Bvhs8eHCBn9WrwFODHw/e5ef02u5afl5vAL2oN4MXq9db u5vJmK8QfS82Mst6e3cpv6aL3VX8hm7vbuA3dc2/KND6geB9me2sieyUpc76cL3s6GwCrXe2+Ptl X6fFz8vBTt5vlA93KpFkKKPC3b5ObyRNPtbph7snOsORTPlUZ28kRz7T2Q/Z0KnOAX+vfK5zMJK/ 71jnkN8vX+gcjuySL3WORHbLVzpHI2XgMcf8Q/K1zvHQYXmycyKyR57pnIpUR7ODfZOds/4x+Wbn XKROvn3gQqRRvtM5H9krL3UuQh631Lm8FYevdq5F2uT1zg04f9C5GbqgIB8dYRWjzxSRlCSfOeJQ UnypEV1J92VEfEqWLzsSjGagUq0vD3KuaKZDcgol11cYORzN8pQCuKIqRb5iyLnA10f6pNO+0kif nO+riBxTSnxVkRNKua82IkmFuOS+Pl+D36tU+pojp6J5lnXc1xrPZ6M5plJD8spa6S7O+HztW08/ 6xNBk1xJqffZIWOK5jgPIcccV5o613rKpQqfBvW3+A5EzigWXwDyLBiByDmF90ViscpRRfEd8Q8p qu+of07x+o5HLih+38nIpWg+qIR9pyNXlF7f2cg1HOdEJpV+33nIqSGzjswQfVMZ8F0ErwEZNPgL 0JHbWHeTnDpyBz8lshTVyqDvMvRoCHIuVRn2XfV7cf4bWVVGfNdj5+tEP8Dx0iEUG0nIXg8ZYxpa dShJGfVNH0qKnhOdooz5bvgHlHHfLcheIYc9lK5M+BaiGeuhrG06V7ruuwsjNuVbAT2LNc4xA3uj Wpnz3YvmlYcKlHnfff+osuh7CBquw5XlLkM0xzxUtE2X4CjuUDnRlVGtrHXthMwR8sdDNcpGVzLk iZBFHqpXNrvS/LM2uisTtKkrxz9nM3flR9rwvBxqIrplX1/XrsiqLbVrt3/MltFV5p+yZXftgZJ5 XdX+FsGkB4IPSe5A/BGxXZCzCGY9EjIIqfqR0E6LUT/akyJk6Mex79BPhpKFbKzh/HQoTcjTz4Yy QZ/f0oX6xVCOUKxfDuULpfArUzSnEyr0q6FdQpV+PbRbqNWnQ2VCg34jtEfIwPaT6PtCs36rZw1b y1A10XXtQX2hO1Vo1e+GGoV2fSW011Ki3+teEET9fqhNsOsPQyzREraTIUcstwId0gXNYwj5onmW cMCzMxQUAp7k0GEh4kkL9QlHPJmhY8JRTw7o45780AlsM0OniD4jnPTsCp0DvbubFk57ykIXhLOe PaELUZ8inPdUhy4JFz11oSvCZU9j6Jpw1bM3NClc97T1lBMrahKmPayfF254pNCMcMvjCN0UFjx6 6LZF8fi6q4S7nmB3hbDiOewfjXoorEN3LH7whnDu6QseiEZuXLLnWGhJuOc5EVq1IM+p0Lpw33Mm 9EB46DkXfCgUei6EckSD51Jol7jTcyWMxGTPtbBRTPNMhpPETM+Mv1/M0Y+HU7bXJuZ7bobTxV2e 2+EscbfnTjhXLPMshQvEPZ7VcJFY7VkPl4h1ngfhcrHRi8KV4l6vMVwjtnmTwvUi600BLXnTwykx 7fBm+RdF3ZsbbhJ93oJQUAx6i8It4mFvSdgi9nnLw7x4zFsZVsQT3pqwKp7y1oe9eH7DfvGMxRsO i+e8TeFeMdMLNl+84LWE+6NzJ17y8uEB8YpXCfSJ17xqeFCc9HpBz3j94SHxJvx0WLzt7Q2mWmq8 kGGJd7wDoJe8g+ERcdU7FB4V173DoB94ysJjVuQd6Zm3Gr2jfqM1yTsWHremeMfDE9Z074RfsWZ5 p8JT1lzvbHjWWuCdC89Zi+wzPeXWEu98qMxa7l0Mz0PJZShZ6V0LL0afYq3xboSXrfXezcCMtWk/ HV6zGMV8/4a1Zb8pvGEp32/uzrZa9qeGN638/oyDtFXZn33QZFVF30GTpWk/eGerd3/hQYjl9hd3 N1v9+0sPplrD+ysOZlh791cdzLb27689mCcU72/oWcP6YGE067cO7G8+WGwd3N96sBRHLwcrcJRy sArvohysja44soNxJLZT8ejquBLbKyA7AwcbrEP720P52L8fbMY5+MFWzMaD7dHdIWIf7luH9eNQ P4nErCP7xe4bQt5+e/eN2O4N2VexjtodB0Xh3n7toD2a9VvH9h84qOG5DjQiGr1KrVH/FyHqt9QG oqkH1O+Qgfo9TSEjvYM2oufo5+kk9DydTL+EXqBfodPQi3QG/Rp6ic6h30Av0/n0x9Er9Hfo76BX E2oS3kbpO6p3fBll7FB3uFDmjp/u+CnKMoOgj5qzze+ibHODuRXVm/eZD6Kvm983/wQFzdfNK+gH 5lXzBroJrfkzZCD/+4EZvYieQy+hJvQ8akbt6CuIRd9Creg/oj4URv3o5yiC/gH9Ak2if6J2ov9F JVEvoN9TL1KvUBSFv3Ey4fcmqVepFkqgMikrFaEKqMPUMaqGOk59h/oa9d+on1FfT/h+wvcp3aAZ 3JTHEDAEqf2Gw4ZvUT7D+4b3qYDh24a/pnoM3zX8DRU2jBjOU980XDT8iDpi+InhJ1S/4X8a/pZ6 n3yPecwwa/g59W3DvGGB+mvDXcOvqEHDrw2/pk4Zfmv4Z+o/47foqNM7Xt7xMvVfd/x8x0Nq2LjD mEvdML5pfJNaN37cuIv6rfFzxjLqd/gLD+r3xi8Zq2iDsdr4Lm00fsXYSpuN7xlZOtPIG1U62+g2 +ulPGr9p7KM/Z+w3DtKfN37XeIauxV9O0I3GEePf0181ThunaadxxjhHq8bbxtt0p3HBuED7jL80 LtNd+H0susf4G+M6HTFuGB/ShxNR4gv0+4kpia/Q3018NfEN+m8S8xI/S59P/GKiQo8nuhKP0iuJ f5X4VwlJid9OHEx4IfF7iSMJL+P/VzXh1cQfJl5KyEwcS/xpQhZ+HyghL/EfEucSdifeSrybUJr4 q8R/TnjLlGe6kNBk+s1zryf8wvw78+8M+Hs5BR0GnYSy8NfGledjMAEKUZ7SXnNfEatq3r5ZVaTY FU05ULOgBJRIldLQr1xULitXq8aU68q0ckO5pSwod+t21uUoR+p05ehbtW+JynHlpHJaOaucr8t5 qwpYZQCOrxGO/xZR1O+p3yMaGJ2MEuDeR8ibqIj+Hv09RNHfp78P987TP0AJ9I/pH6Md5E1UI/0z +mfIRL4Ee47+OX0D7STvoCaRt09foH9B/wKZyXunL9K/pn8NqwO/WZqSQCVQW/9r8I4EI0ojX46l J6QlpKE/SUhPSEcZ5E3R1xLyE/LRR8hXYVkJ5QnlKJt8A/Z6wp6EL6Ic8lVMLnln42PQ/iQqhYwc 1ki+hnzyNXlSnpFvyrflO/KSvCqvyw8UJK8rRiVJSVHSCbKUXKVAXlWKlBKlXKlUapR6pUlpUSwK ryiKqngVvxJWepV+ZUAZVIYIhpURZVQZU8aVCWVKmVXmtoutWZlXFpVlZW1LNpRNG20zbROzLdWW YcuGq3mPSKstD8oW2optpcpmXGwVtipbLWgsDbZ2Zc0mQlm7rd2m2Q7YAraI7QjUmWc7ajtuO2k7 Df2nnlNiVgN/s/4SGZN0kASUCWJAeehNtAMVgiSiT4GYUBnIc6gcZCeqAHkeVaG3yNvl74DVwd9d voj+ArWgZNQGkgJ2h0UvIxEkFbmQRr64PEC+tewmb5SHUAbYo/fRa+jbIB9B/wkkC/0XdAZ9FH0P 5HU0ApKDfgTyBvrvILnoxyAfQ/8DXYP2TYLkk/8N++NoDv0jKkD/G6QQ/RPIJ9EvQXahe+g30Pb7 6P+hT6OHIJ+haCoR7aZ2gu0rI++P/ynYvmRUTt4fr6CyqNfRF6g3qDfQl8j3nlVgDRvIF50tqJr6 BmVBX6baqXb0DnmXvI583fkupVAKqqc6qA70FcpN6aiB6qKCqBFsZwTtBev5TfQX1LeoI+jrVD/V j75Bvu5sA0t6Ce2jxqgxxFDj1E8RS01Qf4t46u+ov0Mi9ffUFLIS/spgBfKRYiowFaAO8naew/Rp UzFykjfyXKYyUxnSTBWmCuQmXxLp5P07j8lieg/tNzEmBnXC3N5FG4T7JfhflpBGAWOAccAEYCqG 2RjmAPPoz6UxaVyakKakWWlOmpcWpWVpTdoAvSnTsgnELKfKGXK2nCcXysVyqVwhV8m1coPcLLfK 7bIo22VNPiAH5Ih8RD4qH5dPyqdBzsrn5YvyZfmqfF2elm/It+QF+a68It+T78sPlcOKQdmpJCtp SqaSo+Qru5TdSpmyB6RaqVMalb0gbQqrSIpD0RWfEgTpU44pJ/D/ILqjfYcVnOA3zG3k31d461+N 3++CvEhYnkxY/hJh+cuE5amE5a8QlqcRlqcTlmcQlr9GWJ5JWJ5FWP5RwvJswvIcwvI3CMtzCcs/ RlieR1j+JmH5x9EUSAHh+icI1wsJ13cRrn+KcL2IcP3ThOufIVz/LHCdRiWE358j/P4P1EeoLOA9 ZnY5YfbnCbMryPcRXyBs3kPY/EXC5krC5i8Bm7tgDXRT3bAG8FcSXyZsriFsrqX+kvpLWA+Y03Xk +4h3CZvrCZsbqCngcSM1TU2jr5q+ZvoaajK1mFrQ10xWkxV/r50cSO6FeUqCsX8eUc424F0xoBRQ AaiKXasFNACaAa34muElabezRJ794yBl5tQbUpmzXNrjrJTnHwW+JlU7a+RFwLJ6C0Oqc9bLa38c uIzU6GyS9jpb5I0PgP8stTkt8qbTotDqgsQ6ecX0x0HKmNW7kuRUlFSnIjmcKoHu9CoZgGzVTs7z 1BWlUL0n+Zx+KegMK8UfgPy5VL0vHXb2KhUfgir1oVLrMkh9zn6CY84B6YRzUGmIAp/jvinNH4D0 9ZRzSGl1DuEjwRnnsNL+4cDlpHPOEemCc1QRH4V0yTkWr3c7pCvOccX+AaRrzolngaNNPyFNOqek GefsU3HTOYfhYPVTGNJt5/wz4Y5zUVpyLj+BVecahkNy9Unrzo1ngcOhn5EeODcxZKTSBEbVhOHQ 9XP42GF3n5UtarucpJrlFDX1cTh8+gU5Xc34MDiC+iVSR5aaTZCr5skFauEjKFKLn0CJWvoIytWK Z0alWiXXqLVPoF5tkJvU5ifQorY+AtzvZ4CiuXbKvCrKimp/KuCecsCVrARcaaScqmrPBK96QPar gSeA64sAjrgy5bAaeRYoR105cq96ZAv96tEt4PvHASdd+eT8tGuXcta1Wx5Qj5P2PgblvKuMnA+q Jz8MykXXHuWyq/qROobU049gWD37BPBvr7rq5BH1vHLd1UiO0669T2vPH8SoelEeUy8/gXH1qjyh Xn8CU+r0dig3XG1x277dFsdt5ZaNu+Vit2zQgkvabke2eLJ9XuPzEh+juy7H1tiuuPTtbSK25DDY FFj7jr6oDXAci65fsq5OqBnEbwDfHacAZ/QrcT47zsERnoPvK/dcPuW+K6g8dB22GVx92L/YdrqO 4eu4b7Zk1wlbmusUtq+2TNcZbCdtOa5ztnzXBewDbLtcl7BtJ30Gvtt2u67E7bOtzHXNtsc1iftt q3bN4LGw1bluYtuJ6yRodN227XXdsbW5lmysa9UmudZtDtcDm64hPL7EB+GxhDG0+cBPxvyZLQj+ JzbOtsNQT59mxHWQe8e0JNsJLQX7nS1fu22OturEiPmUuC/AbcK+0XZKSydtO6NlxeeZlMe2H+ae +GXweaRv57RcfM12AXx4WRTYX+PxfQR1Ub+M/RXxx/CcuC/GRwLgD+nbYz6WPAtgu+T0Y2AfG/er cdiuOPsxtnwk9pkx37jdVz7iI2N+Mg7bNfCDMMfE94E/tE06xzAIb7GfuxLFls0C2Ga0AnK8qRXZ bmsl5DrYD9sdrdy2pFXaVrUa27pWT67jNYx9CV63sI7werI90JrsSGvBtshu1CxkXcTXQcwuEm5B PdjO2ZPANsXWCJkvsFv493Eb+MTaemxdbdmXePuhDmw37Skaj+fcnq4pW7/H5WG92bM01Z6reXG7 7QWa316khYkNx/2BPthLtF57udZPfvdh9ifWLntlzI7H13hkW5lYm0lfH7PHW/3BdjiOP/SsP2BP 7TWxY716HvdpC4/bye22EtvHuI3cbhOhLKkHl8H3YAzsTa46xwX9muOSPomBYxs83ySuuaLPkGtg s+yzbrPjmn4zHr84JvXb9rA2TuwYxB2OGf0OiSnAptlHtGW7XxuLxwSOm/oSsWnY/+O4Adu62/oq 9tGOO/q6Y0l/YB/XNh2rHuRY9xgdDzxJTuRJcRo96c4kTxaJyWL2kvwWx2axuInEPPEYBdcVqwPf c6Z4crG9xO3aiu3icdj6BzaYIB7DxGIPXBeOx5zpngIc7zizPEXx35Py0B/yZxgvsk6gb85cTwm5 huPGOGJx4iN4PBaMxX6PIDauj8d1W8CxWByPx3XxGO0psZmzIIoPjc1w7LU9/sIxVzzu2hZj4baS 3+IysTF5Ym3B+rO3aANPrCuLNhiPsey8NmRXtGFsi+Ll7Ko2gnlt92qjhE9xO4DL4DUH/CPHXm3C 3q9NkfMBbdY+qM1hbF9v9iFtHtsI+7C2SPg5qq09EccA7GPaBgHwEYOsQ2y3Jtw0OU65TfE1iNeE fc6dap93Z2ytP2yDFt3ZxNYsu/Psa+5C+4a7GPueOHB/cY5F1h/02b7pLu2g3RWkbrAfHSZ3Feln rHyH2V3bkepu6MhwN3dku1uxLerIc7d3FLrFjmK3vaPUrWH/R3wgtk8QE3RUuA90VLkD2B531Loj JGcBX9jR4D7S0ew+2tHqPo7Hq6PdfbJDdJ/GeUKH5j6Px6njgPsiLt8RcF/uiLivdhxxX8cxILb/ cdvccdQ93XHcfYMA6sN+BnO746T7Fh73jtPuhY6z7ruYZx3n3SvEhsE8dlx03yP3Lrvvkzquuh9i W95xXTd0TOs7O27oyR239LSOBT2z466e07Gi53fc03fh8e24r+8mdgz3/6Feho8Og74H88GxU692 JOt1jjS90ZGp793iD8TgOP5w5OhtjnyddezSJXI9ZnMdu3WHo0zXyfzBOnHs0X2Oaj3oqNMPb3E1 ngfEfRScOxr1PlzGsVc/hq8hGlHmiLkfoX//G5R/Q3+DsoLuffD3AOwGUrgMLpvL4wq5Yq6Uq2gy cFVcLdcAuplrZTeiwmVjcO2cyG5GhbNzGneAC3AR7gh3lDvOneROc2e580193EXuctMV7ip3nZvm zDE5SnCDu8WlxmSBu8utcPe4+9xD3sDv5JP5ND6Tz+Hz+V38br6M38NXc3RcoEQd38jv5ds4U1R4 lpd4B5TTSQtxi3BJfA8/D56A9/lfOAvcfvtfZR/0XVgbXwF5ieyDppB90JfJPugrZB80DYlIQq8i BSSD7Ia+RnZDP0J2Qz9KdkOzyW7o62Q39A2yG5pLdkM/RnZD3yS7oflkN/TjZDe0gOyGfoLshhbC mptCu9A0yKfJbmgx2Q39DNkN/SzZDS1Bv0S/Qp9D/wekjOyJ/inZE/082RP9AtkT3UP2RL9I9kS/ RGVRWaiK7Im+RfZEq8me6JfJnmgN2RN9m+yJ1pI90XfInmgd1UV1o3qqh+pBf0b2RBvJnuhXyZ7o 18huaDOs9B+iP6d+RP0ItZA90a+TPdFvkD3RfYZew7eQhfxLg+2GS4YfIRbW9QTiDUuGXyER1u8G jCWFvMj/AVcZ6DFzk7nN3GGWmFWQdeYBDLyRTWJT2HQ2iwjPKqzKelk/SJjtZfvZAXaQHWKH2REi uWwBW8SWsOVEKomuYetBN7EtrAUL5g39CeDNJ2O8SSHPx4yhYY7eBPZgrhhg/IuBPZgrRsKVRGDK W8AhvGf+HLCjBTiE+fE84UcS2Sd/AfolA5MwG5KBC+8DnzAPUoAFZ4BPmAGp6AcgrxAGpBEGvArz fw14i/fD/wTm/B+BYXjWXyOznkn2wD8CM7+MssgcZ1PJMMevk9nNIfP6BpnRXGofZUEfIzP6Jsyo A+VTOsxoAdnl/gR1BGaxkMziJ8ks7iJ72p+ifkhdQkWIMpWYyrfNR4HhJabgcWEPsAGmiCmJC5vH lMek8nFhI0wNUx8V9gjTxDSxR+HKY8IeZ08yLSAWEB4Le5ocFUaNC3uW8T4p7HlSg5fxxyQcFfYi 08v0spdB9z8p7FVmgBnckiFcNibDMRl5XKwj1lFmlBmLC7/GjMdk4nGxjjFT8WdZx5lZkCG48phw u5kNZg4EP28ei5jPmuG4SH5BhFt9snZmQqwmNUzER5ZZjop1gllj1qzDoDeeFOsU9G9zS+pZektM UXnKSF1np1kzm7olN9gMIrc+GIm4sAtsNpsXFzLjd9nCx2QFcI8tJlIKcj92/SFnAF2x1aN6xs/t ZKueFC6ZreXS2Aa2GQuXybZGhcth7XClnW3n8tn2bfVsCbeLWWbFLbGzWlyio8/Mw4wAv7kywt0a bg9XjTnG1eGR4BoxP7i9cNZGelvIsZxEWiSRvkZrwkyZJbM0ZZ2zzhM2LJLRXyYjvcI5YO0UwfiV MOWczgxzPhhlMxeE9h3m+oDLFu4Y8N3LnWBp7hRwub/9MHeGLYXn9gFPwlD2HHeBu8Rscle4a9wk tBjzv5+bIb20wIxdZ8LcTShRz93m7kBdeNWSHpGS0bWCZzfMNHFL0P5V6PM6XO+FciWw6nq5B3BW xLXxiCnnjXwSn8Kn81l8LlnLTVHhC/givF75Er4cpJKvgdWqRFcsX883kafBk/gWJsxb8JrkoWYo qfAq7+X9fJgZ4Htj6w+vwGG+n1eAa2bCtwy4O8DWsqX8IJvBD/HD/Ajbyo/C/MJscX38GD/OT8DI FbJV0KYBdpqf4meh9BzIPFvMjxEG4l6SucLlQIAxeJT4RcAyWwVruJ/fgOsavynQ/LxgEuDZQqqQ IWQLeUIhjLUkFGO+C6VChVAl1AoNmOMwsmTOhWYuH9hWKrTyitAOIgp2tgIL3NOEYuEA9KCWbYY7 AbZViGCegm4XjghHhePCST5XOM0sC2dZUTgPfLTjvgkXhcvwzHZgqIb7Z11jRq0bIguWYdy6CfMz D/2pAr70S7RkAiswLJnBUkzwA8KKlMqkM2Ptk0KDlCFl43UNnIHRkvKkQqmYH5ZKpQpgKLYcG2DN 8OgMW8esY9ESTL84I1VBXdjeEQaTklErAwyGumalWmZAamBGpGZmgqWh3Bi0Z01qhbNRoVVqZ8a5 MqFYLJNEyS5pxArGLJl0wEosq1BqnbXOSgEpAnZuMWrrpCPSUfI0eJJ0nFmWTmJrBnpNOimdls5K 58U0CSy60Bq1XMR2mazL0mXpCNsqXcUtEa7CPGHutArXhWnMn6hwfdDuCeEGtknCLZjjBbYBZucu 8KoQ7EGhsAJjfVq4x1YI94WHTL1oEMHuMItispjWPtk+KWbCDJ4G3qwxXjFHzBd3ibvFMnEP287P 43FnRtlSsVqsY9bERnEvvyi2werpBQMjsXZ4/jz4x7viHljBZrBZ7XDHIeqij80Qg+JhsU88xvhZ k3hCPCWeYWbFc+IF8RJrFq9ArWbxmjjJzEHN8+IMtMkMbbkp3hbviEviqrgObZyCuk3MGpR8YEVW I9NrTQJrkwJrqR54kw6/KQSulFqzgL8r1lxmRMwXVoQVrk9YYOb5WWuBtciaC+NAW0us5dZKfspa Y623NllbrBYrb61ha+Go8BtW1eqF0n6xT5i2hq29rGbttw5YB61DYp91mGNJNPXJf88w/w1lmCJy kLca0vD/JmMZRtR7NEq1nAY5C3Ie5CLIZcvlFhDLVcvVfXP75izXQaYt0+TaDZBbIPjaAshdEPjd 3tW9q5YVkHsWnMPS5nrzV+AZySSjQSSjoUkuk0BiXgPJZXaQLMZIYt5EksWYSBbzHMlcnieZSxKJ ec0k5n2RxLzJJGd5iWQrLyMqmU22kz6R9w4tuxFlqYNjGRwbDS/VnLFUPwtqa+F4DnDhD+BSFLWt UdRceUZcA0w+BTNR1GpwvPlsqA3A8XYMd2JYiuLt+eix9jjgJJyvAtafRO1ZOD74cNReBFyGelEM RkDSoyB9ewxvpzyG9H8BsgC5T0HBU+rFKHoMJc+Gehj3t8sBlX8ANVHU34zi7fpnRBOg5SmwRFEP 8/Y2/2yoh7l9W4lBjcEbRf1S9PjuAhxnAX5A+EnUAwfe7v1w1K/H6uiPYQAw+BiGnoLhxzDyL8Ao YOwpGAdMPAVTj2H22VB7F45zFrI+ngq4V7sCuBcrt/iMWAasPQVzsTofwnHj2fCOAY6bH6CW/gBb ZZJjxzRAJtwzffCs7XgnJ/Z884fjnf/P3plAV11d+/93f1MiwpViZAiBxlQRmQlIAXmglDF3YBCU IhVEpIhoU7SoyENAtJEiEgsWUYZSihgDIgIyBZAySZGpzCJNgSIFDAoRkJKbt/fn/IKRR9dbb731 X+u/1nsr63zvZp999tlnn332Oed3B+pKafT99lkp15TU6xRt21xe0+W1dfB6z/Xt+Vclq46UBtcp mVJaXqe0/X6JdCqXv8vn27J8GeSxSHTA1fwS6Tng+/mjLE7Kz2vg76s+6lPOtw9936arOaV8Dihb w8Ha0j2jLOa7Vb8mpi+Y+sggKUOlZJscoftLZJTh65gi46TkmPw6QOdL8mRkipTpZg+IzA7y+2UT 7xHxSVl+jsieFllsxhtZHvhBdGq+VJ0U1SvzGZG8GBHfRcSGiOo9Gfg38Ke2ZZ8s28OOlvOz6Ila RofWRWW/iFYM7Lp2nq6Zo6t7Stk85Zi9MVrF2BatXq79ZTMW/r042Pvk39HaAS+/XFl+nXLtvrzz OmVfuf213B57tRSVK9fsr1f3y//JPll7wPf3wnoDvtsDy+13V3OWlGj74FX2rWg8WGOSP6KyJ0Vl D4rK/hMdHPBlDev+wbrtZNZTVPaZ6HCTi6LPBusiWAdleVFjS/VoniM/la2RHJO3tP3VHHjt2rpm XZXll6trKyewf3ww5xO+a4+8rLeo7E3RN4zdUdmToroHHQlyko5B9qDowqDdf5WDrs3j15Mps/k6 +fhqXfJ35V/muv8qn6Z/v/ynPFk+V2aWy5Hl8iGy6YFMS+MDzdHdJH661TNFzzY633qm6dYk4Ems xDoIrXksOL90k7NR9EKQx2ROu2lsjTf5LKa+V38FZ4JuXYJcpvv/G0Ge0/iTPbqb6Osm+mJibzeJ m26ir5vEWTfVKTHWbXSQP8vy5cLgbFZ2bhr+XR5FV6ADG8ebfIld1+bha3Lw1TNMWR7WcaourZOY 6ja5XPsJwXhaGH9x5pKxdXsj4LUpV7pcp1x7FhxwnRL49dpz3dUyuly59lxXdkb7n5zNlgz4/vlr 3YDvzl3lz1gDgrYry/nk2rUl6y+6bcB/WlfR3QOunrGiuq6PmFx0NV8dN3EdPRXEUxlfZS4E8aev kldiwbqLyRqLhU0pv95iKSZHxFJNfMbqXOccIyXWICiZppAHVX/L4LXtd2tQ10RM9rpY93LrT+Ri 95v1FpM9OjZQyhCz95QV8lGe8ZOOOfaklKcD3TKO2MhgnIF8TO50sZelTJTy+gByUWyaFLnDxeZK yTP7nxbypJwJYoukLDP5OLbaxKnuhbH1UrZI2R74a4+UQ+aeEDth/BQ7Y+RjsnfELklJmDOg5v+y 3ByXPSBewRTVxz4jsR2vbPwelzNoPM3EWTzD+FHnMV43qGsU6GhucnlczohxOR/GNffIeSwu57C4 nKvicp6KDzL+jQ8N8piMP54dvI4w8RCXs1BczkBx2SPik76LH83deh6Iy1koLmeh+OyAH+TcuJwH 4vlGv66TuPgoLmeA+JpysVp2Dyjbo4SObzAy8a2Gp5/GqLS+0sb/+zTG/6ZnZW49d4O+o2pvtd63 rKR0KXWkNJCSKaWllLblXjtIyZLSXcr9UvpJGShliJQnpTwtZaSUMVJeljJRyutSpkmZKWWulLyg LJKyTMpqKeulbJGyXcoeKYekFEo5EfR55l+8npNyKSgqn7CsZNfwkytIqRzYdiZ4lTEkV5WSJiXD 8K++1pXSyNia3Py7MSe3lnKPlE5SokZPck/TX3IfKQ9JGRTwh0rJljLC6E0eJWWclBwpk6RMkTJd ymwp86TkB6+Ly72WyS+XsiZ4nR20W1OufoOUrVJ2Stkn5bCUo9+9qn+ST0op+m+8lvmi2Pjxv1uY g/Kluymqn/kqDGRPXlMum/92vuy1rH2Z3ht8KRWD+Rb+DVW+e72hupTa1vuRLpF4pFekb2RAZDBl WGR45NnI6Mj4yITI5MgbkbcjcyLzIwsjSyIrI+simyLbIrvl70DkSOR45FTkq8iFyJWoHU2OhqMp 0VRKerQO/24gf5nRllLaRjtEs6Ldo/dHJkf7ReZHB0aHRJ+kPB0dGR0TfTk6Mfp6dFp0ZnRuNC+6 SP69LLo6uj66Jbo9uid6KFoYPRE9Ez0XvRRNxNxYhVjlWNVYWiwjVjfWKNY81jp2T6xTLKr1wu8Z 6xN7KDYoNjSWHRsRGxUbR8mJTYpNuW6ZHpsdmxcZFssP/hbL3/Xo5fK3JrYhtlXoncHfvthhylH5 Oyl/RbHi2OW4FfcpFeNVZE+ocd1fXLCCX1xI5hcXKvCLCxX5xYUwv7hQmV9cqMIvLqTwiwtV+cWF avzWQo1weripVTPcLNzBahh+JDzEahceFv6l1TH8dPg5KxIeHX7B6hEeH37Jui+cG15l9Q4XhNdY Y8Jbwqetcfz6wrz/jy0LhaqEsvm8ykr93+QzMoMimSWjbVA6BCWrHK1FVk3G/QGtcv0CemBQhgRF sm6GZN0MyboZknUzXg5kJwbyynu93L+nBa8zgzK3XJ95wb8XWfWztsrfzqx9WYezjsrfSfBoVpH8 FWddjlgRP1LR/GVtjVSJVI/Ujtwm3HrCrx1pEmmRdTTSJtJe1iSrMqtY1mU8MkDm6iZ+acPiNzZs fmPDCWeGMy033DHcyfLCXcMxK4nf26gY7h8eKPPwWPhxq1Z4ePgpKz08MvzvVkZ4XPhFq054dXi1 VTe8NrzWujN8JnzGqvf/WHso8aD7E8G+Eh2hxI3QFaCbQjeFbuZ2EWzuPQ1/IPzfQU8UzPQ+gO4C bdo2he5O28aCjeA3d59Ej7bNRH8/t5mi96B+9skbKXSK217R+5XgYmRmab8l0CUF2DAO/uPQzaCb QTc31gY4EvwlMqKz5G9ufcHCYET1qX0Qqxip24pxPYblQ5R2DkAnU2vR6l04T9A2Aucm6Ha0fQZt N2FJO9BDpgUygwWbQDeBznRbwx8K3QIN8MFm1GZS+2P3bkXvcSxpjaTSzZxzyBg/TETbarTpXDR2 58M32BLsicwgdC5Dp3jD7qE92g29AYIvebK67RHQ7cAD3nDB0SoTssGpyGOnbSk6g5Gc6j0iOA+d P1BOaL/SofPU5iLfEfnXoFPQdh4sRP6y+2fh2+5GwZ7uHu1F6dBZOIPd/YJtVMa6oBjKAr8FCxQd B8mu6Omt8qFjaJgPvYDazsiXIl8P+gS4HlyK/Gn3FyIZ9f4k9CWNW9v31gqdUH5ooLdV8KgrkWCn qox12hsr+I1i6ETAEXQy0ZMKptH2UTAXrOaWUvuw0DsU7cPQq8Gd4FS3n86RfxpcBuaBOWCRYlJ1 6au5mUEkX/L1N1QGQrcDKwWYB+aA2rYakhuoXQTnAJzRcGabeVdacBmYB+aARaDKd0VyFK0sg96b GhXQU7F8HvRKcF7AyQNzwCKwg4xlnZdDFA1RpPf94Hna5ga4DMwDc0DVkIs3XlMZZxr4GjafBwvR U6g2h0572wSLwdPeDDAb7A8SCd4Z0VCN+bqEZCF4KsCxxMB6jQ04CTQk0JBAQ4KoOErtUThHA85K QYex3OptIGa2gdlgf3CXIpFQaGJMaYk01bYL+rSc6dUG4ditA5Sx2Js1Su00OGlw0ljdaapZcCO4 ksjMlzGONPGJ5slgbtBW18VTxHw1/Z+4pa8ZYDbYH9wIngFV52HaHsYbO9G2E3oq9KwA1XtbsbNH kmqrZNBEGvQ8g94qZjabedTa89Cn/X9TDxtUqyw4cqdVTIW/k5ndCWcxa6QOmE4Wakp+e8mvK/gC /C/IRcXQr+sOEvo7Oa2SyYcqGarg/VzwZrLZeLAa3liITAPWwl7oHuD8IAfK/hJCv52k6O/S2fd/ o97wyKXuAPWJv1xpv4HSzkliez5xkkn0bqPVcm+xtnUXYpXWDjX53NfMWV9R1uYe1tQe1pGujtuh c6n9ezDGp7BnMG3fQ/49/EyG8U6qfxQlVyua+Wroy/5oj0C+EvQG5EcH2SOPPJCjuwNrcDD8qeAP wNvpZT9YmtRFZzMpn361tqPOsqxcpVMCVJ13BTl5ptDVicldcNLBQ35NnV/y7Szi+QHy9hLNot5u YnKnSnp1ib1k5cjcaQynaD4PbTOrWO7KsiMwL7vVw5IHVhJjK1mVBjeyXlaCG9lBNFenalvx51pa jWUFjSUOtZdfqVVOV611upqs4spZJVSLNd6eVsv9i+QHlW+p1kokK+eErnSJ8L26s2B5ZpB/xiKp vcwFc8H1/h1K+6+ycrvpLsPKPUzt6gDNClW6l1+f2jNwzmC/eriFv0tzHdbO0N0w9Cl7YirWlsD/ AJ/Xgk5nLEf1pGR3d1X/djcseFJPj3YNRZmvsWQVnbXpjHGmrjWnKfvgnYpOuisc+xM0v4XkeTT/ Ffqv0J3Rv009L6ias7D5SUVrEfQp8AGvgqXnCtV/NzNVDw3bzf6r5yg5JzxM9tMIn8Dp5ZQ7lFFo vP2I2ulYvou+CtCWqiN1/6Le8PCJe5H5HaH7u1NVtTl7lXbvhu7EeIsYxUVyxUVWYip2ku3t1Wqh 05yx3xBYq5ZkQDdw5ewa2syoP3LlNBi6B9u20JZot1u7w3SN06qXnoHtXs6XglPcjqK5LfO4xB2k 8Wm/JfQetH0RoGqbhZ670JnpuoLHFCXqall6KhMPOEn44R1aDQcnEwMnXfXeQjTUBX+Hnjj0rxj7 DPzcnjEOpdUX4GHwMfWYnLJ0FOP01Cr0DRoV7EFPoG0gdvZCj++9oRkgiEYd3SrsuezfpuidB/eC BfAzwCzNCebMqZJ2E7C1t599ROlO5hSKnl3gZvRsRs9m9HyG/GDkByvHzobTBk7cnFqVti6oJYJ7 wQL4GdAqX8mcbOmlwCDnqK7o6apt7d7QvQ2tegQL4GeAteCkET+cN9B5DG3F4HxwAZjv6g7YGZ2d 0dkZnZ3R2RmdnfFSZ9Xs1FNJpx4eWI+G9dBLoZfqKMSrM7Ff8UMzXqXFtpnomUmr82hQTkvsvBjg VlaW2tDTa8xq1dkZ6+ppc11wO9BeNrr7WLPcDlTSMif545zta3AL6AJ+grYa6L8A7gPzadsH7ETb 5fC/ALe5EqV+ho7Lz1N0h6qMu91bISudvvzhnu5T/fBVNh74FvmwetXPY103xdpdxMkxcHJwT9nP 7GwiJvcza/vxDPGpq0w8UEdnyqsm+DZ3IhvJ2kjugh5P721MvDEX7yrHcZgpB35X5I+BF8H54CZO 8vP9E/SinFKdF5lfpU8EyFxDLzeRoxyJhCxmMIsZl3u0Nd75i9wr496Nir7cW0t26Eos2eHJLDtv cVLaqj5xW+m+4z6qtPMB+Fv48/U85s4iKyIvZ2M9F/2QthHORY8j+bHeN93NmqUd7o9Ob70vu5Wp /ZBWf1RMqgm/KhqugPnIDyBORutcOEvVt84R6M5gM0U3XefIzSA2cpBfS0QdVPTmItOMqEhVSecV ZvZL6KHU3kltdaKlAxrMXTUf7EJf7TgVzGIH7KQec46xg+SQGzewa2zS84kzmxPpJPagOZwPR8F5 iVNNEXrWgHvAveBB9BwHt4PPsDcdZJ9druh9DD0aXEF2vcAe9Gs9v7n1OcUdDOhlYB6YAxZprd68 vFP4vyuSFcFW/k8FzY2MG6KzIsA8MAdUDR8g+SytlipHUDndleM9RFT046z7DBgBszkZDuf82Yk7 KSdYtw7xs4q+kHRyNJe6cAR1FCfRfHuAy8A8MAcUbd6deif11xIzm72q0upGtM0GHwG5n7opjP05 6GUBLgPzwBxqdVzPqa/cAqWTavlvgn1UP63cANU/3BGcfPWD045T36gAZ4DZYH+QWNKTm1+Bef8Z kp00N3q3e5uFPut9LPgm/H0BZoP9wY1gY403ajfB2QTnFT3rOu/rCg39O2fp2uC/gc9wtkznHtSK s2sDTsWTiKhniNhJeg60O6H5Q+jnuL0uwbbP4X+uetwI9h9RjlszwBlgNtgf1PV1h1rl/lDvsP47 JuZ1RdjH0XYjOJsTwhjWUQrnh18S/29TezDAGWA22B/ciIz4071Ve/E+1ueKgiqzglYroFPwwAW8 dMjLYy3U1lqD3FhP6I3VPakcr0AtcZdBn4V2iRMX+VHeaWbBoN5ed+jtVbyhUbHdHYNtGrEW9Aos X0GtyaJtwRu9FEFL58ur4fcQeo7yvVuJ5M/B54JcqplnNbk0F5kJyL/LivuSdXQjGbUlGXg69CrN wBJX0spbx7xsQie3V+d1ND+BtvrQy/T+Kzdcrc1GcrVicoFGeLLFbet3aOaZSZLJ9n/mdpPDCj3F ClrK6rgL5HbsLEDDO2iz3Jek1Wr0fKS2uTyncrkRy1zoHvood+GnlBYNReAe1nURuIfVWgTuwdoP hX6VHpfjpSt6BnDeIjttBl1sW6V3ZPcP4NOKDk9OnK3+y7rfsYpzoZciP4u2r7LSc5TjD9Fs4D8O /2PkC8He4Gz/gmJSX93pkPmjRk5STeiqYDO0XUF+CjZX0N3BraLPqdzGXirxo7SttnlndPbdKqyd Uea+STzke1s0TpTvHgvu1PrEMo87TivWdWfdI5K6MHd7mam7lfYreJWk9hJ71gq9EUv0ak7ooLVJ XdhZZutqkny1EtxIXloJ6h6axXOk+vCPwD8C/yz84/APwu+Hts/pxdy8RrEz7gFXaL9eoY7I53ms s5gb9xz2uGkqb/9J79eS5frj4YvYrHmpld61/Uqs+iJW9xpF8eQ28kxjLFHcTu2NnItu1JOP5MMS 1sIMMobWjgZzguyhrfaTN9bqvVtkpsOfjv3kK/8FoZdhc0e3puDvFd10/L+IkX7G7IxA5oFAUjm1 uQd9omN0f6B3ZIenyo65tR3g1raFnPw8fkhj3htyL3uTaKnuSS7yk2l1kRPC+3of94a6crNwJ5Fj n6Ttk7SdCD1f+7J/TI8DmZdZ3PoHMaJfc8Pdw4pw4byqt3K3PnY+iPxX9IhV3njoUXo3d34BbWSe QEML8Gd6XpJzo67KFW413Rew8Avi3Nym7yUSOjP2xs5qGVdf1eM/DY5UdGe7C8icuiJ+orT3rPcs Vqk/eyFj3u8oIJt5Wus8pbuYF0JPZfy/Agv/qPdu5xD0Wb2tO02hO+tt3XmPsdyklnisIPcBt4Zw ZmL/GOes4AuORIJ7St/l8f/AmfBhva3L6NSemnpndyag86kA1YeVwAf0nu6tAH+q9wjnnzp2vyoe yOIOfpRWA/Se7twCvYbaYuz5BxYuhv8172Wkq2f8uvTeFuzPeIeBLYKzpe6qNWi1TW/u9l/05u78 Gv/U4PlhIRY+DGYxO68wjxGdNYleQXsBnDTsnM4tJhdsZ2huKLmstVxuOrl6q5JauYl4d3CiXofk i+BS7yXyodJhMGIQDRE0RNDQGcki7nr1lePWh7MfznRXZjxEW/s28GXuy/dxX76PW1gr7ndv6l1J IkHk7SFIHqTHqpw/G6KtobZ1O0CPNQhnrGoTLICfAdZiZxfPeLsY3VBXboXO2+hshX4zurbg83r3 FPsZBTrro7M+Iy1ipEXqK/cB1ex38HaDL2oUoWGRQfwzELoLfmjnR/GVYjfu74f0/i6jiOqzL3cX /UZZQZ+h4TzaorpbqVWSeRTfcm8XfMgdJ/xnyajcl+V+rbWvgGlw2rrjhc521baGcMi3bi3m4kvw a0Vnq6K3XdFtCI7Vtl4jerkFnV3B1uBctOUYX6HhLFgXDz8HPqEZL2mzeiA5jj8vce97nKf0Tyid 5LPrPay13h14eCuSHaAfVTpps2pLjuvJxEtwH2zFuExstGSWOzAvb0OnoKENMu/p8wFngPrfTWUW FhEbt+ou5pzQ0TkLoCtDj0bmCNiQVhlgCrNZVdt6c3TGvbnwmyH5DrP8itL2l3Ba+S3AKRpvSNbQ 2ZQ4eYkcqLgTnfnQt2NzCj58XvkieQlrL7FCeae+9F0rZDmln0Av0PeywczSd6DvBHP0XfKg9l1w DvIjoQ1WB3Phm7YLoReiLR/8HM7n0AeQEb7do1SfiDYEXwJHgO3AA+BoxZCtaBXDyQQtRWcw9FRw HviDgNZ3DfbT9jycXLAjrV6DTqG2ELwMh17snnDOQhv9bej9AniQ2m/BArQ5yHQFe8M/FtBqw3w4 C+B0hi6lVT3oE+B6cCl4Gsko9CVoHzoBVgePJurpyRB7kLe+UY5jPJMGpionxKhDD4A74B+GXg3u RMZ4r0fiXtHQ3MyF0nY7cCY428wCdCZogVPBeQk9na4z/ldO6H3wPLWfonmaGR10NeN5ZBLI3GrG AqcQq05A7wrGci/jSpa2I2k7SjkW/gm9gGRmIs4opmP5dKydjm2KuXDOg6fh3KpoGToNTAWP02Md MB1sCn5BXyYCX4f+O5iaaC/YC/pmZna8iUnl2wuhGyT09r0XujV8osJOUvSJNP8ZRXcFGkrUA/4T Sntbmet5xjOlb+m7jcj/xsQG2l7HhovIfIuveuiqlDVVnfhXnGxmueScrjhGOiJAG0wXrAa2A0dT Oxpto5Uj/lR+J/iZoBVguu4L0FMDVMk43t4feD6dWZgJKt1R+c5r1BbT6i4sNBFezIjwf+iQmRFG OsvEM/QgZJbgpd0me6iv3D14zKzfFOg0PLMe+fWJe/SpFPQI9PwKeoaiwyp2uhKBl/BbLrXMZqgW /NPqw9AVbPbxXiojSsZLCUWJK0PrGPFV6DegicOHA0yn7Uz0qPwOdO6m9l0Qf1pfMepT4Azw09Kb BUsYYwU4H0DXgk5n1rpDb8fyk9TWUFoyxnzh3EPtU+B0amfiAaLdaQptVnqqesy+E75ZEZ+Ab6H5 UTQ8iuZ9gZeUNpltG+t6A6v1C2aBrBJy8fzd6DGZcDv4j9Jm6knorSYHIjkByR+ZHEgvu+Cz+twx rJ3N0BdLO4udZh+ZQ7bZq75y74buBL8IPRehyYT2DWB9MMOsWWQ2gx8F2ekuQXaK0BZklpgVDZIB 7Cl4qS0ye0CTN4hbm31BvCp3Coe1H3oHHA6aXFEX/B34K/hPQ7cHhxKBz8F/N9gLNJ7HBbR6wOwd /ZAnh9gDzZ7CbPr4vzqYC+4AV4Pk89AHzFcp9CrwMm13mvmCxpOhs9CDwTheugBdidoC6K5g78QF tRD+MXROBheA+cH6NX1p5G8m8i+wInqDneGvh26J/Fi0se+ENtJ7gthgZwyRyZ0aSBYQLdChC2Tj fdD58PtAm7zK7Pt5RFRl8EUyDOcTvzbaTEbqjbVLS9/W95jQUJr4DeMVDG0CL5OHe5JJFoAPIXmZ PFyRsZh9KiXIq+nEtmaGNnDa4L02ZJUL8Cvhh4IANfc6SHYNUDXMp3ZBgOnsO8PwYTp2al5Kp3Yb uJS23XnGWMwz/DSeNKb5H4pkxeDTNfrplJZ8JqeEZ8t36qccQzsU7Tze/93I3ZMnVKG/u/rJnHXc yHi3xe7g36grnXdwtittfwx9zj3AXZX3vPR8bvW16+i86BMJp577mPbu/kHPGErbRe7XGo2Kzjl3 nqXPl0TSOqwYGkKrLopeHs80fLCRO0rXJhrmu3Ludfqh4YrW+r1o1RNszucTLoHJbqrOuPO8eszZ oDJK22P0Gy72MEUn2zmCNpG0tiiGMkwrOLsV3TOKMgrFOc6rOgr0dNCnCvYmo4faPoreODRcAo+A E8DFjj7Pqador3b0dp+u93r7EpwqXl/s1E+RVVSOtVtp67CiyCu9ReW9NuhJp1UTRz+/V8eZprPv zMG2fH2mTavFYGs4dVXeW0Or44ElWtsHzkxnpGYb+G0D1M8RuYG2OeolbFumdKgQexw7pOgV66/e QNu2rZzQGmr1E8jNQkf5xKx+qq27PUGwoT51sVfbr2nWtX+tltt/1HWttP2y/bLgaFvf3bZVPpQL 9lR0Hkdmqs1nHe3Jgo2dVwQ/gG7gvIMeoUPnkaSt3ZG2r0HfjLbzGqWhv9L7ZftmXcu2RkUfuzp2 Vtb4t3mX3/aFc699k65l+w5dyyofioM9FK1vFB0HDV3Q1tuuoTnT3oFOpS/Yx3TXgM5HMoqGBG1/ CH0C/DikHl6CDadCPxLJRiF9wil5UThXQvouc0moWPcCu4nmVXsM79rrL8ueDhWqPYqhe+2qyrGX 684V+rvuuWAa2EhRtAlax6Ang1VCR5A8oisd+nBopO4m6NwRmis4JfSZ7kdqifUFGr5RS+wrlqWf Qne/UvRToP8GXYlPp98I/WP478MRPe7vfdHp9gU7gGcUnZPgAkWvIvwrirYLvgqnLjI/U/T3I1kP jFKbAT0Qug+SJ+DAdycoJtWGvoPatWAxHHpx/gz9KPQYsDucceCziiGstdtS+wl0Ifb4yOSCedRu hP4A+kuwG/hT+IzIKaGt0bYNfBF8DNyLZHNoxuX8kx5/Cb0Be/aBp+D8AW2DaNUSya3wb4VeCD0D nyyHfgacBd5Jq98nye7j1zSzo7R7Biw1c6S0VxHOFeh7zBzBed3MlNLOz8CBYDbaHjLzRaskM2vQ +MQ/a2YN+QXgCWozFJNqw1mLbY2RnAgONf6h959g4TrjE+XInqi08Rh+dueAbegRb4e+phZP2qvR QNR5U8BNyM8Gd4MxkFG7JtJmYOdo5G9HAz73wthA/Nh1iL0bkD+OzHvQ7ZA0MdYeDCsmv6dtk2/B TgeZzmj4CEyBX5NR18UzW5GfSi1rxN1Dq9voC986U8y6w4f7aYtv3QngHej5EJkm6Mef9r20XQKf VeaZWB1CX2Yl1jaxh55PoZG0X6HVaWR+C5oIwXvOcBPJ9HsrvlqoGPoazlv0ZeLwLvBusAdtd0I3 Q0Mm+AX4LfyX6esR6PvQw7g8evdaIDkJPdOg8bxNfnDngiPA3siYHv8CmghZRe3jIPPi1KDHX4B4 PgmOe54eR8I3OY016JrVzcr1boJTBSQzOESFgzbbZCqyiv0V8rR1nwbfBefDN7kR2tkBZzP0EXon rhzWjn2OVkSdZ1aTGVEBMhWQfxuOmfc18HuCqSA2O+RMPwedxiqiwv0MZE25xEYIy/0XaPU88peh WYnuKPAAfObUwf9eP/jkKJes5RIPNlndHQyuRL6YmBlD/Jh8lQeSizzWkfMiHJM5i2hr5pR5d5gp n1hyHgRZa85kkOhN2q6YTFR47F8e0e7j7STG7lPrIu+Qo5xWYDft3bL0DuL+PqHvFvUFO4BnFJ2T 4AJFryL8K4q2C74Kpy4yP1P09yNZD4xSmwE9ELoPkifgwHcnKCbVhr6D2rVgMRx6cf4M/Sj0GLA7 nHHgs4ohrLXbUvsJdCH2+MjkgnnUboT+APpLsBv4U/iMyCmhrdG2DXwRfAzci2RzaMbl/JMefwm9 AXv2gafg/AFtg2jVEsmt8G+FXgg9A58sh34GnAXeSduatC1F5h7o16nNhn4IfhLIWPyzYGNqJ4JD wZ/Qah39pmGhsZzxunPANrRl1KGvqWVE9mraMvveFHAT8rPB3WAMNBaaGTfjGg3ejgbG7oXRyTza dYiBG5A/jsx70O2QNHPdHqRVMrXJt2Cng0xnNHwEplA7FZrIdPcgcxua8YyD/c6H1DZBD56x74W/ BD7R65kYGII2E+EmVj+Fj4z9CpzT1P4WZHZs/OAMB99Cm5nHu8C7wR7U7oRuRqtM8AvwW/gvo/MR 6PvQg+UevXgtkJyEnmnQ+MpmZblzwRFgb2RMj38BzZyuovZxEE86NejxFyDeS4LjnqfHkfBNNiB6 XbMuiHnvJjhVQNaUwzw6aLPNGmc92l8hT1v3afBdcD58k1WgnR1wNkMfoXciwSHC7XO0Ik48E/Nm RAXIVED+bThmZtfA7wmmgtjskG38HHQaq5h39zOQVeAy+yEs91+g1fPIX4Zm7bijwAPwmVMH/3v9 4LO6XSLBJhO6g8GVyBDVrskkRdBmpphNB//7RIjzIEjMO5NBYi9pO/HPXHvkc49Y9fFhEiPyqXWR d8gPTitF6zP7oKVPRbZL7W3mOYYzSThduHcP1qcNzhyeJHSldqZ+N9ZJ18+nOdN4lmIrx/4H/EnK 1w9YWPptC+X0U/R2K7qN4BfTNpvak4r+cOjBYBe0FRlJ+u0TPM24zdJnFHo3nAnnpeCJRyO+W6dP UbJ4fnKZ5yEpPBvJhz9X29o74Qym9g1oGw1F4AhwPmOvqGiPwQO99AmJvYmnFs2hmzsfaVuVsUp5 XnFz8PxE0PqbyniZ6OlJqw48IWmtnNDN7tvCrxo8G8nnGUg+z0MEE6+X6nOq7qXbNfdC99G7rb1T 6VBH6L7UdoAugD6A5CjoZOjW1P6JVqfgVDHa4BxN6E2/ATJVaNUEHEjtPoPUpkJfpvZNNNwG/4/w W0DXo9aH/jn0r40NSocOGhuofVbpRM/SCxIJdeAstmoIHoKeqbRzE3f5UkWnLXgOzmXoaUj+VdHb reiG4NtgPrXJiqFi6CKwCfIWMpPAeuB4akdgwxTogdDz6fE0MiOht1A7DD0V0L8enBtYrpYMhbMc zmpwAshInS7UhuGMSazif2FXzWsS+iQwHc1PBjYo/7DOkdNW0TpM24XgZLTxxMM+DqeXyrh1EvpZ tXbU3pt4RzBhRYVfGZmmyrG/MjajeY7a4NeCU6B0aDL8nokPND5V3t1A7T6tlbHr7FREc0/41dH5 GvbXLL0sdo7D2m+w7ZC28rIZywn4s4m60doq1IK+RkJnoKdJ4grvIFxRf4ITFOU0pVgIJw2ZE9BV FJ2fYFVzZm0TfT2L5sFYWKjou/i2romQ0t4adSpjV1GO/v6OZEhWmVtZx+JXR/6E0l4nZCrC6Wvi EG+n0UtFPFNFPRZ6mVH3Seiz2WFYOB+6QuIBjbGEPu28GYzT+ya80RF6oEqGimnVBPoCkpvQMBl6 Ivx9eGMb/DpwzlObC+cQ2nLhtEPyrKJkHObLxCH2RxnL37ChkEgwkTxFRy23gCN4iXkHxzBTxcgn 0NCIvlpT24T4KYTfUlHyu85L10BG8TgxsBvNO43/A2+o5R0YSyG+qgq/EtgHyWFBv1dYF1eIvXNE gpFUv9VWWmL7HJGsMg+Bk+E8gGQqfaUiuZ1Wm5CZDi6nNh6s30wZi4/NSxjjp/DTwLXYM8RIMt4n zahVUqKIp9ZElB94dQ5RjTfUM6EhaH6DPLAG760P+lI9mcxUVZOpaFVEq/VIJoj2JkguITJTlPYz rJuItFXMuNr/tlnRwRpRbf2Yo9vAAVh4Jsh4NdhrtJdtwZqdJrWLzFpWbZIt38CqTFqZvKqax/OU uMgaRFwN0j29tIfQ9xN1p5AhDzhmHU2kbdz+M5G/itnUMa4zuRHJF+D3wvNTFCUvrSJXaFYxMzIf TKY2nVG3Z7xHwEngFTR3YL7uATPArEBGs9zoYB41s/1Wc6bEwypW0ztExRXeyb1CrF4hnq8wF0pf wm9jgl2sBhwd9XRG2sbsYuScImZntWISUZTELuOcRHIQyB5nfaVxKGfgz8mB58iBmmF6YWdrorQJ MbyTqCYXieQcJFX+ffjDkOwCHYE/F8v3QefD75TYA2az+s7pmVx7SUwrPcp89dTVypzGGFeG2dcS f+L9+lvUWiwfx1jSkeyZ4MxD2zSrtuhMDWZW6JIFqtmy+J03y9Xv6QRPGhWtCvArKN+ylJN4UD9l neirn4RP8H2QRAXoptBNoZvp57QTzfWz9MLPhp8H3V8/P6afzBd6I3QR9Bml9Vs80nal/soN/Ob6 aUDR8x6/zfINv2+zWlG/R2BZ+j33RIp+myORot8HSSz2h+mv3CSN1V+5UbqkQOnEOP81/ZWbpK9U v39cMeks9GeqP+kk9D+hjUwPsBmSD4OD9Hdv1LaSQmOz/zvk50CbVqewuRj+bfArKybdw+gagWcZ 73hql4BJ8H+MZHv6OgN/Kzoz4bTGM4ZzmdoHkZ9Aj1vx0mXwBXq/F8n6tFXJJtBNoDP9LfAvQddH j+HXwZL7oe+E/il69ismJ0HzSz7JydQ+COcVtK3Q38BBw4/R0BS6KXQz/b68yO+CrgreQquO2JyJ zQOZ5RmM9Btqsc2fB6c/uBEspraaYOOk96EXoXMN9ERkPgR/C38J9G7o82qh/gqHWKtx2Iz35Z2S Umj8pu+kJ5qW/EPtKWEu9J134ZzT2pIC9aThJF4A00FaoaFpyQYkaVvCqEtmQB9H55+g90EXUUtE lRyE8wV69BM4llUhlJN8ynIeeW74MCvl58MffdwaPezhp5+0Flty87uvZ/t0S24WpaXWLVZFy7fS rB9ZVf6Dve+AsqJo2q7unrl978zc2mXZXZYlSM45rCTJGSSJJAElB5cgLKBIUAQJoiICkpMkEVEQ AVGQHJQkOYPknHP8a2pH3F3xE/V9v/Of//f0OU9135nbt/vp6qrqnrkzkAcKQ1EoDVWhPjShOmrD m/A2tIB20Am6wUDv/CBoSAOZIDnkhRiqpQxUgwbQlH61DvSCfmQ52kNn6A6D+B2D8d9B8JPNyAzh kA+eheJQlqxzQ3gZJLwAveEdaAWvwmvQAwZDJKgqtWpVhqp1aj6fDprXrVMtHYzmWlLwM0OfIduc hWrMDyWgHFSC56ERvAIKckBd6AP9oTXEQhd4HYbwdwKQDrKC6+meg/JQA3LCe/x5FIQSD+khGrJR vQWhCJSEClAZasJL0IzanQtehL4wANpAB+gKb8BQrwXJwIYMkAqyUw2FoBRUhCpQCxpDczAhN9SD t+BdaAsdIQ56us8ybVGgawtVj7EpY2vGjozdGfu0aBYbp95lHMY4lnEa41zGxS2adW2lVjKuZ9zM uINxH+ORFi06dFYnGa+7aEjGUMa0jLkYi7WMbdfGqMhYnbFOy46dOhgNGJsytmRsz9iZsTtjr9Zd mrUw+jEOZRzFOJlxNuMCxmVUcTNjPeNmxh2M+2I7dutgHGE8yXie8SrjbcaHLppGbKcWsabFGMoY xZiWDnYxMzHmYMzHGMNYgrEsY+VObj01GOsyNmJ8hbE1Yyxjl05dWnY0X2fsw9i/s/v5EMZhjKMY xzNOZZzFOLcrjZG5gHEJ40rG9YybGXd1bdextXmA8SjjacaLjNcZ73bt0KKzDxgtxnDGtIzZGAt0 7Zovv68EY3nG6ox1GRsztiQs4ItljGPsxdifcSjjCMKCvvGM0xjnMC5g/J5xNWEh30bGbYx7GA8x Hmc827Vb866+y4w3Ge+7qCWjnxG7duvcVYczRjOmY8zCmIuxQBwxqYswlmQsz1iVsRZjPUY3Gpdk e8L/glQ0z1NB6r+VE/zg0P8ZTbIYJllRDf7/WMngUnxekNVLisGnREV2zuZnLv+TnCDr/WQMe2qU PCKSanVLvNvj+gc3SnxqTPbUmOZ3GPrUmI5bqliKBOj2IOFn+KeoyFNFQtRfzKXgnCT/lOEvyYyQ 6S/JzJDlL0hBnvTP8c85EeTB/xxDngrzU7QRR15/BEyDBbAadsBxuC4MES4yiUKivKgrWoo40V+M ENPEArFa7BDHxXVpyLSyuuwph8ixcrZcIn+U++RZeVdZKlrlUMVUVdVItVc91RA1Vs2mOej+lj9e Z1WNJOXmScpDk5Q/SFA2khz30TTfA1okKFuFEpedqYm/jzcT1x/eKHE5AhLXHxGepJwlyfmVk5Qb Jykn6U/EvsTlyGxJyrWSlF9P3P7UkxMfT/N94nLmXEnKeRKUaf5lzpfkeD8uS7IPYfE9zForXmaL 77lBOhdJtiqL9+lWT+7z5HFPXn7S2Tnme/J7T6715LbErciJiXuZc0nict5+ic/PeyBxOf/GxOUC C5OUFycuF6ybpFwvSblzknKXJOVRCbSMMjGjk5SXJD4/Jsko/e745iTlrUnK2xKPYtHNhEjMtBAj obUYz9a2OSWgmToChBlqJmNfEQY+pwqudSrjalyOK+kTn7ggLtB5l8VlEOKquApS3BA3QGEZLAMG lsNy5DddfZCqgqrs/p4MkxH0ifsPInTbo4L0zTxUjqTVSBcYD2vhCNwV4dQGP7Uq3KkN0qns1CGs 4rxAWJVaH0o2OR2tFvLRmqcEngYlQ6lNZ1iuRVppyQgqn2O5FneBpNIewrW4j3A99dXV0GjIgEeo rcvp6C8s1+JRkiupfIzl2gRnHvfOPOGdedI785R35q/trcbtrc7tfZ7b++uRGnykJh+plfAI/sgt 3Mgt3Mwt/PXIVj6yjY/s4CMStKRE08yW7p3boTKUWI0gVpVT0alErC/H5eCjNq0kphSd4V6NjPf6 NLXo+814vIBHSoi74i6N2iPxiNgyJcU9XK/J9fq4Xi2jZTT4ZQaZAQIym8wGlqpMo2mbzc3m4Jgt zZYQNFubrQHNtmZbCDG7mF0g1Iwz4yCZ2d3sDmGYDtNBcsyAGahPmTATRGAWzAKRmA1pzYc5MAdE YS7MBSkxD+aBaMyH+fi53AUhNRbGwpAGn8VnIS0WxaLwDBbH4pAOn8PnID2WwlI0Oq6+ZWR9y4SV sBJkxibYBLJgC2wBWbEVtoJs2AbbQHaMxVjIgR2xIxmKztgZcmEcxkFu7I7dIQ++jq9DXuyDfSAf voVvQX7sj/2hAA7EgVAQB+NgKIRDcSgUxg/wA4jBj/AjeBY/xo+hCI7EkVAUP8FPoBiOwTFQHMfh ONLPCTgBnsNJOAlK4hScAqXwU/wUSuN0nA5lcCbOhLL4GX4G5fBz/BzK4xf4BVTAr/ArqIjzcT5U wgW4ACrjQlwIVXAxLoaquASXQDVcikuhOo/38zzeNUhXVkNN0pW1UAvXk7bUxh9Ju+rgRtKuF3Az aVdd3Epa9SJuI62qhztIq+rjLpojDXAPzZGGuI/mSCM8hIfgJX4mdmO8hJegCV7BK9AUr+E1eBlv 4A1wn/Pdj+ZHP9KkEBECfUW0SANv8ZtR+4tGojEMELGiAwzit6EOEa+JOHhPDBFD4EMxWoyBYeKK uALDxU1xEz4W98Q9GOEaGRgpfdIHo6QjHfhEJpPJYLSMlJEwRqaSqWCszCgzwjiZXWaH8TKfrAUT ZJzsBstkD9kDllMc0RNWyN6yD6yU/WV/WC0HyoGwRo6QI2Ct/ER+AuvkNLkb1qsg2Z/7qpAqBA9V WVUeHqkqqoqQaoKaIJQRZ0wRhtnCbCEKmK3MVqKg2cZsIwqZ7cx2orDZ1ewqYsxuZjfxrNnD7CGK mNt9g0RR6wWrmbhkDbSFeOiEOhXkG85LzkT5ZbBlsL28FuwbHCrvokS/8mN6TK9CMCNmVKGYGTOr ZJgVs6owzI7ZVXLMiTlVOObG3CoC82JeFYn5Mb9KgYWwkIrCGIxRKbEIFlHRWAyLqVRYAkuo1FgS S6o0WBpLq7RYFsuqZ7A8llfpsDJWVumxKTZVGdyXU6uM2Bpbq0zYFtuqzNgBO6gs2Ak7qaz4Gr6m smE37KayYw/soXLgG/iGyol9sa/KhW/j2yo3DsABKg8OwkEqLw7BISofvo/vq/z4IX6oCuBwHK4K 4ggcoQrhKBylCuNoHK1icCyOVc/ieByviuBEnKiK4mScrIrhVJyqiuM0nKZK4AycoZ7DWThLlcTZ OFuVwjk4R5XGuThXlcF5OE+Vxa/xa1UOv8FvVHlchItUBfwWv1UV8Tv8TlXCZbhMVcYVuEJVwVW4 SlXFNbhGVcN1uE5Vxw24QT2PP+FPqgZuwk2qJm7BLaoW/ow/q9q4HberOrgTd6oXcDfuVnVxL+5V L+J+3K/q4WE8rOrjBbygGuBlvKwa4lW8qhrhdbyuXsKbeEs19tZSbuRTiG1tdlJnUzQRTejjVqIV CGORsQik74HvASh/SX9Jmj3/GWtMmvuvNf7/3Br/pn3RrH053GhLtPPt/1fH/tWx/5COCbM9xfOh IoMspCoaDSA1FIOyUBXqQCNaL7Sn+L0nxQNDYDiMhakwG+bDElgJP8I22AdH4SxcpcgehE84gddB BboG4gJvsOwW6Mmye+BNlj0CvUnGUa4Py7hAX5bdAm+x7B54m2WPwDsku9F5/VnGBQaw7BZ4l2X3 wECWPQKDSXan84awjAu8x7JbYCjL7oH3WfYIfEiyB503jGVc4COW3QLDWXYPfMyyR6AXSDraj7Bb YBBh98AHhD3+ASMjueddA6M8Zj7xmBntMTPGY2asx8w4j5HxHiMTPEYmeYxM9hiZ4jEy1WPkU4+R 6R4jMzxGZnqMzPIY+cxj5HOPkTkeI194jMz1GPnSY2QE9b9rYCIzMo0Zmf0PGZnnMTLfY+Rrj5EF HiPfeIws8hhZ7OnKtx4zSzxmvvOY+d5jZqnHzDKPkR88RlZ4jKz0GFnlMbLaY2SNx8g6j5H1HiMb PEZ+9Bj5yWPkK2ZkIWvKcmZk7T9kZJPHyGaPkS0eI1s9Rn72GNnuMbLDY2Snx8guj5HdHiN7PUb2 eYzs93TlgMfMQY+ZQx4zhz1mjnjM/OIxcsxj5LjHyAmPkZMeI6c8RjYyI9uYkT2sKUf/ISNnPEbO eoyc8xg57zFywWPkksfIZY+RKx4jVz1GrnmM3PAYuekxcstj5LbHyB2PkXseI/c9Rh54jDz0dOVR PDMWxDNjiXhmLBnPjKU8Zk4zIxeZkevMyF1XU9z3NLrt5t20BpBdbJOTVHVVU7VWbVR79arqqrqp HuoN1VsNUoPVEPWeGqrep7XLUXVMHVcn1El1Sp1WZ9RZdU6dVxfURXVJXVZX1FV1TV1XN4Ix7nuU xFaxlX5govvvXFVNVQOpaqgaoFRL1QoM1Va1A5/qorqAX8WpOAio7qo7RQKvq9fBVr1UL3BUH/UO BNU4NQ6SqyVqE4QHCwcL8y5DNFhGWuMZI52R3shgZDQyGZmNLEZWt2fUohu8uy4gKsHeRE7eD4p1 z6BvZvXOSJ3gjFwJjhGTKpbOBiPccJ8Fls3IBrb3u+FGhBFppDCijJRGtPvsOzrjt9+VkAlCjDAj uWEaPkMbfiNgWIZtOEbQQCPECDXc/S6D+taXmuB+RxrPGSXBMcoYZQDpWAxEqRlqlpqjvlSr1Rq1 Vq1T69UG9aP6SW1Um57EuLtbpqar6VTjTPd/zepz9TnxPVeRHSXmVtHvHVXnHtc+nc76nI4uUd+p 79VStUz9oJarFWqlWvWkMebaZ6gZVPssNcu9I1PNodq/VGSdqYWbqHa3H27teSD8ibU+oR/M2VGP M/d7T6ld/D1XG+h7Zke5AN6B/jAA3oWBMAgG07x+D4by20U/hGHwEc3yj2EEjIRR8AmMhjE058fB eJgAE2ESTIYpZAE+hWkwHWbATJgFn5E9+BzmwBcwF76Er2AeWYevYQF8AwthESyGb8lWfAffw1JY Bj/AclhBlmMVrIY1sBbWwXrYQHbkJ9gIm2AzbIGt8DNZle2wA3bCLtgNe2Av2Zj9cAAOwiE4DEfg F7I4x+A4nICTcApOwxmyP+fgPFyAi3AJLsMVskbX4DrcgJtwC27DHbgL9+A+PICH8IgUWsjaso58 QdaVL8p6sr5sIBvKRvIl2Vg2kU3ly/IV2Uw2ly1kS9lKtpZtZFvZTraXr8pY2UF2lJ1kZ/manCz3 yL1yn9wvD8iD8pA8LI/IX+RReUwelyfkSXlKnpZn5Fl5Tp5XlrwgLypbXpKX5RV5VV6T1+UNeVPe krflHXlX3pP35QP5UD4iE+Teba+UoUzlU1r5VUDVVnXUC6quaqyaqFdUM9VBvab6qwHqXTVQfazG qPHqKzVPfa0WqMXqW7VZbVFb1c9qm9qudqidapfarfaovWqf2q8OqIPqkDqsjqhfjOJGCfe9rcYO Y6exy9ht7DH2GvuM/cYB46BxyDhsHDF+MY4ax4zjxgnjpHHKOG2cMc4a54zzxgXjonHJuGxcMa4a 14zrxg3jpnHLuG3cMe4a94z7xgPjofHIDJphuowuq8vp8rqCrqgr6cq6iq6qq+nq+nldQ9fUtXRt XUe/oOvqF3U9XV830A11I/2Sbqyb6Kb6Zf2Kbqab6xaUWlFqQ6mdbq9f1bG6g+6oO+nO+jXdRXfV cbqb7q576Nf1G7onpV66t+6j++q39Nu6n35H99cD9Lt6oB6kB+sh+j09VL+vP9Af6mH6Iz1cf6xH 6JF6lP5Ej9Zj9Fg9To/XE/REPUlP1lP0VP2pnqY/13P0F3qu/lJ/pefp+fprvUB/oxe6737V3+ol +jv9vV6ql+kf9HK9Qq/Uq/RqvUav1ev0er1B/6h/0hv1Jr1Zb9Fb9c96m96ud+idepferffovXqf 3q8P6IP6kD6sj+hf9FF9TB/XJ/RJfUqf1mf0WX1On9cX9EV9SV/WV/RVfVvf0Xf1PX1fP9AP9SM/ +IWermfomXqW/kzP1tf0dX1D39S3rNetN6ye1ptWL6u31cfqa71lvW31s96x+lsDrHftN+1edm+7 j93Xfst+2+5nv2P3t9+1B9qD7MH2EPs9e6j9vv2B/aE9zB5rj7PH2xPsifYke7I9xZ5qf2pPs6fb M+yZ9iz7M3u2/bn9hT3X/tL+yp5nz7e/thfY39g/2MvtFfZKe5W92l5jr7V/tH+yN9mb7S32Vvtn e5u93d5h77R32XvsX+xj9gn7lH3GPmdfsq/Y1+zr9g37pn3Lvm3fse/a9+z79kP7kQOOcKSjHMMx HZ9zzDnunHBOOqec084Z56xzzjnvXHAuOpecy84V56pzzbnu3HBuOrec284d565zz7nvPHAeOo+C EBRBGVRBI2gGfUEd9AcDQStoB51gMIjBkGBoMFkwLJg8GB6MCEYGUwSjgimD0cFUwdTBNMG0wWeC 6YLpgxmCGYOZgpmDWYLjguODE4ITg5OCk4NTglODnwanBacHZwRnBmfx1WfekeWd0b5ykiQLyvud U1RV8u871fPk33erRuol2KuaqpdhP/vQg6qz6gyHyOO9DYfVcDUcjqnRajQcZ89+gv3WSfZbp9hv nWa/dUYtVIvgLHuI80ZRo5gA3jeVpmVaIp8ZaoaK/LwzWsD3i++kOK3z6ULiIu+SXrMGWuOktKZb P8gU1gbrtizAe6XNeZd0Bnn7qxCg6CAD+fwaFAGNJQ+wjKwz/YQ9ACRu4NwczrnXaEIhElLb66i8 215PuNfeQLjf3vj43N2UWwF+iiWiIC1FADnirx7Ze93P7f2EP9kHCTfZhwm32Bfcb2KEWyNGujVi CrdGrusB1/rrNZoAldagRbgO7URHQvhIKB9JluhIFB9JyUei+YiEAI1aPhq7ItJ9W1JxWRykrCgr gpJVZBUwZE1ZE0zrY+tj8FmLrEWgrcvWZapPmrPkz/8lH5vYw/6/7V//dzys60Of1m/+N31mmG6p W+u2+k3yQK7nrEA+szp7s9rkmT5gP9mAfKTrHeN9Y6un9Iq9/sQf/t4bjiE/+JsHTOhd/m/zho+9 HfnF0eS/E3rFMhR9uLFHfOThxh21KPK448Ud9yjqaEgRx0SOOSZRxHGXtLYeaerLrl7+6jtlh8R+ 0wl1kjlhTnIn3IlwIp0UTpST0ol2UjmpnTROWucZJ52T3sngZHQyOZmdLE5WJ5uT3cnxRG874Mn+ FgNoof1UXnfO7/0uhmAoJvud911nr7c3sA/e+EQvvJv88F57v33QPvyrP8ZITME++cIfeuUHv/fL GIUpMfpveedEvtl58L/gnWsIKSJoKRstskG4qCXqQka+UppNNBWtIKdoI9pAQdFOtINC4lXRAQqL TqInFBG9xEgoL8aKCdBUfCO2QHPZRcZBb9ld9oa3ZF/5NgyS78iB8J4cLN+HYfJDORxG8jXPMXKU JGvPa/yJylFhMEmFq3CYoSJVDpipcqm88L3Kr8rDcvb4O9jj7+TV2y5jqrEFzprJzGQiyrxp3hQp zdvmbRFt3jXvilQ+okuk9g32vS/S+D70fSwy+Eb6RousvrG+CSKnb5Jvtsjrm+NbIIr7FvrWivK+ 9b6t4kXfLt8u0dS317dfvOw76DssmlNs8EC08j2i2KCfjtHFxWL9nC4llvmz+3OIFf5c/rxilT+/ P79Y54/xx4j1/qL+omKDe/1M/Ogv7S8tfvKX9ZcVG/0V/RXFJn8VfxWx2V/dX11s8df11xVb/fX9 9cXP/kb+RmKb/2V/C7Hd387fTuwJ0LJf7LWaWy3EPquV1VYcsNpbceKI1d3qLs6Rnx0nzpOf/UHc ID97Wzy0pf2S1HYTu6ds5kxyjsq+wfeDY+Wq+PtbaDU6l6+4NBGtvU8WJvhEQDHwebFHFoppCtHx 6ZRcnEtRwXSWbmmpV1pKpYOU3LtscoqcpDV5RB5yd0VEEaqzkqhEzqWaqAaGGC1G810266GZGW2m MlObacy05jNmOjO9mcHMaGYyM5tZzKxmNjO7mcPMaeYyc5t5zLxmPjO/WcAsKLaLHWKn2CV2iz1i r9gn9osD4qA4JA6LI+IXcVQcE8fFCXFSnBKnxRlxVpwT5w1lGOqmuqVuqzvqrrqn7qsH6qF69E8+ M6grhuSdBoP/rZCMr2ZFUVKQmpJBzGWlnuYC9760vJT8xGoxihNLULKgJCUbykMFcKAaJYT6lEKg ITSi+LAppTBoSSk5tKUUDl0hDiLgDegJKaAvpZQ0OyVEixARCqlojkZDGpFWpIW0fE/DMzRfa0E6 mq+NID1f1c3AMzWjiBWxkInvcsgsuonukEX0Fr1pTg8WgyG7eE8MhRximBgGuWgGj4XcNIO/gTxi uVgBecVasQ7yi41iIxTk/aZCPPNiOKauyrtOTXnX6RXeC4tOsBeWm++mKi4bE2NpZH6ZnyLHGBnj /kdMlqcjVWVVihzryDoUOdaX9cGk+KcV+CjyeZUix0HWEPBbQ61hYFszrJkQan1mzYEwa5e1GyKt vdYBiLIOW8copu5l94H05EX6QybXQ0B28hBTIKdrzyEv2fNdkJ+s+EEoTJb8MMSQLT8Gz5I9PwFF aI11CoqSTT8Dxciun4PiZNsv0Fgl7Use7ksV2Z76kjZRX4rKonTE7ZGStWhNY3CPTO6Rj+K8RqC5 X36K4l6DAPfL4n4FuV9h3K9wa671FfVovrUQUnEf03EfM1inrDOQxTpnXaJ+uT3Nwz3Nzz2N4Z4W IT84ndYJM2m1UYp7XYF7XYn8002oRt7pAa1Q4q++uv9ybMk9yuv20X3SHhTz+pjXOycbzd5hYtTj z6SYLb6iUvjj82gGPIGDEpJ4YyYMHluT+fAxH5r58DMfAYp7m4DFrNg82g5zE7QaWg0BaWXeB0Jo 9TWcxnyENQ5S0xpsIWSyFls/QAytxC5BSeuKdRtaUQwxEDpQtDAMelJ0MAf6ke//BkaSr98LE3jM F/OYf0se/BdYwiP/HY/89zzyS3nkl/HI/8Ajv5w8+yVYQd79CqwkD/8AVpE/98FminGiYBfFNenh EMUyOeAkRSU2XKToIhlcIR8fTSsAsoS0QnoNwF1BQll3lwFqu3fbwAv2m04F2EzfSSPGPPV5/LTL /9LZj/UBmvOo5mOdr5VAH/L9pg9QF0o+/kxCRb52H/74PAnKGm9No99cbq0nHb9juzOHPuVVfnxL 0nMb8nmt/LWtxcia/Q3rTt+MYFsIbAsF20LFttBgW2iyLfSxLdRsC/1sCwNsCy22hTbbQodtIbIt DGFbGMq2MIxtYXK2heFsCyPYFqZgW+j+t3kl9cCRldUSKP2n14KksEQYtTKDyCEKiGKirKgq6lDr mov2orPoTvFTPzFIfCBG0K9OFjPEHDFfLBbLxGrxo9hK3BwgHk6Li+K6uEsOyCcdGSajZFqZSeYg jmNEDup9NuIiN8tG5IFd2UQUZdlUFGP5sijO8hVRgmUz8RzL5qIkyxaiFMuWojTLVqIMy9aiPMt2 oiLLWPLqruwkarIca6ZwpbHQjGK5yEzpSrznt11pJvc7rvRN8wdZLvUjy2X+EJYP/KEsH/qTsXzk D3MlRVDJWZYKEfw77UV2skYhFGtIKuUibEQRhxu/kE2iXpImUh/zE74iChA2EwUJmwuKZahvhQlb ihjCVuJZwtairHv/iShH+KqoQBhLMYukXlUm7CyqEL4mqhJ2EdUJx4rnCceLGoTjzHCQ1N8IwkWm u/tyz08DQz0lraZ+GoRL/RTzUB997h1Vfk340O8nfOQPgKS+UQTmLwXZaW41Jp8fS76+F/SHoTAC xsM0mAML4HtYDRthBxyA43Ce7It3TZE0KYp0PRPpUj4RI0qQNlUWNURdYuMV6lWsmE1sjSWGPmfZ RMxh2VR8wfJlMZflK+JLls3JuruyhZjHspmYz7Kl+JplK7GAZWt/GldSH9O6knr5DMul/nQsl/nT s3zgz8DyoT8jy0f+TK6kHmdmWUpM5PGbxCM3mUduCo/cVB65T3nMpvGYTedRnMEjN5NHbhaP3Gfu ePjDmfEIZjySGU/BjEcx4ymZ8WhmPBUznpoZF2CEAN9ZrthWAM90EeL+TcR9mnANvq8/GxTgOIB3 w0Qk61oK1pEo97fdWkTKx7m2ria5tpfsySjWFUb3Kp0IJQsFIoLWVYItkWT74vrVKBgsXhT1RUPR QNQTba0G5AEbxe9Ny26yjxwkR6qx6jM1H+/jA3yIj8jKTrAmWpOsydYUa6r1qTWNLO4Ka6W1ylpt rbHWWuus9XgLJSo00EQfavRbd6y71j3rvvXAemg9ssns2R/Zw+2P7RH2SHuU/Yk92h5jL7QX2Yvt b+0l9nf29/ZSe5m9zz5gH7KP2Eft4/ZJ+7R91j5vX7Qv21cd7fidgGM5tuM4QQedECenk8vJ7eRx 8jr5nPxOAaegU8gp7MQ4zzpFnKJOMae4U8J5zinplHJKO2Wcsk45p7xTAR0MImIYJsdwvI138C6m wtToXgfNwitP4NWmSVFXNfJp7WUsRQ5xtKp0ZG9aVQb5vlnkNWQIrwxDef83mZqn5kGY70vfV5Dc t8i3CCJ8t3y3KGak9RKkcNdLFFsdsk5AdnfVRJHUIIofitlfUORQjlb8e6E6rfr3w/McP9Tg+KEm xw+1OH6ozfFDHY4fXuD4oS7HDy9y/FCP44f6HD80sB9S5NDQCaVooTlHC705WngLIyhaeIf6uQQa Pc2I/r0R/K+M068jZDGbwGwGmMcw5jEV85iJe56bex7DPa/NPa/LcVL9+NWnyW8bpHxVcPeWy0La hPqfVIv/WB/jdYdqSMaaAqwpikfYx+OJPJ4hPJ6hPJ7JeDzDeDyT83iG83hG8HhG8nim4PGM4vFM yeMZTeOWAlJ5rbdNTNB6pJjXm7HunGc9BdZTwXoqWU+V913HDEnw3SiKSh5bgV9nOlsOngWsySZr smZN9sevpMUVcVPc86KBZDJSppIZZXZVxWxhtjLbmO3MrmY3swemx4yYGbNidsyJuTEv5sdCGINF sBiWwJJYGstieayMTbEltsa22AE74WvYDXvgG9gX38YBOAiH4Pv4IQ7HETgKR+NYHI8TcTJOxWk4 A2fhbJyDc3Eefo3f4CL8Fr/DZbgCV+EaXIcb8CfchFvwZ9yOO3E37sX9eBgv4GW8itfx5r//9Pj3 vs//2D89Qinmb20mx3vk80s91X3tNBNFe9+BBHch+927dB7f4/M/3Kfz+A4fqkM+J5sm2OlwP6lG FujxfoG4DrcoRi8si9AZ5eizmrK2rCcbysayJdmqzmT1ervX1Z6U3GtpCRPVkjgV+X1yr7wlTO51 uiemcklSRfcqXqJU8/fJvaKXMFFf/iCRP0iUqM+JU8MnJfIfiRKxlDg15fRbuWWS1IZS+z9InZ+U 7IeJE3mtxCllkpQhcfL6F99eruHf/ZE/2B8RcIj8Zwny9ZUpyq7Lz2L59Qks7tNYhsAwGEWrn6kw C+bS+mcJLIe1tALaBnuIv3x8vfmvYpG/hTX/Dj5xFyR+j8QhMcpd90AZdy1Avi6SVw/udRYhstM6 WpK3H0n5UeITyo8W7hvEJ9LKS4pvxCX3KbTiCq1XrvJ7OG6Im5S/Je6wz7xH+fviIeUfSfctKFIa pHOm9FFeS/fJrbak9bcM8jtFQiWtsWWYDKd8hIykfAr3HSHkV1NRPrVMT/kMklZuMpP79hHysdkp n0PmoHxOmZPyuWQucN+qkpvyeaT7NqBxchzlx8vxlJ8gJ1B+oqrET5KtAkpVNZO7z6ozqb9mtFnB fbqiWQmUWdls5j4r3GxH+fbum4nJV/eg/OvuU6vMAeYAyr9rLgf3LcsrKL/ST5bZL2kVKf1ZAq+C CMQGKNILdAh+BiI4O0ir3uDnwRWUXxlcQ/m1FKkKTEtxhqJo8hGv8Mgqh8iQ9PH/s+aRkdDc+3fw bzGI4BhEcAwiEvyLVXAMIjgGERyDCI5BBP/3RHAMIjgGERyDCI5BBMcggmMQwTFIfAslRyKCIxHB kYjgSERwJCI4EhEciQiORARHIoIjEcGRiOBIRHAkIjgSERyJCI5ExP+p7szjoVr/Bz5nFjvZys5Y k/XMWMe+V/YQLZSdsc3EZA8z9myRElfZCiVLCIXQYimRiqKypG6WkCXRwm+cWzfd233dP36/77fX b14vr/F5nnOe8zjn+byf93OO1wxkIgBkIgBkIgBkIgBkIgBkIgBkIgBkIgBkIgBkIgBkIgBkIgBk IgBkIgBkIgBkIgBkIgBkIgBkIgBkIgBkIgBkIgBkIgBkIgBkIgBkIgBkIgBkIgBkIgBkIgBkIgBk IgBkIgBkIgBkIgBkIgBkIgBkIgBkIgBkIgBkIgBkIgBkIgBkIgBkIgBkIgBkIgBkIgBkIgBkIgBk IgBkIgBkIgBkIgBkIgBkIgBkIgBkIgBkIgBkIgBkIgBkIt8+o+TPTyzhC6C+c0KlMD5vkMLnQUMv Fbcr7gMzQAvPp/DtoxbZwAEAwwjS06CkWRBwXhQMdKJhkKYBkABFBQ4g863BPaDMphL+QsEofuiR kgbMAuYMC4ARqBB1g5GoPxuPmLRA4U2NITm30xZZqC7KJk7qAdxHpo8PTeo3PsinbJMCKUh2kAL/ mI+AA3AqHNpgSRoaCWx9Wssub0d0QOY/ewogqX0iYqTBHTSIvUhGDhF9AjHEH+/hSUJLuuxAY3A4 FbQZ3sWfEEBwJ6H1Cf5EOYwgyP/Hxlt/rCH4O5HwBD+MMCi0UY/g4P5eb0UgkNC6R0meBH88KQQU 5GLGqYAYDAiqgNTXAS5mLIjBKmC+hr+gRxRAZPNp2fimKgoVK9RyBjgFAGAX4c1txN/VF8z5JPOy gg+BU4UXU8QPr6ydMi2qXztbiNYK31P4W2GaI9a7T881ZPZyYJfN0MJ0bhx/Wl6Me80d71Bn0QEB jeEtQMbE6dstsu45OZ4S2Q/UZFqYru6TaDN6w6ClelrmoiSu9O3uaL3xmC2NOT57nS5TwgscZYNM J7NrXdVzLPkxdGKceRffpEtz/655xoXTcR/KLU9AxSr+Q8lcJryd71HLXsOaxKgWtbc2meYVX0pC fUnmldzdp+klhWF2JxzxKo0m7LQatusHP513Z6Arfki2tZurUz+0jRyEHFq+URF1aq3qfuRACa+/ vcbdpnd0RSJgDU1sVw06iCN2BI6gDvwicilIvgCSC6lnUwBAknNAclYU68EHxDm8/znRPRGc1Wap 6/cK/P/714/yL2McsXENT00wtqYsZnErzTQAYk+D2BbtHbF55xjvaaHSE9K61H4XXnhnd1Lmav7O Tue5z0+61dUPXFS2wa+J+Wp3dV8aRoW/wKRo5rESvRrX2C248a2fH+iPsx1AW0w5h1Ve4umUVhGX veFWwH5cfItL0Qcb/lXhroGti1aX/fSxtF8oXCuvPXyY9yw3z1t1NL+5DX5GY+gTBE7t4DXrF4Bf mI8aRdQeXLryotNu1m13h5VNXS1Ckn39xMA7urSIhqw7ZSoyr0JflQaNB+bDHnhptz1UPj6qy16q 5MXn9Uxp7DE/8lWpIbLzgIKqnxk/s3M9Q2Hyo34bbaP7/HuLic/Y1eJPHs0reZhPpYIjSEGY/kEF BrkytueW6/Zn77V+Y4rAr4IBNe9VsdQXlQBYKgwwWGqo9A0GIRBBqY3QcMD3WmM4QLaNgI6Dwc4p wBPv50GiHoYVZNkopOWgtXJz9SX4uX7rGMM/dUwUFP6jY7yb613d0NZ4Dz9qq2hLfd1/pUJ9yLEB hxpDXKniZczQqrjS7qDWT0LnOgyPzPUZTTxOvuVtauW8lA2/ZfZ0t4+8mJZbS49oPeOu+sijLwyb L6WxWN4Rl17If8MsKtSnK/bRObuXx/DCSWOh7Ps18iK3jGXDCYNbBdWTcay4F807ltzVZQHs+tr2 XcVXfYD43E/Xq10iKav2+eSY2NSqhYbMol7VYstYru3x5i/AZZjmUvuqJvlG3IwPrkROcblWrpLh mHN6sHvumQDmuMqF24voaxbsKS73ZAaxhjyzjcan1S2tuXvc94RcKo/vtNXKo1gm+KGuKLWFiTVb uWtmm3dLRyj4xeyk6Tv3wDgO7hcHO98aP2L9lQofQfIHkGMDCuJIJpCBho46oaFQtAjE/w9UbNno I8fG106iQAT1DRTYKGBBbkNydgv0BMKIByvnh26b5+wxkCsycHkHMm5Ub0EiqWkUtyl1IMaElVVE GEss9DSZkwr3bSdJHa2J+1JmmhkMM5u8O839HH+HpTB8Ea7ffje+e8W6+2Zesy3hnYvBRQPY7OnO nH7+BsY8HubMJ0OC5TuOzc0UB1xOG8alap7xalL1fZhQKfplZHIAT5+e0Lw2BmtUXPwQvsrKLoea 3nH6pJ635JF61bRRWuYuB8/7zVG63u6ljfWNqYp3FxCs4aHvH47qjYStjY1dXlse6WeuIQ5kjFvU qRaGyz7WfKbI6KwCzyN7iSYu27ukVR1oxD1xTN4bw6vwXv1MPoWp8HBSjUx9wYV7ZUPouhaQJxbN ySzVZLWkO3oIHM+QxMe3EV8ulpT1ROn5B7JQGeNFZYzVV8Y4bQk2gwwJsTmPUFTO/MKs/gYcBRCk EkeBChwQB2I3QoWNECT9R7r2tR7xD/X/yprCZwwpvTfbdv92/5KaYrnofu9nPjeEReozO6cqWtr7 JW5i2ZKahhxkPinbCm6VrkhjfsFZ5CdpGrlNW/dyis4VowTmQXJmeRbNAzuDQPup+c8sLyNJRQr3 SK/nxp0KIhD1huv9Wuz9VXcPMT8IW6jnYP7s6CUZezS5vrwpdoKr9sSN99vqnB1m2EbUZoUPJlVG BdwyHD+VGOT425vyoDaVFAVOeY5nzl0VvBctzniUP0bjwCOjKR5GL9v5l5gtSbryEygxL2Hv3VUZ t6txHXoXfO25jcvSnqRGawUz7Hx6vjpG9NbLhTD3K8akZgldk1wnTkdzsJOy+ICRGD671yzoId3e QPJX1qyA5PfQuRfYspGx1CSkad2UsIvCOqnhe1ZsTM685nriFa2IkpOY+DmaNjghIIrkBrdF/TzN DTY2EEJqguogLl8lXylOwZNEIqrJy7v4+8j5fruGci4EX3miN36jVJ7oT3A96kIKkNe3pg40OWoR uOvbIakeogGqgarfYhAeJ/O1waCgoJ816Oa/qSXSXxIIoo2OHcHa4xw6WhFg+Z3LRKN8+ik5cpY5 hBRkkbWTexG2FR/xzPlE4RePgtxXkjs+7n2SvWbZcoi+5lrxDGXxjCBh/8f382NMj5LotLZxofta rxrupJNwtKM3yXxH133dzO/dy13skkpJwv4jh+sq8eximbOTivTPIvwIGQxWd6VMd1/CysRNFHQ7 SDQ1aYwerI5mvK7EbxFjuHO9MbNgP+3F0y+Cm+0iL5SYdy+U5+bovrxnL6b1PFJxp/lyb2fY2em6 rlwXTuvK8py5Jy29+QVlp+6GSsfLtHYMfvZBDLWols/32fNwbWn9cDeqmJWO98UJ0TdVBaZaU1Vs EsEsbTLXznt3pGlQaXOWSpvYb7TZHT4D0Qb162hjg/d1CyA5+RI300YZxGGUQYySEhbSGwwUYsGN ECQX/0f6th0U/2OiFPTTxxM93fzRBtaGaENrczUMaKAqq6SqqCKrr2ek+m1DBIfgP/wR1m7+gXgX t38F1NR1lEvnYEhFjIHWhZrbM6bnxEZwgYL0A1jjfcEPpQcv0J6Ye6P5qVkivOjT62MR2N5BzSSc ysLKU3XFbY8zKJ8U33rG+vOmjTaYjjbELiowwNsKAwOUTB3m68eMjwk0ZAY/WxeM3apndKQncrsd e1+0hXrvx+HlpBlt2Hj/sNMqV4rJebLGe7zO1FhiC63FdVLYJNPrnVNlPvP9HmS6lW13j3E0Bryk N/3o/GkmH5ejtjbN1ukk6LzvKYNNdL+6icnLvc3yjrypGSj9IYdpCoNoFn0+CuOWdNJcUFe4MOPE F0MDQ4LSFUOVcvxFt1VF/StcN9VxY6zJC7zx4zaWQupnMeWbAfUdSBH+7+S0bXeMin/wbAA+m4xF 9I5r/cAewoS5dtY1xTKTuLSm3KnL6rr67Q/+V+whBRBdnP5P2POtJdLPCEr3Nwr/BFD4UAo907a+ 4V6jRLmWPsVQcuR2SV2pxUfCGSxZ5YetD+1YnWmzMS499oHjASPnqtlC3FaY33i0gKRhiQwO+4KQ o3JgVtQqzQaRol2S66q6rNzJqV+npnWmi/nWEbLkonsJ5qW9Q9qqldWY/fTJE2fx9KaJfX2BporM XmPhBiXSB6NtIg3FeMRvHze6Iz7OE4XfwbnM1f5ORIZsdEh6abW4PUhLlLBa7BqbWujMfFFWsPT1 Ca3I9arUz1lv578gK+/v7jlAuvxxkUOID9dTVDvQtFQ721m+YCv4SWO+c0DKoKklV/uYO/f9arQL w10dTTcsT3h1g2abxC5zEZ5sv2SwbT79R0CxejFmW7TCxMvYnhkK7Qv1KPwrpn7N4usrnUBFRZUN OuGo4S9YfP0NnP/Gm+cqfp8qO/WMj3B39uzSsm79WMZ5XQbbyG5h1Rk9o6UwuBuTIVmX7joqZBlz /aZJXyRqZe7ojaSO0v4KPNE9eLv7RF39XOy1+7OXvrCfZ9wvskO+V2fQFskXeNXX1dfY5tmL+eGW vOiOqJFIU7hK5vvWc3S2gp477w+2BtrLH6sTR9baHvTid1mPCteY7UeKm+GCSLQON+2fxqnIHO1i mRLE0YcHrp318QsdfauVlnXuCMthKQtuZ0fsuYfR5tIi9p6GScPyMayW1atXeVN8ZsV/41i5x/ok lmWJEhig3H4qtLDbkeYtqipOoX4l82CMbsy+2Ey/KiGZXd2EXP1Rr4lIiVTvP3hDASSpZ0Ts5xn6 /2L5xUpD//UG6FZgY00F20TPn8KR588dOOFIJkEGmDXsKMwZpg/T/XFp9rd13U8AlWnGhrkZbtnI llrgRAuwJBMNU+YCbJq16VGy6w17rGP5Z3Dp9UW2jMPJdep8fZ8ul3TVX9kjzEegw0d4IwpFjGZ8 an3DRRqMHsUspmy5QXtcuW06YpLoYJiX8bC750Vq61iL1P3wt10V2P74a/dcbiv3cQu3BA6r59Tw BZwTTnhaW8tuk7yUe9PNOEdSItfx+Bb1Dg634F2NveXRahZVzvuGwclJnMB44sIQjrzKIZzsGuVC gzy9kAPXlw8zSri+Dh90WzUeHkKQTtag/Ji6zz6XdArfNc+VyyasCuePv0xz5zS24bVOu7Vm88XE 4Ql3lZQlkdO53VVBNnvUBvwNqkWXMRRkJRVSZXAAAMnxv3BV9sNa8fs97nzyEMj55/WWBDC0CBT0 38sbo+DrxaRHYJg231an9uZ7xIhhATfXbgVFv++IxFDH2Ic0Y1qySfrwVbocy6rEli+SFulXQddN uzBhbEGbfKkoSZgZDA9zgfnDCNCdeXcYCYaG2cBCYERq5EEtd6L+5gkLKZCIEvvH6ZUUQiR4+DsR PUPQf8EbkgLA0C2/N+zngalx5vAmmPUsnqrKPalTOMWiYIecVQ0w+vz5SkX23Cg4HnH8/fQSIux9 v/3qe9LZKEa/mqEKeYQfkjiFGFjmSpRtjTmlcqFXK8bBjiWk6ynP05YvCknnntegC+uNpq9F5M1U tmq1T7UYjPTpNq1McvIcN5k/CRj2HlZgSoqsSC7ST+n8bL7uUp5x6z5m+96AWsf6dOSHLubAil3B FfCcqLsV6YrKEu2/uzLlp8K7fIWOVUTYKt1+xBFerSdyKrs31JwYWFQhfUfkTWjAE4f8tII5OwsM XJo10OBjphG/cyZHWFr4qxjR0aLfzFWQ7abulyYuDF3YJ3osEewT4iygwIVACpzv+zWiwVDgTNQi uv/6EP3rjPTDAoP26xDNdwC5N49Exu9PgQDqMf+sQWG2UKdaVQyIpU60WJyC0oG/DUT4uhjLSJ1T ioPcYTDBkPd95ejblb8wa2OIjGTdMqaTHWno4iseFEZ1ML11jxNb14P36r9r7ixAB55+2TR2MpVd 56WEVGFxepJTMvdqt9QVS974lbD0Kes7OhONsg5pPQYZrn62juJ6jB1x8CjdWZHssDvYUMtZn4RX H5W53rcnZTgL2OQ8fs3BXjBwtuLDup0aYudk/+y+RXctXQ+TQ/U3mgdjZV/ZNXSmlzkf8dIu4aC7 2SvdfXQ4+3hIMDG63CjnZk10ovlONeloa2Fs6dpUhzYpEN5accnf2qHBsyNiGqPpmbM9arGWpurN owY2GcpDn5bKkSPVE9HOpXVAIDjEomNdfRC1+KFW2RVlLbw1ycPIj9XLdz+HlV8tM+x/AEjYL2MN CmVuZHN0cmVhbQ0KZW5kb2JqDQoxMzggMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5n dGggMjM0Pj4NCnN0cmVhbQ0KeJxdkE1qxDAMhfc+hZbTxeDEXbSLYGinFLLoD017AMdWUkNjG8VZ 5PaVPcMUKrDhofeJJ8lT/9QHn0G+U7QDZph8cIRr3MgijDj7INoGnLf5oupvF5OEZHjY14xLH6Yo ug7kBzfXTDscHlwc8UbIN3JIPsxw+DoNrIctpR9cMGRohNbgcOJBLya9mgVBVuzYO+77vB+Z+XN8 7glBVd2ew9jocE3GIpkwo+gaLg3dM5cWGNy/vjpT42S/DRX3/R27VaOULuqxraq9rezFVaaUZa8R 7UbE6epFaqwSyAe8Hi3FVKjyfgGKUHHfDQplbmRzdHJlYW0NCmVuZG9iag0KMTM5IDAgb2JqDQo8 PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDQwNDg1L0xlbmd0aDEgMTc2MzA4Pj4NCnN0cmVh bQ0KeJzsnQlgFEW+/39V3XMfmQm5EzI9GTJKBgjkgBBiMjkBI3IkYKIEEiASkCMQQFSQuIpgPFCf soCueKyKJ5NDHIIurLCuIpeKeKxCBLwXQZ8HcqTfr3oCkrfJkpGdl79/6lPUt+7uX1dX11QlmQYI AISjiFCdVzR8qBClCwO6Og0zFw3Nyy+445e7hwPZ9SgAfW3oqJFFN417bi2Qt6cAPB81tGhszv6c 8tFAF9cCRK+6vKi4YGbCNDW2j8Cjxl5RXDSsd4j5NoD4FgBT2ciixCRL0uLVAOQ4lpePyr2i+PRN mbl4/CpMDxyXN6Jk1P3TfwRIdgNYH5g8s6L6mYGXHwWydBG2eW3ygnnSYzHvfwNkdTWAuvja6qkz d9xQugbIMqyvnjW1oqYaIkCHxyvB41mmzrjh2r3qh2cBWbsNQPdw1ZSZC78+9fZ2gLy9QNzrqior puyfU3wMj72Inb8KM4KTTSmYbsJ0r6qZ8xbmRFIso3g8x/IZsydXrHnz4V+APFMOENU0s2JhdfAs ownrf4D1pVkVMysLb3QsBLItBEDfq3p2zTw5AVaiPWmsvHpuZXX8vhGbgdztATD8BVjfqyLXuD+e FT8xKONHbbQWGI8fuiSBhW8+/+amE+tPT7WA1ohJnVKfgaEms/VKyLXAifUnbrTA2ZI2xOtYjqkU YoEqGRQskAjjsOR5PC9DEJaTe0EFWtUaVTIeINoXCm/DtTRYq6IGtUgZYgskyFtgYa5iAVI8IlcC N9ilONW7raNJsiaTNLiByLKMR3eqNrErBVHdZhIdDGdCD30fJsDvBPWzsCpQxxZroOC3tKPPwtL/ tC3dAd0JM7vbhq4g1sinutsGDofD4XA4nP8ryDq5ubtt6Cqq6N+PrRwOh9OdEJCbtegtwOdNDofD 4XA4HA6Hw+FwOJzfP6ZSDSHwnLrrLeZ3nO1ol/LjeH638P/YHM5ZyPmr/IaqnPNACO9NDofD4XA4 FwcCCIShEgRCcQ0UofqnYQsc18qgBa3cCjrQyadBD3pUAxhQjWBENYEJ1axoEJhRLRCEakU9BcFg Re0Bwagh0AM1FPUkhEEIajiEokagnoBICMd4FERiPBqiUGMU7QnRqLEQI/8CNkUl6IlqBxtqHEio DtTj0AvsqPEQh+pE/RkuAQfqpdALtTc4URMUdcEl8k/QBy5F7atoP0hATQQXan/oizoA9UdIgn6o yZCImgL95R8gVdGBMAB1ECSjpkGK/N8wWNF0SEUdomgGDES9DAahZkIaahYMlr8HN6SjZsMQ1BzI QM1F/Q7y4DLUfMhELYAs+RgMBTfqMMhGHQ45qJcrWgi5qFdAHuoIKJCPwpWKjoShqKNgGOpoGC5/ C2MULYLLUYuhUD4CY2EE6jhFr4IrUUtgpPxPKIVRqFejHoFrYDTGx0MRahkUo05QdCKMlb+BchiH WgFXoU5C/RomQynqFLgatRKuQb0WxstfwVRFq6AMdRpMkL+E6VCO8esUnQEVqDNhEubPgsmosxWt hinyFzAHKlHnwlTUGkXnQZX8OW7rp6EugOmo16N+BgvhOtQbYCbqjTAL9SZFF8Fs1MVQjXozzJEP wxJFa6EG9RaYh/oHmC8fglthAeptii6F6+WDcDssRF0GN6AuhxtR74Cb5E+hDhah3gmLMecu1E/h brgZ9R5YgroCbkG9F7UF7oM/oN4Pt6L+F9wmH4AHFH0QlqKuhGWof4TlWLoK9QCshjtQ10CdvB8e gjtRH4a7UP+k6CNwD+paWIH6KNyL+hjqJ/A43If6BNyP+mf4L9Qn4QH5Y3gKHpT/AU/DStR18EfU ZxR9FlahPgerUZ+Hh1BfUPRFeBh1PfwJ1QOPoNajfgQNsBa1ER5FbYLH5Q/hJXhC/gA2KPoy/BnV C0+iboSnUJsV3QTrUF+BZ+T34VV4FvUvim6G51C3wPOof4UXUF+DF1G3wnp5H2wDD+rfoF5+D15X 9O/QgPoGNMp74U1oQt0OL6G+BRtQd8DLqDvBi7oLNqLuVnQPNKO+Da+gvgOvyu/Cu6jvwF74C+p7 sBl1H2yR34b3Ff0AXkP9ELaifgTbUP+h6MfwN9RP4HXU/fB3eQ8cULQF3pR3w6ewHfUgvIV6SNHD sAP1M9iJ+jnsQv0C9si74EtFv4K3Ub+Gd+Sd8A28i/pPRY/AXtRvYZ+8A47C+6jHFP0OPkD9Hj5E /W/4CPUHRX+Ej+W34Cf4BPVn2I96HHU7/AIHUE9AC+pJ+BT1lKKn4ZD8JrTCYVQZPkPlc3rg5/Tv fudz+jddntO/6mRO/+pf5vQvO5nTv/iXOf3zLszph8/O6XPbzemHOpnTDylz+qF/mdMPKnP6wXPm 9IPKnH5QmdMPnjOnf/ovc3qLMqe3KHN6y+9wTv+wm+b0vXxO53P6725O/72v03+/c3pn63Q+p/M5 veM5/Y3/D+Z0wBkXTOMNYVoQgIpd/1GOtuPs9r+P9uN4frfgv/nmXAC061U1gbPiooMYwrrbBA6H w+FwOJxAY4zQsV98+7EX0nWc3X4dGsi9FV/xci4AP/ZWnfwYgfMboMaI7jaBw+FwOBwOJ9CYovS4 rRFUXW9h6Dj7QvdWXbeA7604F4DQ9ap8b/Wfg5qiutsEDofD4XA4nEATFGvAjZDqwvdW7dehfhzP 7xZ8xcu5APzYW+kDZ8VFBw2K7W4TOBwOh8PhcAKNRTKyvZUf32EydZzd/k8F/d9bdd2CTv4okcPp Cnxv1S1Qi9TdJnA4HA6Hw+EEGmucCTdC//G9VSD/Fwe+t+JcAH78uWonv6Ll/AaoNa67TeBwOBwO h8MJND2cZtxbqf34DlNQx9nt16H+7626bgFf8XIuAD/2VsbAWXHRQXs4u9sEDofD4XA4nEATmmDB jZA/eytrx9ntdzz+v2+i6y34ipdzAfixt+rkV7Sc34AQmtDdJnA4HA6Hw+EEmoj+wbit0frxd3Y9 Os42t0v5/76JrrfgK17OBeDHVwE7+RUt5zcgRPTvbhM4HA6Hw+FwAk30wBD238L78a398I6z269D /f9OVNdb8BUv5wLw489VO/kVLec3IEQP7G4TOBwOh8PhcAJNz/Qw3FvpLnxvZWmX8v8Na11vYTlv DQ6nU/zYW3XyK1rOb0Dsmd7dJnA4HA6Hw+EEGskdATow+PF+iOiOs9v/jN//9010vUWw38fmcM7i x1cBQwJnxUWHKLm72wQOh8PhcDicQGPPiWR7Kz/eD9HJ3qr9jsf/vVXXLeB7K84F4MfeKjRwVlx0 iPac7jaBw+FwOBwOJ9DEXx4DejD48X4IW8fZ7deh/r/Lr+sW8BUv5wLw4zUrEYGz4qJDFX95d5vA 4XA4HA6HE2gSiiXcCJn9eD+Eo+Ps9l/DMndc6d/QdQs6+cIXh9MV/HjNSie/ouX8BlQJxd1tAofD 4XA4HE6g6TfeASYwW7reIr7j7Kh2Kf/f5dd1C6LOX4XD6Qw/XrPSM3BWXHSo+43vbhM4HA6Hw+Fw Ak3SFCeYweLHd5h6d5wd0y7l/9uru25BzPmrcDid4cfeSgqYERcf6qQp3W0Ch8PhcDgcTqAZOKM3 BIHVj7dN9+04O7Zdyv/3TXTdgtjzV+FwOsOP16zEBc6Kiw7NwBndbQKHw+FwOBxOoEmf1wcs0MOP 90MkdpwttUv5/z8Ddf1919J5a3A4neLHa1Y6+fNXzm9Akz6vu03gcDgcDofDCTS5tyfhRijMjzei Deo4u/06NMxvQ7r+hgq+4uVcAH68ZsUVOCsuOrS5t3e3CRwOh8PhcDiBpnBlGoRCuB9vRLus4+yE dqlIvw3p+hsqEs5fhcPpDEvXq/YPlA0XIbrCld1tAofD4XA4HE6gKXoqE8Ih0o83ouV3nN2vXcr/ 90103YJ+56/C4XSGH69ZSQ2cFRcd+qKnutsEDofD4XA4nEAz3psPURBl73qLwo6zk9ulOvkPhv8N UpdrJp+/CofTGX58FXBI4Ky46DCO93a3CRwOh8PhcDiBZsobhRADMb263qKo4+y0dik/9mptdPJf Ep/3TByOX/jx2hZ3wIy4+DBNeaO7TeBwOBwOh8P5P0Bo8zFAlPQMTGGMzAURRgH7gopFKY+DETAF 5qrdUg8pTpaB7aDa5ciHfO6Up+WRlsq2o7WDqOFsNqEUgP7vCuhFVddt799x9tB2qbFdP94ZlnW9 ar2/x/6P96o7d2xxtjsr87KMIemD0walpiQnDeif2K9vH1dC70svccb3csTZJVtsz5joqMiI8LDQ kB7BVkuQ2WQ06HVajVolCpRAn3xHQbnkcZZ7RKdj2LC+LO2owIyKczLKPRJmFbSv45HKlWpS+5pu rHnt/6rp9tV0n61JLFIGZPTtI+U7JM/OPIfkJVePLsH43XmOUslzRImPUOL3KnETxu12bCDlR1Tl SR5SLuV7ChZU1eWX5+Hh6g36XEdupb5vH6jXGzBqwJgn3FFdT8IziRKh4fnp9RS0JjTKE+XIy/dE OvKYBR4hPr9iimfU6JL8vGi7vbRvHw/JneyY5AFHjifIpVSBXOU0HnWuR6OcRprGrgbulOr7bKm7 y2uBSeUu4xTHlIrxJR6hopSdw+rC8+Z5wm88HPFrEg8enFuy7NzSaKEuP2KaxJJ1dcskz6OjS84t tTMtLcVjYFsaX1BeV4Cnvgs7sbBIwrPRpaUlHrIUTymxK2FX5bu+Skc+yymfLnl0jhxHVd30crw1 UXUeGHODvSEqyr1RboGofKmuuMRh92RFO0or8mLqQ6BuzA2NkW4psn1J3z71FquvY+vNQW0Ro+nc SOXZMiWmVGexwjFne5YwixzDcUB4pMkSWlLiwGtKY1KZBnWT07AaUkqwlWcK3pFpHl1ueZ0lneWz 9h5VvMUh1f0IOAIcR/7ZPqeiLUcdb/kRWJSNk7NDDcvPxD0ulychgQ0RTS7eU7QxU0mn9u2zwEsd jmqLhAF2H4zCvq0oTU/E7rfb2Q2+0+uGSZjw1I4u8aUlmBTdAO5EV6mHlrOSLWdKQseyktozJWeb lztwJDcpj3SoR+s8+y/IEtYjvyrdQ8L+TXGlr7ywyFE4+uoSKb+uvK1vC4vbpXzlaWfL2mKeHrkl QjRti9FoQSnFQTn+bGWWKDF6xHj8p1YG9RSvRoujUskhUoHHUj7Mp6V6u72LjbzyMdZKCX5t1mam J93VPj2kXbqdecY6AQ0WnbSw+Oq6On27MhxqvhMObwtwxENxiV3K9cBYfDLj8Z9X3pLGfGm0x41d lssq4PjzZbUl21WMbouXImx09u1TgBNdXV2BQyqoK6+r8Mq1kxySxVG3kb5GX6urzi8/M3C8cvOd 0Z6Cu0qxr6pIOj4UFHLqHWT56Ho3WV50dclGC4C0vLikgRKaW55TWt8Ly0o2Sji5K7mU5bJMlpBY AgoJXmQD1Sr1oze6AWqVUlHJUNKTvQSUPO2ZPAKTvdSXZzmTRzFP9OW5lTwGm2Nyi0vOHT3KI1na F2AjFAuXNjojbHteEXpDC3oq9G5w9bRtFC4RejYMsbm9gqMxODQpKLuvIOE5ExWVUGejX49+M3oR JgqxmG9BXYK+Fv169JvR70GPawVUViqhn41+LfoWViL0FGIaJJsl+xIhEttG4jUECeFwFL2MXgAb aiL6kegnol+Bfi16tVKP5cxGvwT9ZvTHlBK3EN5wfzLaHt5wpxI0Tp+RpCQrfMnxZUqy8apSXzhi tC/MG+6rlu6rNiDFl90vxxde0scXBscn1bJQb0rakh0mhOFFhqHh1aiEboMgQsAGjwqh4EFPBXVb jlsIbuzlTFq7WRCBCFQguDiwyVsE0mCyJmXrqUyPQjDY6Lf0iK+EHmk0W5PWZl9OD8J69JvRC/Qg uk/pp7CEtrA+R81Cvxb9ZvS70R9Fr6Yt6A6g20/3QxD9BBLRZ6GfiH4t+s3oj6LX0E9QLfRjNj8p yuJZ6Cn9GNVC/4GX9Q/UIPoRxj6iH6Fp7zYMGpy0UYm4Etsitvi2SHh0WyQ4LMlL32n4pTeOKCfe aRxRm4Q4yIRkIa4hfoDNK0Q0ZEyzeemhRsllezS7P90LHvRsQbkXz7wXJPSj0Jejr0avxtg+jO2D WvT3on8UvQc9jjJUC3qJbke/A/0+6I/ejX4Uei3d04Cn8dLdDc4cW3YY3UX/DuHY4zvpG0q4g76u hG/RvynhmxjGYridvt4Qa4NsA5YDtrFgaMEwEctV9K+NvYJtcraVbsa+s6Emos9CPxL9RPQr0Kvp ZhrXMMUWjAfZBNu1gDUb4CslfAoe14J7us3tzMUBKDFxpl+GMZS10londTtXrsYkE+c992OMifO2 uzDGxHnjLRhj4pyxAGNMnFOmY4yJ8+qJGGPiHFmMMRQvfeTlXpfYBo28jkjZQfR67KXrsZeux166 HkR6PXPwi8hse6ghIQF7bI3b1TvBVttMal8htWNI7eOktpLU3kxqbyG1GaR2Aql1kdoYUhtLat2k dhNJw66oJe6mdsnB7ghSu53UvkBqa0itk9TGk9pepFYig9xeam8YnqwE+UrQmM0eOgwvy8TZJ4ja sUftOObtOCdsRt2NXlZSbqwkxfkqR8ayMK4xIcuX7peeNDt7GN2KDbfibdgKB9CLeIO24jDaigfZ igcIQs1CPxH9FvRH0cvo1Vg7Dg1foWgQaiL6LPQT0S9BfxS9WjHnKHoKs9tMXK8Ylthm9EiWolvR xaGzU7u7pyXG4rIME1bEkKBYMjJWjqWDIIy9NjDYqrV6iWnDz6bjP5tAl62j99AV0BNvxL1t4YqG X3ravGRVg3OTLTuU/BFiRRx1ZDA4STyGaVCjpFMhRsvCFIihz2GY1BAzDpsFNTj72JqJmbXaYPsl 5rDtqxgvxeiXMZts70tekTTY3sOc5zbY9sbcYXsz0avFnFecXoJBs6RU3RiTZnthu1L1FixY02C7 mQUbbItjhtqui1EKKn0FE2ow5Q6yjXFebRuGx8uLmWRz1+AxN9iyYibYMny1UlmbDbb+aILLF01A Y3vHKCd1xCoHHDvIS6rcfTQrNSWakZqBmiRNH41dY9P01ERrQrTBWovWrDVq9VqtVq0VtVQL2hCv 3OJ2sZ1oiNrCArXIVFTiFsqUbVrZpEe0FC4HTw+hkBYW5ZBCz5bJUDhJ8vxU5PASPa5WVI4c4gku hMLiHE+aq9Crkcd4BrkKPZpR15TUE3JPKeZ66HL8lC4u8RKZZS2NZvuCjUCIdend0Sy8dOndpaUQ EbYgKyIrONM6uCCvAylvU9evRLSL9/SsLCwq8Tzbs9STxCJyz9JCz3+xjcNG8j05lp+3kXzHgtKS jUIm+T5/DMsXMvNKSwu9ZJxSDyTyHdbDEfOdUk+LH8ysHkjaWF+9Nb568dge6/ViAdbT6SBeqRev 0yn1RMLq1df0ys+r79VLqRMuQY1SpyZcOrfO9nisEx+v1Amrhe1Kne1htayOJ1OpEhODVWJjlCok CmKUKjEkSqky7tcqiW1V7jhb5Q7lTAL5tU6Mr46p5UwdUwvWcXWVyhyXizQOKZ08nm26yh35lejL PXcuqIrw1E6SpPrJpW27MWf5pMlVLKyo9JQ6KvM8kx15Uv2Q8R0Uj2fFQxx59TA+v7ikfry7Mq9h iHtIvqMir7Rx6KiUQe3OdcfZc6WM6uBgo9jBUti5hg7qoHgQKx7KzjWInWsQO9dQ91DlXKCM8VEl 9VrIKcU1vhI2UoMex2t5tL00J8xSnakM3iH2iJujm3G1sg4MuOUx4vbZhJ4V9c3um82K8JliRWa2 s24rirh5iD26maxrK7JgttWRA65582vmQ0T+tDzfvxoEs+bNZx3uU1dNZ2BZPm6S82rmARR6EooK PVm4mq3XaDC3nF2SJ/1MnsGQj2t7X2Y/zExnmYJwtiLLy2B5Ol1bxX+9//Pbwlz2FNTSTY3EHUvm QU2p4IktLKY4FRS3bWGacS3FPh5qSvECa4iL1Jw5RpvZLhf40sCu+YyfN78t1tYX89pCX0tsUnOm S87COst1tsfm4QFB1QyR6KNUT0Ok6IQIAPkL9F+ysHWa/CUrZyH9Gic6b5sHWAcvkGnwAmyG18gx bLUeNwJNwJZAefAwLIIHYBl+rF2NOXfAGHQqzH+ARMpNkAiP4QfbY7AT614FN0MzhJEI+StYAkuF d7HVUjBBHGTDKJgNd5Mr5PkwHg6It8IguAJmQTWplUvke+T75T/Dk7BReEM+DQaIgsnodsrfqj6Q P4a+2OJBWA0HyP26l8CNZ6nFmn+CubBGKBOJPFU+gRbY4Xq0QYQRsJNsoS48eiV8QSLIIiEXj/KE 7JG3Ya0YKIMqWAPNJJUMpXbVeHmEvBPC8BwL8airoQE2oPPCq/ARMaqOyX+Wj0Ek9IHheD1NsIts EVpP39KahT2mwl7qDYOxZDb8Bf4Oe4iD/JXOVhlVSSq36kZ5L4TAABiL1j6NLT8nP9Ob0S0RXhcL 5BwwY7/cx3ob/gafkiiSSEaScbQ3nU0fEeaCFs84AN0UmIb9vQqPvh+H0QZqpLuFJ8TnxJPqnq0t shnviBMegj/BX4kJr1QiNeQPZB85RHPpRPoQPSg8ID4jvqOpwKueADPhbngOfibBJI2MJteQKrKI LCP3kdVkJ9lDvqTZtJheR48KVcIc4VUxB12RWCPeqrpddaf6y9aS1m2tb7f+LCfJt8NoHA+3oPUP wiN4ZRthN3yI7gAcJCpiIGZ0ErGTseQmdDeTu8njZB15hjThWfaQg+Qr/Ej6kZyk+ElL1TQaFz9s CeSgc3GF+QB9mO5Gt4f+k/4ihAtxgktIFTKEUmE2WrVMuBfdS8KnYpS4W5Sxn5NUK1VrVetUz6le Ux1TGzV/wM/4HaeeOJ1wen8rtC5vXdna0NokfwqheA/x0wM3XBlofQW66Xi/V+KIWw/vEiP2XRRJ IJnkCuyZiWQ6mUMWYk/eRtaQJxXbXySvYC+9T46izSYao9jcj6bSHDoS3QRaSefgYux+2kT30ROC RjAIQUKokCAMFcqESmGecIOwUvAIO4RPhIPCT8IpdLKoF21inOgUXeJQcaI4X3xE/EL8QjVe9Zbq M7VePVN9u9qr/g5XNZmaUZrRmjLNCs0GzV5tOY7OrfASvHzuz4hJi3CLkC+8BPfQZDEStzC7cDxP hCnCCIojla4jy+li0kR7qRaqh9Ah5Eo4Jjqxr1+na+lPdIgwghSSIphOB/iOpg4Rn8UgQ9wKR8RX 8Np24ZEXqo3kZnpUbYQGXCMNxnP+TegvuoS34CPhANGIj8E/RD0JJ0fo08IoHAWvipmqErALD8OL whyyGF6i+QD6k9q7cBxfSZ7FeaGYJJHjgozL4CtxFA0SDsGtcB39AI7gc7wc/kimiFPhHkgmi+AL eAqfit6qWeoEdSh5k04T62gP0gRUfAavbjDpRQRVCNxGyoQ16qP0Q5gPu0U97BeeR+t30xeFEeIx 1RhShU/AYrgd5si3wA2qEvEdMhUEMg7ixRac3RYJSaIdwyU4q4zHOW0DPt3NOA9kCyMwJwJHzhU4 LsbiDLEG3SqcJ0QcQdPwGb8KZ7Fd0KQupl6YqjITnHUAxLdax8DV8lOwWp4Ks+T7oS/OB8vkRXjE dfAZrIB1ZGnrTVCNW8kP8dm+QlVAd6sK5L60jn5Ii+jK9vcXezueRMDX6F7ERKZqE9SJ70MRZMl3 ye/h6L4UZ9jVMAkXrIfxKr/FMwwTtkBy65W0Xi4QqvF6D8Bo+WnZRvRQJc+AkfAKPKlRQYXGhffY Q97B670JKukYeZ5Q2ToN+2EF9oIbe2s+zj934GpYmfBU7HdJGgC71W6NR8GVM5yShC2n3Co4CZK4 hf3Ox4PWrsBPGRXoYHG9mv2gqYGCykvXuw3aDLVely5mqNMJSTx8+jBknf48K7o+Ril1YikFtd7w lqBLV6WJGZCG9YQMSiVCyFt6veEW+2OrcOV7peWHsowRliOWw3iIw5ZvIStrhOX057jybVThwoRY MiwZpaUD+vcQrMlWQUhNDv1i0IGUJ3aTGYKO5LduOvVz6wM7dzJbJwiN9HrFVgPM34gfkccb4+JT VF75uDvO2TvFoNZjJ+HeSaVSG77VabWCQEGjzdAH6Wp1VIcrBXeoKShFt58IYgYlbpM1hUQa5zwd wUx0ZYw4nWE57SrLOJ0BWRnMqNMZKMQaPHgw8wP6E5erBzNPSFb03qSdfT8ZsLO/0EjCjx1r/cqn bDuyCp/KILTTIoS7jdoEgylnLFW0nrL+3Qha+Se3wWikY7Vmk5WOpV752yYWwUv51n0pixmDWbEq yCjogFCtzmAGrY7qDWqLhY41WEwmVK98YgOrZbCAV/68iZVg5HhTUJASOdXEakEiLjV2KoIdv2WL Zc+eLdbg8MEul3JBLoj23XS3TSMZDOqxakUFRUVFVYpqvfL3bgeLUaNSQ200YtzMVGdkqldUwyww mZQGx902FnOqiFHSB6cEKaIyCkDMBtBqCdWzC2dHUyLKQTbRcRCMm7txbhMoJwLlRHDmsEDYtfyQ +AOanpWRlZHhu5gy39Wcs1qLdi8BGqQNodFacYHxduMb2JXG4cbhQUJvMd7Ux1wiXCMuMC00LzNp DVSlHWwaaB5JC4U8jVs7wpRj1q+iq4WVmpXadcLTGnUwDTKb+6toiEpFtUaTqb9Ki1GtcUzQGOIm lGq1Or3BYDKZzRZ2n8qDa4NpcDNdByYyoEElab1kgDvMqMOHwpAzVo89hSq5jUsMxNCMF2wmBqxF vRgEEbzUn5pYPRZhwwRjUlC1hVi8dNzLkqpcVasS8BFc12gdUhrhisTHCx+wiNMuV4blSFSk5Qim os5JHi6DiKysDGVIn3FRliNHlqn6uZYt3rasXwQLBvTHhbUBF9axuLB+FYzySRyl+4DK+9LS0kpx Q23EskuxbCOY5OP1Zj3LVRbXJnnvBvtgcx/7YJMXo4MGm5MGKdGX+mJu38G+m1I6d04ZzCkjZbiB drmScTYKCx84iNitDiuuxKyr8GPhmv5hkan4ga7a1DpufWuJqvnk9/cNG/WQcOpEgfjWyVSx5aTE ZoEC+UvhAD5dVuhJNrsX6aloijelmPJMqtSQ1JiraLF+TEhRzFQ6RVWpmxxSHrPFtlf1Xo9PIj/r 8VnI0fBvIj/r2WKTbWE2mysqIywjqjCq2navTdOP9jL1C0unqaZCmm8qCBkec5V+nGmq6TP1F2En yA9mCwkVzAZLEETHGDRW0IfGCIYI36DMGcsiL7MbFZHMbt/3Lyu3L94adKYCRn5oYhWC2GN0CSsO irdY9liJxeq2lltrraLNbTDQsTY3e2itwexhtmIjt5U9zVa12YwaoZSxIxjYk2E1WyxqlvY9OtYz jwiLuMvZ2azzgrXs9DiZYCrYzM4b3EtjYSmNhZVs1uzWHNDIGtGmydKM1AiaWGaFJoLNK5pYdj6N 8hRqjOzImijlEY+MTRnlmzQVyua4XCOOYOT0OXudsjk4/DDEKTXjMHtWj+DTit7KJlMcbGWEjQd7 qtoR53SmpgQPTE4KC8cPABISlpw0MDXF6YhTC2mV25a8N3/63lvLVyY2npaen7/gyXU3LXzs9kfu OvnEWiLUjc6m5hMFNHjH9r++/tGObWzuXYpD5HUxE0fHfveIxB7EIhKHmCLm4vL4WnGeqNZZtTqt ztTDqjOBoCWGGLWGqEGvu/ReLdHGST1IDxpnVTrKqnSdVek6azy7r1vcluSBKcfYD5wk2AMt+HnK +vzMxOu2srsEIus7ULN+VGZhdpOA3cqwoKCz05lWmcuuDB66LcJl+enXTnNlsE48bCn7YS5+3GZl HbHip8/gwcqnEFjeXGZWntSyuaQs2ZocOhB7LVzDukqjDrUufTxzWtY1EzJzcoZMCIkVnY/NGZb+ 9CVDs8rnnt6LNs8ke2gVrgANYNuIS6kit1mn3iFBf3yk5huveprZUXYEEo/gJ3EKuxuhIezezHyw atqDD06repDumvbAA9Mwjr0snyLbxdn0GlxfxLqDSCrQKBX7tVKk2HgjGxiHyyyfQ+IIPJSQag8V xRqy/b77WLtmXBmtI+9iu4hXgdKj+Nn2Dd6wY/UqkmjBC8YWxJ5qJ+tag8m3JP7Ftjaq6PO3UUWf WKuq+LUNgc7afPbreaC1mRT82kbbhTZa+LlZe04bSxfaWOBos8XXhv1Buc9dh/vJADg6yx8nLO7c 4Z4n8K5/ANwV3HHHHXfd4q4NiKvljrv/B90asUncxR133HHHHXfccccdd9xxxx133HHH3e/ZAUA6 /Qv4vpkOMF1RFiegV1IsTsEMX8OZb7BPgB1tcfGcOuxvME+0xdVgJgltcQ1MOltHC/2V/+KexXVQ R9La4ib6LHnt7DeuU8UZbXECKvGxtjgFzf/w9jXgUV3V2uucM+dkwpwEmiJQys8UYxoopCFQSiMf UoyICGmaxjEzzZfmP5MQksnkzE9mhmQm5iJyA8WIWBERuTHSXETMjRgxUooUAWulpEVaEAtF/kRK KaWUInPfvc+ZMK2t3/f43edjnnfv9+y99tprr7X2Pud0ktR0yuASPWg6YnBTnIxMqumCwRVKkAWD J9D0IRkzjTE1GTyRviCbDZ4kfEVewn4j3yRhLlXZwrkMPkLp5Vzh7Xs5T+DtL3Fu5vwk54mGD3Wu +1Dnug91rvtQ56Y4Gd2HOtd9qHPdhzrXfahz3Yc6133I+LA4+y3ctsucq3HtyZzf5nwEsy1B13k3 eErCOM5Hxsl/iuvR+ai49nv42AzO7+Uyus7xcTIT43gql5/D+RTOF3E+jfNCxs1x9pvj5lLj2tXY Wp4lK2XBI+wndK1UQE6qRL2EGqge0KiZXLzl87hyg7OyFO01XCIDPY9SHT5WykdbNcZr1MSvKlFX QtqLsgKSj4LXYCyTreEypYDG9VVAZhlqNy1FWwNV/Uu2fFQy+0NzMouqyQPO5skmG7euyRhtpYeg YTo8YaV0aKqhcvQ2oJ9Zo9HkOF1LYNs/WlUwxHK4XT5I12NGKz0GDVVcI+udxm1pQEbW8HlzeY8T LcyyJpqKtjy+LjfvqeF+egKlB/IVhtVW2PoIzUbs7BjpwTXzXzNqD/c786zT8HMVt1XjbQ0oK3i7 i8/XzOPA9FrR4uY2MclyY0ylcV3KNbn47MsgpfE+NqqM69CMaNUZ66wfskIfEbPDHSfr4h6ugMXl fA7dHz5uN/PIx69Bv2ay5ZjNwz1SwTPxo55gI+o4S4f8ZNQsy8oMuz9ed/3/w9rvaK8Yir2b74NY LGO5+nEriM3+j3Z9Ni5GbCX6WjQ+X2wXMP36WivQ4uMrb+A7659lQumHol7Jo9NglPqqdO7BlYuX Vm6tdyibdT1Msg4S/yyHMp61ZmVOn24tcFZalzTUN2jNrkrr5xvcrgZ3qVbTUJ9hfbSuzppfU+3U mqz5lU2Vbm9lRcaj7prSOmtNk7XUqrlLKyqXlbqXWhuqPllLrDFbH5lfWe2pK3Vn2yrdTei2PpQx PdOavqSm3N3Q1FClTeZSSwqGVBWwIsdd6qupr7Y+VlVVU15pnWbNbyirqbfm1pQ7G+pKm6Za80o1 d015Tan1iVJPfQVUW6c/MjvL3uCxLitttnqaKq2aEzZXNdRrVq3BWlHT5KpDR2l9hdXlrkFjOXoq UZc2WV2V7mU1mlZZYS1rxrBKax3mrGcq0MF0uHmry91Q4SnXrLDD54QhcTOgrqkvr/NUwF/WmBEN 9XXN1vSaydbKZWXQHSdd/09n5+IVbPXuyia2SubVOxOw4UO6PstXlF6DWbTKZSwE7hrMWtHgq69r KK34sBNK9aVXuq1YUQOmQunRXB7NWlHpZW6GjLOyzvVhD2XgfGzg+46dvPXIcHZyNgtJyKpaXF/g p3Cs/wnkmb5T2I6okDZIP5N+LT0H/FLaJW2L01XKT6rY9Smuu/JDc1V+SBvXZ5pgmm76sumLpv+F 8hFIl2InsD2m3wmcwg7hh3gcYzuf3S3c/MRmOvRnQ4reT5/0/3KWiD0F3UVCNKr/VaMl4nOTxEdM aUTzXpd34dqqJ3TsXxT/6HPR24/mL87PzDT+vCZ7ElNRXRFuQFseHvo6SBBXi98lSdwgbgD/nvg9 8I3iRvDvi5vAfyBeAX9bvAH+vgQLpBQphSTpbmkB+BelL4MvllrAW6VWEqWwdA38XekW+N+l2+BR 9psPJmJPhSbNpIF7TM3gAVMAPGj6Jnin6Vvg60zrwL9t+jb4ejmLBHmGPJMk+SH5YfDZ8mfB5yg5 JChfUDCvslhZAp6rPAFewH68WbEpXwUvVArB7cqT4EWKBu5RPOBexQfuV/6NRGWF8nXwlco3wFcl dJGQ8KOEH5GU0J3wc/Cd5kdJNM83h0gyLzdjdeZW80bw75svg79lvgb+biJmSbQn+khK9FvwNGoZ ZkkiyZJsSQefbJkBPtPyY/Ctlp+C77A8D77Xsg/8BcvvwF+0/J5Ey0sWPFNbLlr+hvbLlnfAr1mu g79neQ/8hgWet7xvuQn+AYInqYL6Gzyh7VN/C35AvQr+jnqNRPXdpBEkJN2VdA9JSWOTCtkv+xox F+k+7nnd57q3DT9jjflYUYEZfjMXmjHK7DAXg5eay1FWmV0oveZmlAF4g/khgrLN3IaWr5m/Bt5u XgH+dfM3wFeZ/x18LXzFvHTV8IkIbzwAPtXyINaSacnk6/0r+CXLJb6WF1DuV/djRb/FutgqRqEc nTQaaxmTNAb8HrYuYz3DaL0wQHKpu7SMrOXN7jqaW+2uXEq5zsoyNxXXlWr12P3DSPhKfo6VRmJn ReEDE1kMhvcY7hviu4m9yyTFXQt4H0geuhaw86BpccFCK40yJES8GQw3uITeEXTX0kp3PTl5Wc9L jZcBdkOiMC9X8nItL9fzsoeXL/Hy9LKly5bSdV7eZqWg8DKZl6N4OYFo6M3to6Vo/EJ3rBbYX4SA 7TJ7U4O9w7B6lb8dwlpKobvhl09hRaPxTsR+Y+xeGkfj2Z974P/nnY8b93FtItZv+lA9HPo/qZ6M p+AinId1OPVC1E4dtI42Uhdtoz4aoH14Z3uFTtAZukTX6JZgElRhrJAuzBJyhMVCgVAkuIVOYYOw RegReoVdwl7hkHAEmvGGKazA7HgbTcmEjajHO2Epaivp9X1n9L0wqV2vZ93W64cP6/UjGXqdreeF 8MXrer3wpF5/aa9eP24lE/vV+cd7SGF/Wu6pEClIIKH0jD5/+SZmDQkV7G/OJaDepLdX9Ot1ZYZe V4/icqaajJr5NbaaWuPqWM2lWqodqV/VHq29WHt7aYp+tTS8dN3SrUsH9PF1LXq9rFav63O4lLlh QkNWw8KG4gatYVXD5oadvDXJtdG1w7XPdcx1qZEaRzamN85pzGusaPQ3dujWutnfp2B1sa7NXaXX TfP0WuvTa89FXc5XbNRVPNsE3xoShru4h2rohKAgblnCPKFYcAltwouiKM4U3WJIXCWuAzaJXWKv eEC8iK2TLFmBRZJL8koHpCO4R4w1FZrcppWmLaZtcpa8WTogH1KsSq3iUrqVE1JygpIwEiPwSZif UJhQnFCR0JNwxpxt3mbebz5svpk4LjErcV5iVeK6xOvDZg7rtSy21Fs6LOstmy09ljNqipqj2tR1 6tEkShqWlJk0P8mVtCGpK6k36ZWk68nm5KxkLbkzuT/5UPKx5NPDTcMnDZ86fBGyPTX6ND0cPU5z oseFt6NPC+8DH0SfFgUgMXpcHAYMR79AI6NO7A+JyzvpESA72odxTrKj3wEUATtxLdHw6Hi6C2Da EzCmL26Mk48pQttO9JrQe5yG375BdwGp6DFxex4BsnW7sKO5DPSNwAimdzwwget3Uhb6csAXAAuB xdCcj/orqG2oC1E7MK4ISIKWHENLDrT0QUsf15IDLET7YmjLR81Gs5HMThWjnsao4xj1NEYdx6jj GNWHUX0YxUYcx4jjGMG8cBknQmxVIzAPW9l4jJwQDcbNlWNYmkNP4LoAdSFk7IBIX2KepM9wTz7N Z91Ji9lJA8m7AHGoXaCfQ1biPrZx/x8nWZwWLRFnAYuBx6MDYkF0APtheHQixkzEE1IX4pyDOOcg zjni2OhW8X4qJBmtx9F6HK0s8rsR+d0kofWFoSuTkBV9UxwXfU1MjR4UO6Jv0jAhI/qm8CAwHZiB 3hHAaMAKTALSgAcgmShMjb4qTIM2OfoqsssJrU5odYqjMB98Cp3sLxJhLhoJ2dWQXQ3tC6B5ATQv gOU9sMYJG52w0Qk9q8Wk6CYxBfzuaJ84BvVY1PeiHg9YowuwsjJxcnQBidD7MmZ7GSc8y2Jk6v+V PQqTZpKG1DdiUjQcrc9j/NOw8Rw8cA52noOd5yD5PLxwDl44J94DTASsQBowGXggeu4f9A7NPhSH Vz8UB8XIqZvIp5vxXiARMdmEWGyi+4ydwuOMnJuInJuIOY7DyuOwcqKQCUwHZvA8GPiIN4/Dm8dh +UQR48WR0Vx4IhdereVeHY96As4FK/o+Hc2Dd54WP4O2+2lATIfcZLRPiebifhuzdAT8DmuN7H/6 E2L6USs+HNNR4B8f12YeV5Z/vfB+LzT2QmMv7O+F11+DVC883gupXni8F88EsOt/PK9SoMmH+fug zYdI9ECjDzb4MPo4rO/B6OOwZxM0HIcGllk90OCDbT5o8ME2H6LXg8zHvqKkf8imj8ukSR/JJjbq FEadwqhTGMWieArSpyB9CtIvI2J/wIhTGHEKUfoDRp3ivjuIUQcx6iBGHcSog5jrIEYexMiDGHkQ Iw7iFIjte7bnLZ84LjYmTR+HWQ7iuWV4VEFGKvRs1Ec9QG90ECfXzmgJL314atsJj8+lHPHR6AXx CzRNXBgdFL8E/mXU7BRbEu0Wc3GSPQ7+VbQ5aLRYh3oZZOrBfTSNksVstDANC/nICxjZhZEvY+QF 8TH0PY5rnIXQcEG0A5XAMtjyKYwcEOdCYh7XMCB+gWsZgJYBaPFBywCf/zHYoWtZDQ0DYjHkqoA6 cGZLA9AI3hy9gKfOj1k3ZvJhJh9mGcQsq8UFsG8h6i9DK9PoAC8CiiHzFFAGXglUAdWAE221qJeh 9qD2An6gGfoVcQl8kctXuksshT+duF4G34h8vqWwapjhoUHdQ+hfAn8XAMynTyGfnNwrF8hseCHm y0F44QL35ePg8B/uNPHe1ufexf4WAK6e5DOPpkRjxAVdP8BsWqr3wlcXELvRZOGxi0WAzbsE9WPw iT7XIPwxyOMFD+O5fvjt5ThZluNkGcTJMgjvrh7y7DxI3fFu3Fp5Ngwa2dDFtTp4DEuw7m6su1v0 oa0Zd8vhQ/bwjIRUTNNi8CU8E1Yb99ZdPJ/Y6krgRawIbxqxJ6Bno92wrduIPMuxAXEeJHWtg9DY xfNKt6ULke+GLasR9W6xAqhEWxW3rUSsQc0iv5RHfzU80S02AR7AC/iB5uhqSoN3rsA7V4a8o1vR BSsuGF7qMjw0wLM8l+8J3c9PAiz//jdkdM/4xBL0l3KrusRy8ArUlWivQl0NsJysQV0LLAVvQO0C 3EAT4AdYfpoNrw7wmRdD45KhCO+CxgFK4HbFdp5u1y4jIweRxQv53mf57IhlNjtB2M7BWxtOlLg8 GjC8vAuxGzSygMVvhpFXJcY50IXs43FB7sei/RhG6Vk3gKiOZrbxfc72tWpEstvI1a64PbLa0M2y qsuI3gW8WZXyM0I/rxqxkuGI9stc5im0lAClPL+ZPN+nbL1iPc/3AX6iaICPWzBIIzAaOwxg588d DexEe5nbyTy2dGhOXVMjtGvG2TQsdjZB06Bhx6ChYRCjmQ2DXFLEmEG+RxONGQfj7B2IO/kGmZ1Y 65Nxe1tDhCxD454asvKOhfwEN05NzITzCfGFjmn8rChlvo87M+oM3cwekbcyb0p8BqaZnTjmOBv1 9cQ832B4n0m8bPTu+mgvX7WJR90Zd0INi+1p7nuWF9zvOGN1jxmrgeQISM6A5AzqwXiHcRbeGTGa j9CjdA57Rh/JfOAzMixhyGPx1sdsSxyKfsyfd6Id8+UgVvCRXnjpKeNqGfdeHXZAI9+VPDbM27H4 G3fXhiF7Yh6NWR7rZTOJQ+tNGLrj3Tl5SnDylPA7fiJ/U/g/vSWI9BD/b09EI/ERKJXYN7+T8ZHo QXxMNAMfGVIP4Zn4YXwS6BHKxvvNHHyG0ZfwsdBX8FHJTg688xXhM5x+jneoEbQPnxThAWEa3S08 KDxIo/A+P4NGC28Lb9M9wrvCezRWeF94n8YLHwgf0ASR/dGUiaIsynSfmCAOo0miKiZRmjhcHE7p 4mhxNE0W7xHvoSniveI4ekCcKN6HzE0VUylTTBPTaLo4WZxMWeID4gM0Q8wQM2imOFOE7WK2+Cg9 LOaIC+hz4kJxIc0XF4l59HnxCdyLF4k2sZAWiw7k/2NihVhFXxWdiIpDrBVd9KTYJDbh6dMr+qlc XCGuoCpxpbiSqsUOsYOcJCgVSg/7lptO0kwi10ZgCwnuE6i3AtvBT6PuA3YBewzsB140cISo0Yn6 GHASOIMx51FfBK4A14FbkBEBM5AMjATGAlYgDZiKMZdRZwGzeZ/gvsb7BfdN1HOBHGARkAfYSGhC 2BuLgDIiTzewDeglwdOPejewTyh1bXFnu01NLa497vyqYneF66LbxXHL7W00uzeDb2ssalJ5Xdak Nl5yh4CVrq3uea7tQJ97XnWme17jS00FLsW9wLXLvWBI5pi7EG3z0DZP11+9trHLXdzY4y527Xfn 8/4XUZ9EfWfeUBwvdl1BDTSKGJcM2evALfdmXG9utLq7uV2sPubehjl24/rwUH3dfZTjlvsEx0X3 aeB8Y5r7RONUYLb7NHAe40835jUpHDnumzEeW3tVcdMEhsZA0xSOFU2z4Lf8xg73BraGxh2wcwvs 29lEjQNNc5gvYj5ovNTkAErY2g0fQx76GazumzH/xQB/LWY+jPmN63rljj7XEaz/TJzf9rgLedz2 w4Zj1euH2j/aH+dH+MTFgPgWx/m6LT72nyDjbRyJdSe71wDrwNexeIBv4O0xjNXjw+IUDx4zsx43 2NRr1P1G/Pph676Pxq8xC3Fi8ZqLGM01YsWwo6mdwwqf56FmQHvTqiaFwZBZyxHfzuK7CJiKfNli 5DViDN16ftv0Gu0n0J4Sy3teO3l9E9djUK9BnRJrb6xHfoSRGwzxXLvDkUOpyJ9Mjg7485i7trET vnsG4NfV6xs3IafuxGol3y9FLAZN82PgOREDy43XDf4GcDY+92L7EPuO9V1qqsK1F3Ud4G686r7c eKPJ33jbqPU49ML/h/i67uyTy8A1lvfw50L4LZf1c2x0z+R7kuWBaMT4AGKyF/vAqF17mlp4/vOc 5PsglrOFmI/Vk5iNejvq2NkQn7NGDrJ8RIxcLOd4Thl7X7vBdABXsMevuM9rt7HfjwHX9WuPCevI u3Ot54dnEkdcrsTWxXPBrMedX5vZNfTHrsWmFAbEdJYnHWvnZ0JTS2OHJ4OtxTMT9mGferJRn2Tr YueHexKHGHd+wXbcXSz8m1Pi35ma+belifw7zWT+beYI/j3mSP4N5r38u8v7+LeWn+bfGKbx7/sy oOU34lsi7ifSRGkiidJ90n0kSfdLk8kkPSA9QAnSNGkatD8oPUiJ0nRpOg2TZkgzyCI9JM0iVYpI /0bJ0telf6e7pdXS0zRG+qb0TbpX+pb0bRonfUf6Dk2Uvit9l6zS96Tv0X3S96Uf0CTph9J/0Gek H0k/pnTpWelZekD6T+k/aar0E+knNE36qfRTypB+Jv2MHpT+S/ovypR+Lv2cpku/kH5BWdIvpV/S DOlX0q9opvRr6df0kPSc9BzNkp6XnqeHpRekF2i2dFB6mR6RBqVXab70R+k1+oJ0XDpOC6U/Safo S9Kb0puUK/1F+gs9Jp2TzlGedEH6Gz0uvSW9QzY5XZ5KT8pz5BwqkRfIC6hGXigvolp5sbyYlsm5 ci7Vy3lyHjXI+XI+ueQCuYAaZZtsI7dcKBdSk+yQHaTJRXIReeRiuZi8colcQj65TC4jv1whV1Cz XCU7KSDXynW0XK6XXRSW3bJGX5O9sp9WyAE5RN+QW+QW6pDDcphWy21yG62R2+V2elpeIa+gtfJK eSV9U14lr6JOuUPuoG/Ja+Q1tE5eK6+lb8udcietl9fJ6+g78np5PT0j40PflTfIG2iDvFHeSN+T N8mbaKO8Wd5M35e3yFtok9wld9EP5G65mzbLW+Wt9EO5R+6hLfI2eRv9h7xd3k5d8g55B/1I7pV7 qVvuk/vox/JO+Ve0Vf61/Bxtl5+Xf0M/k1+Qf0t98kH5d/QL+ffyH2iX/LL8Mv1aHpQHabf8qvwq PSf/Uf4j7ZFfk1+j5+Xj8nHaK/9J/hP9Rv6z/GfaJ5+ST9EL8pvym7Rf/ov8F/qtfE4+RwfkC/IF Oij/Vf4rHZL/Jv+Nfie/Jb9FL8pvy2/T7+V35HfoJfld+V36g/ye/B4dlt+X36eX5Q/kD+iI/Hc5 SoOKoEh0VJGVBHpNSVQsdEJJUpLoz8pwZTi9odyl3EWnlLuVu+m08inlU/SmMloZTWeUe5R76S/K eGUSnVdSlVS6rKQpafSWkq6k0xVlijKF3lamKlPpqpKhZNA7SqaSSdeULGUWvavMVmbTTSVb+Sx9 oMxVPk9/V4qUIkFSipViwaSUKCWCrJQpZYKCp8ZqIUGpUWoEi7JUqRNUxa00CcmWREuiMMLyM0u/ cJeKx1/hHtWkmoSxqqIqwr2qWTUL49Rh6jBhvIp/wgQ1WU0WJqoj1BGCVU1RU4T71JHqSGGSOkod JXxaHaOOEVLVsepY4TPqOHWckKZOUK3C/eokNVWYoqapacI0NV1NFzLUKeoU4UF1qjpVyFQz1Axh upqpzhGy1LnqPOFz6nw1T5iv5qv5wuNqgVog5Ks21SY8oRaqhUKB6lAdwlfUIrVIsKnFarHwVbVE LREK1TK1TLCrFWqF4FCrVKfwpFqr1grFap1aJzyl1qv1QgkJ4myx5c7zcyWeRyvLSKjGc3Qlnokr 68G3oNaAABA2sALoMNBJVJWO+hlgE9CFMXj2ruwBdgA7gQFgL3AAeAl4BXgdeAM4C1zCmO2orwI3 eJ9Q3cf7hWo8t1fexhwmYBgwAhiFdjzHV40DJhHVVgF1gJuEWj/qFqCd7qXZtIDy8GbEfnrHT23U QetpM95V+2g3HaAjdILO0hW6KZiEZGGMMEmYKSwQ8khy7HxykmPgyXTH3idxcjtWOU46NjrOgIUd bzg6HWfBvI5DjjbHYbA6x4sOv+MIWJljp8PpeAms0NHvKHYcAst1bHEUOLaC5Ti6HIsceFtxZDvW OBY41oFlOtY65jjWg6U5NjmmOjrBxjlCjkmONWApjirHGEcdmBl6kx31YKMc+Q6ToxBMdRTYbzoc YKJjrv2KI4dE+w3HPPtZxwKwy44p9hOOTLAzjqn2I44ssL3oPeAYB9bvmGPf7ZhAJvtJxyJI5EHC Zj8GHSaUi9Cah1ab/aKjCNKr7Cfta+1Yv3OH/Q37CufO/7F7osx/3oj4TxrpP9OTyH+eZjT/aZh7 SEBU2vBmrCJeU4nKkEdlyKMy5FEZ8qgMeVSGPCp7wwByqeySAeRS+UrUsLIM+VOO/ClH/pQjf8pH AcidcuROOXK3PANA/pdnA/OABcBiIB8ojGsvBiqAWsAFeIEQ0EZUjXfKarxPVuN9shrvkdVnaKo9 3Z4BzASyq5PtC+yL7aPs4+yT7IfsFfZ59lp7vr3Q7rJ77cX2EMo2+0p81tjX2TfYN6Ol274Nn157 P/hu+77qRdV51TbG2E+Rwf9YoXhNfJdE8T3EwsRjofBYJPBYqIjFI4jIZ4cichci8jiNUZ5AXMbx uIxXHIqDJiIu28hq2Y7ofMbygeXvdL8lihhN+f84k0DzSOOxziDzP48TzgtzoVYYKAwXrijsKOws fKaK/XSKWXxHfAfkunidBDlbziZRyVfySULu2cmkPIkMlC0/sfyEFMtty21K+JfGCCmX70Y/qcJu wpnjhK3OZGAkMJbEMHLNaQXSAOSsM8u4ng3MBXKM60UG8gwZG1A0BMGpkRgxkYhzUYwM4zU5y8BH gO+Pwy60jQLG6WBtSFExMkkfz5FuIMOQnwlgpZF5wIIh+Ts24ex31gM4950BroPZzMcY85IT9wHn Ci4nRhYbbR3/AnD/cD4TB9xDnF3cH2JZmMSnVgyBnD16Wxmbewe3jdvHr3d+IvT+AVaLf7Kt8u1p 3awt9ARau23rm/tbt2m5nuTWXq2geXdrv5bbvA+9DrTs1kpQ7tOqmg+1HtLqNH/rYd7Sr7mbD7ce 1fzNR1tPaCXNJyDD5E9j7O7W81oL+GWu7ZpWgFnOawvBb0LyNCQLms+HybbVvymsaO2e5LDKW1K0 Vc2XW7u1tc3XwmO09c2HUW70OFFu8QTCE2z7m2+GU7Wt3svhKdrGAIUzte2QmaD1+arCs7RdKOdo e3jLfv+l8HztxYASXqgdCahoOYZyjG1/IAWjNgbGhHO1k4EJ4Vm2M4HUcIF2JjAl7EB7CiQvBjLD JdoVjK0CTwG/GJgVrrMdC8wJu7XrgflhQrkQ9sNvYb92K5Db2u8RAwWt+zzmgKP1NHgJ1rg+sJ2t Iq7cHujjHKUnj7ew1W1E+y6s6x9Kjy2wJ+zwFAX2Y71VgRfDW1AeaT1kux44Fp7gKQuchJ5PKLU9 gTPhrbxkkii1LbzcjrGpnuRAVbhFcwTqYK0zcDG83VOP9j7NHxpWutszMuAOk2dswI/SHGiBTCBw PfyiJxy4FT7i0SC5y9YeFFvPLy0JtEPGyj2gj0oL5IbbjZapgVXhVZ4slGs9swNrUc4NrA+v9+Rw nfHlosBGeG9RYAsvGV/hv4p82+7bEz6m7dK2hk96OoLmsOrpDCaHSzzPYJY+rGhX+AzPt16+rj2I xdZwim6hlhu4gqxj7fs9m4IjW0/YrgfHhi96soJW+HBV8+7wFdsx+P+6pyuYFr5lOxKcCu/1MO7Z wbjtSPPuiKjdCmYhP1nsjnl2BmdHzJ6BwKxIsmcvLO/1HECed/O90+95KTg3MtIzEMxB7yvBRa39 iNSZiOh5PZiHsW8EbeH5nrPBIqyoz7aKceTqMW2/pxN8Efy5D/K7wmOWrmfccylYBnuuBp3YU9uD 9YjpraAI22xBLTLWM5LzG4EXI1Z4PjeSZrsVDITPeG4390emek3BcCTLOwxR6AZfEZntHcF0ekcF O8KpOtf2BDuRCWzsXO+44DMYq/NJjNvWBze19nrTg12lh70ZwZ7W8ywfImnemWxF3mxo2AarysDn BXcM8QXBnTgZmK9SsSJw5B64dzHj3nzOC7GiE95i6MnxVkAPj0skR3MEByKLvLXBDrS7uLXe4N7w BG8oOABrtwcPgLc1jwuv8q4MvtR6yDM7+ErrIe/KwIucv845dod3jaezdDfOhPZInndd8I2Izbsh eDZS5N0M/WXadltfxOntxkkygZ1gkWQuWc9miWjakeClSA729XmcWkcCmZEcjxmWnPbO5LHIMfjV 8BjvNk9ypMzb6/OXTsIuQLbbbgW2RwKam+UDfH4j7PD2G36+Cst365ztQd3/fJ9O8O5j89r2BFKw 6kPB2+Ej3sMhE9Z+FDKbEdOrpSs9Nv/I8HzvoeV1YcV7Yrk7XAXu57yF8zvtR0MhREoLZJau1Byh EcicY6FRyJyS0Das6FiwJ5zqO+Lb09btO9Z8rW3b0hJ2F/CdXN7e1uu9HOpu62dnbNtujzXU3drv O7N8FeLIue06O3t9F5evbdvnu7J8fXi+77qvve0QvNfSdpid/G1HcbqqbSc8OeCnMXZjeI/vVvPp tvNon9V22duPk/8a2rcgB7YFB9qu+cXlW8MbvUfh7c1+M9oNDvtnhTcuLWkRkdVHAn2Rs76LLWbM u7ElGZmf0zISJ0YZO8e8I1rGYl17GLetD43DLsZc7PwMTUI2nkDm7Paexr2p19MZSm896j0dykBW nw/NhOcvh7LD7d5roXmt27w3QwvgpdxQdiQNfluMnNweysepshCSqeyuEQnbVoUKeUtxZC4kKyIr fBSqRSafDrkiHT4l5I10spMq8oxP9Ze1HvKlhEJh1VscamN3KG86LO/0KZFNvjGhlZAsCQ6Eb/km BCjShRnXIFL+0LrW077U0Abc6daHNmNPLQy1ISu2hbojPVo7u6viHpQaLvFNwdml+jI9Z5HJJm1j ZAcy+QROoa1aSWQn45EBzL4Y3ljbfD6y1zcr1Bs54CkLbYu8BG/0R16BnlmR13Fy9kfewImBk1Db w+z0tbRY28divdRu9Xe0pLWn+TtbprZP9T/TktWe5d/UMrt9tr+rZW77XH+P5m/L9u9oyWnP8e9s WdS+yD/QkteeZ9sfuhxO9e9tsbXb/AcCF9uLsK834QkB92uspbClCHwL2+/+ZMSu3/9SS9nXHJrD tz2yiOVP5Abi64wsYvEF39tS316m7WnRcD7sbwm0O/2vtIRh1euwqt7/BqzS/GdbRsbOENv2lhXh W+yO0B7A2LHhdpyouNtirg7kVSf4HuQVOMur8B7IdIbb9fzxHuWc3x99F3G32uJd2ZIcXhXjgT1t +7z9LPe8xS3PsNOAcW07eCr0bGq95r/U0tUe9lgZ17a2dIVneRe39MTyE2OHuOZu6Wxf4TV5b7Z3 aFt8eyJO/9XlE9o7/WnBHe3P+G+07EAObMcJM9J/G08+fb6tuA+msti1b2Kxa+9iu0NfReSs93Jz /9fWsp3LvafvjpPh1GZTy07kzC2sdKNvQrAnclbbGOqPXPLNQSwuaQvxBJXqm49MuIrzZ1ZE9OFp MHIDeyfEcj60m5f7IJMbOhS57ZsfOtRmYvIoC1AO86wIHS4dAflsROdY6CgrsfvG+BwBahthuxI6 0XqT5RLa+VysbBul9WkXcXqU+FqGyiptYds4vdR2eTrbJiHzT0e6fHWh823pvMzg5Uy+X5zcfud/ k/c1UFGlV4LfexT1w59lQZBGJEWJNKFpmrBQASTIoV6MvKoixIWqghjaJsQQYghtkL8FpAswrmtc YojpGKeXsR1jeoxxGOISxhjadljC8RhC265LjEHbsBxjPMRhGA8xsPfe917xqhrbTmYmZ8+Z8517 v1v33e9+97vf/e73vUcVT4o06JFBj3va5vfdbGpuW8T8jJHZ1NHOvAVN3Q3FgDuaEl+Ka7jVrvVu JWxB3GltOujWv+KCyLTiSME/rQ332sO8DrCk1Lu9qbdhZ1Ve01FY0bCm2k0vLTYdb+r1ehruNvW+ tAievN4Z79a3x4A/wRuvtDaVtseDhrn2xM5dTdtgpbc2ngI7W3G+OhcQeysbjv+XN7zVmIe91U29 IONqrMSZBTsrwJJJ6L1WOpWBthTZnvqmE+3pMFI4nXobm067jkLvwH/pQFNxu9Xb5lpoa3tFaOp2 nX7FtbcKdsnEprPteV7v3oj2Qu+BpsH2bd7DTdr29FeONA23F4P3RtpLvX2AK7zHGirad0KWONq+ a988ZEhv592m0Tavt5/2iEXXlZb5LtYcAaf3RcgSE7Cuo/a2ek81x7ZMdGlhp2vtCsMTeJfpS3hH 0N9YCVf78TzfFYN0VzzRiXurkMYdsyvFtQAytch/JaphBOhqzGxd6Q03Wha7GNLAJ3rvJbwHaTbj aX+v0NbWZYW1w7zVjUboa37vFNqDa6Qrr+k02FDYnIT85lQffxvxi4kuRdpb23i4ZfwlC94veLfu NYP8bHMGyFQ0PoA9ax7HAvsU0F07iYYMjBoaBpvveyeas4He1ZzvOti1m/i7kN+1h+hmktnaLLQd 6OpoFtvPdp5tFtoHiR4GWmwf6epuLmkfBZwEe/Q87acjsMu0dR1smIQ99ybReURfJLqX6Nq9Ue1X YE+fgdx4Uk03XgcfJjW7MJIb+8Hmo8072rVdx4neRvQJkJ+EHFu1t6brtOtg+2RXYnMN0GeR3zXY XNek7Tr9HnqY5EeaI9pvwLxnuCa7RiH+b3RdadjlutI1qaJvEH0Laa8FbM7tugtRmu6NJroUaczJ Ct11D88ncIa0tIe9MgX7WhucARraw7rmGsfxThDOMLc6d7kGm1/rWoB1dKvrMZwHbqL83k6YI3+a zgl7OzuPQ5xcxDPP3k7a0S5288383s5uPdJdV4iOcC00aeFUk9F+tzuqubX9Xueu5s72OciKt9oX Xplp3t/+uNPa09jT1uNtadtn7Cxsadxn7CmAleWFaISMBDGDd5FzmLE7K5quwGoSJdwS0nGh+40W Y8el7nMt0a17us+3xHWMdV9osXRc7b4k3SO3JLcWd4/hnWb3VbyL7L7WktZxDU4F0h0u3dvKd7Wq O1b5XpXuUlsyO6b871Wlu9GW3I7p7qmWgo6Z7umWrR33u2daHB0Pu++3bO941P2wxdPxCFqRnpbK jqXOmJbqfZruR9hv9xL1m4799mjku2m8d07He+eeELSkx0iWpK9Y0hMtjULKkHin3BOH98g9cdK4 8M4dNNP9NeYlbAtxPoo7SI8Fd5CeZOT0pOEa7Iluqd1b05MpaztOdtbvC+nJbfHui/a2SU8npCcG LQeaRnq2NpTCOWeo5fC+uB6H/CyC7vpb+vZZera3HNuX3OORnzmQ3+SnCnT/3jKwb2tPrfzUQno+ INHS8wpo1bWtpX9fmvdiy6l9mV0nWmr35fZUtpzZV9BTjf+tgn51yFS/OuTpV4cafaHew4Lpl4Zx 9EvDBPqlYaK+Ud/GXtDv0/83ZqVfEdroV4QloR8JTWelofdC77Md9MvHF+l3jp+DPjJYIvs4Y0xg n2WxrIq9wjLpPU6lrJd9g5WxfvbXzM1OQSlnZ9g5VsF+zIbZi2yUvcNeYtPsN+xl9n/ZfdbEFtgy a+d4LoV9jTvIHWLnuKPcO+zvuV9xd9k/aWo1X2Z/0JzUfI8tay5o3uSCNFc0b3MGzazmt9xazUJw EPeh4MTgTdxG7UHtBW6TdkT7JufRvqV9i6vQjml/wX1G+791Wu7zOoNuHfct3QZdPHdSl6Dbx50y 7DPs54MN/9VwhA83fNtwjF9n+CvDGX694YeGcf45w9uGKf6Thl8ZFvhPGf4QEsV/Ef/SxHeFRoSu 4btDTaHr+P2hvw6d5Q+F1Ye9xh8N++dwnv/H8PXh6/m3wzeEb+SvhaeEp/C/DH8+/Hl6u3Upq6Un pfH4ey3bUYDjACcATrNY23HbCdtp21nboG3YNgLUqO2KbdJ2w3bLdtd2zzYH9YLtscALeiFCiBJi BbOQhL/9o7llepvexni9qBfpN5ImPpVPZYzP5rMZx+fyuYznt/BbWBBfyNuYhr7PpeWdvJPp+DK+ jOl5N1/BDPyL/IssnK/iP8ci6PtcRv7L/JfZWn4vvxd0NvGtLJK+z7UO/J3IYrS/0P4Cn/ezG+wW jcyEv4i0VbMqW7Wt1lZva7S12by2A7bDtj7bMVu/7ZTtjG3ANmS7aLtsG7dN2K7bbtru2GahfmCb ty0KTNAKYYJJiBHihUQhRUgXrEKeUChsA55JKBZKhQphp7BL2C3sEZoFOMzbFlcKyWCZExaomHzl sVwOCr3C0U/wwnEAJpwQTsO1s0ANCsPCiHBPGBWuwKdJ4YZwS7iLv6/T/Q14M9ovzvF/KGSyeoja XNYCMV9IcW6H+D7HnBDhP2bFEN/vsE/Rm9RKyEef1m3UbWLbdc/qnmVluud0zzGX7nldGnPr0nXp rFxn1VlZhS5Xl8s+o8vT5bEduk/qtrHP6j6j28Fe1FXqKmG9cOw4rCT0sgVfkQYxw2xnAQYBhgFG WJ5t2jZju297aHtkWxI0tkdCiGAUooU4wWJ7KCQLaUKmkCsUCFsFB+DtAB6hUqgWaoV6KI1Cm+AV DgiHhT7Ax4R+4RTwzgBvQBgS2mxTtqvCRdtVKGNAXwN81XbOdt52wXYJf4uof1m/l35tGuLnrRYo meznULLYu1CssOp/wz7GZqFk60p0JSxHV6YrY7m6al0128y4sPlw+m84LAXfAVcaARDFONcc1LEA ZqAXAB4HZZTqXXcJIlz3CJCOcs2VxroW6LPZ9bg0yc0TP9WtL81wRxAfryNPkVPaKXS2O8qnG/nY FgF1KTTqVuh8dywBXsca+1GuKSC4zXRdaYc09oe1AiL0J8rjwb5LoHaBjVgH6lvNJrVtanhS20DA se5wJ5FfatypvrErdqEteB39o/hVXAWqoE81YDsFcCwKKLahz7Ad6qyDPhXfKH2r5xB1yGMsCHFn +PmxRK7xuiKv1HitwZ3t862iG+tW2QakO935VO93Cz6/K7XSN37G+VRqxUb0F44Jx3DILb6nvTI2 pT7iLil91e0qfc29w89O9VgCbRUD/KDUsSrbcDyK/wJjoUpFq2NWL49B8R/yFB0n3VV+fSh1xBPG r4w3ImD8ymeMH6SVdtCXSyvxAmufzBvumtJz7rrSR+5zpUvu80/0y2p16we8/jS5P6WfKtm/ip9j A+br/erWlc+uMGncT6p9fgnwtcsk+elptW/exVVq9TjUsY/1eXeDL29ccLeWXnJ3Eq3USk5W1ueY e7/v2lX3IeoX417J19fcR0qn3K/6fKZfiQ2qp92v+caI8jPuk6X3Qeah+w3fOpfblGncF8pC3JdI jxKTUJcZ3WOooyzafdUXr0ot57qyZPd0WZz7GvkwxTPkSvdcdFk9l115nnHM665CzwTxtnmuu4o9 N0muFHIi5svAOQYfumJAfyAf1n9Zv2c7xX3FSh++Od/puYNj8Pn6abFXFbC2A2MqMF8F5iXZR2iT a5dnVskhrt2eB649nnlXs2fR5yulz8B8rMTNavtTAL/M4p4iPyOkuWfKMt331ftUWa77YVmB+1HZ VveSny5lnwUoc3g0Zds9IUR7PEbacxVQ9FR6oqmu9sSV1XosZfWeZBr/E6Cs0ZOGoMRdWZsnk2qv J1e9l5Yd8BSUHfZsVe89ZX0eB9XHQAf4keZXvbcnSXFQdsrjwfHSGM94KssGPNXUbshTq/ZX2UVP fdllT2PZuKetbMLjLbvuOVB203O47I6nr2zWc6zsgae/bN5zqmzRc+Y9uXC1vU/ZU9R5+El1YHwF 6lP4uI9VqeJttbzfuop+JScq5wNlnShrXq+KJZTDWIyX9+f8ldqVKM23UvvgaeN8Qq71i2V1rayb iIB1FLj/qXIpjUdV+/b9gJzkVz/J3pIAfwb059srA/fVwLpOle/UtTInSr5Olfz9lYavtCrrzdVR znAduLrLta6D5WEu5hkg6C03IfjO4Yo+RTfad7Q8xreGsR/1+VhZf8rZWG5P+Rv2Cdfx8njfukc+ rDtcf2p9rhPliauevWW9rtPlKX7rMCBHKbnIdbY83e9MhNcwJw6WW0v15XmlEeWFruHybUSnlheX JpWXluaXV7hGynfSZ7heKpTvoutwzXWlvJn4IEO1rINoc/lukhkt34N38fqv6/87Y6Efpf9c9bvQ 3zH8j6xJf9nnK8FBbJmeo7xIz1Fe0o5o3+L66AnKq/QE5QQ9QZmkJyi36QnKu4Z9IVF8IT0XuUHP Rf4PPRf5JT0XuU3PRX6Lz0WCYvG5SFAyPhcJ+gg+FwlKx+ciQR+FO9qT7I2VpwdWnm2z5lsFq2gt sbqsO6yp1iprjbXO2gC4FWje2mndbz1kPWJ91aq3ZlhfgysnrW9YI6icAzhvNQO+AOWSdcx61XrN GpHptU5Zp60z1vvWKCgPrY+sSx/TWGOpmK1J0AuWDNKIn2IJskE2w4qvCOX05fj9yYB721aYkXa2 D+5qz0LJofvcXPYLNgl3stegfJz7GTfO8jUTmrdZAT6vgpYc87BK1XjNzCJbkAH9SSPPkMeujLxV NeZDMGIc7zkY5xtQzoNUlfUC2YhP/tbRLxIZRE8S8JKh8HAvjf9vNxWKhqWxF1gw+yjLgPvrLJbN DGCTwMLZVigRbBuUNUyEYmQOKGtZMfsUWPpptp1FQcx5WDT9l81Y1ghlPeuAEsc6oWxgV6DEw9jf Zh/mIrgIlkDfDu1YGWvR1aCMoqt5c0XXiqaKpvMPF80U3c8a3zJSdL/oYdGjoqWia6Km6KEYIhqz PKIx764YLcbl14oW4CXnO6yJeffyHotpYmZWv5iL2Kq1snyHWCBuzerPr80btTLRUTST3/ZCtbi9 6GrRVdFTNE1ajaDfV8R60ENlS2ne46xxsRG1KMXKpJI1K1ZCy7Z8hz0GdQF9QDz8QnV+LdDTBNNi tVgL7TUwnmvYC5W+oodgnxHtBiumthzNr4VWh0Vv0YyYBtLHxP6ia/kOhKxZ0PNQPCWeKZqyJhZN iQPiUNF03j3U4IMlKyMAeTEENIeIF0n7ZXE8y5M3Khph1AjQmwwT4nXUq/RCGhUAGxDEm1DfB60A Yp/YiAU9Id4RZ7eMiLmbwUYxE+QeiPNg4aKdKdrEELsW+/frG8AeZjeJ0eB9GC1YCZQCyKGWIEV2 /SkwbT/uZ78f2I9njWf120/YT9vP2gd941XBanzk2YdXLPcbBfDtIzjLEqAN2IfP/mt598Rke3x+ G+BEiMo20jpVdM2ekjVrT7db8+vteUUz9kL7Nntx1njRfYpTZi8tWrJXgNRO+678PtFr301zuGjf Y29GT9o77N0QO5kQuTCH9oP2XogOj/2oWOCsdzY625xe5wHnYWef85izP6vAWSC2Fc04T9FsQg/O M84BBPtB5ykxV2qB15xDL1RS7Pi8KXlO7MubxBlfmVNRA7HVB+tuFmAeY8t50XmZdI87J/Lr8+ay 6ilWj4n12AJ9k3fPmphVAMXjeMNxTqGpFDjOQ+ykQX0B4BKMn2X1YdlydstZx5jjquOaY8oxbU10 zIB/Chz3HQ8dj7aMbhl1LIle8U5W/8frHHy+w6nZnOwMcRodNc5oZxz1UG9NdFpgdV50JkOsQx/O tI/z+QX2PbSeoGdnpjPX3gu+q/h4Xd4VZ4Fzq9MhLjq3Fy05PThLzkoxE0eSNwczOGq/Yp+03xA9 MCpYgfZbAHftN+wwMvHYZq/PX8fsc/YF+2Mcff7hvMeK34vuO3ipFjMdekeEI8oRi6tI4W3uB92L DjOCIym9w5HqyCh6ZNX6gNa2vduRDX0WruQF37xoILch0Lp35AMIDjG9A2PHUeJwUQzJNEXRDUhg OxxV9j2OGnuho87R4Gh1dDr2K9ENGdUBsoeklek4Atm1DQFnU8odDt7xquM1x8m80aIZiP6HWX0v TmC2dV6HebjuvOmsdtY674hbMR+CjQ9h7lPthfnHxGTIzo9hTEwsyOqXsjHOj3NWPOa04MyLBdB7 svOBc965KKYVs2JtcVixSSx4odJ+sDimOL44UfQUpxSnF1uL84oLi7dlFRQXF5cWVxSnFD3M74PZ MmLOhZwN2al4Z/Eu9AnaXdwsZUqMYJjV0eLdxXtoL/z8f6ATVA2rp2fm+D/lWVoj4wCi0vZAaYbS AWUnlG4oB9OupPVCOQolBcpxKAehnIByGgryzkIZhDIMpRTKCJTRtFH875b6F/U76b94foJ9Evxa BAs7iDnhdKBl/xm8Fwp+/iyLZFzYbNhDsoj+1pUzyLi8PKiHoS4Mysg5m/OYYFAGpIcBRuTPowBX ZP4kwA2ZPyLzRgLaKfQtuVb4kzJcUdGjKvquDFfk+obqmgL35OujKl2Dcq2AejxKrdgYqG81m9S2 qeFJbQMBxzon97mgGrti14h8/VaAvYEQ2P+ICgZVoNh2V253Re5T8c2kiq/M4YhqjI8D/KjUkyp5 pYZrubzKt+prig1Q5+rlOkJlw2BA34PyfCq12vZRqc6NWqX9cI7fGHNjAcwASf52+o0l0NZAPwTW gX0GzoUa1DGrjEHx390VHbmp79PXauMPtCGwvqWaB6V/hRdYyzK5GQDZAJ0A+9/HL/+/1Ip/lfpJ 8/WU2jfup9SBPlb89LTab30F1pOr2K/oz8/xrZ1cAUCUaVElp4rl3BKVjEvST3Ev5+vcHQBVKp+p YwPnvybHbx3m1gE0ALSq/K7EyiGAIzm+tehbk6/KtryW459rhnN8uS73HMBJid58GKAP4BhAfw7l 9c2nZN4ZgAG5b8yJC6vMoTKGQD70tTlZGpu6D+X65iFpDH458GmxFphv3y9frZaXRiWbNl9c4W++ DDAOMKHy1ZPykDLW1fanAH7uG7KfEc4DXMjx26dyLwGMAVwN0HV3BXKvAUzJ9LQ0Nz5Q9MzI9X2A hwCP5PE/AXKXJFDibrNGrkNy/PbSzUaA6By/PL05Tq4tsh+TVWNXAHy1OU0aL45xcyZArtyuwN9f m7cCOAC2A3gAKgGqAWoB6gEaAdoAvB8gPtR7yvvl5Q8ab0qtrK0n7T1PqtW5Ub3WA2tlzp9U33gC PK3/p+Xe1fwXuH5W2/+fVqty0ar1nzI/ar1P2DNX7X+1elLVv8rvbmWecA1cl9bB5psAdwAOyDAr ge+8qrRXdGMsP8hZWcOjOf7nY2X9KWdjuT3mb9wnNs+v2EBrL1paf2p9mxdzVj97y3rzWI7/OgzI UUouytPm+J+JJqV1nBe2Mr48kyouZLm8mIA4kf2dl7jiS9+8qdcAysTnPMbvPdFbFth/nHtNrhf/ Cz8L4yLwxSYpIwCjAFcAJgFuANwCuAtwT/48B7AA8Fj6/Bwvg16SeS4CIEoFsSoZM0ASQCpAhtw+ GyBf5gt/BogAJSpwAeyQ7agCqJH6Iqh7H2hgBSnNKR0p3SkHU3qfaU05+kwDlpReVTmuUM8cSTmR cvqZQ/L1EwBnnylJGUwZfDYRMdYyNSx9AskTJIdtR1JOp4ymjILEFVXBdzCY3vtNX3qziIbeKfIh endINL075Bl6a0gcvS9kA33H10zf8X2e3hHyUXo7SCa9FySL3gtipTeCZNMbQXLoXSBb/uL9cZyJ k741O8yeY+xZiKVnFwLgsQyFUp0McZMMsZUcoQKIq2SIq2SzDLwMSXKduqKLZGHuk7MlIH7hCuA1 y9hT4blne589GlCOv4fz/vxVCr5NkL7JzejNMdI7Y4Lpm9wh9E3ucHpnTAy9JyaO3hCzgd4NY6Z3 wFjo7S9J9MaXZHrLy0fo/S4p/256OXaWDa78DWhDH3NumtowhGXT9AbPpplN9zc93HSfPj/CmmBp w1CSJilElhpKMiIfS1I08pIsUIxS2TSFRdGYFAcaffoIL0maFD0bPKQhBGROYTvkSz1vGMInhzz6 WMv38z+BtP4m/48snv9f/AzbqG3SNjEbZk8mhP44dIR9gt5YEwNgkt8Fk+Brr4H2J6H9KX6YBfMX QFcstYkDiWjCsj/WpzEOAd/6hBjfZsSyWb5KIoaZYiZjJtfHW+osDevj1yeuT1lfDCVmfXrMrfVW gLz1heu3kY5X8Ru4/Pf470HfP+B/AJwf8j9kPD/AD7Ag/kf8j8CyfwBrgmFMY0xPowkBy37CQkN/ CvYZYcUd4Mbo2d12thYiuZOxD7sksOxfodVgObQ6H4CzPGROi8MyZL5ruWhOt1zG+plqy0CC3jL+ 4WTLBNLK59gUy3WUsWy33ESexWO5g3zzLcssyURYbloqLQ+wRlkES7VlntqArKXWsmip38gUoLbp GwsRUCeBZ6MWoNQHYJsCYBv0vzFRtnHecnhjikRvtFpyN+ZBf5eprz7SEybbNSTb9EBlz3XSXbux wnJsY3psysZ4S//GbZZTG4uV8T/jADsaN4ZZ2jaaaFxeGK9CH9gYQ/OI7wRj9AYtzlBh+CzjDS8a djKtodpQzfSGXYYvMIPhi4YvslDDVwxfYWGGPYavsnBDo6GJrfnAMcxxZ+idZGGsEc4tLAGyYcJ5 GS4AXJIBslrCVYBrAFMSbNgF9YxUqyHh/godP7UC8JmzRBPtNGebs+MnYqLj4xIG1gG1rmRdSfw8 lIsbooBaXFdips8JjpjoD++Kj1t3HkpJwpBZMFclHIAr4/HjKANSizHR685Di/MxcTHRMdEJFxMO A3c2JtosxN8xu9bVxE+Yd/iAdJoPIcQPxC8imIV12WYhYcIH2StFsjH+gWSjuQTatSb0I50wlHDK nJTggKtxkn1om2xXNvQugmYRLQLtsj2gG+2ZN+8HOy+DFeNod/yENH6Qq0noM1eZa6A3aBs/C5qA TjgGnxrM+F6VMP7rPORo/tv8t5mB/w7/HRZiKDeUQwRUGiohAj5n+BxEQK2hjkUYXja8zCLprWdR ofOh82xd6ELoAouh95o98yflOHyjWQlAHWU5C/3GpIK+y5AnZz4LybXSNw44tlUll8F24dt5fHIc ZKPvQkTzkI+of+otnnrD9+nqKdIZRbqGIl1Lka6jSDdQpIdQpIdCpDeycNKEY2A0hmAawyay56hs 9xnqeyPxvGQ1x0ZUvKuy3Wq5YbKaY/UyD/971r/G9+j1mCeOWkuaGGniSBNPmoJIk5504JuWg99r A/USSvojnugLnt75hd6Q5iGRxtgs+6Lex+PZDnkW1XK7ZF9sk3l/ziw9bd6fZPdRNqSyW+INs5Oq 2JN4dfIsqnlH5FlUeP9Wc/hBZuFfM8ur+YJj59kVOhXE4n8fj9ruA2eUCCU2qiTKFbUDcBV82kG8 GsISLcJVMaoOSlVUA31GWpRLJxQxar8MokqjHopIoOhTNKn11FGNV1qp/xrpM47F8JLhJRhzvQGi zLDXgBHwgfcmNkAzKP9lM7IS4BRzRp6AUkj4tK8+4SunI8/66EEogE0DpsOmeiwqyRHTAIHyWdJ0 luoVDWd9miQ9jZFhEsfkAbhsqjZdjhyOHEZsuoxRbvi8oebPHaHpAcA8c5rmTAumx5F8pD4yIjIK MNaxkebIJKJTIzMA85HZkfnAM0cKkSLQJZEuKlUgGRtZAyVbLthG79NYF9lAODayFWRQm17W1Cnr qTItwDXk6Kk1gkBXdtAIqwwNf8L+wcP5/zplV2kdJuH/z+cyuGx2CT6/6sdN5tIoC3v9uPFcIuXy 3X7cKC6WdcJnlx83hDPS7ywL/LiM07JS+Jyi4vJsgc7ZUT7eytievsJN/An+dZD4G/4UZLbv89+H k/UZ/gy0PMefA98M8UNMB755k+n5y+AhA/9zfgLyzyT/Ngvn3+HfYWv4G/wNZuSn+Cm2lp/mp0Hn u/y7kHOGQ4ch5/wETuUfglP5TyE28Gz/DcJfJ/yd99DfUNFHVHSfiv6WTMPYOTMH4+WU95Q+S7wY Lh4+zfnxjBz2ftOPp+ci4NOYHw89zMFMq3jsEVuCT/1+vDnwOgd7kZo3yx7QbqTmTbMZ+FTtx5N+ Z1rix5ug2Mrz44357QUSb4SNqub6WbpHw3lllJM5ysmYjXfTjufnVUPte7x6RMX/JtFVKrpS5fmv qzz/jRValvmWqu23VDol+kt+sybROBYLfasT7yOl0SSvSIP90j0o4gHAISwYTnshPq5fvglbYixc w5zhLFwbHgZgCo8JjweMdSJ8TglPhxITbgWcF14I/G1QTMAvDi8FCSy75TqR2qlLPMiZoK02fA/o aIYaZcLkq3kAHeEVdE1qjVBBJT18J+Cd4btU54YPej8TwZXSCPfAuJkpBMCoArj/MIHfTBYAiBBT msxHuf4AOCXXZ2R6ACATIBegQPpsPMqcId1rp9eWAJ5Ze3/tw7WPoNxfu2TShHRjMYWsXcLauG3t tMm4dsZkNEWbjCD9EIspxGQxWUjOKBWplaLRlIwaAZM+UxrqQk0rekyZoFezdjpUBDouNDVkd8hx Uxzg7pDd/2Ynng+6m92hbBFG3yVmoekAVoA8uUYoBNgm18XyNZQrlaEC/NkRmgTjOBiaEZodmh8q QBFDS0IOhnRgAVqkWgCpDChJoa7QHfQZCtQlIIvXd0hFbrWisU6tD3XJmhQ92aFJIJmEukKaQ3pD ekOrQmug7gjp/TPvT/6syF0Da9MI+dkIkWmECDVC5Bohco0QuUaIXCNErjFTlnMAwGnQ6AGAU5IR 8qaxFqBevtYIAFFrLJABPmd0MKdufE1SxFHAqWuyoeRDyV4zvUbUjWNZU7JGoDp/TdIaF8i41uxY 46LPWOrW1Kypoesuqcit/DVmgxTpQ12kaUVPNnwSAfKBrtLv0Q3o7qypAjyuG/iLRy6+j3dRdQLA +x3tUv0f7yrlKTsGynM0e5iDx5azlZwc1K3tBXpGi3M7oztI2IN83QXGaTqCb0JmfqDFXWwx6Brj gm9q4S5ZE4t8Q1rQLON0cRoHcO5o90OMVAYzbLuMO9wMYpCA/M+JtAvMLNUjjTioGzlB3X+cQhnE mg7k8BdIchEx9AFY83niP0Cs2710AvjNy7CbB21HzKUu1+JJQXsPse404QTilBLuJYz239Tidy/n tOWIdRMk2YM7lHYa8FEt3sll6PTE300yiPsJs2C8P2V4FeTLiUPPEYIHiYNtmeYO0RHEv0nyrxEm DXJf1wmjtxep1SKOiC3iKIC+hleX8glnEqa73yWYt+VI1Lz0K9Jv0PyUejwPnvmBTgD8OuE+Lcw0 /ybhB4SnkB+0HumgEeJMEP1zwinEeU7zFmCBcJGEkc8tET2BmLtH9JuEGwnnSjKkJ4z0bEH+8u/5 3wPHHAyj0xzWwHk5OFUDu7rmd0hrfkr8JsTBn9G8AfQS0lwr4qBiuvpd4jiD/wGObSaS5Ah/mTRc Ip0ewuHEaSU9f00yIYQjEetE0vYuYUn/iaATOHbC/yMIoj3oneAB9Axy+O3B40Df1WwE/D+Rw6Vq 8Bz6AuIgK9FJKK81yRr+FvBbyOf3aTYA/dkgsIf7Z00W0D+hVt9EHPxVoncRPk747xBrK0nPY8Ta aeqxDvkaLfHvkeR2omOoLzPR3SS5WZNMFuJK+T3ioEnEGuLwLxPdGXQD34JOkpUkM074DGK2nnNh FBE2ENZzsBKXH/A/ov/Mko5rlsP7oJtB69FyvM/hpnn0wxLioPWwLjk+HWn+NaJ7grZhPBD9gPCv kcO/TngCOdwG4j9CDFkFf8G0iHTQLsIpdHVCE4vjlfQgzZ8m+guEp0hynOjXCXsIP8dBtuSLyZ7n COeStRqi8Z1iMCLNOcRE35Y4aAP0jjJbCHuIP0dt54nza8TLc5oM8KojuA7wOVz7QV+iGdlL1u4i +ptEn0AMMnUU8yCpuYqYf51apRAnFq8GzZJMg8wZpEgeRC+RZBhxuhAHf5XobJI/QthFGkaIrsWr unUkc4TwR0jDN0nbEmWqZbItDDG7TTrfIptbpbgiP39B85+A1lGMRQa/CDIfo1Y50hgJb0O8fAdP +PxrlOejl39P2RvzvxlpbgNdfR2v8h6i3yF6gPBBkt8t81F+njjphAXCpqUdyt0dXMU9ZZLkk0hD ErW6R7iJZJYIf4KwdO/4FmF8WwOsI3yiCDP9RcCHSc+DpfM4dpK5SXtKPdLB1AvIo2Q35me4l4Z5 h5VAuxtizYeJ3ku4lSRrNN8Fyc/gLsC5+Byk+e3gpR/xnYR/RPgueeM24LsUV+E8ZCGeo9W0nfCr FHV2zW9xv9e8C5y/Qs1BZtLvIXoWMTdPnAvE6Sa8HbEmlvhJxDlP+OeEv4Q4OJlkvk10FNHniG4m nZeI4yD5VwnXI2aLGnyqOUb4a4i5GKL7EYNVSN8mfJE4caStlyzRyxqQQ5r5dKJTCV8hPET8PsK7 CXcSv5LaMrl3pMlOdpPwG4TnZBnERwkfIlyHeHkn0dWE81BPUCZppvniTlJfEzTSa+SHrZK2ZdrB IcbxPPNj9MbyORwX4QeIgY+ZZBAxnEOQc56uXiAsEL+X8DRijYNkthM2Ew4jPEvyr5PMHdI5Rq3m CccQbiOZgyRfTzKPNZCruQzNL4D+p+BaopcAm4ONGPkYP1ww0lxUcDzg0OAwpDV4jrytxWcpN4Lx THJPG0beEwE/jzsOW695ATDtd2wL0Qbc3ZZ/QzImTSfJJxFG/r8gBtpBOIpwNp1z0gl/iE5ELxG2 EL4MrYYwtoHGd3Ksoz3UExyEHsMzJLtNZ61+wrelkxjazCcFUwYIHkOMpzs+Cc+rXKU2lfA8YuJc QknuEvEvEX+eOPPEmSfOpeBqxHjW5eYRgw2STC/JjxFf0jZGenpJBnv3kEyqpJ9keonuJc29yGGL NJYxwot00l6UrEX/8FtoLFs0/4IYWwFGDanUV6+kn+w5SbhUpvFqKUrCbkI5lux5nWx7HUcEdCrl fBoL9gVnhnqij6M9kMMgftincfbpLy/3GP4SljErYbTWwP6W8F7MY8s/hLbfp7waCdkUNCzR7kC4 lziLiLlUicbzPJxmz+NVpLlUCUsndmqVSvcCvXR678VzL2DMtEnI5z0kM086K0mmEu9ZgukJWXAU 6gFcS7m0AluR5Dz1conoY4QvUY/HCM+TzkqycI6uNkmYWjXR1V9SX78k+2+T5G1JJ57AuUrJTvLP osSRr+IZfoxajSEfruYTnU8jDcP1/sfTyJF6Jz2pOONsjloxega2lTBb/hngqOVJwPHEiSJO/PIf 4Pw/ghxoj/g8Yp6es/F6soqeesIYkZNOdKq0e9JVel7J9xGekHZqutomjUjaW4n+IWLwOKzlZRti 6AvpWMSgDfttJPwy4TrEkK9+hjOClsO8hBBNuz9azleTzBDhXpmWbMaMcYjwDOFJwv2Eb1OPNUTf ZHSXgTsm+xpH9626Kso25EPKhEzKKvStnueRs/wAOZAZcDXF6PBbK5PkeYarBrITZSRtDHk+lmaH opoyQy/OHb8F1yyszV7M1dL9snxXK60U9NVx8p4g+/AonleJDie8hfBd8vY9og9KJxDCHpSH88b/ Y+/Lo6o4tvXrdJ3qc4QGB1ARUREnVMSDogIqoiAijkE0RolBQBRFQEQkhiigoFHUOMSoQUQc4nWO c+KsibM4RJzHOMQRxxiHCL+qr9pzvffm3nffH79311vrJStff2fX7l3Vu/bep6q7ORGtPfTZnEP0 e92GJZDgLR5Db6nPbfC+BBqeA78USF6D/wW4Fzr1gcsh8QC3A7YD3oT8Hvh24GRgiUAahtYDwHRg D/TyGDp+kIQClwAXAkvRWgyMhyQcIw/HjIeLCDF0Be8B3kPEBr9qGfnie60JvFpdj0BxvesRq39g 3dUB1jYAA/Q7zHOQ70LTD/KjwAPAhXKFCc3K+GbvALQFdgL6YJ0wHlwFYgVFagEr6KsX8S0cCs1N At92KUPNLJsEzAMOBXoCNwHFqpXp8hSgqLqk9CH4j8CxwhrWuuTtS7RyXnqW8W/ztxfFt3PpI9WW 40OBPMJXAI8gbmuCy7sBL4DjMEKpI96JiNM5xkOfgf+A+H8Avg/yu+BFwEVAUakIdn/EiPELD5Q9 EPaJI3p5Ak6MkUBci5FfY+kvJj4jb2+a/MTIxXc3l+AeiBoAfATcAUwGitUdEfp8VFg/sNeQDwem AwOBmfj+LQDu4d8CfczeHA8INN4QqPoKVIBGAhwJ+QqBpqkCDdBXIDFDx1TDjPst0L+P1t7AVQIp 5Ow6OCwYiyE5BMuXwNuBM2BFSALAx0A/BViKvjSgK1qfQvND8HJAabk/9NFKbSF5g1ZPSG5Bchd8 Jbgd9MsD04AK8BGuIh+YAMksYDys9QJi5MZYoLxqR+ARSHKBkUB3YDgwAohrNA7DSOTYWuPqtgDR apbj34DWRPDd6NcFPBSIkdNfYM0HknECbTBH5TBf5hgg5DQP9qfBTmPIgyEfi3OXwc4ZYA4k8D/D XCiPca4TWpfCQme0boQFyJk3eAF4X+BtoAVyREhZfxGHHHkcKuOA6YjMgeIekeFbtbyITxH57IBA 4w2Bqq9ABWjEvUHjSMhXCDRNFWiAvgIJj/C5iPC5iO25ImKlBcFNNaRlwY33pTXBld7QWSWQQp9h FU1h31gMySH0ewm8HTgDVoQkAHwM9FOApRihBnRF61NofgheDigt94c+WqktJG/Q6gnJLUjugq8E t4N+eWAaUAGieij5wARIZgHjYa0XECM3xgLlVTsCj0CSC4wEugPDgRFAXKNxGEYix9YaV7cFiFaz HP8GtCaC70a/LuChQIycosoZfSAZJ2cTs3YJWIw5IgINcjZXCLQBlsOMm2OAOJfmwcI09NUYciL1 wYOhMxZ9LUO/Z4A5kGC+GOZOwX1skxNal8JaZ7RuhAXImTc47nWzvsDbQAvkiKuy/mIvXNa7jMd5 WVd8q64s7cbxBnCEQOoi0ABUCNAX8t7A/QIJ9A2QGKFDp0Eu9UehtRGwDzAD8sfgsKAMBd7EuQng C8EVoBmSAvC24H7AcZDkAL8Efgo0AqXN1UDIDdngb9FaFZKnkDwHLwaHNcUEbAM0AEdDpwewFSSd gS1hrSGwFiTNgfJ6bYCDIAkGWoCOQE+gK7AFNL8GLoC1i0BctZFB5zxat4BfQ6s9+FLgRLQ+AZfz tUsgk/OCOTI2A7aDZhEsHABWhrwO5DhL+Rk4DBgI/AG4AzppOCsXkjDwuuAX0Crl88FPiJUPj6sI xJXAVUBfINZFRMqfCeRRFIF4E5K54L9Bx73shbjvinXjZsTqS6we8TaOUQVixU7x3g9bAckkrBJv Q4JdMI0AT0DrMqAzrO0HbseTrFictbR0jNhZQJKEve01WPAHeguJCXs0gxtQ7gv6QtMevcg3TE6J 8Zuwp2Ny/e8k92vYFwcJZG0EGlXgOshf4jnRRnk/tjRErNgFKtliVPS4vG+JvoYAA2S/sHAOrXfk fhA+DBdIV+FaTkNzjdgTUbln9IYfUAF4xonWGxj5RsxCCUbYDxLIVYyf+4S3soMCjV2BeWIXrExG j0tg3xv9FkJfQ+8abKZKC+IuLv8S2o2d9W5ctcBKwO3ADGAq0KLLT8PPAmdDshw8A36LB5bgzgOe LVK88WXU72yXTsCuvxD9FmJ2xLn79ZEnYbcoLZwWuwNguEDuSdmLkBzV9U+jmp2GTRnVSdAsBC/E FQm5GT65JjSNbeX+BRZigAuAB2U06vFfiNiIwCzLGUzCtcPniKWNmJc0zHgF8Cmw8KPcXULfT96T gQUnXHUyInAIPJ+Ms4JltMio0HOkHOc54iwV9xlYrmhVz8BylLBjfAD7F9DjVIwqV2A5xJ75qUAT 7kuoW3ULYzAjHE3YNasDBGcE8uXw22FpE33ly10z7vPcE2icIOMHI9yNawkQb34zeQ8k0XCJy2tA Zy6uxQk8AnP6Gld6CZJCSOagr5uQhMGHY4FDgc7ArmjdDM3leF5wBpaNsACfsGOI/AxZzTA2ZDqt g1GNwFPUycDFeK7qCl6MJ61u4G+AqWgNA5ogWQ4codbgWBvPZ2tDUh+8Eix8CUmQQHIfeF3qgF+C tVj5bBdowZPfJUAHWHgO+VXgbP25s1hjFOMps6tA5gibs/WVm9DZrq/HgsRdCKxv3XQMEt7GGsNV tyOwM57dD0GPRlizYGwT0G880Cwkxq6Qb8YIPSBfDsvPpTdg2R/YCIh1mlIVrfOBrXDWZMgD2CPx jQP5TnFnScFaiGD9o/SFvAV6bIhekiGJh/fKwDOgeQFoJ65CkU/GKa7lpJxfvFPRGHawyqVNob8d vtoP3h2tIeAu4Fiv8pkSNp+Bfya9CssNMB4nyeUTeYz8FHq8CayEK10PnXTwElgoQb8X5FsBkNyF /nrwq/K65PN9VibGqUfdFDEesVunvoLTCbDsAc2X0JkF3hd9LZZ+VsWbRAFoHYPW7pi7o2i1g4Vr kkP+Cncn7oMPkDEvOB0GNEG+VyJm4TH4RfA5wNsy5lmWGL/gbAVwhoxncd+P3oGOC3y7Hb3nQ+Ko vwuRjqzhaMBui9sE19+yiBbRqMek0EyF37LR2gu9rIHkBBC7FSUIOALxfx+5gz0UjZBzjavIxLmZ 4I/AH0mOcyl6vIuRPAd+iX0Bot2E8auhAk2IT3YQ41kt0PwdWr+CvA0QOyaaJH0COxiJCd5Qh8Db 2CMY0mUlQe/1MZIoaRkWcjH+XFkf1DT4Jw1xMgXVSfAw1YdbmAcdXyYqdrZ4MsVrTonYxwkdckNw Pu94uwAYDMTdKsUTrZcQG9fhk63CjrJQr2/iOdEzdbSwr1fCmqhgQj6XiTd8fkNfv6CGrAOOxXWN xvgPwz/2kKPeMgJsAsnX0CmET44LNDoLZK8huQKJLdAHkurAUTJK2TPOH0JyB/gEml3FnTEehwEY Txr6DUAtDUDvHE34dmBp6P0OdLoK5DqCO8O3k4HbhT6vFWk4V2AMsIlAWoicvQM8zvBdw2R2I56B 2wUa60LnCritQHUJQ7QING1BhFTFtffGGIpgfxST48SomMwy0XswWjfD5ivwV/AnqqJRgR9WQ34Y V+Ei9XG9fzCZs2l4q0GM8ATszALvC69WF2j0wWj7oPU0ziqQ32vy+0IfbQBmPw1cyDuhrz9ktZT2 dU+KHseD+8HmH5i1h9BpLHo0TYedS+g3BZFzBjbHo6+d6P0KEHlnzAM2xGy2gv5RcHcZRZJD57K0 A5wJTXiMZYEj2rlXHTH7QtISEuSgugZ8JGzGgNsA96H1I5zVBz5vDvwF17UA+eICSUPgZWAn1IEA cAO4PSwjB5XBwLewsFvakZkF7oqzXoDPxVnB8rtAoCkb1lDnTfFyPLJKQ3MGJA/AUY25t0UrvhFM +FZiO2G5kDVAPDfAt1UvzFcDRG8DRHsD5N1McZ8KPeJbUg0H7wjuhL6KMPJdwAewX4DR7pdc2gHu Rl+DoemDjJsMjNfjPwCzI/J6nLBg00/wcjMFN3sDFfSLVUQ5T2QT3qljWImZFsNCT8SqM/gKvT4I NOiRz9FmJPTxXp9xkB7bAlUmYywA2SF4F8g7oZdmgquo3moUPByNaD8onjjQy+w0x2T4ZKTRn3Nb 43IR4cbJXBOrTcMBwXlGTBb32YARAg0DMCNtxFnGkcJLPGJ9xP09o9gLJAuJoVj0YkQ9N8rvF1T7 t9315ymZHMuDl9efpODZdBmedJSNB8YDe+Le0X3wXPFUQuiXvSg7DclM8W0u7CgjBNIq4JOB2yHx BS8WaHADHoWkL1rDgK6QzAbXwEuAqcDlkB8HXwycB7QA6wODYLmclLw9L77dcHVp4NdhIRat7YSE 72KE/gBgKeRXwa+JVkWOoVhwY3PwE2j1ADrB8mvIzXhC3QDcHb1EgMdD8zms+ckRwlpX6GyGBNdO LklNSOygPxk2r+HdXZMcs7x2IVHCgNvxXPs2LOxD63o5C+I5uGEA8EtIBus+EdZcYbmjfKqOc7vA WgmwHWyuBS8G2kk/Q98NkgzYmYBzz0oPyNlE63rsyBygnw75S8j34KqTpLelHbRSYHdIOksuZ0H3 mLBzUUSj4aRAPuOCv4K+C1o/gn44RhWCXkLApZcaQycUo70vrwjXOAdyL/RSqayuQLT66T0KeWNY 3iqQzRBofCNaOa8r6gMkznIkMubF2whKfWALGf/gFrylUAPWauC9hesCaRW0NgZ3LZshfI69LYU8 H7hcekYiJBlAP9kKdAHOBq6H5hF4wF/GrRwPsAQYBbwKzUoyciCJx9jOAu/Luzew86GMaujsB57A uRdwXaHAAcBHuMZb0NkCy9MhvwYcIjMaPBpx0hKaqdIakML/r+CT43KcwME4qxTcDJ6Mvs5gZm+L s8zegpuQp2o4MABz11u0mlCj1AZ4E/4B5rEmrmsMRtULUREDTVQtVdo3Qv5YjvxtKjJL4F45Zpnp uF9EcVcqFzZzkcX5Ik54PayLuK2LalZXVB5ZYYC+qEXZsOOH+oAaRW5AEqxnn9ApJ+uYQBor6xvk pcCLwJOwGVTaiCMB94RmGka7UOYUfPgMdy99gXjCrszF9f4mrxrvlkQab/LxpBq7C45o34P9SCTu Tu/B073GhOjvCNiQfMMKwgYmD4wirtGfJseT8MHJg4aRAUMGRSWTofEDUxJImrDbOyzIldTk3xxl 4v/xR8oRW1KROBA78YnLzET81ZpGypNKxJHY88/iTVPRQqzMIP4aQ+cKUQkVdruGh7iK32JBu1Fv Y6QCqRwdPTyJZABzgLnAOcB84PKY+LjBZH1sXMJAshW4My4hLoX8CDwcNzIxnpwAnuGKA8kl4C/x idHx5A6wZPigmDjyHPg6mTcbCBD3wonRihRM3JwSo1P/RvJXZiC4Zy3ffdHR9j00v4d276EJKO3Y vIeajhVJXeJBvEkbEkS6knASQWJIPEkh6fiFgNkkjywhqngtgUySYzZUkkdVvr9mMIvfdBa/sF1X P84m4i8/DTbdCf4CxmYjxmuwKdKPl+SxQk15dFjPz+PHqsHy6DRE2nHazfvi9p1O6J9v6lch3ifC G0T4VROFj7qbeJPB5IdP/8O/R8WGiogyuCneNNjYl7gQP9KBhJIw0o9EkaEkmYwhWdxzX5K5pIAs J+vIZrKT7CdF5Ay5Qm6SB+Q5+YN/dWimzYSaVplWm7bguMa0Fce1pu9xXGf6gR9Xc7YNx9Wm7Tiu Me3Aca1pJ47rTLuIwo+7+ac1XHsPjqtNe3FcY9qH41rTjziuM/3EtdeY9vNPa7n2ARxXmw7iuMZ0 CMe1psM4rjMd4dprTUf5p3Vc+xiOq01FOK4xHcdxrekEjutMJ7n2ur/ziPhl8jSS8W955BSufJXp Z90zp3XPFOueOaN75izvZ5XpnO6f87pfLuh+uaj75ZLukcu6R67oHrmqe+Sa7pHr8Mgvukdu6B65 qXvklu6R27pHfoVH7ugeuat75J7ukfu6Rx7oHnn4X3hkDskny8iaf+qREt0jj3SPPNY98kT3yFPd I8/gkee6R37TI+aF7pnfdc+81D3zChHzWvfPG90/f+h+eav7pVT3SJn0CC808IjZID1iVqRHzFR4 xGyUHjEz6RGzKj1iNkmPmM3SI+Zy/w2P/EiOktPkEvfIPfKUvDYoBhuzjfSI2VZ6xKxJj5jtpEfM 9tIj5vLCI+YK0iPmitIj5krSI2YH6RGzo/SIubLwiLmK9Ii5qvSI2UlGjLma9IzZWXrGXF1EjNlF +sdcQ/dPTd0/tXS/1BNXanbV/VJb94ub7pc6ul/qSr/8tz3ywOqR+rpHGugecdc90lD3SCPdI43h EQ/dI010j3jqHmmqe8Sie8QLHmmme6S57hFv3SMtdI+01D3SCh7x0T3iq3vET/dIaz1i2uieaYuI 8dc90073TIDumfbSM+K3NcW48Q00k38TaCRBvDzGvw1cSH1i4f4KIt1JX+1nXukDzR8YZ2qndTZL KwYL47IzOpulneWsI/TO6WyWdh5M6F3Q2Sz8vkpd4kl8+Hx0JX1IJK/qKWQsmaRdtPZ0ydrTZWtP V6w9XbX2dM3a03VrT7+860m7z1kncyCXPdDZLO0hWEcuK9HZvxrRDeuIblpHdMs6otvWEf1qHdEd 64juWkd0zzqiR9YRPbaO6Il1RE+tI+K5b/A0ePIFjLPizNeDdZQ6+C7mKzc7b6wCUoj4tSj1b2aL r35oJ6Iov4OFWFlnKwu1si5gDL+B58TXinVx5lOc9QxnPIf2b9B8IaJFecrPENEym1T7R1+R+Xxd s4ZsJad4/rzkmaMZqhhcDY0M3gZ/Q4hBvO9stN3Lbc0D22dlP75jyjHO5oIVWdlxKzthZSfBxKpU U04JrtzgOAdtP1u1TltZMRjl3rMnjsoZnCFGMlURo/gKOmff06miiDHNUX4ilGvOUc5ZLZ23sgtW dtHKLlnZZSu7YmVXrewamImvm52IK589T9KStFH42kBZwPs7hF4XKAe41gKFrxSUfP75MKT5ykEu zVeuW239ovvCpExTvuTxUqAs45rLlVXERlmjrCHllXXKd6SCskHZSCopm5Uf+IqfYmXsyKNG/IqL WPdV0H9RcRFvWKms5DY3cn2q7FB28LUijzxlNv5SXPxenohD/q0j/h/pfOXL66wyX5lPaih5Sh6p yW3sIrXwl9/t8JffAfjlO6pOVHMUsVugFN1TG2oj7kNRDfa4Br2r1qAi8g1qLbW2GKEhgqyk92gt 6k4bU0/ajLakWXQCzaaT6GQ6jU6ns+lXdB7Np4V0Gf0LXUlX07X0O7qJfk930D30J3qYFtGTtJie p5fpdXqL23pAH9LH9ClzZx6sLWvH2rNAFsSCWWcWyrqzMNaH9WMDWBQbzIaxRDaSjWafsbEsg2Wx CSyHTWKTWS6bxr5kM9lsNofNZfNZHstnBWwJW85WsXVsI9vCfmDb2C62jx1gR9hxdpKdZufYRXaV 3WB32AP2mD1nL9kbVqZS1aTaquXViqqDWlV1Vmvy63ZVa6tual21vuquNlI9VE/VojZXW6g+amu1 ndpeDVQj1Eh1kDrSdr3tRtvNmqKpmo1mr1XSqmjOWi2tjlZfc9caaR6al9ZC89XaaAFaR62z1k3r qYVrfbUILVKL0cSvVnxLzVQsOWrRWnweGtAGROFebsznoQltwuuDF/UijLagLYhKM2kmMdHxdDwx c+9nk3J0Ip1IbOgX9AtiS6fSqUTjszGd2NFZfAbt+ax8RcrzmZlHKtAFdAGpSBfRRaQSXUqXEgc+ U38hjny2VpLKfMZWkyp81taSqnzmviNOfPY2kWp8Br8nznwWd5DqfCb3EBc+mz+RGvQQPURq0mP0 GKnFZ/YkceWzW0xq8xk+T9z4LF8mdfhMX+fV7Ba9RerRu/QuqU/v0/ukAZ/5h8SdPqKPSEP6hD4h jXgUuJPGPBI8iAdrw9qQJsyf+RNPFsACSFPWgXUgFh4dQcSLR0gwacZCWAhpziMllHjzaOlOWvCI CSMtedT0Ia145PQjPjx6BhBfHkFRxI/FsljSmg3lO5o2LIElkLYsmSUTf5bKUkk7NoaNIQE8usaS 9jzCMkgHHmVZJJBH2gQSxKMth3TkETeJBPOom0w68cjLJSE8+qaRzjwCvyShPApnki48EmeTrjwa 55BuPCLnku48KueTHjwy80hPHp355AMeoQUkjEfpEtKLR+pyEs6jdRXpzSN2HenDo3Yj+ZBtZptJ XxG95CMev7tIfx7D+0gEj+MD5GMey0fIAB7Px8knPKZPkkj2M/uZDGRn2VkSxeP7IonmMX6VxPA4 v0EGsV/ZrySW3Wf3yWD2iD0iQ9gz9ozEsd/Z72Qoj/83ZBgrY2UknucBJcN5LphIAs8HW5LIc6I8 SeJ5UZGM4LnhQJJ5flQlI9VqajWSotZQa5BRPFfcSCrPlLpkDM+W+uQznjHuJJ1nTSPyuSr+om0s zx5PMo5nkIVkqM3UZiRT9Va9SRbPJh8yXvVT/cgE1V/1J9lqgBpActQOagcykWdYBJnEsyySfKHG qDFkspqsJpMptt/ZfkdybTfYbiBTbTfZbiLTePYpZDrPQJV8ybPQhszgmWhPZvJsrERm8YysQmbz rHQmX2k1tZpkjuamuZGveYbWJ3N5lrqTeTxTG5H5PFs9yDeaRbOQPM1b8yYLNB/Nh+Tz7G1DFvIM DiAFWpAWRBZpIVoIKdS6al3JYp7RPckSntXhZCnP7L5kGc/uCPItz/BIspxneQz5ixbPc30Fz/YH ZCStTRtSC/Wmz+gUOoN+Tb+hC+li+i3dQLfQbXQXKuZReoKepufoRXqN3qC/8nr5gDWkz1hD1phO YV1ZTxbO+rIIFsli2BAWz5JYCktj6ayQLWMr2Bq2nsfS96wx28n2sv3sMCuip/nxDLvALrPr7Ba7 x0rYU/aCvWalqqKqqo1qR39lXdXK1E2trsarLVk4ZwPUKHUwu267VTNqZk3TKmiOmpPmorlqdTVP rbnWSmuttdMCtU5aF62HFqb10fppA7QoLVZL4NeajJpGUNMMqGYKqhlFNTOiajHUKxWVyoRKZUal KodKZYNKZYuKpKEi2aEi2aMilUdFqoCKVBEVqRIqkgMqkiMqUmVUpCqoSFVRkZxQkaqhIjmjIlVH LXJBLaqBWlQTtagW6owr6kxt1Bk31Jk6qDN1UWfqoc7UR51pgDrjjjrTEHWmEepMY9QZD9SZJqgA nqgATVEBLKgAXqgAzVABmqMCeKMCtEAFaIUK4IMK4IsK4IcK0BoVoA0qQFtUAH9UgHaoAAGoAO1R ATqgAgSiAgShAnREBQhGBeiEChCCCtAZFSAUFaALKkBXVIBuqADdUQF6oAL05Llfi3yAXA5DFvdC Focjc3sjc/sgcz9E5vZFtn6EbO2HbO2PbI1Atn6MbB2AbP0E2RqJbB2IbI1CbkYjN2OQm4OQm7HI zcHIzSHIzTjk5lDk5jDkZjxyczhyMwG5mYjcTEJujkBuJr+Xm01p83+Zm0focfozPctz8ypyk8eQ npuN/u3c3MoasR1sD/uJHWLH6M/8WMzO67l5lz1kT9hv7BV7qxpUppaz5mZtnpvDkJu1kZuxPDe3 /GluNtNaan6av9ZBC9ZCte7/l5v/l5v/i3PTYBD/R2oXMoAU8G/RjWQnOYjd7W3yGPdJsG8mjfg+ iu/f6G88lrPo7xwn0FccJ9E3HKepk4jC2qppHNupYzi2V9M5Bv6JhRew8BIWXsPCH7DwBSx8Cguf wcLnsMD3f+pYoQE2zsoyrCzTyrKsbLyVTbCybDDsqLVngmvP30l4tblGCHvLSonC6wLfJ/LaoBKV 1wcbYuZ5HYu/ew3FHaT6xBtWKtge5dnMz6T33jEeF2K3f4x/esZ3b5ehZ0/H8dznbfJI72GHKHYU BHsDAz/zqtgT4hmFGTveX/ludJW4B6IUyJ0jKbYtb2v/D08uxJjEsyk34sG9G6DfLziCvexR677/ pvj1Q7BbVnb7HVNHC+1/uTfGExs8kdPwpIm7SnlMqxsHG4cY4/QndwapRUhV8XcWjpCSqgMsWVX7 qeUa5YTk/G5nMCkFWVW7cFEnxWDwsrWUU1lje6o4M2IZqNo0Vg1GQ1YrxWAs6GX5wOLxnsSlsGaG C2mDf3uQKDKSJJJ4Moik8P/8xb+W2u8ZMzp6Zqu5l1YW/TjHMub+mhptXTwrfzGtIKuSlyXLGGnJ ol0LqGJQFBvPlRUv9SyLWHBk97uza/ChJHk1tjRUaW+jrYNbYGLSp8lxg4ekuLpHN3T18vVt5dot Ljo5cWRibIprYGJykqdXTYuLVK78ty2JyQNT4hITvGpbaol26uD01/awxMQU1/ajUoYkJselfGqp WdXO0sri04z/09zL0qxfVTuvZvxjCy7k//SzfApfcSOqg9K7l5eDpaL4YHaw+XDgyCFxCYNTeDcV LPZCaHIwhQ2KGZ6YEPNuYDb/bGB1LLXlwJzfb48Z5NorbnACt+raM7C9JcvgZrGzTqDBwAjNMpQn XG6jZBkMZMunn5/5eENH3+Xeq7wuvKrXovPo3W9q5R/oOOLRyeA7p3P3DesaFvV8nrKv27nO8U3r +g/aVVRni23IlnGjLnfcsWK6fc+f6jV+WvCrXZ1aJ9vXfR0173i1jktnhdaad2xDU7d9oU3SE89X rtk617eC7+UdDZ/Htm5iaFZW2iBk2aZ4w8S8Nz+sjx6X9SqiIHNC9rR1T7fOXnzcZ1nP7KoNJna/ bHlB2j7f/6pt5s6ch/G+33p6v9joudbm86gZabF5c0fa5ax9+uMz1+97VJoafcTjfLOO1Uq2hc5p 3bOXU1HsB5+uWD3xYB//hVk9JyWw71rs+azujrDYtvO6H208tnnChE7qyfwToTlKQg5Zsnvi1V6K +FXgxZmvLZm/Wxy4O2vUM2oWG9XMQ5cxE6WWzEIhNRgz51syv86o0P9E0qO45Pw6H4x1XN9tWtmR Rcn/8/GWVZ7sIVPatJlU8aT/i+gHVwMs5cUYHQyGMiOzUH6w1BACe2MVo+PRGkWpJKn/2icXfuw+ /4Mgz8VB0Y8ttqK5vNHI0yjnvdShIiI+W7lmbGj9p0Xbu6cU9m2Q0mjUhpy3K7vOTiPd7h6+73Qp 7if7wvRnSuD+wxOPvux1dO/CHX0SH0cH/SWIlMw5OL/YZavtwmp2s89eqLm64eePHi4buWr6Fd9p becO3e4z/NSktXXeXr17Jq7cjEk7Sq+Tbd7Pfk9/VaGSJ7vfcM6sDsPcR2zxmX7NZHfo4yHHdmS0 Hxa7fNuWbdO8Dz+lFdLH/HbqWoern5Vev76q9MXVYrsNSWdm3uix2acwvcnpthe9baNaKQszh9b5 4kVE9PR1/bb5no3M7T3BuflvrecWZGmFn0zZ4LFl0dIjKy+4bt5lqZbt6mjXaHvY8/bXBlhuzHSP m7gn6Zdn364syuiQnGrPa8wYXmOi9Boz0LD+G9TCyu/nEeN15j+Y1bzgePFC04yXmRbNvfSC08L6 0ZI5/v/L2OwQODx0jd169Ax7p07/ifp/WXuWjkhxOnIxr+nrJ9HVMhZPKzuYNF5b1KnR69f91hV1 K7+j9YXax1jx5+ntNs1Lred3qaCH663knwNH3C6Ld3y1cML6ehN3OG76eGerLzx/WpkdOSI7s8H3 zemr1WdmKSWbe1dUjozPfrEnO3pgtQLHvAUL84KjW52r2ObDAyGuvar8frRv6Yvdzoc3B8fb3fFj Rctcbkx6fHnF3qTx/U8+fdpu6/klCxaThBWZx0r8jKt3h870cLh2t31quQxD/GDXjV7r/IedCjCP L06yTLX8ujP3RNOS0zntnPst3T0k+84X6TNoaMJHga4heZNKD3Xccqer0WAbVVT4wGVWvbcnvrPf /3JzXefP3qSfieh+cvBdvfa8tGT+9ue1569ZfD759BEt6pPLi1MWfmI/t/3y/g6B9TF9NcqLrOeJ bMpA3ahRx+hkqZLx52kfJBRqGdtaWlt8C1oVtMhpPiQlJcmvadPo5HjP4e/m0DM6cXjTpGFxQto0 KTkxZlR0ysimgb144HlykSXk3QgNBmMbi5/F591ni5LjoRscPXr0nxkclPyepZS/SyhUn8jIBufS LZ0rdWrfqs2AURtvFpKWFUPWefT9Zm76w8WVFs0tcdrw9Yvh085ZnF1W145uHzzr7Fpn9y5ft/w8 IDzyaNT2u3/EffvJuJ8mLsvR0v/yy0efX5xUPDqNLat7OOZl9w+2BLlPc/YIN7sn/1TLqa3HcdIg 0eHk0oFPz0T57SDdWdN5gz+/FR3YrrW2c4ppzPW0gF1X04omuhZWW7Q98vHCVWERqY5vq6exs9Gj hmW+nRi8evVHYbs+27W22pKZ65/aeoy1VLjo1WXnhH7jfv+mUtrdK2MjV9rt96r5Inm+/+DjPiU+ Rb7VR15sfd776vhTeceuT7niXBpj/mTtC8+tzeqlxtV7Vjy1RZ19F+sF8eqzgFefbFl9Kgy1nddj N6m3suLFjrX6jhlc+Pc16D+z1mlp8fVqafGyeHu3EqXHl3/8D6x1wuOGDxqZMnB40r+71rnUKuHN 2oMdQkc4HSwK8e+1+/VKxx88mm2r1CPs4PiH/s3Pd/aa6b55Rsy1Wj0n/LC3y8lx7OWjUTunHFhe vCYuKTatQeydzVseZX9/rGTF20pLbD9ya9j0eMD5PsbqqZuGxwwPDb94+cmVXQvHH8i4Oq6r0mr2 b7vzzX1qDul07Pzu1Iimn2+uZ9zYp/9Ql+iyjPQ2JcXGet18R6eYPt4bcS6nlceoQ/b3avqWS08t XRCfMObaA//pX+ePsP+kUQ+nqMhm+afGd2/sFjGk45QrTSdU6Ln+1SbnqfEl9b5xeHmkwtls++dZ qSNb7v9qTOHRSPUBW5fTfMvL2f0ntJ/QN3t2wrpaHiFHE/MCrw29M67+tGGy3mQZ3LlH6v5ZxTH/ 71jtVFDL6TuLygaxhCHvFcrEO93bff2998ouOdO3591b1bp94P4TlmrWExwVo1bThvQio/guJJC0 /9uV0D8so/6kQM3uVtFrb3rPbRWnLRpoMtjnJnWc+mhk+I525ViTsq0f9Mp2eeg7Y8viPrZXcje3 rn7yzapvD2357oPa1RPNcWOH0UK34IfxG4enu20N/nnCs6nld5omt9xzf+zdpI87Lpx56mjR5Wm7 r+9qdCz9waE1zYonfn8k+seWJ51q70q90nr+huoj82tPOrdxY6Xw3Od5eweFznevnxc5uXzrAw6D 0kK2HV893q/Huqi+Vyx37/rWuPHF0wu+ma8caufGZESrxjlP5yuBTT8LnvRDmXJ+0KvQKxdoyqwN LEE7uuCS+8D0kCdV8yrW9lFcJv6/rWE7Os1ox1OHY8G2e1d23nuRZt77RWnanDMbykMCra4VuWxS /gYsoFYBC6hJsOYR6yIDcPOIY+CaRxgFAaiMsjAwNzIFFk2GhqagMsoYwjUEcQ0aN9OjeaRuoArh yuU5ZxZkpBYpuAS7KrgG+1lZmLoY6xobmDrrmjo5uxmqGihD/CSD6ifdYJCnFIJTi8oyk1MJFm8f WHQ3TTsg1ZiuulEtabOw9zmDXQeELP40ppqwHzHbpJLxjZ3lAPv0L9s/Vssl6bjd9F4SaLL9cs7b KOstzQvdbQU59EyzXZ8dsulhSmNaKZH52uutus47m/LoJVcKZnqHtwhcWK/7o1P22SvNLc/Pz2NL Wl4Ucsj62Hn7HQ83RAjkPF16/fChUvO9X1ofNr7QuCH98dO6j02Lr11nXjRftOW37a/VD7cZnVjA lPL52X8ptUKO4C5Rpk/N6mWeTYXL3681qjh2PUfMXyl1epKvm/5/5fWtb5YV7GU+feuGEetR7QkO 2+Zd1WnL2X5a2Ki291jdOnF9oz9pu2U3uIb+WPtLN705XXNyy6WohcrIzSlEgfBi+rfv73s+Pst8 HJnh931GV9Xd2XooLSWsJQYlLaWS4oLkRKq0lGAmlWAvrFHaf2wHsJVWvPbl8RNt9i01XXKblbVF PuzT+5nLjnP06m8+a194ta2mXP7ua/FNe2se/5z5icvVY63I7kydT3bpSSGf3tWrC06yfHPuZrtf x/cEd+VqdVEHjvn7eQ1Zmm6YbuOZw3C5e1VF4tGtHY5z7czuRCxRn211ay9brMiyTfw+B/tsuj8l zfyR9vbqZxmNDUa3Txly7vmtlOHm8+tysdJzzT4lht9h+9nWNS4Q3WXyU6NP3iuJdWHn10b3l7wT Oa5HWPfLZXNmrjzgURPaZB/PYOE8h+2M/Q39/f7FnLZ/d8V9Of7G/FBK4gLfK7YFZ6I3CDcevLLY UGpvyrVpl6rstaLdgjltzjL/tI9kONMZnGjYxDIbWGJNZ2JkNGhsH8AuG0pHEjHUtaDxGKh2gkYb J7MhD/I4GtBeBI/bkM8AWVYUWGrANbIYApP6icvbnR+abus6f+zDjq4PRxY+qN/oZZCGpIXHMMIg bIFOgxaDL0MmQzJDEUM+eCgujaGEQQFYHeYDRQrAZCJQJBPIyluo1qCCM6WWVBbkpxclFmRUKqCV TCxNjAy9vim/+h3PtwpUlz07zTttgefv545T9xtwv/oU4zrzVbR7d17lh4sTRK807eAzm2aZfrCd 95eLw/KcOWsLZFIjJ969tLHm+ZydJmsYfx1c6/PRUujfgp23bkhMClLU0opPzE/NeJucOf1j+F7G r5dvKr/Y03T1yA/t//8ygm/12X47Zrqt89qc5asPfVAUqb3HtffIusMvatd4FiyYvOylofQu0SXH w2a0XfG61juloTdHgSf1Jtf+GmmuylrnoFnKEZfzpTMX3GcuCLRm/HloudbPKT631/Ep9SX9Dut6 JVJpdOC30oTaH5M44kXmXWZVWRWj4Xdi3do0Dv2LqVNXp+3sPr7x8q2M6q8burpDFzYxyRs0MUkj YonNsImJByjEQffkiF5FolTc7NDkuCDWQAI5LXIjBn4ZgXbCZVgN+cHjD8ZGhobmRmYGxlEYSVE0 a+JJ3aUTal5/KK04LLYv98zp5z/RyidQEjkjmH1CWH1foaNZhFzc+hPpl+fw72F1Z058/mNBwF5G 3z96hrzcjKYzH14qfR3xImLznKaQ1WVRFpMC97y/eq5g8e3Z5YW3Hj6t2Px7ZsnCHrn4TRNvvVzK ts+12HGPaZmTiY20oOXL8OcfVPfYMc7mY5qkrGx29KLy+6V+R0L7n9XYeH5e0PX14gJR5rOzPvU4 aOneDL3efWBCKUfumaMblJc8KhP/+PQ8+7IS3ZyaaIaLU48fCnv7dGm6bvvyS0LBOn1/bCPKk4Nt ZbZritb9Fi67xvp0zYd4q2sPzScoXDzBdLntwVaj5uQTL//d13AQbf7C9zh2d8xCjzMnr622MLQu sAhzNlpzcYnOL2sGBgDj8YDpDQplbmRzdHJlYW0NCmVuZG9iag0KMTQwIDAgb2JqDQpbIDBbIDc1 MF0gIDEzNVsgMzUwXSAgMTc3WyA1NTZdIF0gDQplbmRvYmoNCjE0MSAwIG9iag0KPDwvVHlwZS9Y UmVmL1NpemUgMTQxL1dbIDEgNCAyXSAvUm9vdCAxIDAgUi9JbmZvIDIyIDAgUi9JRFs8QTNBNDQx MUM2QzYyNDU0MkFGRDVFRENFMkYzOTkyNkU+PEEzQTQ0MTFDNkM2MjQ1NDJBRkQ1RURDRTJGMzk5 MjZFPl0gL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMzE0Pj4NCnN0cmVhbQ0KeJw100czg2EQ wPEnFWkkkhARxKsGUaK3IHrvokePfnbg4uZgzPgMPg7j5uBruMeb/fMc9je7s8/MHnaV0l8mY9Cj W6ks9/ApGD4E05NgjgkWDZKCNSXY3gR7GOLwJTgoOr2CKyK4E3AneB4FX1rwPwiBH6WM+iwhlYZz uIAc+Gu51D8Etf/MCAawggnMYAENcuEKbJAHlRAGB9ghH1zgBDcUQCF4oAJ84IUi8EMAiiEIJRCC UiiHMuiFKriGGqiGHuiGOqiFCNRDBzRCA0ShCVqgGdqgFdohBl3QCUvQBzcwAP2wCAsQh0GYh2EY ggSMwBiMwgSMwxRMwgxMwxzMwhkswy2swgqcwgmswxokYQN2YQs2YQe2YR/24ABScAxHcKgve/hd jkQLZjE8fwsvcsXG6KtSvxT9NiYNCmVuZHN0cmVhbQ0KZW5kb2JqDQp4cmVmDQowIDE0Mg0KMDAw MDAwMDAyMyA2NTUzNSBmDQowMDAwMDAwMDE3IDAwMDAwIG4NCjAwMDAwMDAxMjUgMDAwMDAgbg0K MDAwMDAwMDIwOCAwMDAwMCBuDQowMDAwMDAwNDYyIDAwMDAwIG4NCjAwMDAwMDA5MDYgMDAwMDAg bg0KMDAwMDAwMTA3NSAwMDAwMCBuDQowMDAwMDAxMzE1IDAwMDAwIG4NCjAwMDAwMDEzNjggMDAw MDAgbg0KMDAwMDAwMTYzMiAwMDAwMCBuDQowMDAwMDAyNzI1IDAwMDAwIG4NCjAwMDAwMDI4NDkg MDAwMDAgbg0KMDAwMDAwMjg3OSAwMDAwMCBuDQowMDAwMDAzMDMxIDAwMDAwIG4NCjAwMDAwMDMx MDUgMDAwMDAgbg0KMDAwMDAwMzM0OCAwMDAwMCBuDQowMDAwMDAzNjI2IDAwMDAwIG4NCjAwMDAw MDQ0MTkgMDAwMDAgbg0KMDAwMDAwNDQ3MyAwMDAwMCBuDQowMDAwMDA0NzM5IDAwMDAwIG4NCjAw MDAwMDU0ODAgMDAwMDAgbg0KMDAwMDAwNTc1OCAwMDAwMCBuDQowMDAwMDA2NjQ0IDAwMDAwIG4N CjAwMDAwMDAwMjQgNjU1MzUgZg0KMDAwMDAwMDAyNSA2NTUzNSBmDQowMDAwMDAwMDI2IDY1NTM1 IGYNCjAwMDAwMDAwMjcgNjU1MzUgZg0KMDAwMDAwMDAyOCA2NTUzNSBmDQowMDAwMDAwMDI5IDY1 NTM1IGYNCjAwMDAwMDAwMzAgNjU1MzUgZg0KMDAwMDAwMDAzMSA2NTUzNSBmDQowMDAwMDAwMDMy IDY1NTM1IGYNCjAwMDAwMDAwMzMgNjU1MzUgZg0KMDAwMDAwMDAzNCA2NTUzNSBmDQowMDAwMDAw MDM1IDY1NTM1IGYNCjAwMDAwMDAwMzYgNjU1MzUgZg0KMDAwMDAwMDAzNyA2NTUzNSBmDQowMDAw MDAwMDM4IDY1NTM1IGYNCjAwMDAwMDAwMzkgNjU1MzUgZg0KMDAwMDAwMDA0MCA2NTUzNSBmDQow MDAwMDAwMDQxIDY1NTM1IGYNCjAwMDAwMDAwNDIgNjU1MzUgZg0KMDAwMDAwMDA0MyA2NTUzNSBm DQowMDAwMDAwMDQ0IDY1NTM1IGYNCjAwMDAwMDAwNDUgNjU1MzUgZg0KMDAwMDAwMDA0NiA2NTUz NSBmDQowMDAwMDAwMDQ3IDY1NTM1IGYNCjAwMDAwMDAwNDggNjU1MzUgZg0KMDAwMDAwMDA0OSA2 NTUzNSBmDQowMDAwMDAwMDUwIDY1NTM1IGYNCjAwMDAwMDAwNTEgNjU1MzUgZg0KMDAwMDAwMDA1 MiA2NTUzNSBmDQowMDAwMDAwMDUzIDY1NTM1IGYNCjAwMDAwMDAwNTQgNjU1MzUgZg0KMDAwMDAw MDA1NSA2NTUzNSBmDQowMDAwMDAwMDU2IDY1NTM1IGYNCjAwMDAwMDAwNTcgNjU1MzUgZg0KMDAw MDAwMDA1OCA2NTUzNSBmDQowMDAwMDAwMDU5IDY1NTM1IGYNCjAwMDAwMDAwNjAgNjU1MzUgZg0K MDAwMDAwMDA2MSA2NTUzNSBmDQowMDAwMDAwMDYyIDY1NTM1IGYNCjAwMDAwMDAwNjMgNjU1MzUg Zg0KMDAwMDAwMDA2NCA2NTUzNSBmDQowMDAwMDAwMDY1IDY1NTM1IGYNCjAwMDAwMDAwNjYgNjU1 MzUgZg0KMDAwMDAwMDA2NyA2NTUzNSBmDQowMDAwMDAwMDY4IDY1NTM1IGYNCjAwMDAwMDAwNjkg NjU1MzUgZg0KMDAwMDAwMDA3MCA2NTUzNSBmDQowMDAwMDAwMDcxIDY1NTM1IGYNCjAwMDAwMDAw NzIgNjU1MzUgZg0KMDAwMDAwMDA3MyA2NTUzNSBmDQowMDAwMDAwMDc0IDY1NTM1IGYNCjAwMDAw MDAwNzUgNjU1MzUgZg0KMDAwMDAwMDA3NiA2NTUzNSBmDQowMDAwMDAwMDc3IDY1NTM1IGYNCjAw MDAwMDAwNzggNjU1MzUgZg0KMDAwMDAwMDA3OSA2NTUzNSBmDQowMDAwMDAwMDgwIDY1NTM1IGYN CjAwMDAwMDAwODEgNjU1MzUgZg0KMDAwMDAwMDA4MiA2NTUzNSBmDQowMDAwMDAwMDgzIDY1NTM1 IGYNCjAwMDAwMDAwODQgNjU1MzUgZg0KMDAwMDAwMDA4NSA2NTUzNSBmDQowMDAwMDAwMDg2IDY1 NTM1IGYNCjAwMDAwMDAwODcgNjU1MzUgZg0KMDAwMDAwMDA4OCA2NTUzNSBmDQowMDAwMDAwMDg5 IDY1NTM1IGYNCjAwMDAwMDAwOTAgNjU1MzUgZg0KMDAwMDAwMDA5MSA2NTUzNSBmDQowMDAwMDAw MDkyIDY1NTM1IGYNCjAwMDAwMDAwOTMgNjU1MzUgZg0KMDAwMDAwMDA5NCA2NTUzNSBmDQowMDAw MDAwMDk1IDY1NTM1IGYNCjAwMDAwMDAwOTYgNjU1MzUgZg0KMDAwMDAwMDA5NyA2NTUzNSBmDQow MDAwMDAwMDk4IDY1NTM1IGYNCjAwMDAwMDAwOTkgNjU1MzUgZg0KMDAwMDAwMDEwMCA2NTUzNSBm DQowMDAwMDAwMTAxIDY1NTM1IGYNCjAwMDAwMDAxMDIgNjU1MzUgZg0KMDAwMDAwMDEwMyA2NTUz NSBmDQowMDAwMDAwMTA0IDY1NTM1IGYNCjAwMDAwMDAxMDUgNjU1MzUgZg0KMDAwMDAwMDEwNiA2 NTUzNSBmDQowMDAwMDAwMTA3IDY1NTM1IGYNCjAwMDAwMDAxMDggNjU1MzUgZg0KMDAwMDAwMDEw OSA2NTUzNSBmDQowMDAwMDAwMTEwIDY1NTM1IGYNCjAwMDAwMDAxMTEgNjU1MzUgZg0KMDAwMDAw MDExMiA2NTUzNSBmDQowMDAwMDAwMTEzIDY1NTM1IGYNCjAwMDAwMDAxMTQgNjU1MzUgZg0KMDAw MDAwMDExNSA2NTUzNSBmDQowMDAwMDAwMTE2IDY1NTM1IGYNCjAwMDAwMDAxMTcgNjU1MzUgZg0K MDAwMDAwMDExOCA2NTUzNSBmDQowMDAwMDAwMTE5IDY1NTM1IGYNCjAwMDAwMDAxMjAgNjU1MzUg Zg0KMDAwMDAwMDEyMSA2NTUzNSBmDQowMDAwMDAwMTIyIDY1NTM1IGYNCjAwMDAwMDAxMjMgNjU1 MzUgZg0KMDAwMDAwMDEyNCA2NTUzNSBmDQowMDAwMDAwMTI1IDY1NTM1IGYNCjAwMDAwMDAxMjYg NjU1MzUgZg0KMDAwMDAwMDEyNyA2NTUzNSBmDQowMDAwMDAwMTI4IDY1NTM1IGYNCjAwMDAwMDAx MjkgNjU1MzUgZg0KMDAwMDAwMDEzMCA2NTUzNSBmDQowMDAwMDAwMTMxIDY1NTM1IGYNCjAwMDAw MDAxMzIgNjU1MzUgZg0KMDAwMDAwMDEzMyA2NTUzNSBmDQowMDAwMDAwMTM0IDY1NTM1IGYNCjAw MDAwMDAxMzUgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDA4NjUzIDAwMDAwIG4N CjAwMDAwMDg5ODcgMDAwMDAgbg0KMDAwMDEwMjEwNyAwMDAwMCBuDQowMDAwMTAyNDE3IDAwMDAw IG4NCjAwMDAxNDI5OTUgMDAwMDAgbg0KMDAwMDE0MzA1MCAwMDAwMCBuDQp0cmFpbGVyDQo8PC9T aXplIDE0Mi9Sb290IDEgMCBSL0luZm8gMjIgMCBSL0lEWzxBM0E0NDExQzZDNjI0NTQyQUZENUVE Q0UyRjM5OTI2RT48QTNBNDQxMUM2QzYyNDU0MkFGRDVFRENFMkYzOTkyNkU+XSA+Pg0Kc3RhcnR4 cmVmDQoxNDM1NjcNCiUlRU9GDQp4cmVmDQowIDANCnRyYWlsZXINCjw8L1NpemUgMTQyL1Jvb3Qg MSAwIFIvSW5mbyAyMiAwIFIvSURbPEEzQTQ0MTFDNkM2MjQ1NDJBRkQ1RURDRTJGMzk5MjZFPjxB M0E0NDExQzZDNjI0NTQyQUZENUVEQ0UyRjM5OTI2RT5dIC9QcmV2IDE0MzU2Ny9YUmVmU3RtIDE0 MzA1MD4+DQpzdGFydHhyZWYNCjE0NjU2Nw0KJSVFT0Y= --_007_4E1F6AAD24975D4BA5B168042967394367511EAFTK5EX14MBXC283r_ Content-Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet; name="OAuth Feature Matrix - All.xlsx" Content-Description: OAuth Feature Matrix - All.xlsx Content-Disposition: attachment; filename="OAuth Feature Matrix - All.xlsx"; size=30571; creation-date="Tue, 12 Mar 2013 17:37:34 GMT"; modification-date="Thu, 14 Mar 2013 21:35:25 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQBBN4LPcgEAAAQFAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACs lMtuwjAQRfeV+g+Rt1Vi6KKqKgKLPpYtEvQDTDwkFo5teQYKf99JeKhCPBSVTaLYnnvudTwejNa1 TVYQ0XiXi37WEwm4wmvjylx8Tz/SZ5EgKaeV9Q5ysQEUo+H93WC6CYAJVzvMRUUUXqTEooJaYeYD OJ6Z+1gr4s9YyqCKhSpBPvZ6T7LwjsBRSo2GGA7eYK6WlpL3NQ9vncyME8nrdl2DyoUKwZpCERuV K6ePIKmfz00B2hfLmqUzDBGUxgqAapuFaJgYJ0DEwVDIk8wIFrtBd6kyrmyNYWUCPnD0M4Rm5nyq Xd0X/45oNCRjFelT1Zxdrq388XEx836RXRbpujXtFmW1Mm7v+wK/XYyyffVvbKTJ1wpf8UF8xkC2 z/9baGWuAJE2FvDGabei18iViqAnxKe3vLmBv9qXfHBLjaMPyF0bofsu7FukqU4DC0EkA4cmOXXY DkRu+e7Ao4sAmjtFgz7Blu0dNvwFAAD//wMAUEsDBBQABgAIAAAAIQC1VTAj9QAAAEwCAAALAAgC X3JlbHMvLnJlbHMgogQCKKAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAjJLPTsMwDMbvSLxD5PvqbkgIoaW7TEi7IVQewCTuH7WNoyRA9/aE A4JKY9vR9ufPP1ve7uZpVB8cYi9Ow7ooQbEzYnvXanitn1YPoGIiZ2kUxxqOHGFX3d5sX3iklJti 1/uosouLGrqU/CNiNB1PFAvx7HKlkTBRymFo0ZMZqGXclOU9hr8eUC081cFqCAd7B6o++jz5src0 TW94L+Z9YpdOjECeEzvLduVDZgupz9uomkLLSYMV85zTEcn7ImMDnibaXE/0/7Y4cSJLidBI4PM8 34pzQOvrgS6faKn4vc484qeE4U1k+GHBxQ9UXwAAAP//AwBQSwMEFAAGAAgAAAAhAIE+lJf0AAAA ugIAABoACAF4bC9fcmVscy93b3JrYm9vay54bWwucmVscyCiBAEooAABAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAKySz0rEMBDG74LvEOZu064iIpvuRYS9an2AkEybsm0SMuOfvr2hotuFZb30 EvhmyPf9Mpnt7mscxAcm6oNXUBUlCPQm2N53Ct6a55sHEMTaWz0EjwomJNjV11fbFxw050vk+kgi u3hS4Jjjo5RkHI6aihDR504b0qg5y9TJqM1Bdyg3ZXkv09ID6hNPsbcK0t7egmimmJP/9w5t2xt8 CuZ9RM9nIiTxNOQHiEanDlnBjy4yI8jz8Zs14zmPBY/ps5TzWV1iqNZk+AzpQA6Rjxx/JZJz5yLM 3Zow5HRC+8opr9vyW5bl38nIk42rvwEAAP//AwBQSwMEFAAGAAgAAAAhAKharMM3AQAA9AEAAA8A AAB4bC93b3JrYm9vay54bWyMUcFuwjAMvU/aP0S+j5YyYCBSpGmbxmVCGoNz1rg0Ik2iJKzw93Nb sbHbTvazk+fn58XyVGv2hT4oazgMBykwNIWVyuw5fGxe7h6AhSiMFNoa5HDGAMv89mbRWH/4tPbA iMAEDlWMbp4koaiwFmFgHRrqlNbXIhL0+yQ4j0KGCjHWOsnSdJLUQhnoGeb+Pxy2LFWBT7Y41mhi T+JRi0jyQ6VcgHxRKo3bfiMmnHsTNek+aWBahPgsVUTJYUzQNvin4I/u8ag0dWejdARJ/rPk2hNo t90qbMJvvYXstFNG2oYDeXe+ypuuvFMyVuRslk4zYH3tFdW+ihym49mkHZNcUXf+0IguMtOJf289 G9Ih2rgifZT7uaLEr+SwY7h8K4Qu1p61oXt4P55k/YvLwfJvAAAA//8DAFBLAwQUAAYACAAAACEA 2oI3jsgnAAC+oAAAFAAAAHhsL3NoYXJlZFN0cmluZ3MueG1s1F3rchvHcv6vKr/DFE7VMRUTpEhZ 8jmyBRdFScd0LIkhqKO4UinVElgQKwG7OLsL0fAvv0aqkr/xS+SX8yZ+knxf98xeZhckLpTKUdkS uZeemZ6+d0/vN9/+NJ2YD2GaRUn8uHOwd69jwniQDKP48nHn9fnz7l86JsuDeBhMkjh83FmEWefb 3md3vsmy3ODdOHvcGef57NH+fjYYh9Mg20tmYYw7oySdBjl+TS/3s1kaBsNsHIb5dLJ/eO/ew/1p EMUdM0jmcY5x73+JceZx9I95eKyXHjw46PS+yaLeN3nveRjk8zTMvtnPe9/s85pePwtHYYrpNu8c T6Iwzs35YhZmj/zX/pYG7p7Z6YwmyVXWudt4yoI4TZNRNGmBcjTPx0ka/RzkQJ05CzF1oOQ0SINp mAOhDYD+C9ksibPwmjeI30fZLBgA70BgFqYfwk7P4E9leY/4+yCJR9EQK46Cibfa1YHM5heTaLDu 6xY/Mo2r8MIEsxmgCFK2ATXHarvBJZbUvQiycHhbcGPM7EO4EbSSbGSx9e08ToYhiAmcExpSVOfu yqvnBp5kJk/ehzGYbzhLIpAnmC4PR/OJSVL9GTSYfbsyUG+yJ1PuSpRjipH7cc1pehDPwiyZp4PQ vLqKwxRUnGVXSTo0x2loCdFn1+WU6IG21H0LkPpHL344NE/CIMUUjzLQFJl1UyR+/+Z8c1gDkUhv o+HKo1u6KF4EGaTzAQXhkESRzAKInNUpAq9FaTjI387TaOU5ZANI89WfJs2u/DR5ZeWHHTLIX9vh IUzTJF15XHn67TDMBmk0W4t49M11kB0MoMmytyIIVp6gRUz13S0RJOO/zaE6IS2Udzq7JswHe6vL tPCnGYgtexutzmxpOMIb49bl96Bl8mSQTMwzKx8b6nW5dGm8C/FdF94O6MpIbwN5LvJ7bVDcv+Mg Nvk4hBoHdV+EBspvaKZJGuIqbiWwcFbn87a5nVnep6Wy0QzfjIPcTKJRmEfT0ESZuYQWxaQTo4Sn 2guXaVph8qM0mZpAFrT6zImKDQeyxKPTuLURzUcCy31efZLryYNo2MpBy9lDiG7tt2RSZu3XZLAN 343hgHgc2pvOJ3k0m4RdiA4xp7uUW5n57df7qz/65eqPPvAfdeOqvDxOphcRTUxY9qY/n82SFNzQ 8AREq5q/BxO4DMsfW75l9LDWMCRm6sJ4U18OHl5ctLobEQyHQMLqxt5s3NzH5XNJRqNJFIdvVczU l5DCN2x/8xUQdPLUHCdxDIvHvMD84EtkRt/He/zvFH9lP5sPwQQO6EFnv/cNFAwMK0jiKTwuuZI+ T2CLyyPHwSS6SCM+Nwqm0WShlw95YV+A5b3ffj3cs9QE4FVP9fmxefjVl38FYR7uHdSXkffOyru/ /Xqwd3/vYNd8ucJjh3zs8AZogMfHGvzQGPRLPtbghSyYTg67F2pCt87+3RV8tGvuVwb6y7XTOLx2 LcDKDfevWyLQeS1Cef86TMr9GyFcN4OHN+yToP/6Sfz261eWNJr7VMHyb78+WO2xg70HQmh7IKTr pgfUXzP5+zcgroXgG0TVQL1HVI37CP3QWkTcpRFGMTtZAiMlQVRrEszMVZSPjRpn7uFmsKcE54dx roMmzzaB1QerBHjaYNUt0WKGPr4dzFWm54Nsn2a75KQNxj8ISFjjR82JlXyKnvXcOQEGozQMBPGL SNlwDYu9FQys9iLI8CEKzHfn56fmSZA1QlZVcXpIYerhcvnCVxrXRfqeJMPF1pBtaEJ21wNml/Hg nnd9+fS5b0dwGuBCSMAjp0eSqTeBaKzRSIIJ6ruznTfNMcVmHybrDYuQZY4Q8Opm8LLN2TLGswzs CsGe3vkPfbPD6Hf26K75uwbRfUOoZ6PjeZJMsr0ozEcSER8zEJ6OBjQKvA2+8Y0GSVz3xjANRnmX 43YT7ny3KnvXGLkBp5TQS6ColboXhzni/+Eg29fxPxx2l1jt3YO39/aImJUBih3cBSnRzOtOrZm3 FA505MOvHtwzO68ooczh3j0bz/MDGz2d6pJ5+tMTsLDtKmCP4bw3gC6xSn1wfSArGjnh+UMUv2+I zl5VbphzON3ZNMqYw3HCtg4UxugSS1nNBuBEX6Bd/PFMYyuJq6bxH2Rm1r74A87MmpTVmeW9N2/e dCtKNizNoO+QZ0Os+3kUTrxI8x8C0y2r+WPMy1kJdTxXZaVjb+obgyAbs4INFi+FonuceqT96eUL rw37h2PMTz67FubMe68zpKiNbEaR2MnU2C+k+6pCsLJrfzhsf+K5XYNrUPKmCP7EJNMiZfJenVQY G8rho2BFcFXURhZPcQnx5D1Z/tpvVbavJSZZw0vz/vWm/nOY9FeMyyNdYAZIkmcMzOdjRuelwkFS OMwlrG5kF+a8+A4a1ET0i3FKuBQmcyHN9SDCmRwmV3GXcU9ybT1nILmCWqQ923Qgej8uz0ljKHTZ IlZI0N3g6HCH04WZFYUan3YwZMaStbeE6wrihUGsNWJwOZi0LrO6qGE4QtxUMsXrkYB4c/RsbFXQ Tna3vveGvmQCDz/9PCsxvDpFgBqY7KL90qyfqdovBoU0CBxssj92DLDItPuM9UzABB32MhizPfDX ZyfmX4SWiqKf7YF20jCYTDvlTm6yepILURzF4F3kaFItTtotLgh374KkhriUzUfwNlgv9VYTE5K5 3ogHLdobSXPTMFgRvNPyp4IPN1lobTyk2j/iOPNWeyPIPDqWUpZNcdc+BtmtNUqxIcYoRCAGj/I8 jS7medhn1cYU22/CifwLPRI3LCvJSdc15Ibj6ypFnX4M9Angj4SzivwdTIJoKpiSAW8JPS2CvtTl 0KKbCvVCryMXOAiHLKZkDdHR6YkT77IA5PPT8DLKcriQGi1co+SsGIOCUYwG2iMCl9thK+8UbLUA b5MhAJgCTorkKrLSDba6MuKka1KkUuojc7dScmSyZNeMk6stQFNAcYZbgyyra0r0QpVeIvU8qRtX taGEe8ViVJNu7aW0jWsNN+jXmlV3SwO38MM0RLTLJCOYdNMpSoaZZIA4A0VrPaIoH0gw0Bzqj2kF EufrrfV1zCCKoGoQpYP5lCXQKM4SQ6juSFgKXyLJPvawS+Xc6gOLvScEURMFhKxm2hCmAeo8rXJY HXAhD3QnasKAkF+iUBpJ+s3hNmXMNmAFD0LhSjWu0snJFF8jro4IyJfAvEzyJyEwUSBSWbepadeD G0N6ZfPwJCaFFhp8e9jF5rUjeZN9EwQHk0tIqnw8rREb9E4WXa5kdKyOnuvHA02ni1nu76pirm7n rD4ksXat7ChthY8vMMqxblVKNPi4g8xDx+zgbzhDd2E3wDBaHWWl+GkCzuYXAIy/3yG9sxnk6xia CFp9osLFnfhihCnFSY5sJ7nZzqpguPVhxqYTBblDINSoW+mGMG/g3M67PMK5mw026XrWLaltU+ZZ jV9vaZzlCq8TzIfYDfwtem9tsiP+1aJk0IYme4AiRaOutQxbt40QwVudCAlcbKJqIOgfc9Ra04GD OzKV6BJKhu2Acxa+fRz4dBtBo2vB59zDn/I0KI32zMXmYEJCG1KFM09dhoZs9MJAQYDh1rDkPES1 Qy3iDzXvimMCqWsMtsbOcInrlQDfsBI/lFJbyvrWr4xWjzaqUS3Vu0LCW4zgrUVCUbDetbCpfTc2 XMLNPKIui1Y4rcckVS2fxBqVlfh7gLVoaZquTNTiGnRE9NzMIXWsbcsZDtot05H1q11AngePSrY3 weQqWLDKTDmNZwkuNMOAk1IiCnD0oZVn19spzELDBJ9wwKAq7sslQryV5GFJfvXFrEYZjvocR21L Gz682+BQTwSUQ9wyAco4dUFWJyiXHyrJcgvBVmiA+ojKXLc6koc/xPT0cJQb5DYWcbPwlEzFugYA uDEwHTGGOjZImIY408hUldX+S3MFq7MKt+IaCV0fP4oHkzkTRHZ8l5rYfLhayCjCipGJ5KnD6jlC b/EfYTCKW/XeHYbXG8Rxj5XQamAiAg5M2Zw5425+NGxrv9YNW4m199UDRPJ9FNmg3tMgD1zoCAiW WUGDeLNZfcEto2I4p9e3h0+KVAenZKzqAPQVtl6ET/Y1OgwwxHU5Hxl+dYS1Leha8G6F6w3Bfbme AMUh3JrquJwVx7qFaMqNG4XNcIl+m2i6he1xkDbbCZ96b2ZKNw5Nu40ZEwojDWeTYMGQvwfFzNIQ x1BxxG51oqqqhRp/qJw+gusZ94uMaFU3eIOvPmRtCUKuG8y74DfMUx1IW78EtPD3xsQRTkNAbujj bPVpc0SZOhOCqQbFMVjNnC/CKJZH19gIC55zr4EsDMxVPAQ98AsA4j6uvjYhZq/IZZggWDObJAsg rbSk4HuuDpZrcprkeqnlEZPU1LQm+VcfXNakCh80UqQtiGDLq05h+jB7i3qlZN5bPHKnRf4cTGdf G+k9k7Y81X7DBr3854cRDL95iogRcqAyQZpcaJsDQ8J/NkaIlY/413XArv4jOcBs180VxXYGfUi0 y0fjIIbfiqDn/A4QdTRUSmq8pF02/EkEwylmPo8QyZOfghl+HC5iJM/9Rz8EaRRiivNsHkxwaLQz XaBFDtoloa8SGyb5R5rba/4WWCOtn0tg72KCxgwWw5AFienoSQtIQylKpiEBGxa1WTzHa+S8beeu LfAvmyehk9OuuqmZmc7RuuiCjKjJf5p4PDZ31JcaIVsKUDymh/+LfK+F4q+8QWUu9a+OfwYeQ8Qk xyTY2Cg14WCcsIYxN9GIkh0P5D7Mg3tAfGZ2qshoFGHHQE8Sf55DLuLwBBL3jSdk7eP5NIhxcDwY Cko1xFVN/1PR8+QKD2OoAd8gjxhUWggs4BP1NBgPpw958hu5Z8QeZmGAOTgwcmqNcTQYrag9DSeN wy4xthoOA3YDOCg3xMdEFQNmVtRrgAw14CyUcTD2X6uc9oImatxFtAB7f7FYwvB67MR/SykJ2VzD nGkCFGBpBXWwq1GNXA/Gjf1YaTExcC3pHLodOye6u982YWnrryB7n2mlYu0EudKqvwJvhtAmwUSf bIKvseG3d+v4vmdAnz706upA7UQUENSJw6salpBECy5watV/HdxgOWfM19IQYhGcWgky4s3RJLhE AzXIxQbP1IevkkcVo/6okDjewO+u3meM4WEwni4BiWCjUUHo4pySwm0R2DSm2LzKHwFdrtKEjEFG 2cWKPiR6YLSQ50r9anqIwkhZ1uHDcesD4fJcqJPNrG8qpLP/DkTxEo4uGdR/xwnJgF41FIbTGf5z drPiMIR8G0eXKJTtQitBcrOMggGoJW/IAOMA7ckcqoEUJ5B3LZ7dLJgvbyK7ggvNx5rXZz/QclYZ 6w/cnwGj8OHDAfY1R1E0fh1EMxB/DCr1n9aFoYWV8JU1L/Wi/6gj8qoUaBAAEDJMppNFF23eQuwy NvD165OnPqyrENXjFOcw0KgcYkwzANEMQpW3MCn8s05oqdA/fPBw/6z/4MCeaCgV31n/yPTx/8Hb RjePH5udBF826C1uXIEA9CcdQ1gV1fL+TTeMqGYs5DQFRuP8ZPi4g/6LLNt/3ImT4yS2JdjSYqJc gJ3Shm/3VdvSJ9OfwIchigylVEq0/msQi1PAe7BovXOLz9kwUZa04QxeJBc4OyWy42mYvc+TmRVw W0G9bl3bzPZNceyBcbyKYy4mfGFuStc/6CScx9A+a7D1RFSruyYPv0F/xH7/lTlzxc/PpUZN2EnF Ojg1/AnuFrlyhEZ6ui1b4aViwW64X0/hZE9gY6Z0xW11qEha6D57R+ydYLJLoasSARYA/f95nrAK byC27wDGFrkcLKxGUpp8iHhqlcuVylQY71sttrZZCwi/E5URsCZR7YxWMJRaIofFk63qUKq7KMeR hgBm2QXl5hZU027Fg+9Nl0W3WgFwIo0SIXa3GKh33D97TtzlqkeFqyR+YdhhFUec0D5UCMyqpcz1 f1xsM2oM8UZvbsKzLNsAugo/hyqGkwSTk3bzRQgFGCUgtSBFI9ihOTkF0enmiT1Ni0MOn9AhYlwC i4TTgC5pc1jrC5QuT7eZj24RGB0VboVhL0jlNamyAz6pVAuTnpI0gIEDd2GgOnNDPtOxoe7EBqhI GnFNyHwTYR8MeES304Zl2M60VjAxgtuHCu9t0HDGQnNyZZn43wbcKVuaEhymLn3tCjtuQ1RZHbzh 24vthMx2g2ewHYmKqwjWzxVDTnCEWbuJmh2yK35yVpzo5G3wjoVC4NDYzeCPStW0msSzhO1gcRdD wQpHl1lyD4x08tg2I1Y8xA0356kgBHONlcqhWjDXraTVyQgO13soHrAoRO8EBgx+gZdbQQb8HTkO NVJFLg9JMAIkC1/cWrv4pRqwNDCbt8HWloT4//p1KcpAg2MNgGxILNr0GiqUEnkHHigaswUoXE/Q Hpc98kjf0gJO/fgNRyEbBRPUpM0vxyaG6iOD0nQDry6sw70haCo9Rk22Yrp6icE2BEniLpzAbQCV PQQ3RUyhUhkGTgt/dENwpZ2OAIgcjBVXB4U66gRloCQnkmEaPmAcB2fjttoWkg2kry0k3QKb7dYk CdGlXbYyITlPwQaVAExJEECY0yKjHZxliUjELabfA8zSzuduboVWCA4ozHQrs5O4q7vnG9LVx/I6 rbVuu3xuODmiumRnSkXETaAKt9nLPHoHqggvtE39NpDsEtfhx61mvqXZdgtUdzyBGEIuAXyFHJCZ JDixJxisdAp9CaMPFr1FztV+4n6E8yz+YjBRLFTeOSq/uYCoJNImjOVBQamPgmDlzzB36MCLQdl4 /ccwQ5inr9bfnj+hs2f9c/hXOBI6cq4kMl3ogDpwM6uGaQmoVMJXDId8j+QS/DPkJClbEp6jbgzy Ej1hGxcRh9JQo/i4+fgqgA3rT++wJqkrSJFVIb6kjduB0hxltY0xXiaNS3zRH+W4EvVv3Hwlnfj9 Vyw+/csvIXmczVCZrX3aCSX/rXN29aDJodGkafCOp6ikJoJCG4xuO4B0QVzyKyKlpADeHYAiUlAB 0Sk0Z5WeWrx8Ss4Y0ykp4rXMruBrDnCBMUrlmx6glCO4E9W7SqpwJeYpPsai7UhwH/OFna1jcBYg +izCiYEoz8IJQi0ZzGoOiUxGlDMqBPHEdRSvNvB8TqD4D09JDAnqmU6lDnGF3Ig7A4vQmzwDiFbI i9VuZ7AUrl2Ae5uIwRcXEFEY1jAg1uUFu4kwn/5BXHKozA+IaaLHsL9zr+Z5NxnhIyaIW1QZRfgB PIU9BXzni6hLj/CHD+ZYkTuBm8IcIzZ5ipKYIRiKMXHwFKISuKiBcnFemI8WLnXVFXRWGnBPcTeB rQNTFut+9epJAR8H5LBtyNUL7rgzsIsGQAc6u2vmGnGKeDiBNm9gtJgtUlJ1NVsleTlAUgRZNGAo +wZstBBYmUPnvuY8SqnTQX6lCMZUz/0WWElirE2RAoMPJIPocxUre+Ycdq8jUEzBlYxjIK2d5J7T Nh4koHHoUKDSoK8i1KswVAMBLyFt/S3sy8BdgEeCy22ngUqAYw4yQCgVzqndXIncCUvoiR6GniX3 uWgM9YyVpQgjFF+oKFgEc2amXg4h2Thtme6uvoCNVcM/QW2Bhs8q+/RGBUoo45CGiAymn5AmkmBO gXx9pLIF+GzEJTSCtsjc31dcjedDUI30hRwmaAspb2V/OkP+Dz76kXwEQ9po+AiEYC4QVFC/iItK rU0DP0/tASzM+1DSszTrFQ7duKKkAuqxq6KsAaIlU/4m/Bz0B/kDYThki01zgCbKsJVjEAr7rkrv JM1AzyE037DLFBjU5m138TMDn4gsADj+QbAcwhp02hhcVi3mOfdIiUAS7eRHXjqieoZIx2qGTVZU 5dSAigAfwqpjnauyXoiKD0yCeLBqQFtPgLqUZ0i6e1Dvwj/42b08CPgLlDuph2JdL4Bk56iImURS XoE2oPg+0HvnkCPOJGUO+ijeR8QXZMV4MhcVoTfFuQRkzs4bc3+mE42VYzA9wOLPTLjoqii6nZsg aog7IAUVI6yQSEMkldxrv1MB5IGwoen020tA7IcohO4iN0K8WvLCDGnP8HXgmmEFrgJ05Ra5Z55j 4BalwO12UEogFbWKmzjmOmV6E9KgcFZVtQ1JVbjDej4KghaU2O0ULSpNfyWEzJlKJrZG6FUSgtLk Q05xAukNbNcohastztGUZfuNUy0NKCfZ+Pdf/ptoYFqoFH+kCRAU7BQ4JiJVwiGElJ4Go3IEwrmb 1h5moJv2re0sfTWOBmPOiWEUFKUD9AXoLASvBcJY1LqB6b85l/0nmT67/5cvVXrxS0qwGUA4HBnF DNj29+Gi+yEAmmdBBL0GvQDg2nGCeJLiADe7SZKgxOQdNCK+jPKeYlZqvGSfYZkUouoSoE//WWL0 lalb5l0icfQyUu27nNJbECdIYQJT5z0vifDl9JU+iBLZRuldd6h5i6YkAANoYsGys8yoqHQsiJ2S FZVYwohwGEuEixoAmzL1x8Z1u+awO/oHPEpszyyKJfdHRmaoZn925Uvv1zdYAm0lIiL7uP1NnmpQ 2CvbAAWqHlQ2DrjxWUjzAkanq+cUWnJSgtwt6gN7jDA8FDttuQZg0tBongLLqai7hVMfalaAIQyp 2Oar5GgEbA1MGdTGVEzD5nqZJI0SAlkp8l0kRrxc6zriY3KZOpWKF2yuxkAtx6g/iIqdlFqCRNzE Jew5JB7SqOkLqcZsrOBZ/8Gh31a9Rx+u5OyC/ElPwTBBqwXbcoFCk3sq+T6wAZ2DDPuVXC3MJdkx lmZUOv8mGf/v//j4OALCnsXD7muGO45qqbAzlST+G+cgbGYBXF8taB7YeQh7wVrqPJlP3uNjlLMh qKGx8hdBzNowrYp9ai3sM8mKq3fdGGocLrRwcoqvX0pRGeWdVSl6qAZIOOsLTrg/bik+pGMtbPvz JP+62/3zZf41yzP7i3gwTpFB1+9Q+u9Mg5+i6XxK0VYPaVbsuxN8EFCOj0t0wGj+BZLKhwWkSSX+ QJSQaBHoG7XX9AML/hsg6q9Z7IAdxktsC0VRjR6ScsJTbJobXjfdrtlX9GJvFev4nZaiPxirufH5 jH18w9S/tdQFEc1CI9BGVqyaaew6n9PPYy57AtIDassVa4nl8goZiMpHaByx2G28jmaqXlZAvPkL Ci7hfULvMDDi34N4Qu/h+tjiZGWaA6ns/FKSEBju406N12IJntoEcwXc4ZcGKZKm7yrQ3E0qHxCD 5tMaoL/91ltOe+hb99o1LS8ro9Aj03u/p9aKd7UdKqv3+ecIZkQl+15j1UqDBWski7Xf6CPSg7D9 /s0zb9xepfy2C2RleZHXqOCRSrQScaP+sRSB0pEGRH6hkXwFMpE6iJZRwavo92EPIfoA5jCn2E5U vC//pjom/tWXR/6Vo5c/GmyKfxk7v2veZRD4MLVmSC03uBZi2H+JodFmFSDMY3aBabkD0Cpgmi8h xU5TEVZwy3cse9+1VQceoW7w+MnxF603X508Pa7EVcjuKvV3EY4RxaAyoF0VSEEO9oHyX7Kf/spt ba55bA4KT9V/5jlEkVSu0wfJ5tO2j1L2WMrknWqlIfezNV19mOW4D5eO2/aMuk/UWdosC3EpOBTK 2v4Y83gCwwT2lX9D3Dj/oksO+9cZUKarJ+ndLENdg3Ykbkjss2RCvvkuHF6EaeNQBlSZWEI/oeCC NqD16nhWI5nDJxCkCjfJR7vosizTIe2i5Mcw2685Xf5C/Af8+8I5VDtVKUOhUJZMP4J5C0NXP76N SMqcxoTo8L0ZSMwlAvYGyXQftVo8Q7d/+vzhw30JrnxxjjLTL05hHuvnqv8kV3mxvNY9uPfVXw+/ alh63B2E/1+f0OKU/ECLYHqJfokx3VYUXziPYw5xd4GIC5FcBOCsXVDRnlw390dNwBaDHB5KNRDp Ia99SwSjUuB37cYU+6wyQ0Mj1TdWGgwG5QUsbZ5oQXA3GLxncKNckn8Yp33G5+LQkviqkYIi2iZK XT41rhRMQxuDQntI4HAcTmagkAmFJkcGDEntUhwWPRThFzGqAzIr/Tza5+QdpGqy6ALuFPYZzHQ5 Ryx4z8AARtxZzsmJ8VqSuZ53uWJEjPvO+ncOPNUoii35LDCpT+M+Qj2YgQSDQBJz2AYy2yk/A0+7 tdSGLPrG3AgYbtpqOCzG46kpb+t6dFhEcmEM/x7ieDu24oPz8QwqjVkia47FXjQ+A9G+nWB5dmCm pljsT6H7bcoGlKFh2vLMbyWEimBQdesQTfVm2j4YuU8KWimSWTwPA5UHqjgBrkcC2VTJUotWxH9I BvjFftTeqou9z+54Y/aqaPXvaQmY2fkCUfL4kS+KHsmndQ4fyRkK0KL9XKks0+UrBTHiDy2Xfg3T UdGrIdHaazw1E+DMyk+gR/FaREbKxiPAw1ht9TIsqeriGsJHv0YPMlThVD4stAmfMfDx4c5CPGx8 Yo8ngFwwQmt4iuObtt5sB5IwTtARrhzWxaxlvEptXMWAjBtzOBEakGAHd1+mJDE2YfbM3P+rb3j3 Cg2EtCk+I8YHJR7sq9p2+juJ3dc3Eft0UTrQnq0YFw/fRxQWCjULcYePfgqR8mQAJMB0YcY4pec/ LhNkXSOeab1HNQIBpxIEP0hw139S4jWIu06D93CcwCKQRY4j66WqFQSX8g8LGkgJuw8XvIaAMirQ qMuUyJbMoEpuQvQldB8oaByNFlmkbp0SSGkIbzlcIDm5oMEWzL5LJ9vqS8SMzTlwdG+Y9h3lsZkv TP+7I18A9TCrf0KhE1IiCJ9czCN0uyORITqBylIGC4Ya60H9QDSJaDvAAIZVAukDLGmOhC8gBsIX IOKeIDKHBAnAIaEZggMct2XJKEcZAJ45irMrJg2oI0FXGTxPnEmD/sOCWMwFXYJZzLP2jEqptagX ugbkCo9PWMoq6qO+BO2tOVCMD8gypBZMvel3z5khNv3zhu/zIspByju2+uEMgWp0x/Qw3SsLx83O 8XgOO+EFD46S8BrPnhJtJ668Y+dJGiEXcIzj2Rc4Rdp4+jvJspmdJ8mF+RtsqyRdNJ45Ojy9jyeO zd/KsFvXPI0wje9QYJX7L7QTBl1mOXte8Zk1c8STTGpAwXtg0Z1N1dPeHoo9BFMi8SXP6qM4p7L2 nRIAXiRz8CVHvI0BK50bESdW6DAYWkDTrNp8Na26tzyE8DER6Q/d7MNFK/TjbKIKR2tqfJrluiE/ 5TLrKNZMuaPfbVbdOxfl8kyy82c2ytL4YOBynjrCxlYY16oqgdY2PUsD1GrggTXaffgS4qaB1iW4 nstT3hYmnGG2fKtuwEXzK33e1DxlsHyPiqBkvbNco1FafapFFzhfJPWOala+Nyv/a/XLp+WRzqoU fgPalo/nk5DboU8qO8pBP6X0cKPWd3gbubEczW363AVr6AU4S/rjjO5vMoIWfnNDioY5gtYsa23R wttYFEVgBObp0o9LrK+Jey73TmtWwzBaYV/aSUxaQ6Kq18vcpBjJkvJDjQbCSYsZykIaxyGxH8zG u+OH9gQZTGia46Kz4fizWgK2I7wcjWgAaew9Qvt6JIcsA1vIZWucUcMTMIokIaNgMG44wSxCkJ43 A5hyqKPZRVEA+9vAr+CpfFTSsZ+D1OJoc11OiEV2LNHBhCQSUTjpPP4pcVdEETOzjxAFQLLYGM6O 2tn0DsKfBqHEZekS1oAb307tvWLBXyU+JmU+9RCOJ3x7MbbGv1bdNbZqMe9jfMauZAAJHEsam6Ep YFNjArQSueATWrmheN4wGxH1gf+NbcCWscgHkBp47aPedMDCDnhMzFigAgV12VDQeY5twFWu4Vn/ 9MT0Je3zlEauNIozT20AuAETYHAQyl9aHRnAp5VmYrJ7D7eLCoecoPq1QTqWHVXttVj1XkcX8imi 1Y0IWe+0cqalGkqtUIhs5RTNOlCGhLAny3fghkPU2R0rnHTxEenSll66yxdIdE9KZ/gSaRYdjuXf IgqB6BLVJIMD7cUmDnefJK7PtCGnWXAiY2GyhbXN66xED0r77A4C2QnWlai3MN6nWUsjLEGOBudg hVwmzth5y6BQfvqqrIliP5Wi9KxUBLadULlr1IGIOECMX4JtpEgsyH//5T8yKQOD4IG0Zm2YBD2U 5aU+jPN49Nmd01c4T7Ev+/zZnQJpj0dJIuUNohHEoX1MSnnLXlFygz88Di4GB4f35XfUhaEs7HHX VQNJDWMo2R7cylAHMQun8iQKxx5LxY78huIxC8bHhxTwAGFWQGsFj4o30iv6wiBcK/QhkySRF5Tj MjzMQkP2ByAr5nAQobhIE9RiMbDDAn3Gq+ynytmryA8m9goB1zX9KQ4fIHYBitp5ym9eDs3zPUQV 8bXCuCHxVcoBW3rc8xJphx0NRV3tYzqD912NO981Oy+TD8hi5Ij3NaB4UrHq+fvI8h5tsUHxlRBU OqAEOh/s3TRSRRLtuLqLJW/qShnmkoOtzhqDrpT2ekiOLmyhjI1QV1PSN82jgOYtt10FHEHWo9Kx o8pKKIO/kzBw7tF0YOnz2xfufhkHRsURe7zvRHuI5JWPoVgrQgScaQrwUAe1AS196zrvgp9/fmvL ATqPOjCa0oMOBuQPoF0kvqWD0Wd39MlL9JGYoUPWI/Nve3t7/44Hv3/2TOnRW2ThQsYIROOMDr+m oZVRzaz1sbXMXNZScpyXcZd1rA6JTCCBnZiXYw0oe6Bg0ZAeOGAg8XQWXdA2S+K7X5vP7jRggomQ HatqrDRJoJkErG0Shyg+6tbkBIm2xeijwcw0nCLtLXYjTZaitUkWjCS6LaYkyyN1Hqp0gPIAKyfj 6vuUclQPgsGvfWTtSeZ3//js9dPSYhMaaKE7/WTO+zCckTjmMzXrbBmwLaAvJY9gYw9B2Uq2u8Qq I94o3wah2Re7pfkSzC+ZWrBiqkop+0oHEi/X9Tqbh6jHYoq9WD4Sqtn46DMbyJcOKIyc4lCO/ajl 2dNdyn6kXZGLFRsa2/0mvIDIugxTfb2PoxPArKMSlvMWp9YxJ61lgXWIZZKk97lZKDAdqp31taC4 9jFFCFyLcohK0q5LDjT2zC1ZA6aWk5QIRNF0ildJpnWH3ko4nwz6loaOoZ4grHkkvmuk0Q+WvP8O jT+445bSss/u3MIUsAmlljQdZhm5049EiGaaYHwkT3Rpzj6yg7es0BGClpt/dkd+t8hpBytP1MDW ceYgqjntI0s0bFH8DuP+BWQDfCgQB10yUEmA4yQh67tNOIIlxsMA8OJgUUESgawb1v3vv/yno5m3 MAd+/+W/Sr8Hpg1PY7AY3rUW/77/6mXBLRifLooEytUQZCkGvCsyvYMqv1jyKuAJcsFkpfqXI1uV t4R+G7M9v4KMKdPcMKF8314q1GXOigYm+lkByuo0mqvgCOR1XPlu4AgfV7SCzU6pcD9pclQVIN7l +QiktOmRuj+2xFTLtqrDuPSPO0vXJtroDNSGKJT5siLikycvwCSOc4r8qmbC7Afozc55MhyaH1Av NoYd1FDcVdnmk5neq/C1/4CcYziqm7R96UbrG2Ttip948wM118B0WRMlNRs7Xily0/vX7vdg7a7F VbmO/SzLe/8nAAAAAP//AwBQSwMEFAAGAAgAAAAhAEpV2LeFAQAAaAYAACMAAAB4bC93b3Jrc2hl ZXRzL19yZWxzL3NoZWV0MS54bWwucmVsc8SVTU8bMRCG70j8h5XvtpM0hLZik0tB4sCFj3Nl7Nld F69teSZ8/HsmAQShqdJUVXK0Lb/zPuOZ8cnssQ/VPRT0KdZiqAaigmiT87Gtxc31mfwqKiQTnQkp Qi2eAMVsenhwcgnBEF/CzmesWCViLTqi/F1rtB30BlXKEPmkSaU3xMvS6mzsnWlBjwaDiS4fNcR0 RbM6d7Uo547jXz9ljrxZOzWNt/Aj2XkPkdaE0Ln4SFCugIgBkaVNaYFqodTns8/robr1Uej1Jr/8 T5Md45bg4927vVd2Simg8kDNMpcd9UG7YhqSiz2ZzJw6iaYPI3kLpkB5U7hIjjN4+sjs0YQ/URzv gAK5PEJqfVTd3LkAKgLp7WyOdmCTXa5Ldmns5PiIe+Slbv4urcM9+x1/287vZDd+F8PBu+X7YwaL +mVD2hQjWJI9IPKkQDn8OVCLUt+O4mhfFMsmvB/Jfh7I5wCyAGaekyCJG/tfcca7wVlX9L9NmF8P tHG+6JX/YfoMAAD//wMAUEsDBBQABgAIAAAAIQD/8fuApwYAAFsaAAATAAAAeGwvdGhlbWUvdGhl bWUxLnhtbOxZz48bNRS+I/E/jOae5tfMJFk1WyWTpAvdbasmLerRSZyMG884mnF2G1WVUHtEQkIU xAWJGwcEVGolLuWvWSiCIvVf4NkzmdiJw25XPRTU3UvG873nz+/Z37PHl6/cD6l1jOOEsKhply+V bAtHIzYm0bRp3x70CnXbSjiKxoiyCDftJU7sK/sffnAZ7fEAh9gC+yjZQ0074Hy+VywmI2hGySU2 xxG8m7A4RBwe42lxHKMT8BvSYqVU8oohIpFtRSgEtzcmEzLC1kC4tPdXzrsUHiOeiIYRjfvCNdYs JHY8KwtEskx8GlvHiDZt6GfMTgb4PrctihIOL5p2Sf7Zxf3LRbSXGVG+w1ax68m/zC4zGM8qss94 Osw7dRzX8Vq5fwmgfBvXrXW9rpf7kwA0GsFIUy6qT7fdaHfcDKuA0p8G351ap1rW8Ir/6hbnliv+ NbwEpf6dLXyv50MUNbwEpXh3C+84tYrvaHgJSvHeFr5WanWcmoaXoICSaLaFLrle1V+NNodMGD0w whuu06tVMudrFMyGfHaJLiYs4rvmWojusbgHAAGkiJPI4ss5nqARzGIfUTKMiXVIpgEX3aA9jJT3 adMo2WoSPVrJKCZz3rQ/niNYF2uvr1/8+PrFM+v1i6enj56fPvrl9PHj00c/p740wwMUTVXDV99/ 8fe3n1p/Pfvu1ZOvzPhExf/+02e//fqlGQjraM3o5ddP/3j+9OU3n//5wxMDvBWjoQofkBAn1nV8 Yt1iIYxNBkZnjofxm1kMAkQ0CxSAb4PrLg804PUloiZcG+vBuxODhJiAVxf3NK79IF5wYuj5WhBq wCPGaJvFxgBcE30pER4soqm583ih4m4hdGzq20eRltruYg7aSUwu/QBrNG9SFHE0xRHmlnjHZhgb RneXEC2uR2QUs4RNuHWXWG1EjCEZkKE2kdZGBySEvCxNBCHVWmyO7lhtRk2j7uBjHQkLAlED+QGm WhivogVHocnlAIVUDfgh4oGJZH8Zj1RcN+GQ6SmmzOqOcZKYbG7EMF4l6ddAPsxpP6LLUEfGnMxM Pg8RYyqyw2Z+gMK5CdsnUaBiP0pmMEWRdZNxE/yI6StEPEMeULQz3XcI1tJ9thDcBuVUKa0niHiz iA25vIqZNn/7SzpBWKoMCLum1yGJzhTvtIf3st20WzExLp6DDbHehfsPSnQHLaKbGFbFdol6r9Dv Fdr+3yv0rrX89nV5LcWg0mIzmO645f473Ln9nhBK+3xJ8WEid+AJFKBxDxqFnTx64vw4Ng/gp1jJ 0IGGm8ZI2lgx458QHvQDNIfde9kWTqZJ5nqaWHOWwKlRNht9CzxdhEdsnJ46y2VxwkzFI0F83V5y 83Y4MfAU7dXWJ6ncvWQ7lSfeFQFh+yYklM50ElUDidqqUQRJnq8haAYScmRvhUXDwKIu3K9StcUC qOVZgR2SBfuqpu06YAJGcGxCFI9FntJUr7Irk/k2M70rmNoMKMGnjWwGrDPdEFx3Dk+MLp1q58i0 RkKZbjoJGRlZw5IAjXE2O0XreWi8aa4b65Rq9EQoslgoNGr1f2Nx0VyD3aY20EhVChpZJ03bq7ow ZUZo3rQncHqHn+Ec5k4idraITuET2IjH6YK/iLLM44R3UBKkAZeik6pBSDiOLUrCpi2Gn6eBRlJD JLdyBQThnSXXAFl518hB0vUk48kEj7iadqVFRDp9BIVPtcL4VppfHCws2QLS3Q/GJ9aQLuJbCKaY WyuLAI5JAp94ymk0xwS+SuZCtp5/G4Upk131s6CcQ2k7ovMAZRVFFfMULqU8pyOf8hgoT9mYIaBK SLJCOJyKAqsGVaumedVIOeysumcbicgpormumZqqiKppVjGth1UZ2IjlxYq8wmoVYiiXaoVPpXtT chsrrdvYJ+RVAgKex89Qdc9REBRq6840aoLxtgwLzc5a9dqxGuAZ1M5TJBTV91ZuN+KW1whjd9B4 ocoPdpuzFpomq32ljLS8vlBvGNjwHohHB77lLihPZCrh/iBGsCHqyz1JKhuwRO7zbGnAL2sRk6b9 oOS2HL/i+oVS3e0WnKpTKtTdVrXQct1queuWS5125SEUFh6EZTe9OunBFye6TC9Qmrad3aRIwNZt Srj6unZpxMIik7clRTkCeZtSruy+TbEIqM8Dr9JrVBttr9CotnoFp9OuFxq+1y50PL/W6XV8t97o PbStYwl2WlXf8br1glf2/YLjlcQ46o1CzalUWk6tVe86rYfZfgZCkOpIFhSIs+S1/w8AAAD//wMA UEsDBBQABgAIAAAAIQDPzZ5jnQMAAIgSAAANAAAAeGwvc3R5bGVzLnhtbMxY32/aMBB+n7T/IfI7 DTBoC0oyjXZok7aqUjttryZxwKp/RLbTwab977tzIGRtWVGBti9gX3zn78723WdH7+dSBLfMWK5V TDpHbRIwleqMq2lMvl2PW6cksI6qjAqtWEwWzJL3yds3kXULwa5mjLkATCgbk5lzxTAMbTpjktoj XTAFX3JtJHXQNdPQFobRzKKSFGG33T4OJeWKVBaGMt3GiKTmpixaqZYFdXzCBXcLb4sEMh1+nipt 6EQA1HmnR9OVbd+5Z17y1Girc3cE5kKd5zxl91EOwkEIlpIo18rZINWlchCrDtjGKYY3Sv9UY/wG 0uWwJLK/glsq/LgwiVIttAkchAaQdQhIFJWsGnFGBZ8YjsKcSi4WlbiLAh/N5TjJwTcUhgikgpNE Exz1THPtZ57N8L3LhwtVDf/A85SPLEkbF3Gf68+bEx7YuTqIfhdXi8VVxuYsi8np9p7d2wWbnNiL 8YOgfsjow0f8O+RTzKkW45POqLGQN3168Ku1jIX/s3CwuRB1nuliRgFBEkG+c8yoMXSCZft6UUA+ UZCa0XBYjXtk9NTQRafbbyh4PZh3ok0GpaDOcDBzJUoiwXIHMxg+neG/0wX8TrRzkDeTKON0qhUV 0AxXGssGmE2ZEFdYLn7ktW30ap4HqpRj6T7DzoHCg1lt1QQfl83KXtUB+5uU+qD/sFJAi0IsLko5 YWbsq5GfzUsxluveyPu/7n8QfKokw2wP8LzCpdGOpc5XS3+Mw6Z3la8NNzsnT/IzmOePOowB2+Dw SruC3PACqxMUm8qpYKYN/wUxxyqF60uQCDieYh8WmAQ/DS2u2RyLnd8t83xz/KEabgcHCyUafE5w W8fqJcD9Z+dWC/m8sXq354XcYU8dvx4oQIP3ur13iErv9UDZ+lxtzEE7xOHk9cRh38lvh6gMXk9U dk9sO8Rh37ljv8Vy64PzEgXpieAqLnWYYuVZFvCqBpn8h0rWJCzAa1VMPgEvNoKrG7ijeyoFsCYl F44rJFb+mnJX5wK5oVgpQBAaCneoHuDI5msy6786fHXwNLdGBjYyltNSuOv6Y0zW7a8s46Xs1qMu +a123kRM1u0vyLk7x8jAgIt9sXDzh/+gNDwmvz+OTgbnH8fd1ml7dNrqvWP91qA/Om/1e2ej8/Px oN1tn/1pPILs8ATin2qAAHZ6QyvgocQsnV26eLWWxaTRqeB7/giw4YKwciK09RNS8hcAAP//AwBQ SwMEFAAGAAgAAAAhAIRrlQJsLgAAQxQBABgAAAB4bC93b3Jrc2hlZXRzL3NoZWV0MS54bWycndty 3EiSpu/XbN9BxvuRiEPyUFaqsU7miZm7a23TPbPXLClVorUkaklWV9c8/XqcAPff/wRC2RfZJfCD I8Ldw8M9EAB+/vd/ff3y5p/H55fHp2/vL5q3lxdvjt8+PH18/Pbb+4v//Pvm324u3ry8Pnz7+PDl 6dvx/cWfx5eLf//lf/6Pn/94ev7Hy+fj8fWNSPj28v7i8+vr95/evXv58Pn49eHl7dP34zf5y6en 568Pr/LP59/evXx/Pj58jCd9/fKuvby8evf14fHbRZLw03ONjKdPnx4/HFdPH37/evz2moQ8H788 vEr7Xz4/fn8p0r5+qBH39eH5H79//7cPT1+/i4hfH788vv4ZhV68+frhp/vfvj09P/z6Rfr9r6Z/ +FBkx3848V8fPzw/vTx9en0r4t6lhvo+3767fSeSfvk56uGvz7/8/P3ht+Pfjq//+f2vz28+Pb7+ /emvckBscfHul5/fDdTHR+lwsNKb5+On9xd/aX46tP1VYCLyX4/HP17Uf795ffj1b8cvxw+vx49B 1pv/fnr6+rcPD1+O/ydY5IscuxRbByv++vT0j3D6vYCX0rDvD9+Ob/7823fRRTzz9en7/zp+er07 fpGz/tJevHn48Pr4z+NfBXt/8evT6+vT1/D36CevcujT89N/H7/FlsUGhDYHmRZOQkahL/8v9asd ux0aVVSg+7eJPiXa+nj89PD7l9f/ePpjd3z87XNobv+2FysFY/308c/V8eWDeIl0620XxH54+iI6 kt83Xx+Dt4uRH/4V//+Px4+vn99f9Ndvr676y6t2EXrzZzD87cWbD7+/SB//b0KiWQYRoo0oQv4/ i2gWb/u++REZXZZxpWVcX193fXdd247rLEP+f2yHkyFXmuiLjPSkDtHLhJBphTRFI81VdyOmyIJu 3t7cXF03N6ZDwb+TSaILrx5eH375+fnpjzcSCaQNL+I0Elean5rwj/cX0r7U+mT/yASbX4ni0h8G LzjhAmL7IPsvSZ7oVs5+EY//5y+XP7/7Z2hNJpaeaCxxlwi59CCjv1lYZsWYK8usEyN2G+QsepCz YXJurJxtYhpR+SioBWjnBS3aWyvo3jP9DTB7wvTQsQNhbq6Ha70TOw/GFp8xxqbjtxgvwO8v5Hfo ZztIjeZdJiKOeHMZcX9zmRQwTsWLcr1wVvS14XpjL9L1EiG/A3GF3pIQGToD0nbArAhzA0pdMwbk bAoT/Br+tk1/a7Trd2jdXREwNra/BEH3nmlvemuHfQVz8Ex/0w1yjPnEUMZ8k14SYGs1GAvLRMj1 B5M4qyVk2mqEcVZjDCh0UxhitV3529hUbxDPtEqR0VH3jAGjHRgzttUYJExOOkZPGiTAdtjClZeJ 8MNWYqy5TBi2C5moZ4J8OM16AESxZSImPSAh1gMg3KwI4zyAMaNWo3U2hSEesE1/mxm3RcCUm3jG j9sK5uCZvh/jonETmdvOsV84zdqvwVk6IZMGTIg14BhfouJXhHEGZAw4wqYwxIC78rcp23jGD+EK 5uCZk7YJ1Z0ewpVjK5wGtgFvXiZk0jYJmbYNYVQWEe23ZgwEl01hmG3K36Zs4xlvmwrm4JmTthHF GNtMhtcA2/AKXr5MhA+vjZSB5jrBB1pJ2GfiazwPnABGxDIzxguAucuMdQPwplW5mLR1mK7bG6DW TBRCmwEirrAt15lOkAYRY2P8hEwg7zIUAt89EKjvx3TGBNtYK+GIbhsJ15Puk0ssydkH9TYdelCG UikdCqm7fMTaDpq/KrKt7cb2p0FMRHXdOKOkKZJBC2jmNkPa6bpbmDp2RFJ/Obqm1SnWJ7UjJBUi RqmgnGWol2Xg6sZeQYfuMmO1DL6/ylDwlcGEZISkyxlRN2O3o5Z35HrEvZkkaPmeSHLpxoFAfT/m atYUoqizglU4D4KV9+8Eaf9OR4y6OqjOV02WbTU/diAr1YvqL0d92V6GJNwN4oqQnJJ343DQ2mVY IUCHA6e8y4zttnO4fDHbbSxYmSgfkpOo27gUA9fZUQnQq3sKjdqNJthTCPp+INBpb8QKKASGaxkY 07E2FTrGSt4XVTUUW38Xkn8xnDUKqHuVIRsFMPitiaiug4C8YdBi1JZ12FAOnOOwqYwwqoAuLcPc hQ4L5r/LjNUNONIqQ1Y3LplkotBht0WUmGQItn4dhYqCpt9TyHlu0oHpHy63HIik054bagQ0WEVR 3aTawhjM+26CdBz1JUmLk/s6y9ad7DoIo9sMSTAdFX87Wtp6ZUi2sZPzwzOl6KaLkIcsm8ToVlyB 395lRnenxUG2YpCrPSnkJu3UJHM5XJC+p5KcszFJAB2IpF55pLWDNMrZoabCCOfNTtoJGp1t1aQj 8ju4SKtCoGlaK7OXadpk5I40NAjC5jIzxjXAfe4yY1roloMZ5FyDQuAamwEiFc9u+KPSlvMbCo1z QZpeKYR+Q6BucWL8tjIGjXGqptd4FhjJhagMjV5zl49Ym0D0WTFIuVbUw4ZA3WIM+9b/QhaNIarp JR+adsSUfJsYhXXQsk2Q8UTw1rvM2F4DtGKQirmx12sCdT1WXQRqvbOldps2uaVsKsk5m5fUL8Y2 WUuInpwlusv2bXer/iehcdowQYp1vh4dZNkmSDtfOqK7vGhgQlnl0ywEXV4zqB/HV/bQisttsyTt Y65NO3Y5bPi+BjowqB0bbm0V6gU9aqZtkqoL8YVhPhhHY1TIsk1ItIi9Uki666+UUnStsgZCyDJu LYCCH5i7zGhL+9uFDML5YTNAJPRv8x9Doj9oxmexg4gR8qsBDGrGOGJ1emax0PpioR0HczZkKRbC bo+4RJXPMrrEuLRi0C1Mo2sGoaQNgTq1mBHbtM2QjMJB7y1K2hFJDronUI8utyeQk3SYgawFWfXQ yM4XGWPTQ5GUD6qmzDZ05UNLygcMaisG3brw6CV1KGlDJHULiMbbDGkbdugyOyKpv4S86Z5B6Nh7 BuFK1IFBJ5OrkOXXR7ZUE+jIpoJztltitEauYXzetYkxo9FnvgTyka1ANLKlP85FtiJiHIYksnlI L+PbcSH9+gGdBtrmCm0LbrZsE6RzhXREfsfg4erKfJqBUIVrCo1TbrTqpgbaDq1UbcJFkx2VBINh TyEYxQcKjZKMTTqs8KqKiHiWtU1zC2XcMkPKNvmIUbuzDYOcbSiEtiFQt4BWbjOkh2XrbEMkaS+P rrCvgQ4E6hfjVGptI/HEjJc624SzwDaqvkrBqEuQtk06YmzTjw2Lp63yaQa6HT0rQmsCdShpw6DF mBFFSTsC9ZeQnB4YpIo9q9FQ8eioHjRasdTSpUpJVDQGFdDNMjPaka7BI+8yY/Tn4juD/ABILTKS 8E7VhkjqFpBNbzM0MxkQUX4yYBDOg3sC6Zte1l6iTWev2SXKLpwFI0AtvuURkCA9AtIRo9IeYusq yzbQLbjktjRAsu3RX9A6OybKFfI10IFAvcobrUqxOKwLKqkC1AOgwZWJZafKxKjku3zEaKuHeLFi EN532A6yR412mL7uqCSw4L4GOhCoV0HUavSHiuDOF8EtNHGZGfHHwX2uIdzcZcao1oeSdDEDYSjZ lhZN17nkeiQAsOtB7/ZE0ukAwIrh5rqd3X7T+Wq4wSJlmSEdA9JpRmG433yVTzPQLWSmawLJEwvD 1t04PjYMuoKiYDu0cvSGDifdHZEkD1nYy+0Z1AF0YJDSnHX9UC/ifFpxn6xLdaYJJ7cw+y8zpK3j y1N5yMd2cpVPM9bBcLKmEAyxDYE63AS9HVo5Wofkj6ThPtRXQAfSJp2JWuuE2gytU5Pt5PJQhZ8G o8ayS5C2DikFfXZPILTOdpCtdQrW2WXI2hkG2L4GOsxAVqdyvbN0Gs7DnARqkWWXIK3TdER+h5nA L3Xm0wyE9lpTCPLTTQ20HVqp2uQrJtJwzMH29HKQHhxmIGOdnlWzXXM1O13EE9E8GJAypMyTjxjN O5dnkDMPhcDlt0MDtOYB2hFJ/SV42p5Aeg6Os9OBQL2qn63mQ/mIsaZZ3Jx83rA8P9SHE63me0zs lhnSmk+nac272y+rfJqFIFlfUwgmlS1ppbvcjknClGzPILwldGBQOxraah5r2skl5j7VjfI7BBTo 6zIjUdn2SqFA0jaevlIqp/Qc38LYXvaJMYkuhPC7zGgj+hDIIBxj2wzNVLpElE50rUawmJrWiC+i WvDGZbi3LcNBe3o6YvqPd0NW+TQD4XL7mkEoaUMgf4dmaOXoRe6WyY5IctC+BjrMQNYkoQTRTlpV 3/apcNHOiktWy8xo05ByRz3mE6PoKp9mTQPxeE2gDgvlDYOuxqgQL7cdWjmapsMFih2R1F/CdLdn EO5KOzBIreNZ07BibnY1R57ixwmiwWcylxnStiGVnJ+aCYR1yDrLNgbExZzt0IBR7S1COyoJ4t2+ BjoQqFcre1btoa748RGRqhE9Ihq3VaNPkFY7KWK82gl0C+uS6yx7Ru2lAZNq95frL+Fye3o5sM1h BrJqD5UOqr3vZm8C96lC0orvsdxfZkgr3hdWLkNZ5dO0Th20ZhBGtQ2DMI3ZZkh3xV1uxyR1ENX2 DMLLHWYgax3RgbHO9MwdaPv82AJvRCz7BEWbmGstWFVSUYfH82xq7G6AZsZkUJBl3WVGW91nUAxy GVRpkcx7Q/rot8QQUTqDivPUPYF0BWIVKB5kjBXm9Jur2dpiEc6zCmxwZ94yQ2oo5SNGX+qBsjSt E6i7hKW7NYHcrLCpgbYZ0nZ2knZUEsSwewqBy+wpBJIOBOrV6qU1IVYplXfeFqle0SGkheRpmRmt m2vo0F1mjE2xNlsxyI+B3KKZMZAofT0yBjx0egxI984aA+E8GAOqiI/OvFwkSI+BdES3v8WNWqt8 moY6fBXGmkG4pL5hED7otx1aqYIPrrvviKQen4y/Z5Cqr6NS9gzCVObAILVGbMcAVou1Y4DUjZCs Lxelbhx148cAqST9GCCQHwO5RTNjgImCgvc+N1z70MkF7UWotzClqtlYF0/EQeBUGKSb0jufZtqG HrAikOyLtjcl1gzCOxcbBl1BINtmSIbnOAPjINgTSVqp0b8PM5B13bNKt4Uv3RZ4U2qZIR17SFWm 9qXn+ddDnXpgNELbQfaoLDJreklOWfssybgC3sE5zEBWo6EoQV+eLYYXqZTR02HvNl5lSGvUV0Au EV/l03QXHbSugTY10HZo5WibBa657Gok7WugwwxkbcNKt5qEPdVgMqsPY9OtVCwSE41jLyqKNw4x WZEsAm0jGu60WWZGh4prCL93mdFGJ7VBupiB/JyQWzQzJ3hRJC/ykB6RRm1XrLiSlzfO3vKJJ4IG XWqZITWU8hGjC7WJOAUnAnW4sXnNIFdnM+gKjLjNkDa0vwdNJGmlxobvCdTjQ6YHBql1SGseVrpV DKUrVrrBrLrMkLZOOs1Yx83Y+TQNdVjNrwnkpo4NhXDGHlo5RgUnaUclQcG1r4EOM5C1TihAcBJq +35+8KTKxc5D4JbLqwRp86QjWvNuilnl0yahNYNcQsUgXEHZZkh3xbVpxyTh+tO+BjowSG0As+YJ RZgzz/yLLq7CeXa56gaz3cz4eegqZO3nXDTXBGryw5dnLqNs+3TXNVTzd5nR5vczEoPcjJShmft9 RJSfkQikK/UcPFm9M0YDa1pWylTsnLpKRYr2VozPy8zocZfOMjpVu87zpOWhDrP1dZatJXW4NrZh EL4AYDu0cgyLHRYyOyKpb2DXyj2D1JDKxvG96/Hm54FJOnU3K7xX14yTyXwt0jbb6GC1cJkZbTdS mqi97dluBHL3frNsaze4B7Jh0BWMz+3QytFu7rbujkhy0H0NtK+BDgTq1fKRHXms8KoZeb70atxG lasEaRP60qtVe7OzCT3U4Z6d7SBbKd7dYsyQtjPJ8vzlHHSYkWR1embBdJWKIRPNYHQvM6OT22uY zO4yY3rtVrYY5LYelhZJtBhqOH+Hg4gic0bqnG5Ur3bAWAUKZYJJWBqsqmLCiTauNN0450T3Wl4l SHtlOiK/Qy9btb89e6WHOtwlsM6ytaQOF2s2DLoCI26HVk60aUckuYbvCaQ1H3t3YJBabTPmuWZF ZkUVE8+z1sFbm8vMGP+GwHyXGa1knxMxyPl3adG0fxNR3r8JpKOIVaAMceffs6td1+Esq75G7XJI zp0h5dz5iNGW2sEeT1sTyCcyDLoC42yHBox+6xMZIqlvoJ7dMwgfvz4wSK0IWLXT+m6+gAiWAcW7 d8RkRvvtDWQ0d5kxlnBxmUGYy68JpF+ME226zdBMwk9E+besUGisx62WQ7mlK6bJTPA60Nap3b6a zGifTmcZTbpMMJ9mIMwENwTq8EH07dCA0add/rYnkhx0mIGsIlnpWfO0z7WvPXHcLDOjdUrqNbw1 usqnaZ12uHlowyB8+HM7NGDUqYsTeyKpx1XxA4NOpbvxkyLaOeNNx4olnnii9dPG7UPKkFaqr7Na VULFgbrKpxml4k3aDYPwMbjt0ACtVChZ9kRSj6s3BwapotU6KtZ+lXdyr1OppvPdBjdnLjOkdUoq PB9GPeRuiG2ybKN4XHPeDg0YdeqWk/dEklsROcxAVqehKEFHrajLrlMxY3WKe9ozpHVKaiC3UpxP M+rCleINg3Apcjs0YNRphztN90SSzqji2DnMQFanrC6bf3/atS/LelyaWWZIq9QXPG4ldZVP0yp1 0JpB+KDihkE4qrdDK0e9L/AxzB2ThHn6nkF4uQODTtV816ID4/DTaUOg7Zpujw60jCL1Fob7fESr Ww9T4y03Z1Y58Tw7U/S4nXeZIeUu+YhpmhuBDMLkcDvIHo3s77BQSWNGFwfXfQ20r4EOM5BV/FnV 0Y2vjha4A3GZIa32dJpWuxuAq3zaJLSugTY10DZDOob7vQA1kvY10GEGsrY5s4S6SSWU/A4rLFiM LzMzGmedj2i9O0++J1CvHiSyzf+h2uTG1yau7suMkEPHrmG6vcuM6YZLWAjU4dr+ZoDYe6zyH0/W e1YTWFxMhtvwcT6o0nCD4DIz05ogNYbXhIc6XBzYlhadWrmxnQ1ZOCZTFQtWNyl71wOxwfeoLTM0 uu1dPjJjb18Z+ASVSOpcMjU0YHRBN0r2RJKe+VIyRaFxBdrq9Myk/4Yl/bCItMyQ1qnP51tc/Frl 07Ti3VaGDYO8TtPltDP7pJ9I8gkqhcalLqtTlvTX+KlP+uWDuXbT5fImQVqnLOkfzZ2K03ya0WkD icKGQa6QGhqg/RQutyeSiJ+ShqvH6a1OWdJfo1Of9be4m3t5kyCtU5/1+xe559OMTnG35oZB3k9L A7ROR++KJtwTScRPScPVlk6rU2n5WfE0nGdT4wXe2FveJEjrNB2R32GOJTlaBbTOso0kfIhzwyAs bbYZ0lODa9OuRtK+BjrMQMY6t2cWLvE8W1NhbbHMzGicdT6iVepmn3sCnczRbkNGfsZkHc+zzuV2 3GRGh3W34yYzpkMuRyFQh1FxW1pUlaPcssw6rLtPJmbxLNtp3MaxzMxos7t8xHRRPaqUAj+B3AaY DYOuYXbYDg0Yx69f6iWS/I4UBqnlVDsMxMpn+VE4D1TawBrq8jZBWqfpiNGpq9/zaRpySd92kD2q y42oPZHkY/oMZNWFBUHlIu6tLw1wtCwzIxoaArjbtJAZrRp/U5dARH+5RXXDLqThOtpMD7eUtOuo 7/cX3CZI+0Y6Yvrm9hfk0zTk9hdsB9mjJv0NfyLJ3/CfgaxvnJnr3/pcHxcSl5kxvgHlwF1mtGqI b/gKgfhGbpEYZHBFvaHFdjukmdo3wpCoWIO/Temp8RIMr8sMaS8hWa16eC5G5U0+Tauic/fgB9mq k7hivSeSerxNeGCQ2gNn1RUySFRXRaZ9mzJPrS63zJIZ7SXu9npmtGqIl/g0l0zcuUV1XiIXdN2u eBz7Npxn5xl/RzFD2kvSaaaX6nGD7CUe6vAByO0gW3sJTHT7DOnL9XjH4MAgtaHJeIls4yL6qngT RDrRKgz9dVkgpbBySHehVfeHo8bkW66hWXYztktS5OOqidKy+lMJSHN5ZiabTrQ9bfEhSulqEK9v b8jXcdMh3TxffTLKR8pC6SHn05BCmSuqsjEqV9RG2qUocBCWCVfEkeYynGjVtsAdeqK2RBkPSYd0 J1wxJ18VrqDkq8KEciUmpVyNWShtAteuXaEmW7+vosRQpPWqXWAoaZiJfJO5U3MZcFtfLtyKSqFG 89yXQ7qDJ6vH5vLMPDadiN4DSyniPSm5HJsngy4d0s1jg85TbNAV8WNMZoPOy/LJP23X6UEXUlSc vGfLz+YyZbYyvId0aoH7gURpiTJKS4e00pxry5CroGTIEYoMOUIp1y7TQKJMh3DHkQy5Clky5Coo GXLTFAw5zMRnhlxKd2VQD+Zxb3xpLhMUrQNXwwR45mopgdXhCvfbiS8QCBYMZEiRVBirSvEOT7kh Jd7hKbeUL995ZxSMfkkSEnXyFlt0InEPL8xtGBb38JRf6p6jwGCYgs8YLOW5xmC4W765JJA3WIL0 cPa5dxGlKXdnTwxGZOGTHWIwRsHdBLGEp5glPMUsMU2BJaSTLp62YSV+xiThPJuGui1xzSWB8KZz gbSy2bSURGmKjSFPuWlJTOKpDh+xlzGUKBlD5bNrYiZ/ptuELAOGUeCvEk8ZNY5ka6bwfWdiptkn fpt4ItgJaqflCJWe7sshaeMQkf0uYUb1qsqHPoTkGqfuimWKpklZuRn+8BiK9KFApQ+bckj3ocNN DwdGTfQh5J3Yh5qcv0kJq56v3WarJkO6o+p2YQzadwXSvSLjJYvSFBkvhHLjZUeviJ8REY/xKTkJ TpQawzR4jGjCabvKY8KJNkeWkhhuNDdNooy64Wl4UXeCtCJb9cBRNMqKUUzdRBbOGKJuRkG7RN2M ckGGUifVHdJ17dzTU0CTsnudtLln2JoMkaQtJCc/crWUfkqvh4DktrjIS6Wi3TWE77gXi/pEluQA hPILcEVWgMdm4dtjxKT+km56v2eULpdgbGCGHRZ9xckrpoSUR+tQ1OJdfYmnKtsukScdMkMBbx2t y4ma6vCpdYnNXlaHtzi3hdL2ZPHJy/Lvzi+ydLu0dmMfZTYgstRzNmCDkBn/wIBJibTuDapP9O4h df1iCZKSoygJSp7qGggRYglC4V0vsUSiZh3dC2OO7iltClBySGe1kitv+DVNyoO1uhvcji76LlTJ G0Rv6ZD2FBbMPeXqNdFbET/GB+bBTBZYSkJ+BSUePE2BcqWT5yk3nGjzygbXMkS5hVLKTYfkdwyY GH0kiHiKqc1TPe5uELV5SntbGfiEUi+8tGprz03H44mQmODAXTaZ0utQ+ZA0clAbyfoIRTyXUE65 27ER6oo+WaGyxgQjKndfZJnWqyW+bAIm67QJQr7vwkII39NZS5vqBD37LfAhNrFAoowF0iHdB7IS mE+0FBRc6yLeUOgGG0r5lUDWIb8SSNsFtbjYqaKPB0adrpharJhmzJOqCB20fcyOMm3wQc+8azKk dUzSPEK5pR4ZC6lVc7MfEaZnP4gh0kfjwDOKCThGDqxo2gQZt02HjBrUg+dx6K2afKKmugZqDnHb Clnitp7qrmGrhKi0NHUML47aFUq3i0R4csVefYcD9P5jVU6bqhwdL/w8lyGj93SebjkL2J5yO8FF 755yAVv07im/Cb9Qov1xIsHBI3r3stycKeGigpJwMU2BdUKl5ML6/LsPmjaVWNpOLb68UeJ6ooyh fG3GDOUpNrN6ihnKUx3uEpEBkqg5Q3lZzFAVlBjKU716Hh4MFQolNNT8jbg21VemV/hsrpipUCVv lHCeDpnxpB70LnHMU/IhORsmZaQQCtcJxAClEeNI6XDNTkaKl8UMUEGJATzVq2fnwQChiEIDyBdS 3oqQmakklV/aBgt8hEtsUChlA1+3sRSogpKYRih8J55YilBoT7FUovTYX6j4H31DLEVk4QYuiWmE wiuKpQilFr/AUqEi05aaMU8q4PS6Gq6fiHUSNAay+3JIj5DT2w9awX6kTQG3GZd6QDoqWNrkIeW9 EZJxnCD5Hecff8uUUO4pQ/EhIgsXzMWHCsUeRix/nU3tipCx2Tq1i50T5/EUWQOfoazzdFhqTjtP xK2hcBvcsiEQVmN3BZIeTRkqi9KUy5/XVJY31CCLGir/VQxVAtKOySVWGeSqnuDVD0yWth1YJRRK ekiHRamazYFdOBHsAws9Yh8CQQIt9kmQ1jzJWwhF8hZCuUlMtO2vyLTtKa3HOFJE29MUaBtryGpt +2pSLSjksNV5CF8NLtpO0Jy2PcW07SmmbU8xbXuKaXuaAm1LYnCeb4cTwbdh6UN820NE2wma07an mLY9xbTtKaZtTzFtT1Og7VAdnRVJUlkl1xriMz52Kdr2ENE2KdBwNWpVRGmbMG0TWTi3SCTxFNO2 p5i2pynQdihxztJ2qo2Mtr1ve4ho21dZLG57imnbU8y3PcW07Smm7WkKtB3qmbO0nQoho22346Pz EL7CVOJ2grTXMm17imnbU0zbjIKltD1tF8lJmKxxdR20HWoS1PZ8Rd6lUsbo2m++HKiSfIlqSQ2E lZKEjQpKEkRC4QOiG0rhFbeFanSeSMS3sB9EbFJBSebCqNG+YJMfK/06UvqN5i75ii/98nnay0+X fp1gzk9q9jDFE+38ju/ElhknSLcQPlMmrpMg3V6yNk8oNiqJLDLjeIrFQE+xGOip08s0PdZvtbev 44lWkfgs5rIhkNd2hqTVQ6ZAtE2oDp8nXpcLGlle20QW0TahiLYJNaHtUFZgDKzx7T7VIzoK4suH RdseItomlY1f4MiitB6JbxOKzDiEYtom7fIzDpOlFnFsdOtDWXGWtlM9YrTtsqko3Q4Aom1S2RBt e4pp21NM255i2vYU821PTfi2qOs8bYcTrSLVs4B5Vuk9RLSdIO21LJJ4imnbU0zbnmLa9hTTtqcm tB3KirN8O9Ujcq0h2uILoCSSeIhom1Q2xLc9xbTtKaZtRo25TXSVfWm88QISSbysCW2HsgK1Lcup 8zcz+lSQaHX3/mmegRrT13zI9EI9Mh77umoItcA9dDIr+qpogbtTN5TCb9dtC6U7tGig+NkVSrd+ gZ+mEUuRdjWwknhg1MnvsDR9KEm0pSSyhL33H35/eX36unl6/vogfi8Hptepoxj7kKU8fWtv1Mkw SfVPO6Tyoup0SPaRF1OKytIxfTOkYNKQYRj26itiMJGFnF53qjpJS8WAvkrbgrGkG4UqTb4rh7T9 WlyalM6WWiOuiL+V7b36f6AucTCLjw+TRGcWPaW/a9fqcVu8uFaRojSHLi+uRSjsgLgWodR7d8AK WCxVWyFVRNoKUmI4ZyqUskI6NGkFUVui5tTmZfW4hUbURiiiNkKdVps03zjvzMgLOIw83DQpLpuo WERbKy3OLWjiibCDCWv8ZcMo9L67QhnD+akxy9IUuTlFKJc8bOgVcdLbFkq7itsUvCuUbpe74n0V ta+iDnMUWFgGknGo2nG4CCeihSFKiYUJhQNFLJwooyNiYU+R5IfJwqJVLOxlOauIhRNlLQyRVixc IUssXEGJhSsosfA0BRYOdQfOdzUPVi1SwSLXGmbVBjebioUJhet0YmFf/JBiglAdpkNrKotY2F+x w71vYuFEzVnYy3LeIhauoMTCFZRYeJoCC0vzjYWnJ4VFwHFScBV5ptikEJJ97VAzl0u1gXUjt9C5 IBSaXtzI1xnMjTzFAoWnnFElUHiqwxdgSQjwlJMlDsIo0IQ4CKNg24A4iKd69TYlcBBWcdWslC1S TaFt1+IHRyUEFGpMtvIhG9EhVxa1+ZLFFaqikGkKuoolS/V8lmsNFe1a9x7YZuEpeQjHZp/ipoky vcfEb8Uo5qZEFkY70WQFJQ5YQYm+KyhxQE/16sF6sEooDXTIqLZKqimsA4K+xQELJQ4IFw7Jtb7w TKxKubgE32HKW+ADS3K5RLHQKCY3l6vuZzgRsykY9HJhQmGJL96XKPkdOuGCpMyihMIcV8IfoyDL E+9jFLRevI9RPvxVUOJ9jBqvaJ3g6twqJp5orbLw+8wHagx/+ZA0UpkA3HbTEKrzQ5tQLkgemCxN gUJkPJ3lpvnL9Xo4yoqSDX/LhlE+SGbK6ghca11kGcq7KZOFyd6uStY9p5yb0isCJVYJin5/car1 YJWQ8+lYFYJHzT7D/MF6bZXWv/BqoJSbkixTvSMxriSJ2jzlv81GKfUCDugqZqy1cfIq5a66q7Ii 6ByQUMQBE2WMg1uhxAEJhYNUhrKnOnRT0aSn9CCN+hYHrKD2VZQ44LQssErIKdEBa9LEq5SMaqu0 /jnLgSoOKM0jWezJd8rET7+f1bySn47RWEamc5pClebdNeRj861qXrSXeAjLT8e5KFLiIYxyawmU grAiHuJl9XhzQZTrKe1tYPuQzp2l3JQHatsv8Ms4MiUUSinXJ5DkARPy3XhHiQkqZIkJKqhtoWyH IMTIUK6QJYO0ghJDTVNgKEylpzPa/I14k9H2kImIeVQCHf1V1KAOQQswp64O3iVvHsfhondL9+X7 7sM9HzFvOlFH6gVu/5MWF/HiY9BiOdM494zOAg4LJP4JmPx18nHrmYzLdKJu5+kRFz/Ofc6IKx8I V8ml3HvBcMYo/D7WXcO+EI5z4IpRHd5GWDNK9z7HQXJFsqBCKCdrX3XFA6fG+GxdJX67+yyrSMDA Cg7fgb1s8qfBR6cR5aYTjdPg56alE57q1Tt0oBMsk6yZyMMOUuhE658WHKgSzKUTPkd0axnSCU9N dCKkLmdZIuU8OoDLrTg3PgjVwkwr/fL5k+vXjlHMW70sR4mOpikw9LkZW/4+tdERvn9cvLXkdS6i xk8xn2WclJToC7fukzhN/tIzWWGJ3yvWF54O5fnzxuJ3QyEuO02cL6QJeByVEsz8nOye7r7n1OhE YCycuWvnzfw9Ya0zyZxdJ8qErbsKbi8OnSgdbTpcQhIn9FSv3hMF/To3H8if4tX9anFfizhhmdan ++VThA53fUu/PNWr11VAv8Jsrl2t2l7hRLtsJMm4s1ehVBRNh+R38NauhUJFOuGp052IH7k9pxP5 67jaOJKoYicGauwE+axuh4nHoSHURCekFc4SNbcwyVdrJbF1nQjiwV64sWfVkE/SdjhhSL+SLG3C iX6F+VAbZzqY5a/KWpPACF82jCK98VOx2y4hvfGUnrLseInfetW9CeOlZv2qfCRWub2k0s5KbMKG 3ouV/PTJ+uWpXr2VA/rFJtmqfpXpcxzOrS+Ny1djde+JvZIs7Vcd1iRiL0/16mUX0K8wFaO9arLE /ElW7YcthinxwzLTu+Qhfn70rAuXeVordJxuY4UhF/aUvC/BupM4ip/gXWYnCvXUxAA4d4LPHxg1 CsV9UNKvMsF7heIMPBNH/IzaYoSWy3mKqdHPqGy8eWpCjWF+0+4x05s0HWrlSclnzS29KZSaqNIh +R1m21btJraDJX4tUjeqNhnIn5nUzWtx2lg2hCLKJp+s7NRnxaP/H4os0y+1Fg39koYZZVf3K5xo J80W2yL9KpTz2fjZRFRoTVTN31vUCpUdjGhvRvkgQL7d2KmNw0WhbBYc829QaJhasF81UTV/GFH3 q8WtcqLQMguOfky+qNj51WBCnU5M4jcNz+oEm/Jc1pg/mTjWW+K0ZOZSBSno+NyZK39gUOtYVlac 75SZawwM8k4IS60a8rHCDj1M+pVk6cHYqzuT0K8w25yldjLlqSe58sRIPn3I+uWnvA5LZumXp/TX EaBfODFOR/T8gT8ZdUNglpcwWf3LSFDTYezgfTmkla23YUGjwpyklT3TKDId4hq0NIpQGBXvCmXa 6fe7km8HkvciEUpPrVEzG3ZFsupaI0u0zCbzMRzGK+45BbmauBGTNVJgMVGYsVj1XBVOtHOVrLM5 hypUCa1iqHRIfgdPbPFhA4kEnupwHUPU5qlexQvT1ZZ+kLBiFkkn2q62+GTvcqSGrpZDpquYRq0Y 5bLme0Zpn4SuhhShehzK9+69LfHFG9JBQuHEflco02c3Dhnl+rxjlO5zilBV1L6KOsxRoOWQw2gt Vxbn8o1Hr2+10TT2S/RdKOVQ6ZBRrpproXksa6pY4ZGPGbjmtbjVQ5pXKNW8dMg2b5zkoXkhO9Ha m5wr5F2ksVGigCFsyCvHIN4Uyi9yt/Hza/pywVjh5snMZUneorZkFlMRCp1ehobPW1oMmRIOPNWh rE2hwvdJBn10+FEZiRpeWK8SD7DImamSbF92DiPL+M42hMKOiZJIEoRjQ5TkqQ7TSem9p3rlM9B7 TKgqZ0LZ0ex7j7uZZLgQivQ+UXYEwTK39N5THb6JU3rvqV5dEXofkgYcHlXBgmRn6iZqGSCEUm2J lNieZC7oR9J7T3Xq3aFRlgwQQt2AT4qOPNWrT8mCjsQsg47kv2ciR6Bt1iD3StygIBRRTKLkdxjs 7i1M0hlCKUe0nTFfRJMTpzuTP4NmizxcIGgZ5TuTKdsZKBjviyxDne6MznfmO+MTmRbXfZdyj97b j3QmUaaZbrNHkaUpt9lDukxkne5ySAXKgBXBtdEqf0BMLjW4ktw4QrccqHFyZ18ew4EufSAZivoA AfhgyBfO6UNJPVQf3Ct+2/ztLtNTYkCSsyC1KrKMAfEFBdJ5IuvUKmEbv+wFna9Yq0vn2bjS4t1m 8d6yaKQM6JeDWgxI0gdP9WpmBQOG9EL1YSaIpGREG6TF+8nS8kJJy+FqYTpXV6t2+ZQG6OvKPUXn 8oRCR7hryfetWnW3O04+4i4+8ejUKMhTFKNuYE1GDOJl9WqyBxWFOR9UVPNRM6ln5UTrVXKn0umI UERHPvFoMcSIjjzl1sQ2lLqBWVR05GX1KiUAHYU5X+loxmlThjCuq4qHqkMgWgLED4gONOyJdPcy ZWxny7jxEL/3ozpSOx7yd4JkoI9TwKWzdabMqFEb0G3H44dvzmmKiBcV2KbgKlKbP6tjmnIyS4sf kYGm1MTV/PEZ2xRYglvKPb1sDaU7FcNAK2R+q2pKmkdsU6AKkKYkymhF3TKGpogw7ZnVvhLOQwNB Gi1NSZRpinpaBpqiJw1RZ3VT0sRgtQLhUppSpg9lILXdEpoSYmvxFWnKdCjIn5fQoUAfAtEhJNWL TgHMiFaHQLQOYPOtVtEqTjyiI3UIROsANi9ahaYiWh2youNb5KsVUt5WP+xYX8o2tuiKZG0nvgy9 XnSKOVrX+W3qTLQood6M+S3nRnQQECZWF77jm7zrW11Ge0noRCHqEOhaj/ZZM+a3SZtWlwHtWw2j d3rIdGU0qlarQ9DqHxqN+c3EptUpVWK6/qHRmF9Ra0SfHI3x3bH1ZlRDLw+Z/PJZ1uofGo35da+m 1SdHY3wraHWr8ztEtWh9yJoxvgKzXrQfjfkdmkQh5oWZs36dX4BpWn1yNMb3N9a3Wg29bMb8AkjW 6h8ajfnVhqbVJ0djfEFdfavV0CutVofAjD80Gsv74lS81oeS6Hcvn4/H19XD68MvP3/+8/vx+cvj t3+8qP9+83z89P7iL1IVXrx5/unx4/uL5/uPURMDPiDiNwMSX2bnETH2gMSX23lE7DggfWi8R0T5 AxI/nuIRUeKAXBEpab1+QCSWfHx8+f7l4c/3F59fX7+//PTu3Zen3x6/vf38+8ePX45vvx1f43wx XEmU9P3ht+P/fngW6uXNl+MnSd0v34qg58ffQgIV//v16Xv8L2nOr0+v8jrB8q/Px4ePx+fwL+nv p6en1/IP6XCQ+7fj6+/f37x8ePhylFxPOvzp8fXvT7tjln3x5un58fjt9eH18enb+4vvT8+vzw+P r6rTN7G5fzw9/yOa+Jf/LwAAAAD//wMAUEsDBBQABgAIAAAAIQCtn3pcZAEAAJ8CAAARAAgBZG9j UHJvcHMvY29yZS54bWwgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACEkl1PgzAY he9N/A+k91AKbpoGWPzILowzJmI03jXtu60ZtKStbvx7OwaI0cRLcs77cM5Js8WhroJPMFZqlSMS xSgAxbWQapOjl3IZXqHAOqYEq7SCHLVg0aI4P8t4Q7k28GR0A8ZJsIEnKUt5k6Otcw3F2PIt1MxG 3qG8uNamZs5/mg1uGN+xDeAkjue4BscEcwwfgWEzElGPFHxENh+m6gCCY6igBuUsJhHB314HprZ/ HnTKxFlL1za+Ux93yhb8JI7ug5Wjcb/fR/u0i+HzE/y2enjuqoZSHbfigIpMcMoNMKdNca3cVqs2 ePQtK6kyPNGOO1bMupWffC1B3LTFSu4guPdr2wz/VoeDJyOVA1EkMUnDOA3JRZkQms4oSd/Hu8Hk 03TlT5FABL4OPZUflNf09q5cop5HQjIrk5SSS5rMPW9wdZX8X0dg3ef+lzhJmMwmxAFQdKF/Pqni CwAA//8DAFBLAwQUAAYACAAAACEA2qOSaC0BAAA0BAAAJwAAAHhsL3ByaW50ZXJTZXR0aW5ncy9w cmludGVyU2V0dGluZ3MxLmJpbuyTz06DQBDGP1pj1DSxj2B8A40voAUMDQhZIOWK7dhsQncJ3Zro I3r07BP4AF7bWWxJvRk96hD4zc7MN2H/RZCYooHGkt8HGJyhQIKU6XJkihUWIKg2M+FKyR4xP805 wOEbin5/DTj8vJ/ooxnzFEWvx7RfIGSF+aLbyn8EZ6uytN0t12zbcAc3uMvPMXTC/gAvrx+7X+7y +85xN9h17wL/zh9Zgf2dH/IgjbKxnfqQj9hv7kmg6pW5kQp+LKI0zsXIg/BSNwyRK9nQ0nqBMtRU VD5KNUfs+wgW5Zyyp5owTrzbiGaIG0nKlEZqhSQWmbgOMox0VZWGWomgpa5WbT6uLS6QlDU1qXwm hF6WecLW6ybSM8Ll1X1d2/l9xwZcFBXuxOF12QAAAP//AwBQSwMEFAAGAAgAAAAhADwCMP6BAQAA /gIAABAACAFkb2NQcm9wcy9hcHAueG1sIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAnJJBb9swDIXvA/ofDN0TOW0wDIGsomha9NBiAZJ2Z1WmYyGKZIiskezXj7aRxdl66o3ke3j6 REndHvY+ayGhi6EQs2kuMgg2li5sC/G6eZz8EBmSCaXxMUAhjoDiVl99U6sUG0jkADOOCFiImqhZ SIm2hr3BKcuBlSqmvSFu01bGqnIWltF+7CGQvM7z7xIOBKGEctL8DRRD4qKlr4aW0XZ8+LY5Ngys 1V3TeGcN8S31i7MpYqwoezhY8EqORcV0a7AfydFR50qOW7W2xsM9B+vKeAQlzwP1BKZb2sq4hFq1 tGjBUkwZut+8tmuRvRuEDqcQrUnOBGKszjY0fe0bpKR/xbTDGoBQSTYMw74ce8e1m+tZb+Di0tgF DCAsXCJuHHnAn9XKJPqEeDYm7hkG3gFn3fENZ475+ivzSf9kP7uww9dmE5eG4LS7y6Fa1yZByes+ 6eeBeuK1Jd+F3NcmbKE8ef4Xupd+G76zns2n+U3OjziaKXn+uPoPAAAA//8DAFBLAQItABQABgAI AAAAIQBBN4LPcgEAAAQFAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsB Ai0AFAAGAAgAAAAhALVVMCP1AAAATAIAAAsAAAAAAAAAAAAAAAAAqwMAAF9yZWxzLy5yZWxzUEsB Ai0AFAAGAAgAAAAhAIE+lJf0AAAAugIAABoAAAAAAAAAAAAAAAAA0QYAAHhsL19yZWxzL3dvcmti b29rLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAKharMM3AQAA9AEAAA8AAAAAAAAAAAAAAAAABQkA AHhsL3dvcmtib29rLnhtbFBLAQItABQABgAIAAAAIQDagjeOyCcAAL6gAAAUAAAAAAAAAAAAAAAA AGkKAAB4bC9zaGFyZWRTdHJpbmdzLnhtbFBLAQItABQABgAIAAAAIQBKVdi3hQEAAGgGAAAjAAAA AAAAAAAAAAAAAGMyAAB4bC93b3Jrc2hlZXRzL19yZWxzL3NoZWV0MS54bWwucmVsc1BLAQItABQA BgAIAAAAIQD/8fuApwYAAFsaAAATAAAAAAAAAAAAAAAAACk0AAB4bC90aGVtZS90aGVtZTEueG1s UEsBAi0AFAAGAAgAAAAhAM/NnmOdAwAAiBIAAA0AAAAAAAAAAAAAAAAAATsAAHhsL3N0eWxlcy54 bWxQSwECLQAUAAYACAAAACEAhGuVAmwuAABDFAEAGAAAAAAAAAAAAAAAAADJPgAAeGwvd29ya3No ZWV0cy9zaGVldDEueG1sUEsBAi0AFAAGAAgAAAAhAK2felxkAQAAnwIAABEAAAAAAAAAAAAAAAAA a20AAGRvY1Byb3BzL2NvcmUueG1sUEsBAi0AFAAGAAgAAAAhANqjkmgtAQAANAQAACcAAAAAAAAA AAAAAAAABnAAAHhsL3ByaW50ZXJTZXR0aW5ncy9wcmludGVyU2V0dGluZ3MxLmJpblBLAQItABQA BgAIAAAAIQA8AjD+gQEAAP4CAAAQAAAAAAAAAAAAAAAAAHhxAABkb2NQcm9wcy9hcHAueG1sUEsF BgAAAAAMAAwAJgMAAC90AAAAAA== --_007_4E1F6AAD24975D4BA5B168042967394367511EAFTK5EX14MBXC283r_ Content-Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet; name="OAuth Feature Matrix.xlsx" Content-Description: OAuth Feature Matrix.xlsx Content-Disposition: attachment; filename="OAuth Feature Matrix.xlsx"; size=19538; creation-date="Mon, 11 Mar 2013 19:42:12 GMT"; modification-date="Thu, 14 Mar 2013 20:46:57 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQBBN4LPcgEAAAQFAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACs lMtuwjAQRfeV+g+Rt1Vi6KKqKgKLPpYtEvQDTDwkFo5teQYKf99JeKhCPBSVTaLYnnvudTwejNa1 TVYQ0XiXi37WEwm4wmvjylx8Tz/SZ5EgKaeV9Q5ysQEUo+H93WC6CYAJVzvMRUUUXqTEooJaYeYD OJ6Z+1gr4s9YyqCKhSpBPvZ6T7LwjsBRSo2GGA7eYK6WlpL3NQ9vncyME8nrdl2DyoUKwZpCERuV K6ePIKmfz00B2hfLmqUzDBGUxgqAapuFaJgYJ0DEwVDIk8wIFrtBd6kyrmyNYWUCPnD0M4Rm5nyq Xd0X/45oNCRjFelT1Zxdrq388XEx836RXRbpujXtFmW1Mm7v+wK/XYyyffVvbKTJ1wpf8UF8xkC2 z/9baGWuAJE2FvDGabei18iViqAnxKe3vLmBv9qXfHBLjaMPyF0bofsu7FukqU4DC0EkA4cmOXXY DkRu+e7Ao4sAmjtFgz7Blu0dNvwFAAD//wMAUEsDBBQABgAIAAAAIQC1VTAj9QAAAEwCAAALAAgC X3JlbHMvLnJlbHMgogQCKKAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAjJLPTsMwDMbvSLxD5PvqbkgIoaW7TEi7IVQewCTuH7WNoyRA9/aE A4JKY9vR9ufPP1ve7uZpVB8cYi9Ow7ooQbEzYnvXanitn1YPoGIiZ2kUxxqOHGFX3d5sX3iklJti 1/uosouLGrqU/CNiNB1PFAvx7HKlkTBRymFo0ZMZqGXclOU9hr8eUC081cFqCAd7B6o++jz5src0 TW94L+Z9YpdOjECeEzvLduVDZgupz9uomkLLSYMV85zTEcn7ImMDnibaXE/0/7Y4cSJLidBI4PM8 34pzQOvrgS6faKn4vc484qeE4U1k+GHBxQ9UXwAAAP//AwBQSwMEFAAGAAgAAAAhAIE+lJf0AAAA ugIAABoACAF4bC9fcmVscy93b3JrYm9vay54bWwucmVscyCiBAEooAABAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAKySz0rEMBDG74LvEOZu064iIpvuRYS9an2AkEybsm0SMuOfvr2hotuFZb30 EvhmyPf9Mpnt7mscxAcm6oNXUBUlCPQm2N53Ct6a55sHEMTaWz0EjwomJNjV11fbFxw050vk+kgi u3hS4Jjjo5RkHI6aihDR504b0qg5y9TJqM1Bdyg3ZXkv09ID6hNPsbcK0t7egmimmJP/9w5t2xt8 CuZ9RM9nIiTxNOQHiEanDlnBjy4yI8jz8Zs14zmPBY/ps5TzWV1iqNZk+AzpQA6Rjxx/JZJz5yLM 3Zow5HRC+8opr9vyW5bl38nIk42rvwEAAP//AwBQSwMEFAAGAAgAAAAhAB0ldkGlAQAAswIAAA8A AAB4bC93b3JrYm9vay54bWyMUk1vnDAQvVfqf7B8Z4352OyugKjbpWqkqoraNDm7MCzWYhvZ3kJU 9b93ANFEyqWn+bD95s17zm5H1ZFfYJ00Oqd8E1ICujK11Oec/nj4FOwocV7oWnRGQ06fwdHb4v27 bDD28tOYC0EA7XLaet8fGHNVC0q4jelB40ljrBIeS3tmrrcgatcCeNWxKAy3TAmp6YJwsP+DYZpG VnAy1VWB9guIhU54pO9a2TtaZI3s4HHZiIi+/yoU8h47SjrhfFlLD3VOUyzNAC+NLSX22h+vssPT fRzGlBX/lry3WEzbPkoY3Et/Ksn4JHVthpyids+v8mFuP8natzmN4ijFEUvvM8hz61FuvoujaQ57 hT0LhDPmSPTM/vskGkcnpniHBDG3B4mJvav5jLA+q0RX3Vsyhflikm6j+QaM/ovzRYaRXK3M6W+e hB9uwn0ShGWcBsluHwW7JI6Cj8kpKtOb8lQe0z+rPSNP3xikZGWNM43fVEaxxZs3NvOQcb44XWSI clh/zsSyFdY/WFFd8L99g+YoHHq1LIQ8UZiVNVtfFX8BAAD//wMAUEsDBBQABgAIAAAAIQA+g65i +A0AAG1SAAAUAAAAeGwvc2hhcmVkU3RyaW5ncy54bWzMXOtu20YW/r/AvsOAfzYBItlWbm3gsHDc ZptF22Rtp8H+MsbiyGLLi8oZxXFfKO+RJ9vvzPA6JKUhJQUxAicRyXObcz+HOv3hUxyxjyKTYZq8 9E6mxx4TyTwNwuT2pff+6vXkO49JxZOAR2kiXnr3Qno/+P/8x6mUiuHZRL70lkqtXhwdyflSxFxO 05VIcGWRZjFX+G92eyRXmeCBXAqh4uhodnz87CjmYeKxebpO1Evv8cn3Hlsn4V9rcW4+mT39zvNP ZeifKv+14GqdCXl6pPzTI/rMfH4hFiIDte0r51EoEsWu7ldCvrAf+3fGi2vsgbeI0jvpPWzdlYN4 l6WLMOqAcrZWyzQL/+YKkmMXAqRDIu94xmOhIM8WQPsBuUoTKTY8QeJ9IVd8DrFDflJkH4XnM/zU 2HtB/5+nySIMwHHII4tbdyCr9U0Uzoc+nstHk3EnbhhfrQBFC2UXUGtwO+G3YGlyw6UI9gU3AWUf xSholdpoZpvHeZ4GAsoEwxGMNMp76Mw9HeAbyVT6p0hge8EqDaGesDklFuuIpZn5N3RQ/uAM1CL2 TUynEiqQGBb/HEimBfFCyHSdzQV7e5eIDFos5V2aBew8E7ki2ubar4kW6Fy79wDp8uzXX2bsleAZ SDyT0Cky1rFC/M+Hq/Gw5tojXYeBM/ZcL8oHoQbZek6OMCClSFccLsddI/BYmIm5ul5noTMNcg5n 7n436azz3WQrzjcXwiD72k0OIsvSzBmvvvs6EHKehatBymOeHCJsPkckk9faETgTmAum/uyOAtL4 rxVCJ7yFsR3vERNqPnX3aeLTCsomr0N3Y8vEAk8sO9n3EWVUOk8j9lPuH1vhtd+7tJ6F+2467wKo s9C7QF5p/z0YFJ3fOU+YWgqEcWj3jWAIfgGL00zgU1xKkeG423kXbRe57VOmMorCD0uuWBQuhApj wULJbhFFQXTKjOKZ6IWPKbUC8YssjRnXDLlTTqIYiShXHkPG3jCyA4Glc3Yncpg/CINOC+o3D610 g5/SRLHBj2lkI59NUH9YFurH60iFq0hM4Dp0Oj0hvyXZl8+P3W994n7rU/vWAq/xl+dpfBNSionM nl2uV6s0gzW0KgEdVdnvPELJ0H9b/5FRgTUgkViZEsYivR88irjQvYzgQQAhuCd7q2X7HPtpSReL KEzEtXEzTRYy1IbdT76FgN78yM7TJEHGw34FfaglJDPP4zn68w6/5N/sI49Q9554R/4pAgwSK3ji GBWX/iR7nSIX17ec8yi8yUK6b8HjMLo3H8/ogyMNTPlfPs+muTYBeL1SfX3Onj1/8j0UczY9abKh /Ivq6pfPJ9PH05NH7InDbTO6bbYFGuDRbS17aCF9Qre1bEHyOJpNbkwK3Un9H3eo0TZcryH6biMZ s428QCpbrm9iEeLcKFC6vkmS+vpWCJsoeLblnLT4NxPx5fPzXDXa51ST8pfPT91uO5k+1Yo2hSJt Ig+i30D84y2C61D4llK1RG8pVes6Wj+ULaLv0mqjsAcyRZKSoqkV8RW7C9WSmeSsuLnd7KnA2W2c TdD0vW1gTWS1Bk8XrGYmWlJoy7uA6UKeDbKbzG7PSTkY/aAhkSc/Jp1wqin8vHInAqgZZdpAcL/o lAUDMvZOMMjayybDx5Czn6+u3rFXXLZaVnV3OiNnasmyn3EnvEWn71Ua3O8MOW9N6NO1gOVsPD22 Pu8nn87tDEUDSgjd8FBUkUhTTaAZy0wngfHm6exWTRNOnbMH6TC0aFkqdIDd0+C+w9mxx9MH1qHZ 41/9cskeUPNbvnjIfjc9dDsR8vPmuErTSE5DoRa6Ib6kPni2mFNSYB3w1idaKrHpiSDjCzUhvJOU Tn5S970DMLfgVB66B4rJUqeJUGj/i7k8Mvg/ziY9Wfvk5Pp4SoJxBqjz4AlUidK8SZyneb1wECOf PX96zB68JQ/FZtPjvJ9nNzZ8Q2oPnTZ5GixyuxrYcxTvLaA9WakN7hLCCheF8/wlTP5suU6/7jfY FYpuGYeSRjiFs20CRTLakymbtAEyMQ9QXny41Dj3xPXU+BuhLM8vvkHK8pSyTpnyP3z4MKkFWVGl QT9jzIZe9+tQRFan+ZuQdAc33wZdRZbQlHPdVxbmTfGGoclGU8GWiVdOsbid4kj33f2MN9B+c4b5 1anrME7lv5eYUDN9GOVgR5pkv/Turk6wdmrfnLS/Mm0bZA1NHivgr6wyHV5G+U1Vod6QQo0CjlCq mBxZV4o9yqN8zf7gp2rH19GTbMilfX1zqv8aKf0d9eUxLmBzDMklNebVkrrzesNBj3BoluCeZJfp vK4dTFMT3S/qU6KkYLJoaQ6DiGIySO+SCfU9yWqbMwM9K2h02uVYRFT9FHNOSoZEMS2iDQkqNwg7 yuHsnq3KRY2viwyTsXTwkRBfPLln6LWG1FzmUSebdaYCsUDfVE+Kh6mAruaossmXgh7Ih82zZ1RL pqjws3/JSsLuGgFtoGEX5S/t/Zl6/sKwSIPGwZjzyXHAROLJT7TOBElQwV41Y3YH/v7iDfuv1qVy 6Wd3oF4meBR71UmO4Z7UhUQcJrBdzGgys5z0qPxAW/cjqFSAj+R6gWqD9qWuzWBCT65H2WAu9tbQ nLUSVjTvzPpTaYdjGG3gw6j9gHjWnfkGl5Ye61WWsbLrxkHm1tmlGCkxciJwg2dKZeHNWolL2tqI cfxMRPpvxJGklVnpmXQzQo7Eb7jU4fQQ4tOADySzmv+dRzyMtaQ0wj2Jp8PRV7EcUXSsUy/jOmaB cxHQMiXtEJ29e1O4d80A5vmZuA2lQglpuoUDVs5KHOQYddJA+YiGS8eRb94ZsPUFvDEoAJgcnF6S q/nKApl7MCKiG16ktuqjac+95ILJ9BFbpnc7gCYHRRTuDLLarqnEi1B6i9Fz1EyuGqi09eqM0aR0 g1npwpsnboivjaxuT4g77CEW6HaxdIGULo6xMkxDBrgzaLTZR9TBBx4MOof1Y8oCSebDeH2fUBNF i2oeZvN1TBvQWM7SiVCzkMg1vMeTHRptr59zR6zzPa0QDVdAkE2aFiA1wJ5nHhzcAZf+wJxEwxkQ 5N+wKI0h/Xi4bR+zC1gtB63hRmuKTafCp9gR0V0Q8C+c/ZaqVwKSKAVpTLcdaYfBTeC95Fq8SUhD ywi+O+zy8LqFPObctIB5dAtPpZZxQ9kQd2R465R0uItnMz7odHa/UvapGsk18xx3lCS1jb6jyhUO 7zAqXHv1Ei079jB58NgD/EYx9BB5AxIjd5FV7qcNWK5vABi//8B4ZxzkTQZNAnInVFuxl9wsQFKS Kkw7yZpzqkqDGw4zYV7IVSFAhNGC05Ewt1iu94cK8drNiEPabLqVto01Hjd73ROe/oDn8XWA08Bv HfcGqx3J32SU1LShlJ1jSZGZ0lqjbeZG6OC5KyEB1zlRvRH01xq71lTAoRyJdXcJK8M5wjUtvh0G PpWN0NFB8Il28UllvEraZdGbQwqJaEghnObUVWso714wBAgY3IBMzhJUN9Sy/9CorggnhDoA2YCT IRaHrQBv4cRupTRYGZ79amzNbqNJqvX2rlbhHTBYvOhWFLJ3s9jUfRojWdhuI6ZkMRtOw4ykHuXT xHRldf+dgxezmmY402FxgB6ReLZbSFNqu1pGAW3PepTX1UVDnl48qsye8eiO39OWmbE0epfgxkwY 8KaUdgV49aHTZoedFKgwbYKviJDX3X3FItxbpR65yrsz46YZhfYVFrWrbtjw9mGhlguoUOxZATWe piNrKlQxH6rUcgfHVkaAJkZjXHvFZMkPPT3zclSBZB9MbHeeelIxNAGANXLm6WTIy5uEmcA7jTSq yqN/76zA3VToKDZ46Cb+MJlHaxoQ5fiL0cR4dI2WUQiOMYmktw7r7xFazB8AGblbU70XEh6GpLCe 3EObBBMdcEgqn5lT383uhu1c1xZoa732S1MBYvi+CPOm3o9c8aJ1BAFrqhBBLGrcGe7ACnRFXN8d PmmkKXAqw6ojoFphZyZstW/oIQeKTTMfjd5dYF0MbQRfcDgMBZ3LZgXUBeHOWkfsOOLaQzdl60Hh MIpBfz5o2sPxFJDGnYStvduNssBDqd1ow0TAyMQq4vfU8regsFUm8BoqXrFzV6p6WGjYh/HTZyg9 k8tyIlqPDRZyd5QNFrS6jqC7tDfQaQrIfH8JYqH/twhHOw0NucCWmTvZhFGTTgPBzDTFgayRzpdt lNxGBxxEDp5ob4AsE0yXCsG88AsAunx0500rs7XkEqRo1qyi9B5CqzIp1J7uYImnIpJs9lqWMumd ms4hvztyzZMJ+NCRcmxBAs5ttQiYNkz/fxidMfqOEN1G0kfd3J3s2R4nfulH81y5rAbrtZZUY0Jo E9G/7GZ7nvpEnMPJ5FNx01a7o404HCXYvsff47EUaWBjCQ6A79N1jnEfCGttQWTtBjqOrgM0zT3H c9Ose3J7qZc9hxOkjbpd5B0Od9HZaHWXDo9ydzb9K/OVElQ6sIt8Yar1Lki/3ZyZAFwkEnkhqqEV yl3XgNHLJbZ9bkM0VPb+Rd5R+2lPkigaDqarOUIW7RcwLNKGe89m06BVAzdJLQt82yH4lAZUrXOL KvuLCJxVp2nCTVoOokKuCIeqUj/HthIXOvJVXWWFdHfvMZzV/nPdn5gpW2iL2nwzVX1ju65V+8Nu Y+7onBGytQqj8O9iUetuXxmF0+YSmhkDUxpfvwlNho9SqHht8JK+i7H1vYjuOrEBZpGmmHhBa4Td CUsj+TrC10X6/wcAAP//AwBQSwMEFAAGAAgAAAAhAHCxQL1qAQAAwQUAACMAAAB4bC93b3Jrc2hl ZXRzL19yZWxzL3NoZWV0MS54bWwucmVsc8RUTU8CMRC9m/gfNr13Cwj4ERYuasLBi+LZlO4sW+m2 TWdA+PcWCEYIBjAEjjNN37w3M286vVllkikE1M5mrJ7WWAJWuVzbUcbeB8/8jiVI0ubSOAsZmwOy Xvf6qvMKRlL8hKX2mEQUixkrifyDEKhKqCSmzoONL4ULlaQYhpHwUo3lCESjVmuL8BuDdTcwk36e sdDPb1gymPtYeT+2Kwqt4NGpSQWWdpQQZUQKRttxBJVhBPQDS84ZTDVQsaRZUmVEHmRBfJHjTk6o 5Cgr0+BDkAHCGuHF5ZHc04wgWGmY2K3i9pQqfNA2lnsDojgmXDPJWJqKrbftuJ4Otf2LZOOUJI9r dShU+7YVl281lsOaWr8w3+b9cXzb5+G7cJ3OUwsk0INCsUpw5awFRbwCxGhB5PWPWrpY9ONUtC6l YmnBaYNXE0PaG+AB0McDBJyirf8rp3keOQfdl88v2ntdxMbh7X4DAAD//wMAUEsDBBQABgAIAAAA IQD/8fuApwYAAFsaAAATAAAAeGwvdGhlbWUvdGhlbWUxLnhtbOxZz48bNRS+I/E/jOae5tfMJFk1 WyWTpAvdbasmLerRSZyMG884mnF2G1WVUHtEQkIUxAWJGwcEVGolLuWvWSiCIvVf4NkzmdiJw25X PRTU3UvG873nz+/Z37PHl6/cD6l1jOOEsKhply+VbAtHIzYm0bRp3x70CnXbSjiKxoiyCDftJU7s K/sffnAZ7fEAh9gC+yjZQ0074Hy+VywmI2hGySU2xxG8m7A4RBwe42lxHKMT8BvSYqVU8oohIpFt RSgEtzcmEzLC1kC4tPdXzrsUHiOeiIYRjfvCNdYsJHY8KwtEskx8GlvHiDZt6GfMTgb4PrctihIO L5p2Sf7Zxf3LRbSXGVG+w1ax68m/zC4zGM8qss94Osw7dRzX8Vq5fwmgfBvXrXW9rpf7kwA0GsFI Uy6qT7fdaHfcDKuA0p8G351ap1rW8Ir/6hbnliv+NbwEpf6dLXyv50MUNbwEpXh3C+84tYrvaHgJ SvHeFr5WanWcmoaXoICSaLaFLrle1V+NNodMGD0wwhuu06tVMudrFMyGfHaJLiYs4rvmWojusbgH AAGkiJPI4ss5nqARzGIfUTKMiXVIpgEX3aA9jJT3adMo2WoSPVrJKCZz3rQ/niNYF2uvr1/8+PrF M+v1i6enj56fPvrl9PHj00c/p740wwMUTVXDV99/8fe3n1p/Pfvu1ZOvzPhExf/+02e//fqlGQjr aM3o5ddP/3j+9OU3n//5wxMDvBWjoQofkBAn1nV8Yt1iIYxNBkZnjofxm1kMAkQ0CxSAb4PrLg80 4PUloiZcG+vBuxODhJiAVxf3NK79IF5wYuj5WhBqwCPGaJvFxgBcE30pER4soqm583ih4m4hdGzq 20eRltruYg7aSUwu/QBrNG9SFHE0xRHmlnjHZhgbRneXEC2uR2QUs4RNuHWXWG1EjCEZkKE2kdZG BySEvCxNBCHVWmyO7lhtRk2j7uBjHQkLAlED+QGmWhivogVHocnlAIVUDfgh4oGJZH8Zj1RcN+GQ 6SmmzOqOcZKYbG7EMF4l6ddAPsxpP6LLUEfGnMxMPg8RYyqyw2Z+gMK5CdsnUaBiP0pmMEWRdZNx E/yI6StEPEMeULQz3XcI1tJ9thDcBuVUKa0niHiziA25vIqZNn/7SzpBWKoMCLum1yGJzhTvtIf3 st20WzExLp6DDbHehfsPSnQHLaKbGFbFdol6r9DvFdr+3yv0rrX89nV5LcWg0mIzmO645f473Ln9 nhBK+3xJ8WEid+AJFKBxDxqFnTx64vw4Ng/gp1jJ0IGGm8ZI2lgx458QHvQDNIfde9kWTqZJ5nqa WHOWwKlRNht9CzxdhEdsnJ46y2VxwkzFI0F83V5y83Y4MfAU7dXWJ6ncvWQ7lSfeFQFh+yYklM50 ElUDidqqUQRJnq8haAYScmRvhUXDwKIu3K9StcUCqOVZgR2SBfuqpu06YAJGcGxCFI9FntJUr7Ir k/k2M70rmNoMKMGnjWwGrDPdEFx3Dk+MLp1q58i0RkKZbjoJGRlZw5IAjXE2O0XreWi8aa4b65Rq 9EQoslgoNGr1f2Nx0VyD3aY20EhVChpZJ03bq7owZUZo3rQncHqHn+Ec5k4idraITuET2IjH6YK/ iLLM44R3UBKkAZeik6pBSDiOLUrCpi2Gn6eBRlJDJLdyBQThnSXXAFl518hB0vUk48kEj7iadqVF RDp9BIVPtcL4VppfHCws2QLS3Q/GJ9aQLuJbCKaYWyuLAI5JAp94ymk0xwS+SuZCtp5/G4Upk131 s6CcQ2k7ovMAZRVFFfMULqU8pyOf8hgoT9mYIaBKSLJCOJyKAqsGVaumedVIOeysumcbicgpormu mZqqiKppVjGth1UZ2IjlxYq8wmoVYiiXaoVPpXtTchsrrdvYJ+RVAgKex89Qdc9REBRq6840aoLx tgwLzc5a9dqxGuAZ1M5TJBTV91ZuN+KW1whjd9B4ocoPdpuzFpomq32ljLS8vlBvGNjwHohHB77l LihPZCrh/iBGsCHqyz1JKhuwRO7zbGnAL2sRk6b9oOS2HL/i+oVS3e0WnKpTKtTdVrXQct1queuW S5125SEUFh6EZTe9OunBFye6TC9Qmrad3aRIwNZtSrj6unZpxMIik7clRTkCeZtSruy+TbEIqM8D r9JrVBttr9CotnoFp9OuFxq+1y50PL/W6XV8t97oPbStYwl2WlXf8br1glf2/YLjlcQ46o1CzalU Wk6tVe86rYfZfgZCkOpIFhSIs+S1/w8AAAD//wMAUEsDBBQABgAIAAAAIQD1FLwTiAMAAIYOAAAN AAAAeGwvc3R5bGVzLnhtbMxX227bMAx9H7B/MPTuynbjLAlsF01TYwO2YUA7YK+KLSdCdTFkuU02 7N9Hybl4l6zBellfEokWqXNIipSSs5Xg3i3VDVMyReFJgDwqC1UyuUjR5+vcHyGvMUSWhCtJU7Sm DTrLXr9KGrPm9GpJqfHAhGxStDSmnmDcFEsqSHOiairhS6W0IAameoGbWlNSNlZJcBwFwRALwiTq LExEcYwRQfRNW/uFEjUxbM44M2tnC3mimLxbSKXJnAPUVTggxda2m/xmXrBCq0ZV5gTMYVVVrKC/ oxzjMQZLWVIpaRqvUK00KXoDpu0Okxup7mRuP4EDN6uypPnq3RIOkhDhLCkUV9oz4BkA5iSSCNqt uCCczTWzyyoiGF934sgKnDM36wQDalaILY4OTZbM7apn2utx9jkM31F+Olft4D/xPu09IQlsEB8z /qy/4ZORc3FrIO8Y57tTENmEB0GWwGk0VMscJt5mfL2uId0lFI4ubd26e1YvNFmHUdxTwG5DyHSl SyhU2/Nnj1onyhJOKwM+0GyxtP9G1fA7V8bAqc6SkpGFkoTDEG81NgOgU1DOr2wx+1LtbFtWq8qT rciFeVemCMqiPXTbIRDZDDt73QTsH1KKQf/PSh6pa77+2Io51bmrlW43J7W+3M+mjv9+fs7ZQgpq axHAcwqftDK0MK6WuyzDfXYd1x5NqE2HIVvKByCvqnsJH6HdQe6xsGigFnakvKXS7Cv43BZRG19k 25RhhZ1DgJF3p0l9TVdA3xVUvKoOkwnvJ9PBsXXcGnxOcEf76n+A+0vmdmnwvL46feRAPiCnhi8H yuDlQDk6mQ8e/AeE5LGP+QOgHO2HfzjUBRR9qo8qiK4BQMnv9bmfutyuP3j2QpKit9CyNWfyBm63 rsqDS+ct44ZJW/NHti//qvPRti2+VQDiPYVfuhDgKFf7Puu+Gntddx14hwxslLQiLTfXu48p2o8/ 0JK1Itqt+sRulXEmUrQfv7fXgXBoIUObeN/AnRn+vVazFH27nL4Zzy7zyB8F05E/OKWxP46nMz8e XExns3wcRMHF997r4QFvB/fGgd4UDiYNhxeG3pDdULzay1LUm3Tw3UUIYPexj6NhcB6HgZ+fBqE/ GJKRPxqexn4eh9FsOJhexnncwx7/G/YwwGHYPdAs+HhimKCQGttYbSPUl0KQYPoXEngbCdzsHpDZ DwAAAP//AwBQSwMEFAAGAAgAAAAhAJJ8t+BKEgAAFHMAABgAAAB4bC93b3Jrc2hlZXRzL3NoZWV0 MS54bWyUXdtuG8kRfQ+QfyD4HondvAuWF3vBbhZIgEU2l2eaGlmEJVIhaXudr0/1vW6jmXqxZfqo T1d11+ma4eHw3Xd/vDxPvnTny+F0vJ+6m9l00h33p4fD8eP99F///Pkvm+nkct0dH3bPp2N3P/3W Xabfvf/zn959PZ0/XZ667jqBEY6X++nT9fp6d3t72T91L7vLzem1O8L/PJ7OL7sr/PP88fbyeu52 D/GXXp5v/Wy2un3ZHY7TNMLdecwYp8fHw7776bT//NIdr2mQc/e8u8L8L0+H10sZ7WU/ZriX3fnT 59e/7E8vrzDEh8Pz4fotDjqdvOzvfv14PJ13H54h7j/cYrcvY8d/iOFfDvvz6XJ6vN7AcLdpojLm 7e32FkZ6/+7hABGEtE/O3eP99Ht394tfrKa379/FDP370H29oJ8n192H37vnbn/tHmChppOwAB9O p08B+Cu8NIMxX3fHbvLt91cII2Kup9e/dY/XH7vnZ2Dw08lufz186X4D2P30w+l6Pb2E/49LfIWX Hs+n/3XHOIdIFWYXxqTgNEga9Mc5/PJ/YwTwI0z+ts4e/1wi+Tluh9/Ok4fucff5+fqP09e/doeP T2G6i5sFJDjk+e7h20/dZQ8LDGHdxGH3p2cYA/6cvBzCRoX12f2R8nB4uD7dTzfbEMW3sFawZfef LxDbf9J/uTCv+quQhfir8PfX9P9z+HHUr0Ks8Vfh7/yr3t242Xa+XuIRPnSX6895Bd6YCESbYljN N/BzHnFzs9ms1m5Dhgx5TRmI2f1pd929f3c+fZ1AzUAqLrBGUIHuLizG/XRd4k/ZjpCQ4bm7gUjV DEN+wljfh8HupxANwC+wob68n727/RLYM+IHiXAU8WNCrNAYft4wtzDtOveQeDT3N6cWsPdT+LNO zVPiHxIi7ULMErIyliVlEEKoLGvGkhDwZ0WseqKDRR3NG7BxoeqoG8abEGN4w2YcG2/A0qwuGG9C yKzCAo9mCVga3ZaxJMSY6GB3j+YNWMrr+H5OkDHE4SQcm9aAZcRtk8RS+yFBxhAHZRtLHLB0Pecs 0wkh19PB0T+aJoJZgLwcM4ZE2DBEB1zQjLEhRjDjnvMoM0gJ06I5LkkKlgPH6yNjSJhtNjRMAI0P M4AHw0wgJUyL+DipPm7Jtk3GkDBbKmiYFgFySV9IiuVq9omQs6hQBLOMrniYihC1VNAwsRLBRnnz 9HKKFMkwixiF8x6fYA5rzyCVIj78EIsDQkeAT7GWCsqN5WeQO6nLwGr2SZDHEjREFcFsNfmZmTEk zJYKEqbHEjTIHcCMW6xmHDHkmK+mh+GrDAxSBTCjWjZ9SWdJHJEtZ8sFjTMoRpHaQfIApuRexplA SpxYgwapkgYBrHZAre5ylAmiEGHBGSRSBId3I77oTZvMqmFoPrECDXIndcHl4XlD4osCiW1j0Ruv 6M2y6XVOaJ/eeIveRDDbJLzZyRhciOsWOE2oRW+81Bvvm5DlMPv0Zm7RmwimYbptE5NElUFyi84t 8hLBjGrJqyGDFCrYhaMrPF77UirfmrQcVBiQqsu6LTBZvLlFXSKYcrsN36MZpIRpUZd5kg5ceG4j MtqnL3OLvkQwjcpzvc4YUg4t6zSjFn2ZS31xS14OGaRk1CIwc0Vgtu3MyTunT2DmFoGJYJpRtxFR pa5HicqiJ3OpJ3ArhvWIGSSpFhY9iWAeFU9gBilUFj1ZBDCl8nOewAxSqCx6skhaAX/WY1wQFTnh B9zCIh4RzGLi2pExpMxaKZIyW1jUJIIZNxeTjFHSaRGThWxWFk0oUpFljMJkkQ649cz3iNu0nidT JZBCZZGOhSYdrRvIVH3SsbBIRwSzlZrzes4gJSosHTCfN6/wFkk68M73C0GVQJJqiaVjiCqCWVS8 yjKG7P1WH2TvL7GWDHJLLXHb1g2kxYsjapc+y1D75epjkCoJBRBWLfE8oXFA1pv0hYnlZZA7gGmK 3VKQJ5CymlhNBqlkb+L5ObAsrUlLxbovTKwvg9xSX9xSkCeQEiYWmEEqKTB+Iaj6BGYJw4/fOAFM F88vuJbFEfMejbv2l/wK3LfkJ9MSa85goKkTwUIghDQOqBaIRXKWSU1IgYhSLIqDdk47q4gOrCwa FMEsx6I6M0junJVFciKYUrktPwUzSKGySM5KkZw536QZpFBZFGaVxINsE8HUJzAri8BEMM2f59WQ McBXtXbd5I5uE4vArKTAzAV3n76sLPoSwTTKOW8qMkZZOYu8rKS8uG3rK9MRmEEKlUVLVklLcIWj 91IzU8KQpWsbiS6dRV1WUl3cvB06mbzIC5fMtUVMIpitHS/wjCFhtp1Ewlxb1CWCKbdbtoFTmBkk V3NtUZcIplTibmrG4DA3bRvTMAE0+kxcBzDl3rZxc5QJo0RpkZu17GcW/FTKGIXJIi7RI0Fjclu+ QzNIobKoy1p2L27bztGcv77uZW2RlwjmUfH2PoOUqCzyspby4oU8Z1CkinH+gl+hO9KiL+skHfgA 9AuxJfv0ZWPRlwimKfViT2aQTOkGywlM983LwAjmVFzLMkihwnIySBXA9M1+ca9qkzAKExaPQSYp HkK4NkU8UAfRdi3ZJsHuVIVrkFvKibhDHQdkV4F93FhgBrll9+LmvOo3fe3LBgvMIJUmMPwYiiNq lw0bLDCDVLJ/ATMmu8kZR1SpsMAMUikCM+OHwSaBlD2K5WSQKikFbpX8UkTVJydbLCdDVBHMCq9t t3QWZIwMamtRkwhmasI3RcZA+Q227luIbHThRTDlFvKcMUqUFnnZSnnxc66ZGaRQWdRkK9VENNQZ QxLa01BvLWoSwTShsqHOICVMi5pspZrIhCYMCbPtLSLYWywv8PObJ2AEszBXvBAzSAkTy8sglZQX cS5ti7q08uhrqLdYbwa5pd7I5jOOqKmom2HBGeJKaJpT0b8UkMypm2HNGSYLaErmZ7wc05h6aFhl htkCmrEt+RHhZgkVY0tNaHlJuV3nZlh9hmeQ5AcYqoD6Bb+eT2Pq8WIBGmaTCuQX/KLFzRJKW0ss OcNssoPxS7mWfS2Mm2HVGWZLkoIzKd4bSEPqiQSCejwNkwV0GKctm7gr6GYKqC0tETk3s0hPQjN6 uYxSfNCdIkZvUR/41IGMnnemKqg1KpQ+2nXHvjXjFHOvMMM0EL855Ijhd3Clq5kXrXQ7kFO/lYZU t1V06I6PTOrRth2LhazIUZsRcq6wxGIxgt978/B0LokRbmNB2FlzXlB47yM7C+PH8jTMn4QHcFUM xU0/V83AcmGxOg2TFd1BZGITZ4cwibWdDyxWLFfD9EmucK79rKlDWeuEUqQ4mnrLxhpmk1Ik3lpw 2SeMg+0zyjmbK1ix/DphAklj6lWE5Wk4WClPTrzx7lxBiX1ksgI7zQssc1vdwJIN90eDsWVjL9k2 wpLreu2/zuT/TWh6zshlUwzAm3bK0xrxQWFG79qIpu2ZEyWSQUqJeJP4RDQlk5smgzQyk/hkky9Z xpk4wasVWG4ak9ZUW2+TOj8TWldRki2ox/hVk1rjhf3XZZOwlkncCg0XROpyAFfPDNljVguwDM2k LNnyixXSy1UrwtJmtO6rB5ML2FWHbxtZXisooE0rGlqOJmewq65fRC+i10CthWH0sGrj91W2C+Pk L8QmVkDogo7Rm8SomoFR9O1d6nxeK6B+epM8ZRcxib6104U+NVAY1E9vEizFNSwMZnB7WlwX9NOb FKz6hlHyRReugNBNWLb2JknLhmOcVy8704oSKmOyHLvsOSaS1iq4LHW5upNkJkmrhuKWWSnWCgjd VaOZNRmRXTUZI3pR1Aqon97UTlXjMaIXVaWA+ulNkpYdy3hfCaOfU0D99DDUeEVVPMrCgOcUUD+9 SdKqTRklvx0VeZ8roH56k6RV73Kj9+INNldRos6iaxl1RXA/CCovPXQBPf3g7UvubH3GtQ53N/kl d0XJSZh0THE/e+H3dBUl2UytmWKAduIdfldRks0kZIoHGm5ViEym5iw+loPqFnFBw3q8vW6KDRq0 jLNpKPQhbjYBk3JlmzO+gnDytryGQh+vZhMwaVd2P9MJtD43l6+Gck1h2QRM6rUMaPpOKNzCEEuQ UNqCm8Qqu6BpuGJ7aSjXGhUWrkmulqm5whPws5bJku+CEtW0NDVcEU2vhv1MJjfdnsJzgrs4dQlY uCapKoZodF3nZ23oEm661tRW1yRV2RONZdjLi4uM0thMUqV4p518G0ZDuXY+0uQS//SgemkG6oXY SxUl9hKxUA+zwf5g77LBsVp3SV5KzWndu5eiDRqdvW+LteasnrVMlgkE+QtbXoZr0qVsriZFoSS3 6FLrPvpLh1iuh/OdrgLxBLx49oyrzmwZrkmXFJe1Q08lKsnt1SVitB6OTSqOFx9PdtWPLWMziVA2 UsOs6s0lLz7T6qonW7KZREgxXHt5OVBRks0kQtlijWNz8mZWNWILNmKyHlw3xWUNfSbXAA2FDHdU 8ojTengCigitRLtSDdkyXGAYf2WluK29E219RUk2k+Io/mpoq0VyFcVBnw5nyTU1R4rt2q1Ec1RR MlyT4ijWay8+VOIqSrKZOqHsvqZ1Ig6P6tGWbCbF0QzYK3GTVUOh6zi2lCYRUm3Z4sJGQbn+CZh0 KVuz8enlVqJbqCiRb2LOHpQFxZ0NpwcvnYqSbEFWRjciikEbTg/BpkhVb3KjyXr8BIKK0bberYRS ZOM2WYL+CZikKju1ydDo8Ta5W9BQ/RMwSVW2a+MJeCfOAQXVv7+jCXv8EpROCPUUXhwN2ditNKMm Zzc8q0IsuJd3RRTUG+GaBC17uWm+haBVlCwwk3plOzdhQw1E2V5hTFYF/dvLpF7xUbBsaGSiKBMI Y6qXGiYvuMtGbxquOHcVVP/qmizi8Ol7kUnvhVhXlFhdkykcPngr2Jz4bLWK6l3d6OweXbuaWRzd TsurW1EyXJNUKX5xj+6dFbZytSfZTF2V5hBHj1oqbFK9HHJ3084jOsHHJ1dKlUNvnJcJKKj+CZik KvvCaacnTudqMZf5NklV9obj2nXo7coSriZVrcBYvk1Slf3hZAJrKR59UgUf24FqHLu6CU2F0Yu7 tQ3Fk+uJjXyorUtoyubQW9EpuSoKPcGNJBdc6KZwFalCT80oEygoGa6lqwLjoBBGj+6dFbaCkmwW XfLZHw5zr3dFwJrCutiCkh0MWI9MmVQUZ90qoMSmoNCHa9hSWi4A4Sa7SK5b80sEFdU/AYsuwX13 OQFk6SkZUFD9E7BIFdx3lxNAT2goE1BQ/ROwSJXPhnMqVfyyRUX1ToBYzmErv3kHGW6fKhngNwFU VP8EQus0Wj6VB097cbcObjHJafZPIIjP+AkUqUJFjz7LlPdAfWi1kJjoLR/PVqQKsQlbH1zIWMI1 aZzyWGqP3nwp4fb1Xj4ax8eHK9XLy4ez1sdVy+SaBE17FvWGX4FCp2lJrknQtAdSI8twSa5F0Ex+ dDgbc2yQycKGXqKnRTSKj1/K1C+Rw1HcX4Ct1CZA2Uzmc9gkcRzYhu0oFh+XKygin+gNITYBky5l pzmdAG8iveJah88w1Y6BTcCkS9l9TifA7y/4jCIZQAXGJhBkZfSCZ/85nYDoTzQrO7rrwyYAgxkm END3UzoB0Z8o9nb4iFbfEpg6tGxTpxPg101wWyBOkywBekuEZcAkaNm5HlvNXM74JTa0Sarqs6yb UuCX2NBBQ8ZvHKQ4ZdboJTa0qV+qj6ZGs+5VHJMH3Wd7Oc41fonO2uQvh2/qyTukzRq/xIY2qUR9 1DQaujQ08BIb2lT/9UnSaOjSl8ihTZVdnxyNhk7FrlxVRfP16M2XrdpkGUuBylmbqrE+CBrNuvQS cmhTNdYHP6OhS5cghzZVY33QMxq6txqjH3p8rlHp5ULPhmplGU32aXhmkSgZ/BLd19HHPHrW2fWM dwh+iQ1tqsbsaCZD91Zj9B+PnzUqvZzrbGDWcm2qxvrk5bZD8EssIaYTtD5qGQ3dW43cd/z2lWu2 DpNci2pMX5yXvtrt6dtrd34+HD/Bd97Vn/P3BMZO8nx3eLifnn99iGNKCKh4hfhgppIQWOwKiZ8A kxBYxwpZ6KPA6lXIUodAEiskfr/hbWWC8F53H7u/784fD8fL5Bm+izB84x/IyTl9KWD8Gb7FML4K A6XvLCz/eoKvk+zga+vCdwROHk+na/kHBBzG/b27fn6dnM4H+CbB+A2R99PX0/l63h2uaE7raDar 32f5/v8CAAAA//8DAFBLAwQUAAYACAAAACEAUWIGilUBAABqAgAAEQAIAWRvY1Byb3BzL2NvcmUu eG1sIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAhJJfT4MwFMXfTfwOpO9QCts0 DbD4J3swzpiI0fjWtHdbMyikrTK+vQU2ZNHEx/ac++s5N02Wh7LwvkAbWakUkSBEHiheCam2KXrN V/418oxlSrCiUpCiFgxaZpcXCa8przQ866oGbSUYz5GUobxO0c7ammJs+A5KZgLnUE7cVLpk1h31 FteM79kWcBSGC1yCZYJZhjugX49EdEQKPiLrT130AMExFFCCsgaTgOAfrwVdmj8HemXiLKVta9fp GHfKFnwQR/fByNHYNE3QxH0Ml5/g9/XjS1/Vl6rbFQeUJYJTroHZSmc3yu4q1XpPrmUhVYInWrfH ghm7divfSBC3bbaWe/Ae3LZNgn+rDtz3GOggPJeMDj1Oylt8d5+vUBaFJPZD4pN5HsWUXNFo8dE9 fjbfJR0uymOEf4mxT2Z5FNLZgs6vJsQTIOtzn/+O7BsAAP//AwBQSwMEFAAGAAgAAAAhAOwWOA7X CwAAtBsAACcAAAB4bC9wcmludGVyU2V0dGluZ3MvcHJpbnRlclNldHRpbmdzMS5iaW7sV2k01G0b v8ekh6esiRhlKUmMPYMYCpWsjWVkxm5sgzGMMBkqbZStZIok0XiTLVlGhaJ4kyVb1hCPZZTljShN 5v1Py5c+Pec8H95z3uO6z7Xe93Wd//07c825bjzAA1uAAdYACUyADWTZAg0oFgoIwBtEQIwEWkAd aAIUZHmD3wm2AWwcAn1SdhzAAwMwMPMnic8b0kLACfJ5IAmHPEuoGgVaBKjuPyfYzxIbIM0D8S// 98q2GHPHMfXfo//c3/a9hLAidwHA5R/0FKTBf9m/618bphLCAG8BB34m3K//QVzcfieNcS04LxTk QHtc/pX/+7l1//8bgd9/GU+h69pZ2R/l3loYlAKn7z1FApFAFmABCeovItTHBBAMdRu3h2XBPqAD 8T7IsgV2UJYlwcPbP9jXzNuXAICthy/Bzp9KgKIUCiH0u48h+PqTggEwDQ8JJET+VNYk+/Agz0AC wBDCSIHhFO4JHXX1SIi9Q/y5X/P3yFQCAA1rjBP3Xpsh++9SrfsnUz6oD+b4haEUGPhD9oCY9GZu tpWdySGu7uDnSgBUfigAh/3oKz11AP2rcXNgYEr75+ZPpabmEOxFCgoJJYSFEbyRph4UDzU1oNeu rBPBP6VtYvECJxAojRW5hRuMz6pj9OW0DpBVqy3GRxsfzLfFFslWZO32J4p64dxN5TSTcIdPBDY9 QGQu2NkiOs4cvF/gMCPup2CLY+ooBC0OmvIkSJ0x3nPxOVK+YMNeUdO8s3zC8k9RWo9ra4yaELNv W2dYrTW0+dkVn8nWzOMlmRlVFO1raUhZW7tFlyKr1tkiMzT7ug2l/NTgAC5RNgaRFlsp7aDw2WBs R6NzkKDKAYe7bOdJk2YZXNLewmjFqgglzo7FbLibqctG85c7vaqGPzD5e1BpdZFaBYpirzwxKmFH 5mterdzCrL3E2P+xgT6U1T15dYh9eYEXXbB7/HhQu5rJp6AJBD1nNeljTHCsNaO/DdlODFOI0Nu5 JzpTRayRWrOyWW1CIqG0M16YZjFbe1KANVgr2hM3OqXU/HAA6Rlx0ix/yOeO/r/YuxaNHNf2lkwG ZQWM7LWfqqBp5d7iESJIzvsN8p9nF8dxsj5mT9TGYtbyWzg4R1w7EltRnfZYbZl/pHHVlcFWMCoI zUYzXAfnfHhRnyMTxra6I2hde/0+vRxjfHhRwbpoYvCqplnmrw7ctdjUQaMctuakUS7bYijfbYr6 +hYR1C1+kWvQ0Zq5pHQCb8yWPKhzYtXz0QhhZfviizRDP1RSXwucWhWtVCD3mJxsqWfPd+LSMEfY i11O4+hZqLTjPnncozWK3EcH9ExRFiIuHfvmKtETrNZcdt7n68rKUpU/J+mMUt7J+WfWUcf7atOj NV3ztuHzW/Gv+1G7W1wjvj2kI570KXSb1WgfNNG2jlkVmxGZyRcvF+jc89m1/A1m+1Gk5CvCEfSj iobnr0dRDJfDj0sJmzKOXhb0GgjQLxIZF7tjJbbbK3Pgq+iwvkmzjbqRyvZej869BTkb7zWMFtye QT4VPugSVx9h0jlgXJVLg5dWdgSdcTngsKv1GHK8wF9AMnlmp80zjqTRsRgJUk22pDx6UFGSxKqp iZ5XO2TpR08zapo9FxUgPRHVKV7N2xM6gVKfx8YYLhIXPb++5yUOEaMeRLlh12YC7El7OG6TQsrz 90+RWu1K0qra6vn2LBhwTktUR7u/67aSiVYJkTMIX+1jnNR/DT96Qxg+RWtI7gOoBQzqmLK9fsKl a3MXSqVkM5xDCtek8MpyDEsMjHYg5BtZLtUI1vut2wquZGummZTgJ0g713hbvLGy/vR9eNmMeNRs uc65EU0NRLZnq1h99ZLDn60KMxd2YPVD3sb7rmCEEmEdglRjnQBeHeOtlYctQ3skGyov7hA9XpNs nFt/Wtk1zMNg/2PKztmtmXWnap4Mnb6/xZltUEjk6xxQLfMkVpHf+A7VB9+lLWGJRuelmVLjy67L LLlV+dlnORG8lbEX4FjErgpEZQ+8OtFJ9JIuBUf3iDe0dMsVcl+RuHQRLeXrpjHYdu7Jcgd9Wial l2B6rmp/SH/ovXb+vXdkOukvYjWKt5OZBaEJRRdrrUX6vu1KKpYNqXBiZrhbBdrJdeSNbfJAdecO xyt3rdWm7BCxpC1sOa2L99hE9/TAi/AblcUR0YZH83MOp/cX6OIr0nsTLOdhuBP9TytOLXcZfC4+ b2ZapRvy1iri3eUlu8VyNDF/Qvw8/aL3tpGDq+LXntmoV/YokftDiUAHF1whWfUwcclK852iKZ1M LXy4YN9kpitwvNNLwnD3O8VXhap3nwRGy10ocegniI7EUDMFcTFjlbuMHjjI3xS5eWS/sNGy89Qx PqxuQ23u9eEcpbPDdTyVB16VrAFm5Wh0Yf3iZ3btFrLc+Pi0Z1/C83rm4PRFYYQhWs1iuoqi9YGo 2Na0Tynknu+RcyryrFR54pIBGm82Zer62N3tvTQTLbghTtRiyXZExdtxXqMMo29TlNILm/7PznSa RrHAvw0wuffi99/QDOdJ6xALH2up3Yy/JohHjm3HjBeERZalHGk5iUfj4794acvF5t38K5nXHDJV Y/OkJ5LDrnxs8mtmp5bdNGqzapbJVVo83By6xtyjFOuNR3iw4MbaZ9HVL2VIls0ykhKDy0zvhLSr 7AfbsGN6eVTLJWFY5IbmMT37KxTBuw0vlk2P77/gqJBlco/8Itsy7V3YtCM+fh525+MOd7xKQujS jtt8WM9b4hVjas3+txyvp+WbFRkkhmbkt9o0d91xvHVIr7VLfNeE/+VXbe3abb5i/W1d4rsn/BPu 68CwJxbLMfh4skeA0bNUeYKGqopFwia78YAblczA5+cQZIXJimPKJXdvTla4mEcVDWBdztAI+0ve Zqf1ahbbSwZ9yHKaXBwwZPZF1CR/YzJ4QnmK6Qrz266u1JpEuqr6SfdilG/9izIacOU9+gucYJ0i J3e05YKrVQpdRpwx0LJDkh1ebxBFG4li033fuPV/CluzfrdRbO3pbXOe6I29yNMxyXlH4Npy7v2J IaLq+obbOV++YpRImfxMerBKEIp64uD0W78bsPPJ00eVrFaWLPpCgpobmHVNiZvaA/DoRpckhESG y+pFcuwlBFbrPrlkQ/k088ARgtPBQ9Ysqk9KS86pdB9+zap256IS3vLy5uwiJ5vHvvvmEk+lRz78 IBa03FY60ABDshrvXp1LPZVOGe/0X/QztnhEZhVOOXF1hX/jdiE/c1SxaitzC/dgT77kio+xBUK7 N5GG0rWoyd7sZ24wWWJGgsrHWxVvfZJ7Jm1W0RApGNCfMEx7cxi2PONjeTjOWSfXDZViParLeqE/ 36SSq3UZJ9rdmRSeaE5aNvGKnKNdz1ectaNvrOh7P0698MSalUXG3jiAzJyo4CEWCtgg0uxJjFTi Geeb7ZKpsqXYlCSPyg6xsoLNAf4SdfqnNUMEzh51OIBs6yXS5AdvNEnByJxBEZelumGZISqb/UIo dyLVc6V4hEhtoZDWXLvGGSfps/sMPR6NpLt2XWV8zX1OpDZT5t88YcAhp49IHaDMB9cwzLtqiIsZ rupvZWRcu5ItVw7H9VK6KTLFUVZNlis52b2UIYrMIaqVouWK3L3eJQYL/eRThnXGnAmhhJXGQn9Y zogJeiTkUMMwYXwt7SWu1rLQ2p8ykq7PNQS0j1R+VhjywS5csAnef3Ky+9lLC/QVtdEbwU7bx98X YTBtapxhXOBkssQ2DltGqA5OczRYKxnZnL7c8iq/T/hrtu/MX1c/ke8ve2U1vH6UiXUwLZkk3ktF dfd87L37OrylKWxrW0/9vMVstVSxl+qa57dyh0D73rh4FoeHAxEA2lMmNlb7eIAoNMVGAi9IBgLV 7zYBQI9OEAQ8QQDYDNlcEgBi0HxH4pv58+doBynujCkGpKH3rDaUqQ6xDmRrQlIVmofVoaUFxIEU FOO+cFW/7+l9P8WVKGhJQNVD0DHcsXmd1hFYR2AdgXUE1hFYR2AdgXUE1hFYR2Adgf8BAv8FAAD/ /wMAUEsDBBQABgAIAAAAIQA8AjD+gQEAAP4CAAAQAAgBZG9jUHJvcHMvYXBwLnhtbCCiBAEooAAB AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJySQW/bMAyF7wP6HwzdEzltMAyBrKJoWvTQYgGS dmdVpmMhimSIrJHs14+2kcXZeuqN5Ht4+kRJ3R72PmshoYuhELNpLjIINpYubAvxunmc/BAZkgml 8TFAIY6A4lZffVOrFBtI5AAzjghYiJqoWUiJtoa9wSnLgZUqpr0hbtNWxqpyFpbRfuwhkLzO8+8S DgShhHLS/A0UQ+Kipa+GltF2fPi2OTYMrNVd03hnDfEt9YuzKWKsKHs4WPBKjkXFdGuwH8nRUedK jlu1tsbDPQfryngEJc8D9QSmW9rKuIRatbRowVJMGbrfvLZrkb0bhA6nEK1JzgRirM42NH3tG6Sk f8W0wxqAUEk2DMO+HHvHtZvrWW/g4tLYBQwgLFwibhx5wJ/VyiT6hHg2Ju4ZBt4BZ93xDWeO+for 80n/ZD+7sMPXZhOXhuC0u8uhWtcmQcnrPunngXritSXfhdzXJmyhPHn+F7qXfhu+s57Np/lNzo84 mil5/rj6DwAAAP//AwBQSwECLQAUAAYACAAAACEAQTeCz3IBAAAEBQAAEwAAAAAAAAAAAAAAAAAA AAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQC1VTAj9QAAAEwCAAALAAAAAAAA AAAAAAAAAKsDAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQCBPpSX9AAAALoCAAAaAAAAAAAA AAAAAAAAANEGAAB4bC9fcmVscy93b3JrYm9vay54bWwucmVsc1BLAQItABQABgAIAAAAIQAdJXZB pQEAALMCAAAPAAAAAAAAAAAAAAAAAAUJAAB4bC93b3JrYm9vay54bWxQSwECLQAUAAYACAAAACEA PoOuYvgNAABtUgAAFAAAAAAAAAAAAAAAAADXCgAAeGwvc2hhcmVkU3RyaW5ncy54bWxQSwECLQAU AAYACAAAACEAcLFAvWoBAADBBQAAIwAAAAAAAAAAAAAAAAABGQAAeGwvd29ya3NoZWV0cy9fcmVs cy9zaGVldDEueG1sLnJlbHNQSwECLQAUAAYACAAAACEA//H7gKcGAABbGgAAEwAAAAAAAAAAAAAA AACsGgAAeGwvdGhlbWUvdGhlbWUxLnhtbFBLAQItABQABgAIAAAAIQD1FLwTiAMAAIYOAAANAAAA AAAAAAAAAAAAAIQhAAB4bC9zdHlsZXMueG1sUEsBAi0AFAAGAAgAAAAhAJJ8t+BKEgAAFHMAABgA AAAAAAAAAAAAAAAANyUAAHhsL3dvcmtzaGVldHMvc2hlZXQxLnhtbFBLAQItABQABgAIAAAAIQBR YgaKVQEAAGoCAAARAAAAAAAAAAAAAAAAALc3AABkb2NQcm9wcy9jb3JlLnhtbFBLAQItABQABgAI AAAAIQDsFjgO1wsAALQbAAAnAAAAAAAAAAAAAAAAAEM6AAB4bC9wcmludGVyU2V0dGluZ3MvcHJp bnRlclNldHRpbmdzMS5iaW5QSwECLQAUAAYACAAAACEAPAIw/oEBAAD+AgAAEAAAAAAAAAAAAAAA AABfRgAAZG9jUHJvcHMvYXBwLnhtbFBLBQYAAAAADAAMACYDAAAWSQAAAAA= --_007_4E1F6AAD24975D4BA5B168042967394367511EAFTK5EX14MBXC283r_-- From sakimura@gmail.com Thu Mar 14 15:34: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 5D86111E8133 for ; Thu, 14 Mar 2013 15:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, 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 ibUI4v47WLr4 for ; Thu, 14 Mar 2013 15:34:02 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 8832B11E812B for ; Thu, 14 Mar 2013 15:34:02 -0700 (PDT) Received: by mail-la0-f54.google.com with SMTP id gw10so3126368lab.27 for ; Thu, 14 Mar 2013 15:34:01 -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=rIVGBq0vexYXCw75nLXfXUUKZ8c/N2V/2zBSPvuvaoY=; b=OsbpxjVBBAP7gvejAmnQZ6L1fJa7Q1S/vKFhW967pm1JXYYNSdMnt4AaEOasDTOGXP l89fgbhAS/YZOJBDE84Dwo30KSE8WFuvPFhfhatSetQKGHO7H2fdw5Tvqu4FNLIq8ht+ tnAAxGMOh+4nOkIfdAsLhBi4aALUWX8ZJ5NKavTHWt8+EJ2+2Qb2urYHysrGbEx3rkdz zI0CzdrigAtrurlGMrXWMAfZBBRijvyJ0J3ox9ECAa2EwfgwH5P48pnRLiPpNQimP3s/ yVKKFzH138rJWT+YkgjFbdQcxsRfxX2gFCG/HzAjMKY8O7IWNipIIWjNKHt6+/uq/p+U cAKA== MIME-Version: 1.0 X-Received: by 10.152.133.52 with SMTP id oz20mr3741284lab.30.1363300441442; Thu, 14 Mar 2013 15:34:01 -0700 (PDT) Received: by 10.112.103.202 with HTTP; Thu, 14 Mar 2013 15:34:01 -0700 (PDT) Date: Fri, 15 Mar 2013 07:34:01 +0900 Message-ID: From: Nat Sakimura To: oauth Content-Type: text/plain; charset=ISO-8859-1 Subject: [OAUTH-WG] JWT - typ and cty X-BeenThere: oauth@ietf.org X-Mailman-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, 14 Mar 2013 22:34:03 -0000 In the interest of time, I did not follow up in the WG F2F, but the if cty=JWT for both JWE and JWS still bothers me. Yes, it can be unambiguously identify if the content is JWS or JWE, but to do that, you have to sniff the body of the decoded JWT. If we had typ=JWT+JWS etc. or cty=JWT+JWS, it would be able to tell without deep sniffing. -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en From Adam.Lewis@motorolasolutions.com Thu Mar 14 17: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 6D39611E8151 for ; Thu, 14 Mar 2013 17:47:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.466 X-Spam-Level: X-Spam-Status: No, score=-0.466 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 5Uv00KqUW7rd for ; Thu, 14 Mar 2013 17:47:26 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe005.messaging.microsoft.com [216.32.180.188]) by ietfa.amsl.com (Postfix) with ESMTP id AC4DE11E810E for ; Thu, 14 Mar 2013 17:47:26 -0700 (PDT) Received: from mail137-co1-R.bigfish.com (10.243.78.228) by CO1EHSOBE017.bigfish.com (10.243.66.80) with Microsoft SMTP Server id 14.1.225.23; Fri, 15 Mar 2013 00:47:26 +0000 Received: from mail137-co1 (localhost [127.0.0.1]) by mail137-co1-R.bigfish.com (Postfix) with ESMTP id 1507A38013F for ; Fri, 15 Mar 2013 00:47:26 +0000 (UTC) X-Forefront-Antispam-Report: CIP:129.188.136.17; KIP:(null); UIP:(null); IPV:NLI; H:il06msg01.mot-solutions.com; RD:none; EFVD:NLI X-SpamScore: -28 X-BigFish: VPS-28(zz98dI9371Ic85fh179dNzz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL17326ah8275dh18c673h8275bhz2fh2a8h683h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1155h) Received-SPF: pass (mail137-co1: domain of motorolasolutions.com designates 129.188.136.17 as permitted sender) client-ip=129.188.136.17; envelope-from=Adam.Lewis@motorolasolutions.com; helo=il06msg01.mot-solutions.com ; olutions.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.237.133; KIP:(null); UIP:(null); (null); H:BY2PRD0411HT001.namprd04.prod.outlook.com; R:internal; EFV:INT Received: from mail137-co1 (localhost.localdomain [127.0.0.1]) by mail137-co1 (MessageSwitch) id 1363308443848916_4980; Fri, 15 Mar 2013 00:47:23 +0000 (UTC) Received: from CO1EHSMHS002.bigfish.com (unknown [10.243.78.248]) by mail137-co1.bigfish.com (Postfix) with ESMTP id C393244021D for ; Fri, 15 Mar 2013 00:47:23 +0000 (UTC) Received: from il06msg01.mot-solutions.com (129.188.136.17) by CO1EHSMHS002.bigfish.com (10.243.66.12) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 15 Mar 2013 00:47:20 +0000 Received: from il06msg01.mot-solutions.com (il06vts01.mot.com [129.188.137.141]) by il06msg01.mot-solutions.com (8.14.3/8.14.3) with ESMTP id r2F0lJE0026612 for ; Thu, 14 Mar 2013 19:47:19 -0500 (CDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by il06msg01.mot-solutions.com (8.14.3/8.14.3) with ESMTP id r2F0lJsF026608 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 14 Mar 2013 19:47:19 -0500 (CDT) Received: from mail47-ch1-R.bigfish.com (10.43.68.237) by CH1EHSOBE004.bigfish.com (10.43.70.54) with Microsoft SMTP Server id 14.1.225.23; Fri, 15 Mar 2013 00:47:19 +0000 Received: from mail47-ch1 (localhost [127.0.0.1]) by mail47-ch1-R.bigfish.com (Postfix) with ESMTP id 560481601F6 for ; Fri, 15 Mar 2013 00:47:19 +0000 (UTC) Received: from mail47-ch1 (localhost.localdomain [127.0.0.1]) by mail47-ch1 (MessageSwitch) id 1363308437174922_3243; Fri, 15 Mar 2013 00:47:17 +0000 (UTC) Received: from CH1EHSMHS030.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.232]) by mail47-ch1.bigfish.com (Postfix) with ESMTP id 283C1140061; Fri, 15 Mar 2013 00:47:17 +0000 (UTC) Received: from BY2PRD0411HT001.namprd04.prod.outlook.com (157.56.237.133) by CH1EHSMHS030.bigfish.com (10.43.70.30) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 15 Mar 2013 00:47:16 +0000 Received: from BY2PRD0411MB441.namprd04.prod.outlook.com ([169.254.5.31]) by BY2PRD0411HT001.namprd04.prod.outlook.com ([10.255.128.36]) with mapi id 14.16.0275.006; Fri, 15 Mar 2013 00:47:07 +0000 From: Lewis Adam-CAL022 To: Brian Campbell Thread-Topic: [OAUTH-WG] JWT grant_type and client_id Thread-Index: AQHOIP0buuyrhjJKAkSeWf9bfOunXJil6wOw Date: Fri, 15 Mar 2013 00:47:06 +0000 Message-ID: <59E470B10C4630419ED717AC79FCF9A9568A84A6@BY2PRD0411MB441.namprd04.prod.outlook.com> References: <59E470B10C4630419ED717AC79FCF9A948D552B8@BY2PRD0411MB441.namprd04.prod.outlook.com> <4E1F6AAD24975D4BA5B168042967394367472284@TK5EX14MBXC284.redmond.corp.microsoft.com> <59E470B10C4630419ED717AC79FCF9A9568A83EA@BY2PRD0411MB441.namprd04.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [150.130.34.167] Content-Type: multipart/alternative; boundary="_000_59E470B10C4630419ED717AC79FCF9A9568A84A6BY2PRD0411MB441_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%1294$Dn%PINGIDENTITY.COM$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn% X-FOPE-CONNECTOR: Id%1294$Dn%MICROSOFT.COM$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn% X-FOPE-CONNECTOR: Id%1294$Dn%IETF.ORG$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn% X-CFilter-Loop: Reflected X-OriginatorOrg: motorolasolutions.com Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] JWT grant_type and client_id X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 00:47:28 -0000 --_000_59E470B10C4630419ED717AC79FCF9A9568A84A6BY2PRD0411MB441_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hmmm, one more thought ... no scope?? The JWT is the grant, is it assumed = that the scope is conveyed as a claim within the token? Otherwise it would= seem that it would require a scope. Thoughts? adam From: Brian Campbell [mailto:bcampbell@pingidentity.com] Sent: Thursday, March 14, 2013 4:44 PM To: Lewis Adam-CAL022 Cc: Mike Jones; "WG "@il06exr02.mot.com Subject: Re: [OAUTH-WG] JWT grant_type and client_id Yes, that is correct. I'm working on new revisions of the drafts that will hopefully make that po= int more clear. On Thu, Mar 14, 2013 at 5:26 PM, Lewis Adam-CAL022 > wrote: Coming back to this ... am I correct in that client_id is not required? We= are implementing this spec and want to make sure that we are doing it righ= t. By my understanding the only two parameters that are required in the JW= T grant type are "urn:ietf:params:oauth:grant-type:jwt-bearer" and the as= sertion. Is this correct? From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Monday, February 18, 2013 6:58 PM To: Lewis Adam-CAL022; oauth@ietf.org WG Subject: RE: JWT grant_type and client_id The client_id value and the access token value are independent. -- Mike From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Lewis Adam-CAL= 022 Sent: Monday, February 18, 2013 2:50 PM To: oauth@ietf.org WG Subject: [OAUTH-WG] JWT grant_type and client_id Is there any guidance on the usage of client_id when using the JWT assertio= n profile as a grant type? draft-ietf-oauth-jwt-bearer-04 makes no mention= so I assume that it is not required ... but it would be necessary if using= in conjunction with a HOK profile where the JWT assertion is issued to - a= nd may only be used by - the intended client. Obviously this is straight f= orward enough, really I'm just looking to be sure that I'm not missing anyt= hing. tx adam _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_59E470B10C4630419ED717AC79FCF9A9568A84A6BY2PRD0411MB441_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hmmm, one more thought &#= 8230; no scope??  The JWT is the grant, is it assumed that the scope i= s conveyed as a claim within the token?  Otherwise it would seem that it would require a scope.

 <= /p>

Thoughts?

adam

 <= /p>

From: Brian Ca= mpbell [mailto:bcampbell@pingidentity.com]
Sent: Thursday, March 14, 2013 4:44 PM
To: Lewis Adam-CAL022
Cc: Mike Jones; "WG <oauth@ietf.org>"@il06exr02.mot.= com
Subject: Re: [OAUTH-WG] JWT grant_type and client_id

 

Yes, that is correct.=

I'm working on new revisions of the drafts that will= hopefully make that point more clear.

 

On Thu, Mar 14, 2013 at 5:26 PM, Lewis Adam-CAL022 &= lt;Ad= am.Lewis@motorolasolutions.com> wrote:

Coming back to this … am I correct in=
 that client_id is not required?  We are implementing this spec and wa=
nt to make sure that we are doing it right.  By my understanding the o=
nly two parameters that are required in the JWT grant type are  "=
urn:ietf:params:oauth:grant-type:jwt-bearer"  and the assertion.&=
nbsp;  Is this correct?

 

 

From: Mike Jones [mailto:Michael.Jones= @microsoft.com]
Sent: Monday, February 18, 2013 6:58 PM
To: Lewis Adam-CAL022; oauth@ietf.org WG
Subject: RE: JWT grant_type and client_id

 

The client_id value and the access t= oken value are independent.

 

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

 

From: oauth-bounces@i= etf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Lewis Adam-CAL022
Sent: Monday, February 18, 2013 2:50 PM
To: oauth@ietf.o= rg WG
Subject: [OAUTH-WG] JWT grant_type and client_id

 

 

Is there any guidance on the usage of client_id when = using the JWT assertion profile as a grant type?  draft-ietf-oauth-jwt= -bearer-04 makes no mention so I assume that it is not required … but it would = be necessary if using in conjunction with a HOK profile where the JWT asser= tion is issued to – and may only be used by – the intended clie= nt.  Obviously this is straight forward enough, really I’m just looking to be sure that I’m not missing anything.

 

tx

adam


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

 

--_000_59E470B10C4630419ED717AC79FCF9A9568A84A6BY2PRD0411MB441_-- From mpeck@mitre.org Thu Mar 14 20:05: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 B1F0411E8151 for ; Thu, 14 Mar 2013 20:05: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=[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 EZdWJMTqWpFV for ; Thu, 14 Mar 2013 20:05:19 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id C0C7711E8148 for ; Thu, 14 Mar 2013 20:05:18 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 4D2C51F0491 for ; Thu, 14 Mar 2013 23:05:18 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 237651F0430 for ; Thu, 14 Mar 2013 23:05:18 -0400 (EDT) Received: from IMCMBX04.MITRE.ORG ([169.254.4.94]) by IMCCAS01.MITRE.ORG ([129.83.29.68]) with mapi id 14.02.0342.003; Thu, 14 Mar 2013 23:05:17 -0400 From: "Peck, Michael A" To: "oauth@ietf.org" Thread-Topic: draft-ietf-oauth-json-web-token-06 comment Thread-Index: Ac4hKer06uwxlpu0QjCubugIrIswZQ== Date: Fri, 15 Mar 2013 03:05:16 +0000 Message-ID: <8B4C063947CD794BB6FF90C78BAE9B321EFD49A2@IMCMBX04.MITRE.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.51] Content-Type: multipart/alternative; boundary="_000_8B4C063947CD794BB6FF90C78BAE9B321EFD49A2IMCMBX04MITREOR_" MIME-Version: 1.0 Subject: [OAUTH-WG] draft-ietf-oauth-json-web-token-06 comment X-BeenThere: oauth@ietf.org X-Mailman-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, 15 Mar 2013 03:05:20 -0000 --_000_8B4C063947CD794BB6FF90C78BAE9B321EFD49A2IMCMBX04MITREOR_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable To explain my comment at the microphone today: Section 8 states: JWTs use JSON Web Signature (JWS) [JWS] and JSON Web Encryption (JWE) [JWE= ] to sign and/or encrypt the contents of the JWT. I believe it'd be useful to expand upon this to give guidance to those usin= g JWT on what they should do to cryptographically protect it. When should = they do nothing? When should they just sign? When should they just encrypt?= When should they sign and then encrypt? What security properties does each= option provide or not provide? The choices seem to be: 1. No JWS and no JWE - assumes the JWT is protected through some othe= r mechanism or that it doesn't need to be protected 2. JWS - probably OK if confidentiality is not necessary. 3. JWE: Authentication is not provided unless a shared symmetric key is used (if it= 's asymmetric encryption, only integrity protection will be provided, not a= uthentication). Under what conditions is authentication necessary or not necessary? AES-GCM may not be safe to use with a shared symmetric key (I sent feedback= on this to the jose mailing list). draft-ietf-oauth-v2-http-mac for example seems to currently solely use JWE = and says "this keying material is a symmetric or asymmetric long-term key e= stablished between the resoruce server and authorization server". If it's = asymmetric, a JWS seems to also be necessary to authenticate the authorizat= ion server as the source of the JWT? 4. JWS then JWE: A recipient who is an attacker/who is compromised could potentially strip o= ff the JWE (making it just a JWS) or strip the JWE and replace it with anot= her JWE to cause confusion about the intended recipient of the JWT and forw= ard it on to another recipient. The presence of the "aud" (Audience) claim= seems to protect against this. However, the "aud" claim is optional in JW= Ts. Thanks, Mike --_000_8B4C063947CD794BB6FF90C78BAE9B321EFD49A2IMCMBX04MITREOR_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

To explain my comment at the microphone today:<= /o:p>

 

Section 8 states:

 

JWTs use JSON Web Signature (JWS) [JWS] and JSON Web Encryption (JWE)
[JWE] =
to sign and/or encrypt the contents of the JWT.

 

I believe it’d be useful to expand upon this t= o give guidance to those using JWT on what they should do to cryptographica= lly protect it.  When should they do nothing? When should they just si= gn? When should they just encrypt? When should they sign and then encrypt? What security properties does each option prov= ide or not provide?

 

The choices seem to be:

 

1.     &= nbsp; No JWS and no JWE – assumes the JWT is protec= ted through some other mechanism or that it doesn’t need to be protec= ted

 

2.     &= nbsp; JWS – probably OK if confidentiality is not n= ecessary. 

 

3.     &= nbsp; JWE:

Authen= tication is not provided unless a shared symmetric key is used (if it’= ;s asymmetric encryption, only integrity protection will be provided, not a= uthentication). 

Under what conditions is authentication neces= sary or not necessary?

AES-GCM may not be safe to use with a shared = symmetric key (I sent feedback on this to the jose mailing list).

 

draft-ietf-oauth-v2-http-mac for example seem= s to currently solely use JWE and says “this keying material is a sym= metric or asymmetric long-term key established between the resoruce server = and authorization server”.  If it’s asymmetric, a JWS seems to also be necessary to authenticate the authorization server = as the source of the JWT?

 

4.     &= nbsp; JWS then JWE:

A reci= pient who is an attacker/who is compromised could potentially strip off the= JWE (making it just a JWS) or strip the JWE and replace it with another JW= E to cause confusion about the intended recipient of the JWT and forward it on to another recipient.  The pre= sence of the “aud” (Audience) claim seems to protect against th= is.  However, the “aud” claim is optional in JWTs.

 

 

Thanks,

Mike

--_000_8B4C063947CD794BB6FF90C78BAE9B321EFD49A2IMCMBX04MITREOR_-- From phil.hunt@oracle.com Thu Mar 14 20:17:00 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 53AF911E819B for ; Thu, 14 Mar 2013 20:17:00 -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 K8+DIZCVepef for ; Thu, 14 Mar 2013 20:16:59 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 0231511E818C for ; Thu, 14 Mar 2013 20:16:58 -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 r2F3GvqM024020 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 15 Mar 2013 03:16:58 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r2F3Gvhg010945 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Mar 2013 03:16:57 GMT Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r2F3GvgH013013; Thu, 14 Mar 2013 22:16:57 -0500 Received: from [10.0.1.2] (/64.134.184.181) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 14 Mar 2013 20:16:56 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_3634F0DF-7932-4135-87EE-1B268381D148" From: Phil Hunt In-Reply-To: <8B4C063947CD794BB6FF90C78BAE9B321EFD49A2@IMCMBX04.MITRE.ORG> Date: Thu, 14 Mar 2013 23:16:55 -0400 Message-Id: References: <8B4C063947CD794BB6FF90C78BAE9B321EFD49A2@IMCMBX04.MITRE.ORG> To: "Peck, Michael A" X-Mailer: Apple Mail (2.1283) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] draft-ietf-oauth-json-web-token-06 comment X-BeenThere: oauth@ietf.org X-Mailman-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, 15 Mar 2013 03:17:00 -0000 --Apple-Mail=_3634F0DF-7932-4135-87EE-1B268381D148 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Mike, It is my understanding there will be new draft (or a revision of the MAC = draft) that builds on the JWT draft to define a secure (MAC) token based = on the security requirements presentation I gave today.=20 I believe all/most of your questions should be addressed in the security = draft: http://tools.ietf.org/html/draft-tschofenig-oauth-security-01.=20 Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-03-14, at 11:05 PM, Peck, Michael A wrote: > To explain my comment at the microphone today: > =20 > Section 8 states: > =20 > JWTs use JSON Web Signature (JWS) [JWS] and JSON Web Encryption (JWE) > [JWE] to sign and/or encrypt the contents of the JWT. > =20 > I believe it=92d be useful to expand upon this to give guidance to = those using JWT on what they should do to cryptographically protect it. = When should they do nothing? When should they just sign? When should = they just encrypt? When should they sign and then encrypt? What security = properties does each option provide or not provide? > =20 > The choices seem to be: > =20 > 1. No JWS and no JWE =96 assumes the JWT is protected through = some other mechanism or that it doesn=92t need to be protected > =20 > 2. JWS =96 probably OK if confidentiality is not necessary.=20 > =20 > 3. JWE: > Authentication is not provided unless a shared symmetric key is used = (if it=92s asymmetric encryption, only integrity protection will be = provided, not authentication).=20 > Under what conditions is authentication necessary or not necessary? > AES-GCM may not be safe to use with a shared symmetric key (I sent = feedback on this to the jose mailing list). > =20 > draft-ietf-oauth-v2-http-mac for example seems to currently solely use = JWE and says =93this keying material is a symmetric or asymmetric = long-term key established between the resoruce server and authorization = server=94. If it=92s asymmetric, a JWS seems to also be necessary to = authenticate the authorization server as the source of the JWT? > =20 > 4. JWS then JWE: > A recipient who is an attacker/who is compromised could potentially = strip off the JWE (making it just a JWS) or strip the JWE and replace it = with another JWE to cause confusion about the intended recipient of the = JWT and forward it on to another recipient. The presence of the =93aud=94= (Audience) claim seems to protect against this. However, the =93aud=94 = claim is optional in JWTs. > =20 > =20 > Thanks, > Mike > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_3634F0DF-7932-4135-87EE-1B268381D148 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 htt= p://tools.ietf.org/html/draft-tschofenig-oauth-security-01. 

Phil

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





On 2013-03-14, at 11:05 PM, Peck, Michael A = wrote:

To explain my comment at the = microphone today:
 
Section 8 states:
JWTs use JSON Web Signature = (JWS) [JWS] and JSON Web Encryption = (JWE)
[JWE] to sign and/or encrypt the =
contents of the JWT.
I believe it=92d be useful to expand = upon this to give guidance to those using JWT on what they should do to = cryptographically protect it.  When should they do nothing? When = should they just sign? When should they just encrypt? When should they = sign and then encrypt? What security properties does each option provide = or not provide?
 
The choices seem to be:
 
       No JWS and no = JWE =96 assumes the JWT is protected through some other mechanism or = that it doesn=92t need to be protected
 
       JWS =96 = probably OK if confidentiality is not = necessary. 
 
3. JWE:=
Authentication is not provided unless = a shared symmetric key is used (if it=92s asymmetric encryption, only = integrity protection will be provided, not = authentication). 
Under what = conditions is authentication necessary or not = necessary?
AES-GCM may not be safe to use with = a shared symmetric key (I sent feedback on this to the jose mailing = list).
 
draft-ietf-oauth-v2-http-mac for example seems to = currently solely use JWE and says =93this keying material is a symmetric = or asymmetric long-term key established between the resoruce server and = authorization server=94.  If it=92s asymmetric, a JWS seems to also = be necessary to authenticate the authorization server as the source of = the JWT?
 
4. JWS then = JWE:
A recipient who = is an attacker/who is compromised could potentially strip off the JWE = (making it just a JWS) or strip the JWE and replace it with another JWE = to cause confusion about the intended recipient of the JWT and forward = it on to another recipient.  The presence of the =93aud=94 = (Audience) claim seems to protect against this.  However, the =93aud=94= claim is optional in JWTs.
 
Thanks,
, "oauth@ietf.org" Thread-Topic: draft-ietf-oauth-json-web-token-06 comment Thread-Index: Ac4hKer06uwxlpu0QjCubugIrIswZQAAd59Q Date: Fri, 15 Mar 2013 03:22:47 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436751CC06@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <8B4C063947CD794BB6FF90C78BAE9B321EFD49A2@IMCMBX04.MITRE.ORG> In-Reply-To: <8B4C063947CD794BB6FF90C78BAE9B321EFD49A2@IMCMBX04.MITRE.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.33] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436751CC06TK5EX14MBXC284r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(164054002)(199002)(189002)(377454001)(33656001)(56816002)(47976001)(55846006)(31966008)(5343655001)(5343635001)(53806001)(51856001)(15202345001)(66066001)(16236675001)(77982001)(20776003)(47736001)(4396001)(74502001)(54316002)(79102001)(80022001)(54356001)(46102001)(59766001)(512954001)(49866001)(76482001)(65816001)(50986001)(74662001)(69226001)(47446002)(63696002)(16406001)(56776001); DIR:OUT; SFP:; SCL:1; SRVR:BN1AFFO11HUB013; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 078693968A Cc: Brad Hill Subject: Re: [OAUTH-WG] draft-ietf-oauth-json-web-token-06 comment X-BeenThere: oauth@ietf.org X-Mailman-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, 15 Mar 2013 03:22:58 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436751CC06TK5EX14MBXC284r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mike. I appreciate your comments. Recently, Jeff Hodges and Brad Hill = have made related comments about the desirability of providing additional g= uidance to implementers as to what security properties different choices gi= ve. I agree with you - especially recognizing that the specs will be used = by people who are not experts in the subtleties of cryptography. I will endeavor to do this in subsequent drafts. If you have particular te= xt that you believe should be incorporated, that would be highly appreciate= d. Best wishes, -- Mike From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of P= eck, Michael A Sent: Thursday, March 14, 2013 8:05 PM To: oauth@ietf.org Subject: [OAUTH-WG] draft-ietf-oauth-json-web-token-06 comment To explain my comment at the microphone today: Section 8 states: JWTs use JSON Web Signature (JWS) [JWS] and JSON Web Encryption (JWE) [JWE= ] to sign and/or encrypt the contents of the JWT. I believe it'd be useful to expand upon this to give guidance to those usin= g JWT on what they should do to cryptographically protect it. When should = they do nothing? When should they just sign? When should they just encrypt?= When should they sign and then encrypt? What security properties does each= option provide or not provide? The choices seem to be: 1. No JWS and no JWE - assumes the JWT is protected through some other= mechanism or that it doesn't need to be protected 2. JWS - probably OK if confidentiality is not necessary. 3. JWE: Authentication is not provided unless a shared symmetric key is used (if it= 's asymmetric encryption, only integrity protection will be provided, not a= uthentication). Under what conditions is authentication necessary or not necessary? AES-GCM may not be safe to use with a shared symmetric key (I sent feedback= on this to the jose mailing list). draft-ietf-oauth-v2-http-mac for example seems to currently solely use JWE = and says "this keying material is a symmetric or asymmetric long-term key e= stablished between the resoruce server and authorization server". If it's = asymmetric, a JWS seems to also be necessary to authenticate the authorizat= ion server as the source of the JWT? 4. JWS then JWE: A recipient who is an attacker/who is compromised could potentially strip o= ff the JWE (making it just a JWS) or strip the JWE and replace it with anot= her JWE to cause confusion about the intended recipient of the JWT and forw= ard it on to another recipient. The presence of the "aud" (Audience) claim= seems to protect against this. However, the "aud" claim is optional in JW= Ts. Thanks, Mike --_000_4E1F6AAD24975D4BA5B16804296739436751CC06TK5EX14MBXC284r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Mike.  I appre= ciate your comments.  Recently, Jeff Hodges and Brad Hill have made re= lated comments about the desirability of providing additional guidance to i= mplementers as to what security properties different choices give.  I agree with you – especially recognizing that t= he specs will be used by people who are not experts in the subtleties of cr= yptography.

 

I will endeavor to do = this in subsequent drafts.  If you have particular text that you belie= ve should be incorporated, that would be highly appreciated.

 

   &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;      Best wishes,

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

 

From: oauth-bo= unces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Peck, Michael A
Sent: Thursday, March 14, 2013 8:05 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] draft-ietf-oauth-json-web-token-06 comment<= /o:p>

 

To explain my comment at the microphone today:<= /o:p>

 

Section 8 states:

 

JWTs use JSON Web Signature (JWS) [JWS] and JSON Web Encryption (JWE)
[JWE] =
to sign and/or encrypt the contents of the JWT.

 

I believe it’d be useful to expand upon this t= o give guidance to those using JWT on what they should do to cryptographica= lly protect it.  When should they do nothing? When should they just si= gn? When should they just encrypt? When should they sign and then encrypt? What security properties does each option prov= ide or not provide?

 

The choices seem to be:

 

1.      No JWS and no JWE – assumes the JWT is protec= ted through some other mechanism or that it doesn’t need to be protec= ted

 

2.      JWS – probably OK if confidentiality is not n= ecessary. 

 

3.      JWE:

Authen= tication is not provided unless a shared symmetric key is used (if it’= ;s asymmetric encryption, only integrity protection will be provided, not a= uthentication). 

Under what conditions is authentication neces= sary or not necessary?

AES-GCM may not be safe to use with a shared = symmetric key (I sent feedback on this to the jose mailing list).

 

draft-ietf-oauth-v2-http-mac for example seem= s to currently solely use JWE and says “this keying material is a sym= metric or asymmetric long-term key established between the resoruce server = and authorization server”.  If it’s asymmetric, a JWS seems to also be necessary to authenticate the authorization server = as the source of the JWT?

 

4.      JWS then JWE:

A reci= pient who is an attacker/who is compromised could potentially strip off the= JWE (making it just a JWS) or strip the JWE and replace it with another JW= E to cause confusion about the intended recipient of the JWT and forward it on to another recipient.  The pre= sence of the “aud” (Audience) claim seems to protect against th= is.  However, the “aud” claim is optional in JWTs.

 

 

Thanks,

Mike

--_000_4E1F6AAD24975D4BA5B16804296739436751CC06TK5EX14MBXC284r_-- From ve7jtb@ve7jtb.com Fri Mar 15 10:09: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 712FC21F8749 for ; Fri, 15 Mar 2013 10:09:43 -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 s0Orlbe5m7rJ for ; Fri, 15 Mar 2013 10:09:41 -0700 (PDT) Received: from mail-pb0-f41.google.com (mail-pb0-f41.google.com [209.85.160.41]) by ietfa.amsl.com (Postfix) with ESMTP id 215A621F8746 for ; Fri, 15 Mar 2013 10:09:38 -0700 (PDT) Received: by mail-pb0-f41.google.com with SMTP id um15so4120448pbc.28 for ; Fri, 15 Mar 2013 10:09: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=BUF6otU7ABk0B8tR0z63ZNmkdLKMHl6qITy4PQO3N4I=; b=UC7SbU4Bl8jQKWrLccAADeJkD137cgL93BvGUa05UCMvr01mrBd6h+pcmQCQ7DC9L0 jKDrhdurIsij5u64Su+JGLFcaEotrbl7f/wWVu127ROaZle30lweOENyA49FAo1w6gR0 P7ObzX4sxaSkMP6CUn+2XEXbqDo+kXQ+8h+n/wiqU02LxUxuzYQ1owZSMKNMNU5NPgse W2jPn8iUxxQKMHW3ZYc9KYigKf1JH2yiYLUlWcmaYaFCx980M5XX37LTdGxdUm4ovV78 AevwPnGm3T2USH+rDRiVWyn0cL/YFXc6XhNAu9vesRCWRrk8ONZTM0KQoRz+dzghYtfn sKng== X-Received: by 10.68.137.202 with SMTP id qk10mr17685371pbb.189.1363367377919; Fri, 15 Mar 2013 10:09:37 -0700 (PDT) Received: from dhcp-543c.meeting.ietf.org (dhcp-543c.meeting.ietf.org. [130.129.84.60]) by mx.google.com with ESMTPS id hu2sm9648117pbc.38.2013.03.15.10.09.33 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Mar 2013 10:09:34 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_423D693E-A891-4A80-AECC-0146104CF03B"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Bradley In-Reply-To: <59E470B10C4630419ED717AC79FCF9A9568A84A6@BY2PRD0411MB441.namprd04.prod.outlook.com> Date: Fri, 15 Mar 2013 13:09:31 -0400 Message-Id: References: <59E470B10C4630419ED717AC79FCF9A948D552B8@BY2PRD0411MB441.namprd04.prod.outlook.com> <4E1F6AAD24975D4BA5B168042967394367472284@TK5EX14MBXC284.redmond.corp.microsoft.com> <59E470B10C4630419ED717AC79FCF9A9568A83EA@BY2PRD0411MB441.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A9568A84A6@BY2PRD0411MB441.namprd04.prod.outlook.com> To: Lewis Adam-CAL022 X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQmbN8K6C5kcVmNYdgQQhXkhBB02upRSXjBn4ZL7Kb6/gPayeNWCfATotqDDK2Y1+EyDw5G4 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] JWT grant_type and client_id X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 17:09:43 -0000 --Apple-Mail=_423D693E-A891-4A80-AECC-0146104CF03B Content-Type: multipart/alternative; boundary="Apple-Mail=_AF3D3A16-C245-4B2C-A7FD-3A71AF9D9C24" --Apple-Mail=_AF3D3A16-C245-4B2C-A7FD-3A71AF9D9C24 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 The spec is a touch vague on that. I think the scopes should be in the = assertion and the client can use the scopes outside the assertion to = down-scope. Having a standard claim in JWT and SAML for passing scopes is probably = useful as part of a profile. John B. On 2013-03-14, at 8:47 PM, Lewis Adam-CAL022 = wrote: > Hmmm, one more thought =85 no scope?? The JWT is the grant, is it = assumed that the scope is conveyed as a claim within the token? = Otherwise it would seem that it would require a scope. > =20 > Thoughts? > adam > =20 > From: Brian Campbell [mailto:bcampbell@pingidentity.com]=20 > Sent: Thursday, March 14, 2013 4:44 PM > To: Lewis Adam-CAL022 > Cc: Mike Jones; "WG "@il06exr02.mot.com > Subject: Re: [OAUTH-WG] JWT grant_type and client_id > =20 > Yes, that is correct. >=20 > I'm working on new revisions of the drafts that will hopefully make = that point more clear. > =20 >=20 > On Thu, Mar 14, 2013 at 5:26 PM, Lewis Adam-CAL022 = wrote: > Coming back to this =85 am I correct in that client_id is not = required? We are implementing this spec and want to make sure that we = are doing it right. By my understanding the only two parameters that = are required in the JWT grant type are = "urn:ietf:params:oauth:grant-type:jwt-bearer" and the assertion. Is = this correct? > =20 > =20 > From: Mike Jones [mailto:Michael.Jones@microsoft.com]=20 > Sent: Monday, February 18, 2013 6:58 PM > To: Lewis Adam-CAL022; oauth@ietf.org WG > Subject: RE: JWT grant_type and client_id > =20 > The client_id value and the access token value are independent. > =20 > -- = Mike > =20 > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf = Of Lewis Adam-CAL022 > Sent: Monday, February 18, 2013 2:50 PM > To: oauth@ietf.org WG > Subject: [OAUTH-WG] JWT grant_type and client_id > =20 > =20 > Is there any guidance on the usage of client_id when using the JWT = assertion profile as a grant type? draft-ietf-oauth-jwt-bearer-04 makes = no mention so I assume that it is not required =85 but it would be = necessary if using in conjunction with a HOK profile where the JWT = assertion is issued to =96 and may only be used by =96 the intended = client. Obviously this is straight forward enough, really I=92m just = looking to be sure that I=92m not missing anything. > =20 > tx > adam >=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=_AF3D3A16-C245-4B2C-A7FD-3A71AF9D9C24 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 The spec is a touch vague on = that.  I think the scopes should be in the assertion and the client = can use the scopes outside the assertion to = down-scope.

Having a standard claim in JWT and SAML = for passing scopes is probably useful as part of a = profile.

John B.

On = 2013-03-14, at 8:47 PM, Lewis Adam-CAL022 <Adam.Lewis@motorolasoluti= ons.com> wrote:

Hmmm, one more thought =85= no scope??  The JWT is the grant, is it assumed that the scope is = conveyed as a claim within the token?  Otherwise it would seem that = it would require a scope.
 
adam
 
From: Brian Campbell = [mailto:bcampbell@pingidentity.com] 
Sent: Thursday, March 14, 2013 = 4:44 PM
To: Lewis = Adam-CAL022
Cc: Mike Jones; "WG <oauth@ietf.org>"@il06exr02.mot.com
Subject:=  Re: [OAUTH-WG] JWT = grant_type and client_id
 

Yes, that is = correct.

I'm working on = new revisions of the drafts that will hopefully make that point more = clear.

On Thu, Mar = 14, 2013 at 5:26 PM, Lewis Adam-CAL022 <

 
The client_id value and the access = token value are independent.
 oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Lewis = Adam-CAL022
Sent: Monday, February 18, 2013 = 2:50 PM
To: oauth@ietf.org WG
Subject: [OAUTH-WG] JWT grant_type = and client_id
 
Is = there any guidance on the usage of client_id when using the JWT = assertion profile as a grant type?  draft-ietf-oauth-jwt-bearer-04 = makes no mention so I assume that it is not required =85 but it would be = necessary if using in conjunction with a HOK profile where the JWT = assertion is issued to =96 and may only be used by =96 the intended = client.  Obviously this is straight forward enough, really I=92m = just looking to be sure that I=92m not missing = anything.
OAuth@ietf.org
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth

= --Apple-Mail=_AF3D3A16-C245-4B2C-A7FD-3A71AF9D9C24-- --Apple-Mail=_423D693E-A891-4A80-AECC-0146104CF03B 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 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMzE1MTcwOTMxWjAjBgkqhkiG9w0BCQQxFgQU0LMukVdi Nrn/+wR5gs8U64R0wowwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEArCFVBrq5wxa/mOWnMGUnyl0GMdpiF2aLC9S1lzIG se4/nYbxTg2FBuuejifnPPgu4PaiYYJLTJEo1xAhHLgn9t8xpFlQyKE4NbWBGAwc9KLYldOgI0Km KrkshdO2BS08fC675++3BT356E2+slXJX8tTXnZLSmjkh896c3LQCj/ih7dE30X1HmLkDwcorlvs LQOH7df1X928dPIsxshj6mJcS1b4O2W65qUdMApLAQs7EPgSsWix2rAZzky2yfNRq4X24UMmBSid SIY4WhNU5z9erjMvS3em7XJQAfBdRlE8dddKN+HyJt97Gdnctg+ACR7bV1YF3Ec7mpjtBRTk4gAA AAAAAA== --Apple-Mail=_423D693E-A891-4A80-AECC-0146104CF03B-- From Jeff.Hodges@KingsMountain.com Fri Mar 15 10:11: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 DC70121F8548 for ; Fri, 15 Mar 2013 10:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.11 X-Spam-Level: X-Spam-Status: No, score=-103.11 tagged_above=-999 required=5 tests=[AWL=0.489, 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 M8HSQIq18uRf for ; Fri, 15 Mar 2013 10:11:32 -0700 (PDT) Received: from oproxy12-pub.bluehost.com (oproxy12-pub.bluehost.com [50.87.16.10]) by ietfa.amsl.com (Postfix) with SMTP id 48D6B21F874F for ; Fri, 15 Mar 2013 10:11:27 -0700 (PDT) Received: (qmail 1546 invoked by uid 0); 15 Mar 2013 17:11:03 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy12.bluehost.com with SMTP; 15 Mar 2013 17:11:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=MCpISSoLg9qs8t8Ia/cWjLojosvlM5QwUvB0YV81FAs=; b=8H7F/Fw4XIDgW2TqmRE5zvTDRvFlAdZXF37L2/Fr0JqTKnNtZuw8ThnJx4oqnbpcgyGeK4VdTqI5kQHIs6x+s3dg0BcmE1fZIJGRBwCoxeGd3MrQr+70KNpHHlEyCZok; Received: from [130.129.19.55] (port=43444) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.80) (envelope-from ) id 1UGY9m-0006pX-76 for oauth@ietf.org; Fri, 15 Mar 2013 11:11:02 -0600 Message-ID: <51435624.40904@KingsMountain.com> Date: Fri, 15 Mar 2013 10:11:00 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: IETF oauth WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 130.129.19.55 authed with jeff.hodges+kingsmountain.com} 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: Fri, 15 Mar 2013 17:11:34 -0000 During the OAuth 2nd session at IETF-86 orlando, after I mentioned the sign-then-encrypt considerations at the mic, Brad Hill pointed out that the below paper is perhaps an even more fundamental reference for the sigh-then-encrypt composition than the Davis paper I pointed to in the below attached message back in Dec-2012.. Authenticated Encryption: Relations among notions and analysis of the generic composition paradigm (2007) Bellare & Namprempre http://eprint.iacr.org/2000/025.pdf After having talked with Mike Jones f2f earlier in the week about this stuff, during which he indicated he believed that these issues are addressed in the JWT spec, I looked at draft-ietf-oauth-json-web-token-06 and note that the last paragraph of the security considerations says.. While syntactically, the signing and encryption operations for Nested JWTs may be applied in any order, normally 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. Furthermore, signatures over encrypted text are not considered valid in many jurisdictions. ..which certainly touches upon the issue(s), but could arguably contain more rationale. Though, if you wish the spec to be terse (as above) you should probably at least reference Davis (which is resonably approachable) and Bellare & Namprempre (which is a formal proof). Also, in terms of linkages between signing and encrypting wrappers, it seems that if one includes at least an audience claim in the JWT Claims Set, in a signed & encrypted JWT (aka "Nested JWT"), and the receiver of the JWT checks the audience and does not rely on the JWT if it does not identify them, then you are arguably in ok shape. If the JWT includes both subject and audience claims, that would be best. It may be a good idea to note this, since in the JWT spec all claims are optional, and incorporation of (and reliance on) JWT claims is left to JWT profiles. I.e., there arguably should be advice to JWT profile authors regarding security properties resulting from incorporation (or not) of various JWT claims. HTH, =JeffH ------ https://www.ietf.org/mail-archive/web/oauth/current/msg10326.html [OAUTH-WG] regarding nested JWTs and security From: =JeffH Date: Fri, 21 Dec 2012 15:07:35 -0800 To: IETF oauth WG "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=10.1.1.28.7379&rep=rep1&type=pdf One has to carefully compose signing and encryption in order to avoid various 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 what 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 determine whether it addresses the need for sign and encrypt to cross-refer (see S4.3 in the paper). HTH, =JeffH From hannes.tschofenig@gmx.net Fri Mar 15 10:54:32 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 0953921F88DB for ; Fri, 15 Mar 2013 10:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.849 X-Spam-Level: X-Spam-Status: No, score=-102.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQBOonYnk6qu for ; Fri, 15 Mar 2013 10:54:30 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 2871D21F8858 for ; Fri, 15 Mar 2013 10:54:30 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.35]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0LyPe4-1Uly1j1LNO-015sTw for ; Fri, 15 Mar 2013 18:54:29 +0100 Received: (qmail invoked by alias); 15 Mar 2013 17:54:29 -0000 Received: from dhcp-1077.meeting.ietf.org (EHLO dhcp-1077.meeting.ietf.org) [130.129.16.119] by mail.gmx.net (mp035) with SMTP; 15 Mar 2013 18:54:29 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/m74B8+K/mH/1JErh6KYriz0dOswANyspNFgrY6q HiWON+NubUiLRT From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 15 Mar 2013 13:54:26 -0400 Message-Id: <48B22416-E2F4-4118-8348-84141525A1AB@gmx.net> To: "oauth@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] Meeting Minutes X-BeenThere: oauth@ietf.org X-Mailman-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, 15 Mar 2013 17:54:32 -0000 Here are the meeting minutes from the two OAuth WG sessions this week: http://www.ietf.org/proceedings/86/minutes/minutes-86-oauth In case you want to correct something please let us know within the next = two weeks.=20 Ciao Hannes & Derek From Adam.Lewis@motorolasolutions.com Fri Mar 15 13:40: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 3EBEB21F872E for ; Fri, 15 Mar 2013 13:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.966 X-Spam-Level: X-Spam-Status: No, score=-1.966 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 g0ChXyAgXzO5 for ; Fri, 15 Mar 2013 13:40:28 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe002.messaging.microsoft.com [207.46.163.25]) by ietfa.amsl.com (Postfix) with ESMTP id A57C821F8546 for ; Fri, 15 Mar 2013 13:40:28 -0700 (PDT) Received: from mail145-co9-R.bigfish.com (10.236.132.238) by CO9EHSOBE028.bigfish.com (10.236.130.91) with Microsoft SMTP Server id 14.1.225.23; Fri, 15 Mar 2013 20:40:28 +0000 Received: from mail145-co9 (localhost [127.0.0.1]) by mail145-co9-R.bigfish.com (Postfix) with ESMTP id 43C24480257 for ; Fri, 15 Mar 2013 20:40:28 +0000 (UTC) X-Forefront-Antispam-Report: CIP:129.188.136.17; KIP:(null); UIP:(null); IPV:NLI; H:il06msg01.mot-solutions.com; RD:none; EFVD:NLI X-SpamScore: -29 X-BigFish: VPS-29(zz98dI9371I936eIc85fh179dNzz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL17326ah8275dh18c673h1954cbh8275bhz2fh2a8h683h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1155h) Received-SPF: pass (mail145-co9: domain of motorolasolutions.com designates 129.188.136.17 as permitted sender) client-ip=129.188.136.17; envelope-from=Adam.Lewis@motorolasolutions.com; helo=il06msg01.mot-solutions.com ; olutions.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.237.133; KIP:(null); UIP:(null); (null); H:BY2PRD0411HT005.namprd04.prod.outlook.com; R:internal; EFV:INT Received: from mail145-co9 (localhost.localdomain [127.0.0.1]) by mail145-co9 (MessageSwitch) id 1363380026332909_15065; Fri, 15 Mar 2013 20:40:26 +0000 (UTC) Received: from CO9EHSMHS013.bigfish.com (unknown [10.236.132.252]) by mail145-co9.bigfish.com (Postfix) with ESMTP id 4522B3C005D for ; Fri, 15 Mar 2013 20:40:26 +0000 (UTC) Received: from il06msg01.mot-solutions.com (129.188.136.17) by CO9EHSMHS013.bigfish.com (10.236.130.23) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 15 Mar 2013 20:40:25 +0000 Received: from il06msg01.mot-solutions.com (il06vts03.mot.com [129.188.137.143]) by il06msg01.mot-solutions.com (8.14.3/8.14.3) with ESMTP id r2FKePe5005532 for ; Fri, 15 Mar 2013 15:40:25 -0500 (CDT) Received: from DB8EHSOBE023.bigfish.com (mail-db8lp0188.outbound.messaging.microsoft.com [213.199.154.188]) by il06msg01.mot-solutions.com (8.14.3/8.14.3) with ESMTP id r2FKeNmG005526 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 15 Mar 2013 15:40:24 -0500 (CDT) Received: from mail209-db8-R.bigfish.com (10.174.8.228) by DB8EHSOBE023.bigfish.com (10.174.4.86) with Microsoft SMTP Server id 14.1.225.23; Fri, 15 Mar 2013 20:40:23 +0000 Received: from mail209-db8 (localhost [127.0.0.1]) by mail209-db8-R.bigfish.com (Postfix) with ESMTP id 2EA62A006B for ; Fri, 15 Mar 2013 20:40:23 +0000 (UTC) Received: from mail209-db8 (localhost.localdomain [127.0.0.1]) by mail209-db8 (MessageSwitch) id 1363380021592695_2087; Fri, 15 Mar 2013 20:40:21 +0000 (UTC) Received: from DB8EHSMHS012.bigfish.com (unknown [10.174.8.238]) by mail209-db8.bigfish.com (Postfix) with ESMTP id 8DDE8480049; Fri, 15 Mar 2013 20:40:21 +0000 (UTC) Received: from BY2PRD0411HT005.namprd04.prod.outlook.com (157.56.237.133) by DB8EHSMHS012.bigfish.com (10.174.4.22) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 15 Mar 2013 20:40:21 +0000 Received: from BY2PRD0411MB441.namprd04.prod.outlook.com ([169.254.5.31]) by BY2PRD0411HT005.namprd04.prod.outlook.com ([10.255.128.40]) with mapi id 14.16.0275.006; Fri, 15 Mar 2013 20:40:15 +0000 From: Lewis Adam-CAL022 To: John Bradley Thread-Topic: [OAUTH-WG] JWT grant_type and client_id Thread-Index: AQHOIZ/r1HEEtHv+3EWHg8cTaO2lWpinNtgw Date: Fri, 15 Mar 2013 20:40:15 +0000 Message-ID: <59E470B10C4630419ED717AC79FCF9A9568A8760@BY2PRD0411MB441.namprd04.prod.outlook.com> References: <59E470B10C4630419ED717AC79FCF9A948D552B8@BY2PRD0411MB441.namprd04.prod.outlook.com> <4E1F6AAD24975D4BA5B168042967394367472284@TK5EX14MBXC284.redmond.corp.microsoft.com> <59E470B10C4630419ED717AC79FCF9A9568A83EA@BY2PRD0411MB441.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A9568A84A6@BY2PRD0411MB441.namprd04.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [150.130.34.151] Content-Type: multipart/alternative; boundary="_000_59E470B10C4630419ED717AC79FCF9A9568A8760BY2PRD0411MB441_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%1294$Dn%VE7JTB.COM$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn% X-FOPE-CONNECTOR: Id%1294$Dn%PINGIDENTITY.COM$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn% X-FOPE-CONNECTOR: Id%1294$Dn%IETF.ORG$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn% X-CFilter-Loop: Reflected X-OriginatorOrg: motorolasolutions.com Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] JWT grant_type and client_id X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 20:40:31 -0000 --_000_59E470B10C4630419ED717AC79FCF9A9568A8760BY2PRD0411MB441_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi John, I would like to argue that the scope should be a parameter in the access to= ken request message, the same as it is for the RO creds grant and client cr= eds grant type. This would keep it consistent with the core OAuth grant ty= pes that talk directly to the token endpoint. Thoughts? adam From: John Bradley [mailto:ve7jtb@ve7jtb.com] Sent: Friday, March 15, 2013 12:10 PM To: Lewis Adam-CAL022 Cc: Brian Campbell; "WG "@il06exr02.mot.com Subject: Re: [OAUTH-WG] JWT grant_type and client_id The spec is a touch vague on that. I think the scopes should be in the ass= ertion and the client can use the scopes outside the assertion to down-scop= e. Having a standard claim in JWT and SAML for passing scopes is probably usef= ul as part of a profile. John B. On 2013-03-14, at 8:47 PM, Lewis Adam-CAL022 > wrote: Hmmm, one more thought ... no scope?? The JWT is the grant, is it assumed = that the scope is conveyed as a claim within the token? Otherwise it would= seem that it would require a scope. Thoughts? adam From: Brian Campbell [mailto:bcampbell@pingidentity.com] Sent: Thursday, March 14, 2013 4:44 PM To: Lewis Adam-CAL022 Cc: Mike Jones; "WG >"@il06exr02.mot.= com Subject: Re: [OAUTH-WG] JWT grant_type and client_id Yes, that is correct. I'm working on new revisions of the drafts that will hopefully make that po= int more clear. On Thu, Mar 14, 2013 at 5:26 PM, Lewis Adam-CAL022 > wrote: Coming back to this ... am I correct in that client_id is not required? We= are implementing this spec and want to make sure that we are doing it righ= t. By my understanding the only two parameters that are required in the JW= T grant type are "urn:ietf:params:oauth:grant-type:jwt-bearer" and the as= sertion. Is this correct? From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Monday, February 18, 2013 6:58 PM To: Lewis Adam-CAL022; oauth@ietf.org WG Subject: RE: JWT grant_type and client_id The client_id value and the access token value are independent. -- Mike From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Lewis Adam-CAL= 022 Sent: Monday, February 18, 2013 2:50 PM To: oauth@ietf.org WG Subject: [OAUTH-WG] JWT grant_type and client_id Is there any guidance on the usage of client_id when using the JWT assertio= n profile as a grant type? draft-ietf-oauth-jwt-bearer-04 makes no mention= so I assume that it is not required ... but it would be necessary if using= in conjunction with a HOK profile where the JWT assertion is issued to - a= nd may only be used by - the intended client. Obviously this is straight f= orward enough, really I'm just looking to be sure that I'm not missing anyt= hing. tx adam _______________________________________________ OAuth mailing 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_59E470B10C4630419ED717AC79FCF9A9568A8760BY2PRD0411MB441_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi John,

 <= /p>

I would like to argue tha= t the scope should be a parameter in the access token request message, the = same as it is for the RO creds grant and client creds grant type.  This would keep it consistent with the core OAuth grant types = that talk directly to the token endpoint.

 <= /p>

Thoughts?

adam

 <= /p>

From: John Bra= dley [mailto:ve7jtb@ve7jtb.com]
Sent: Friday, March 15, 2013 12:10 PM
To: Lewis Adam-CAL022
Cc: Brian Campbell; "WG <oauth@ietf.org>"@il06exr02.= mot.com
Subject: Re: [OAUTH-WG] JWT grant_type and client_id

 

The spec is a touch vague on that.  I think the= scopes should be in the assertion and the client can use the scopes outsid= e the assertion to down-scope.

 

Having a standard claim in JWT and SAML for passing = scopes is probably useful as part of a profile.

 

John B.

 

On 2013-03-14, at 8:47 PM, Lewis Adam-CAL022 <Adam.Lewis@motorolasolutio= ns.com> wrote:



Hmmm, one more thought &#= 8230; no scope??  The JWT is the grant, is it assumed that the scope i= s conveyed as a claim within the token?  Otherwise it would seem that it would require a scope.

 <= /p>

Thoughts?

adam

 <= /p>

From: Brian Campbell [mailto:bcampbell@pingidentit= y.com] 
Sent: Thursday, Ma= rch 14, 2013 4:44 PM
To: Lewis Adam-CAL= 022
Cc: Mike Jones; &q= uot;WG <oauth@ietf.org>"@<= a href=3D"http://il06exr02.mot.com">il06exr02.mot.com
Subject: Re: [OAUT= H-WG] JWT grant_type and client_id

 

Yes, that is correct.=

I'm working on new revisions of the drafts that will= hopefully make that point more clear.

 

On Thu, Mar 14, 2013 at 5:26 PM, Lewis Adam-CAL022 &= lt;Adam.Lewis@motorolasolutions.com> = wrote:

Coming back to this … am I correct in=
 that client_id is not required?  We are implementing this spec and wa=
nt to make sure that we are doing it right.  By my understanding the o=
nly two parameters that are required in the JWT grant type are  "=
urn:ietf:params:oauth:grant-type:jwt-bearer"  and the assertion.&=
nbsp;  Is this correct?

 

 

From: Mike Jones [mailto:Michael.Jones@microsoft.com] 
Sent: Monday, Febr= uary 18, 2013 6:58 PM
To: Lewis Adam-CAL= 022; oauth@ietf.org=  WG
Subject: RE: JWT g= rant_type and client_id

 

The client_id value an= d the access token value are independent.

 

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

 

From: = oauth-bounces@ietf.org&nbs= p;[mailto:oauth-bounces@ietf.org] On Behalf Of Lewis Adam= -CAL022
Sent: Monday, Febr= uary 18, 2013 2:50 PM
To: oauth@ie= tf.org WG
Subject: [OAUTH-WG= ] JWT grant_type and client_id

 

 

Is there any guidance on the usage of c= lient_id when using the JWT assertion profile as a grant type?  draft-= ietf-oauth-jwt-bearer-04 makes no mention so I assume that it is not required … but it would be necessary if using in conjunction = with a HOK profile where the JWT assertion is issued to – and may onl= y be used by – the intended client.  Obviously this is straight = forward enough, really I’m just looking to be sure that I’m not missing anything.

 

tx

adam


_______________________________________________
OAuth mailing list
OAuth@ietf.o= rg
<= span style=3D"color:purple">https://www.ietf.org/mailman/listinfo/oauth

 

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

 

--_000_59E470B10C4630419ED717AC79FCF9A9568A8760BY2PRD0411MB441_-- From sberyozkin@gmail.com Fri Mar 15 14:31: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 681D921F8A27 for ; Fri, 15 Mar 2013 14:31:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.457 X-Spam-Level: X-Spam-Status: No, score=0.457 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, J_CHICKENPOX_25=0.6, 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 XRC0w5GNmso5 for ; Fri, 15 Mar 2013 14:31:46 -0700 (PDT) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id ED48D21F8A09 for ; Fri, 15 Mar 2013 14:31:45 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id x8so3631272wey.6 for ; Fri, 15 Mar 2013 14:31:41 -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=Ix2sDLovn+5u3ce8PABEIMnDbRKP5+VbgyoTTgUFxBA=; b=tt8Txu/O+Ly9RkM9JESYQYedDq6T5oJjpVDWnvHn7L+JmoYVczf5eMpmr+FmkWR60I A1wSIgYREChQZ6ppviC/Y/y/WAf40E2hykbzNqIqsG6nL0L99I/63DzaIHv4mMaybqSm OuB8BiXsUDvya17H2/7gPbb16fucmhfBMJxQcxEatrkJRhwhXebBvbcwDFsYZyAKSP+1 fDu5zED3Bd4sXAvdKIsf7MY342brs8+jQgVAdrLQFfq1SRliOKvSoRxjcwVnv2RbmAfn soRezt4xuuTVEY4W5b6ZYLlu66jbg+A/DksYByptvEfhI84a5kWBObBRZgcC8aHFkQCv JPZA== X-Received: by 10.180.94.133 with SMTP id dc5mr3234955wib.1.1363383089498; Fri, 15 Mar 2013 14:31:29 -0700 (PDT) Received: from [192.168.2.5] ([89.100.141.171]) by mx.google.com with ESMTPS id c15sm340301wiw.3.2013.03.15.14.31.27 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Mar 2013 14:31:28 -0700 (PDT) Message-ID: <51439320.9060401@gmail.com> Date: Fri, 15 Mar 2013 21:31:12 +0000 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: <59E470B10C4630419ED717AC79FCF9A948D552B8@BY2PRD0411MB441.namprd04.prod.outlook.com> <4E1F6AAD24975D4BA5B168042967394367472284@TK5EX14MBXC284.redmond.corp.microsoft.com> <59E470B10C4630419ED717AC79FCF9A9568A83EA@BY2PRD0411MB441.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A9568A84A6@BY2PRD0411MB441.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A9568A8760@BY2PRD0411MB441.namprd04.prod.outlook.com> In-Reply-To: <59E470B10C4630419ED717AC79FCF9A9568A8760@BY2PRD0411MB441.namprd04.prod.outlook.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [OAUTH-WG] JWT grant_type and client_id X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 21:31:47 -0000 Hi On 15/03/13 20:40, Lewis Adam-CAL022 wrote: > Hi John, > > I would like to argue that the scope should be a parameter in the access > token request message, the same as it is for the RO creds grant and > client creds grant type. This would keep it consistent with the core > OAuth grant types that talk directly to the token endpoint. > Assuming the assertion is acting as a grant, then it is indeed an access token request message, so IMHO it makes sense to get an outbound scope parameter optionally supported which I guess will imply that the client id will also have to accompany it... Cheers, Sergey > Thoughts? > > adam > > *From:*John Bradley [mailto:ve7jtb@ve7jtb.com] > *Sent:* Friday, March 15, 2013 12:10 PM > *To:* Lewis Adam-CAL022 > *Cc:* Brian Campbell; "WG "@il06exr02.mot.com > *Subject:* Re: [OAUTH-WG] JWT grant_type and client_id > > The spec is a touch vague on that. I think the scopes should be in the > assertion and the client can use the scopes outside the assertion to > down-scope. > > Having a standard claim in JWT and SAML for passing scopes is probably > useful as part of a profile. > > John B. > > On 2013-03-14, at 8:47 PM, Lewis Adam-CAL022 > > wrote: > > > > Hmmm, one more thought … no scope?? The JWT is the grant, is it assumed > that the scope is conveyed as a claim within the token? Otherwise it > would seem that it would require a scope. > > Thoughts? > > adam > > *From:*Brian Campbell [mailto:bcampbell@pingidentity.com > ] > *Sent:*Thursday, March 14, 2013 4:44 PM > *To:*Lewis Adam-CAL022 > *Cc:*Mike Jones; "WG >"@il06exr02.mot.com > *Subject:*Re: [OAUTH-WG] JWT grant_type and client_id > > Yes, that is correct. > > I'm working on new revisions of the drafts that will hopefully make that > point more clear. > > On Thu, Mar 14, 2013 at 5:26 PM, Lewis Adam-CAL022 > > wrote: > > Coming back to this… am I correct in that client_id is not required? We are implementing this spec and want to make sure that we are doing it right. By my understanding the only two parameters that are required in the JWT grant type are "urn:ietf:params:oauth:grant-type:jwt-bearer" and the assertion. Is this correct? > > *From:*Mike Jones [mailto:Michael.Jones@microsoft.com > ] > *Sent:*Monday, February 18, 2013 6:58 PM > *To:*Lewis Adam-CAL022;oauth@ietf.org WG > *Subject:*RE: JWT grant_type and client_id > > The client_id value and the access token value are independent. > > -- Mike > > *From:*oauth-bounces@ietf.org > [mailto:oauth-bounces@ietf.org > ]*On Behalf Of*Lewis Adam-CAL022 > *Sent:*Monday, February 18, 2013 2:50 PM > *To:*oauth@ietf.org WG > *Subject:*[OAUTH-WG] JWT grant_type and client_id > > Is there any guidance on the usage of client_id when using the JWT > assertion profile as a grant type? draft-ietf-oauth-jwt-bearer-04 makes > no mention so I assume that it is not required … but it would be > necessary if using in conjunction with a HOK profile where the JWT > assertion is issued to – and may only be used by – the intended client. > Obviously this is straight forward enough, really I’m just looking to be > sure that I’m not missing anything. > > tx > > adam > > > _______________________________________________ > OAuth mailing 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 Adam.Lewis@motorolasolutions.com Fri Mar 15 14:44: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 8660421F848D for ; Fri, 15 Mar 2013 14:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.167 X-Spam-Level: X-Spam-Status: No, score=-0.167 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_00=-2.599, J_CHICKENPOX_25=0.6, 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 d-7c5xb4Jfdf for ; Fri, 15 Mar 2013 14:44:07 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0185.outbound.messaging.microsoft.com [213.199.154.185]) by ietfa.amsl.com (Postfix) with ESMTP id 1A16621F848B for ; Fri, 15 Mar 2013 14:44:06 -0700 (PDT) Received: from mail166-db8-R.bigfish.com (10.174.8.226) by DB8EHSOBE010.bigfish.com (10.174.4.73) with Microsoft SMTP Server id 14.1.225.23; Fri, 15 Mar 2013 21:44:05 +0000 Received: from mail166-db8 (localhost [127.0.0.1]) by mail166-db8-R.bigfish.com (Postfix) with ESMTP id 7BFDBD000D3 for ; Fri, 15 Mar 2013 21:44:05 +0000 (UTC) X-Forefront-Antispam-Report: CIP:192.160.210.20; KIP:(null); UIP:(null); IPV:NLI; H:ct11msg01.am.mot-solutions.com; RD:ct11msg01.mot-solutions.com; EFVD:NLI X-SpamScore: -32 X-BigFish: VPS-32(zzbb2dI98dI9371I936eI542I1432I179dNzz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL17326ah8275dh8275bhz2fh2a8h683h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1b0ah1155h) Received-SPF: pass (mail166-db8: domain of motorolasolutions.com designates 192.160.210.20 as permitted sender) client-ip=192.160.210.20; envelope-from=Adam.Lewis@motorolasolutions.com; helo=ct11msg01.am.mot-solutions.com ; olutions.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.237.133; KIP:(null); UIP:(null); (null); H:BY2PRD0411HT003.namprd04.prod.outlook.com; R:internal; EFV:INT Received: from mail166-db8 (localhost.localdomain [127.0.0.1]) by mail166-db8 (MessageSwitch) id 1363383843175858_30241; Fri, 15 Mar 2013 21:44:03 +0000 (UTC) Received: from DB8EHSMHS008.bigfish.com (unknown [10.174.8.241]) by mail166-db8.bigfish.com (Postfix) with ESMTP id EB33CDC0047 for ; Fri, 15 Mar 2013 21:44:01 +0000 (UTC) Received: from ct11msg01.am.mot-solutions.com (192.160.210.20) by DB8EHSMHS008.bigfish.com (10.174.4.18) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 15 Mar 2013 21:44:01 +0000 Received: from ct11msg01.am.mot-solutions.com (ct11vts01.am.mot.com [10.177.16.159]) by ct11msg01.am.mot-solutions.com (8.14.3/8.14.3) with ESMTP id r2FLhV6k011467 for ; Fri, 15 Mar 2013 16:43:32 -0500 (CDT) Received: from CO9EHSOBE017.bigfish.com (co9ehsobe002.messaging.microsoft.com [207.46.163.25]) by ct11msg01.am.mot-solutions.com (8.14.3/8.14.3) with ESMTP id r2FLhVWr011461 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 15 Mar 2013 16:43:31 -0500 (CDT) Received: from mail117-co9-R.bigfish.com (10.236.132.239) by CO9EHSOBE017.bigfish.com (10.236.130.80) with Microsoft SMTP Server id 14.1.225.23; Fri, 15 Mar 2013 21:43:58 +0000 Received: from mail117-co9 (localhost [127.0.0.1]) by mail117-co9-R.bigfish.com (Postfix) with ESMTP id ABE2F300161 for ; Fri, 15 Mar 2013 21:43:58 +0000 (UTC) Received: from mail117-co9 (localhost.localdomain [127.0.0.1]) by mail117-co9 (MessageSwitch) id 1363383836381799_783; Fri, 15 Mar 2013 21:43:56 +0000 (UTC) Received: from CO9EHSMHS028.bigfish.com (unknown [10.236.132.234]) by mail117-co9.bigfish.com (Postfix) with ESMTP id 517D8D8005A; Fri, 15 Mar 2013 21:43:56 +0000 (UTC) Received: from BY2PRD0411HT003.namprd04.prod.outlook.com (157.56.237.133) by CO9EHSMHS028.bigfish.com (10.236.130.38) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 15 Mar 2013 21:43:56 +0000 Received: from BY2PRD0411MB441.namprd04.prod.outlook.com ([169.254.5.31]) by BY2PRD0411HT003.namprd04.prod.outlook.com ([10.255.128.38]) with mapi id 14.16.0275.006; Fri, 15 Mar 2013 21:43:55 +0000 From: Lewis Adam-CAL022 To: Sergey Beryozkin , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] JWT grant_type and client_id Thread-Index: AQHOIcSMntq7LhwW+0iu3UcODyW3TZinR/zA Date: Fri, 15 Mar 2013 21:43:55 +0000 Message-ID: <59E470B10C4630419ED717AC79FCF9A9568A87C1@BY2PRD0411MB441.namprd04.prod.outlook.com> References: <59E470B10C4630419ED717AC79FCF9A948D552B8@BY2PRD0411MB441.namprd04.prod.outlook.com> <4E1F6AAD24975D4BA5B168042967394367472284@TK5EX14MBXC284.redmond.corp.microsoft.com> <59E470B10C4630419ED717AC79FCF9A9568A83EA@BY2PRD0411MB441.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A9568A84A6@BY2PRD0411MB441.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A9568A8760@BY2PRD0411MB441.namprd04.prod.outlook.com> <51439320.9060401@gmail.com> In-Reply-To: <51439320.9060401@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [150.130.34.151] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%1294$Dn%GMAIL.COM$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn% X-FOPE-CONNECTOR: Id%1294$Dn%IETF.ORG$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn% X-CFilter-Loop: Reflected X-OriginatorOrg: motorolasolutions.com Subject: Re: [OAUTH-WG] JWT grant_type and client_id X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 21:44:08 -0000 Right ... thinking about this further I think the answer is "all of the abo= ve." If the JWT is a grant type then as you say it needs a scope param and= optionally a client_id param. I argued for the client_id param earlier si= nce it could assist with HOK scenarios once those further develop. But when the JWT is used as an AT then it will definitely require the scope= as a claim. So I change my argument to "both" :) adam -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of S= ergey Beryozkin Sent: Friday, March 15, 2013 4:31 PM To: oauth@ietf.org Subject: Re: [OAUTH-WG] JWT grant_type and client_id Hi On 15/03/13 20:40, Lewis Adam-CAL022 wrote: > Hi John, > > I would like to argue that the scope should be a parameter in the access > token request message, the same as it is for the RO creds grant and > client creds grant type. This would keep it consistent with the core > OAuth grant types that talk directly to the token endpoint. > Assuming the assertion is acting as a grant, then it is indeed an access=20 token request message, so IMHO it makes sense to get an outbound scope=20 parameter optionally supported which I guess will imply that the client=20 id will also have to accompany it... Cheers, Sergey > Thoughts? > > adam > > *From:*John Bradley [mailto:ve7jtb@ve7jtb.com] > *Sent:* Friday, March 15, 2013 12:10 PM > *To:* Lewis Adam-CAL022 > *Cc:* Brian Campbell; "WG "@il06exr02.mot.com > *Subject:* Re: [OAUTH-WG] JWT grant_type and client_id > > The spec is a touch vague on that. I think the scopes should be in the > assertion and the client can use the scopes outside the assertion to > down-scope. > > Having a standard claim in JWT and SAML for passing scopes is probably > useful as part of a profile. > > John B. > > On 2013-03-14, at 8:47 PM, Lewis Adam-CAL022 > > wrote: > > > > Hmmm, one more thought ... no scope?? The JWT is the grant, is it assumed > that the scope is conveyed as a claim within the token? Otherwise it > would seem that it would require a scope. > > Thoughts? > > adam > > *From:*Brian Campbell [mailto:bcampbell@pingidentity.com > ] > *Sent:*Thursday, March 14, 2013 4:44 PM > *To:*Lewis Adam-CAL022 > *Cc:*Mike Jones; "WG >"@il06exr02.mot.com > *Subject:*Re: [OAUTH-WG] JWT grant_type and client_id > > Yes, that is correct. > > I'm working on new revisions of the drafts that will hopefully make that > point more clear. > > On Thu, Mar 14, 2013 at 5:26 PM, Lewis Adam-CAL022 > > wrote: > > Coming back to this... am I correct in that client_id is not required? = We are implementing this spec and want to make sure that we are doing it = right. By my understanding the only two parameters that are required in = the JWT grant type are "urn:ietf:params:oauth:grant-type:jwt-bearer" an= d the assertion. Is this correct? > > *From:*Mike Jones [mailto:Michael.Jones@microsoft.com > ] > *Sent:*Monday, February 18, 2013 6:58 PM > *To:*Lewis Adam-CAL022;oauth@ietf.org WG > *Subject:*RE: JWT grant_type and client_id > > The client_id value and the access token value are independent. > > -- Mike > > *From:*oauth-bounces@ietf.org > [mailto:oauth-bounces@ietf.org > ]*On Behalf Of*Lewis Adam-CAL022 > *Sent:*Monday, February 18, 2013 2:50 PM > *To:*oauth@ietf.org WG > *Subject:*[OAUTH-WG] JWT grant_type and client_id > > Is there any guidance on the usage of client_id when using the JWT > assertion profile as a grant type? draft-ietf-oauth-jwt-bearer-04 makes > no mention so I assume that it is not required ... but it would be > necessary if using in conjunction with a HOK profile where the JWT > assertion is issued to - and may only be used by - the intended client. > Obviously this is straight forward enough, really I'm just looking to be > sure that I'm not missing anything. > > tx > > adam > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From bcampbell@pingidentity.com Fri Mar 15 15:13:29 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 55B8711E80D1 for ; Fri, 15 Mar 2013 15:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.556 X-Spam-Level: X-Spam-Status: No, score=-5.556 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_25=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 XZN8kU5Vy7gC for ; Fri, 15 Mar 2013 15:13:28 -0700 (PDT) Received: from na3sys009aog109.obsmtp.com (na3sys009aog109.obsmtp.com [74.125.149.201]) by ietfa.amsl.com (Postfix) with ESMTP id BA95B11E80A5 for ; Fri, 15 Mar 2013 15:13:27 -0700 (PDT) Received: from mail-ob0-f197.google.com ([209.85.214.197]) (using TLSv1) by na3sys009aob109.postini.com ([74.125.148.12]) with SMTP ID DSNKUUOdBi50kwHjuTR8IbwGXQp1nB8Lz1DR@postini.com; Fri, 15 Mar 2013 15:13:27 PDT Received: by mail-ob0-f197.google.com with SMTP id ta14so19412055obb.8 for ; Fri, 15 Mar 2013 15:13:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=4oUgNR9MBTSyjqKM3RAvZZtEh2O1fN401nDlGbooVho=; b=mlWMVbuJJtuVQNT6aoNUDMXXKV19wId3lc1bJdrzfrq5tZ/mLikm1ybbvvWFwFqN6w jI0xn3o6k9MmwuZFYkHncEpCJHXr1XYPDgosbDyPZU2ygyc2A/gXZ95Uzsixx5EVkSBg X1GduHnmIqw/fo6pE/ZSS3Nt1bQXaFeXoiT7J5G69joq1WyKaVGMrulr7OXef71a95o7 DBTn9h6TB97MZx7/T0aKPwR3yBchd6kP6gZkyUINMgSzMp313lpe2b5J9rzg7FyEekfX 2u+LugvViMj140oTHdnjm1q0Q8GX+Z1EXH52InCNpwoy1nJ3PFM2xjULf0hKvWUOH4PN 9MrA== X-Received: by 10.50.222.167 with SMTP id qn7mr2603020igc.42.1363385606034; Fri, 15 Mar 2013 15:13:26 -0700 (PDT) X-Received: by 10.50.222.167 with SMTP id qn7mr2603015igc.42.1363385605931; Fri, 15 Mar 2013 15:13:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.32.106 with HTTP; Fri, 15 Mar 2013 15:12:55 -0700 (PDT) In-Reply-To: <59E470B10C4630419ED717AC79FCF9A9568A87C1@BY2PRD0411MB441.namprd04.prod.outlook.com> References: <59E470B10C4630419ED717AC79FCF9A948D552B8@BY2PRD0411MB441.namprd04.prod.outlook.com> <4E1F6AAD24975D4BA5B168042967394367472284@TK5EX14MBXC284.redmond.corp.microsoft.com> <59E470B10C4630419ED717AC79FCF9A9568A83EA@BY2PRD0411MB441.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A9568A84A6@BY2PRD0411MB441.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A9568A8760@BY2PRD0411MB441.namprd04.prod.outlook.com> <51439320.9060401@gmail.com> <59E470B10C4630419ED717AC79FCF9A9568A87C1@BY2PRD0411MB441.namprd04.prod.outlook.com> From: Brian Campbell Date: Fri, 15 Mar 2013 16:12:55 -0600 Message-ID: To: Lewis Adam-CAL022 Content-Type: multipart/alternative; boundary=14dae9340f87bbe88004d7fdf260 X-Gm-Message-State: ALoCoQnk53P4r/Hj9hQwERuR26VkD9qyzsrV+bOL1Lrz/aKRG5spZK88sLa8eK146tGWigDtd8xZcJ9vpfXNYcQpxLPwiuSUCiR7ikH/14+9xS5K1/edRlo8DuvK+blHkVjoQuooHL3f Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] JWT grant_type and client_id X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 22:13:29 -0000 --14dae9340f87bbe88004d7fdf260 Content-Type: text/plain; charset=ISO-8859-1 So currently the base assertion document defines scope as an HTTP parameter on the access token request message when using an assertion as a grant[1]. And that applies to both the SAML and JWT grants (perhaps that needs to be more clear?). Also RFC 6749 defines the scope parameter for the client credentials access token request[2], which similarly applies to both SAML and JWT in the case of assertion client authentication using the "client_credentials" grant type. [1] http://tools.ietf.org/html/draft-ietf-oauth-assertions-10#section-4.1 [2] http://tools.ietf.org/html/rfc6749#section-4.4.1 On Fri, Mar 15, 2013 at 3:43 PM, Lewis Adam-CAL022 < Adam.Lewis@motorolasolutions.com> wrote: > Right ... thinking about this further I think the answer is "all of the > above." If the JWT is a grant type then as you say it needs a scope param > and optionally a client_id param. I argued for the client_id param earlier > since it could assist with HOK scenarios once those further develop. > > But when the JWT is used as an AT then it will definitely require the > scope as a claim. > > So I change my argument to "both" :) > > adam > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of > Sergey Beryozkin > Sent: Friday, March 15, 2013 4:31 PM > To: oauth@ietf.org > Subject: Re: [OAUTH-WG] JWT grant_type and client_id > > Hi > On 15/03/13 20:40, Lewis Adam-CAL022 wrote: > > Hi John, > > > > I would like to argue that the scope should be a parameter in the access > > token request message, the same as it is for the RO creds grant and > > client creds grant type. This would keep it consistent with the core > > OAuth grant types that talk directly to the token endpoint. > > > Assuming the assertion is acting as a grant, then it is indeed an access > token request message, so IMHO it makes sense to get an outbound scope > parameter optionally supported which I guess will imply that the client > id will also have to accompany it... > > Cheers, Sergey > > > Thoughts? > > > > adam > > > > *From:*John Bradley [mailto:ve7jtb@ve7jtb.com] > > *Sent:* Friday, March 15, 2013 12:10 PM > > *To:* Lewis Adam-CAL022 > > *Cc:* Brian Campbell; "WG "@il06exr02.mot.com > > *Subject:* Re: [OAUTH-WG] JWT grant_type and client_id > > > > The spec is a touch vague on that. I think the scopes should be in the > > assertion and the client can use the scopes outside the assertion to > > down-scope. > > > > Having a standard claim in JWT and SAML for passing scopes is probably > > useful as part of a profile. > > > > John B. > > > > On 2013-03-14, at 8:47 PM, Lewis Adam-CAL022 > > > > wrote: > > > > > > > > Hmmm, one more thought ... no scope?? The JWT is the grant, is it assumed > > that the scope is conveyed as a claim within the token? Otherwise it > > would seem that it would require a scope. > > > > Thoughts? > > > > adam > > > > *From:*Brian Campbell [mailto:bcampbell@pingidentity.com > > ] > > *Sent:*Thursday, March 14, 2013 4:44 PM > > *To:*Lewis Adam-CAL022 > > *Cc:*Mike Jones; "WG > >"@il06exr02.mot.com > > *Subject:*Re: [OAUTH-WG] JWT grant_type and client_id > > > > Yes, that is correct. > > > > I'm working on new revisions of the drafts that will hopefully make that > > point more clear. > > > > On Thu, Mar 14, 2013 at 5:26 PM, Lewis Adam-CAL022 > > > > wrote: > > > > Coming back to this... am I correct in that client_id is not required? > We are implementing this spec and want to make sure that we are doing it > right. By my understanding the only two parameters that are required in > the JWT grant type are "urn:ietf:params:oauth:grant-type:jwt-bearer" > and the assertion. Is this correct? > > > > *From:*Mike Jones [mailto:Michael.Jones@microsoft.com > > ] > > *Sent:*Monday, February 18, 2013 6:58 PM > > *To:*Lewis Adam-CAL022;oauth@ietf.org WG > > *Subject:*RE: JWT grant_type and client_id > > > > The client_id value and the access token value are independent. > > > > -- Mike > > > > *From:*oauth-bounces@ietf.org > > [mailto:oauth-bounces@ietf.org > > ]*On Behalf Of*Lewis Adam-CAL022 > > *Sent:*Monday, February 18, 2013 2:50 PM > > *To:*oauth@ietf.org WG > > *Subject:*[OAUTH-WG] JWT grant_type and client_id > > > > Is there any guidance on the usage of client_id when using the JWT > > assertion profile as a grant type? draft-ietf-oauth-jwt-bearer-04 makes > > no mention so I assume that it is not required ... but it would be > > necessary if using in conjunction with a HOK profile where the JWT > > assertion is issued to - and may only be used by - the intended client. > > Obviously this is straight forward enough, really I'm just looking to be > > sure that I'm not missing anything. > > > > tx > > > > adam > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --14dae9340f87bbe88004d7fdf260 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
So currently the base assertion document defines scope as = an HTTP parameter on the access token request message when using an asserti= on as a grant[1].=A0 And that applies to both the SAML and JWT grants (perh= aps that needs to be more clear?). Also RFC 6749 defines the scope paramete= r for the client credentials access token request[2], which similarly appli= es to both SAML and JWT in the case of assertion client authentication usin= g the "client_credentials" grant type.

[1] http://tools.ietf.org/html/draft-ietf-oauth-assertions-10#se= ction-4.1
[2] http://tools.ietf.org/html/rfc6749#section-4.4.1


On Fri,= Mar 15, 2013 at 3:43 PM, Lewis Adam-CAL022 <Adam.Lewis@m= otorolasolutions.com> wrote:
Right ... thinking about this further I thin= k the answer is "all of the above." =A0If the JWT is a grant type= then as you say it needs a scope param and optionally a client_id param. = =A0I argued for the client_id param earlier since it could assist with HOK = scenarios once those further develop.

But when the JWT is used as an AT then it will definitely require the scope= as a claim.

So I change my argument to "both" :)

adam

-----Original Message-----
From: oauth-bounces@ietf.org = [mailto:oauth-bounces@ietf.org] On Behalf Of Sergey Beryozkin
Sent: Friday, March 15, 2013 4:31 PM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] JWT grant_type and client_id

Hi
On 15/03/13 20:40, Lewis Adam-CAL022 wrote:
> Hi John,
>
> I would like to argue that the scope should be a parameter in the acce= ss
> token request message, the same as it is for the RO creds grant and > client creds grant type. This would keep it consistent with the core > OAuth grant types that talk directly to the token endpoint.
>
Assuming the assertion is acting as a grant, then it is indeed an access token request message, so IMHO it makes sense to get an outbound scope
parameter optionally supported which I guess will imply that the client
id will also have to accompany it...

Cheers, Sergey

> Thoughts?
>
> adam
>
> *From:*John Bradley [mailto:ve7jt= b@ve7jtb.com]
> *Sent:* Friday, March 15, 2013 12:10 PM
> *To:* Lewis Adam-CAL022
> *Cc:* Brian Campbell; "WG <o= auth@ietf.org>"@il06exr02.mot.com
> *Subject:* Re: [OAUTH-WG] JWT grant_type and client_id
>
> The spec is a touch vague on that. I think the scopes should be in the=
> assertion and the client can use the scopes outside the assertion to > down-scope.
>
> Having a standard claim in JWT and SAML for passing scopes is probably=
> useful as part of a profile.
>
> John B.
>
> On 2013-03-14, at 8:47 PM, Lewis Adam-CAL022
> <Adam.Lewis@mot= orolasolutions.com
> <mailto:Adam.Le= wis@motorolasolutions.com>> wrote:
>
>
>
> Hmmm, one more thought ... no scope?? The JWT is the grant= , is it assumed
> that the scope is conveyed as a claim within the tok= en? Otherwise it
> would seem that it would require a scope.
>
> Thoughts?
>
> adam
>
> *From:*Brian Campbell [mailto:bcampbell@pingidentity.com
> <http://pingi= dentity.com>]
> *Sent:*Thursday, March 14, 2013 4:44 PM
> *To:*Lewis Adam-CAL022
> *Cc:*Mike Jones; "WG <oauth@= ietf.org
> <mailto:oauth@ietf.org>>= ;"@il06exr02.mo= t.com <http:/= /il06exr02.mot.com>
> *Subject:*Re: [OAUTH-WG] JWT grant_type and client_id
>
> Yes, that is correct.
>
> I'm working on new revisions of the drafts that will hopefully mak= e that
> point more clear.
>
> On Thu, Mar 14, 2013 at 5:26 PM, Lewis Adam-CAL022
> <Adam.Lewis@mot= orolasolutions.com
> <mailto:Adam.Le= wis@motorolasolutions.com>> wrote:
>
> Coming back to this... =A0am I correct in that client_id is not = required? =A0 =A0We are implementing this spec and want to make sure that w= e are doing it right. =A0 =A0By my understanding the only two parameters th= at are required in the JWT grant type are =A0"urn:ietf:params:oauth:gr= ant-type:jwt-bearer" =A0 =A0and the assertion. =A0 =A0 =A0Is this corr= ect?
>
> *From:*Mike Jones [mailto:Michael.Jones@microsoft.com
> <mailto:Michael.Jone= s@microsoft.com>]
> *Sent:*Monday, February 18, 2013 6:58 PM
> *To:*Lewis Adam-CAL022= ;oauth@ietf.org <mailto:oauth@ietf= .org>WG
> *Subject:*RE: JWT grant_type and client_id
>
> The client_id value and the access token value are independent.
>
> -- Mike
>
> *From:*oauth-bounces@ietf.or= g
> <mailto:oauth-bounces@iet= f.org>[mailto:oauth-bounce= s@ietf.org
> <mailto:oauth-bounces@iet= f.org>]*On Behalf Of*Lewis Adam-CAL022
> *Sent:*Monday, February 18, 2013 2:50 PM
> *To:*oauth@ietf.org <mailto:<= a href=3D"mailto:oauth@ietf.org">oauth@ietf.org>WG
> *Subject:*[OAUTH-WG] JWT grant_type and client_id
>
> Is there any guidance on the usage of client_id when using the JWT
> assertion profile as a grant type? draft-ietf-oauth-jwt-bearer-04 make= s
> no mention so I assume that it is not required ... but it would = be
> necessary if using in conjunct= ion with a HOK profile where the JWT
> assertion is issued to - and may only be used by - the intended client= .
> Obviously this is straight forward enough, really I'm just looking= to be
> sure that I'm not missing anything.
>
> tx
>
> adam
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org <mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org <mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
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

--14dae9340f87bbe88004d7fdf260-- From bcampbell@pingidentity.com Fri Mar 15 15:16:42 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 6A63421F89A5 for ; Fri, 15 Mar 2013 15:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.526 X-Spam-Level: X-Spam-Status: No, score=-5.526 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_25=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 YDdR0YGhyVdy for ; Fri, 15 Mar 2013 15:16:41 -0700 (PDT) Received: from na3sys009aog135.obsmtp.com (na3sys009aog135.obsmtp.com [74.125.149.84]) by ietfa.amsl.com (Postfix) with ESMTP id D527021F8812 for ; Fri, 15 Mar 2013 15:16:40 -0700 (PDT) Received: from mail-ia0-f199.google.com ([209.85.210.199]) (using TLSv1) by na3sys009aob135.postini.com ([74.125.148.12]) with SMTP ID DSNKUUOduofslFOT5R6b8hNfz0v6/Mqnnfm0@postini.com; Fri, 15 Mar 2013 15:16:40 PDT Received: by mail-ia0-f199.google.com with SMTP id o25so4594521iad.2 for ; Fri, 15 Mar 2013 15:16:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=SEIWtWjX6sL1foXrQhRi+LZIHIqrQ8ZsMzsnarPwMJY=; b=XRnb/vPMMzwjFaQ/7bkGs5DhSLfgJgvds4aBR0lGywUH8ZJC1UjZVdF12nasfSsfUF DJnIcs9likJtR+HW2pxcy6ZFxtgfvIbBgJk+Cnj7biNG2HR5rz+00kEoFwbVdSIXaDIm tpugFvH3vG/SHGmNFw468fhLXn6e6vZ1Tw7WCvpplFSc6A12G0wnBD8h5OeZtIXYFnq1 MvUJSaKQOp24RszrbkUwHGdSugoQyaTiGQ8rue267Mlqd8AYv2WzG+JqbVuj2UvkrLSl ivEcL9/J+4BRMC6p/VU67dimqoSognWbmnVwtQXs+1xMi4YJarZRkRVj+rbQ6sxsU65f Nbag== X-Received: by 10.50.222.167 with SMTP id qn7mr2606380igc.42.1363385786457; Fri, 15 Mar 2013 15:16:26 -0700 (PDT) X-Received: by 10.50.222.167 with SMTP id qn7mr2606376igc.42.1363385786356; Fri, 15 Mar 2013 15:16:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.32.106 with HTTP; Fri, 15 Mar 2013 15:15:56 -0700 (PDT) In-Reply-To: References: <59E470B10C4630419ED717AC79FCF9A948D552B8@BY2PRD0411MB441.namprd04.prod.outlook.com> <4E1F6AAD24975D4BA5B168042967394367472284@TK5EX14MBXC284.redmond.corp.microsoft.com> <59E470B10C4630419ED717AC79FCF9A9568A83EA@BY2PRD0411MB441.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A9568A84A6@BY2PRD0411MB441.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A9568A8760@BY2PRD0411MB441.namprd04.prod.outlook.com> <51439320.9060401@gmail.com> <59E470B10C4630419ED717AC79FCF9A9568A87C1@BY2PRD0411MB441.namprd04.prod.outlook.com> From: Brian Campbell Date: Fri, 15 Mar 2013 16:15:56 -0600 Message-ID: To: Lewis Adam-CAL022 Content-Type: multipart/alternative; boundary=14dae9340f877cdbc904d7fdfdd3 X-Gm-Message-State: ALoCoQnxX24+HbKcAz8P5CDIk1UrSGTPU7JM9NWYZGtbb0w8DTNNl3eSj5CRsWOq8NZKVnYcM2AeGAT6mK8WDSL0euQXFycqtmIXy/Ld3cXL6DjgCZUZPMrB19dwIuRFVEwGsF6pD4Zf Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] JWT grant_type and client_id X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 22:16:42 -0000 --14dae9340f877cdbc904d7fdfdd3 Content-Type: text/plain; charset=ISO-8859-1 Codifying a claim/attribute for scope that goes in the assertion is something that's been discussed but never seemed to get sufficient consensus regarding how to exactly to do it and if it really provided much value. On Fri, Mar 15, 2013 at 4:12 PM, Brian Campbell wrote: > So currently the base assertion document defines scope as an HTTP > parameter on the access token request message when using an assertion as a > grant[1]. And that applies to both the SAML and JWT grants (perhaps that > needs to be more clear?). Also RFC 6749 defines the scope parameter for the > client credentials access token request[2], which similarly applies to both > SAML and JWT in the case of assertion client authentication using the > "client_credentials" grant type. > > [1] http://tools.ietf.org/html/draft-ietf-oauth-assertions-10#section-4.1 > [2] http://tools.ietf.org/html/rfc6749#section-4.4.1 > > > On Fri, Mar 15, 2013 at 3:43 PM, Lewis Adam-CAL022 < > Adam.Lewis@motorolasolutions.com> wrote: > >> Right ... thinking about this further I think the answer is "all of the >> above." If the JWT is a grant type then as you say it needs a scope param >> and optionally a client_id param. I argued for the client_id param earlier >> since it could assist with HOK scenarios once those further develop. >> >> But when the JWT is used as an AT then it will definitely require the >> scope as a claim. >> >> So I change my argument to "both" :) >> >> adam >> >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Sergey Beryozkin >> Sent: Friday, March 15, 2013 4:31 PM >> To: oauth@ietf.org >> Subject: Re: [OAUTH-WG] JWT grant_type and client_id >> >> Hi >> On 15/03/13 20:40, Lewis Adam-CAL022 wrote: >> > Hi John, >> > >> > I would like to argue that the scope should be a parameter in the access >> > token request message, the same as it is for the RO creds grant and >> > client creds grant type. This would keep it consistent with the core >> > OAuth grant types that talk directly to the token endpoint. >> > >> Assuming the assertion is acting as a grant, then it is indeed an access >> token request message, so IMHO it makes sense to get an outbound scope >> parameter optionally supported which I guess will imply that the client >> id will also have to accompany it... >> >> Cheers, Sergey >> >> > Thoughts? >> > >> > adam >> > >> > *From:*John Bradley [mailto:ve7jtb@ve7jtb.com] >> > *Sent:* Friday, March 15, 2013 12:10 PM >> > *To:* Lewis Adam-CAL022 >> > *Cc:* Brian Campbell; "WG "@il06exr02.mot.com >> > *Subject:* Re: [OAUTH-WG] JWT grant_type and client_id >> > >> > The spec is a touch vague on that. I think the scopes should be in the >> > assertion and the client can use the scopes outside the assertion to >> > down-scope. >> > >> > Having a standard claim in JWT and SAML for passing scopes is probably >> > useful as part of a profile. >> > >> > John B. >> > >> > On 2013-03-14, at 8:47 PM, Lewis Adam-CAL022 >> > > > > wrote: >> > >> > >> > >> > Hmmm, one more thought ... no scope?? The JWT is the grant, is it >> assumed >> > that the scope is conveyed as a claim within the token? Otherwise it >> > would seem that it would require a scope. >> > >> > Thoughts? >> > >> > adam >> > >> > *From:*Brian Campbell [mailto:bcampbell@pingidentity.com >> > ] >> > *Sent:*Thursday, March 14, 2013 4:44 PM >> > *To:*Lewis Adam-CAL022 >> > *Cc:*Mike Jones; "WG > > >"@il06exr02.mot.com >> > *Subject:*Re: [OAUTH-WG] JWT grant_type and client_id >> > >> > Yes, that is correct. >> > >> > I'm working on new revisions of the drafts that will hopefully make that >> > point more clear. >> > >> > On Thu, Mar 14, 2013 at 5:26 PM, Lewis Adam-CAL022 >> > > > > wrote: >> > >> > Coming back to this... am I correct in that client_id is not required? >> We are implementing this spec and want to make sure that we are doing it >> right. By my understanding the only two parameters that are required in >> the JWT grant type are "urn:ietf:params:oauth:grant-type:jwt-bearer" >> and the assertion. Is this correct? >> > >> > *From:*Mike Jones [mailto:Michael.Jones@microsoft.com >> > ] >> > *Sent:*Monday, February 18, 2013 6:58 PM >> > *To:*Lewis Adam-CAL022;oauth@ietf.org WG >> > *Subject:*RE: JWT grant_type and client_id >> > >> > The client_id value and the access token value are independent. >> > >> > -- Mike >> > >> > *From:*oauth-bounces@ietf.org >> > [mailto:oauth-bounces@ietf.org >> > ]*On Behalf Of*Lewis Adam-CAL022 >> > *Sent:*Monday, February 18, 2013 2:50 PM >> > *To:*oauth@ietf.org WG >> > *Subject:*[OAUTH-WG] JWT grant_type and client_id >> > >> > Is there any guidance on the usage of client_id when using the JWT >> > assertion profile as a grant type? draft-ietf-oauth-jwt-bearer-04 makes >> > no mention so I assume that it is not required ... but it would be >> > necessary if using in conjunction with a HOK profile where the JWT >> > assertion is issued to - and may only be used by - the intended client. >> > Obviously this is straight forward enough, really I'm just looking to be >> > sure that I'm not missing anything. >> > >> > tx >> > >> > adam >> > >> > >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/oauth >> > >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/oauth >> > >> > >> > >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > --14dae9340f877cdbc904d7fdfdd3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Codifying a claim/attribute for scope that goes in the ass= ertion is something that's been discussed but never seemed to get suffi= cient consensus regarding how to exactly to do it and if it really provided= much value.


On Fri,= Mar 15, 2013 at 4:12 PM, Brian Campbell <bcampbell@pingidentity.= com> wrote:
So currently the base asser= tion document defines scope as an HTTP parameter on the access token reques= t message when using an assertion as a grant[1].=A0 And that applies to bot= h the SAML and JWT grants (perhaps that needs to be more clear?). Also RFC = 6749 defines the scope parameter for the client credentials access token re= quest[2], which similarly applies to both SAML and JWT in the case of asser= tion client authentication using the "client_credentials" grant t= ype.

[1] http://tools.ietf.org/html/draft-ietf-oaut= h-assertions-10#section-4.1
[2] http://tools.ietf.org/html/rfc6= 749#section-4.4.1

On Fri, Mar 15, 2013 at 3:43 PM, Lewis Ada= m-CAL022 <Adam.Lewis@motorolasolutions.com> w= rote:
Right ... thinking about this further I thin= k the answer is "all of the above." =A0If the JWT is a grant type= then as you say it needs a scope param and optionally a client_id param. = =A0I argued for the client_id param earlier since it could assist with HOK = scenarios once those further develop.

But when the JWT is used as an AT then it will definitely require the scope= as a claim.

So I change my argument to "both" :)

adam

-----Original Message-----
From: oauth-bou= nces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Sergey Beryozkin
Sent: Friday, March 15, 2013 4:31 PM
To: oauth@ietf.org<= br> Subject: Re: [OAUTH-WG] JWT grant_type and client_id

Hi
On 15/03/13 20:40, Lewis Adam-CAL022 wrote:
> Hi John,
>
> I would like to argue that the scope should be a parameter in the acce= ss
> token request message, the same as it is for the RO creds grant and > client creds grant type. This would keep it consistent with the core > OAuth grant types that talk directly to the token endpoint.
>
Assuming the assertion is acting as a grant, then it is indeed an access token request message, so IMHO it makes sense to get an outbound scope
parameter optionally supported which I guess will imply that the client
id will also have to accompany it...

Cheers, Sergey

> Thoughts?
>
> adam
>
> *From:*John Bradley [mailto:ve7jtb@ve7jtb.com]
> *Sent:* Friday, March 15, 2013 12:10 PM
> *To:* Lewis Adam-CAL022
> *Cc:* Brian Campbell; "WG <oauth@ietf.org>"@il06exr02.mot.com
> *Subject:* Re: [OAUTH-WG] JWT grant_type and client_id
>
> The spec is a touch vague on that. I think the scopes should be in the=
> assertion and the client can use the scopes outside the assertion to > down-scope.
>
> Having a standard claim in JWT and SAML for passing scopes is probably=
> useful as part of a profile.
>
> John B.
>
> On 2013-03-14, at 8:47 PM, Lewis Adam-CAL022
> <Adam.Lewis@motorolasolutions.com
> <mailto:Adam.Lewis@motorolasolutions.com>> wrote:
>
>
>
> Hmmm, one more thought ... no scope?? The JWT is the grant= , is it assumed
> that the scope is conveyed as a claim within the token? Otherwise= it
> would seem that it would require a scope.
>
> Thoughts?
>
> adam
>
> *From:*Brian Campbell [mailto:bcampbell@pingidentity.com
> <http://pingi= dentity.com>]
> *Sent:*Thursday, March 14, 2013 4:44 PM
> *To:*Lewis Adam-CAL022
> *Cc:*Mike Jones; "WG <oauth@ietf.org
> <mailto:oauth@i= etf.org>>"@il06exr02.mot.com <http://il06exr02.mot.com>
> *Subject:*Re: [OAUTH-WG] JWT grant_type and client_id
>
> Yes, that is correct.
>
> I'm working on new revisions of the drafts that will hopefully mak= e that
> point more clear.
>
> On Thu, Mar 14, 2013 at 5:26 PM, Lewis Adam-CAL022
> <Adam.Lewis@motorolasolutions.com
> <mailto:Adam.Lewis@motorolasolutions.com>> wrote:
>
> Coming back to this... =A0am I correct in that client_id is not = required? =A0 =A0We are implementing this spec and want to make sure that w= e are doing it right. =A0 =A0By my understanding the only two parameters th= at are required in the JWT grant type are =A0"urn:ietf:params:oauth:gr= ant-type:jwt-bearer" =A0 =A0and the assertion. =A0 =A0 =A0Is this corr= ect?
>
> *From:*Mike Jones [mailto:Michael.Jones@microsoft.com
> <mailto:Michael.Jones@microsoft.com>]
> *Sent:*Monday, February 18, 2013 6:58 PM
> *To:*Lewis Adam-CAL022;oauth@ietf.org <mailto:oauth@ietf.org>WG
> *Subject:*RE: JWT grant_type and client_id
>
> The client_id value and the access token value are independent.
>
> -- Mike
>
> *From:*oau= th-bounces@ietf.org
> <mailto:oauth-bounces@ietf.org>[mailto:oauth-bounces@ietf.org
> <mailto:oauth-bounces@ietf.org>]*On Behalf Of*Lewis Adam-CAL022
> *Sent:*Monday, February 18, 2013 2:50 PM
> *To:*oauth@ietf.or= g <mailto:oauth@= ietf.org>WG
> *Subject:*[OAUTH-WG] JWT grant_type and client_id
>
> Is there any guidance on the usage of client_id when using the JWT
> assertion profile as a grant type? draft-ietf-oauth-jwt-bearer-04 make= s
> no mention so I assume that it is not required ... but it would = be
> necessary if using in conjunction with a HOK profile where t= he JWT
> assertion is issued to - and may only be used by - the intended client= .
> Obviously this is straight forward enough, really I'm just looking= to be
> sure that I'm not missing anything.
>
> tx
>
> adam
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org= <mailto:OAuth@ietf.= org>
> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org= <mailto:OAuth@ietf.= org>
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
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


--14dae9340f877cdbc904d7fdfdd3-- From Adam.Lewis@motorolasolutions.com Fri Mar 15 15:51:29 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 C036021F8936 for ; Fri, 15 Mar 2013 15:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.159 X-Spam-Level: X-Spam-Status: No, score=0.159 tagged_above=-999 required=5 tests=[AWL=-0.975, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_25=0.6, 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 Ne7tXtOpQtah for ; Fri, 15 Mar 2013 15:51:26 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0185.outbound.messaging.microsoft.com [213.199.154.185]) by ietfa.amsl.com (Postfix) with ESMTP id A404521F8920 for ; Fri, 15 Mar 2013 15:51:25 -0700 (PDT) Received: from mail190-db8-R.bigfish.com (10.174.8.231) by DB8EHSOBE029.bigfish.com (10.174.4.92) with Microsoft SMTP Server id 14.1.225.23; Fri, 15 Mar 2013 22:51:22 +0000 Received: from mail190-db8 (localhost [127.0.0.1]) by mail190-db8-R.bigfish.com (Postfix) with ESMTP id A79818E0227 for ; Fri, 15 Mar 2013 22:51:22 +0000 (UTC) X-Forefront-Antispam-Report: CIP:192.160.210.20; KIP:(null); UIP:(null); IPV:NLI; H:ct11msg01.am.mot-solutions.com; RD:ct11msg01.mot-solutions.com; EFVD:NLI X-SpamScore: -32 X-BigFish: VPS-32(zzbb2dI98dI9371I936eIc85fh542I1432I179dNzz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz18de19h1033IL17326ah8275dh18c673h1954cbh8275bhz2fh2a8h683h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1b0ah1155h) Received-SPF: pass (mail190-db8: domain of motorolasolutions.com designates 192.160.210.20 as permitted sender) client-ip=192.160.210.20; envelope-from=Adam.Lewis@motorolasolutions.com; helo=ct11msg01.am.mot-solutions.com ; olutions.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.237.133; KIP:(null); UIP:(null); (null); H:BY2PRD0411HT003.namprd04.prod.outlook.com; R:internal; EFV:INT Received: from mail190-db8 (localhost.localdomain [127.0.0.1]) by mail190-db8 (MessageSwitch) id 1363387855278282_13614; Fri, 15 Mar 2013 22:50:55 +0000 (UTC) Received: from DB8EHSMHS009.bigfish.com (unknown [10.174.8.244]) by mail190-db8.bigfish.com (Postfix) with ESMTP id 41ECF4600CC for ; Fri, 15 Mar 2013 22:50:55 +0000 (UTC) Received: from ct11msg01.am.mot-solutions.com (192.160.210.20) by DB8EHSMHS009.bigfish.com (10.174.4.19) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 15 Mar 2013 22:50:53 +0000 Received: from ct11msg01.am.mot-solutions.com (ct11vts03.am.mot.com [10.177.16.162]) by ct11msg01.am.mot-solutions.com (8.14.3/8.14.3) with ESMTP id r2FMoOaV015800 for ; Fri, 15 Mar 2013 17:50:24 -0500 (CDT) Received: from DB8EHSOBE021.bigfish.com (mail-db8lp0184.outbound.messaging.microsoft.com [213.199.154.184]) by ct11msg01.am.mot-solutions.com (8.14.3/8.14.3) with ESMTP id r2FMoN2g015794 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 15 Mar 2013 17:50:23 -0500 (CDT) Received: from mail23-db8-R.bigfish.com (10.174.8.225) by DB8EHSOBE021.bigfish.com (10.174.4.84) with Microsoft SMTP Server id 14.1.225.23; Fri, 15 Mar 2013 22:50:50 +0000 Received: from mail23-db8 (localhost [127.0.0.1]) by mail23-db8-R.bigfish.com (Postfix) with ESMTP id 9D060C00173 for ; Fri, 15 Mar 2013 22:50:50 +0000 (UTC) Received: from mail23-db8 (localhost.localdomain [127.0.0.1]) by mail23-db8 (MessageSwitch) id 1363387841218845_5725; Fri, 15 Mar 2013 22:50:41 +0000 (UTC) Received: from DB8EHSMHS010.bigfish.com (unknown [10.174.8.232]) by mail23-db8.bigfish.com (Postfix) with ESMTP id 2F6BE380048; Fri, 15 Mar 2013 22:50:41 +0000 (UTC) Received: from BY2PRD0411HT003.namprd04.prod.outlook.com (157.56.237.133) by DB8EHSMHS010.bigfish.com (10.174.4.20) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 15 Mar 2013 22:50:40 +0000 Received: from BY2PRD0411MB441.namprd04.prod.outlook.com ([169.254.5.31]) by BY2PRD0411HT003.namprd04.prod.outlook.com ([10.255.128.38]) with mapi id 14.16.0275.006; Fri, 15 Mar 2013 22:50:36 +0000 From: Lewis Adam-CAL022 To: Brian Campbell Thread-Topic: [OAUTH-WG] JWT grant_type and client_id Thread-Index: AQHOIcpbWGop5BX/OECnwHSB/syrP5inWuyA Date: Fri, 15 Mar 2013 22:50:35 +0000 Message-ID: <59E470B10C4630419ED717AC79FCF9A9568A984C@BY2PRD0411MB441.namprd04.prod.outlook.com> References: <59E470B10C4630419ED717AC79FCF9A948D552B8@BY2PRD0411MB441.namprd04.prod.outlook.com> <4E1F6AAD24975D4BA5B168042967394367472284@TK5EX14MBXC284.redmond.corp.microsoft.com> <59E470B10C4630419ED717AC79FCF9A9568A83EA@BY2PRD0411MB441.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A9568A84A6@BY2PRD0411MB441.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A9568A8760@BY2PRD0411MB441.namprd04.prod.outlook.com> <51439320.9060401@gmail.com> <59E470B10C4630419ED717AC79FCF9A9568A87C1@BY2PRD0411MB441.namprd04.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [150.130.161.105] Content-Type: multipart/alternative; boundary="_000_59E470B10C4630419ED717AC79FCF9A9568A984CBY2PRD0411MB441_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%1294$Dn%PINGIDENTITY.COM$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn% X-FOPE-CONNECTOR: Id%1294$Dn%GMAIL.COM$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn% X-FOPE-CONNECTOR: Id%1294$Dn%IETF.ORG$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn% X-CFilter-Loop: Reflected X-OriginatorOrg: motorolasolutions.com Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] JWT grant_type and client_id X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 22:51:29 -0000 --_000_59E470B10C4630419ED717AC79FCF9A9568A984CBY2PRD0411MB441_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yeah ... I forgot about that. I remember figuring that out at one point an= d then I guess I lost it. So right, my vote would be to make it more clear= , either by repeating the full list of params (my vote) or by at least maki= ng a reference. It would be nice to be able to read the JWT or SAML profil= es as a self-contained doc. adam From: Brian Campbell [mailto:bcampbell@pingidentity.com] Sent: Friday, March 15, 2013 5:13 PM To: Lewis Adam-CAL022 Cc: Sergey Beryozkin; oauth@ietf.org Subject: Re: [OAUTH-WG] JWT grant_type and client_id So currently the base assertion document defines scope as an HTTP parameter= on the access token request message when using an assertion as a grant[1].= And that applies to both the SAML and JWT grants (perhaps that needs to b= e more clear?). Also RFC 6749 defines the scope parameter for the client cr= edentials access token request[2], which similarly applies to both SAML and= JWT in the case of assertion client authentication using the "client_crede= ntials" grant type. [1] http://tools.ietf.org/html/draft-ietf-oauth-assertions-10#section-4.1 [2] http://tools.ietf.org/html/rfc6749#section-4.4.1 On Fri, Mar 15, 2013 at 3:43 PM, Lewis Adam-CAL022 > wrote: Right ... thinking about this further I think the answer is "all of the abo= ve." If the JWT is a grant type then as you say it needs a scope param and= optionally a client_id param. I argued for the client_id param earlier si= nce it could assist with HOK scenarios once those further develop. But when the JWT is used as an AT then it will definitely require the scope= as a claim. So I change my argument to "both" :) adam -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Sergey Beryozk= in Sent: Friday, March 15, 2013 4:31 PM To: oauth@ietf.org Subject: Re: [OAUTH-WG] JWT grant_type and client_id Hi On 15/03/13 20:40, Lewis Adam-CAL022 wrote: > Hi John, > > I would like to argue that the scope should be a parameter in the access > token request message, the same as it is for the RO creds grant and > client creds grant type. This would keep it consistent with the core > OAuth grant types that talk directly to the token endpoint. > Assuming the assertion is acting as a grant, then it is indeed an access token request message, so IMHO it makes sense to get an outbound scope parameter optionally supported which I guess will imply that the client id will also have to accompany it... Cheers, Sergey > Thoughts? > > adam > > *From:*John Bradley [mailto:ve7jtb@ve7jtb.com] > *Sent:* Friday, March 15, 2013 12:10 PM > *To:* Lewis Adam-CAL022 > *Cc:* Brian Campbell; "WG >"@il06ex= r02.mot.com > *Subject:* Re: [OAUTH-WG] JWT grant_type and client_id > > The spec is a touch vague on that. I think the scopes should be in the > assertion and the client can use the scopes outside the assertion to > down-scope. > > Having a standard claim in JWT and SAML for passing scopes is probably > useful as part of a profile. > > John B. > > On 2013-03-14, at 8:47 PM, Lewis Adam-CAL022 > > >> wrote: > > > > Hmmm, one more thought ... no scope?? The JWT is the grant, is it assumed > that the scope is conveyed as a claim within the token? Otherwise it > would seem that it would require a scope. > > Thoughts? > > adam > > *From:*Brian Campbell [mailto:bcampbell@pingidentity.com > ] > *Sent:*Thursday, March 14, 2013 4:44 PM > *To:*Lewis Adam-CAL022 > *Cc:*Mike Jones; "WG > >>"@il06exr02.mot.com > *Subject:*Re: [OAUTH-WG] JWT grant_type and client_id > > Yes, that is correct. > > I'm working on new revisions of the drafts that will hopefully make that > point more clear. > > On Thu, Mar 14, 2013 at 5:26 PM, Lewis Adam-CAL022 > > >> wrote: > > Coming back to this... am I correct in that client_id is not required? = We are implementing this spec and want to make sure that we are doing it = right. By my understanding the only two parameters that are required in = the JWT grant type are "urn:ietf:params:oauth:grant-type:jwt-bearer" an= d the assertion. Is this correct? > > *From:*Mike Jones [mailto:Michael.Jones@microsoft.com > >] > *Sent:*Monday, February 18, 2013 6:58 PM > *To:*Lewis Adam-CAL022;oauth@ietf.org >WG > *Subject:*RE: JWT grant_type and client_id > > The client_id value and the access token value are independent. > > -- Mike > > *From:*oauth-bounces@ietf.org > >[mailto:oau= th-bounces@ietf.org > >]*On Behalf= Of*Lewis Adam-CAL022 > *Sent:*Monday, February 18, 2013 2:50 PM > *To:*oauth@ietf.org >WG > *Subject:*[OAUTH-WG] JWT grant_type and client_id > > Is there any guidance on the usage of client_id when using the JWT > assertion profile as a grant type? draft-ietf-oauth-jwt-bearer-04 makes > no mention so I assume that it is not required ... but it would be > necessary if using in conjunction with a HOK profile where the JWT > assertion is issued to - and may only be used by - the intended client. > Obviously this is straight forward enough, really I'm just looking to be > sure that I'm not missing anything. > > tx > > adam > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_59E470B10C4630419ED717AC79FCF9A9568A984CBY2PRD0411MB441_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yeah … I forgot abo= ut that.  I remember figuring that out at one point and then I guess I= lost it.  So right, my vote would be to make it more clear, either by repeating the full list of params (my vote) or by at least making a ref= erence.  It would be nice to be able to read the JWT or SAML profiles = as a self-contained doc. 

 <= /p>

adam

 <= /p>

From: Brian Ca= mpbell [mailto:bcampbell@pingidentity.com]
Sent: Friday, March 15, 2013 5:13 PM
To: Lewis Adam-CAL022
Cc: Sergey Beryozkin; oauth@ietf.org
Subject: Re: [OAUTH-WG] JWT grant_type and client_id

 

So currently the base assertion document defines sco= pe as an HTTP parameter on the access token request message when using an a= ssertion as a grant[1].  And that applies to both the SAML and JWT gra= nts (perhaps that needs to be more clear?). Also RFC 6749 defines the scope parameter for the client credentials acces= s token request[2], which similarly applies to both SAML and JWT in the cas= e of assertion client authentication using the "client_credentials&quo= t; grant type.

[1] http://tools.ietf.org/html/draft-ietf-oauth-assertions-10#section-4.1 <= br> [2] http://too= ls.ietf.org/html/rfc6749#section-4.4.1

 

On Fri, Mar 15, 2013 at 3:43 PM, Lewis Adam-CAL022 &= lt;Ad= am.Lewis@motorolasolutions.com> wrote:

Right ... thinking about this further I think the an= swer is "all of the above."  If the JWT is a grant type then= as you say it needs a scope param and optionally a client_id param.  = I argued for the client_id param earlier since it could assist with HOK scenarios once those further develop.

But when the JWT is used as an AT then it will definitely require the scope= as a claim.

So I change my argument to "both" :)

adam


-----Original Message-----
From: oauth-bounces@ietf.org = [mailto:oauth-bounces@ietf.org] On Behalf Of Sergey Beryozkin
Sent: Friday, March 15, 2013 4:31 PM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] JWT grant_type and client_id

Hi
On 15/03/13 20:40, Lewis Adam-CAL022 wrote:
> Hi John,
>
> I would like to argue that the scope should be a parameter in the acce= ss
> token request message, the same as it is for the RO creds grant and > client creds grant type. This would keep it consistent with the core > OAuth grant types that talk directly to the token endpoint.
>
Assuming the assertion is acting as a grant, then it is indeed an access token request message, so IMHO it makes sense to get an outbound scope
parameter optionally supported which I guess will imply that the client
id will also have to accompany it...

Cheers, Sergey

> Thoughts?
>
> adam
>
> *From:*John Bradley [mailto:ve7jt= b@ve7jtb.com]
> *Sent:* Friday, March 15, 2013 12:10 PM
> *To:* Lewis Adam-CAL022
> *Cc:* Brian Campbell; "WG <o= auth@ietf.org>"@il06exr02.mot.com
> *Subject:* Re: [OAUTH-WG] JWT grant_type and client_id
>
> The spec is a touch vague on that. I think the scopes should be in the=
> assertion and the client can use the scopes outside the assertion to > down-scope.
>
> Having a standard claim in JWT and SAML for passing scopes is probably=
> useful as part of a profile.
>
> John B.
>
> On 2013-03-14, at 8:47 PM, Lewis Adam-CAL022
> <Adam.Lewis@mot= orolasolutions.com
> <mailto:Adam.Le= wis@motorolasolutions.com>> wrote:
>
>
>

> Hmmm, one more thought ... no scope?? The JWT i= s the grant, is it assumed

> that the scope is conveyed as a claim within th= e token? Otherwise it
> would seem that it would require a scope.
>
> Thoughts?
>
> adam
>
> *From:*Brian Campbell [mailto:bcampbell@pingidentity.com
> <http://pingi= dentity.com>]
> *Sent:*Thursday, March 14, 2013 4:44 PM
> *To:*Lewis Adam-CAL022
> *Cc:*Mike Jones; "WG <oauth@= ietf.org
> <mailto:oauth@ietf.org>>= ;"@il06exr02.mo= t.com <http:/= /il06exr02.mot.com>
> *Subject:*Re: [OAUTH-WG] JWT grant_type and client_id
>
> Yes, that is correct.
>
> I'm working on new revisions of the drafts that will hopefully make th= at
> point more clear.
>
> On Thu, Mar 14, 2013 at 5:26 PM, Lewis Adam-CAL022
> <Adam.Lewis@mot= orolasolutions.com
> <mailto:Adam.Le= wis@motorolasolutions.com>> wrote:
>

> Coming back to this...  am I correct in th= at client_id is not required?    We are implementing this spec an= d want to make sure that we are doing it right.    By my understa= nding the only two parameters that are required in the JWT grant type are  "urn:ietf:params:oauth:grant-type:jwt-bearer" &nb= sp;  and the assertion.      Is this correct?

>
> *From:*Mike Jones [mailto:Michael.Jones@microsoft.com
> <mailto:Michael.Jone= s@microsoft.com>]
> *Sent:*Monday, February 18, 2013 6:58 PM
> *To:*Lewis Adam-CAL022= ;oauth@ietf.org <mailto:oauth@ietf= .org>WG
> *Subject:*RE: JWT grant_type and client_id
>
> The client_id value and the access token value are independent.
>
> -- Mike
>
> *From:*oauth-bounces@ietf.or= g
> <mailto:oauth-bounces@iet= f.org>[mailto:oauth-bounce= s@ietf.org
> <mailto:oauth-bounces@iet= f.org>]*On Behalf Of*Lewis Adam-CAL022
> *Sent:*Monday, February 18, 2013 2:50 PM
> *To:*oauth@ietf.org <mailto:<= a href=3D"mailto:oauth@ietf.org">oauth@ietf.org>WG
> *Subject:*[OAUTH-WG] JWT grant_type and client_id
>
> Is there any guidance on the usage of client_id when using the JWT
> assertion profile as a grant type? draft-ietf-oauth-jwt-bearer-04 make= s

> no mention so I assume that it is not required = ... but it would be

> necessary if using in conjunction with a HOK pr= ofile where the JWT
> assertion is issued to - and may only be used by - the intended client= .
> Obviously this is straight forward enough, really I'm just looking to = be
> sure that I'm not missing anything.
>
> tx
>
> adam
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org <mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org <mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

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





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

 

--_000_59E470B10C4630419ED717AC79FCF9A9568A984CBY2PRD0411MB441_-- From Adam.Lewis@motorolasolutions.com Fri Mar 15 15:55: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 F3EAC11E80ED for ; Fri, 15 Mar 2013 15:54:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.146 X-Spam-Level: X-Spam-Status: No, score=-0.146 tagged_above=-999 required=5 tests=[AWL=-0.280, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_25=0.6, RCVD_IN_DNSWL_LOW=-1, 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 w8IG0SP6QhAQ for ; Fri, 15 Mar 2013 15:54:54 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe005.messaging.microsoft.com [216.32.180.188]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5F011E80F6 for ; Fri, 15 Mar 2013 15:54:53 -0700 (PDT) Received: from mail33-co1-R.bigfish.com (10.243.78.238) by CO1EHSOBE017.bigfish.com (10.243.66.80) with Microsoft SMTP Server id 14.1.225.23; Fri, 15 Mar 2013 22:54:53 +0000 Received: from mail33-co1 (localhost [127.0.0.1]) by mail33-co1-R.bigfish.com (Postfix) with ESMTP id 55D044000F1 for ; Fri, 15 Mar 2013 22:54:53 +0000 (UTC) X-Forefront-Antispam-Report: CIP:192.160.210.14; KIP:(null); UIP:(null); IPV:NLI; H:ct11msg02.am.mot-solutions.com; RD:ct11msg02.mot-solutions.com; EFVD:NLI X-SpamScore: -37 X-BigFish: VPS-37(zzbb2dI98dI9371I936eIc85fh1441M542I1432I179dNzz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz18de19h1033IL17326ah8275dh18c673h1954cbh8275bhz2fh2a8h683h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1b0ah1155h) Received-SPF: pass (mail33-co1: domain of motorolasolutions.com designates 192.160.210.14 as permitted sender) client-ip=192.160.210.14; envelope-from=Adam.Lewis@motorolasolutions.com; helo=ct11msg02.am.mot-solutions.com ; olutions.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.237.133; KIP:(null); UIP:(null); (null); H:BY2PRD0411HT005.namprd04.prod.outlook.com; R:internal; EFV:INT Received: from mail33-co1 (localhost.localdomain [127.0.0.1]) by mail33-co1 (MessageSwitch) id 1363388089708804_28539; Fri, 15 Mar 2013 22:54:49 +0000 (UTC) Received: from CO1EHSMHS006.bigfish.com (unknown [10.243.78.245]) by mail33-co1.bigfish.com (Postfix) with ESMTP id A9CF350006B for ; Fri, 15 Mar 2013 22:54:49 +0000 (UTC) Received: from ct11msg02.am.mot-solutions.com (192.160.210.14) by CO1EHSMHS006.bigfish.com (10.243.66.16) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 15 Mar 2013 22:54:49 +0000 Received: from ct11msg02.am.mot-solutions.com (ct11vts03.am.mot.com [10.177.16.162]) by ct11msg02.am.mot-solutions.com (8.14.3/8.14.3) with ESMTP id r2FMt1uW008417 for ; Fri, 15 Mar 2013 18:55:01 -0400 (EDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ct11msg02.am.mot-solutions.com (8.14.3/8.14.3) with ESMTP id r2FMt0E7008411 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 15 Mar 2013 18:55:00 -0400 (EDT) Received: from mail22-tx2-R.bigfish.com (10.9.14.243) by TX2EHSOBE015.bigfish.com (10.9.40.35) with Microsoft SMTP Server id 14.1.225.23; Fri, 15 Mar 2013 22:54:46 +0000 Received: from mail22-tx2 (localhost [127.0.0.1]) by mail22-tx2-R.bigfish.com (Postfix) with ESMTP id BC8C6A02AA for ; Fri, 15 Mar 2013 22:54:46 +0000 (UTC) Received: from mail22-tx2 (localhost.localdomain [127.0.0.1]) by mail22-tx2 (MessageSwitch) id 1363388084780028_24542; Fri, 15 Mar 2013 22:54:44 +0000 (UTC) Received: from TX2EHSMHS031.bigfish.com (unknown [10.9.14.228]) by mail22-tx2.bigfish.com (Postfix) with ESMTP id B8C09C0243; Fri, 15 Mar 2013 22:54:44 +0000 (UTC) Received: from BY2PRD0411HT005.namprd04.prod.outlook.com (157.56.237.133) by TX2EHSMHS031.bigfish.com (10.9.99.131) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 15 Mar 2013 22:54:44 +0000 Received: from BY2PRD0411MB441.namprd04.prod.outlook.com ([169.254.5.31]) by BY2PRD0411HT005.namprd04.prod.outlook.com ([10.255.128.40]) with mapi id 14.16.0275.006; Fri, 15 Mar 2013 22:54:41 +0000 From: Lewis Adam-CAL022 To: Brian Campbell Thread-Topic: [OAUTH-WG] JWT grant_type and client_id Thread-Index: AQHOIcpbWGop5BX/OECnwHSB/syrP5inUb8AgAAJ15A= Date: Fri, 15 Mar 2013 22:54:40 +0000 Message-ID: <59E470B10C4630419ED717AC79FCF9A9568A985E@BY2PRD0411MB441.namprd04.prod.outlook.com> References: <59E470B10C4630419ED717AC79FCF9A948D552B8@BY2PRD0411MB441.namprd04.prod.outlook.com> <4E1F6AAD24975D4BA5B168042967394367472284@TK5EX14MBXC284.redmond.corp.microsoft.com> <59E470B10C4630419ED717AC79FCF9A9568A83EA@BY2PRD0411MB441.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A9568A84A6@BY2PRD0411MB441.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A9568A8760@BY2PRD0411MB441.namprd04.prod.outlook.com> <51439320.9060401@gmail.com> <59E470B10C4630419ED717AC79FCF9A9568A87C1@BY2PRD0411MB441.namprd04.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [150.130.161.105] Content-Type: multipart/alternative; boundary="_000_59E470B10C4630419ED717AC79FCF9A9568A985EBY2PRD0411MB441_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%1294$Dn%PINGIDENTITY.COM$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn% X-FOPE-CONNECTOR: Id%1294$Dn%GMAIL.COM$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn% X-FOPE-CONNECTOR: Id%1294$Dn%IETF.ORG$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn% X-CFilter-Loop: Reflected X-OriginatorOrg: motorolasolutions.com Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] JWT grant_type and client_id X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 22:55:06 -0000 --_000_59E470B10C4630419ED717AC79FCF9A9568A985EBY2PRD0411MB441_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I guess that it depends on what JWT is meant to be. My understanding is th= at it began as something to support Web SSO authentication for OIDC, so sco= pe didn't make any sense then. Nor does it make any sense as a strict gran= t type. The use case where it becomes interesting (the one I am looking to= ) is for when an access token or refresh token is a JWT. I think some vend= ors are beginning to make their structured tokens a JWT, and that is my cur= rent thinking as well ... if folks agree that JWT can be used as the struct= ure for OAuth tokens, then it makes sense to include a scope field. If not= , then it will be JSON+encryption+signing, just not a JWT :) adam From: Brian Campbell [mailto:bcampbell@pingidentity.com] Sent: Friday, March 15, 2013 5:16 PM To: Lewis Adam-CAL022 Cc: Sergey Beryozkin; oauth@ietf.org Subject: Re: [OAUTH-WG] JWT grant_type and client_id Codifying a claim/attribute for scope that goes in the assertion is somethi= ng that's been discussed but never seemed to get sufficient consensus regar= ding how to exactly to do it and if it really provided much value. On Fri, Mar 15, 2013 at 4:12 PM, Brian Campbell > wrote: So currently the base assertion document defines scope as an HTTP parameter= on the access token request message when using an assertion as a grant[1].= And that applies to both the SAML and JWT grants (perhaps that needs to b= e more clear?). Also RFC 6749 defines the scope parameter for the client cr= edentials access token request[2], which similarly applies to both SAML and= JWT in the case of assertion client authentication using the "client_crede= ntials" grant type. [1] http://tools.ietf.org/html/draft-ietf-oauth-assertions-10#section-4.1 [2] http://tools.ietf.org/html/rfc6749#section-4.4.1 On Fri, Mar 15, 2013 at 3:43 PM, Lewis Adam-CAL022 > wrote: Right ... thinking about this further I think the answer is "all of the abo= ve." If the JWT is a grant type then as you say it needs a scope param and= optionally a client_id param. I argued for the client_id param earlier si= nce it could assist with HOK scenarios once those further develop. But when the JWT is used as an AT then it will definitely require the scope= as a claim. So I change my argument to "both" :) adam -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Sergey Beryozk= in Sent: Friday, March 15, 2013 4:31 PM To: oauth@ietf.org Subject: Re: [OAUTH-WG] JWT grant_type and client_id Hi On 15/03/13 20:40, Lewis Adam-CAL022 wrote: > Hi John, > > I would like to argue that the scope should be a parameter in the access > token request message, the same as it is for the RO creds grant and > client creds grant type. This would keep it consistent with the core > OAuth grant types that talk directly to the token endpoint. > Assuming the assertion is acting as a grant, then it is indeed an access token request message, so IMHO it makes sense to get an outbound scope parameter optionally supported which I guess will imply that the client id will also have to accompany it... Cheers, Sergey > Thoughts? > > adam > > *From:*John Bradley [mailto:ve7jtb@ve7jtb.com] > *Sent:* Friday, March 15, 2013 12:10 PM > *To:* Lewis Adam-CAL022 > *Cc:* Brian Campbell; "WG >"@il06ex= r02.mot.com > *Subject:* Re: [OAUTH-WG] JWT grant_type and client_id > > The spec is a touch vague on that. I think the scopes should be in the > assertion and the client can use the scopes outside the assertion to > down-scope. > > Having a standard claim in JWT and SAML for passing scopes is probably > useful as part of a profile. > > John B. > > On 2013-03-14, at 8:47 PM, Lewis Adam-CAL022 > > >> wrote: > > > > Hmmm, one more thought ... no scope?? The JWT is the grant, is it assumed > that the scope is conveyed as a claim within the token? Otherwise it > would seem that it would require a scope. > > Thoughts? > > adam > > *From:*Brian Campbell [mailto:bcampbell@pingidentity.com > ] > *Sent:*Thursday, March 14, 2013 4:44 PM > *To:*Lewis Adam-CAL022 > *Cc:*Mike Jones; "WG > >>"@il06exr02.mot.com > *Subject:*Re: [OAUTH-WG] JWT grant_type and client_id > > Yes, that is correct. > > I'm working on new revisions of the drafts that will hopefully make that > point more clear. > > On Thu, Mar 14, 2013 at 5:26 PM, Lewis Adam-CAL022 > > >> wrote: > > Coming back to this... am I correct in that client_id is not required? = We are implementing this spec and want to make sure that we are doing it = right. By my understanding the only two parameters that are required in = the JWT grant type are "urn:ietf:params:oauth:grant-type:jwt-bearer" an= d the assertion. Is this correct? > > *From:*Mike Jones [mailto:Michael.Jones@microsoft.com > >] > *Sent:*Monday, February 18, 2013 6:58 PM > *To:*Lewis Adam-CAL022;oauth@ietf.org >WG > *Subject:*RE: JWT grant_type and client_id > > The client_id value and the access token value are independent. > > -- Mike > > *From:*oauth-bounces@ietf.org > >[mailto:oau= th-bounces@ietf.org > >]*On Behalf= Of*Lewis Adam-CAL022 > *Sent:*Monday, February 18, 2013 2:50 PM > *To:*oauth@ietf.org >WG > *Subject:*[OAUTH-WG] JWT grant_type and client_id > > Is there any guidance on the usage of client_id when using the JWT > assertion profile as a grant type? draft-ietf-oauth-jwt-bearer-04 makes > no mention so I assume that it is not required ... but it would be > necessary if using in conjunction with a HOK profile where the JWT > assertion is issued to - and may only be used by - the intended client. > Obviously this is straight forward enough, really I'm just looking to be > sure that I'm not missing anything. > > tx > > adam > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_59E470B10C4630419ED717AC79FCF9A9568A985EBY2PRD0411MB441_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I guess that it depends o= n what JWT is meant to be.  My understanding is that it began as somet= hing to support Web SSO authentication for OIDC, so scope didn’t make any sense then.  Nor does it make any sense as a strict grant ty= pe.  The use case where it becomes interesting (the one I am looking t= o) is for when an access token or refresh token is a JWT.  I think som= e vendors are beginning to make their structured tokens a JWT, and that is my current thinking as well … if folks agr= ee that JWT can be used as the structure for OAuth tokens, then it makes se= nse to include a scope field.  If not, then it will be JSON+encryp= tion+signing, just not a JWT J

 <= /p>

adam

 <= /p>

From: Brian Ca= mpbell [mailto:bcampbell@pingidentity.com]
Sent: Friday, March 15, 2013 5:16 PM
To: Lewis Adam-CAL022
Cc: Sergey Beryozkin; oauth@ietf.org
Subject: Re: [OAUTH-WG] JWT grant_type and client_id

 

Codifying a claim/attribute for scope that goes in t= he assertion is something that's been discussed but never seemed to get suf= ficient consensus regarding how to exactly to do it and if it really provid= ed much value.

 

On Fri, Mar 15, 2013 at 4:12 PM, Brian Campbell <= bcampbell@p= ingidentity.com> wrote:

So currently the base assertion document defines sco= pe as an HTTP parameter on the access token request message when using an a= ssertion as a grant[1].  And that applies to both the SAML and JWT gra= nts (perhaps that needs to be more clear?). Also RFC 6749 defines the scope parameter for the client credentials acces= s token request[2], which similarly applies to both SAML and JWT in the cas= e of assertion client authentication using the "client_credentials&quo= t; grant type.

[1] http://tools.ietf.org/html/draft-ietf-oauth-assertions-10#section-4.1 <= br> [2] http://tools.ietf.org/html/rfc6749#section-4.4.1

 

On Fri, Mar 15, 2013 at 3:43 PM, Lewis Adam-CAL022 &= lt;Ad= am.Lewis@motorolasolutions.com> wrote:

Right ... thinking about this further I think the an= swer is "all of the above."  If the JWT is a grant type then= as you say it needs a scope param and optionally a client_id param.  = I argued for the client_id param earlier since it could assist with HOK scenarios once those further develop.

But when the JWT is used as an AT then it will definitely require the scope= as a claim.

So I change my argument to "both" :)

adam


-----Original Message-----
From: oauth-bou= nces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Sergey Beryozkin
Sent: Friday, March 15, 2013 4:31 PM
To: oauth@ietf.org<= br> Subject: Re: [OAUTH-WG] JWT grant_type and client_id

Hi
On 15/03/13 20:40, Lewis Adam-CAL022 wrote:
> Hi John,
>
> I would like to argue that the scope should be a parameter in the acce= ss
> token request message, the same as it is for the RO creds grant and > client creds grant type. This would keep it consistent with the core > OAuth grant types that talk directly to the token endpoint.
>
Assuming the assertion is acting as a grant, then it is indeed an access token request message, so IMHO it makes sense to get an outbound scope
parameter optionally supported which I guess will imply that the client
id will also have to accompany it...

Cheers, Sergey

> Thoughts?
>
> adam
>
> *From:*John Bradley [mailto:ve7jtb@ve7jtb.com]
> *Sent:* Friday, March 15, 2013 12:10 PM
> *To:* Lewis Adam-CAL022
> *Cc:* Brian Campbell; "WG <oauth@ietf.org>"@il06exr02.mot.com
> *Subject:* Re: [OAUTH-WG] JWT grant_type and client_id
>
> The spec is a touch vague on that. I think the scopes should be in the=
> assertion and the client can use the scopes outside the assertion to > down-scope.
>
> Having a standard claim in JWT and SAML for passing scopes is probably=
> useful as part of a profile.
>
> John B.
>
> On 2013-03-14, at 8:47 PM, Lewis Adam-CAL022
> <Adam.Lewis@motorolasolutions.com
> <mailto:Adam.Lewis@motorolasolutions.com>> wrote:
>
>
>

> Hmmm, one more thought ... no scope?? The JWT i= s the grant, is it assumed

> that the scope is conveyed as a claim within th= e token? Otherwise it
> would seem that it would require a scope.
>
> Thoughts?
>
> adam
>
> *From:*Brian Campbell [mailto:bcampbell@pingidentity.com
> <http://pingi= dentity.com>]
> *Sent:*Thursday, March 14, 2013 4:44 PM
> *To:*Lewis Adam-CAL022
> *Cc:*Mike Jones; "WG <oauth@ietf.org
> <mailto:oauth@i= etf.org>>"@il06exr02.mot.com <http://il06exr02.mot.com>
> *Subject:*Re: [OAUTH-WG] JWT grant_type and client_id
>
> Yes, that is correct.
>
> I'm working on new revisions of the drafts that will hopefully make th= at
> point more clear.
>
> On Thu, Mar 14, 2013 at 5:26 PM, Lewis Adam-CAL022
> <Adam.Lewis@motorolasolutions.com
> <mailto:Adam.Lewis@motorolasolutions.com>> wrote:
>

> Coming back to this...  am I correct in th= at client_id is not required?    We are implementing this spec an= d want to make sure that we are doing it right.    By my understa= nding the only two parameters that are required in the JWT grant type are  "urn:ietf:params:oauth:grant-type:jwt-bearer" &nb= sp;  and the assertion.      Is this correct?

>
> *From:*Mike Jones [mailto:Michael.Jones@microsoft.com
> <mailto:Michael.Jones@microsoft.com>]
> *Sent:*Monday, February 18, 2013 6:58 PM
> *To:*Lewis Adam-CAL022;oauth@ietf.org <mailto:oauth@ietf.org>WG
> *Subject:*RE: JWT grant_type and client_id
>
> The client_id value and the access token value are independent.
>
> -- Mike
>
> *From:*oau= th-bounces@ietf.org
> <mailto:oauth-bounces@ietf.org>[mailto:oauth-bounces@ietf.org
> <mailto:oauth-bounces@ietf.org>]*On Behalf Of*Lewis Adam-CAL022
> *Sent:*Monday, February 18, 2013 2:50 PM
> *To:*oauth@ietf.or= g <mailto:oauth@= ietf.org>WG
> *Subject:*[OAUTH-WG] JWT grant_type and client_id
>
> Is there any guidance on the usage of client_id when using the JWT
> assertion profile as a grant type? draft-ietf-oauth-jwt-bearer-04 make= s

> no mention so I assume that it is not required = ... but it would be

> necessary if using in conjunction with a HOK pr= ofile where the JWT
> assertion is issued to - and may only be used by - the intended client= .
> Obviously this is straight forward enough, really I'm just looking to = be
> sure that I'm not missing anything.
>
> tx
>
> adam
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org= <mailto:OAuth@ietf.= org>
> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org= <mailto:OAuth@ietf.= org>
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth

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





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

 

 

--_000_59E470B10C4630419ED717AC79FCF9A9568A985EBY2PRD0411MB441_-- From Michael.Jones@microsoft.com Fri Mar 15 18:04: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 752B921F8B0A for ; Fri, 15 Mar 2013 18:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_25=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 uAUFctOrnWLU for ; Fri, 15 Mar 2013 18:04:32 -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 3723D21F8B08 for ; Fri, 15 Mar 2013 18:04:30 -0700 (PDT) Received: from BN1BFFO11FD009.protection.gbl (10.58.52.204) by BN1BFFO11HUB004.protection.gbl (10.58.53.114) with Microsoft SMTP Server (TLS) id 15.0.641.9; Sat, 16 Mar 2013 01:03:26 +0000 Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.37) by BN1BFFO11FD009.mail.protection.outlook.com (10.58.53.69) with Microsoft SMTP Server (TLS) id 15.0.641.9 via Frontend Transport; Sat, 16 Mar 2013 01:03:25 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.29]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0318.003; Sat, 16 Mar 2013 01:03:22 +0000 From: Mike Jones To: Brian Campbell , Lewis Adam-CAL022 Thread-Topic: [OAUTH-WG] JWT grant_type and client_id Thread-Index: Ac4h4g4wygAJgL9ySFC/PJajtkIVLA== Date: Sat, 16 Mar 2013 01:03:22 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436752C010@TK5EX14MBXC284.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436752C010TK5EX14MBXC284r_" 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)(79102001)(54316002)(49866001)(55846006)(76482001)(77982001)(56816002)(512874001)(20776003)(51856001)(74502001)(74662001)(46102001)(50986001)(63696002)(59766001)(53806001)(47976001)(47446002)(54356001)(65816001)(56776001)(47736001)(31966008)(16406001)(69226001)(4396001)(33656001)(80022001)(5343635001); DIR:OUT; SFP:; SCL:1; SRVR:BN1BFFO11HUB004; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0787459938 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] JWT grant_type and client_id X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Mar 2013 01:04:33 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436752C010TK5EX14MBXC284r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGF2aW5nIGEgc2NvcGUgY2xhaW0gaW4gc3BlY2lmaWMgcHJvZmlsZXMgY291bGQgbWFrZSBzZW5z ZS4gIFRoYXQgZG9lc27igJl0IG1lYW4gdGhhdCBpdCBoYXMgdG8gYmUgZGVmaW5lZCBpbiB0aGUg SldUIHNwZWMgcGVyIHNlLiAgSWYgYW55dGhpbmcsIHBlb3BsZSBleHByZXNzZWQgYSBkZXNpcmUg aW4geWVzdGVyZGF54oCZcyB3b3JraW5nIGdyb3VwIG1lZXRpbmcgdG8ga2VlcCB0aGUgYmFzZSBj bGFpbXMgc2V0IHNtYWxsLCByYXRoZXIgdGhhbiBleHBhbmRpbmcgaXQuDQoNClByb2ZpbGVzIGNh biByZWdpc3RlciB0aGUgY2xhaW1zIHRoZXkgZGVmaW5lIGluIHRoZSBJQU5BIEpXVCBDbGFpbXMg cmVnaXN0cnksIGlmIHRoZXkgY2hvb3NlLg0KDQotLSBNaWtlDQoNCg0KRnJvbTogTGV3aXMgQWRh bS1DQUwwMjINClNlbnQ6IOKAjk1hcmNo4oCOIOKAjjE14oCOLCDigI4yMDEzIOKAjjPigI464oCO NTXigI4g4oCOUE0NClRvOiBCcmlhbiBDYW1wYmVsbA0KQ0M6IG9hdXRoQGlldGYub3JnDQpTdWJq ZWN0OiBSZTogW09BVVRILVdHXSBKV1QgZ3JhbnRfdHlwZSBhbmQgY2xpZW50X2lkDQoNCkkgZ3Vl c3MgdGhhdCBpdCBkZXBlbmRzIG9uIHdoYXQgSldUIGlzIG1lYW50IHRvIGJlLiAgTXkgdW5kZXJz dGFuZGluZyBpcyB0aGF0IGl0IGJlZ2FuIGFzIHNvbWV0aGluZyB0byBzdXBwb3J0IFdlYiBTU08g YXV0aGVudGljYXRpb24gZm9yIE9JREMsIHNvIHNjb3BlIGRpZG7igJl0IG1ha2UgYW55IHNlbnNl IHRoZW4uICBOb3IgZG9lcyBpdCBtYWtlIGFueSBzZW5zZSBhcyBhIHN0cmljdCBncmFudCB0eXBl LiAgVGhlIHVzZSBjYXNlIHdoZXJlIGl0IGJlY29tZXMgaW50ZXJlc3RpbmcgKHRoZSBvbmUgSSBh bSBsb29raW5nIHRvKSBpcyBmb3Igd2hlbiBhbiBhY2Nlc3MgdG9rZW4gb3IgcmVmcmVzaCB0b2tl biBpcyBhIEpXVC4gIEkgdGhpbmsgc29tZSB2ZW5kb3JzIGFyZSBiZWdpbm5pbmcgdG8gbWFrZSB0 aGVpciBzdHJ1Y3R1cmVkIHRva2VucyBhIEpXVCwgYW5kIHRoYXQgaXMgbXkgY3VycmVudCB0aGlu a2luZyBhcyB3ZWxsIOKApiBpZiBmb2xrcyBhZ3JlZSB0aGF0IEpXVCBjYW4gYmUgdXNlZCBhcyB0 aGUgc3RydWN0dXJlIGZvciBPQXV0aCB0b2tlbnMsIHRoZW4gaXQgbWFrZXMgc2Vuc2UgdG8gaW5j bHVkZSBhIHNjb3BlIGZpZWxkLiAgSWYgbm90LCB0aGVuIGl0IHdpbGwgYmUgSlNPTitlbmNyeXB0 aW9uK3NpZ25pbmcsIGp1c3Qgbm90IGEgSldUIOKYug0KDQphZGFtDQoNCkZyb206IEJyaWFuIENh bXBiZWxsIFttYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb21dDQpTZW50OiBGcmlkYXks IE1hcmNoIDE1LCAyMDEzIDU6MTYgUE0NClRvOiBMZXdpcyBBZGFtLUNBTDAyMg0KQ2M6IFNlcmdl eSBCZXJ5b3praW47IG9hdXRoQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBKV1Qg Z3JhbnRfdHlwZSBhbmQgY2xpZW50X2lkDQoNCkNvZGlmeWluZyBhIGNsYWltL2F0dHJpYnV0ZSBm b3Igc2NvcGUgdGhhdCBnb2VzIGluIHRoZSBhc3NlcnRpb24gaXMgc29tZXRoaW5nIHRoYXQncyBi ZWVuIGRpc2N1c3NlZCBidXQgbmV2ZXIgc2VlbWVkIHRvIGdldCBzdWZmaWNpZW50IGNvbnNlbnN1 cyByZWdhcmRpbmcgaG93IHRvIGV4YWN0bHkgdG8gZG8gaXQgYW5kIGlmIGl0IHJlYWxseSBwcm92 aWRlZCBtdWNoIHZhbHVlLg0KDQpPbiBGcmksIE1hciAxNSwgMjAxMyBhdCA0OjEyIFBNLCBCcmlh biBDYW1wYmVsbCA8YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208bWFpbHRvOmJjYW1wYmVsbEBw aW5naWRlbnRpdHkuY29tPj4gd3JvdGU6DQpTbyBjdXJyZW50bHkgdGhlIGJhc2UgYXNzZXJ0aW9u IGRvY3VtZW50IGRlZmluZXMgc2NvcGUgYXMgYW4gSFRUUCBwYXJhbWV0ZXIgb24gdGhlIGFjY2Vz cyB0b2tlbiByZXF1ZXN0IG1lc3NhZ2Ugd2hlbiB1c2luZyBhbiBhc3NlcnRpb24gYXMgYSBncmFu dFsxXS4gIEFuZCB0aGF0IGFwcGxpZXMgdG8gYm90aCB0aGUgU0FNTCBhbmQgSldUIGdyYW50cyAo cGVyaGFwcyB0aGF0IG5lZWRzIHRvIGJlIG1vcmUgY2xlYXI/KS4gQWxzbyBSRkMgNjc0OSBkZWZp bmVzIHRoZSBzY29wZSBwYXJhbWV0ZXIgZm9yIHRoZSBjbGllbnQgY3JlZGVudGlhbHMgYWNjZXNz IHRva2VuIHJlcXVlc3RbMl0sIHdoaWNoIHNpbWlsYXJseSBhcHBsaWVzIHRvIGJvdGggU0FNTCBh bmQgSldUIGluIHRoZSBjYXNlIG9mIGFzc2VydGlvbiBjbGllbnQgYXV0aGVudGljYXRpb24gdXNp bmcgdGhlICJjbGllbnRfY3JlZGVudGlhbHMiIGdyYW50IHR5cGUuDQoNClsxXSBodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWFzc2VydGlvbnMtMTAjc2VjdGlvbi00 LjENClsyXSBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2NzQ5I3NlY3Rpb24tNC40LjEN Cg0KT24gRnJpLCBNYXIgMTUsIDIwMTMgYXQgMzo0MyBQTSwgTGV3aXMgQWRhbS1DQUwwMjIgPEFk YW0uTGV3aXNAbW90b3JvbGFzb2x1dGlvbnMuY29tPG1haWx0bzpBZGFtLkxld2lzQG1vdG9yb2xh c29sdXRpb25zLmNvbT4+IHdyb3RlOg0KUmlnaHQgLi4uIHRoaW5raW5nIGFib3V0IHRoaXMgZnVy dGhlciBJIHRoaW5rIHRoZSBhbnN3ZXIgaXMgImFsbCBvZiB0aGUgYWJvdmUuIiAgSWYgdGhlIEpX VCBpcyBhIGdyYW50IHR5cGUgdGhlbiBhcyB5b3Ugc2F5IGl0IG5lZWRzIGEgc2NvcGUgcGFyYW0g YW5kIG9wdGlvbmFsbHkgYSBjbGllbnRfaWQgcGFyYW0uICBJIGFyZ3VlZCBmb3IgdGhlIGNsaWVu dF9pZCBwYXJhbSBlYXJsaWVyIHNpbmNlIGl0IGNvdWxkIGFzc2lzdCB3aXRoIEhPSyBzY2VuYXJp b3Mgb25jZSB0aG9zZSBmdXJ0aGVyIGRldmVsb3AuDQoNCkJ1dCB3aGVuIHRoZSBKV1QgaXMgdXNl ZCBhcyBhbiBBVCB0aGVuIGl0IHdpbGwgZGVmaW5pdGVseSByZXF1aXJlIHRoZSBzY29wZSBhcyBh IGNsYWltLg0KDQpTbyBJIGNoYW5nZSBteSBhcmd1bWVudCB0byAiYm90aCIgOikNCg0KYWRhbQ0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogb2F1dGgtYm91bmNlc0BpZXRmLm9y ZzxtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpvYXV0aC1ib3VuY2VzQGll dGYub3JnPG1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIFNlcmdl eSBCZXJ5b3praW4NClNlbnQ6IEZyaWRheSwgTWFyY2ggMTUsIDIwMTMgNDozMSBQTQ0KVG86IG9h dXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbT0FVVEgt V0ddIEpXVCBncmFudF90eXBlIGFuZCBjbGllbnRfaWQNCg0KSGkNCk9uIDE1LzAzLzEzIDIwOjQw LCBMZXdpcyBBZGFtLUNBTDAyMiB3cm90ZToNCj4gSGkgSm9obiwNCj4NCj4gSSB3b3VsZCBsaWtl IHRvIGFyZ3VlIHRoYXQgdGhlIHNjb3BlIHNob3VsZCBiZSBhIHBhcmFtZXRlciBpbiB0aGUgYWNj ZXNzDQo+IHRva2VuIHJlcXVlc3QgbWVzc2FnZSwgdGhlIHNhbWUgYXMgaXQgaXMgZm9yIHRoZSBS TyBjcmVkcyBncmFudCBhbmQNCj4gY2xpZW50IGNyZWRzIGdyYW50IHR5cGUuIFRoaXMgd291bGQg a2VlcCBpdCBjb25zaXN0ZW50IHdpdGggdGhlIGNvcmUNCj4gT0F1dGggZ3JhbnQgdHlwZXMgdGhh dCB0YWxrIGRpcmVjdGx5IHRvIHRoZSB0b2tlbiBlbmRwb2ludC4NCj4NCkFzc3VtaW5nIHRoZSBh c3NlcnRpb24gaXMgYWN0aW5nIGFzIGEgZ3JhbnQsIHRoZW4gaXQgaXMgaW5kZWVkIGFuIGFjY2Vz cw0KdG9rZW4gcmVxdWVzdCBtZXNzYWdlLCBzbyBJTUhPIGl0IG1ha2VzIHNlbnNlIHRvIGdldCBh biBvdXRib3VuZCBzY29wZQ0KcGFyYW1ldGVyIG9wdGlvbmFsbHkgc3VwcG9ydGVkIHdoaWNoIEkg Z3Vlc3Mgd2lsbCBpbXBseSB0aGF0IHRoZSBjbGllbnQNCmlkIHdpbGwgYWxzbyBoYXZlIHRvIGFj Y29tcGFueSBpdC4uLg0KDQpDaGVlcnMsIFNlcmdleQ0KDQo+IFRob3VnaHRzPw0KPg0KPiBhZGFt DQo+DQo+ICpGcm9tOipKb2huIEJyYWRsZXkgW21haWx0bzp2ZTdqdGJAdmU3anRiLmNvbTxtYWls dG86dmU3anRiQHZlN2p0Yi5jb20+XQ0KPiAqU2VudDoqIEZyaWRheSwgTWFyY2ggMTUsIDIwMTMg MTI6MTAgUE0NCj4gKlRvOiogTGV3aXMgQWRhbS1DQUwwMjINCj4gKkNjOiogQnJpYW4gQ2FtcGJl bGw7ICJXRyA8b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4iQGlsMDZleHIw Mi5tb3QuY29tPGh0dHA6Ly9pbDA2ZXhyMDIubW90LmNvbT4NCj4gKlN1YmplY3Q6KiBSZTogW09B VVRILVdHXSBKV1QgZ3JhbnRfdHlwZSBhbmQgY2xpZW50X2lkDQo+DQo+IFRoZSBzcGVjIGlzIGEg dG91Y2ggdmFndWUgb24gdGhhdC4gSSB0aGluayB0aGUgc2NvcGVzIHNob3VsZCBiZSBpbiB0aGUN Cj4gYXNzZXJ0aW9uIGFuZCB0aGUgY2xpZW50IGNhbiB1c2UgdGhlIHNjb3BlcyBvdXRzaWRlIHRo ZSBhc3NlcnRpb24gdG8NCj4gZG93bi1zY29wZS4NCj4NCj4gSGF2aW5nIGEgc3RhbmRhcmQgY2xh aW0gaW4gSldUIGFuZCBTQU1MIGZvciBwYXNzaW5nIHNjb3BlcyBpcyBwcm9iYWJseQ0KPiB1c2Vm dWwgYXMgcGFydCBvZiBhIHByb2ZpbGUuDQo+DQo+IEpvaG4gQi4NCj4NCj4gT24gMjAxMy0wMy0x NCwgYXQgODo0NyBQTSwgTGV3aXMgQWRhbS1DQUwwMjINCj4gPEFkYW0uTGV3aXNAbW90b3JvbGFz b2x1dGlvbnMuY29tPG1haWx0bzpBZGFtLkxld2lzQG1vdG9yb2xhc29sdXRpb25zLmNvbT4NCj4g PG1haWx0bzpBZGFtLkxld2lzQG1vdG9yb2xhc29sdXRpb25zLmNvbTxtYWlsdG86QWRhbS5MZXdp c0Btb3Rvcm9sYXNvbHV0aW9ucy5jb20+Pj4gd3JvdGU6DQo+DQo+DQo+DQo+IEhtbW0sIG9uZSBt b3JlIHRob3VnaHQgLi4uIG5vIHNjb3BlPz8gVGhlIEpXVCBpcyB0aGUgZ3JhbnQsIGlzIGl0IGFz c3VtZWQNCj4gdGhhdCB0aGUgc2NvcGUgaXMgY29udmV5ZWQgYXMgYSBjbGFpbSB3aXRoaW4gdGhl IHRva2VuPyBPdGhlcndpc2UgaXQNCj4gd291bGQgc2VlbSB0aGF0IGl0IHdvdWxkIHJlcXVpcmUg YSBzY29wZS4NCj4NCj4gVGhvdWdodHM/DQo+DQo+IGFkYW0NCj4NCj4gKkZyb206KkJyaWFuIENh bXBiZWxsIFttYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208bWFpbHRvOmJjYW1wYmVs bEBwaW5naWRlbnRpdHkuY29tPg0KPiA8aHR0cDovL3BpbmdpZGVudGl0eS5jb20+XQ0KPiAqU2Vu dDoqVGh1cnNkYXksIE1hcmNoIDE0LCAyMDEzIDQ6NDQgUE0NCj4gKlRvOipMZXdpcyBBZGFtLUNB TDAyMg0KPiAqQ2M6Kk1pa2UgSm9uZXM7ICJXRyA8b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRo QGlldGYub3JnPg0KPiA8bWFpbHRvOm9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9y Zz4+PiJAaWwwNmV4cjAyLm1vdC5jb208aHR0cDovL2lsMDZleHIwMi5tb3QuY29tPiA8aHR0cDov L2lsMDZleHIwMi5tb3QuY29tPg0KPiAqU3ViamVjdDoqUmU6IFtPQVVUSC1XR10gSldUIGdyYW50 X3R5cGUgYW5kIGNsaWVudF9pZA0KPg0KPiBZZXMsIHRoYXQgaXMgY29ycmVjdC4NCj4NCj4gSSdt IHdvcmtpbmcgb24gbmV3IHJldmlzaW9ucyBvZiB0aGUgZHJhZnRzIHRoYXQgd2lsbCBob3BlZnVs bHkgbWFrZSB0aGF0DQo+IHBvaW50IG1vcmUgY2xlYXIuDQo+DQo+IE9uIFRodSwgTWFyIDE0LCAy MDEzIGF0IDU6MjYgUE0sIExld2lzIEFkYW0tQ0FMMDIyDQo+IDxBZGFtLkxld2lzQG1vdG9yb2xh c29sdXRpb25zLmNvbTxtYWlsdG86QWRhbS5MZXdpc0Btb3Rvcm9sYXNvbHV0aW9ucy5jb20+DQo+ IDxtYWlsdG86QWRhbS5MZXdpc0Btb3Rvcm9sYXNvbHV0aW9ucy5jb208bWFpbHRvOkFkYW0uTGV3 aXNAbW90b3JvbGFzb2x1dGlvbnMuY29tPj4+IHdyb3RlOg0KPg0KPiBDb21pbmcgYmFjayB0byB0 aGlzLi4uICBhbSBJIGNvcnJlY3QgaW4gdGhhdCBjbGllbnRfaWQgaXMgbm90IHJlcXVpcmVkPyAg ICBXZSBhcmUgaW1wbGVtZW50aW5nIHRoaXMgc3BlYyBhbmQgd2FudCB0byBtYWtlIHN1cmUgdGhh dCB3ZSBhcmUgZG9pbmcgaXQgcmlnaHQuICAgIEJ5IG15IHVuZGVyc3RhbmRpbmcgdGhlIG9ubHkg dHdvIHBhcmFtZXRlcnMgdGhhdCBhcmUgcmVxdWlyZWQgaW4gdGhlIEpXVCBncmFudCB0eXBlIGFy ZSAgInVybjppZXRmOnBhcmFtczpvYXV0aDpncmFudC10eXBlOmp3dC1iZWFyZXIiICAgIGFuZCB0 aGUgYXNzZXJ0aW9uLiAgICAgIElzIHRoaXMgY29ycmVjdD8NCj4NCj4gKkZyb206Kk1pa2UgSm9u ZXMgW21haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9u ZXNAbWljcm9zb2Z0LmNvbT4NCj4gPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208 bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+XQ0KPiAqU2VudDoqTW9uZGF5LCBG ZWJydWFyeSAxOCwgMjAxMyA2OjU4IFBNDQo+ICpUbzoqTGV3aXMgQWRhbS1DQUwwMjI7b2F1dGhA aWV0Zi5vcmc8bWFpbHRvOkFkYW0tQ0FMMDIyJTNCb2F1dGhAaWV0Zi5vcmc+IDxtYWlsdG86b2F1 dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj5XRw0KPiAqU3ViamVjdDoqUkU6IEpX VCBncmFudF90eXBlIGFuZCBjbGllbnRfaWQNCj4NCj4gVGhlIGNsaWVudF9pZCB2YWx1ZSBhbmQg dGhlIGFjY2VzcyB0b2tlbiB2YWx1ZSBhcmUgaW5kZXBlbmRlbnQuDQo+DQo+IC0tIE1pa2UNCj4N Cj4gKkZyb206Km9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0 Zi5vcmc+DQo+IDxtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86b2F1dGgtYm91 bmNlc0BpZXRmLm9yZz4+W21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpvYXV0 aC1ib3VuY2VzQGlldGYub3JnPg0KPiA8bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8bWFp bHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+Pl0qT24gQmVoYWxmIE9mKkxld2lzIEFkYW0tQ0FM MDIyDQo+ICpTZW50OipNb25kYXksIEZlYnJ1YXJ5IDE4LCAyMDEzIDI6NTAgUE0NCj4gKlRvOipv YXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+IDxtYWlsdG86b2F1dGhAaWV0Zi5v cmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj5XRw0KPiAqU3ViamVjdDoqW09BVVRILVdHXSBKV1Qg Z3JhbnRfdHlwZSBhbmQgY2xpZW50X2lkDQo+DQo+IElzIHRoZXJlIGFueSBndWlkYW5jZSBvbiB0 aGUgdXNhZ2Ugb2YgY2xpZW50X2lkIHdoZW4gdXNpbmcgdGhlIEpXVA0KPiBhc3NlcnRpb24gcHJv ZmlsZSBhcyBhIGdyYW50IHR5cGU/IGRyYWZ0LWlldGYtb2F1dGgtand0LWJlYXJlci0wNCBtYWtl cw0KPiBubyBtZW50aW9uIHNvIEkgYXNzdW1lIHRoYXQgaXQgaXMgbm90IHJlcXVpcmVkIC4uLiBi dXQgaXQgd291bGQgYmUNCj4gbmVjZXNzYXJ5IGlmIHVzaW5nIGluIGNvbmp1bmN0aW9uIHdpdGgg YSBIT0sgcHJvZmlsZSB3aGVyZSB0aGUgSldUDQo+IGFzc2VydGlvbiBpcyBpc3N1ZWQgdG8gLSBh bmQgbWF5IG9ubHkgYmUgdXNlZCBieSAtIHRoZSBpbnRlbmRlZCBjbGllbnQuDQo+IE9idmlvdXNs eSB0aGlzIGlzIHN0cmFpZ2h0IGZvcndhcmQgZW5vdWdoLCByZWFsbHkgSSdtIGp1c3QgbG9va2lu ZyB0byBiZQ0KPiBzdXJlIHRoYXQgSSdtIG5vdCBtaXNzaW5nIGFueXRoaW5nLg0KPg0KPiB0eA0K Pg0KPiBhZGFtDQo+DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+IE9BdXRoIG1haWxpbmcgbGlzdA0KPiBPQXV0aEBpZXRmLm9yZzxtYWlsdG86 T0F1dGhAaWV0Zi5vcmc+IDxtYWlsdG86T0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYu b3JnPj4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KPg0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBPQXV0 aCBtYWlsaW5nIGxpc3QNCj4gT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPiA8 bWFpbHRvOk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4+DQo+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCj4NCj4NCj4NCj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gT0F1dGggbWFpbGluZyBs aXN0DQo+IE9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBp ZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL29hdXRoDQoNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8 bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9vYXV0aA0KDQoNCg== --_000_4E1F6AAD24975D4BA5B16804296739436752C010TK5EX14MBXC284r_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZSBkYXRhLWV4dGVybmFsc3R5bGU9InRy dWUiPgpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0 UGFyYWdyYXBoIHsKbWFyZ2luLXRvcDowaW47Cm1hcmdpbi1yaWdodDowaW47Cm1hcmdpbi1ib3R0 b206MGluOwptYXJnaW4tbGVmdDouNWluOwptYXJnaW4tYm90dG9tOi4wMDAxcHQ7Cn0KCnAuTXNv TGlzdFBhcmFncmFwaEN4U3BGaXJzdCwgbGkuTXNvTGlzdFBhcmFncmFwaEN4U3BGaXJzdCwgZGl2 Lk1zb0xpc3RQYXJhZ3JhcGhDeFNwRmlyc3QsIHAuTXNvTGlzdFBhcmFncmFwaEN4U3BNaWRkbGUs IGxpLk1zb0xpc3RQYXJhZ3JhcGhDeFNwTWlkZGxlLCBkaXYuTXNvTGlzdFBhcmFncmFwaEN4U3BN aWRkbGUsIHAuTXNvTGlzdFBhcmFncmFwaEN4U3BMYXN0LCBsaS5Nc29MaXN0UGFyYWdyYXBoQ3hT cExhc3QsIGRpdi5Nc29MaXN0UGFyYWdyYXBoQ3hTcExhc3QgewptYXJnaW4tdG9wOjBpbjsKbWFy Z2luLXJpZ2h0OjBpbjsKbWFyZ2luLWJvdHRvbTowaW47Cm1hcmdpbi1sZWZ0Oi41aW47Cm1hcmdp bi1ib3R0b206LjAwMDFwdDsKbGluZS1oZWlnaHQ6MTE1JTsKfQo8L3N0eWxlPjxzdHlsZT48IS0t CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwgewptYXJnaW46MGluIDBp biAwcHQ7CmZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7CmZvbnQtc2l6ZTox MnB0Owp9Ci0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keT4NCjxkaXYgZGF0YS1leHRlcm5hbHN0 eWxlPSJmYWxzZSIgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksJ1NlZ29lIFVJJyxNZWlyeW8s J01pY3Jvc29mdCBZYUhlaSBVSScsJ01pY3Jvc29mdCBKaGVuZ0hlaSBVSScsJ01hbGd1biBHb3Ro aWMnLCdLaG1lciBVSScsJ05pcm1hbGEgVUknLFR1bmdhLCdMYW8gVUknLEVicmltYSxzYW5zLXNl cmlmO2ZvbnQtc2l6ZToxNnB4OyI+DQo8ZGl2PkhhdmluZyBhIHNjb3BlIGNsYWltIGluIHNwZWNp ZmljIHByb2ZpbGVzIGNvdWxkIG1ha2Ugc2Vuc2UuJm5ic3A7IFRoYXQgZG9lc27igJl0IG1lYW4g dGhhdCBpdCBoYXMgdG8gYmUgZGVmaW5lZCBpbiB0aGUgSldUIHNwZWMgcGVyIHNlLiZuYnNwOyBJ ZiBhbnl0aGluZywgcGVvcGxlIGV4cHJlc3NlZCBhIGRlc2lyZSBpbiB5ZXN0ZXJkYXnigJlzIHdv cmtpbmcgZ3JvdXAgbWVldGluZyB0byBrZWVwIHRoZSBiYXNlIGNsYWltcyBzZXQgc21hbGwsIHJh dGhlciB0aGFuDQogZXhwYW5kaW5nIGl0LjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXYg ZGF0YS1mb2N1c2Zyb21wb2ludGVyPSJ0cnVlIj5Qcm9maWxlcyBjYW4gcmVnaXN0ZXIgdGhlIGNs YWltcyB0aGV5IGRlZmluZSBpbiB0aGUgSUFOQSBKV1QgQ2xhaW1zIHJlZ2lzdHJ5LCBpZiB0aGV5 IGNob29zZS48L2Rpdj4NCjxkaXYgZGF0YS1mb2N1c2Zyb21wb2ludGVyPSJ0cnVlIj4mbmJzcDs8 L2Rpdj4NCjxkaXYgZGF0YS1mb2N1c2Zyb21wb2ludGVyPSJ0cnVlIj4tLSBNaWtlPC9kaXY+DQo8 ZGl2IGRhdGEtZm9jdXNmcm9tcG9pbnRlcj0idHJ1ZSI+Jm5ic3A7PC9kaXY+DQo8ZGl2PiZuYnNw OzwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyLXRvcC1jb2xvcjogcmdiKDIyNSwgMjI1LCAyMjUp OyBib3JkZXItdG9wLXdpZHRoOiAxcHg7IGJvcmRlci10b3Atc3R5bGU6IHNvbGlkOyI+DQo8c3Ry b25nPkZyb206PC9zdHJvbmc+Jm5ic3A7TGV3aXMgQWRhbS1DQUwwMjI8YnI+DQo8c3Ryb25nPlNl bnQ6PC9zdHJvbmc+Jm5ic3A74oCOTWFyY2jigI4g4oCOMTXigI4sIOKAjjIwMTMg4oCOM+KAjjri gI41NeKAjiDigI5QTTxicj4NCjxzdHJvbmc+VG86PC9zdHJvbmc+Jm5ic3A7QnJpYW4gQ2FtcGJl bGw8YnI+DQo8c3Ryb25nPkNDOjwvc3Ryb25nPiZuYnNwO29hdXRoQGlldGYub3JnPGJyPg0KPHN0 cm9uZz5TdWJqZWN0Ojwvc3Ryb25nPiZuYnNwO1JlOiBbT0FVVEgtV0ddIEpXVCBncmFudF90eXBl IGFuZCBjbGllbnRfaWQ8YnI+DQo8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNz PSIgV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSIgTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6IHJnYigzMSwgNzMsIDEyNSk7IGZvbnQtZmFtaWx5OiAmcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7IGZvbnQtc2l6ZTogMTFwdDsiPkkgZ3Vlc3MgdGhhdCBpdCBk ZXBlbmRzIG9uIHdoYXQgSldUIGlzIG1lYW50IHRvIGJlLiZuYnNwOyBNeSB1bmRlcnN0YW5kaW5n IGlzIHRoYXQgaXQgYmVnYW4gYXMgc29tZXRoaW5nIHRvIHN1cHBvcnQgV2ViIFNTTyBhdXRoZW50 aWNhdGlvbiBmb3IgT0lEQywNCiBzbyBzY29wZSBkaWRu4oCZdCBtYWtlIGFueSBzZW5zZSB0aGVu LiZuYnNwOyBOb3IgZG9lcyBpdCBtYWtlIGFueSBzZW5zZSBhcyBhIHN0cmljdCBncmFudCB0eXBl LiZuYnNwOyBUaGUgdXNlIGNhc2Ugd2hlcmUgaXQgYmVjb21lcyBpbnRlcmVzdGluZyAodGhlIG9u ZSBJIGFtIGxvb2tpbmcgdG8pIGlzIGZvciB3aGVuIGFuIGFjY2VzcyB0b2tlbiBvciByZWZyZXNo IHRva2VuIGlzIGEgSldULiZuYnNwOyBJIHRoaW5rIHNvbWUgdmVuZG9ycyBhcmUgYmVnaW5uaW5n IHRvIG1ha2UNCiB0aGVpciBzdHJ1Y3R1cmVkIHRva2VucyBhIEpXVCwgYW5kIHRoYXQgaXMgbXkg Y3VycmVudCB0aGlua2luZyBhcyB3ZWxsIOKApiBpZiBmb2xrcyBhZ3JlZSB0aGF0IEpXVCBjYW4g YmUgdXNlZCBhcyB0aGUgc3RydWN0dXJlIGZvciBPQXV0aCB0b2tlbnMsIHRoZW4gaXQgbWFrZXMg c2Vuc2UgdG8gaW5jbHVkZSBhIHNjb3BlIGZpZWxkLiZuYnNwOyBJZiBub3QsIHRoZW4gaXQgd2ls bCBiZSBKU09OJiM0MztlbmNyeXB0aW9uJiM0MztzaWduaW5nLCBqdXN0IG5vdCBhIEpXVA0KPC9z cGFuPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgZm9udC1mYW1pbHk6IFdp bmdkaW5nczsgZm9udC1zaXplOiAxMXB0OyI+Sjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IHJn YigzMSwgNzMsIDEyNSk7IGZvbnQtZmFtaWx5OiAmcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7IGZvbnQtc2l6ZTogMTFwdDsiPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i IE1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyBmb250LWZh bWlseTogJnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBmb250LXNp emU6IDExcHQ7Ij4mbmJzcDs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9IiBNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgZm9udC1mYW1pbHk6ICZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgZm9udC1zaXplOiAxMXB0OyI+YWRhbTwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iIE1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2Io MzEsIDczLCAxMjUpOyBmb250LWZhbWlseTogJnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7OyBmb250LXNpemU6IDExcHQ7Ij4mbmJzcDs8L3NwYW4+PC9wPg0KPGRpdiBz dHlsZT0iYm9yZGVyLXdpZHRoOiAxcHQgbWVkaXVtIG1lZGl1bTsgYm9yZGVyLXN0eWxlOiBzb2xp ZCBub25lIG5vbmU7IGJvcmRlci1jb2xvcjogcmdiKDE4MSwgMTk2LCAyMjMpIGJsYWNrIGJsYWNr OyBwYWRkaW5nOiAzcHQgMGluIDBpbjsiPg0KPHAgY2xhc3M9IiBNc29Ob3JtYWwiPjxiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTogJnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7IGZvbnQtc2l6ZTogMTBwdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6ICZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBmb250 LXNpemU6IDEwcHQ7Ij4gQnJpYW4gQ2FtcGJlbGwgW21haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50 aXR5LmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIE1hcmNoIDE1LCAyMDEzIDU6MTYg UE08YnI+DQo8Yj5Ubzo8L2I+IExld2lzIEFkYW0tQ0FMMDIyPGJyPg0KPGI+Q2M6PC9iPiBTZXJn ZXkgQmVyeW96a2luOyBvYXV0aEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09B VVRILVdHXSBKV1QgZ3JhbnRfdHlwZSBhbmQgY2xpZW50X2lkPC9zcGFuPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9IiBNc29Ob3JtYWwiPiZuYnNwOzwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iIE1zb05v cm1hbCI+Q29kaWZ5aW5nIGEgY2xhaW0vYXR0cmlidXRlIGZvciBzY29wZSB0aGF0IGdvZXMgaW4g dGhlIGFzc2VydGlvbiBpcyBzb21ldGhpbmcgdGhhdCdzIGJlZW4gZGlzY3Vzc2VkIGJ1dCBuZXZl ciBzZWVtZWQgdG8gZ2V0IHN1ZmZpY2llbnQgY29uc2Vuc3VzIHJlZ2FyZGluZyBob3cgdG8gZXhh Y3RseSB0byBkbyBpdCBhbmQgaWYgaXQgcmVhbGx5IHByb3ZpZGVkIG11Y2ggdmFsdWUuPC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9IiBNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OiAxMnB0OyI+Jm5ic3A7PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSIgTXNvTm9ybWFsIj5PbiBGcmks IE1hciAxNSwgMjAxMyBhdCA0OjEyIFBNLCBCcmlhbiBDYW1wYmVsbCAmbHQ7PGEgdGFiaW5kZXg9 Ii0xIiBocmVmPSJtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20iPmJjYW1wYmVsbEBw aW5naWRlbnRpdHkuY29tPC9hPiZndDsgd3JvdGU6PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSIgTXNv Tm9ybWFsIj5TbyBjdXJyZW50bHkgdGhlIGJhc2UgYXNzZXJ0aW9uIGRvY3VtZW50IGRlZmluZXMg c2NvcGUgYXMgYW4gSFRUUCBwYXJhbWV0ZXIgb24gdGhlIGFjY2VzcyB0b2tlbiByZXF1ZXN0IG1l c3NhZ2Ugd2hlbiB1c2luZyBhbiBhc3NlcnRpb24gYXMgYSBncmFudFsxXS4mbmJzcDsgQW5kIHRo YXQgYXBwbGllcyB0byBib3RoIHRoZSBTQU1MIGFuZCBKV1QgZ3JhbnRzIChwZXJoYXBzIHRoYXQg bmVlZHMgdG8gYmUgbW9yZSBjbGVhcj8pLg0KIEFsc28gUkZDIDY3NDkgZGVmaW5lcyB0aGUgc2Nv cGUgcGFyYW1ldGVyIGZvciB0aGUgY2xpZW50IGNyZWRlbnRpYWxzIGFjY2VzcyB0b2tlbiByZXF1 ZXN0WzJdLCB3aGljaCBzaW1pbGFybHkgYXBwbGllcyB0byBib3RoIFNBTUwgYW5kIEpXVCBpbiB0 aGUgY2FzZSBvZiBhc3NlcnRpb24gY2xpZW50IGF1dGhlbnRpY2F0aW9uIHVzaW5nIHRoZSAmcXVv dDtjbGllbnRfY3JlZGVudGlhbHMmcXVvdDsgZ3JhbnQgdHlwZS48YnI+DQo8YnI+DQpbMV0gPGEg dGFiaW5kZXg9Ii0xIiBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LW9hdXRoLWFzc2VydGlvbnMtMTAjc2VjdGlvbi00LjEiPg0KaHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1hc3NlcnRpb25zLTEwI3NlY3Rpb24tNC4xPC9hPiA8YnI+ DQpbMl0gPGEgdGFiaW5kZXg9Ii0xIiBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9y ZmM2NzQ5I3NlY3Rpb24tNC40LjEiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY3NDkj c2VjdGlvbi00LjQuMTwvYT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSIgTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTogMTJwdDsiPiZuYnNwOzwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iIE1zb05vcm1hbCI+T24gRnJpLCBNYXIgMTUsIDIwMTMgYXQgMzo0 MyBQTSwgTGV3aXMgQWRhbS1DQUwwMjIgJmx0OzxhIHRhYmluZGV4PSItMSIgaHJlZj0ibWFpbHRv OkFkYW0uTGV3aXNAbW90b3JvbGFzb2x1dGlvbnMuY29tIj5BZGFtLkxld2lzQG1vdG9yb2xhc29s dXRpb25zLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvcD4NCjxwIGNsYXNzPSIgTXNvTm9ybWFsIj5SaWdo dCAuLi4gdGhpbmtpbmcgYWJvdXQgdGhpcyBmdXJ0aGVyIEkgdGhpbmsgdGhlIGFuc3dlciBpcyAm cXVvdDthbGwgb2YgdGhlIGFib3ZlLiZxdW90OyAmbmJzcDtJZiB0aGUgSldUIGlzIGEgZ3JhbnQg dHlwZSB0aGVuIGFzIHlvdSBzYXkgaXQgbmVlZHMgYSBzY29wZSBwYXJhbSBhbmQgb3B0aW9uYWxs eSBhIGNsaWVudF9pZCBwYXJhbS4gJm5ic3A7SSBhcmd1ZWQgZm9yIHRoZSBjbGllbnRfaWQgcGFy YW0gZWFybGllciBzaW5jZSBpdCBjb3VsZA0KIGFzc2lzdCB3aXRoIEhPSyBzY2VuYXJpb3Mgb25j ZSB0aG9zZSBmdXJ0aGVyIGRldmVsb3AuPGJyPg0KPGJyPg0KQnV0IHdoZW4gdGhlIEpXVCBpcyB1 c2VkIGFzIGFuIEFUIHRoZW4gaXQgd2lsbCBkZWZpbml0ZWx5IHJlcXVpcmUgdGhlIHNjb3BlIGFz IGEgY2xhaW0uPGJyPg0KPGJyPg0KU28gSSBjaGFuZ2UgbXkgYXJndW1lbnQgdG8gJnF1b3Q7Ym90 aCZxdW90OyA6KTxicj4NCjxicj4NCmFkYW08L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSIg TXNvTm9ybWFsIj48YnI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IDxh IHRhYmluZGV4PSItMSIgaHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciPm9hdXRo LWJvdW5jZXNAaWV0Zi5vcmc8L2E+IFttYWlsdG86PGEgdGFiaW5kZXg9Ii0xIiBocmVmPSJtYWls dG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyI+b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9u IEJlaGFsZiBPZiBTZXJnZXkgQmVyeW96a2luPGJyPg0KU2VudDogRnJpZGF5LCBNYXJjaCAxNSwg MjAxMyA0OjMxIFBNPGJyPg0KVG86IDxhIHRhYmluZGV4PSItMSIgaHJlZj0ibWFpbHRvOm9hdXRo QGlldGYub3JnIj5vYXV0aEBpZXRmLm9yZzwvYT48YnI+DQpTdWJqZWN0OiBSZTogW09BVVRILVdH XSBKV1QgZ3JhbnRfdHlwZSBhbmQgY2xpZW50X2lkPGJyPg0KPGJyPg0KSGk8YnI+DQpPbiAxNS8w My8xMyAyMDo0MCwgTGV3aXMgQWRhbS1DQUwwMjIgd3JvdGU6PGJyPg0KJmd0OyBIaSBKb2huLDxi cj4NCiZndDs8YnI+DQomZ3Q7IEkgd291bGQgbGlrZSB0byBhcmd1ZSB0aGF0IHRoZSBzY29wZSBz aG91bGQgYmUgYSBwYXJhbWV0ZXIgaW4gdGhlIGFjY2Vzczxicj4NCiZndDsgdG9rZW4gcmVxdWVz dCBtZXNzYWdlLCB0aGUgc2FtZSBhcyBpdCBpcyBmb3IgdGhlIFJPIGNyZWRzIGdyYW50IGFuZDxi cj4NCiZndDsgY2xpZW50IGNyZWRzIGdyYW50IHR5cGUuIFRoaXMgd291bGQga2VlcCBpdCBjb25z aXN0ZW50IHdpdGggdGhlIGNvcmU8YnI+DQomZ3Q7IE9BdXRoIGdyYW50IHR5cGVzIHRoYXQgdGFs ayBkaXJlY3RseSB0byB0aGUgdG9rZW4gZW5kcG9pbnQuPGJyPg0KJmd0Ozxicj4NCkFzc3VtaW5n IHRoZSBhc3NlcnRpb24gaXMgYWN0aW5nIGFzIGEgZ3JhbnQsIHRoZW4gaXQgaXMgaW5kZWVkIGFu IGFjY2Vzczxicj4NCnRva2VuIHJlcXVlc3QgbWVzc2FnZSwgc28gSU1ITyBpdCBtYWtlcyBzZW5z ZSB0byBnZXQgYW4gb3V0Ym91bmQgc2NvcGU8YnI+DQpwYXJhbWV0ZXIgb3B0aW9uYWxseSBzdXBw b3J0ZWQgd2hpY2ggSSBndWVzcyB3aWxsIGltcGx5IHRoYXQgdGhlIGNsaWVudDxicj4NCmlkIHdp bGwgYWxzbyBoYXZlIHRvIGFjY29tcGFueSBpdC4uLjxicj4NCjxicj4NCkNoZWVycywgU2VyZ2V5 PGJyPg0KPGJyPg0KJmd0OyBUaG91Z2h0cz88YnI+DQomZ3Q7PGJyPg0KJmd0OyBhZGFtPGJyPg0K Jmd0Ozxicj4NCiZndDsgKkZyb206KkpvaG4gQnJhZGxleSBbbWFpbHRvOjxhIHRhYmluZGV4PSIt MSIgaHJlZj0ibWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tIj52ZTdqdGJAdmU3anRiLmNvbTwvYT5d PGJyPg0KJmd0OyAqU2VudDoqIEZyaWRheSwgTWFyY2ggMTUsIDIwMTMgMTI6MTAgUE08YnI+DQom Z3Q7ICpUbzoqIExld2lzIEFkYW0tQ0FMMDIyPGJyPg0KJmd0OyAqQ2M6KiBCcmlhbiBDYW1wYmVs bDsgJnF1b3Q7V0cgJmx0OzxhIHRhYmluZGV4PSItMSIgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYu b3JnIj5vYXV0aEBpZXRmLm9yZzwvYT4mZ3Q7JnF1b3Q7QDxhIHRhYmluZGV4PSItMSIgaHJlZj0i aHR0cDovL2lsMDZleHIwMi5tb3QuY29tIj5pbDA2ZXhyMDIubW90LmNvbTwvYT48YnI+DQomZ3Q7 ICpTdWJqZWN0OiogUmU6IFtPQVVUSC1XR10gSldUIGdyYW50X3R5cGUgYW5kIGNsaWVudF9pZDxi cj4NCiZndDs8YnI+DQomZ3Q7IFRoZSBzcGVjIGlzIGEgdG91Y2ggdmFndWUgb24gdGhhdC4gSSB0 aGluayB0aGUgc2NvcGVzIHNob3VsZCBiZSBpbiB0aGU8YnI+DQomZ3Q7IGFzc2VydGlvbiBhbmQg dGhlIGNsaWVudCBjYW4gdXNlIHRoZSBzY29wZXMgb3V0c2lkZSB0aGUgYXNzZXJ0aW9uIHRvPGJy Pg0KJmd0OyBkb3duLXNjb3BlLjxicj4NCiZndDs8YnI+DQomZ3Q7IEhhdmluZyBhIHN0YW5kYXJk IGNsYWltIGluIEpXVCBhbmQgU0FNTCBmb3IgcGFzc2luZyBzY29wZXMgaXMgcHJvYmFibHk8YnI+ DQomZ3Q7IHVzZWZ1bCBhcyBwYXJ0IG9mIGEgcHJvZmlsZS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBK b2huIEIuPGJyPg0KJmd0Ozxicj4NCiZndDsgT24gMjAxMy0wMy0xNCwgYXQgODo0NyBQTSwgTGV3 aXMgQWRhbS1DQUwwMjI8YnI+DQomZ3Q7ICZsdDs8YSB0YWJpbmRleD0iLTEiIGhyZWY9Im1haWx0 bzpBZGFtLkxld2lzQG1vdG9yb2xhc29sdXRpb25zLmNvbSI+QWRhbS5MZXdpc0Btb3Rvcm9sYXNv bHV0aW9ucy5jb208L2E+PGJyPg0KJmd0OyAmbHQ7bWFpbHRvOjxhIHRhYmluZGV4PSItMSIgaHJl Zj0ibWFpbHRvOkFkYW0uTGV3aXNAbW90b3JvbGFzb2x1dGlvbnMuY29tIj5BZGFtLkxld2lzQG1v dG9yb2xhc29sdXRpb25zLmNvbTwvYT4mZ3Q7Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7PGJyPg0KJmd0 Ozxicj4NCiZndDs8L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9IiBNc29Ob3JtYWwiPiZn dDsgSG1tbSwgb25lIG1vcmUgdGhvdWdodCAuLi4gbm8gc2NvcGU/PyBUaGUgSldUIGlzIHRoZSBn cmFudCwgaXMgaXQgYXNzdW1lZDwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iIE1zb05vcm1hbCI+Jmd0 OyB0aGF0IHRoZSBzY29wZSBpcyBjb252ZXllZCBhcyBhIGNsYWltIHdpdGhpbiB0aGUgdG9rZW4/ IE90aGVyd2lzZSBpdDxicj4NCiZndDsgd291bGQgc2VlbSB0aGF0IGl0IHdvdWxkIHJlcXVpcmUg YSBzY29wZS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaG91Z2h0cz88YnI+DQomZ3Q7PGJyPg0KJmd0 OyBhZGFtPGJyPg0KJmd0Ozxicj4NCiZndDsgKkZyb206KkJyaWFuIENhbXBiZWxsIFttYWlsdG86 PGEgdGFiaW5kZXg9Ii0xIiBocmVmPSJtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20i PmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPC9hPjxicj4NCiZndDsgJmx0OzxhIHRhYmluZGV4 PSItMSIgaHJlZj0iaHR0cDovL3BpbmdpZGVudGl0eS5jb20iPmh0dHA6Ly9waW5naWRlbnRpdHku Y29tPC9hPiZndDtdPGJyPg0KJmd0OyAqU2VudDoqVGh1cnNkYXksIE1hcmNoIDE0LCAyMDEzIDQ6 NDQgUE08YnI+DQomZ3Q7ICpUbzoqTGV3aXMgQWRhbS1DQUwwMjI8YnI+DQomZ3Q7ICpDYzoqTWlr ZSBKb25lczsgJnF1b3Q7V0cgJmx0OzxhIHRhYmluZGV4PSItMSIgaHJlZj0ibWFpbHRvOm9hdXRo QGlldGYub3JnIj5vYXV0aEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7ICZsdDttYWlsdG86PGEgdGFi aW5kZXg9Ii0xIiBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYub3JnPC9h PiZndDsmZ3Q7JnF1b3Q7QDxhIHRhYmluZGV4PSItMSIgaHJlZj0iaHR0cDovL2lsMDZleHIwMi5t b3QuY29tIj5pbDA2ZXhyMDIubW90LmNvbTwvYT4gJmx0OzxhIHRhYmluZGV4PSItMSIgaHJlZj0i aHR0cDovL2lsMDZleHIwMi5tb3QuY29tIj5odHRwOi8vaWwwNmV4cjAyLm1vdC5jb208L2E+Jmd0 Ozxicj4NCiZndDsgKlN1YmplY3Q6KlJlOiBbT0FVVEgtV0ddIEpXVCBncmFudF90eXBlIGFuZCBj bGllbnRfaWQ8YnI+DQomZ3Q7PGJyPg0KJmd0OyBZZXMsIHRoYXQgaXMgY29ycmVjdC48YnI+DQom Z3Q7PGJyPg0KJmd0OyBJJ20gd29ya2luZyBvbiBuZXcgcmV2aXNpb25zIG9mIHRoZSBkcmFmdHMg dGhhdCB3aWxsIGhvcGVmdWxseSBtYWtlIHRoYXQ8YnI+DQomZ3Q7IHBvaW50IG1vcmUgY2xlYXIu PGJyPg0KJmd0Ozxicj4NCiZndDsgT24gVGh1LCBNYXIgMTQsIDIwMTMgYXQgNToyNiBQTSwgTGV3 aXMgQWRhbS1DQUwwMjI8YnI+DQomZ3Q7ICZsdDs8YSB0YWJpbmRleD0iLTEiIGhyZWY9Im1haWx0 bzpBZGFtLkxld2lzQG1vdG9yb2xhc29sdXRpb25zLmNvbSI+QWRhbS5MZXdpc0Btb3Rvcm9sYXNv bHV0aW9ucy5jb208L2E+PGJyPg0KJmd0OyAmbHQ7bWFpbHRvOjxhIHRhYmluZGV4PSItMSIgaHJl Zj0ibWFpbHRvOkFkYW0uTGV3aXNAbW90b3JvbGFzb2x1dGlvbnMuY29tIj5BZGFtLkxld2lzQG1v dG9yb2xhc29sdXRpb25zLmNvbTwvYT4mZ3Q7Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iIE1zb05vcm1hbCI+Jmd0OyBDb21pbmcgYmFjayB0byB0aGlzLi4uICZu YnNwO2FtIEkgY29ycmVjdCBpbiB0aGF0IGNsaWVudF9pZCBpcyBub3QgcmVxdWlyZWQ/ICZuYnNw OyAmbmJzcDtXZSBhcmUgaW1wbGVtZW50aW5nIHRoaXMgc3BlYyBhbmQgd2FudCB0byBtYWtlIHN1 cmUgdGhhdCB3ZSBhcmUgZG9pbmcgaXQgcmlnaHQuICZuYnNwOyAmbmJzcDtCeSBteSB1bmRlcnN0 YW5kaW5nIHRoZSBvbmx5IHR3byBwYXJhbWV0ZXJzIHRoYXQgYXJlIHJlcXVpcmVkIGluIHRoZSBK V1QgZ3JhbnQNCiB0eXBlIGFyZSAmbmJzcDsmcXVvdDt1cm46aWV0ZjpwYXJhbXM6b2F1dGg6Z3Jh bnQtdHlwZTpqd3QtYmVhcmVyJnF1b3Q7ICZuYnNwOyAmbmJzcDthbmQgdGhlIGFzc2VydGlvbi4g Jm5ic3A7ICZuYnNwOyAmbmJzcDtJcyB0aGlzIGNvcnJlY3Q/PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSIgTXNvTm9ybWFsIj4mZ3Q7PGJyPg0KJmd0OyAqRnJvbToqTWlrZSBKb25lcyBbbWFpbHRvOjxh IHRhYmluZGV4PSItMSIgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSI+ TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9hPjxicj4NCiZndDsgJmx0O21haWx0bzo8YSB0 YWJpbmRleD0iLTEiIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iPk1p Y2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7XTxicj4NCiZndDsgKlNlbnQ6Kk1vbmRh eSwgRmVicnVhcnkgMTgsIDIwMTMgNjo1OCBQTTxicj4NCiZndDsgKlRvOipMZXdpcyA8YSB0YWJp bmRleD0iLTEiIGhyZWY9Im1haWx0bzpBZGFtLUNBTDAyMiUzQm9hdXRoQGlldGYub3JnIj5BZGFt LUNBTDAyMjtvYXV0aEBpZXRmLm9yZzwvYT4gJmx0O21haWx0bzo8YSB0YWJpbmRleD0iLTEiIGhy ZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+b2F1dGhAaWV0Zi5vcmc8L2E+Jmd0O1dHPGJyPg0K Jmd0OyAqU3ViamVjdDoqUkU6IEpXVCBncmFudF90eXBlIGFuZCBjbGllbnRfaWQ8YnI+DQomZ3Q7 PGJyPg0KJmd0OyBUaGUgY2xpZW50X2lkIHZhbHVlIGFuZCB0aGUgYWNjZXNzIHRva2VuIHZhbHVl IGFyZSBpbmRlcGVuZGVudC48YnI+DQomZ3Q7PGJyPg0KJmd0OyAtLSBNaWtlPGJyPg0KJmd0Ozxi cj4NCiZndDsgKkZyb206KjxhIHRhYmluZGV4PSItMSIgaHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5j ZXNAaWV0Zi5vcmciPm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyAmbHQ7bWFp bHRvOjxhIHRhYmluZGV4PSItMSIgaHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmci Pm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0O1ttYWlsdG86PGEgdGFiaW5kZXg9Ii0xIiBo cmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyI+b2F1dGgtYm91bmNlc0BpZXRmLm9y ZzwvYT48YnI+DQomZ3Q7ICZsdDttYWlsdG86PGEgdGFiaW5kZXg9Ii0xIiBocmVmPSJtYWlsdG86 b2F1dGgtYm91bmNlc0BpZXRmLm9yZyI+b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7XSpP biBCZWhhbGYgT2YqTGV3aXMgQWRhbS1DQUwwMjI8YnI+DQomZ3Q7ICpTZW50OipNb25kYXksIEZl YnJ1YXJ5IDE4LCAyMDEzIDI6NTAgUE08YnI+DQomZ3Q7ICpUbzoqPGEgdGFiaW5kZXg9Ii0xIiBo cmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYub3JnPC9hPiAmbHQ7bWFpbHRv OjxhIHRhYmluZGV4PSItMSIgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj5vYXV0aEBpZXRm Lm9yZzwvYT4mZ3Q7V0c8YnI+DQomZ3Q7ICpTdWJqZWN0OipbT0FVVEgtV0ddIEpXVCBncmFudF90 eXBlIGFuZCBjbGllbnRfaWQ8YnI+DQomZ3Q7PGJyPg0KJmd0OyBJcyB0aGVyZSBhbnkgZ3VpZGFu Y2Ugb24gdGhlIHVzYWdlIG9mIGNsaWVudF9pZCB3aGVuIHVzaW5nIHRoZSBKV1Q8YnI+DQomZ3Q7 IGFzc2VydGlvbiBwcm9maWxlIGFzIGEgZ3JhbnQgdHlwZT8gZHJhZnQtaWV0Zi1vYXV0aC1qd3Qt YmVhcmVyLTA0IG1ha2VzPC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iIE1zb05vcm1hbCI+Jmd0OyBu byBtZW50aW9uIHNvIEkgYXNzdW1lIHRoYXQgaXQgaXMgbm90IHJlcXVpcmVkIC4uLiBidXQgaXQg d291bGQgYmU8L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSIgTXNvTm9ybWFsIj4mZ3Q7IG5l Y2Vzc2FyeSBpZiB1c2luZyBpbiBjb25qdW5jdGlvbiB3aXRoIGEgSE9LIHByb2ZpbGUgd2hlcmUg dGhlIEpXVDxicj4NCiZndDsgYXNzZXJ0aW9uIGlzIGlzc3VlZCB0byAtIGFuZCBtYXkgb25seSBi ZSB1c2VkIGJ5IC0gdGhlIGludGVuZGVkIGNsaWVudC48YnI+DQomZ3Q7IE9idmlvdXNseSB0aGlz IGlzIHN0cmFpZ2h0IGZvcndhcmQgZW5vdWdoLCByZWFsbHkgSSdtIGp1c3QgbG9va2luZyB0byBi ZTxicj4NCiZndDsgc3VyZSB0aGF0IEknbSBub3QgbWlzc2luZyBhbnl0aGluZy48YnI+DQomZ3Q7 PGJyPg0KJmd0OyB0eDxicj4NCiZndDs8YnI+DQomZ3Q7IGFkYW08YnI+DQomZ3Q7PGJyPg0KJmd0 Ozxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQomZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxicj4NCiZndDsgPGEgdGFiaW5kZXg9Ii0x IiBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPiAmbHQ7bWFp bHRvOjxhIHRhYmluZGV4PSItMSIgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBp ZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KJmd0OyA8YSB0YWJpbmRleD0iLTEiIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PGJyPg0KJmd0Ozxicj4NCiZndDsgX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IE9BdXRoIG1h aWxpbmcgbGlzdDxicj4NCiZndDsgPGEgdGFiaW5kZXg9Ii0xIiBocmVmPSJtYWlsdG86T0F1dGhA aWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPiAmbHQ7bWFpbHRvOjxhIHRhYmluZGV4PSItMSIg aHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0K Jmd0OyA8YSB0YWJpbmRleD0iLTEiIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vb2F1dGgiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1 dGg8L2E+PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgT0F1dGggbWFp bGluZyBsaXN0PGJyPg0KJmd0OyA8YSB0YWJpbmRleD0iLTEiIGhyZWY9Im1haWx0bzpPQXV0aEBp ZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyA8YSB0YWJpbmRleD0iLTEiIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PGJyPg0KPGJyPg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWls aW5nIGxpc3Q8YnI+DQo8YSB0YWJpbmRleD0iLTEiIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9y ZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgdGFiaW5kZXg9Ii0xIiBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4N Cjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgdGFiaW5kZXg9Ii0xIiBocmVmPSJtYWlsdG86 T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIHRhYmluZGV4PSItMSIg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iIE1zb05vcm1hbCI+Jm5ic3A7PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iIE1zb05vcm1hbCI+Jm5ic3A7PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_4E1F6AAD24975D4BA5B16804296739436752C010TK5EX14MBXC284r_-- From Michael.Jones@microsoft.com Fri Mar 15 20:17: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 4408A1F0D26 for ; Fri, 15 Mar 2013 20:17:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=0.300, 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 YiyOhpkiZ+6f for ; Fri, 15 Mar 2013 20:17:57 -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 6D9091F0C74 for ; Fri, 15 Mar 2013 20:17:56 -0700 (PDT) Received: from BL2FFO11FD001.protection.gbl (10.173.161.204) by BL2FFO11HUB011.protection.gbl (10.173.161.117) with Microsoft SMTP Server (TLS) id 15.0.641.9; Sat, 16 Mar 2013 03:17:49 +0000 Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD001.mail.protection.outlook.com (10.173.160.101) with Microsoft SMTP Server (TLS) id 15.0.641.9 via Frontend Transport; Sat, 16 Mar 2013 03:17:49 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.29]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.02.0318.003; Sat, 16 Mar 2013 03:17:48 +0000 From: Mike Jones To: IETF oauth WG , Jeff Hodges Thread-Topic: [OAUTH-WG] regarding nested JWTs and security Thread-Index: Ac4h9NW8GeA4NUyhwUWvRyDR+5HaGg== Date: Sat, 16 Mar 2013 03:17:48 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394367530168@TK5EX14MBXC284.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394367530168TK5EX14MBXC284r_" 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)(46102001)(47736001)(63696002)(51856001)(59766001)(54356001)(55846006)(5343635001)(44976002)(56776001)(31966008)(74502001)(50986001)(47446002)(47976001)(53806001)(77982001)(20776003)(80022001)(79102001)(4396001)(54316002)(56816002)(33656001)(76482001)(74662001)(49866001)(512874001)(65816001)(16406001)(69226001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB011; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0787459938 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: Sat, 16 Mar 2013 03:17:59 -0000 --_000_4E1F6AAD24975D4BA5B168042967394367530168TK5EX14MBXC284r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGFnYWluIGZvciB0aGUgdGhvcm91Z2ggYW5kIHVzZWZ1bCBmZWVkYmFjaywgSmVmZi4g IEnigJlsbCB3b3JrIG9uIGluY29ycG9yYXRpbmcgaXQgaW4gdGhlIG5leHQgSldUIGRyYWZ0Lg0K DQpJdCB3YXMgZ3JlYXQgc2VlaW5nIHlvdSBpbiBPcmxhbmRvIQ0KDQotLSBNaWtlDQoNCkZyb206 ID1KZWZmSA0KU2VudDog4oCOTWFyY2jigI4g4oCOMTXigI4sIOKAjjIwMTMg4oCOMTDigI464oCO MTHigI4g4oCOQU0NClRvOiBJRVRGIG9hdXRoIFdHDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBy ZWdhcmRpbmcgbmVzdGVkIEpXVHMgYW5kIHNlY3VyaXR5DQoNCkR1cmluZyB0aGUgT0F1dGggMm5k IHNlc3Npb24gYXQgSUVURi04NiBvcmxhbmRvLCBhZnRlciBJIG1lbnRpb25lZCB0aGUNCnNpZ24t dGhlbi1lbmNyeXB0IGNvbnNpZGVyYXRpb25zIGF0IHRoZSBtaWMsIEJyYWQgSGlsbCBwb2ludGVk IG91dCB0aGF0IHRoZQ0KYmVsb3cgcGFwZXIgaXMgcGVyaGFwcyBhbiBldmVuIG1vcmUgZnVuZGFt ZW50YWwgcmVmZXJlbmNlIGZvciB0aGUNCnNpZ2gtdGhlbi1lbmNyeXB0IGNvbXBvc2l0aW9uIHRo YW4gdGhlIERhdmlzIHBhcGVyIEkgcG9pbnRlZCB0byBpbiB0aGUgYmVsb3cNCmF0dGFjaGVkIG1l c3NhZ2UgYmFjayBpbiBEZWMtMjAxMi4uDQoNCiAgIEF1dGhlbnRpY2F0ZWQgRW5jcnlwdGlvbjog UmVsYXRpb25zIGFtb25nIG5vdGlvbnMgYW5kIGFuYWx5c2lzDQogICBvZiB0aGUgZ2VuZXJpYyBj b21wb3NpdGlvbiBwYXJhZGlnbSAoMjAwNykNCiAgIEJlbGxhcmUgJiBOYW1wcmVtcHJlDQogICBo dHRwOi8vZXByaW50LmlhY3Iub3JnLzIwMDAvMDI1LnBkZg0KDQpBZnRlciBoYXZpbmcgdGFsa2Vk IHdpdGggTWlrZSBKb25lcyBmMmYgZWFybGllciBpbiB0aGUgd2VlayBhYm91dCB0aGlzIHN0dWZm LA0KZHVyaW5nIHdoaWNoIGhlIGluZGljYXRlZCBoZSBiZWxpZXZlZCB0aGF0IHRoZXNlIGlzc3Vl cyBhcmUgYWRkcmVzc2VkIGluIHRoZSBKV1QNCnNwZWMsIEkgbG9va2VkIGF0IGRyYWZ0LWlldGYt b2F1dGgtanNvbi13ZWItdG9rZW4tMDYgYW5kIG5vdGUgdGhhdCB0aGUgbGFzdA0KcGFyYWdyYXBo IG9mIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzYXlzLi4NCg0KICAgIFdoaWxlIHN5bnRh Y3RpY2FsbHksIHRoZSBzaWduaW5nIGFuZCBlbmNyeXB0aW9uIG9wZXJhdGlvbnMgZm9yIE5lc3Rl ZA0KICAgIEpXVHMgbWF5IGJlIGFwcGxpZWQgaW4gYW55IG9yZGVyLCBub3JtYWxseSBzZW5kZXJz IHNob3VsZCBzaWduIHRoZQ0KICAgIG1lc3NhZ2UgYW5kIHRoZW4gZW5jcnlwdCB0aGUgcmVzdWx0 ICh0aHVzIGVuY3J5cHRpbmcgdGhlIHNpZ25hdHVyZSkuDQogICAgVGhpcyBwcmV2ZW50cyBhdHRh Y2tzIGluIHdoaWNoIHRoZSBzaWduYXR1cmUgaXMgc3RyaXBwZWQsIGxlYXZpbmcNCiAgICBqdXN0 IGFuIGVuY3J5cHRlZCBtZXNzYWdlLCBhcyB3ZWxsIGFzIHByb3ZpZGluZyBwcml2YWN5IGZvciB0 aGUNCiAgICBzaWduZXIuICBGdXJ0aGVybW9yZSwgc2lnbmF0dXJlcyBvdmVyIGVuY3J5cHRlZCB0 ZXh0IGFyZSBub3QNCiAgICBjb25zaWRlcmVkIHZhbGlkIGluIG1hbnkganVyaXNkaWN0aW9ucy4N Cg0KLi53aGljaCBjZXJ0YWlubHkgdG91Y2hlcyB1cG9uIHRoZSBpc3N1ZShzKSwgYnV0IGNvdWxk IGFyZ3VhYmx5IGNvbnRhaW4gbW9yZQ0KcmF0aW9uYWxlLiBUaG91Z2gsIGlmIHlvdSB3aXNoIHRo ZSBzcGVjIHRvIGJlIHRlcnNlIChhcyBhYm92ZSkgeW91IHNob3VsZA0KcHJvYmFibHkgYXQgbGVh c3QgcmVmZXJlbmNlIERhdmlzICh3aGljaCBpcyByZXNvbmFibHkgYXBwcm9hY2hhYmxlKSBhbmQg QmVsbGFyZQ0KJiBOYW1wcmVtcHJlICh3aGljaCBpcyBhIGZvcm1hbCBwcm9vZikuDQoNCkFsc28s IGluIHRlcm1zIG9mIGxpbmthZ2VzIGJldHdlZW4gc2lnbmluZyBhbmQgZW5jcnlwdGluZyB3cmFw cGVycywgaXQgc2VlbXMNCnRoYXQgaWYgb25lIGluY2x1ZGVzIGF0IGxlYXN0IGFuIGF1ZGllbmNl IGNsYWltIGluIHRoZSBKV1QgQ2xhaW1zIFNldCwgaW4gYQ0Kc2lnbmVkICYgZW5jcnlwdGVkIEpX VCAoYWthICJOZXN0ZWQgSldUIiksIGFuZCB0aGUgcmVjZWl2ZXIgb2YgdGhlIEpXVCBjaGVja3MN CnRoZSBhdWRpZW5jZSBhbmQgZG9lcyBub3QgcmVseSBvbiB0aGUgSldUIGlmIGl0IGRvZXMgbm90 IGlkZW50aWZ5IHRoZW0sIHRoZW4geW91DQphcmUgYXJndWFibHkgaW4gb2sgc2hhcGUuIElmIHRo ZSBKV1QgaW5jbHVkZXMgYm90aCBzdWJqZWN0IGFuZCBhdWRpZW5jZSBjbGFpbXMsDQp0aGF0IHdv dWxkIGJlIGJlc3QuIEl0IG1heSBiZSBhIGdvb2QgaWRlYSB0byBub3RlIHRoaXMsIHNpbmNlIGlu IHRoZSBKV1Qgc3BlYw0KYWxsIGNsYWltcyBhcmUgb3B0aW9uYWwsIGFuZCBpbmNvcnBvcmF0aW9u IG9mIChhbmQgcmVsaWFuY2Ugb24pIEpXVCBjbGFpbXMgaXMNCmxlZnQgdG8gSldUIHByb2ZpbGVz LiBJLmUuLCB0aGVyZSBhcmd1YWJseSBzaG91bGQgYmUgYWR2aWNlIHRvIEpXVCBwcm9maWxlDQph dXRob3JzIHJlZ2FyZGluZyBzZWN1cml0eSBwcm9wZXJ0aWVzIHJlc3VsdGluZyBmcm9tIGluY29y cG9yYXRpb24gKG9yIG5vdCkgb2YNCnZhcmlvdXMgSldUIGNsYWltcy4NCg0KSFRILA0KDQo9SmVm ZkgNCi0tLS0tLQ0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRo L2N1cnJlbnQvbXNnMTAzMjYuaHRtbA0KDQpbT0FVVEgtV0ddIHJlZ2FyZGluZyBuZXN0ZWQgSldU cyBhbmQgc2VjdXJpdHkNCkZyb206ID1KZWZmSCA8SmVmZi5Ib2RnZXNAS2luZ3NNb3VudGFpbi5j b20+DQpEYXRlOiBGcmksIDIxIERlYyAyMDEyIDE1OjA3OjM1IC0wODAwDQpUbzogSUVURiBvYXV0 aCBXRyA8b2F1dGhAaWV0Zi5vcmc+DQoNCiJuZXN0ZWQgSldUcyIgYXJlIG9ubHkgbm9taW5hbGx5 IGRlZmluZWQgaW4gZHJhZnQtaWV0Zi1vYXV0aC1qc29uLXdlYi10b2tlbi0wNQ0KKGFuZCB0aGUg dGVybSBpcyBtaXNzaW5nIGZyb20gdGhlIHRlcm1pbm9sb2d5IHNlY3Rpb24pLg0KDQp0aGUgSldU IHNwZWMgaW1wbGllcyB0aGF0ICJzaWduaW5nIGFuZCB0aGVuIGVuY3J5cHRpbmciIGFuZCAiZW5j cnlwdGluZyBhbmQgdGhlbg0Kc2lnbmluZyIgYXJlIGVxdWl2YWxlbnQuIGhvd2V2ZXIgdGhleSBh cmVuJ3QgaW4gdmFyaW91cyB3YXlzLg0KDQpBeGVsIGFscmVhZHkgcmFpc2VkIHRoaXMgcG9pbnQg aW4uLg0KDQogICAgUmU6IFtqb3NlXSBlbmNyeXB0aW5nIEFORCBzaWduaW5nIGEgdG9rZW4NCiAg ICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2pvc2UvY3VycmVudC9tc2cw MTI2OS5odG1sDQoNCi4uYW5kIGNpdGVkIHRoaXMgcGFwZXIgKHdvcnRoIGNpdGluZyBhZ2Fpbiku Lg0KDQogICAgRGVmZWN0aXZlIFNpZ24gJiBFbmNyeXB0IGluIFMvTUlNRSwgUEtDUyM3LCBNT1NT LCBQRU0sIFBHUCwgYW5kIFhNTA0KICAgIERvbiBEYXZpcw0KICAgIGh0dHA6Ly93b3JsZC5zdGQu Y29tL35kdGQvc2lnbl9lbmNyeXB0L3NpZ25fZW5jcnlwdDcuaHRtbA0KDQpodHRwOi8vY2l0ZXNl ZXJ4LmlzdC5wc3UuZWR1L3ZpZXdkb2MvZG93bmxvYWQ/ZG9pPTEwLjEuMS4yOC43Mzc5JnJlcD1y ZXAxJnR5cGU9cGRmDQoNCg0KT25lIGhhcyB0byBjYXJlZnVsbHkgY29tcG9zZSBzaWduaW5nIGFu ZCBlbmNyeXB0aW9uIGluIG9yZGVyIHRvIGF2b2lkIHZhcmlvdXMNCnZ1bG5lcmFiaWxpdGllcyBk ZXRhaWxlZCBpbiB0aGUgbGF0dGVyLg0KDQpJIGFncmVlIHdpdGggQXhlbCB0aGF0IHRoZXJlIHNo b3VsZCBiZSBvbmUgY2FyZWZ1bGx5IGRlc2lnbmVkIHdheSB0byBjcmFmdCBhDQpzaWduZWQgYW5k IGVuY3J5cHRlZCBKVyouDQoNCk5vdGUgdGhhdCBpbiB0aGUgSlNNUyBkcmFmdCAoZHJhZnQtcmVz Y29ybGEtanNtcy0wMDsgYW4gZWFybHkgaW5wdXQgaW50byB3aGF0DQpiZWNhbWUgdGhlIEpPU0Ug V0cpLCBzaWduICYgZW5jcnlwdCBjb21wb3NpdGlvbiBpcyBkZWNsYXJlZC4uDQoNCiAgPiA0LjYu ICBDb21wb3NpdGlvbg0KICA+DQogID4gICAgVGhpcyBkb2N1bWVudCBkb2VzIG5vdCBzcGVjaWZ5 IGEgY29tYmluYXRpb24gc2lnbmVkIGFuZCBlbmNyeXB0ZWQNCiAgPiAgICBtb2RlLiAgSG93ZXZl ciwgYmVjYXVzZSB0aGUgY29udGVudHMgb2YgYSBtZXNzYWdlIGNhbiBiZSBhcmJpdHJhcnksDQog ID4gICAgYW5kIGVuY3J5cHRpb24gYW5kIGRhdGEgb3JpZ2luIGF1dGhlbnRpY2F0aW9uIGNhbiBi ZSBwcm92aWRlZCBieQ0KICA+ICAgIHJlY3Vyc2l2ZWx5IGVuY2Fwc3VsYXRpbmcgbXVsdGlwbGUg SlNNUyBtZXNzYWdlcy4gIEluIGdlbmVyYWwsDQogID4gICAgc2VuZGVycyBTSE9VTEQgc2lnbiB0 aGUgbWVzc2FnZSBhbmQgdGhlbiBlbmNyeXB0IHRoZSByZXN1bHQgKHRodXMNCiAgPiAgICBlbmNy eXB0aW5nIHRoZSBzaWduYXR1cmUpLiAgVGhpcyBwcmV2ZW50cyBhdHRhY2tzIGluIHdoaWNoIHRo ZQ0KICA+ICAgIHNpZ25hdHVyZSBpcyBzdHJpcHBlZCwgbGVhdmluZyBqdXN0IGFuIGVuY3J5cHRl ZCBtZXNzYWdlLCBhcyB3ZWxsIGFzDQogID4gICAgcHJvdmlkaW5nIHByaXZhY3kgZm9yIHRoZSBz aWduZXIuDQoNCi4udGhvIHRoYXQncyBhIGRyYWZ0eSBkcmFmdCBhbmQgSSBkaWRuJ3QgcmV2aWV3 IGNhcmVmdWxseSBlbm91Z2ggdG8gZGV0ZXJtaW5lDQp3aGV0aGVyIGl0IGFkZHJlc3NlcyB0aGUg bmVlZCBmb3Igc2lnbiBhbmQgZW5jcnlwdCB0byBjcm9zcy1yZWZlciAoc2VlIFM0LjMgaW4NCnRo ZSBwYXBlcikuDQoNCg0KSFRILA0KDQo9SmVmZkgNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3Jn DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo= --_000_4E1F6AAD24975D4BA5B168042967394367530168TK5EX14MBXC284r_ Content-Type: text/html; charset="utf-8" Content-ID: <10FFDF1F1CF33C4DB6C125D0A6FDCE54@microsoft.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZSBkYXRhLWV4dGVybmFsc3R5bGU9InRy dWUiPgpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0 UGFyYWdyYXBoIHsKbWFyZ2luLXRvcDowaW47Cm1hcmdpbi1yaWdodDowaW47Cm1hcmdpbi1ib3R0 b206MGluOwptYXJnaW4tbGVmdDouNWluOwptYXJnaW4tYm90dG9tOi4wMDAxcHQ7Cn0KCnAuTXNv TGlzdFBhcmFncmFwaEN4U3BGaXJzdCwgbGkuTXNvTGlzdFBhcmFncmFwaEN4U3BGaXJzdCwgZGl2 Lk1zb0xpc3RQYXJhZ3JhcGhDeFNwRmlyc3QsIHAuTXNvTGlzdFBhcmFncmFwaEN4U3BNaWRkbGUs IGxpLk1zb0xpc3RQYXJhZ3JhcGhDeFNwTWlkZGxlLCBkaXYuTXNvTGlzdFBhcmFncmFwaEN4U3BN aWRkbGUsIHAuTXNvTGlzdFBhcmFncmFwaEN4U3BMYXN0LCBsaS5Nc29MaXN0UGFyYWdyYXBoQ3hT cExhc3QsIGRpdi5Nc29MaXN0UGFyYWdyYXBoQ3hTcExhc3QgewptYXJnaW4tdG9wOjBpbjsKbWFy Z2luLXJpZ2h0OjBpbjsKbWFyZ2luLWJvdHRvbTowaW47Cm1hcmdpbi1sZWZ0Oi41aW47Cm1hcmdp bi1ib3R0b206LjAwMDFwdDsKbGluZS1oZWlnaHQ6MTE1JTsKfQo8L3N0eWxlPg0KPC9oZWFkPg0K PGJvZHk+DQo8ZGl2IGRhdGEtZXh0ZXJuYWxzdHlsZT0iZmFsc2UiIHN0eWxlPSJmb250LWZhbWls eTpDYWxpYnJpLCdTZWdvZSBVSScsTWVpcnlvLCdNaWNyb3NvZnQgWWFIZWkgVUknLCdNaWNyb3Nv ZnQgSmhlbmdIZWkgVUknLCdNYWxndW4gR290aGljJywnS2htZXIgVUknLCdOaXJtYWxhIFVJJyxU dW5nYSwnTGFvIFVJJyxFYnJpbWEsc2Fucy1zZXJpZjtmb250LXNpemU6MTZweDsiPg0KPGRpdj5U aGFua3MgYWdhaW4gZm9yIHRoZSB0aG9yb3VnaCBhbmQgdXNlZnVsIGZlZWRiYWNrLCBKZWZmLiZu YnNwOyBJ4oCZbGwgd29yayBvbiBpbmNvcnBvcmF0aW5nIGl0IGluIHRoZSBuZXh0IEpXVCBkcmFm dC48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2Pkl0IHdhcyBncmVhdCBzZWVpbmcgeW91 IGluIE9ybGFuZG8hPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj4tLSBNaWtlPC9kaXY+ DQo8ZGl2IGRhdGEtc2lnbmF0dXJlYmxvY2s9InRydWUiPiZuYnNwOzwvZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyLXRvcC1jb2xvcjogcmdiKDIyNSwgMjI1LCAyMjUpOyBib3JkZXItdG9wLXdpZHRo OiAxcHg7IGJvcmRlci10b3Atc3R5bGU6IHNvbGlkOyI+DQo8c3Ryb25nPkZyb206PC9zdHJvbmc+ Jm5ic3A7PUplZmZIPGJyPg0KPHN0cm9uZz5TZW50Ojwvc3Ryb25nPiZuYnNwO+KAjk1hcmNo4oCO IOKAjjE14oCOLCDigI4yMDEzIOKAjjEw4oCOOuKAjjEx4oCOIOKAjkFNPGJyPg0KPHN0cm9uZz5U bzo8L3N0cm9uZz4mbmJzcDtJRVRGIG9hdXRoIFdHPGJyPg0KPHN0cm9uZz5TdWJqZWN0Ojwvc3Ry b25nPiZuYnNwO1JlOiBbT0FVVEgtV0ddIHJlZ2FyZGluZyBuZXN0ZWQgSldUcyBhbmQgc2VjdXJp dHk8YnI+DQo8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQpEdXJpbmcgdGhlIE9BdXRoIDJuZCBz ZXNzaW9uIGF0IElFVEYtODYgb3JsYW5kbywgYWZ0ZXIgSSBtZW50aW9uZWQgdGhlIDxicj4NCnNp Z24tdGhlbi1lbmNyeXB0IGNvbnNpZGVyYXRpb25zIGF0IHRoZSBtaWMsIEJyYWQgSGlsbCBwb2lu dGVkIG91dCB0aGF0IHRoZSA8YnI+DQpiZWxvdyBwYXBlciBpcyBwZXJoYXBzIGFuIGV2ZW4gbW9y ZSBmdW5kYW1lbnRhbCByZWZlcmVuY2UgZm9yIHRoZSA8YnI+DQpzaWdoLXRoZW4tZW5jcnlwdCBj b21wb3NpdGlvbiB0aGFuIHRoZSBEYXZpcyBwYXBlciBJIHBvaW50ZWQgdG8gaW4gdGhlIGJlbG93 IDxicj4NCmF0dGFjaGVkIG1lc3NhZ2UgYmFjayBpbiBEZWMtMjAxMi4uPGJyPg0KPGJyPg0KJm5i c3A7Jm5ic3A7IEF1dGhlbnRpY2F0ZWQgRW5jcnlwdGlvbjogUmVsYXRpb25zIGFtb25nIG5vdGlv bnMgYW5kIGFuYWx5c2lzPGJyPg0KJm5ic3A7Jm5ic3A7IG9mIHRoZSBnZW5lcmljIGNvbXBvc2l0 aW9uIHBhcmFkaWdtICgyMDA3KTxicj4NCiZuYnNwOyZuYnNwOyBCZWxsYXJlICZhbXA7IE5hbXBy ZW1wcmU8YnI+DQombmJzcDsmbmJzcDsgaHR0cDovL2VwcmludC5pYWNyLm9yZy8yMDAwLzAyNS5w ZGY8YnI+DQo8YnI+DQpBZnRlciBoYXZpbmcgdGFsa2VkIHdpdGggTWlrZSBKb25lcyBmMmYgZWFy bGllciBpbiB0aGUgd2VlayBhYm91dCB0aGlzIHN0dWZmLCA8YnI+DQpkdXJpbmcgd2hpY2ggaGUg aW5kaWNhdGVkIGhlIGJlbGlldmVkIHRoYXQgdGhlc2UgaXNzdWVzIGFyZSBhZGRyZXNzZWQgaW4g dGhlIEpXVCA8YnI+DQpzcGVjLCBJIGxvb2tlZCBhdCBkcmFmdC1pZXRmLW9hdXRoLWpzb24td2Vi LXRva2VuLTA2IGFuZCBub3RlIHRoYXQgdGhlIGxhc3QgPGJyPg0KcGFyYWdyYXBoIG9mIHRoZSBz ZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzYXlzLi48YnI+DQo8YnI+DQombmJzcDsmbmJzcDsmbmJz cDsgV2hpbGUgc3ludGFjdGljYWxseSwgdGhlIHNpZ25pbmcgYW5kIGVuY3J5cHRpb24gb3BlcmF0 aW9ucyBmb3IgTmVzdGVkPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IEpXVHMgbWF5IGJlIGFwcGxp ZWQgaW4gYW55IG9yZGVyLCBub3JtYWxseSBzZW5kZXJzIHNob3VsZCBzaWduIHRoZTxicj4NCiZu YnNwOyZuYnNwOyZuYnNwOyBtZXNzYWdlIGFuZCB0aGVuIGVuY3J5cHQgdGhlIHJlc3VsdCAodGh1 cyBlbmNyeXB0aW5nIHRoZSBzaWduYXR1cmUpLjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyBUaGlz IHByZXZlbnRzIGF0dGFja3MgaW4gd2hpY2ggdGhlIHNpZ25hdHVyZSBpcyBzdHJpcHBlZCwgbGVh dmluZzxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyBqdXN0IGFuIGVuY3J5cHRlZCBtZXNzYWdlLCBh cyB3ZWxsIGFzIHByb3ZpZGluZyBwcml2YWN5IGZvciB0aGU8YnI+DQombmJzcDsmbmJzcDsmbmJz cDsgc2lnbmVyLiZuYnNwOyBGdXJ0aGVybW9yZSwgc2lnbmF0dXJlcyBvdmVyIGVuY3J5cHRlZCB0 ZXh0IGFyZSBub3Q8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgY29uc2lkZXJlZCB2YWxpZCBpbiBt YW55IGp1cmlzZGljdGlvbnMuPGJyPg0KPGJyPg0KLi53aGljaCBjZXJ0YWlubHkgdG91Y2hlcyB1 cG9uIHRoZSBpc3N1ZShzKSwgYnV0IGNvdWxkIGFyZ3VhYmx5IGNvbnRhaW4gbW9yZSA8YnI+DQpy YXRpb25hbGUuIFRob3VnaCwgaWYgeW91IHdpc2ggdGhlIHNwZWMgdG8gYmUgdGVyc2UgKGFzIGFi b3ZlKSB5b3Ugc2hvdWxkIDxicj4NCnByb2JhYmx5IGF0IGxlYXN0IHJlZmVyZW5jZSBEYXZpcyAo d2hpY2ggaXMgcmVzb25hYmx5IGFwcHJvYWNoYWJsZSkgYW5kIEJlbGxhcmUgPGJyPg0KJmFtcDsg TmFtcHJlbXByZSAod2hpY2ggaXMgYSBmb3JtYWwgcHJvb2YpLjxicj4NCjxicj4NCkFsc28sIGlu IHRlcm1zIG9mIGxpbmthZ2VzIGJldHdlZW4gc2lnbmluZyBhbmQgZW5jcnlwdGluZyB3cmFwcGVy cywgaXQgc2VlbXMgPGJyPg0KdGhhdCBpZiBvbmUgaW5jbHVkZXMgYXQgbGVhc3QgYW4gYXVkaWVu Y2UgY2xhaW0gaW4gdGhlIEpXVCBDbGFpbXMgU2V0LCBpbiBhIDxicj4NCnNpZ25lZCAmYW1wOyBl bmNyeXB0ZWQgSldUIChha2EgJnF1b3Q7TmVzdGVkIEpXVCZxdW90OyksIGFuZCB0aGUgcmVjZWl2 ZXIgb2YgdGhlIEpXVCBjaGVja3MgPGJyPg0KdGhlIGF1ZGllbmNlIGFuZCBkb2VzIG5vdCByZWx5 IG9uIHRoZSBKV1QgaWYgaXQgZG9lcyBub3QgaWRlbnRpZnkgdGhlbSwgdGhlbiB5b3UgPGJyPg0K YXJlIGFyZ3VhYmx5IGluIG9rIHNoYXBlLiBJZiB0aGUgSldUIGluY2x1ZGVzIGJvdGggc3ViamVj dCBhbmQgYXVkaWVuY2UgY2xhaW1zLCA8YnI+DQp0aGF0IHdvdWxkIGJlIGJlc3QuIEl0IG1heSBi ZSBhIGdvb2QgaWRlYSB0byBub3RlIHRoaXMsIHNpbmNlIGluIHRoZSBKV1Qgc3BlYyA8YnI+DQph bGwgY2xhaW1zIGFyZSBvcHRpb25hbCwgYW5kIGluY29ycG9yYXRpb24gb2YgKGFuZCByZWxpYW5j ZSBvbikgSldUIGNsYWltcyBpcyA8YnI+DQpsZWZ0IHRvIEpXVCBwcm9maWxlcy4gSS5lLiwgdGhl cmUgYXJndWFibHkgc2hvdWxkIGJlIGFkdmljZSB0byBKV1QgcHJvZmlsZSA8YnI+DQphdXRob3Jz IHJlZ2FyZGluZyBzZWN1cml0eSBwcm9wZXJ0aWVzIHJlc3VsdGluZyBmcm9tIGluY29ycG9yYXRp b24gKG9yIG5vdCkgb2YgPGJyPg0KdmFyaW91cyBKV1QgY2xhaW1zLjxicj4NCjxicj4NCkhUSCw8 YnI+DQo8YnI+DQo9SmVmZkg8YnI+DQotLS0tLS08YnI+DQo8YnI+DQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMTAzMjYuaHRtbDxicj4NCjxi cj4NCltPQVVUSC1XR10gcmVnYXJkaW5nIG5lc3RlZCBKV1RzIGFuZCBzZWN1cml0eTxicj4NCkZy b206ID1KZWZmSCAmbHQ7SmVmZi5Ib2RnZXNAS2luZ3NNb3VudGFpbi5jb20mZ3Q7PGJyPg0KRGF0 ZTogRnJpLCAyMSBEZWMgMjAxMiAxNTowNzozNSAtMDgwMDxicj4NClRvOiBJRVRGIG9hdXRoIFdH ICZsdDtvYXV0aEBpZXRmLm9yZyZndDs8YnI+DQo8YnI+DQomcXVvdDtuZXN0ZWQgSldUcyZxdW90 OyBhcmUgb25seSBub21pbmFsbHkgZGVmaW5lZCBpbiBkcmFmdC1pZXRmLW9hdXRoLWpzb24td2Vi LXRva2VuLTA1PGJyPg0KKGFuZCB0aGUgdGVybSBpcyBtaXNzaW5nIGZyb20gdGhlIHRlcm1pbm9s b2d5IHNlY3Rpb24pLjxicj4NCjxicj4NCnRoZSBKV1Qgc3BlYyBpbXBsaWVzIHRoYXQgJnF1b3Q7 c2lnbmluZyBhbmQgdGhlbiBlbmNyeXB0aW5nJnF1b3Q7IGFuZCAmcXVvdDtlbmNyeXB0aW5nIGFu ZCB0aGVuPGJyPg0Kc2lnbmluZyZxdW90OyBhcmUgZXF1aXZhbGVudC4gaG93ZXZlciB0aGV5IGFy ZW4ndCBpbiB2YXJpb3VzIHdheXMuPGJyPg0KPGJyPg0KQXhlbCBhbHJlYWR5IHJhaXNlZCB0aGlz IHBvaW50IGluLi48YnI+DQo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgUmU6IFtqb3NlXSBlbmNy eXB0aW5nIEFORCBzaWduaW5nIGEgdG9rZW48YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9qb3NlL2N1cnJlbnQvbXNnMDEyNjkuaHRt bDxicj4NCjxicj4NCi4uYW5kIGNpdGVkIHRoaXMgcGFwZXIgKHdvcnRoIGNpdGluZyBhZ2Fpbiku Ljxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyBEZWZlY3RpdmUgU2lnbiAmYW1wOyBFbmNy eXB0IGluIFMvTUlNRSwgUEtDUyM3LCBNT1NTLCBQRU0sIFBHUCwgYW5kIFhNTDxicj4NCiZuYnNw OyZuYnNwOyZuYnNwOyBEb24gRGF2aXM8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgaHR0cDovL3dv cmxkLnN0ZC5jb20vfmR0ZC9zaWduX2VuY3J5cHQvc2lnbl9lbmNyeXB0Ny5odG1sPGJyPg0KPGJy Pg0KaHR0cDovL2NpdGVzZWVyeC5pc3QucHN1LmVkdS92aWV3ZG9jL2Rvd25sb2FkP2RvaT0xMC4x LjEuMjguNzM3OSZhbXA7cmVwPXJlcDEmYW1wO3R5cGU9cGRmPGJyPg0KPGJyPg0KPGJyPg0KT25l IGhhcyB0byBjYXJlZnVsbHkgY29tcG9zZSBzaWduaW5nIGFuZCBlbmNyeXB0aW9uIGluIG9yZGVy IHRvIGF2b2lkIHZhcmlvdXM8YnI+DQp2dWxuZXJhYmlsaXRpZXMgZGV0YWlsZWQgaW4gdGhlIGxh dHRlci48YnI+DQo8YnI+DQpJIGFncmVlIHdpdGggQXhlbCB0aGF0IHRoZXJlIHNob3VsZCBiZSBv bmUgY2FyZWZ1bGx5IGRlc2lnbmVkIHdheSB0byBjcmFmdCBhPGJyPg0Kc2lnbmVkIGFuZCBlbmNy eXB0ZWQgSlcqLjxicj4NCjxicj4NCk5vdGUgdGhhdCBpbiB0aGUgSlNNUyBkcmFmdCAoZHJhZnQt cmVzY29ybGEtanNtcy0wMDsgYW4gZWFybHkgaW5wdXQgaW50byB3aGF0PGJyPg0KYmVjYW1lIHRo ZSBKT1NFIFdHKSwgc2lnbiAmYW1wOyBlbmNyeXB0IGNvbXBvc2l0aW9uIGlzIGRlY2xhcmVkLi48 YnI+DQo8YnI+DQombmJzcDsgJmd0OyA0LjYuJm5ic3A7IENvbXBvc2l0aW9uPGJyPg0KJm5ic3A7 ICZndDs8YnI+DQombmJzcDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBUaGlzIGRvY3VtZW50IGRv ZXMgbm90IHNwZWNpZnkgYSBjb21iaW5hdGlvbiBzaWduZWQgYW5kIGVuY3J5cHRlZDxicj4NCiZu YnNwOyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG1vZGUuJm5ic3A7IEhvd2V2ZXIsIGJlY2F1c2Ug dGhlIGNvbnRlbnRzIG9mIGEgbWVzc2FnZSBjYW4gYmUgYXJiaXRyYXJ5LDxicj4NCiZuYnNwOyAm Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFuZCBlbmNyeXB0aW9uIGFuZCBkYXRhIG9yaWdpbiBhdXRo ZW50aWNhdGlvbiBjYW4gYmUgcHJvdmlkZWQgYnk8YnI+DQombmJzcDsgJmd0OyZuYnNwOyZuYnNw OyZuYnNwOyByZWN1cnNpdmVseSBlbmNhcHN1bGF0aW5nIG11bHRpcGxlIEpTTVMgbWVzc2FnZXMu Jm5ic3A7IEluIGdlbmVyYWwsPGJyPg0KJm5ic3A7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsgc2Vu ZGVycyBTSE9VTEQgc2lnbiB0aGUgbWVzc2FnZSBhbmQgdGhlbiBlbmNyeXB0IHRoZSByZXN1bHQg KHRodXM8YnI+DQombmJzcDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBlbmNyeXB0aW5nIHRoZSBz aWduYXR1cmUpLiZuYnNwOyBUaGlzIHByZXZlbnRzIGF0dGFja3MgaW4gd2hpY2ggdGhlPGJyPg0K Jm5ic3A7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsgc2lnbmF0dXJlIGlzIHN0cmlwcGVkLCBsZWF2 aW5nIGp1c3QgYW4gZW5jcnlwdGVkIG1lc3NhZ2UsIGFzIHdlbGwgYXM8YnI+DQombmJzcDsgJmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyBwcm92aWRpbmcgcHJpdmFjeSBmb3IgdGhlIHNpZ25lci48YnI+ DQo8YnI+DQouLnRobyB0aGF0J3MgYSBkcmFmdHkgZHJhZnQgYW5kIEkgZGlkbid0IHJldmlldyBj YXJlZnVsbHkgZW5vdWdoIHRvIGRldGVybWluZTxicj4NCndoZXRoZXIgaXQgYWRkcmVzc2VzIHRo ZSBuZWVkIGZvciBzaWduIGFuZCBlbmNyeXB0IHRvIGNyb3NzLXJlZmVyIChzZWUgUzQuMyBpbjxi cj4NCnRoZSBwYXBlcikuPGJyPg0KPGJyPg0KPGJyPg0KSFRILDxicj4NCjxicj4NCj1KZWZmSDxi cj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K T0F1dGggbWFpbGluZyBsaXN0PGJyPg0KT0F1dGhAaWV0Zi5vcmc8YnI+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPGJyPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_4E1F6AAD24975D4BA5B168042967394367530168TK5EX14MBXC284r_-- From phil.hunt@oracle.com Sat Mar 16 02:51: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 8246C21F8AA6 for ; Sat, 16 Mar 2013 02:51:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.902 X-Spam-Level: X-Spam-Status: No, score=-4.902 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_25=0.6, 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 0r2iztqpH2tb for ; Sat, 16 Mar 2013 02:51:42 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id EDB1C21F8A8E for ; Sat, 16 Mar 2013 02:51:41 -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 r2G9pefl000379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 16 Mar 2013 09:51:40 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r2G9pdV7027741 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 16 Mar 2013 09:51:40 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r2G9pdMP001642; Sat, 16 Mar 2013 04:51:39 -0500 Received: from [192.168.156.29] (/98.79.94.25) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 16 Mar 2013 02:51:39 -0700 References: <4E1F6AAD24975D4BA5B16804296739436752C010@TK5EX14MBXC284.redmond.corp.microsoft.com> Mime-Version: 1.0 (1.0) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436752C010@TK5EX14MBXC284.redmond.corp.microsoft.com> Content-Type: multipart/alternative; boundary=Apple-Mail-C246926A-C99D-43AB-9386-DF3023213823 Content-Transfer-Encoding: 7bit Message-Id: <577837CC-A415-4F7E-82A2-CDB21859650C@oracle.com> X-Mailer: iPhone Mail (10B146) From: Phil Hunt Date: Sat, 16 Mar 2013 05:51:38 -0400 To: Mike Jones X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] JWT grant_type and client_id X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Mar 2013 09:51:43 -0000 --Apple-Mail-C246926A-C99D-43AB-9386-DF3023213823 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable It's a question of whether the jwt spec alone is used (in which case it need= s scope) or whether another profile for access tokens is needed.=20 Since scope is fundamental to oauth, i think it is part if the core set of m= inimal attributes for access tokens. In fact i cab envision cases where ref= erences to authorizing user or client might be eliminated or anonymized leav= ing only one. Eg grant the holder of this token the right to do scope xyz.=20= Phil Sent from my phone. On 2013-03-15, at 21:03, Mike Jones wrote: > Having a scope claim in specific profiles could make sense. That doesn=E2= =80=99t mean that it has to be defined in the JWT spec per se. If anything,= people expressed a desire in yesterday=E2=80=99s working group meeting to k= eep the base claims set small, rather than expanding it. > =20 > Profiles can register the claims they define in the IANA JWT Claims regist= ry, if they choose. > =20 > -- Mike > =20 > =20 > From: Lewis Adam-CAL022 > Sent: =E2=80=8EMarch=E2=80=8E =E2=80=8E15=E2=80=8E, =E2=80=8E2013 =E2=80=8E= 3=E2=80=8E:=E2=80=8E55=E2=80=8E =E2=80=8EPM > To: Brian Campbell > CC: oauth@ietf.org > Subject: Re: [OAUTH-WG] JWT grant_type and client_id > =20 > I guess that it depends on what JWT is meant to be. My understanding is t= hat it began as something to support Web SSO authentication for OIDC, so sco= pe didn=E2=80=99t make any sense then. Nor does it make any sense as a stri= ct grant type. The use case where it becomes interesting (the one I am look= ing to) is for when an access token or refresh token is a JWT. I think some= vendors are beginning to make their structured tokens a JWT, and that is my= current thinking as well =E2=80=A6 if folks agree that JWT can be used as t= he structure for OAuth tokens, then it makes sense to include a scope field.= If not, then it will be JSON+encryption+signing, just not a JWT J > =20 > adam > =20 > From: Brian Campbell [mailto:bcampbell@pingidentity.com]=20 > Sent: Friday, March 15, 2013 5:16 PM > To: Lewis Adam-CAL022 > Cc: Sergey Beryozkin; oauth@ietf.org > Subject: Re: [OAUTH-WG] JWT grant_type and client_id > =20 > Codifying a claim/attribute for scope that goes in the assertion is someth= ing that's been discussed but never seemed to get sufficient consensus regar= ding how to exactly to do it and if it really provided much value. > =20 >=20 > On Fri, Mar 15, 2013 at 4:12 PM, Brian Campbell wrote: > So currently the base assertion document defines scope as an HTTP paramete= r on the access token request message when using an assertion as a grant[1].= And that applies to both the SAML and JWT grants (perhaps that needs to be= more clear?). Also RFC 6749 defines the scope parameter for the client cred= entials access token request[2], which similarly applies to both SAML and JW= T in the case of assertion client authentication using the "client_credentia= ls" grant type. >=20 > [1] http://tools.ietf.org/html/draft-ietf-oauth-assertions-10#section-4.1=20= > [2] http://tools.ietf.org/html/rfc6749#section-4.4.1 > =20 >=20 > On Fri, Mar 15, 2013 at 3:43 PM, Lewis Adam-CAL022 wrote: > Right ... thinking about this further I think the answer is "all of the ab= ove." If the JWT is a grant type then as you say it needs a scope param and= optionally a client_id param. I argued for the client_id param earlier sin= ce it could assist with HOK scenarios once those further develop. >=20 > But when the JWT is used as an AT then it will definitely require the scop= e as a claim. >=20 > So I change my argument to "both" :) >=20 > adam >=20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of S= ergey Beryozkin > Sent: Friday, March 15, 2013 4:31 PM > To: oauth@ietf.org > Subject: Re: [OAUTH-WG] JWT grant_type and client_id >=20 > Hi > On 15/03/13 20:40, Lewis Adam-CAL022 wrote: > > Hi John, > > > > I would like to argue that the scope should be a parameter in the access= > > token request message, the same as it is for the RO creds grant and > > client creds grant type. This would keep it consistent with the core > > OAuth grant types that talk directly to the token endpoint. > > > Assuming the assertion is acting as a grant, then it is indeed an access > token request message, so IMHO it makes sense to get an outbound scope > parameter optionally supported which I guess will imply that the client > id will also have to accompany it... >=20 > Cheers, Sergey >=20 > > Thoughts? > > > > adam > > > > *From:*John Bradley [mailto:ve7jtb@ve7jtb.com] > > *Sent:* Friday, March 15, 2013 12:10 PM > > *To:* Lewis Adam-CAL022 > > *Cc:* Brian Campbell; "WG "@il06exr02.mot.com > > *Subject:* Re: [OAUTH-WG] JWT grant_type and client_id > > > > The spec is a touch vague on that. I think the scopes should be in the > > assertion and the client can use the scopes outside the assertion to > > down-scope. > > > > Having a standard claim in JWT and SAML for passing scopes is probably > > useful as part of a profile. > > > > John B. > > > > On 2013-03-14, at 8:47 PM, Lewis Adam-CAL022 > > > > wrote: > > > > > > > > Hmmm, one more thought ... no scope?? The JWT is the grant, is it assume= d > > that the scope is conveyed as a claim within the token? Otherwise it > > would seem that it would require a scope. > > > > Thoughts? > > > > adam > > > > *From:*Brian Campbell [mailto:bcampbell@pingidentity.com > > ] > > *Sent:*Thursday, March 14, 2013 4:44 PM > > *To:*Lewis Adam-CAL022 > > *Cc:*Mike Jones; "WG > >"@il06exr02.mot.com > > *Subject:*Re: [OAUTH-WG] JWT grant_type and client_id > > > > Yes, that is correct. > > > > I'm working on new revisions of the drafts that will hopefully make that= > > point more clear. > > > > On Thu, Mar 14, 2013 at 5:26 PM, Lewis Adam-CAL022 > > > > wrote: > > > > Coming back to this... am I correct in that client_id is not required? = We are implementing this spec and want to make sure that we are doing it r= ight. By my understanding the only two parameters that are required in th= e JWT grant type are "urn:ietf:params:oauth:grant-type:jwt-bearer" and t= he assertion. Is this correct? > > > > *From:*Mike Jones [mailto:Michael.Jones@microsoft.com > > ] > > *Sent:*Monday, February 18, 2013 6:58 PM > > *To:*Lewis Adam-CAL022;oauth@ietf.org WG > > *Subject:*RE: JWT grant_type and client_id > > > > The client_id value and the access token value are independent. > > > > -- Mike > > > > *From:*oauth-bounces@ietf.org > > [mailto:oauth-bounces@ietf.org > > ]*On Behalf Of*Lewis Adam-CAL022 > > *Sent:*Monday, February 18, 2013 2:50 PM > > *To:*oauth@ietf.org WG > > *Subject:*[OAUTH-WG] JWT grant_type and client_id > > > > Is there any guidance on the usage of client_id when using the JWT > > assertion profile as a grant type? draft-ietf-oauth-jwt-bearer-04 makes > > no mention so I assume that it is not required ... but it would be > > necessary if using in conjunction with a HOK profile where the JWT > > assertion is issued to - and may only be used by - the intended client. > > Obviously this is straight forward enough, really I'm just looking to be= > > sure that I'm not missing anything. > > > > tx > > > > adam > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=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-C246926A-C99D-43AB-9386-DF3023213823 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
It's a question of whether the jwt spe= c alone is used (in which case it needs scope) or whether another profile fo= r access tokens is needed. 

Since scope is fun= damental to oauth, i think it is part if the core set of minimal attributes f= or access tokens.  In fact i cab envision cases where references to aut= horizing user or client might be eliminated or anonymized leaving only one. E= g grant the holder of this token the right to do scope xyz. 

Phi= l

Sent from my phone.

On 2013-03-15, a= t 21:03, Mike Jones <Micha= el.Jones@microsoft.com> wrote:

<= blockquote type=3D"cite">
Having a scope claim in specific profiles could make sense.  That d= oesn=E2=80=99t mean that it has to be defined in the JWT spec per se.  I= f anything, people expressed a desire in yesterday=E2=80=99s working group m= eeting to keep the base claims set small, rather than expanding it.
 
Profiles can register the claims they de= fine in the IANA JWT Claims registry, if they choose.
 
-- Mike
 
 
From: Lewis Adam-CAL022
Sent: =E2=80=8EMarch=E2=80=8E =E2=80=8E15=E2=80=8E, =E2= =80=8E2013 =E2=80=8E3=E2=80=8E:=E2=80=8E55=E2=80=8E =E2=80=8EPM
To: Brian Campbell
CC: oauth@ietf.org
Subject: Re: [OAUTH-WG] JWT grant_type and client_id
 

I guess that i= t depends on what JWT is meant to be.  My understanding is that it bega= n as something to support Web SSO authentication for OIDC, so scope didn=E2=80=99t make any sense then.  Nor does it make any sen= se as a strict grant type.  The use case where it becomes interesting (= the one I am looking to) is for when an access token or refresh token is a J= WT.  I think some vendors are beginning to make their structured tokens a JWT, and that is my current thinking as well =E2=80= =A6 if folks agree that JWT can be used as the structure for OAuth tokens, t= hen it makes sense to include a scope field.  If not, then it will be J= SON+encryption+signing, just not a JWT J

 =

adam

 =

From: Brian C= ampbell [mailto:bcampbell@ping= identity.com]
Sent: Friday, March 15, 2013 5:16 PM
To: Lewis Adam-CAL022
Cc: Sergey Beryozkin; oauth@ietf.or= g
Subject: Re: [OAUTH-WG] JWT grant_type and client_id

 

Codifying a claim/attribute for scope that goes in t= he assertion is something that's been discussed but never seemed to get suff= icient consensus regarding how to exactly to do it and if it really provided= much value.

 

On Fri, Mar 15, 2013 at 4:12 PM, Brian Campbell <= bcampbell@ping= identity.com> wrote:

So currently the base assertion document defines sco= pe as an HTTP parameter on the access token request message when using an as= sertion as a grant[1].  And that applies to both the SAML and JWT grant= s (perhaps that needs to be more clear?). Also RFC 6749 defines the scope parameter for the client credentials access= token request[2], which similarly applies to both SAML and JWT in the case o= f assertion client authentication using the "client_credentials" grant type.=

[1] http://tools.ietf.org/html/draft-ietf-oauth-assertions-10#section-4.1 [2] http://tools.ietf.org/html/rfc6749#section-4.4.1

 

On Fri, Mar 15, 2013 at 3:43 PM, Lewis Adam-CAL022 &= lt;Adam.= Lewis@motorolasolutions.com> wrote:

Right ... thinking about this further I think the an= swer is "all of the above."  If the JWT is a grant type then as you say= it needs a scope param and optionally a client_id param.  I argued for= the client_id param earlier since it could assist with HOK scenarios once those further develop.

But when the JWT is used as an AT then it will definitely require the scope a= s a claim.

So I change my argument to "both" :)

adam


-----Original Message-----
From: oauth-bounce= s@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Sergey Beryozkin
Sent: Friday, March 15, 2013 4:31 PM
To: oauth@ietf.org
= Subject: Re: [OAUTH-WG] JWT grant_type and client_id

Hi
On 15/03/13 20:40, Lewis Adam-CAL022 wrote:
> Hi John,
>
> I would like to argue that the scope should be a parameter in the acces= s
> token request message, the same as it is for the RO creds grant and
= > client creds grant type. This would keep it consistent with the core > OAuth grant types that talk directly to the token endpoint.
>
Assuming the assertion is acting as a grant, then it is indeed an access
= token request message, so IMHO it makes sense to get an outbound scope
parameter optionally supported which I guess will imply that the client
id will also have to accompany it...

Cheers, Sergey

> Thoughts?
>
> adam
>
> *From:*John Bradley [mailto:ve7jtb@ve7jtb.com]
> *Sent:* Friday, March 15, 2013 12:10 PM
> *To:* Lewis Adam-CAL022
> *Cc:* Brian Campbell; "WG <oauth@ietf.org>"@il06exr02.mot.com
> *Subject:* Re: [OAUTH-WG] JWT grant_type and client_id
>
> The spec is a touch vague on that. I think the scopes should be in the<= br> > assertion and the client can use the scopes outside the assertion to > down-scope.
>
> Having a standard claim in JWT and SAML for passing scopes is probably<= br> > useful as part of a profile.
>
> John B.
>
> On 2013-03-14, at 8:47 PM, Lewis Adam-CAL022
> <Adam.Lewis@motorolasolutions.com
> <mailto:Adam.Lewis@motorolasolutions.com>> wrote:
>
>
>

> Hmmm, one more thought ... no scope?? The JWT i= s the grant, is it assumed

> that the scope is conveyed as a claim within th= e token? Otherwise it
> would seem that it would require a scope.
>
> Thoughts?
>
> adam
>
> *From:*Brian Campbell [mailto:bcampbell@pingidentity.com
> <http://pingiden= tity.com>]
> *Sent:*Thursday, March 14, 2013 4:44 PM
> *To:*Lewis Adam-CAL022
> *Cc:*Mike Jones; "WG <oauth@ietf.org
> <mailto:oauth@ietf= .org>>"@il06e= xr02.mot.com <ht= tp://il06exr02.mot.com>
> *Subject:*Re: [OAUTH-WG] JWT grant_type and client_id
>
> Yes, that is correct.
>
> I'm working on new revisions of the drafts that will hopefully make tha= t
> point more clear.
>
> On Thu, Mar 14, 2013 at 5:26 PM, Lewis Adam-CAL022
> <Adam.Lewis@motorolasolutions.com
> <mailto:Adam.Lewis@motorolasolutions.com>> wrote:
>

> Coming back to this...  am I correct in th= at client_id is not required?    We are implementing this spec and= want to make sure that we are doing it right.    By my understand= ing the only two parameters that are required in the JWT grant type are  "urn:ietf:params:oauth:grant-type:jwt-bearer"    a= nd the assertion.      Is this correct?

>
> *From:*Mike Jones [mailto:Michael.Jones@microsoft.com
> <mailto:Michael.Jones@microsoft.com>]
> *Sent:*Monday, February 18, 2013 6:58 PM
> *To:*Lewis Adam-CAL022;oauth@ietf.org <mailto:oauth@ietf.org>WG
> *Subject:*RE: JWT grant_type and client_id
>
> The client_id value and the access token value are independent.
>
> -- Mike
>
> *From:*oauth-= bounces@ietf.org
> <mailto:oa= uth-bounces@ietf.org>[mailto:oauth-bounces@ietf.org
> <mailto:oa= uth-bounces@ietf.org>]*On Behalf Of*Lewis Adam-CAL022
> *Sent:*Monday, February 18, 2013 2:50 PM
> *To:*oauth@ietf.org <mailto:oauth@ietf.o= rg>WG
> *Subject:*[OAUTH-WG] JWT grant_type and client_id
>
> Is there any guidance on the usage of client_id when using the JWT
> assertion profile as a grant type? draft-ietf-oauth-jwt-bearer-04 makes=

> no mention so I assume that it is not required .= .. but it would be

> necessary if using in conjunction with a HOK pr= ofile where the JWT
> assertion is issued to - and may only be used by - the intended client.=
> Obviously this is straight forward enough, really I'm just looking to b= e
> sure that I'm not missing anything.
>
> tx
>
> adam
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org &l= t;mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org &l= t;mailto: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
http= s://www.ietf.org/mailman/listinfo/oauth





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

 

 

____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth
= --Apple-Mail-C246926A-C99D-43AB-9386-DF3023213823-- From stephen.farrell@cs.tcd.ie Sat Mar 16 07:44: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 9D2CA21F8A67 for ; Sat, 16 Mar 2013 07:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.059, 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 SiZF3DGrkbjz for ; Sat, 16 Mar 2013 07:44:25 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF4A21F8A56 for ; Sat, 16 Mar 2013 07:44:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B851ABE77; Sat, 16 Mar 2013 14:44:02 +0000 (GMT) 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 Q+7lU-by+uW3; Sat, 16 Mar 2013 14:44:01 +0000 (GMT) Received: from [172.16.12.81] (unknown [130.129.48.15]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 69BC1BE76; Sat, 16 Mar 2013 14:44:00 +0000 (GMT) Message-ID: <5144852E.7060700@cs.tcd.ie> Date: Sat, 16 Mar 2013 14:43:58 +0000 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: RFC Errata System References: <20130226170711.9FB6072E12F@rfc-editor.org> In-Reply-To: <20130226170711.9FB6072E12F@rfc-editor.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: johnp.field@emc.com, derek@ihtfp.com, oauth@ietf.org Subject: Re: [OAUTH-WG] [Editorial Errata Reported] RFC6749 (3500) X-BeenThere: oauth@ietf.org X-Mailman-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, 16 Mar 2013 14:44:27 -0000 This looks right to me (and I'm in a boring meeting processing errata:-) so I'm gonna mark it as verified. Please let me know if that's wrong. S On 02/26/2013 05:07 PM, RFC Errata System wrote: > The following errata report has been submitted for RFC6749, > "The OAuth 2.0 Authorization Framework". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=6749&eid=3500 > > -------------------------------------- > Type: Editorial > Reported by: John Field > > Section: 4.1 > > Original Text > ------------- > (E) The authorization server authenticates the client, validates the > authorization code, and ensures that the redirection URI > received matches the URI used to redirect the client in > step (C). If valid, the authorization server responds back with > an access token and, optionally, a refresh token. > > Corrected Text > -------------- > (E) The authorization server authenticates the client, validates the > authorization code, and ensures that the redirection URI > received matches the URI used to redirect (the resource owner's user-agent) > to the client in step (C). If valid, the authorization server > responds back with an access token and, optionally, a refresh token. > > Notes > ----- > The URI in question is the URI that was used to redirect the resource owner's user-agent back to the client to deliver the code. The original text in step (E) seems to say that this URI was used to redirect the client, but I think this is an ambiguous/imprecise use of the word "client." It was not the OAuth client that was redirected using that URI, it was the resource owner's user-agent that was redirected, *to* the client. > > The parenthetical (the resource owner's user-agent) is more precise but may perhaps be too verbose. I think, at minimum, we must say "....the URI used to redirect *to* the client in step (C)." > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC6749 (draft-ietf-oauth-v2-31) > -------------------------------------- > Title : The OAuth 2.0 Authorization Framework > Publication Date : October 2012 > Author(s) : D. Hardt, Ed. > Category : PROPOSED STANDARD > Source : Web Authorization Protocol > Area : Security > Stream : IETF > Verifying Party : IESG > From Michael.Jones@microsoft.com Sat Mar 16 10:17: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 78E3821F88C1 for ; Sat, 16 Mar 2013 10:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_25=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 91gHf2qV3S6Y for ; Sat, 16 Mar 2013 10:16:59 -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 7EF2621F8830 for ; Sat, 16 Mar 2013 10:16:59 -0700 (PDT) Received: from BN1AFFO11FD028.protection.gbl (10.58.52.200) by BN1BFFO11HUB022.protection.gbl (10.58.53.132) with Microsoft SMTP Server (TLS) id 15.0.641.9; Sat, 16 Mar 2013 17:16:56 +0000 Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.37) by BN1AFFO11FD028.mail.protection.outlook.com (10.58.52.88) with Microsoft SMTP Server (TLS) id 15.0.641.9 via Frontend Transport; Sat, 16 Mar 2013 17:16:56 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.29]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.02.0318.003; Sat, 16 Mar 2013 17:16:54 +0000 From: Mike Jones To: Phil Hunt Thread-Topic: [OAUTH-WG] JWT grant_type and client_id Thread-Index: Ac4h4g4wygAJgL9ySFC/PJajtkIVLAAScwAAAA9vA+A= Date: Sat, 16 Mar 2013 17:16:53 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394367533A20@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739436752C010@TK5EX14MBXC284.redmond.corp.microsoft.com> <577837CC-A415-4F7E-82A2-CDB21859650C@oracle.com> In-Reply-To: <577837CC-A415-4F7E-82A2-CDB21859650C@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.34] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394367533A20TK5EX14MBXC284r_" 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)(33656001)(20776003)(56816002)(69226001)(16406001)(55846006)(512874001)(50986001)(46102001)(54356001)(53806001)(51856001)(54316002)(66066001)(47446002)(76482001)(79102001)(49866001)(74502001)(47976001)(47736001)(56776001)(31966008)(4396001)(63696002)(77982001)(74662001)(59766001)(65816001)(80022001); DIR:OUT; SFP:; SCL:1; SRVR:BN1BFFO11HUB022; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0787459938 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] JWT grant_type and client_id X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Mar 2013 17:17:01 -0000 --_000_4E1F6AAD24975D4BA5B168042967394367533A20TK5EX14MBXC284r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSB0aGF0IGl04oCZcyBsaWtlbHkgYSBjbGFpbSB0aGF0IHdvdWxkIGJlIHVzZWQgaW4g YWNjZXNzIHRva2Vucy4NCg0KSeKAmW0gY29taW5nIHRvIHRoZSBjb25jbHVzaW9uIHRoYXQgd2Ug c2hvdWxkIGFjdHVhbGx5IHdyaXRlIGFuIGFjY2VzcyB0b2tlbiBwcm9maWxlIGZvciBKV1QgYW5k IHByb2JhYmx5IFNBTUwgYXMgd2VsbC4gIFRoaXMgd291bGQgYmUgcGFyYWxsZWwgdG8gdGhlIGtp bmRzIG9mIHJlcXVpcmVtZW50cyBwbGFjZWQgb24gdGhlIHVzZSBvZiBTQU1MIGFuZCBKV1Qgd2hl biB1c2VkIGZvciBjbGllbnQgYXV0aGVudGljYXRpb24gYW5kIGFzIHJlc291cmNlIGdyYW50cy4g IFRoaXMgY291bGQgb25seSBoZWxwIGludGVyb3BlcmFiaWxpdHksIGFzIHBlb3BsZSB3b3VsZCBo YXZlIGEgcGxhY2UgdG8gZ28gdG8gcmVhZCBhYm91dCBiZXN0IHByYWN0aWNlcyBmb3IgdGhpcyB1 c2UgY2FzZS4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBQaGlsIEh1bnQgW21haWx0bzpwaGlsLmh1 bnRAb3JhY2xlLmNvbV0NClNlbnQ6IFNhdHVyZGF5LCBNYXJjaCAxNiwgMjAxMyAyOjUyIEFNDQpU bzogTWlrZSBKb25lcw0KQ2M6IEJyaWFuIENhbXBiZWxsOyBMZXdpcyBBZGFtLUNBTDAyMjsgb2F1 dGhAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIEpXVCBncmFudF90eXBlIGFuZCBj bGllbnRfaWQNCg0KSXQncyBhIHF1ZXN0aW9uIG9mIHdoZXRoZXIgdGhlIGp3dCBzcGVjIGFsb25l IGlzIHVzZWQgKGluIHdoaWNoIGNhc2UgaXQgbmVlZHMgc2NvcGUpIG9yIHdoZXRoZXIgYW5vdGhl ciBwcm9maWxlIGZvciBhY2Nlc3MgdG9rZW5zIGlzIG5lZWRlZC4NCg0KU2luY2Ugc2NvcGUgaXMg ZnVuZGFtZW50YWwgdG8gb2F1dGgsIGkgdGhpbmsgaXQgaXMgcGFydCBpZiB0aGUgY29yZSBzZXQg b2YgbWluaW1hbCBhdHRyaWJ1dGVzIGZvciBhY2Nlc3MgdG9rZW5zLiAgSW4gZmFjdCBpIGNhYiBl bnZpc2lvbiBjYXNlcyB3aGVyZSByZWZlcmVuY2VzIHRvIGF1dGhvcml6aW5nIHVzZXIgb3IgY2xp ZW50IG1pZ2h0IGJlIGVsaW1pbmF0ZWQgb3IgYW5vbnltaXplZCBsZWF2aW5nIG9ubHkgb25lLiBF ZyBncmFudCB0aGUgaG9sZGVyIG9mIHRoaXMgdG9rZW4gdGhlIHJpZ2h0IHRvIGRvIHNjb3BlIHh5 ei4NCg0KUGhpbA0KDQpTZW50IGZyb20gbXkgcGhvbmUuDQoNCk9uIDIwMTMtMDMtMTUsIGF0IDIx OjAzLCBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hh ZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KSGF2aW5nIGEgc2NvcGUgY2xhaW0gaW4g c3BlY2lmaWMgcHJvZmlsZXMgY291bGQgbWFrZSBzZW5zZS4gIFRoYXQgZG9lc27igJl0IG1lYW4g dGhhdCBpdCBoYXMgdG8gYmUgZGVmaW5lZCBpbiB0aGUgSldUIHNwZWMgcGVyIHNlLiAgSWYgYW55 dGhpbmcsIHBlb3BsZSBleHByZXNzZWQgYSBkZXNpcmUgaW4geWVzdGVyZGF54oCZcyB3b3JraW5n IGdyb3VwIG1lZXRpbmcgdG8ga2VlcCB0aGUgYmFzZSBjbGFpbXMgc2V0IHNtYWxsLCByYXRoZXIg dGhhbiBleHBhbmRpbmcgaXQuDQoNClByb2ZpbGVzIGNhbiByZWdpc3RlciB0aGUgY2xhaW1zIHRo ZXkgZGVmaW5lIGluIHRoZSBJQU5BIEpXVCBDbGFpbXMgcmVnaXN0cnksIGlmIHRoZXkgY2hvb3Nl Lg0KDQotLSBNaWtlDQoNCg0KRnJvbTogTGV3aXMgQWRhbS1DQUwwMjINClNlbnQ6IOKAjk1hcmNo 4oCOIOKAjjE14oCOLCDigI4yMDEzIOKAjjPigI464oCONTXigI4g4oCOUE0NClRvOiBCcmlhbiBD YW1wYmVsbA0KQ0M6IG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4NClN1Ympl Y3Q6IFJlOiBbT0FVVEgtV0ddIEpXVCBncmFudF90eXBlIGFuZCBjbGllbnRfaWQNCg0KSSBndWVz cyB0aGF0IGl0IGRlcGVuZHMgb24gd2hhdCBKV1QgaXMgbWVhbnQgdG8gYmUuICBNeSB1bmRlcnN0 YW5kaW5nIGlzIHRoYXQgaXQgYmVnYW4gYXMgc29tZXRoaW5nIHRvIHN1cHBvcnQgV2ViIFNTTyBh dXRoZW50aWNhdGlvbiBmb3IgT0lEQywgc28gc2NvcGUgZGlkbuKAmXQgbWFrZSBhbnkgc2Vuc2Ug dGhlbi4gIE5vciBkb2VzIGl0IG1ha2UgYW55IHNlbnNlIGFzIGEgc3RyaWN0IGdyYW50IHR5cGUu ICBUaGUgdXNlIGNhc2Ugd2hlcmUgaXQgYmVjb21lcyBpbnRlcmVzdGluZyAodGhlIG9uZSBJIGFt IGxvb2tpbmcgdG8pIGlzIGZvciB3aGVuIGFuIGFjY2VzcyB0b2tlbiBvciByZWZyZXNoIHRva2Vu IGlzIGEgSldULiAgSSB0aGluayBzb21lIHZlbmRvcnMgYXJlIGJlZ2lubmluZyB0byBtYWtlIHRo ZWlyIHN0cnVjdHVyZWQgdG9rZW5zIGEgSldULCBhbmQgdGhhdCBpcyBteSBjdXJyZW50IHRoaW5r aW5nIGFzIHdlbGwg4oCmIGlmIGZvbGtzIGFncmVlIHRoYXQgSldUIGNhbiBiZSB1c2VkIGFzIHRo ZSBzdHJ1Y3R1cmUgZm9yIE9BdXRoIHRva2VucywgdGhlbiBpdCBtYWtlcyBzZW5zZSB0byBpbmNs dWRlIGEgc2NvcGUgZmllbGQuICBJZiBub3QsIHRoZW4gaXQgd2lsbCBiZSBKU09OK2VuY3J5cHRp b24rc2lnbmluZywganVzdCBub3QgYSBKV1Qg4pi6DQoNCmFkYW0NCg0KRnJvbTogQnJpYW4gQ2Ft cGJlbGwgW21haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbV0NClNlbnQ6IEZyaWRheSwg TWFyY2ggMTUsIDIwMTMgNToxNiBQTQ0KVG86IExld2lzIEFkYW0tQ0FMMDIyDQpDYzogU2VyZ2V5 IEJlcnlvemtpbjsgb2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPg0KU3ViamVj dDogUmU6IFtPQVVUSC1XR10gSldUIGdyYW50X3R5cGUgYW5kIGNsaWVudF9pZA0KDQpDb2RpZnlp bmcgYSBjbGFpbS9hdHRyaWJ1dGUgZm9yIHNjb3BlIHRoYXQgZ29lcyBpbiB0aGUgYXNzZXJ0aW9u IGlzIHNvbWV0aGluZyB0aGF0J3MgYmVlbiBkaXNjdXNzZWQgYnV0IG5ldmVyIHNlZW1lZCB0byBn ZXQgc3VmZmljaWVudCBjb25zZW5zdXMgcmVnYXJkaW5nIGhvdyB0byBleGFjdGx5IHRvIGRvIGl0 IGFuZCBpZiBpdCByZWFsbHkgcHJvdmlkZWQgbXVjaCB2YWx1ZS4NCg0KT24gRnJpLCBNYXIgMTUs IDIwMTMgYXQgNDoxMiBQTSwgQnJpYW4gQ2FtcGJlbGwgPGJjYW1wYmVsbEBwaW5naWRlbnRpdHku Y29tPG1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbT4+IHdyb3RlOg0KU28gY3VycmVu dGx5IHRoZSBiYXNlIGFzc2VydGlvbiBkb2N1bWVudCBkZWZpbmVzIHNjb3BlIGFzIGFuIEhUVFAg cGFyYW1ldGVyIG9uIHRoZSBhY2Nlc3MgdG9rZW4gcmVxdWVzdCBtZXNzYWdlIHdoZW4gdXNpbmcg YW4gYXNzZXJ0aW9uIGFzIGEgZ3JhbnRbMV0uICBBbmQgdGhhdCBhcHBsaWVzIHRvIGJvdGggdGhl IFNBTUwgYW5kIEpXVCBncmFudHMgKHBlcmhhcHMgdGhhdCBuZWVkcyB0byBiZSBtb3JlIGNsZWFy PykuIEFsc28gUkZDIDY3NDkgZGVmaW5lcyB0aGUgc2NvcGUgcGFyYW1ldGVyIGZvciB0aGUgY2xp ZW50IGNyZWRlbnRpYWxzIGFjY2VzcyB0b2tlbiByZXF1ZXN0WzJdLCB3aGljaCBzaW1pbGFybHkg YXBwbGllcyB0byBib3RoIFNBTUwgYW5kIEpXVCBpbiB0aGUgY2FzZSBvZiBhc3NlcnRpb24gY2xp ZW50IGF1dGhlbnRpY2F0aW9uIHVzaW5nIHRoZSAiY2xpZW50X2NyZWRlbnRpYWxzIiBncmFudCB0 eXBlLg0KDQpbMV0gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1h c3NlcnRpb25zLTEwI3NlY3Rpb24tNC4xDQpbMl0gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv cmZjNjc0OSNzZWN0aW9uLTQuNC4xDQoNCk9uIEZyaSwgTWFyIDE1LCAyMDEzIGF0IDM6NDMgUE0s IExld2lzIEFkYW0tQ0FMMDIyIDxBZGFtLkxld2lzQG1vdG9yb2xhc29sdXRpb25zLmNvbTxtYWls dG86QWRhbS5MZXdpc0Btb3Rvcm9sYXNvbHV0aW9ucy5jb20+PiB3cm90ZToNClJpZ2h0IC4uLiB0 aGlua2luZyBhYm91dCB0aGlzIGZ1cnRoZXIgSSB0aGluayB0aGUgYW5zd2VyIGlzICJhbGwgb2Yg dGhlIGFib3ZlLiIgIElmIHRoZSBKV1QgaXMgYSBncmFudCB0eXBlIHRoZW4gYXMgeW91IHNheSBp dCBuZWVkcyBhIHNjb3BlIHBhcmFtIGFuZCBvcHRpb25hbGx5IGEgY2xpZW50X2lkIHBhcmFtLiAg SSBhcmd1ZWQgZm9yIHRoZSBjbGllbnRfaWQgcGFyYW0gZWFybGllciBzaW5jZSBpdCBjb3VsZCBh c3Npc3Qgd2l0aCBIT0sgc2NlbmFyaW9zIG9uY2UgdGhvc2UgZnVydGhlciBkZXZlbG9wLg0KDQpC dXQgd2hlbiB0aGUgSldUIGlzIHVzZWQgYXMgYW4gQVQgdGhlbiBpdCB3aWxsIGRlZmluaXRlbHkg cmVxdWlyZSB0aGUgc2NvcGUgYXMgYSBjbGFpbS4NCg0KU28gSSBjaGFuZ2UgbXkgYXJndW1lbnQg dG8gImJvdGgiIDopDQoNCmFkYW0NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+IFtt YWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9y Zz5dIE9uIEJlaGFsZiBPZiBTZXJnZXkgQmVyeW96a2luDQpTZW50OiBGcmlkYXksIE1hcmNoIDE1 LCAyMDEzIDQ6MzEgUE0NClRvOiBvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+ DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBKV1QgZ3JhbnRfdHlwZSBhbmQgY2xpZW50X2lkDQoN CkhpDQpPbiAxNS8wMy8xMyAyMDo0MCwgTGV3aXMgQWRhbS1DQUwwMjIgd3JvdGU6DQo+IEhpIEpv aG4sDQo+DQo+IEkgd291bGQgbGlrZSB0byBhcmd1ZSB0aGF0IHRoZSBzY29wZSBzaG91bGQgYmUg YSBwYXJhbWV0ZXIgaW4gdGhlIGFjY2Vzcw0KPiB0b2tlbiByZXF1ZXN0IG1lc3NhZ2UsIHRoZSBz YW1lIGFzIGl0IGlzIGZvciB0aGUgUk8gY3JlZHMgZ3JhbnQgYW5kDQo+IGNsaWVudCBjcmVkcyBn cmFudCB0eXBlLiBUaGlzIHdvdWxkIGtlZXAgaXQgY29uc2lzdGVudCB3aXRoIHRoZSBjb3JlDQo+ IE9BdXRoIGdyYW50IHR5cGVzIHRoYXQgdGFsayBkaXJlY3RseSB0byB0aGUgdG9rZW4gZW5kcG9p bnQuDQo+DQpBc3N1bWluZyB0aGUgYXNzZXJ0aW9uIGlzIGFjdGluZyBhcyBhIGdyYW50LCB0aGVu IGl0IGlzIGluZGVlZCBhbiBhY2Nlc3MNCnRva2VuIHJlcXVlc3QgbWVzc2FnZSwgc28gSU1ITyBp dCBtYWtlcyBzZW5zZSB0byBnZXQgYW4gb3V0Ym91bmQgc2NvcGUNCnBhcmFtZXRlciBvcHRpb25h bGx5IHN1cHBvcnRlZCB3aGljaCBJIGd1ZXNzIHdpbGwgaW1wbHkgdGhhdCB0aGUgY2xpZW50DQpp ZCB3aWxsIGFsc28gaGF2ZSB0byBhY2NvbXBhbnkgaXQuLi4NCg0KQ2hlZXJzLCBTZXJnZXkNCg0K PiBUaG91Z2h0cz8NCj4NCj4gYWRhbQ0KPg0KPiAqRnJvbToqSm9obiBCcmFkbGV5IFttYWlsdG86 dmU3anRiQHZlN2p0Yi5jb208bWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tPl0NCj4gKlNlbnQ6KiBG cmlkYXksIE1hcmNoIDE1LCAyMDEzIDEyOjEwIFBNDQo+ICpUbzoqIExld2lzIEFkYW0tQ0FMMDIy DQo+ICpDYzoqIEJyaWFuIENhbXBiZWxsOyAiV0cgPG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0 aEBpZXRmLm9yZz4+IkBpbDA2ZXhyMDIubW90LmNvbTxodHRwOi8vaWwwNmV4cjAyLm1vdC5jb20+ DQo+ICpTdWJqZWN0OiogUmU6IFtPQVVUSC1XR10gSldUIGdyYW50X3R5cGUgYW5kIGNsaWVudF9p ZA0KPg0KPiBUaGUgc3BlYyBpcyBhIHRvdWNoIHZhZ3VlIG9uIHRoYXQuIEkgdGhpbmsgdGhlIHNj b3BlcyBzaG91bGQgYmUgaW4gdGhlDQo+IGFzc2VydGlvbiBhbmQgdGhlIGNsaWVudCBjYW4gdXNl IHRoZSBzY29wZXMgb3V0c2lkZSB0aGUgYXNzZXJ0aW9uIHRvDQo+IGRvd24tc2NvcGUuDQo+DQo+ IEhhdmluZyBhIHN0YW5kYXJkIGNsYWltIGluIEpXVCBhbmQgU0FNTCBmb3IgcGFzc2luZyBzY29w ZXMgaXMgcHJvYmFibHkNCj4gdXNlZnVsIGFzIHBhcnQgb2YgYSBwcm9maWxlLg0KPg0KPiBKb2hu IEIuDQo+DQo+IE9uIDIwMTMtMDMtMTQsIGF0IDg6NDcgUE0sIExld2lzIEFkYW0tQ0FMMDIyDQo+ IDxBZGFtLkxld2lzQG1vdG9yb2xhc29sdXRpb25zLmNvbTxtYWlsdG86QWRhbS5MZXdpc0Btb3Rv cm9sYXNvbHV0aW9ucy5jb20+DQo+IDxtYWlsdG86QWRhbS5MZXdpc0Btb3Rvcm9sYXNvbHV0aW9u cy5jb208bWFpbHRvOkFkYW0uTGV3aXNAbW90b3JvbGFzb2x1dGlvbnMuY29tPj4+IHdyb3RlOg0K Pg0KPg0KPg0KPiBIbW1tLCBvbmUgbW9yZSB0aG91Z2h0IC4uLiBubyBzY29wZT8/IFRoZSBKV1Qg aXMgdGhlIGdyYW50LCBpcyBpdCBhc3N1bWVkDQo+IHRoYXQgdGhlIHNjb3BlIGlzIGNvbnZleWVk IGFzIGEgY2xhaW0gd2l0aGluIHRoZSB0b2tlbj8gT3RoZXJ3aXNlIGl0DQo+IHdvdWxkIHNlZW0g dGhhdCBpdCB3b3VsZCByZXF1aXJlIGEgc2NvcGUuDQo+DQo+IFRob3VnaHRzPw0KPg0KPiBhZGFt DQo+DQo+ICpGcm9tOipCcmlhbiBDYW1wYmVsbCBbbWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRp dHkuY29tPG1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbT4NCj4gPGh0dHA6Ly9waW5n aWRlbnRpdHkuY29tPl0NCj4gKlNlbnQ6KlRodXJzZGF5LCBNYXJjaCAxNCwgMjAxMyA0OjQ0IFBN DQo+ICpUbzoqTGV3aXMgQWRhbS1DQUwwMjINCj4gKkNjOipNaWtlIEpvbmVzOyAiV0cgPG9hdXRo QGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4NCj4gPG1haWx0bzpvYXV0aEBpZXRmLm9y ZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+Pj4iQGlsMDZleHIwMi5tb3QuY29tPGh0dHA6Ly9pbDA2 ZXhyMDIubW90LmNvbT4gPGh0dHA6Ly9pbDA2ZXhyMDIubW90LmNvbT4NCj4gKlN1YmplY3Q6KlJl OiBbT0FVVEgtV0ddIEpXVCBncmFudF90eXBlIGFuZCBjbGllbnRfaWQNCj4NCj4gWWVzLCB0aGF0 IGlzIGNvcnJlY3QuDQo+DQo+IEknbSB3b3JraW5nIG9uIG5ldyByZXZpc2lvbnMgb2YgdGhlIGRy YWZ0cyB0aGF0IHdpbGwgaG9wZWZ1bGx5IG1ha2UgdGhhdA0KPiBwb2ludCBtb3JlIGNsZWFyLg0K Pg0KPiBPbiBUaHUsIE1hciAxNCwgMjAxMyBhdCA1OjI2IFBNLCBMZXdpcyBBZGFtLUNBTDAyMg0K PiA8QWRhbS5MZXdpc0Btb3Rvcm9sYXNvbHV0aW9ucy5jb208bWFpbHRvOkFkYW0uTGV3aXNAbW90 b3JvbGFzb2x1dGlvbnMuY29tPg0KPiA8bWFpbHRvOkFkYW0uTGV3aXNAbW90b3JvbGFzb2x1dGlv bnMuY29tPG1haWx0bzpBZGFtLkxld2lzQG1vdG9yb2xhc29sdXRpb25zLmNvbT4+PiB3cm90ZToN Cj4NCj4gQ29taW5nIGJhY2sgdG8gdGhpcy4uLiAgYW0gSSBjb3JyZWN0IGluIHRoYXQgY2xpZW50 X2lkIGlzIG5vdCByZXF1aXJlZD8gICAgV2UgYXJlIGltcGxlbWVudGluZyB0aGlzIHNwZWMgYW5k IHdhbnQgdG8gbWFrZSBzdXJlIHRoYXQgd2UgYXJlIGRvaW5nIGl0IHJpZ2h0LiAgICBCeSBteSB1 bmRlcnN0YW5kaW5nIHRoZSBvbmx5IHR3byBwYXJhbWV0ZXJzIHRoYXQgYXJlIHJlcXVpcmVkIGlu IHRoZSBKV1QgZ3JhbnQgdHlwZSBhcmUgICJ1cm46aWV0ZjpwYXJhbXM6b2F1dGg6Z3JhbnQtdHlw ZTpqd3QtYmVhcmVyIiAgICBhbmQgdGhlIGFzc2VydGlvbi4gICAgICBJcyB0aGlzIGNvcnJlY3Q/ DQo+DQo+ICpGcm9tOipNaWtlIEpvbmVzIFttYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQu Y29tPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+DQo+IDxtYWlsdG86TWljaGFl bC5Kb25lc0BtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+ Pl0NCj4gKlNlbnQ6Kk1vbmRheSwgRmVicnVhcnkgMTgsIDIwMTMgNjo1OCBQTQ0KPiAqVG86Kkxl d2lzIEFkYW0tQ0FMMDIyO29hdXRoQGlldGYub3JnPG1haWx0bzpBZGFtLUNBTDAyMiUzQm9hdXRo QGlldGYub3JnPiA8bWFpbHRvOm9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4+ V0cNCj4gKlN1YmplY3Q6KlJFOiBKV1QgZ3JhbnRfdHlwZSBhbmQgY2xpZW50X2lkDQo+DQo+IFRo ZSBjbGllbnRfaWQgdmFsdWUgYW5kIHRoZSBhY2Nlc3MgdG9rZW4gdmFsdWUgYXJlIGluZGVwZW5k ZW50Lg0KPg0KPiAtLSBNaWtlDQo+DQo+ICpGcm9tOipvYXV0aC1ib3VuY2VzQGlldGYub3JnPG1h aWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPg0KPiA8bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0 Zi5vcmc8bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+PlttYWlsdG86b2F1dGgtYm91bmNl c0BpZXRmLm9yZzxtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZz4NCj4gPG1haWx0bzpvYXV0 aC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPj5dKk9uIEJl aGFsZiBPZipMZXdpcyBBZGFtLUNBTDAyMg0KPiAqU2VudDoqTW9uZGF5LCBGZWJydWFyeSAxOCwg MjAxMyAyOjUwIFBNDQo+ICpUbzoqb2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3Jn PiA8bWFpbHRvOm9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4+V0cNCj4gKlN1 YmplY3Q6KltPQVVUSC1XR10gSldUIGdyYW50X3R5cGUgYW5kIGNsaWVudF9pZA0KPg0KPiBJcyB0 aGVyZSBhbnkgZ3VpZGFuY2Ugb24gdGhlIHVzYWdlIG9mIGNsaWVudF9pZCB3aGVuIHVzaW5nIHRo ZSBKV1QNCj4gYXNzZXJ0aW9uIHByb2ZpbGUgYXMgYSBncmFudCB0eXBlPyBkcmFmdC1pZXRmLW9h dXRoLWp3dC1iZWFyZXItMDQgbWFrZXMNCj4gbm8gbWVudGlvbiBzbyBJIGFzc3VtZSB0aGF0IGl0 IGlzIG5vdCByZXF1aXJlZCAuLi4gYnV0IGl0IHdvdWxkIGJlDQo+IG5lY2Vzc2FyeSBpZiB1c2lu ZyBpbiBjb25qdW5jdGlvbiB3aXRoIGEgSE9LIHByb2ZpbGUgd2hlcmUgdGhlIEpXVA0KPiBhc3Nl cnRpb24gaXMgaXNzdWVkIHRvIC0gYW5kIG1heSBvbmx5IGJlIHVzZWQgYnkgLSB0aGUgaW50ZW5k ZWQgY2xpZW50Lg0KPiBPYnZpb3VzbHkgdGhpcyBpcyBzdHJhaWdodCBmb3J3YXJkIGVub3VnaCwg cmVhbGx5IEknbSBqdXN0IGxvb2tpbmcgdG8gYmUNCj4gc3VyZSB0aGF0IEknbSBub3QgbWlzc2lu ZyBhbnl0aGluZy4NCj4NCj4gdHgNCj4NCj4gYWRhbQ0KPg0KPg0KPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4g T0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPiA8bWFpbHRvOk9BdXRoQGlldGYu b3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4+DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vb2F1dGgNCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gT0F1dGggbWFpbGluZyBsaXN0DQo+IE9BdXRoQGlldGYub3JnPG1h aWx0bzpPQXV0aEBpZXRmLm9yZz4gPG1haWx0bzpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhA aWV0Zi5vcmc+Pg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRo DQo+DQo+DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+IE9BdXRoIG1haWxpbmcgbGlzdA0KPiBPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhA aWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRo IG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQoNCg0KDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5n IGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBp ZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL29hdXRoDQo= --_000_4E1F6AAD24975D4BA5B168042967394367533A20TK5EX14MBXC284r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJ bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0K CWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgs IGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1w cmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdp bi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNl cmlmIjt9DQpwLm1zb2xpc3RwYXJhZ3JhcGhjeHNwZmlyc3QsIGxpLm1zb2xpc3RwYXJhZ3JhcGhj eHNwZmlyc3QsIGRpdi5tc29saXN0cGFyYWdyYXBoY3hzcGZpcnN0DQoJe21zby1zdHlsZS1uYW1l Om1zb2xpc3RwYXJhZ3JhcGhjeHNwZmlyc3Q7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJp Z2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglsaW5lLWhlaWdodDoxMTUlOw0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpwLm1zb2xpc3RwYXJh Z3JhcGhjeHNwbWlkZGxlLCBsaS5tc29saXN0cGFyYWdyYXBoY3hzcG1pZGRsZSwgZGl2Lm1zb2xp c3RwYXJhZ3JhcGhjeHNwbWlkZGxlDQoJe21zby1zdHlsZS1uYW1lOm1zb2xpc3RwYXJhZ3JhcGhj eHNwbWlkZGxlOw0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2lu LWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJbGluZS1oZWlnaHQ6MTE1JTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KcC5tc29saXN0cGFyYWdyYXBoY3hzcGxhc3QsIGxp Lm1zb2xpc3RwYXJhZ3JhcGhjeHNwbGFzdCwgZGl2Lm1zb2xpc3RwYXJhZ3JhcGhjeHNwbGFzdA0K CXttc28tc3R5bGUtbmFtZTptc29saXN0cGFyYWdyYXBoY3hzcGxhc3Q7DQoJbWFyZ2luLXRvcDow aW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVm dDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglsaW5lLWhlaWdodDoxMTUlOw0KCWZv bnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9 DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bh bi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsN Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7 DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2Ug V29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAx LjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBhZ3JlZSB0aGF0IGl04oCZcyBs aWtlbHkgYSBjbGFpbSB0aGF0IHdvdWxkIGJlIHVzZWQgaW4gYWNjZXNzIHRva2Vucy48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPknigJltIGNvbWluZyB0byB0aGUgY29uY2x1c2lvbiB0aGF0IHdlIHNob3VsZCBhY3R1YWxs eSB3cml0ZSBhbiBhY2Nlc3MgdG9rZW4gcHJvZmlsZSBmb3IgSldUIGFuZCBwcm9iYWJseSBTQU1M IGFzIHdlbGwuJm5ic3A7IFRoaXMgd291bGQgYmUgcGFyYWxsZWwgdG8gdGhlIGtpbmRzIG9mDQog cmVxdWlyZW1lbnRzIHBsYWNlZCBvbiB0aGUgdXNlIG9mIFNBTUwgYW5kIEpXVCB3aGVuIHVzZWQg Zm9yIGNsaWVudCBhdXRoZW50aWNhdGlvbiBhbmQgYXMgcmVzb3VyY2UgZ3JhbnRzLiZuYnNwOyBU aGlzIGNvdWxkIG9ubHkgaGVscCBpbnRlcm9wZXJhYmlsaXR5LCBhcyBwZW9wbGUgd291bGQgaGF2 ZSBhIHBsYWNlIHRvIGdvIHRvIHJlYWQgYWJvdXQgYmVzdCBwcmFjdGljZXMgZm9yIHRoaXMgdXNl 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 c2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ IFBoaWwgSHVudCBbbWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tXQ0KPGJyPg0KPGI+U2VudDo8 L2I+IFNhdHVyZGF5LCBNYXJjaCAxNiwgMjAxMyAyOjUyIEFNPGJyPg0KPGI+VG86PC9iPiBNaWtl IEpvbmVzPGJyPg0KPGI+Q2M6PC9iPiBCcmlhbiBDYW1wYmVsbDsgTGV3aXMgQWRhbS1DQUwwMjI7 IG9hdXRoQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIEpXVCBn cmFudF90eXBlIGFuZCBjbGllbnRfaWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQncyBhIHF1ZXN0aW9uIG9mIHdoZXRoZXIgdGhlIGp3dCBz cGVjIGFsb25lIGlzIHVzZWQgKGluIHdoaWNoIGNhc2UgaXQgbmVlZHMgc2NvcGUpIG9yIHdoZXRo ZXIgYW5vdGhlciBwcm9maWxlIGZvciBhY2Nlc3MgdG9rZW5zIGlzIG5lZWRlZC4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2luY2Ug c2NvcGUgaXMgZnVuZGFtZW50YWwgdG8gb2F1dGgsIGkgdGhpbmsgaXQgaXMgcGFydCBpZiB0aGUg Y29yZSBzZXQgb2YgbWluaW1hbCBhdHRyaWJ1dGVzIGZvciBhY2Nlc3MgdG9rZW5zLiAmbmJzcDtJ biBmYWN0IGkgY2FiIGVudmlzaW9uIGNhc2VzIHdoZXJlIHJlZmVyZW5jZXMgdG8gYXV0aG9yaXpp bmcgdXNlciBvciBjbGllbnQgbWlnaHQgYmUgZWxpbWluYXRlZCBvciBhbm9ueW1pemVkIGxlYXZp bmcgb25seQ0KIG9uZS4gRWcgZ3JhbnQgdGhlIGhvbGRlciBvZiB0aGlzIHRva2VuIHRoZSByaWdo dCB0byBkbyBzY29wZSB4eXouJm5ic3A7PGJyPg0KPGJyPg0KUGhpbDxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2VudCBmcm9tIG15IHBob25lLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCk9uIDIwMTMtMDMtMTUsIGF0IDIxOjAzLCBN aWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29t Ij5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5IYXZpbmcgYSBzY29wZSBjbGFpbSBpbiBzcGVjaWZpYyBwcm9maWxlcyBjb3Vs ZCBtYWtlIHNlbnNlLiZuYnNwOyBUaGF0IGRvZXNu4oCZdCBtZWFuIHRoYXQgaXQgaGFzIHRvIGJl IGRlZmluZWQgaW4gdGhlIEpXVCBzcGVjIHBlciBzZS4mbmJzcDsgSWYgYW55dGhpbmcsIHBlb3Bs ZSBleHByZXNzZWQgYSBkZXNpcmUgaW4geWVzdGVyZGF54oCZcyB3b3JraW5nDQogZ3JvdXAgbWVl dGluZyB0byBrZWVwIHRoZSBiYXNlIGNsYWltcyBzZXQgc21hbGwsIHJhdGhlciB0aGFuIGV4cGFu ZGluZyBpdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Qcm9maWxlcyBjYW4g cmVnaXN0ZXIgdGhlIGNsYWltcyB0aGV5IGRlZmluZSBpbiB0aGUgSUFOQSBKV1QgQ2xhaW1zIHJl Z2lzdHJ5LCBpZiB0aGV5IGNob29zZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij4tLSBNaWtlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiAwaW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L3N0cm9uZz48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4mbmJzcDtMZXdpcyBBZGFtLUNBTDAyMjxicj4NCjxzdHJvbmc+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+U2VudDo8L3NwYW4+PC9zdHJvbmc+Jm5ic3A74oCOTWFyY2jigI4g4oCOMTXigI4sIOKAjjIw MTMg4oCOM+KAjjrigI41NeKAjiDigI5QTTxicj4NCjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+VG86PC9z cGFuPjwvc3Ryb25nPiZuYnNwO0JyaWFuIENhbXBiZWxsPGJyPg0KPHN0cm9uZz48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5DQzo8L3NwYW4+PC9zdHJvbmc+Jm5ic3A7PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3Jn Ij5vYXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlN1YmplY3Q6PC9z cGFuPjwvc3Ryb25nPiZuYnNwO1JlOiBbT0FVVEgtV0ddIEpXVCBncmFudF90eXBlIGFuZCBjbGll bnRfaWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5JIGd1ZXNzIHRoYXQgaXQgZGVwZW5kcyBvbiB3aGF0IEpXVCBpcyBt ZWFudCB0byBiZS4mbmJzcDsgTXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IGl0IGJlZ2FuIGFzIHNv bWV0aGluZw0KIHRvIHN1cHBvcnQgV2ViIFNTTyBhdXRoZW50aWNhdGlvbiBmb3IgT0lEQywgc28g c2NvcGUgZGlkbuKAmXQgbWFrZSBhbnkgc2Vuc2UgdGhlbi4mbmJzcDsgTm9yIGRvZXMgaXQgbWFr ZSBhbnkgc2Vuc2UgYXMgYSBzdHJpY3QgZ3JhbnQgdHlwZS4mbmJzcDsgVGhlIHVzZSBjYXNlIHdo ZXJlIGl0IGJlY29tZXMgaW50ZXJlc3RpbmcgKHRoZSBvbmUgSSBhbSBsb29raW5nIHRvKSBpcyBm b3Igd2hlbiBhbiBhY2Nlc3MgdG9rZW4gb3IgcmVmcmVzaCB0b2tlbiBpcyBhIEpXVC4mbmJzcDsN CiBJIHRoaW5rIHNvbWUgdmVuZG9ycyBhcmUgYmVnaW5uaW5nIHRvIG1ha2UgdGhlaXIgc3RydWN0 dXJlZCB0b2tlbnMgYSBKV1QsIGFuZCB0aGF0IGlzIG15IGN1cnJlbnQgdGhpbmtpbmcgYXMgd2Vs bCDigKYgaWYgZm9sa3MgYWdyZWUgdGhhdCBKV1QgY2FuIGJlIHVzZWQgYXMgdGhlIHN0cnVjdHVy ZSBmb3IgT0F1dGggdG9rZW5zLCB0aGVuIGl0IG1ha2VzIHNlbnNlIHRvIGluY2x1ZGUgYSBzY29w ZSBmaWVsZC4mbmJzcDsgSWYgbm90LCB0aGVuIGl0IHdpbGwgYmUNCiBKU09OJiM0MztlbmNyeXB0 aW9uJiM0MztzaWduaW5nLCBqdXN0IG5vdCBhIEpXVCA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMxRjQ5N0QiPko8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPmFkYW08L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEJyaWFuIENh bXBiZWxsIFs8YSBocmVmPSJtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20iPm1haWx0 bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gRnJp ZGF5LCBNYXJjaCAxNSwgMjAxMyA1OjE2IFBNPGJyPg0KPGI+VG86PC9iPiBMZXdpcyBBZGFtLUNB TDAyMjxicj4NCjxiPkNjOjwvYj4gU2VyZ2V5IEJlcnlvemtpbjsgPGEgaHJlZj0ibWFpbHRvOm9h dXRoQGlldGYub3JnIj5vYXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6 IFtPQVVUSC1XR10gSldUIGdyYW50X3R5cGUgYW5kIGNsaWVudF9pZDwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Q29kaWZ5aW5nIGEgY2xhaW0vYXR0cmlidXRlIGZv ciBzY29wZSB0aGF0IGdvZXMgaW4gdGhlIGFzc2VydGlvbiBpcyBzb21ldGhpbmcgdGhhdCdzIGJl ZW4gZGlzY3Vzc2VkIGJ1dCBuZXZlciBzZWVtZWQgdG8gZ2V0IHN1ZmZpY2llbnQNCiBjb25zZW5z dXMgcmVnYXJkaW5nIGhvdyB0byBleGFjdGx5IHRvIGRvIGl0IGFuZCBpZiBpdCByZWFsbHkgcHJv dmlkZWQgbXVjaCB2YWx1ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2lu LWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPk9uIEZyaSwgTWFyIDE1 LCAyMDEzIGF0IDQ6MTIgUE0sIEJyaWFuIENhbXBiZWxsICZsdDs8YSBocmVmPSJtYWlsdG86YmNh bXBiZWxsQHBpbmdpZGVudGl0eS5jb20iPmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+U28gY3VycmVudGx5IHRoZSBiYXNlIGFzc2VydGlvbiBkb2N1bWVu dCBkZWZpbmVzIHNjb3BlIGFzIGFuIEhUVFAgcGFyYW1ldGVyIG9uIHRoZSBhY2Nlc3MgdG9rZW4g cmVxdWVzdCBtZXNzYWdlIHdoZW4gdXNpbmcgYW4gYXNzZXJ0aW9uDQogYXMgYSBncmFudFsxXS4m bmJzcDsgQW5kIHRoYXQgYXBwbGllcyB0byBib3RoIHRoZSBTQU1MIGFuZCBKV1QgZ3JhbnRzIChw ZXJoYXBzIHRoYXQgbmVlZHMgdG8gYmUgbW9yZSBjbGVhcj8pLiBBbHNvIFJGQyA2NzQ5IGRlZmlu ZXMgdGhlIHNjb3BlIHBhcmFtZXRlciBmb3IgdGhlIGNsaWVudCBjcmVkZW50aWFscyBhY2Nlc3Mg dG9rZW4gcmVxdWVzdFsyXSwgd2hpY2ggc2ltaWxhcmx5IGFwcGxpZXMgdG8gYm90aCBTQU1MIGFu ZCBKV1QgaW4gdGhlIGNhc2UNCiBvZiBhc3NlcnRpb24gY2xpZW50IGF1dGhlbnRpY2F0aW9uIHVz aW5nIHRoZSAmcXVvdDtjbGllbnRfY3JlZGVudGlhbHMmcXVvdDsgZ3JhbnQgdHlwZS48YnI+DQo8 YnI+DQpbMV0gPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1v YXV0aC1hc3NlcnRpb25zLTEwI3NlY3Rpb24tNC4xIj4NCmh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYtb2F1dGgtYXNzZXJ0aW9ucy0xMCNzZWN0aW9uLTQuMTwvYT4gPGJyPg0K WzJdIDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY3NDkjc2VjdGlvbi00 LjQuMSI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjc0OSNzZWN0aW9uLTQuNC4xPC9h PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1i b3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5PbiBGcmksIE1hciAxNSwg MjAxMyBhdCAzOjQzIFBNLCBMZXdpcyBBZGFtLUNBTDAyMiAmbHQ7PGEgaHJlZj0ibWFpbHRvOkFk YW0uTGV3aXNAbW90b3JvbGFzb2x1dGlvbnMuY29tIj5BZGFtLkxld2lzQG1vdG9yb2xhc29sdXRp b25zLmNvbTwvYT4mZ3Q7DQogd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5SaWdodCAuLi4gdGhpbmtpbmcgYWJvdXQgdGhpcyBm dXJ0aGVyIEkgdGhpbmsgdGhlIGFuc3dlciBpcyAmcXVvdDthbGwgb2YgdGhlIGFib3ZlLiZxdW90 OyAmbmJzcDtJZiB0aGUgSldUIGlzIGEgZ3JhbnQgdHlwZSB0aGVuIGFzIHlvdSBzYXkgaXQgbmVl ZHMNCiBhIHNjb3BlIHBhcmFtIGFuZCBvcHRpb25hbGx5IGEgY2xpZW50X2lkIHBhcmFtLiAmbmJz cDtJIGFyZ3VlZCBmb3IgdGhlIGNsaWVudF9pZCBwYXJhbSBlYXJsaWVyIHNpbmNlIGl0IGNvdWxk IGFzc2lzdCB3aXRoIEhPSyBzY2VuYXJpb3Mgb25jZSB0aG9zZSBmdXJ0aGVyIGRldmVsb3AuPGJy Pg0KPGJyPg0KQnV0IHdoZW4gdGhlIEpXVCBpcyB1c2VkIGFzIGFuIEFUIHRoZW4gaXQgd2lsbCBk ZWZpbml0ZWx5IHJlcXVpcmUgdGhlIHNjb3BlIGFzIGEgY2xhaW0uPGJyPg0KPGJyPg0KU28gSSBj aGFuZ2UgbXkgYXJndW1lbnQgdG8gJnF1b3Q7Ym90aCZxdW90OyA6KTxicj4NCjxicj4NCmFkYW08 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+PGJyPg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQpGcm9t OiA8YSBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyI+b2F1dGgtYm91bmNlc0Bp ZXRmLm9yZzwvYT4gW21haWx0bzo8YSBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9y ZyI+b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBTZXJnZXkgQmVyeW96 a2luPGJyPg0KU2VudDogRnJpZGF5LCBNYXJjaCAxNSwgMjAxMyA0OjMxIFBNPGJyPg0KVG86IDxh IGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+b2F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KU3Vi amVjdDogUmU6IFtPQVVUSC1XR10gSldUIGdyYW50X3R5cGUgYW5kIGNsaWVudF9pZDxicj4NCjxi cj4NCkhpPGJyPg0KT24gMTUvMDMvMTMgMjA6NDAsIExld2lzIEFkYW0tQ0FMMDIyIHdyb3RlOjxi cj4NCiZndDsgSGkgSm9obiw8YnI+DQomZ3Q7PGJyPg0KJmd0OyBJIHdvdWxkIGxpa2UgdG8gYXJn dWUgdGhhdCB0aGUgc2NvcGUgc2hvdWxkIGJlIGEgcGFyYW1ldGVyIGluIHRoZSBhY2Nlc3M8YnI+ DQomZ3Q7IHRva2VuIHJlcXVlc3QgbWVzc2FnZSwgdGhlIHNhbWUgYXMgaXQgaXMgZm9yIHRoZSBS TyBjcmVkcyBncmFudCBhbmQ8YnI+DQomZ3Q7IGNsaWVudCBjcmVkcyBncmFudCB0eXBlLiBUaGlz IHdvdWxkIGtlZXAgaXQgY29uc2lzdGVudCB3aXRoIHRoZSBjb3JlPGJyPg0KJmd0OyBPQXV0aCBn cmFudCB0eXBlcyB0aGF0IHRhbGsgZGlyZWN0bHkgdG8gdGhlIHRva2VuIGVuZHBvaW50Ljxicj4N CiZndDs8YnI+DQpBc3N1bWluZyB0aGUgYXNzZXJ0aW9uIGlzIGFjdGluZyBhcyBhIGdyYW50LCB0 aGVuIGl0IGlzIGluZGVlZCBhbiBhY2Nlc3M8YnI+DQp0b2tlbiByZXF1ZXN0IG1lc3NhZ2UsIHNv IElNSE8gaXQgbWFrZXMgc2Vuc2UgdG8gZ2V0IGFuIG91dGJvdW5kIHNjb3BlPGJyPg0KcGFyYW1l dGVyIG9wdGlvbmFsbHkgc3VwcG9ydGVkIHdoaWNoIEkgZ3Vlc3Mgd2lsbCBpbXBseSB0aGF0IHRo ZSBjbGllbnQ8YnI+DQppZCB3aWxsIGFsc28gaGF2ZSB0byBhY2NvbXBhbnkgaXQuLi48YnI+DQo8 YnI+DQpDaGVlcnMsIFNlcmdleTxicj4NCjxicj4NCiZndDsgVGhvdWdodHM/PGJyPg0KJmd0Ozxi cj4NCiZndDsgYWRhbTxicj4NCiZndDs8YnI+DQomZ3Q7ICpGcm9tOipKb2huIEJyYWRsZXkgW21h aWx0bzo8YSBocmVmPSJtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20iPnZlN2p0YkB2ZTdqdGIuY29t PC9hPl08YnI+DQomZ3Q7ICpTZW50OiogRnJpZGF5LCBNYXJjaCAxNSwgMjAxMyAxMjoxMCBQTTxi cj4NCiZndDsgKlRvOiogTGV3aXMgQWRhbS1DQUwwMjI8YnI+DQomZ3Q7ICpDYzoqIEJyaWFuIENh bXBiZWxsOyAmcXVvdDtXRyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj5vYXV0 aEBpZXRmLm9yZzwvYT4mZ3Q7JnF1b3Q7QDxhIGhyZWY9Imh0dHA6Ly9pbDA2ZXhyMDIubW90LmNv bSI+aWwwNmV4cjAyLm1vdC5jb208L2E+PGJyPg0KJmd0OyAqU3ViamVjdDoqIFJlOiBbT0FVVEgt V0ddIEpXVCBncmFudF90eXBlIGFuZCBjbGllbnRfaWQ8YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGUg c3BlYyBpcyBhIHRvdWNoIHZhZ3VlIG9uIHRoYXQuIEkgdGhpbmsgdGhlIHNjb3BlcyBzaG91bGQg YmUgaW4gdGhlPGJyPg0KJmd0OyBhc3NlcnRpb24gYW5kIHRoZSBjbGllbnQgY2FuIHVzZSB0aGUg c2NvcGVzIG91dHNpZGUgdGhlIGFzc2VydGlvbiB0bzxicj4NCiZndDsgZG93bi1zY29wZS48YnI+ DQomZ3Q7PGJyPg0KJmd0OyBIYXZpbmcgYSBzdGFuZGFyZCBjbGFpbSBpbiBKV1QgYW5kIFNBTUwg Zm9yIHBhc3Npbmcgc2NvcGVzIGlzIHByb2JhYmx5PGJyPg0KJmd0OyB1c2VmdWwgYXMgcGFydCBv ZiBhIHByb2ZpbGUuPGJyPg0KJmd0Ozxicj4NCiZndDsgSm9obiBCLjxicj4NCiZndDs8YnI+DQom Z3Q7IE9uIDIwMTMtMDMtMTQsIGF0IDg6NDcgUE0sIExld2lzIEFkYW0tQ0FMMDIyPGJyPg0KJmd0 OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOkFkYW0uTGV3aXNAbW90b3JvbGFzb2x1dGlvbnMuY29tIj5B ZGFtLkxld2lzQG1vdG9yb2xhc29sdXRpb25zLmNvbTwvYT48YnI+DQomZ3Q7ICZsdDttYWlsdG86 PGEgaHJlZj0ibWFpbHRvOkFkYW0uTGV3aXNAbW90b3JvbGFzb2x1dGlvbnMuY29tIj5BZGFtLkxl d2lzQG1vdG9yb2xhc29sdXRpb25zLmNvbTwvYT4mZ3Q7Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7PGJy Pg0KJmd0Ozxicj4NCiZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mZ3Q7IEhtbW0sIG9uZSBtb3JlIHRo b3VnaHQgLi4uIG5vIHNjb3BlPz8gVGhlIEpXVCBpcyB0aGUgZ3JhbnQsIGlzIGl0IGFzc3VtZWQ8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4mZ3Q7IHRoYXQgdGhlIHNjb3BlIGlzIGNvbnZleWVkIGFzIGEgY2xhaW0gd2l0aGlu IHRoZSB0b2tlbj8gT3RoZXJ3aXNlIGl0PGJyPg0KJmd0OyB3b3VsZCBzZWVtIHRoYXQgaXQgd291 bGQgcmVxdWlyZSBhIHNjb3BlLjxicj4NCiZndDs8YnI+DQomZ3Q7IFRob3VnaHRzPzxicj4NCiZn dDs8YnI+DQomZ3Q7IGFkYW08YnI+DQomZ3Q7PGJyPg0KJmd0OyAqRnJvbToqQnJpYW4gQ2FtcGJl bGwgW21haWx0bzo8YSBocmVmPSJtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20iPmJj YW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPC9hPjxicj4NCiZndDsgJmx0OzxhIGhyZWY9Imh0dHA6 Ly9waW5naWRlbnRpdHkuY29tIj5odHRwOi8vcGluZ2lkZW50aXR5LmNvbTwvYT4mZ3Q7XTxicj4N CiZndDsgKlNlbnQ6KlRodXJzZGF5LCBNYXJjaCAxNCwgMjAxMyA0OjQ0IFBNPGJyPg0KJmd0OyAq VG86Kkxld2lzIEFkYW0tQ0FMMDIyPGJyPg0KJmd0OyAqQ2M6Kk1pa2UgSm9uZXM7ICZxdW90O1dH ICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYub3JnPC9hPjxi cj4NCiZndDsgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9hdXRo QGlldGYub3JnPC9hPiZndDsmZ3Q7JnF1b3Q7QDxhIGhyZWY9Imh0dHA6Ly9pbDA2ZXhyMDIubW90 LmNvbSI+aWwwNmV4cjAyLm1vdC5jb208L2E+ICZsdDs8YSBocmVmPSJodHRwOi8vaWwwNmV4cjAy Lm1vdC5jb20iPmh0dHA6Ly9pbDA2ZXhyMDIubW90LmNvbTwvYT4mZ3Q7PGJyPg0KJmd0OyAqU3Vi amVjdDoqUmU6IFtPQVVUSC1XR10gSldUIGdyYW50X3R5cGUgYW5kIGNsaWVudF9pZDxicj4NCiZn dDs8YnI+DQomZ3Q7IFllcywgdGhhdCBpcyBjb3JyZWN0Ljxicj4NCiZndDs8YnI+DQomZ3Q7IEkn bSB3b3JraW5nIG9uIG5ldyByZXZpc2lvbnMgb2YgdGhlIGRyYWZ0cyB0aGF0IHdpbGwgaG9wZWZ1 bGx5IG1ha2UgdGhhdDxicj4NCiZndDsgcG9pbnQgbW9yZSBjbGVhci48YnI+DQomZ3Q7PGJyPg0K Jmd0OyBPbiBUaHUsIE1hciAxNCwgMjAxMyBhdCA1OjI2IFBNLCBMZXdpcyBBZGFtLUNBTDAyMjxi cj4NCiZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpBZGFtLkxld2lzQG1vdG9yb2xhc29sdXRpb25z LmNvbSI+QWRhbS5MZXdpc0Btb3Rvcm9sYXNvbHV0aW9ucy5jb208L2E+PGJyPg0KJmd0OyAmbHQ7 bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpBZGFtLkxld2lzQG1vdG9yb2xhc29sdXRpb25zLmNvbSI+ QWRhbS5MZXdpc0Btb3Rvcm9sYXNvbHV0aW9ucy5jb208L2E+Jmd0OyZndDsgd3JvdGU6PGJyPg0K Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4mZ3Q7IENvbWluZyBiYWNrIHRvIHRoaXMuLi4gJm5ic3A7YW0gSSBjb3Jy ZWN0IGluIHRoYXQgY2xpZW50X2lkIGlzIG5vdCByZXF1aXJlZD8gJm5ic3A7ICZuYnNwO1dlIGFy ZSBpbXBsZW1lbnRpbmcgdGhpcyBzcGVjIGFuZCB3YW50IHRvIG1ha2Ugc3VyZQ0KIHRoYXQgd2Ug YXJlIGRvaW5nIGl0IHJpZ2h0LiAmbmJzcDsgJm5ic3A7QnkgbXkgdW5kZXJzdGFuZGluZyB0aGUg b25seSB0d28gcGFyYW1ldGVycyB0aGF0IGFyZSByZXF1aXJlZCBpbiB0aGUgSldUIGdyYW50IHR5 cGUgYXJlICZuYnNwOyZxdW90O3VybjppZXRmOnBhcmFtczpvYXV0aDpncmFudC10eXBlOmp3dC1i ZWFyZXImcXVvdDsgJm5ic3A7ICZuYnNwO2FuZCB0aGUgYXNzZXJ0aW9uLiAmbmJzcDsgJm5ic3A7 ICZuYnNwO0lzIHRoaXMgY29ycmVjdD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mZ3Q7PGJyPg0KJmd0OyAqRnJvbToqTWlr ZSBKb25lcyBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5j b20iPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvYT48YnI+DQomZ3Q7ICZsdDttYWlsdG86 PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSI+TWljaGFlbC5Kb25l c0BtaWNyb3NvZnQuY29tPC9hPiZndDtdPGJyPg0KJmd0OyAqU2VudDoqTW9uZGF5LCBGZWJydWFy eSAxOCwgMjAxMyA2OjU4IFBNPGJyPg0KJmd0OyAqVG86Kkxld2lzIDxhIGhyZWY9Im1haWx0bzpB ZGFtLUNBTDAyMiUzQm9hdXRoQGlldGYub3JnIj5BZGFtLUNBTDAyMjtvYXV0aEBpZXRmLm9yZzwv YT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYu b3JnPC9hPiZndDtXRzxicj4NCiZndDsgKlN1YmplY3Q6KlJFOiBKV1QgZ3JhbnRfdHlwZSBhbmQg Y2xpZW50X2lkPGJyPg0KJmd0Ozxicj4NCiZndDsgVGhlIGNsaWVudF9pZCB2YWx1ZSBhbmQgdGhl IGFjY2VzcyB0b2tlbiB2YWx1ZSBhcmUgaW5kZXBlbmRlbnQuPGJyPg0KJmd0Ozxicj4NCiZndDsg LS0gTWlrZTxicj4NCiZndDs8YnI+DQomZ3Q7ICpGcm9tOio8YSBocmVmPSJtYWlsdG86b2F1dGgt Ym91bmNlc0BpZXRmLm9yZyI+b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7ICZs dDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciPm9hdXRoLWJv dW5jZXNAaWV0Zi5vcmc8L2E+Jmd0O1ttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5j ZXNAaWV0Zi5vcmciPm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyAmbHQ7bWFp bHRvOjxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnIj5vYXV0aC1ib3VuY2Vz QGlldGYub3JnPC9hPiZndDtdKk9uIEJlaGFsZiBPZipMZXdpcyBBZGFtLUNBTDAyMjxicj4NCiZn dDsgKlNlbnQ6Kk1vbmRheSwgRmVicnVhcnkgMTgsIDIwMTMgMjo1MCBQTTxicj4NCiZndDsgKlRv Oio8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYub3JnPC9hPiAmbHQ7 bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+b2F1dGhAaWV0Zi5vcmc8L2E+ Jmd0O1dHPGJyPg0KJmd0OyAqU3ViamVjdDoqW09BVVRILVdHXSBKV1QgZ3JhbnRfdHlwZSBhbmQg Y2xpZW50X2lkPGJyPg0KJmd0Ozxicj4NCiZndDsgSXMgdGhlcmUgYW55IGd1aWRhbmNlIG9uIHRo ZSB1c2FnZSBvZiBjbGllbnRfaWQgd2hlbiB1c2luZyB0aGUgSldUPGJyPg0KJmd0OyBhc3NlcnRp b24gcHJvZmlsZSBhcyBhIGdyYW50IHR5cGU/IGRyYWZ0LWlldGYtb2F1dGgtand0LWJlYXJlci0w NCBtYWtlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij4mZ3Q7IG5vIG1lbnRpb24gc28gSSBhc3N1bWUgdGhhdCBpdCBpcyBu b3QgcmVxdWlyZWQgLi4uIGJ1dCBpdCB3b3VsZCBiZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mZ3Q7IG5lY2Vz c2FyeSBpZiB1c2luZyBpbiBjb25qdW5jdGlvbiB3aXRoIGEgSE9LIHByb2ZpbGUgd2hlcmUgdGhl IEpXVDxicj4NCiZndDsgYXNzZXJ0aW9uIGlzIGlzc3VlZCB0byAtIGFuZCBtYXkgb25seSBiZSB1 c2VkIGJ5IC0gdGhlIGludGVuZGVkIGNsaWVudC48YnI+DQomZ3Q7IE9idmlvdXNseSB0aGlzIGlz IHN0cmFpZ2h0IGZvcndhcmQgZW5vdWdoLCByZWFsbHkgSSdtIGp1c3QgbG9va2luZyB0byBiZTxi cj4NCiZndDsgc3VyZSB0aGF0IEknbSBub3QgbWlzc2luZyBhbnl0aGluZy48YnI+DQomZ3Q7PGJy Pg0KJmd0OyB0eDxicj4NCiZndDs8YnI+DQomZ3Q7IGFkYW08YnI+DQomZ3Q7PGJyPg0KJmd0Ozxi cj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQomZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOk9B dXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWls dG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPiZndDs8YnI+DQomZ3Q7IDxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PGJyPg0KJmd0Ozxicj4NCiZn dDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQom Z3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGll dGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86T0F1 dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPiZndDs8YnI+DQomZ3Q7IDxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+ DQomZ3Q7PGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NCiZndDsgT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KJmd0OyA8YSBocmVmPSJt YWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCiZndDsgPGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48YnI+DQo8YnI+DQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxp bmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5v cmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9vYXV0aCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48 YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxh IGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0 PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48 YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRo Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_4E1F6AAD24975D4BA5B168042967394367533A20TK5EX14MBXC284r_-- From Adam.Lewis@motorolasolutions.com Sat Mar 16 10:38: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 74AB821F8610 for ; Sat, 16 Mar 2013 10:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_25=0.6, RCVD_IN_DNSWL_LOW=-1, 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 MLHmSMEtKbDx for ; Sat, 16 Mar 2013 10:38:10 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe005.messaging.microsoft.com [216.32.180.188]) by ietfa.amsl.com (Postfix) with ESMTP id 0310D21F8539 for ; Sat, 16 Mar 2013 10:38:09 -0700 (PDT) Received: from mail6-co1-R.bigfish.com (10.243.78.250) by CO1EHSOBE002.bigfish.com (10.243.66.65) with Microsoft SMTP Server id 14.1.225.23; Sat, 16 Mar 2013 17:38:09 +0000 Received: from mail6-co1 (localhost [127.0.0.1]) by mail6-co1-R.bigfish.com (Postfix) with ESMTP id 063D8900111 for ; Sat, 16 Mar 2013 17:38:09 +0000 (UTC) X-Forefront-Antispam-Report: CIP:129.188.136.17; KIP:(null); UIP:(null); IPV:NLI; H:il06msg01.mot-solutions.com; RD:none; EFVD:NLI X-SpamScore: -37 X-BigFish: VPS-37(zzbb2dI98dI9371Ic89bh936eI1441M542I1432Ic857h179dNzz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahz97hz18de19h1033IL17326ah8275dh18c673h1954cbh8275bhz2fh2a8h683h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1155h) Received-SPF: pass (mail6-co1: domain of motorolasolutions.com designates 129.188.136.17 as permitted sender) client-ip=129.188.136.17; envelope-from=Adam.Lewis@motorolasolutions.com; helo=il06msg01.mot-solutions.com ; olutions.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.237.133; KIP:(null); UIP:(null); (null); H:BY2PRD0411HT003.namprd04.prod.outlook.com; R:internal; EFV:INT Received: from mail6-co1 (localhost.localdomain [127.0.0.1]) by mail6-co1 (MessageSwitch) id 1363455485799517_31445; Sat, 16 Mar 2013 17:38:05 +0000 (UTC) Received: from CO1EHSMHS004.bigfish.com (unknown [10.243.78.230]) by mail6-co1.bigfish.com (Postfix) with ESMTP id B74AF44004A for ; Sat, 16 Mar 2013 17:38:05 +0000 (UTC) Received: from il06msg01.mot-solutions.com (129.188.136.17) by CO1EHSMHS004.bigfish.com (10.243.66.14) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 16 Mar 2013 17:38:05 +0000 Received: from il06msg01.mot-solutions.com (il06vts02.mot.com [129.188.137.142]) by il06msg01.mot-solutions.com (8.14.3/8.14.3) with ESMTP id r2GHc4s4021547 for ; Sat, 16 Mar 2013 12:38:04 -0500 (CDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe002.messaging.microsoft.com [216.32.180.12]) by il06msg01.mot-solutions.com (8.14.3/8.14.3) with ESMTP id r2GHc3Hp021534 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 16 Mar 2013 12:38:04 -0500 (CDT) Received: from mail97-va3-R.bigfish.com (10.7.14.240) by VA3EHSOBE007.bigfish.com (10.7.40.11) with Microsoft SMTP Server id 14.1.225.23; Sat, 16 Mar 2013 17:38:03 +0000 Received: from mail97-va3 (localhost [127.0.0.1]) by mail97-va3-R.bigfish.com (Postfix) with ESMTP id 4BC7E2A0176 for ; Sat, 16 Mar 2013 17:38:03 +0000 (UTC) Received: from mail97-va3 (localhost.localdomain [127.0.0.1]) by mail97-va3 (MessageSwitch) id 1363455480176934_21840; Sat, 16 Mar 2013 17:38:00 +0000 (UTC) Received: from VA3EHSMHS005.bigfish.com (unknown [10.7.14.225]) by mail97-va3.bigfish.com (Postfix) with ESMTP id 247F230004E; Sat, 16 Mar 2013 17:38:00 +0000 (UTC) Received: from BY2PRD0411HT003.namprd04.prod.outlook.com (157.56.237.133) by VA3EHSMHS005.bigfish.com (10.7.99.15) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 16 Mar 2013 17:37:59 +0000 Received: from BY2PRD0411MB441.namprd04.prod.outlook.com ([169.254.5.31]) by BY2PRD0411HT003.namprd04.prod.outlook.com ([10.255.128.38]) with mapi id 14.16.0275.006; Sat, 16 Mar 2013 17:37:58 +0000 From: Lewis Adam-CAL022 To: Mike Jones , Phil Hunt Thread-Topic: [OAUTH-WG] JWT grant_type and client_id Thread-Index: Ac4h4g4wygAJgL9ySFC/PJajtkIVLAAScwAAAA9vA+AAAMbVUA== Date: Sat, 16 Mar 2013 17:37:57 +0000 Message-ID: <59E470B10C4630419ED717AC79FCF9A9568A991E@BY2PRD0411MB441.namprd04.prod.outlook.com> References: <4E1F6AAD24975D4BA5B16804296739436752C010@TK5EX14MBXC284.redmond.corp.microsoft.com> <577837CC-A415-4F7E-82A2-CDB21859650C@oracle.com> <4E1F6AAD24975D4BA5B168042967394367533A20@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394367533A20@TK5EX14MBXC284.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [150.130.138.7] Content-Type: multipart/alternative; boundary="_000_59E470B10C4630419ED717AC79FCF9A9568A991EBY2PRD0411MB441_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%1294$Dn%MICROSOFT.COM$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn% X-FOPE-CONNECTOR: Id%1294$Dn%ORACLE.COM$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn% X-FOPE-CONNECTOR: Id%1294$Dn%PINGIDENTITY.COM$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn% X-FOPE-CONNECTOR: Id%1294$Dn%IETF.ORG$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn% X-CFilter-Loop: Reflected X-OriginatorOrg: motorolasolutions.com Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] JWT grant_type and client_id X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Mar 2013 17:38:12 -0000 --_000_59E470B10C4630419ED717AC79FCF9A9568A991EBY2PRD0411MB441_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzENCg0KSeKAmXZlIGJlZW4gdHJ5aW5nIHRvIGFyZ3VlIHRoaXMgZm9yIGEgIGJpdCBub3cg4oCm IHRoYXQgd2hpbGUgT0F1dGggbWF5IG5vdCBkZXByZWNhdGUgdGhlIHVzYWdlIG9mIHVuc3RydWN0 dXJlZCBhY2Nlc3MgdG9rZW5zIChvciBwcm9oaWJpdGluZyBvdGhlcnMgZnJvbSBkZWZpbmluZyB0 aGVpciBvd24pIHRoYXQgaGF2aW5nIGEgV0cgZ3VpZGFuY2Ugb24gd2hhdCBhIHN0cnVjdHVyZWQg SldUIChvciBTQU1MKSBhY2Nlc3MgdG9rZW4gd291bGQgbGlrZSDigKYgSSB0aGluayBkZXZlbG9w ZXJzIG1vdmluZyBmb3J3YXJkIG1pZ2h0IGJlIGluY2xpbmVkIHRvIHVzZSBpdC4NCg0KYWRhbQ0K DQpGcm9tOiBNaWtlIEpvbmVzIFttYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tXQ0K U2VudDogU2F0dXJkYXksIE1hcmNoIDE2LCAyMDEzIDEyOjE3IFBNDQpUbzogUGhpbCBIdW50DQpD YzogQnJpYW4gQ2FtcGJlbGw7IExld2lzIEFkYW0tQ0FMMDIyOyBvYXV0aEBpZXRmLm9yZw0KU3Vi amVjdDogUkU6IFtPQVVUSC1XR10gSldUIGdyYW50X3R5cGUgYW5kIGNsaWVudF9pZA0KDQpJIGFn cmVlIHRoYXQgaXTigJlzIGxpa2VseSBhIGNsYWltIHRoYXQgd291bGQgYmUgdXNlZCBpbiBhY2Nl c3MgdG9rZW5zLg0KDQpJ4oCZbSBjb21pbmcgdG8gdGhlIGNvbmNsdXNpb24gdGhhdCB3ZSBzaG91 bGQgYWN0dWFsbHkgd3JpdGUgYW4gYWNjZXNzIHRva2VuIHByb2ZpbGUgZm9yIEpXVCBhbmQgcHJv YmFibHkgU0FNTCBhcyB3ZWxsLiAgVGhpcyB3b3VsZCBiZSBwYXJhbGxlbCB0byB0aGUga2luZHMg b2YgcmVxdWlyZW1lbnRzIHBsYWNlZCBvbiB0aGUgdXNlIG9mIFNBTUwgYW5kIEpXVCB3aGVuIHVz ZWQgZm9yIGNsaWVudCBhdXRoZW50aWNhdGlvbiBhbmQgYXMgcmVzb3VyY2UgZ3JhbnRzLiAgVGhp cyBjb3VsZCBvbmx5IGhlbHAgaW50ZXJvcGVyYWJpbGl0eSwgYXMgcGVvcGxlIHdvdWxkIGhhdmUg YSBwbGFjZSB0byBnbyB0byByZWFkIGFib3V0IGJlc3QgcHJhY3RpY2VzIGZvciB0aGlzIHVzZSBj YXNlLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IFBoaWwgSHVudCBbbWFpbHRvOnBoaWwuaHVudEBv cmFjbGUuY29tXQ0KU2VudDogU2F0dXJkYXksIE1hcmNoIDE2LCAyMDEzIDI6NTIgQU0NClRvOiBN aWtlIEpvbmVzDQpDYzogQnJpYW4gQ2FtcGJlbGw7IExld2lzIEFkYW0tQ0FMMDIyOyBvYXV0aEBp ZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBK V1QgZ3JhbnRfdHlwZSBhbmQgY2xpZW50X2lkDQoNCkl0J3MgYSBxdWVzdGlvbiBvZiB3aGV0aGVy IHRoZSBqd3Qgc3BlYyBhbG9uZSBpcyB1c2VkIChpbiB3aGljaCBjYXNlIGl0IG5lZWRzIHNjb3Bl KSBvciB3aGV0aGVyIGFub3RoZXIgcHJvZmlsZSBmb3IgYWNjZXNzIHRva2VucyBpcyBuZWVkZWQu DQoNClNpbmNlIHNjb3BlIGlzIGZ1bmRhbWVudGFsIHRvIG9hdXRoLCBpIHRoaW5rIGl0IGlzIHBh cnQgaWYgdGhlIGNvcmUgc2V0IG9mIG1pbmltYWwgYXR0cmlidXRlcyBmb3IgYWNjZXNzIHRva2Vu cy4gIEluIGZhY3QgaSBjYWIgZW52aXNpb24gY2FzZXMgd2hlcmUgcmVmZXJlbmNlcyB0byBhdXRo b3JpemluZyB1c2VyIG9yIGNsaWVudCBtaWdodCBiZSBlbGltaW5hdGVkIG9yIGFub255bWl6ZWQg bGVhdmluZyBvbmx5IG9uZS4gRWcgZ3JhbnQgdGhlIGhvbGRlciBvZiB0aGlzIHRva2VuIHRoZSBy aWdodCB0byBkbyBzY29wZSB4eXouDQoNClBoaWwNCg0KU2VudCBmcm9tIG15IHBob25lLg0KDQpP biAyMDEzLTAzLTE1LCBhdCAyMTowMywgTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3Nv ZnQuY29tPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+PiB3cm90ZToNCkhhdmlu ZyBhIHNjb3BlIGNsYWltIGluIHNwZWNpZmljIHByb2ZpbGVzIGNvdWxkIG1ha2Ugc2Vuc2UuICBU aGF0IGRvZXNu4oCZdCBtZWFuIHRoYXQgaXQgaGFzIHRvIGJlIGRlZmluZWQgaW4gdGhlIEpXVCBz cGVjIHBlciBzZS4gIElmIGFueXRoaW5nLCBwZW9wbGUgZXhwcmVzc2VkIGEgZGVzaXJlIGluIHll c3RlcmRheeKAmXMgd29ya2luZyBncm91cCBtZWV0aW5nIHRvIGtlZXAgdGhlIGJhc2UgY2xhaW1z IHNldCBzbWFsbCwgcmF0aGVyIHRoYW4gZXhwYW5kaW5nIGl0Lg0KDQpQcm9maWxlcyBjYW4gcmVn aXN0ZXIgdGhlIGNsYWltcyB0aGV5IGRlZmluZSBpbiB0aGUgSUFOQSBKV1QgQ2xhaW1zIHJlZ2lz dHJ5LCBpZiB0aGV5IGNob29zZS4NCg0KLS0gTWlrZQ0KDQoNCkZyb206IExld2lzIEFkYW0tQ0FM MDIyDQpTZW50OiDigI5NYXJjaOKAjiDigI4xNeKAjiwg4oCOMjAxMyDigI4z4oCOOuKAjjU14oCO IOKAjlBNDQpUbzogQnJpYW4gQ2FtcGJlbGwNCkNDOiBvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1 dGhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBKV1QgZ3JhbnRfdHlwZSBhbmQg Y2xpZW50X2lkDQoNCkkgZ3Vlc3MgdGhhdCBpdCBkZXBlbmRzIG9uIHdoYXQgSldUIGlzIG1lYW50 IHRvIGJlLiAgTXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IGl0IGJlZ2FuIGFzIHNvbWV0aGluZyB0 byBzdXBwb3J0IFdlYiBTU08gYXV0aGVudGljYXRpb24gZm9yIE9JREMsIHNvIHNjb3BlIGRpZG7i gJl0IG1ha2UgYW55IHNlbnNlIHRoZW4uICBOb3IgZG9lcyBpdCBtYWtlIGFueSBzZW5zZSBhcyBh IHN0cmljdCBncmFudCB0eXBlLiAgVGhlIHVzZSBjYXNlIHdoZXJlIGl0IGJlY29tZXMgaW50ZXJl c3RpbmcgKHRoZSBvbmUgSSBhbSBsb29raW5nIHRvKSBpcyBmb3Igd2hlbiBhbiBhY2Nlc3MgdG9r ZW4gb3IgcmVmcmVzaCB0b2tlbiBpcyBhIEpXVC4gIEkgdGhpbmsgc29tZSB2ZW5kb3JzIGFyZSBi ZWdpbm5pbmcgdG8gbWFrZSB0aGVpciBzdHJ1Y3R1cmVkIHRva2VucyBhIEpXVCwgYW5kIHRoYXQg aXMgbXkgY3VycmVudCB0aGlua2luZyBhcyB3ZWxsIOKApiBpZiBmb2xrcyBhZ3JlZSB0aGF0IEpX VCBjYW4gYmUgdXNlZCBhcyB0aGUgc3RydWN0dXJlIGZvciBPQXV0aCB0b2tlbnMsIHRoZW4gaXQg bWFrZXMgc2Vuc2UgdG8gaW5jbHVkZSBhIHNjb3BlIGZpZWxkLiAgSWYgbm90LCB0aGVuIGl0IHdp bGwgYmUgSlNPTitlbmNyeXB0aW9uK3NpZ25pbmcsIGp1c3Qgbm90IGEgSldUIOKYug0KDQphZGFt DQoNCkZyb206IEJyaWFuIENhbXBiZWxsIFttYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5j b21dDQpTZW50OiBGcmlkYXksIE1hcmNoIDE1LCAyMDEzIDU6MTYgUE0NClRvOiBMZXdpcyBBZGFt LUNBTDAyMg0KQ2M6IFNlcmdleSBCZXJ5b3praW47IG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0 aEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIEpXVCBncmFudF90eXBlIGFuZCBj bGllbnRfaWQNCg0KQ29kaWZ5aW5nIGEgY2xhaW0vYXR0cmlidXRlIGZvciBzY29wZSB0aGF0IGdv ZXMgaW4gdGhlIGFzc2VydGlvbiBpcyBzb21ldGhpbmcgdGhhdCdzIGJlZW4gZGlzY3Vzc2VkIGJ1 dCBuZXZlciBzZWVtZWQgdG8gZ2V0IHN1ZmZpY2llbnQgY29uc2Vuc3VzIHJlZ2FyZGluZyBob3cg dG8gZXhhY3RseSB0byBkbyBpdCBhbmQgaWYgaXQgcmVhbGx5IHByb3ZpZGVkIG11Y2ggdmFsdWUu DQoNCk9uIEZyaSwgTWFyIDE1LCAyMDEzIGF0IDQ6MTIgUE0sIEJyaWFuIENhbXBiZWxsIDxiY2Ft cGJlbGxAcGluZ2lkZW50aXR5LmNvbTxtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20+ PiB3cm90ZToNClNvIGN1cnJlbnRseSB0aGUgYmFzZSBhc3NlcnRpb24gZG9jdW1lbnQgZGVmaW5l cyBzY29wZSBhcyBhbiBIVFRQIHBhcmFtZXRlciBvbiB0aGUgYWNjZXNzIHRva2VuIHJlcXVlc3Qg bWVzc2FnZSB3aGVuIHVzaW5nIGFuIGFzc2VydGlvbiBhcyBhIGdyYW50WzFdLiAgQW5kIHRoYXQg YXBwbGllcyB0byBib3RoIHRoZSBTQU1MIGFuZCBKV1QgZ3JhbnRzIChwZXJoYXBzIHRoYXQgbmVl ZHMgdG8gYmUgbW9yZSBjbGVhcj8pLiBBbHNvIFJGQyA2NzQ5IGRlZmluZXMgdGhlIHNjb3BlIHBh cmFtZXRlciBmb3IgdGhlIGNsaWVudCBjcmVkZW50aWFscyBhY2Nlc3MgdG9rZW4gcmVxdWVzdFsy XSwgd2hpY2ggc2ltaWxhcmx5IGFwcGxpZXMgdG8gYm90aCBTQU1MIGFuZCBKV1QgaW4gdGhlIGNh c2Ugb2YgYXNzZXJ0aW9uIGNsaWVudCBhdXRoZW50aWNhdGlvbiB1c2luZyB0aGUgImNsaWVudF9j cmVkZW50aWFscyIgZ3JhbnQgdHlwZS4NCg0KWzFdIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtb2F1dGgtYXNzZXJ0aW9ucy0xMCNzZWN0aW9uLTQuMQ0KWzJdIGh0dHA6Ly90 b29scy5pZXRmLm9yZy9odG1sL3JmYzY3NDkjc2VjdGlvbi00LjQuMQ0KDQpPbiBGcmksIE1hciAx NSwgMjAxMyBhdCAzOjQzIFBNLCBMZXdpcyBBZGFtLUNBTDAyMiA8QWRhbS5MZXdpc0Btb3Rvcm9s YXNvbHV0aW9ucy5jb208bWFpbHRvOkFkYW0uTGV3aXNAbW90b3JvbGFzb2x1dGlvbnMuY29tPj4g d3JvdGU6DQpSaWdodCAuLi4gdGhpbmtpbmcgYWJvdXQgdGhpcyBmdXJ0aGVyIEkgdGhpbmsgdGhl IGFuc3dlciBpcyAiYWxsIG9mIHRoZSBhYm92ZS4iICBJZiB0aGUgSldUIGlzIGEgZ3JhbnQgdHlw ZSB0aGVuIGFzIHlvdSBzYXkgaXQgbmVlZHMgYSBzY29wZSBwYXJhbSBhbmQgb3B0aW9uYWxseSBh IGNsaWVudF9pZCBwYXJhbS4gIEkgYXJndWVkIGZvciB0aGUgY2xpZW50X2lkIHBhcmFtIGVhcmxp ZXIgc2luY2UgaXQgY291bGQgYXNzaXN0IHdpdGggSE9LIHNjZW5hcmlvcyBvbmNlIHRob3NlIGZ1 cnRoZXIgZGV2ZWxvcC4NCg0KQnV0IHdoZW4gdGhlIEpXVCBpcyB1c2VkIGFzIGFuIEFUIHRoZW4g aXQgd2lsbCBkZWZpbml0ZWx5IHJlcXVpcmUgdGhlIHNjb3BlIGFzIGEgY2xhaW0uDQoNClNvIEkg Y2hhbmdlIG15IGFyZ3VtZW50IHRvICJib3RoIiA6KQ0KDQphZGFtDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBvYXV0aC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpvYXV0aC1i b3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm9h dXRoLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgU2VyZ2V5IEJlcnlvemtpbg0KU2Vu dDogRnJpZGF5LCBNYXJjaCAxNSwgMjAxMyA0OjMxIFBNDQpUbzogb2F1dGhAaWV0Zi5vcmc8bWFp bHRvOm9hdXRoQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gSldUIGdyYW50X3R5 cGUgYW5kIGNsaWVudF9pZA0KDQpIaQ0KT24gMTUvMDMvMTMgMjA6NDAsIExld2lzIEFkYW0tQ0FM MDIyIHdyb3RlOg0KPiBIaSBKb2huLA0KPg0KPiBJIHdvdWxkIGxpa2UgdG8gYXJndWUgdGhhdCB0 aGUgc2NvcGUgc2hvdWxkIGJlIGEgcGFyYW1ldGVyIGluIHRoZSBhY2Nlc3MNCj4gdG9rZW4gcmVx dWVzdCBtZXNzYWdlLCB0aGUgc2FtZSBhcyBpdCBpcyBmb3IgdGhlIFJPIGNyZWRzIGdyYW50IGFu ZA0KPiBjbGllbnQgY3JlZHMgZ3JhbnQgdHlwZS4gVGhpcyB3b3VsZCBrZWVwIGl0IGNvbnNpc3Rl bnQgd2l0aCB0aGUgY29yZQ0KPiBPQXV0aCBncmFudCB0eXBlcyB0aGF0IHRhbGsgZGlyZWN0bHkg dG8gdGhlIHRva2VuIGVuZHBvaW50Lg0KPg0KQXNzdW1pbmcgdGhlIGFzc2VydGlvbiBpcyBhY3Rp bmcgYXMgYSBncmFudCwgdGhlbiBpdCBpcyBpbmRlZWQgYW4gYWNjZXNzDQp0b2tlbiByZXF1ZXN0 IG1lc3NhZ2UsIHNvIElNSE8gaXQgbWFrZXMgc2Vuc2UgdG8gZ2V0IGFuIG91dGJvdW5kIHNjb3Bl DQpwYXJhbWV0ZXIgb3B0aW9uYWxseSBzdXBwb3J0ZWQgd2hpY2ggSSBndWVzcyB3aWxsIGltcGx5 IHRoYXQgdGhlIGNsaWVudA0KaWQgd2lsbCBhbHNvIGhhdmUgdG8gYWNjb21wYW55IGl0Li4uDQoN CkNoZWVycywgU2VyZ2V5DQoNCj4gVGhvdWdodHM/DQo+DQo+IGFkYW0NCj4NCj4gKkZyb206Kkpv aG4gQnJhZGxleSBbbWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tPG1haWx0bzp2ZTdqdGJAdmU3anRi LmNvbT5dDQo+ICpTZW50OiogRnJpZGF5LCBNYXJjaCAxNSwgMjAxMyAxMjoxMCBQTQ0KPiAqVG86 KiBMZXdpcyBBZGFtLUNBTDAyMg0KPiAqQ2M6KiBCcmlhbiBDYW1wYmVsbDsgIldHIDxvYXV0aEBp ZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+PiJAaWwwNmV4cjAyLm1vdC5jb208aHR0cDov L2lsMDZleHIwMi5tb3QuY29tPg0KPiAqU3ViamVjdDoqIFJlOiBbT0FVVEgtV0ddIEpXVCBncmFu dF90eXBlIGFuZCBjbGllbnRfaWQNCj4NCj4gVGhlIHNwZWMgaXMgYSB0b3VjaCB2YWd1ZSBvbiB0 aGF0LiBJIHRoaW5rIHRoZSBzY29wZXMgc2hvdWxkIGJlIGluIHRoZQ0KPiBhc3NlcnRpb24gYW5k IHRoZSBjbGllbnQgY2FuIHVzZSB0aGUgc2NvcGVzIG91dHNpZGUgdGhlIGFzc2VydGlvbiB0bw0K PiBkb3duLXNjb3BlLg0KPg0KPiBIYXZpbmcgYSBzdGFuZGFyZCBjbGFpbSBpbiBKV1QgYW5kIFNB TUwgZm9yIHBhc3Npbmcgc2NvcGVzIGlzIHByb2JhYmx5DQo+IHVzZWZ1bCBhcyBwYXJ0IG9mIGEg cHJvZmlsZS4NCj4NCj4gSm9obiBCLg0KPg0KPiBPbiAyMDEzLTAzLTE0LCBhdCA4OjQ3IFBNLCBM ZXdpcyBBZGFtLUNBTDAyMg0KPiA8QWRhbS5MZXdpc0Btb3Rvcm9sYXNvbHV0aW9ucy5jb208bWFp bHRvOkFkYW0uTGV3aXNAbW90b3JvbGFzb2x1dGlvbnMuY29tPg0KPiA8bWFpbHRvOkFkYW0uTGV3 aXNAbW90b3JvbGFzb2x1dGlvbnMuY29tPG1haWx0bzpBZGFtLkxld2lzQG1vdG9yb2xhc29sdXRp b25zLmNvbT4+PiB3cm90ZToNCj4NCj4NCj4NCj4gSG1tbSwgb25lIG1vcmUgdGhvdWdodCAuLi4g bm8gc2NvcGU/PyBUaGUgSldUIGlzIHRoZSBncmFudCwgaXMgaXQgYXNzdW1lZA0KPiB0aGF0IHRo ZSBzY29wZSBpcyBjb252ZXllZCBhcyBhIGNsYWltIHdpdGhpbiB0aGUgdG9rZW4/IE90aGVyd2lz ZSBpdA0KPiB3b3VsZCBzZWVtIHRoYXQgaXQgd291bGQgcmVxdWlyZSBhIHNjb3BlLg0KPg0KPiBU aG91Z2h0cz8NCj4NCj4gYWRhbQ0KPg0KPiAqRnJvbToqQnJpYW4gQ2FtcGJlbGwgW21haWx0bzpi Y2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTxtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5j b20+DQo+IDxodHRwOi8vcGluZ2lkZW50aXR5LmNvbT5dDQo+ICpTZW50OipUaHVyc2RheSwgTWFy Y2ggMTQsIDIwMTMgNDo0NCBQTQ0KPiAqVG86Kkxld2lzIEFkYW0tQ0FMMDIyDQo+ICpDYzoqTWlr ZSBKb25lczsgIldHIDxvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+DQo+IDxt YWlsdG86b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4+IkBpbDA2ZXhyMDIu bW90LmNvbTxodHRwOi8vaWwwNmV4cjAyLm1vdC5jb20+IDxodHRwOi8vaWwwNmV4cjAyLm1vdC5j b20+DQo+ICpTdWJqZWN0OipSZTogW09BVVRILVdHXSBKV1QgZ3JhbnRfdHlwZSBhbmQgY2xpZW50 X2lkDQo+DQo+IFllcywgdGhhdCBpcyBjb3JyZWN0Lg0KPg0KPiBJJ20gd29ya2luZyBvbiBuZXcg cmV2aXNpb25zIG9mIHRoZSBkcmFmdHMgdGhhdCB3aWxsIGhvcGVmdWxseSBtYWtlIHRoYXQNCj4g cG9pbnQgbW9yZSBjbGVhci4NCj4NCj4gT24gVGh1LCBNYXIgMTQsIDIwMTMgYXQgNToyNiBQTSwg TGV3aXMgQWRhbS1DQUwwMjINCj4gPEFkYW0uTGV3aXNAbW90b3JvbGFzb2x1dGlvbnMuY29tPG1h aWx0bzpBZGFtLkxld2lzQG1vdG9yb2xhc29sdXRpb25zLmNvbT4NCj4gPG1haWx0bzpBZGFtLkxl d2lzQG1vdG9yb2xhc29sdXRpb25zLmNvbTxtYWlsdG86QWRhbS5MZXdpc0Btb3Rvcm9sYXNvbHV0 aW9ucy5jb20+Pj4gd3JvdGU6DQo+DQo+IENvbWluZyBiYWNrIHRvIHRoaXMuLi4gIGFtIEkgY29y cmVjdCBpbiB0aGF0IGNsaWVudF9pZCBpcyBub3QgcmVxdWlyZWQ/ICAgIFdlIGFyZSBpbXBsZW1l bnRpbmcgdGhpcyBzcGVjIGFuZCB3YW50IHRvIG1ha2Ugc3VyZSB0aGF0IHdlIGFyZSBkb2luZyBp dCByaWdodC4gICAgQnkgbXkgdW5kZXJzdGFuZGluZyB0aGUgb25seSB0d28gcGFyYW1ldGVycyB0 aGF0IGFyZSByZXF1aXJlZCBpbiB0aGUgSldUIGdyYW50IHR5cGUgYXJlICAidXJuOmlldGY6cGFy YW1zOm9hdXRoOmdyYW50LXR5cGU6and0LWJlYXJlciIgICAgYW5kIHRoZSBhc3NlcnRpb24uICAg ICAgSXMgdGhpcyBjb3JyZWN0Pw0KPg0KPiAqRnJvbToqTWlrZSBKb25lcyBbbWFpbHRvOk1pY2hh ZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29t Pg0KPiA8bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5K b25lc0BtaWNyb3NvZnQuY29tPj5dDQo+ICpTZW50OipNb25kYXksIEZlYnJ1YXJ5IDE4LCAyMDEz IDY6NTggUE0NCj4gKlRvOipMZXdpcyBBZGFtLUNBTDAyMjtvYXV0aEBpZXRmLm9yZzxtYWlsdG86 QWRhbS1DQUwwMjIlM0JvYXV0aEBpZXRmLm9yZz4gPG1haWx0bzpvYXV0aEBpZXRmLm9yZzxtYWls dG86b2F1dGhAaWV0Zi5vcmc+PldHDQo+ICpTdWJqZWN0OipSRTogSldUIGdyYW50X3R5cGUgYW5k IGNsaWVudF9pZA0KPg0KPiBUaGUgY2xpZW50X2lkIHZhbHVlIGFuZCB0aGUgYWNjZXNzIHRva2Vu IHZhbHVlIGFyZSBpbmRlcGVuZGVudC4NCj4NCj4gLS0gTWlrZQ0KPg0KPiAqRnJvbToqb2F1dGgt Ym91bmNlc0BpZXRmLm9yZzxtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZz4NCj4gPG1haWx0 bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPj5b bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5v cmc+DQo+IDxtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86b2F1dGgtYm91bmNl c0BpZXRmLm9yZz4+XSpPbiBCZWhhbGYgT2YqTGV3aXMgQWRhbS1DQUwwMjINCj4gKlNlbnQ6Kk1v bmRheSwgRmVicnVhcnkgMTgsIDIwMTMgMjo1MCBQTQ0KPiAqVG86Km9hdXRoQGlldGYub3JnPG1h aWx0bzpvYXV0aEBpZXRmLm9yZz4gPG1haWx0bzpvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhA aWV0Zi5vcmc+PldHDQo+ICpTdWJqZWN0OipbT0FVVEgtV0ddIEpXVCBncmFudF90eXBlIGFuZCBj bGllbnRfaWQNCj4NCj4gSXMgdGhlcmUgYW55IGd1aWRhbmNlIG9uIHRoZSB1c2FnZSBvZiBjbGll bnRfaWQgd2hlbiB1c2luZyB0aGUgSldUDQo+IGFzc2VydGlvbiBwcm9maWxlIGFzIGEgZ3JhbnQg dHlwZT8gZHJhZnQtaWV0Zi1vYXV0aC1qd3QtYmVhcmVyLTA0IG1ha2VzDQo+IG5vIG1lbnRpb24g c28gSSBhc3N1bWUgdGhhdCBpdCBpcyBub3QgcmVxdWlyZWQgLi4uIGJ1dCBpdCB3b3VsZCBiZQ0K PiBuZWNlc3NhcnkgaWYgdXNpbmcgaW4gY29uanVuY3Rpb24gd2l0aCBhIEhPSyBwcm9maWxlIHdo ZXJlIHRoZSBKV1QNCj4gYXNzZXJ0aW9uIGlzIGlzc3VlZCB0byAtIGFuZCBtYXkgb25seSBiZSB1 c2VkIGJ5IC0gdGhlIGludGVuZGVkIGNsaWVudC4NCj4gT2J2aW91c2x5IHRoaXMgaXMgc3RyYWln aHQgZm9yd2FyZCBlbm91Z2gsIHJlYWxseSBJJ20ganVzdCBsb29raW5nIHRvIGJlDQo+IHN1cmUg dGhhdCBJJ20gbm90IG1pc3NpbmcgYW55dGhpbmcuDQo+DQo+IHR4DQo+DQo+IGFkYW0NCj4NCj4N Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gT0F1 dGggbWFpbGluZyBsaXN0DQo+IE9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4g PG1haWx0bzpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+Pg0KPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo+DQo+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IE9BdXRoIG1haWxpbmcgbGlzdA0K PiBPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+IDxtYWlsdG86T0F1dGhAaWV0 Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPj4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9vYXV0aA0KPg0KPg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4gT0F1dGhAaWV0 Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL29hdXRoDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpP QXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1 dGgNCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0 Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1h aWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0K --_000_59E470B10C4630419ED717AC79FCF9A9568A991EBY2PRD0411MB441_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglw YW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFy IjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4w cHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnAuTXNvTGlzdFBhcmFn cmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0 eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJ bWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Iiwic2VyaWYiO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxs b29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpw Lm1zb2xpc3RwYXJhZ3JhcGhjeHNwZmlyc3QsIGxpLm1zb2xpc3RwYXJhZ3JhcGhjeHNwZmlyc3Qs IGRpdi5tc29saXN0cGFyYWdyYXBoY3hzcGZpcnN0DQoJe21zby1zdHlsZS1uYW1lOm1zb2xpc3Rw YXJhZ3JhcGhjeHNwZmlyc3Q7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsN CgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglsaW5lLWhlaWdodDoxMTUlOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpwLm1zb2xpc3RwYXJhZ3JhcGhjeHNw bWlkZGxlLCBsaS5tc29saXN0cGFyYWdyYXBoY3hzcG1pZGRsZSwgZGl2Lm1zb2xpc3RwYXJhZ3Jh cGhjeHNwbWlkZGxlDQoJe21zby1zdHlsZS1uYW1lOm1zb2xpc3RwYXJhZ3JhcGhjeHNwbWlkZGxl Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTow aW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJbGluZS1o ZWlnaHQ6MTE1JTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLCJzZXJpZiI7fQ0KcC5tc29saXN0cGFyYWdyYXBoY3hzcGxhc3QsIGxpLm1zb2xpc3Rw YXJhZ3JhcGhjeHNwbGFzdCwgZGl2Lm1zb2xpc3RwYXJhZ3JhcGhjeHNwbGFzdA0KCXttc28tc3R5 bGUtbmFtZTptc29saXN0cGFyYWdyYXBoY3hzcGxhc3Q7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFy Z2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglsaW5lLWhlaWdodDoxMTUlOw0KCWZvbnQtc2l6ZTox Mi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLkVt YWlsU3R5bGUyMw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjUN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+JiM0MzsxPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5J4oCZdmUgYmVl biB0cnlpbmcgdG8gYXJndWUgdGhpcyBmb3IgYSAmbmJzcDtiaXQgbm93IOKApiB0aGF0IHdoaWxl IE9BdXRoIG1heSBub3QgZGVwcmVjYXRlIHRoZSB1c2FnZSBvZiB1bnN0cnVjdHVyZWQgYWNjZXNz IHRva2VucyAob3IgcHJvaGliaXRpbmcgb3RoZXJzIGZyb20gZGVmaW5pbmcNCiB0aGVpciBvd24p IHRoYXQgaGF2aW5nIGEgV0cgZ3VpZGFuY2Ugb24gd2hhdCBhIHN0cnVjdHVyZWQgSldUIChvciBT QU1MKSBhY2Nlc3MgdG9rZW4gd291bGQgbGlrZSDigKYgSSB0aGluayBkZXZlbG9wZXJzIG1vdmlu ZyBmb3J3YXJkIG1pZ2h0IGJlIGluY2xpbmVkIHRvIHVzZSBpdC48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPmFkYW0mbmJz cDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IE1pa2UgSm9uZXMgW21haWx0bzpNaWNoYWVsLkpvbmVz QG1pY3Jvc29mdC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gU2F0dXJkYXksIE1hcmNoIDE2LCAy MDEzIDEyOjE3IFBNPGJyPg0KPGI+VG86PC9iPiBQaGlsIEh1bnQ8YnI+DQo8Yj5DYzo8L2I+IEJy aWFuIENhbXBiZWxsOyBMZXdpcyBBZGFtLUNBTDAyMjsgb2F1dGhAaWV0Zi5vcmc8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUkU6IFtPQVVUSC1XR10gSldUIGdyYW50X3R5cGUgYW5kIGNsaWVudF9pZDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGFncmVlIHRoYXQgaXTigJlzIGxpa2Vs eSBhIGNsYWltIHRoYXQgd291bGQgYmUgdXNlZCBpbiBhY2Nlc3MgdG9rZW5zLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ SeKAmW0gY29taW5nIHRvIHRoZSBjb25jbHVzaW9uIHRoYXQgd2Ugc2hvdWxkIGFjdHVhbGx5IHdy aXRlIGFuIGFjY2VzcyB0b2tlbiBwcm9maWxlIGZvciBKV1QgYW5kIHByb2JhYmx5IFNBTUwgYXMg d2VsbC4mbmJzcDsgVGhpcyB3b3VsZCBiZSBwYXJhbGxlbCB0byB0aGUga2luZHMgb2YNCiByZXF1 aXJlbWVudHMgcGxhY2VkIG9uIHRoZSB1c2Ugb2YgU0FNTCBhbmQgSldUIHdoZW4gdXNlZCBmb3Ig Y2xpZW50IGF1dGhlbnRpY2F0aW9uIGFuZCBhcyByZXNvdXJjZSBncmFudHMuJm5ic3A7IFRoaXMg Y291bGQgb25seSBoZWxwIGludGVyb3BlcmFiaWxpdHksIGFzIHBlb3BsZSB3b3VsZCBoYXZlIGEg cGxhY2UgdG8gZ28gdG8gcmVhZCBhYm91dCBiZXN0IHByYWN0aWNlcyBmb3IgdGhpcyB1c2UgY2Fz ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAw aW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gUGhp bCBIdW50IFs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iPm1haWx0bzpwaGls Lmh1bnRAb3JhY2xlLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gU2F0dXJkYXksIE1hcmNo IDE2LCAyMDEzIDI6NTIgQU08YnI+DQo8Yj5Ubzo8L2I+IE1pa2UgSm9uZXM8YnI+DQo8Yj5DYzo8 L2I+IEJyaWFuIENhbXBiZWxsOyBMZXdpcyBBZGFtLUNBTDAyMjsgPGEgaHJlZj0ibWFpbHRvOm9h dXRoQGlldGYub3JnIj5vYXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6 IFtPQVVUSC1XR10gSldUIGdyYW50X3R5cGUgYW5kIGNsaWVudF9pZDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCdzIGEgcXVlc3Rpb24gb2Yg d2hldGhlciB0aGUgand0IHNwZWMgYWxvbmUgaXMgdXNlZCAoaW4gd2hpY2ggY2FzZSBpdCBuZWVk cyBzY29wZSkgb3Igd2hldGhlciBhbm90aGVyIHByb2ZpbGUgZm9yIGFjY2VzcyB0b2tlbnMgaXMg bmVlZGVkLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5TaW5jZSBzY29wZSBpcyBmdW5kYW1lbnRhbCB0byBvYXV0aCwgaSB0aGluayBp dCBpcyBwYXJ0IGlmIHRoZSBjb3JlIHNldCBvZiBtaW5pbWFsIGF0dHJpYnV0ZXMgZm9yIGFjY2Vz cyB0b2tlbnMuICZuYnNwO0luIGZhY3QgaSBjYWIgZW52aXNpb24gY2FzZXMgd2hlcmUgcmVmZXJl bmNlcyB0byBhdXRob3JpemluZyB1c2VyIG9yIGNsaWVudCBtaWdodCBiZSBlbGltaW5hdGVkIG9y IGFub255bWl6ZWQgbGVhdmluZyBvbmx5DQogb25lLiBFZyBncmFudCB0aGUgaG9sZGVyIG9mIHRo aXMgdG9rZW4gdGhlIHJpZ2h0IHRvIGRvIHNjb3BlIHh5ei4mbmJzcDs8YnI+DQo8YnI+DQpQaGls PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TZW50IGZyb20g bXkgcGhvbmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KT24gMjAxMy0w My0xNSwgYXQgMjE6MDMsIE1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpv bmVzQG1pY3Jvc29mdC5jb20iPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdy b3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkhhdmluZyBhIHNjb3BlIGNsYWltIGluIHNwZWNp ZmljIHByb2ZpbGVzIGNvdWxkIG1ha2Ugc2Vuc2UuJm5ic3A7IFRoYXQgZG9lc27igJl0IG1lYW4g dGhhdCBpdCBoYXMgdG8gYmUgZGVmaW5lZCBpbiB0aGUgSldUIHNwZWMgcGVyIHNlLiZuYnNwOyBJ ZiBhbnl0aGluZywgcGVvcGxlIGV4cHJlc3NlZCBhIGRlc2lyZSBpbiB5ZXN0ZXJkYXnigJlzIHdv cmtpbmcNCiBncm91cCBtZWV0aW5nIHRvIGtlZXAgdGhlIGJhc2UgY2xhaW1zIHNldCBzbWFsbCwg cmF0aGVyIHRoYW4gZXhwYW5kaW5nIGl0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPlByb2ZpbGVzIGNhbiByZWdpc3RlciB0aGUgY2xhaW1zIHRoZXkgZGVmaW5lIGluIHRoZSBJ QU5BIEpXVCBDbGFpbXMgcmVnaXN0cnksIGlmIHRoZXkgY2hvb3NlLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPi0tIE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206 PC9zcGFuPjwvc3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwO0xld2lzIEFkYW0tQ0FMMDIyPGJyPg0K PHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5TZW50Ojwvc3Bhbj48L3N0cm9uZz4mbmJzcDs8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPuKAjjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5NYXJjaDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+4oCOPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij7igI48L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ MTU8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPuKAjjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4sDQo8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPuKAjjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4yMDEzDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPuKAjjwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4zPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij7igI48L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Ojwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+4oCOPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjU1PC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij7i gI48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPuKAjjwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5QTTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQo8c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRvOjwv c3Bhbj48L3N0cm9uZz4mbmJzcDtCcmlhbiBDYW1wYmVsbDxicj4NCjxzdHJvbmc+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+Q0M6PC9zcGFuPjwvc3Ryb25nPiZuYnNwOzxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9y ZyI+b2F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5TdWJqZWN0Ojwv c3Bhbj48L3N0cm9uZz4mbmJzcDtSZTogW09BVVRILVdHXSBKV1QgZ3JhbnRfdHlwZSBhbmQgY2xp ZW50X2lkPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+SSBndWVzcyB0aGF0IGl0IGRlcGVuZHMgb24gd2hhdCBKV1QgaXMg bWVhbnQgdG8gYmUuJm5ic3A7IE15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCBpdCBiZWdhbiBhcyBz b21ldGhpbmcNCiB0byBzdXBwb3J0IFdlYiBTU08gYXV0aGVudGljYXRpb24gZm9yIE9JREMsIHNv IHNjb3BlIGRpZG7igJl0IG1ha2UgYW55IHNlbnNlIHRoZW4uJm5ic3A7IE5vciBkb2VzIGl0IG1h a2UgYW55IHNlbnNlIGFzIGEgc3RyaWN0IGdyYW50IHR5cGUuJm5ic3A7IFRoZSB1c2UgY2FzZSB3 aGVyZSBpdCBiZWNvbWVzIGludGVyZXN0aW5nICh0aGUgb25lIEkgYW0gbG9va2luZyB0bykgaXMg Zm9yIHdoZW4gYW4gYWNjZXNzIHRva2VuIG9yIHJlZnJlc2ggdG9rZW4gaXMgYSBKV1QuJm5ic3A7 DQogSSB0aGluayBzb21lIHZlbmRvcnMgYXJlIGJlZ2lubmluZyB0byBtYWtlIHRoZWlyIHN0cnVj dHVyZWQgdG9rZW5zIGEgSldULCBhbmQgdGhhdCBpcyBteSBjdXJyZW50IHRoaW5raW5nIGFzIHdl bGwg4oCmIGlmIGZvbGtzIGFncmVlIHRoYXQgSldUIGNhbiBiZSB1c2VkIGFzIHRoZSBzdHJ1Y3R1 cmUgZm9yIE9BdXRoIHRva2VucywgdGhlbiBpdCBtYWtlcyBzZW5zZSB0byBpbmNsdWRlIGEgc2Nv cGUgZmllbGQuJm5ic3A7IElmIG5vdCwgdGhlbiBpdCB3aWxsIGJlDQogSlNPTiYjNDM7ZW5jcnlw dGlvbiYjNDM7c2lnbmluZywganVzdCBub3QgYSBKV1QgPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMUY0OTdEIj5KPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5hZGFtPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGlu IDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBCcmlhbiBD YW1wYmVsbCBbPGEgaHJlZj0ibWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tIj5tYWls dG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IEZy aWRheSwgTWFyY2ggMTUsIDIwMTMgNToxNiBQTTxicj4NCjxiPlRvOjwvYj4gTGV3aXMgQWRhbS1D QUwwMjI8YnI+DQo8Yj5DYzo8L2I+IFNlcmdleSBCZXJ5b3praW47IDxhIGhyZWY9Im1haWx0bzpv YXV0aEBpZXRmLm9yZyI+b2F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl OiBbT0FVVEgtV0ddIEpXVCBncmFudF90eXBlIGFuZCBjbGllbnRfaWQ8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkNvZGlmeWluZyBhIGNsYWltL2F0dHJpYnV0ZSBm b3Igc2NvcGUgdGhhdCBnb2VzIGluIHRoZSBhc3NlcnRpb24gaXMgc29tZXRoaW5nIHRoYXQncyBi ZWVuIGRpc2N1c3NlZCBidXQgbmV2ZXIgc2VlbWVkIHRvIGdldCBzdWZmaWNpZW50DQogY29uc2Vu c3VzIHJlZ2FyZGluZyBob3cgdG8gZXhhY3RseSB0byBkbyBpdCBhbmQgaWYgaXQgcmVhbGx5IHBy b3ZpZGVkIG11Y2ggdmFsdWUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdp bi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5PbiBGcmksIE1hciAx NSwgMjAxMyBhdCA0OjEyIFBNLCBCcmlhbiBDYW1wYmVsbCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJj YW1wYmVsbEBwaW5naWRlbnRpdHkuY29tIj5iY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPlNvIGN1cnJlbnRseSB0aGUgYmFzZSBhc3NlcnRpb24gZG9jdW1l bnQgZGVmaW5lcyBzY29wZSBhcyBhbiBIVFRQIHBhcmFtZXRlciBvbiB0aGUgYWNjZXNzIHRva2Vu IHJlcXVlc3QgbWVzc2FnZSB3aGVuIHVzaW5nIGFuIGFzc2VydGlvbg0KIGFzIGEgZ3JhbnRbMV0u Jm5ic3A7IEFuZCB0aGF0IGFwcGxpZXMgdG8gYm90aCB0aGUgU0FNTCBhbmQgSldUIGdyYW50cyAo cGVyaGFwcyB0aGF0IG5lZWRzIHRvIGJlIG1vcmUgY2xlYXI/KS4gQWxzbyBSRkMgNjc0OSBkZWZp bmVzIHRoZSBzY29wZSBwYXJhbWV0ZXIgZm9yIHRoZSBjbGllbnQgY3JlZGVudGlhbHMgYWNjZXNz IHRva2VuIHJlcXVlc3RbMl0sIHdoaWNoIHNpbWlsYXJseSBhcHBsaWVzIHRvIGJvdGggU0FNTCBh bmQgSldUIGluIHRoZSBjYXNlDQogb2YgYXNzZXJ0aW9uIGNsaWVudCBhdXRoZW50aWNhdGlvbiB1 c2luZyB0aGUgJnF1b3Q7Y2xpZW50X2NyZWRlbnRpYWxzJnF1b3Q7IGdyYW50IHR5cGUuPGJyPg0K PGJyPg0KWzFdIDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt b2F1dGgtYXNzZXJ0aW9ucy0xMCNzZWN0aW9uLTQuMSI+DQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLW9hdXRoLWFzc2VydGlvbnMtMTAjc2VjdGlvbi00LjE8L2E+IDxicj4N ClsyXSA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2NzQ5I3NlY3Rpb24t NC40LjEiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY3NDkjc2VjdGlvbi00LjQuMTwv YT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4t Ym90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+T24gRnJpLCBNYXIgMTUs IDIwMTMgYXQgMzo0MyBQTSwgTGV3aXMgQWRhbS1DQUwwMjIgJmx0OzxhIGhyZWY9Im1haWx0bzpB ZGFtLkxld2lzQG1vdG9yb2xhc29sdXRpb25zLmNvbSI+QWRhbS5MZXdpc0Btb3Rvcm9sYXNvbHV0 aW9ucy5jb208L2E+Jmd0Ow0KIHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+UmlnaHQgLi4uIHRoaW5raW5nIGFib3V0IHRoaXMg ZnVydGhlciBJIHRoaW5rIHRoZSBhbnN3ZXIgaXMgJnF1b3Q7YWxsIG9mIHRoZSBhYm92ZS4mcXVv dDsgJm5ic3A7SWYgdGhlIEpXVCBpcyBhIGdyYW50IHR5cGUgdGhlbiBhcyB5b3Ugc2F5IGl0IG5l ZWRzDQogYSBzY29wZSBwYXJhbSBhbmQgb3B0aW9uYWxseSBhIGNsaWVudF9pZCBwYXJhbS4gJm5i c3A7SSBhcmd1ZWQgZm9yIHRoZSBjbGllbnRfaWQgcGFyYW0gZWFybGllciBzaW5jZSBpdCBjb3Vs ZCBhc3Npc3Qgd2l0aCBIT0sgc2NlbmFyaW9zIG9uY2UgdGhvc2UgZnVydGhlciBkZXZlbG9wLjxi cj4NCjxicj4NCkJ1dCB3aGVuIHRoZSBKV1QgaXMgdXNlZCBhcyBhbiBBVCB0aGVuIGl0IHdpbGwg ZGVmaW5pdGVseSByZXF1aXJlIHRoZSBzY29wZSBhcyBhIGNsYWltLjxicj4NCjxicj4NClNvIEkg Y2hhbmdlIG15IGFyZ3VtZW50IHRvICZxdW90O2JvdGgmcXVvdDsgOik8YnI+DQo8YnI+DQphZGFt PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPjxicj4NCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJv bTogPGEgaHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciPm9hdXRoLWJvdW5jZXNA aWV0Zi5vcmc8L2E+IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5v cmciPm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgU2VyZ2V5IEJlcnlv emtpbjxicj4NClNlbnQ6IEZyaWRheSwgTWFyY2ggMTUsIDIwMTMgNDozMSBQTTxicj4NClRvOiA8 YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYub3JnPC9hPjxicj4NClN1 YmplY3Q6IFJlOiBbT0FVVEgtV0ddIEpXVCBncmFudF90eXBlIGFuZCBjbGllbnRfaWQ8YnI+DQo8 YnI+DQpIaTxicj4NCk9uIDE1LzAzLzEzIDIwOjQwLCBMZXdpcyBBZGFtLUNBTDAyMiB3cm90ZTo8 YnI+DQomZ3Q7IEhpIEpvaG4sPGJyPg0KJmd0Ozxicj4NCiZndDsgSSB3b3VsZCBsaWtlIHRvIGFy Z3VlIHRoYXQgdGhlIHNjb3BlIHNob3VsZCBiZSBhIHBhcmFtZXRlciBpbiB0aGUgYWNjZXNzPGJy Pg0KJmd0OyB0b2tlbiByZXF1ZXN0IG1lc3NhZ2UsIHRoZSBzYW1lIGFzIGl0IGlzIGZvciB0aGUg Uk8gY3JlZHMgZ3JhbnQgYW5kPGJyPg0KJmd0OyBjbGllbnQgY3JlZHMgZ3JhbnQgdHlwZS4gVGhp cyB3b3VsZCBrZWVwIGl0IGNvbnNpc3RlbnQgd2l0aCB0aGUgY29yZTxicj4NCiZndDsgT0F1dGgg Z3JhbnQgdHlwZXMgdGhhdCB0YWxrIGRpcmVjdGx5IHRvIHRoZSB0b2tlbiBlbmRwb2ludC48YnI+ DQomZ3Q7PGJyPg0KQXNzdW1pbmcgdGhlIGFzc2VydGlvbiBpcyBhY3RpbmcgYXMgYSBncmFudCwg dGhlbiBpdCBpcyBpbmRlZWQgYW4gYWNjZXNzPGJyPg0KdG9rZW4gcmVxdWVzdCBtZXNzYWdlLCBz byBJTUhPIGl0IG1ha2VzIHNlbnNlIHRvIGdldCBhbiBvdXRib3VuZCBzY29wZTxicj4NCnBhcmFt ZXRlciBvcHRpb25hbGx5IHN1cHBvcnRlZCB3aGljaCBJIGd1ZXNzIHdpbGwgaW1wbHkgdGhhdCB0 aGUgY2xpZW50PGJyPg0KaWQgd2lsbCBhbHNvIGhhdmUgdG8gYWNjb21wYW55IGl0Li4uPGJyPg0K PGJyPg0KQ2hlZXJzLCBTZXJnZXk8YnI+DQo8YnI+DQomZ3Q7IFRob3VnaHRzPzxicj4NCiZndDs8 YnI+DQomZ3Q7IGFkYW08YnI+DQomZ3Q7PGJyPg0KJmd0OyAqRnJvbToqSm9obiBCcmFkbGV5IFtt YWlsdG86PGEgaHJlZj0ibWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tIj52ZTdqdGJAdmU3anRiLmNv bTwvYT5dPGJyPg0KJmd0OyAqU2VudDoqIEZyaWRheSwgTWFyY2ggMTUsIDIwMTMgMTI6MTAgUE08 YnI+DQomZ3Q7ICpUbzoqIExld2lzIEFkYW0tQ0FMMDIyPGJyPg0KJmd0OyAqQ2M6KiBCcmlhbiBD YW1wYmVsbDsgJnF1b3Q7V0cgJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+b2F1 dGhAaWV0Zi5vcmc8L2E+Jmd0OyZxdW90O0A8YSBocmVmPSJodHRwOi8vaWwwNmV4cjAyLm1vdC5j b20iPmlsMDZleHIwMi5tb3QuY29tPC9hPjxicj4NCiZndDsgKlN1YmplY3Q6KiBSZTogW09BVVRI LVdHXSBKV1QgZ3JhbnRfdHlwZSBhbmQgY2xpZW50X2lkPGJyPg0KJmd0Ozxicj4NCiZndDsgVGhl IHNwZWMgaXMgYSB0b3VjaCB2YWd1ZSBvbiB0aGF0LiBJIHRoaW5rIHRoZSBzY29wZXMgc2hvdWxk IGJlIGluIHRoZTxicj4NCiZndDsgYXNzZXJ0aW9uIGFuZCB0aGUgY2xpZW50IGNhbiB1c2UgdGhl IHNjb3BlcyBvdXRzaWRlIHRoZSBhc3NlcnRpb24gdG88YnI+DQomZ3Q7IGRvd24tc2NvcGUuPGJy Pg0KJmd0Ozxicj4NCiZndDsgSGF2aW5nIGEgc3RhbmRhcmQgY2xhaW0gaW4gSldUIGFuZCBTQU1M IGZvciBwYXNzaW5nIHNjb3BlcyBpcyBwcm9iYWJseTxicj4NCiZndDsgdXNlZnVsIGFzIHBhcnQg b2YgYSBwcm9maWxlLjxicj4NCiZndDs8YnI+DQomZ3Q7IEpvaG4gQi48YnI+DQomZ3Q7PGJyPg0K Jmd0OyBPbiAyMDEzLTAzLTE0LCBhdCA4OjQ3IFBNLCBMZXdpcyBBZGFtLUNBTDAyMjxicj4NCiZn dDsgJmx0OzxhIGhyZWY9Im1haWx0bzpBZGFtLkxld2lzQG1vdG9yb2xhc29sdXRpb25zLmNvbSI+ QWRhbS5MZXdpc0Btb3Rvcm9sYXNvbHV0aW9ucy5jb208L2E+PGJyPg0KJmd0OyAmbHQ7bWFpbHRv OjxhIGhyZWY9Im1haWx0bzpBZGFtLkxld2lzQG1vdG9yb2xhc29sdXRpb25zLmNvbSI+QWRhbS5M ZXdpc0Btb3Rvcm9sYXNvbHV0aW9ucy5jb208L2E+Jmd0OyZndDsgd3JvdGU6PGJyPg0KJmd0Ozxi cj4NCiZndDs8YnI+DQomZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jmd0OyBIbW1tLCBvbmUgbW9yZSB0 aG91Z2h0IC4uLiBubyBzY29wZT8/IFRoZSBKV1QgaXMgdGhlIGdyYW50LCBpcyBpdCBhc3N1bWVk PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+Jmd0OyB0aGF0IHRoZSBzY29wZSBpcyBjb252ZXllZCBhcyBhIGNsYWltIHdpdGhp biB0aGUgdG9rZW4/IE90aGVyd2lzZSBpdDxicj4NCiZndDsgd291bGQgc2VlbSB0aGF0IGl0IHdv dWxkIHJlcXVpcmUgYSBzY29wZS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaG91Z2h0cz88YnI+DQom Z3Q7PGJyPg0KJmd0OyBhZGFtPGJyPg0KJmd0Ozxicj4NCiZndDsgKkZyb206KkJyaWFuIENhbXBi ZWxsIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tIj5i Y2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTwvYT48YnI+DQomZ3Q7ICZsdDs8YSBocmVmPSJodHRw Oi8vcGluZ2lkZW50aXR5LmNvbSI+aHR0cDovL3BpbmdpZGVudGl0eS5jb208L2E+Jmd0O108YnI+ DQomZ3Q7ICpTZW50OipUaHVyc2RheSwgTWFyY2ggMTQsIDIwMTMgNDo0NCBQTTxicj4NCiZndDsg KlRvOipMZXdpcyBBZGFtLUNBTDAyMjxicj4NCiZndDsgKkNjOipNaWtlIEpvbmVzOyAmcXVvdDtX RyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj5vYXV0aEBpZXRmLm9yZzwvYT48 YnI+DQomZ3Q7ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj5vYXV0 aEBpZXRmLm9yZzwvYT4mZ3Q7Jmd0OyZxdW90O0A8YSBocmVmPSJodHRwOi8vaWwwNmV4cjAyLm1v dC5jb20iPmlsMDZleHIwMi5tb3QuY29tPC9hPiAmbHQ7PGEgaHJlZj0iaHR0cDovL2lsMDZleHIw Mi5tb3QuY29tIj5odHRwOi8vaWwwNmV4cjAyLm1vdC5jb208L2E+Jmd0Ozxicj4NCiZndDsgKlN1 YmplY3Q6KlJlOiBbT0FVVEgtV0ddIEpXVCBncmFudF90eXBlIGFuZCBjbGllbnRfaWQ8YnI+DQom Z3Q7PGJyPg0KJmd0OyBZZXMsIHRoYXQgaXMgY29ycmVjdC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBJ J20gd29ya2luZyBvbiBuZXcgcmV2aXNpb25zIG9mIHRoZSBkcmFmdHMgdGhhdCB3aWxsIGhvcGVm dWxseSBtYWtlIHRoYXQ8YnI+DQomZ3Q7IHBvaW50IG1vcmUgY2xlYXIuPGJyPg0KJmd0Ozxicj4N CiZndDsgT24gVGh1LCBNYXIgMTQsIDIwMTMgYXQgNToyNiBQTSwgTGV3aXMgQWRhbS1DQUwwMjI8 YnI+DQomZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86QWRhbS5MZXdpc0Btb3Rvcm9sYXNvbHV0aW9u cy5jb20iPkFkYW0uTGV3aXNAbW90b3JvbGFzb2x1dGlvbnMuY29tPC9hPjxicj4NCiZndDsgJmx0 O21haWx0bzo8YSBocmVmPSJtYWlsdG86QWRhbS5MZXdpc0Btb3Rvcm9sYXNvbHV0aW9ucy5jb20i PkFkYW0uTGV3aXNAbW90b3JvbGFzb2x1dGlvbnMuY29tPC9hPiZndDsmZ3Q7IHdyb3RlOjxicj4N CiZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+Jmd0OyBDb21pbmcgYmFjayB0byB0aGlzLi4uICZuYnNwO2FtIEkgY29y cmVjdCBpbiB0aGF0IGNsaWVudF9pZCBpcyBub3QgcmVxdWlyZWQ/ICZuYnNwOyAmbmJzcDtXZSBh cmUgaW1wbGVtZW50aW5nIHRoaXMgc3BlYyBhbmQgd2FudCB0byBtYWtlIHN1cmUNCiB0aGF0IHdl IGFyZSBkb2luZyBpdCByaWdodC4gJm5ic3A7ICZuYnNwO0J5IG15IHVuZGVyc3RhbmRpbmcgdGhl IG9ubHkgdHdvIHBhcmFtZXRlcnMgdGhhdCBhcmUgcmVxdWlyZWQgaW4gdGhlIEpXVCBncmFudCB0 eXBlIGFyZSAmbmJzcDsmcXVvdDt1cm46aWV0ZjpwYXJhbXM6b2F1dGg6Z3JhbnQtdHlwZTpqd3Qt YmVhcmVyJnF1b3Q7ICZuYnNwOyAmbmJzcDthbmQgdGhlIGFzc2VydGlvbi4gJm5ic3A7ICZuYnNw OyAmbmJzcDtJcyB0aGlzIGNvcnJlY3Q/PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jmd0Ozxicj4NCiZndDsgKkZyb206Kk1p a2UgSm9uZXMgW21haWx0bzo8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQu Y29tIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+PGJyPg0KJmd0OyAmbHQ7bWFpbHRv OjxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iPk1pY2hhZWwuSm9u ZXNAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7XTxicj4NCiZndDsgKlNlbnQ6Kk1vbmRheSwgRmVicnVh cnkgMTgsIDIwMTMgNjo1OCBQTTxicj4NCiZndDsgKlRvOipMZXdpcyA8YSBocmVmPSJtYWlsdG86 QWRhbS1DQUwwMjIlM0JvYXV0aEBpZXRmLm9yZyI+QWRhbS1DQUwwMjI7b2F1dGhAaWV0Zi5vcmc8 L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj5vYXV0aEBpZXRm Lm9yZzwvYT4mZ3Q7V0c8YnI+DQomZ3Q7ICpTdWJqZWN0OipSRTogSldUIGdyYW50X3R5cGUgYW5k IGNsaWVudF9pZDxicj4NCiZndDs8YnI+DQomZ3Q7IFRoZSBjbGllbnRfaWQgdmFsdWUgYW5kIHRo ZSBhY2Nlc3MgdG9rZW4gdmFsdWUgYXJlIGluZGVwZW5kZW50Ljxicj4NCiZndDs8YnI+DQomZ3Q7 IC0tIE1pa2U8YnI+DQomZ3Q7PGJyPg0KJmd0OyAqRnJvbToqPGEgaHJlZj0ibWFpbHRvOm9hdXRo LWJvdW5jZXNAaWV0Zi5vcmciPm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyAm bHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnIj5vYXV0aC1i b3VuY2VzQGlldGYub3JnPC9hPiZndDtbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3Vu Y2VzQGlldGYub3JnIj5vYXV0aC1ib3VuY2VzQGlldGYub3JnPC9hPjxicj4NCiZndDsgJmx0O21h aWx0bzo8YSBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyI+b2F1dGgtYm91bmNl c0BpZXRmLm9yZzwvYT4mZ3Q7XSpPbiBCZWhhbGYgT2YqTGV3aXMgQWRhbS1DQUwwMjI8YnI+DQom Z3Q7ICpTZW50OipNb25kYXksIEZlYnJ1YXJ5IDE4LCAyMDEzIDI6NTAgUE08YnI+DQomZ3Q7ICpU bzoqPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj5vYXV0aEBpZXRmLm9yZzwvYT4gJmx0 O21haWx0bzo8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYub3JnPC9h PiZndDtXRzxicj4NCiZndDsgKlN1YmplY3Q6KltPQVVUSC1XR10gSldUIGdyYW50X3R5cGUgYW5k IGNsaWVudF9pZDxicj4NCiZndDs8YnI+DQomZ3Q7IElzIHRoZXJlIGFueSBndWlkYW5jZSBvbiB0 aGUgdXNhZ2Ugb2YgY2xpZW50X2lkIHdoZW4gdXNpbmcgdGhlIEpXVDxicj4NCiZndDsgYXNzZXJ0 aW9uIHByb2ZpbGUgYXMgYSBncmFudCB0eXBlPyBkcmFmdC1pZXRmLW9hdXRoLWp3dC1iZWFyZXIt MDQgbWFrZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+Jmd0OyBubyBtZW50aW9uIHNvIEkgYXNzdW1lIHRoYXQgaXQgaXMg bm90IHJlcXVpcmVkIC4uLiBidXQgaXQgd291bGQgYmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jmd0OyBuZWNl c3NhcnkgaWYgdXNpbmcgaW4gY29uanVuY3Rpb24gd2l0aCBhIEhPSyBwcm9maWxlIHdoZXJlIHRo ZSBKV1Q8YnI+DQomZ3Q7IGFzc2VydGlvbiBpcyBpc3N1ZWQgdG8gLSBhbmQgbWF5IG9ubHkgYmUg dXNlZCBieSAtIHRoZSBpbnRlbmRlZCBjbGllbnQuPGJyPg0KJmd0OyBPYnZpb3VzbHkgdGhpcyBp cyBzdHJhaWdodCBmb3J3YXJkIGVub3VnaCwgcmVhbGx5IEknbSBqdXN0IGxvb2tpbmcgdG8gYmU8 YnI+DQomZ3Q7IHN1cmUgdGhhdCBJJ20gbm90IG1pc3NpbmcgYW55dGhpbmcuPGJyPg0KJmd0Ozxi cj4NCiZndDsgdHg8YnI+DQomZ3Q7PGJyPg0KJmd0OyBhZGFtPGJyPg0KJmd0Ozxicj4NCiZndDs8 YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyPg0KJmd0OyBPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzpP QXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFp bHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KJmd0OyA8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxicj4NCiZndDs8YnI+DQom Z3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K Jmd0OyBPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzpPQXV0aEBp ZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOk9B dXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KJmd0OyA8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxicj4NCiZndDs8YnI+DQomZ3Q7PGJy Pg0KJmd0Ozxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+DQomZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxicj4NCiZndDsgPGEgaHJlZj0i bWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IDxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PGJyPg0KPGJyPg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWls aW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYu b3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vb2F1dGgiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+ PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8 YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlz dDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+ PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0 aCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_59E470B10C4630419ED717AC79FCF9A9568A991EBY2PRD0411MB441_-- From jricher@mitre.org Mon Mar 18 09:19: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 44F3121F8D76 for ; Mon, 18 Mar 2013 09:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.648 X-Spam-Level: X-Spam-Status: No, score=-3.648 tagged_above=-999 required=5 tests=[AWL=2.350, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_25=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 N9pOgEQ1h4gT for ; Mon, 18 Mar 2013 09:19:21 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 65D7821F8CCB for ; Mon, 18 Mar 2013 09:19:21 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 871A01F0300; Mon, 18 Mar 2013 12:19:10 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 7288D1F02C8; Mon, 18 Mar 2013 12:19:10 -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, 18 Mar 2013 12:19:10 -0400 Message-ID: <51473E2B.3090109@mitre.org> Date: Mon, 18 Mar 2013 12:17:47 -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: Lewis Adam-CAL022 References: <4E1F6AAD24975D4BA5B16804296739436752C010@TK5EX14MBXC284.redmond.corp.microsoft.com> <577837CC-A415-4F7E-82A2-CDB21859650C@oracle.com> <4E1F6AAD24975D4BA5B168042967394367533A20@TK5EX14MBXC284.redmond.corp.microsoft.com> <59E470B10C4630419ED717AC79FCF9A9568A991E@BY2PRD0411MB441.namprd04.prod.outlook.com> In-Reply-To: <59E470B10C4630419ED717AC79FCF9A9568A991E@BY2PRD0411MB441.namprd04.prod.outlook.com> Content-Type: multipart/alternative; boundary="------------020501090007000906070905" X-Originating-IP: [129.83.31.58] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] JWT grant_type and client_id X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 16:19:34 -0000 --------------020501090007000906070905 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit +1, and I think that Nat's draft is a good first stab at this: http://tools.ietf.org/id/draft-sakimura-oidc-structured-token-01.txt -- Justin On 03/16/2013 01:37 PM, Lewis Adam-CAL022 wrote: > > +1 > > I've been trying to argue this for a bit now ... that while OAuth may > not deprecate the usage of unstructured access tokens (or prohibiting > others from defining their own) that having a WG guidance on what a > structured JWT (or SAML) access token would like ... I think > developers moving forward might be inclined to use it. > > adam > > *From:*Mike Jones [mailto:Michael.Jones@microsoft.com] > *Sent:* Saturday, March 16, 2013 12:17 PM > *To:* Phil Hunt > *Cc:* Brian Campbell; Lewis Adam-CAL022; oauth@ietf.org > *Subject:* RE: [OAUTH-WG] JWT grant_type and client_id > > I agree that it's likely a claim that would be used in access tokens. > > I'm coming to the conclusion that we should actually write an access > token profile for JWT and probably SAML as well. This would be > parallel to the kinds of requirements placed on the use of SAML and > JWT when used for client authentication and as resource grants. This > could only help interoperability, as people would have a place to go > to read about best practices for this use case. > > -- Mike > > *From:*Phil Hunt [mailto:phil.hunt@oracle.com] > *Sent:* Saturday, March 16, 2013 2:52 AM > *To:* Mike Jones > *Cc:* Brian Campbell; Lewis Adam-CAL022; oauth@ietf.org > > *Subject:* Re: [OAUTH-WG] JWT grant_type and client_id > > It's a question of whether the jwt spec alone is used (in which case > it needs scope) or whether another profile for access tokens is needed. > > Since scope is fundamental to oauth, i think it is part if the core > set of minimal attributes for access tokens. In fact i cab envision > cases where references to authorizing user or client might be > eliminated or anonymized leaving only one. Eg grant the holder of this > token the right to do scope xyz. > > Phil > > Sent from my phone. > > > On 2013-03-15, at 21:03, Mike Jones > wrote: > > Having a scope claim in specific profiles could make sense. That > doesn't mean that it has to be defined in the JWT spec per se. If > anything, people expressed a desire in yesterday's working group > meeting to keep the base claims set small, rather than expanding it. > > Profiles can register the claims they define in the IANA JWT > Claims registry, if they choose. > > -- Mike > > *From:* Lewis Adam-CAL022 > *Sent:* ?March??15?, ?2013 ?3?:?55??PM > *To:* Brian Campbell > *CC:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] JWT grant_type and client_id > > I guess that it depends on what JWT is meant to be. My > understanding is that it began as something to support Web SSO > authentication for OIDC, so scope didn't make any sense then. Nor > does it make any sense as a strict grant type. The use case where > it becomes interesting (the one I am looking to) is for when an > access token or refresh token is a JWT. I think some vendors are > beginning to make their structured tokens a JWT, and that is my > current thinking as well ... if folks agree that JWT can be used > as the structure for OAuth tokens, then it makes sense to include > a scope field. If not, then it will be JSON+encryption+signing, > just not a JWT J > > adam > > *From:*Brian Campbell [mailto:bcampbell@pingidentity.com] > *Sent:* Friday, March 15, 2013 5:16 PM > *To:* Lewis Adam-CAL022 > *Cc:* Sergey Beryozkin; oauth@ietf.org > *Subject:* Re: [OAUTH-WG] JWT grant_type and client_id > > Codifying a claim/attribute for scope that goes in the assertion > is something that's been discussed but never seemed to get > sufficient consensus regarding how to exactly to do it and if it > really provided much value. > > On Fri, Mar 15, 2013 at 4:12 PM, Brian Campbell > > > wrote: > > So currently the base assertion document defines scope as an HTTP > parameter on the access token request message when using an > assertion as a grant[1]. And that applies to both the SAML and > JWT grants (perhaps that needs to be more clear?). Also RFC 6749 > defines the scope parameter for the client credentials access > token request[2], which similarly applies to both SAML and JWT in > the case of assertion client authentication using the > "client_credentials" grant type. > > [1] > http://tools.ietf.org/html/draft-ietf-oauth-assertions-10#section-4.1 > [2] http://tools.ietf.org/html/rfc6749#section-4.4.1 > > On Fri, Mar 15, 2013 at 3:43 PM, Lewis Adam-CAL022 > > wrote: > > Right ... thinking about this further I think the answer is "all > of the above." If the JWT is a grant type then as you say it > needs a scope param and optionally a client_id param. I argued > for the client_id param earlier since it could assist with HOK > scenarios once those further develop. > > But when the JWT is used as an AT then it will definitely require > the scope as a claim. > > So I change my argument to "both" :) > > adam > > > -----Original Message----- > From: oauth-bounces@ietf.org > [mailto:oauth-bounces@ietf.org ] On > Behalf Of Sergey Beryozkin > Sent: Friday, March 15, 2013 4:31 PM > To: oauth@ietf.org > Subject: Re: [OAUTH-WG] JWT grant_type and client_id > > Hi > On 15/03/13 20:40, Lewis Adam-CAL022 wrote: > > Hi John, > > > > I would like to argue that the scope should be a parameter in > the access > > token request message, the same as it is for the RO creds grant and > > client creds grant type. This would keep it consistent with the core > > OAuth grant types that talk directly to the token endpoint. > > > Assuming the assertion is acting as a grant, then it is indeed an > access > token request message, so IMHO it makes sense to get an outbound scope > parameter optionally supported which I guess will imply that the > client > id will also have to accompany it... > > Cheers, Sergey > > > Thoughts? > > > > adam > > > > *From:*John Bradley [mailto:ve7jtb@ve7jtb.com > ] > > *Sent:* Friday, March 15, 2013 12:10 PM > > *To:* Lewis Adam-CAL022 > > *Cc:* Brian Campbell; "WG >"@il06exr02.mot.com > > *Subject:* Re: [OAUTH-WG] JWT grant_type and client_id > > > > The spec is a touch vague on that. I think the scopes should be > in the > > assertion and the client can use the scopes outside the assertion to > > down-scope. > > > > Having a standard claim in JWT and SAML for passing scopes is > probably > > useful as part of a profile. > > > > John B. > > > > On 2013-03-14, at 8:47 PM, Lewis Adam-CAL022 > > > > >> wrote: > > > > > > > > > Hmmm, one more thought ... no scope?? The JWT is the grant, is it > assumed > > > that the scope is conveyed as a claim within the token? Otherwise it > > would seem that it would require a scope. > > > > Thoughts? > > > > adam > > > > *From:*Brian Campbell [mailto:bcampbell@pingidentity.com > > > ] > > *Sent:*Thursday, March 14, 2013 4:44 PM > > *To:*Lewis Adam-CAL022 > > *Cc:*Mike Jones; "WG > > >>"@il06exr02.mot.com > > > *Subject:*Re: [OAUTH-WG] JWT grant_type and client_id > > > > Yes, that is correct. > > > > I'm working on new revisions of the drafts that will hopefully > make that > > point more clear. > > > > On Thu, Mar 14, 2013 at 5:26 PM, Lewis Adam-CAL022 > > > > >> wrote: > > > > > Coming back to this... am I correct in that client_id is not > required? We are implementing this spec and want to make sure > that we are doing it right. By my understanding the only two > parameters that are required in the JWT grant type are > "urn:ietf:params:oauth:grant-type:jwt-bearer" and the > assertion. Is this correct? > > > > > *From:*Mike Jones [mailto:Michael.Jones@microsoft.com > > > >] > > *Sent:*Monday, February 18, 2013 6:58 PM > > *To:*Lewis Adam-CAL022;oauth@ietf.org > >WG > > *Subject:*RE: JWT grant_type and client_id > > > > The client_id value and the access token value are independent. > > > > -- Mike > > > > *From:*oauth-bounces@ietf.org > > >[mailto:oauth-bounces@ietf.org > > > >]*On Behalf Of*Lewis Adam-CAL022 > > *Sent:*Monday, February 18, 2013 2:50 PM > > *To:*oauth@ietf.org > >WG > > *Subject:*[OAUTH-WG] JWT grant_type and client_id > > > > Is there any guidance on the usage of client_id when using the JWT > > assertion profile as a grant type? > draft-ietf-oauth-jwt-bearer-04 makes > > > no mention so I assume that it is not required ... but it would be > > > necessary if using in conjunction with a HOK profile where the JWT > > assertion is issued to - and may only be used by - the intended > client. > > Obviously this is straight forward enough, really I'm just > looking to be > > sure that I'm not missing anything. > > > > tx > > > > adam > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------020501090007000906070905 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit +1, and I think that Nat's draft is a good first stab at this:

http://tools.ietf.org/id/draft-sakimura-oidc-structured-token-01.txt

 -- Justin


On 03/16/2013 01:37 PM, Lewis Adam-CAL022 wrote:

+1

 

I’ve been trying to argue this for a  bit now … that while OAuth may not deprecate the usage of unstructured access tokens (or prohibiting others from defining their own) that having a WG guidance on what a structured JWT (or SAML) access token would like … I think developers moving forward might be inclined to use it.

 

adam 

 

From: Mike Jones [mailto:Michael.Jones@microsoft.com]
Sent: Saturday, March 16, 2013 12:17 PM
To: Phil Hunt
Cc: Brian Campbell; Lewis Adam-CAL022; oauth@ietf.org
Subject: RE: [OAUTH-WG] JWT grant_type and client_id

 

I agree that it’s likely a claim that would be used in access tokens.

 

I’m coming to the conclusion that we should actually write an access token profile for JWT and probably SAML as well.  This would be parallel to the kinds of requirements placed on the use of SAML and JWT when used for client authentication and as resource grants.  This could only help interoperability, as people would have a place to go to read about best practices for this use case.

 

                                                            -- Mike

 

From: Phil Hunt [mailto:phil.hunt@oracle.com]
Sent: Saturday, March 16, 2013 2:52 AM
To: Mike Jones
Cc: Brian Campbell; Lewis Adam-CAL022; oauth@ietf.org
Subject: Re: [OAUTH-WG] JWT grant_type and client_id

 

It's a question of whether the jwt spec alone is used (in which case it needs scope) or whether another profile for access tokens is needed. 

 

Since scope is fundamental to oauth, i think it is part if the core set of minimal attributes for access tokens.  In fact i cab envision cases where references to authorizing user or client might be eliminated or anonymized leaving only one. Eg grant the holder of this token the right to do scope xyz. 

Phil

 

Sent from my phone.


On 2013-03-15, at 21:03, Mike Jones <Michael.Jones@microsoft.com> wrote:

Having a scope claim in specific profiles could make sense.  That doesn’t mean that it has to be defined in the JWT spec per se.  If anything, people expressed a desire in yesterday’s working group meeting to keep the base claims set small, rather than expanding it.

 

Profiles can register the claims they define in the IANA JWT Claims registry, if they choose.

 

-- Mike

 

 

From: Lewis Adam-CAL022
Sent: ‎March‎ ‎15‎, ‎2013 ‎3‎:‎55‎ ‎PM
To: Brian Campbell
CC: oauth@ietf.org
Subject: Re: [OAUTH-WG] JWT grant_type and client_id

 

I guess that it depends on what JWT is meant to be.  My understanding is that it began as something to support Web SSO authentication for OIDC, so scope didn’t make any sense then.  Nor does it make any sense as a strict grant type.  The use case where it becomes interesting (the one I am looking to) is for when an access token or refresh token is a JWT.  I think some vendors are beginning to make their structured tokens a JWT, and that is my current thinking as well … if folks agree that JWT can be used as the structure for OAuth tokens, then it makes sense to include a scope field.  If not, then it will be JSON+encryption+signing, just not a JWT J

 

adam

 

From: Brian Campbell [mailto:bcampbell@pingidentity.com]
Sent: Friday, March 15, 2013 5:16 PM
To: Lewis Adam-CAL022
Cc: Sergey Beryozkin; oauth@ietf.org
Subject: Re: [OAUTH-WG] JWT grant_type and client_id

 

Codifying a claim/attribute for scope that goes in the assertion is something that's been discussed but never seemed to get sufficient consensus regarding how to exactly to do it and if it really provided much value.

 

On Fri, Mar 15, 2013 at 4:12 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:

So currently the base assertion document defines scope as an HTTP parameter on the access token request message when using an assertion as a grant[1].  And that applies to both the SAML and JWT grants (perhaps that needs to be more clear?). Also RFC 6749 defines the scope parameter for the client credentials access token request[2], which similarly applies to both SAML and JWT in the case of assertion client authentication using the "client_credentials" grant type.

[1] http://tools.ietf.org/html/draft-ietf-oauth-assertions-10#section-4.1
[2] http://tools.ietf.org/html/rfc6749#section-4.4.1

 

On Fri, Mar 15, 2013 at 3:43 PM, Lewis Adam-CAL022 <Adam.Lewis@motorolasolutions.com> wrote:

Right ... thinking about this further I think the answer is "all of the above."  If the JWT is a grant type then as you say it needs a scope param and optionally a client_id param.  I argued for the client_id param earlier since it could assist with HOK scenarios once those further develop.

But when the JWT is used as an AT then it will definitely require the scope as a claim.

So I change my argument to "both" :)

adam


-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Sergey Beryozkin
Sent: Friday, March 15, 2013 4:31 PM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] JWT grant_type and client_id

Hi
On 15/03/13 20:40, Lewis Adam-CAL022 wrote:
> Hi John,
>
> I would like to argue that the scope should be a parameter in the access
> token request message, the same as it is for the RO creds grant and
> client creds grant type. This would keep it consistent with the core
> OAuth grant types that talk directly to the token endpoint.
>
Assuming the assertion is acting as a grant, then it is indeed an access
token request message, so IMHO it makes sense to get an outbound scope
parameter optionally supported which I guess will imply that the client
id will also have to accompany it...

Cheers, Sergey

> Thoughts?
>
> adam
>
> *From:*John Bradley [mailto:ve7jtb@ve7jtb.com]
> *Sent:* Friday, March 15, 2013 12:10 PM
> *To:* Lewis Adam-CAL022
> *Cc:* Brian Campbell; "WG <oauth@ietf.org>"@il06exr02.mot.com
> *Subject:* Re: [OAUTH-WG] JWT grant_type and client_id
>
> The spec is a touch vague on that. I think the scopes should be in the
> assertion and the client can use the scopes outside the assertion to
> down-scope.
>
> Having a standard claim in JWT and SAML for passing scopes is probably
> useful as part of a profile.
>
> John B.
>
> On 2013-03-14, at 8:47 PM, Lewis Adam-CAL022
> <Adam.Lewis@motorolasolutions.com
> <mailto:Adam.Lewis@motorolasolutions.com>> wrote:
>
>
>

> Hmmm, one more thought ... no scope?? The JWT is the grant, is it assumed

> that the scope is conveyed as a claim within the token? Otherwise it
> would seem that it would require a scope.
>
> Thoughts?
>
> adam
>
> *From:*Brian Campbell [mailto:bcampbell@pingidentity.com
> <http://pingidentity.com>]
> *Sent:*Thursday, March 14, 2013 4:44 PM
> *To:*Lewis Adam-CAL022
> *Cc:*Mike Jones; "WG <oauth@ietf.org
> <mailto:oauth@ietf.org>>"@il06exr02.mot.com <http://il06exr02.mot.com>
> *Subject:*Re: [OAUTH-WG] JWT grant_type and client_id
>
> Yes, that is correct.
>
> I'm working on new revisions of the drafts that will hopefully make that
> point more clear.
>
> On Thu, Mar 14, 2013 at 5:26 PM, Lewis Adam-CAL022
> <Adam.Lewis@motorolasolutions.com
> <mailto:Adam.Lewis@motorolasolutions.com>> wrote:
>

> Coming back to this...  am I correct in that client_id is not required?    We are implementing this spec and want to make sure that we are doing it right.    By my understanding the only two parameters that are required in the JWT grant type are  "urn:ietf:params:oauth:grant-type:jwt-bearer"    and the assertion.      Is this correct?

>
> *From:*Mike Jones [mailto:Michael.Jones@microsoft.com
> <mailto:Michael.Jones@microsoft.com>]
> *Sent:*Monday, February 18, 2013 6:58 PM
> *To:*Lewis Adam-CAL022;oauth@ietf.org <mailto:oauth@ietf.org>WG
> *Subject:*RE: JWT grant_type and client_id
>
> The client_id value and the access token value are independent.
>
> -- Mike
>
> *From:*oauth-bounces@ietf.org
> <mailto:oauth-bounces@ietf.org>[mailto:oauth-bounces@ietf.org
> <mailto:oauth-bounces@ietf.org>]*On Behalf Of*Lewis Adam-CAL022
> *Sent:*Monday, February 18, 2013 2:50 PM
> *To:*oauth@ietf.org <mailto:oauth@ietf.org>WG
> *Subject:*[OAUTH-WG] JWT grant_type and client_id
>
> Is there any guidance on the usage of client_id when using the JWT
> assertion profile as a grant type? draft-ietf-oauth-jwt-bearer-04 makes

> no mention so I assume that it is not required ... but it would be

> necessary if using in conjunction with a HOK profile where the JWT
> assertion is issued to - and may only be used by - the intended client.
> Obviously this is straight forward enough, really I'm just looking to be
> sure that I'm not missing anything.
>
> tx
>
> adam
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org <mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org <mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing 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

--------------020501090007000906070905-- From internet-drafts@ietf.org Mon Mar 18 13:33: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 7E9FC21F90BB; Mon, 18 Mar 2013 13:33:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.346 X-Spam-Level: X-Spam-Status: No, score=-102.346 tagged_above=-999 required=5 tests=[AWL=0.254, 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 9CkK5UpeULT3; Mon, 18 Mar 2013 13:33:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C5EA321F90BD; Mon, 18 Mar 2013 13:33:30 -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 Message-ID: <20130318203330.29916.3688.idtracker@ietfa.amsl.com> Date: Mon, 18 Mar 2013 13:33:30 -0700 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-08.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, 18 Mar 2013 20:33:31 -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 : OAuth 2.0 Dynamic Client Registration Protocol Author(s) : Justin Richer John Bradley Michael B. Jones Maciej Machulak Filename : draft-ietf-oauth-dyn-reg-08.txt Pages : 22 Date : 2013-03-18 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-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jricher@mitre.org Mon Mar 18 13:39: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 8861221F9077 for ; Mon, 18 Mar 2013 13:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[AWL=1.400, 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 rDwH7KcqlAR0 for ; Mon, 18 Mar 2013 13:39:56 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id EEC9421F905C for ; Mon, 18 Mar 2013 13:39:55 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 783F21F06F6 for ; Mon, 18 Mar 2013 16:39:55 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 4E37E1F0422 for ; Mon, 18 Mar 2013 16:39:55 -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, 18 Mar 2013 16:39:55 -0400 Message-ID: <51477B47.7010303@mitre.org> Date: Mon, 18 Mar 2013 16:38:31 -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: References: <20130318203330.29916.3688.idtracker@ietfa.amsl.com> In-Reply-To: <20130318203330.29916.3688.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [129.83.31.58] Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-08.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, 18 Mar 2013 20:39:56 -0000 This version of Dynamic Registration incorporates a few minor syntactic and editorial changes that have creeped up over the last couple weeks, such as changing "grant_type" to "grant_types", and adding in a "response_types" field. This version does *not* yet address the human readable string localization issue, as I don't see a clear winner here yet. -- Justin On 03/18/2013 04:33 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-08.txt > Pages : 22 > Date : 2013-03-18 > > 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-08 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dyn-reg-08 > > > 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 From sberyozkin@gmail.com Tue Mar 19 03:22: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 CB41221F8915 for ; Tue, 19 Mar 2013 03:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.448 X-Spam-Level: X-Spam-Status: No, score=-0.448 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, J_CHICKENPOX_25=0.6, 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 7osqk8nhS72n for ; Tue, 19 Mar 2013 03:22:18 -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 4519B21F8873 for ; Tue, 19 Mar 2013 03:22:18 -0700 (PDT) Received: by mail-bk0-f46.google.com with SMTP id j5so143548bkw.19 for ; Tue, 19 Mar 2013 03:22:17 -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=a7CNGfhhgTWI1HtpdTW7oplCl4iCNI8BAVtku1E1IsY=; b=Yu3YRyhD0eVl7+0okJAQ9n1BfJtZ7c6766lf6gBXs7GisJXk4XaGP3B+ywwZgHK1R0 6vZlGEG0hDATar5YVrz6WYrs0Xe9BmApyHMBmX4BkbVPTWJZpZN8mwietsgfn8JA9ysK 4wbH7Z9UYL8t1G+XgTRPsXJQBv52518pZqujDcOGPGyA9+p9taOHQC0BvrhG4oV1BBdy iAu4+nCwzjvl4JuwtcLCYDvDr8p5la06tb7zY1faCikDTfm8Io7S6FG0gQgYj4uAPPrr GEeA5jTpA+SlMTG1sO2r1Q1tYkP8yysxtT89NSjxgdICJ7DibotPH1I5P7GPmPmLPWo5 SPvA== X-Received: by 10.205.15.136 with SMTP id pu8mr8460674bkb.133.1363688537352; Tue, 19 Mar 2013 03:22:17 -0700 (PDT) Received: from [10.36.226.5] ([217.173.99.61]) by mx.google.com with ESMTPS id b21sm6305346bkw.12.2013.03.19.03.22.15 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Mar 2013 03:22:16 -0700 (PDT) Message-ID: <51483C49.4040503@gmail.com> Date: Tue, 19 Mar 2013 10:22:01 +0000 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: Brian Campbell References: <59E470B10C4630419ED717AC79FCF9A948D552B8@BY2PRD0411MB441.namprd04.prod.outlook.com> <4E1F6AAD24975D4BA5B168042967394367472284@TK5EX14MBXC284.redmond.corp.microsoft.com> <59E470B10C4630419ED717AC79FCF9A9568A83EA@BY2PRD0411MB441.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A9568A84A6@BY2PRD0411MB441.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A9568A8760@BY2PRD0411MB441.namprd04.prod.outlook.com> <51439320.9060401@gmail.com> <59E470B10C4630419ED717AC79FCF9A9568A87C1@BY2PRD0411MB441.namprd04.prod.outlook.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] JWT grant_type and client_id X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 10:22:19 -0000 Hi, Just one remark, the example in [1] shows "client_id"; IMHO it makes sense to clarify than in this context (where the assertion is used as a grant), it is optional as per: http://tools.ietf.org/html/rfc6749#section-3.2.1 "A client MAY use the "client_id" request parameter to identify itself when sending requests to the token endpoint" and otherwise http://tools.ietf.org/html/rfc6749#section-2.3 dictates how the client authentication is done. By the way, my reading of the main spec's section 2.3 tells me that the only time one would use only "client_id" in the form payload is when the client secret is empty or perhaps the client is not in the possession of the secret. Does it make sense to completely drop a "client_id" parameter in the example at [1] in the assertion draft and use an example with a Basic authentication instead ? Thanks, Sergey On 15/03/13 22:12, Brian Campbell wrote: > So currently the base assertion document defines scope as an HTTP > parameter on the access token request message when using an assertion as > a grant[1]. And that applies to both the SAML and JWT grants (perhaps > that needs to be more clear?). Also RFC 6749 defines the scope parameter > for the client credentials access token request[2], which similarly > applies to both SAML and JWT in the case of assertion client > authentication using the "client_credentials" grant type. > > [1] http://tools.ietf.org/html/draft-ietf-oauth-assertions-10#section-4.1 > [2] http://tools.ietf.org/html/rfc6749#section-4.4.1 > > > On Fri, Mar 15, 2013 at 3:43 PM, Lewis Adam-CAL022 > > wrote: > > Right ... thinking about this further I think the answer is "all of > the above." If the JWT is a grant type then as you say it needs a > scope param and optionally a client_id param. I argued for the > client_id param earlier since it could assist with HOK scenarios > once those further develop. > > But when the JWT is used as an AT then it will definitely require > the scope as a claim. > > So I change my argument to "both" :) > > adam > > -----Original Message----- > From: oauth-bounces@ietf.org > [mailto:oauth-bounces@ietf.org ] On > Behalf Of Sergey Beryozkin > Sent: Friday, March 15, 2013 4:31 PM > To: oauth@ietf.org > Subject: Re: [OAUTH-WG] JWT grant_type and client_id > > Hi > On 15/03/13 20:40, Lewis Adam-CAL022 wrote: > > Hi John, > > > > I would like to argue that the scope should be a parameter in the > access > > token request message, the same as it is for the RO creds grant and > > client creds grant type. This would keep it consistent with the core > > OAuth grant types that talk directly to the token endpoint. > > > Assuming the assertion is acting as a grant, then it is indeed an access > token request message, so IMHO it makes sense to get an outbound scope > parameter optionally supported which I guess will imply that the client > id will also have to accompany it... > > Cheers, Sergey > > > Thoughts? > > > > adam > > > > *From:*John Bradley [mailto:ve7jtb@ve7jtb.com > ] > > *Sent:* Friday, March 15, 2013 12:10 PM > > *To:* Lewis Adam-CAL022 > > *Cc:* Brian Campbell; "WG >"@il06exr02.mot.com > > *Subject:* Re: [OAUTH-WG] JWT grant_type and client_id > > > > The spec is a touch vague on that. I think the scopes should be > in the > > assertion and the client can use the scopes outside the assertion to > > down-scope. > > > > Having a standard claim in JWT and SAML for passing scopes is > probably > > useful as part of a profile. > > > > John B. > > > > On 2013-03-14, at 8:47 PM, Lewis Adam-CAL022 > > > > >> wrote: > > > > > > > > Hmmm, one more thought ... no scope?? The JWT is the grant, is it > assumed > > that the scope is conveyed as a claim within the token? Otherwise it > > would seem that it would require a scope. > > > > Thoughts? > > > > adam > > > > *From:*Brian Campbell [mailto:bcampbell@pingidentity.com > > > ] > > *Sent:*Thursday, March 14, 2013 4:44 PM > > *To:*Lewis Adam-CAL022 > > *Cc:*Mike Jones; "WG > > >>"@il06exr02.mot.com > > > *Subject:*Re: [OAUTH-WG] JWT grant_type and client_id > > > > Yes, that is correct. > > > > I'm working on new revisions of the drafts that will hopefully > make that > > point more clear. > > > > On Thu, Mar 14, 2013 at 5:26 PM, Lewis Adam-CAL022 > > > > >> wrote: > > > > Coming back to this... am I correct in that client_id is not > required? We are implementing this spec and want to make sure > that we are doing it right. By my understanding the only two > parameters that are required in the JWT grant type are > "urn:ietf:params:oauth:grant-type:jwt-bearer" and the assertion. > Is this correct? > > > > *From:*Mike Jones [mailto:Michael.Jones@microsoft.com > > > >] > > *Sent:*Monday, February 18, 2013 6:58 PM > > *To:*Lewis Adam-CAL022;oauth@ietf.org > >WG > > *Subject:*RE: JWT grant_type and client_id > > > > The client_id value and the access token value are independent. > > > > -- Mike > > > > *From:*oauth-bounces@ietf.org > > >[mailto:oauth-bounces@ietf.org > > > >]*On Behalf Of*Lewis Adam-CAL022 > > *Sent:*Monday, February 18, 2013 2:50 PM > > *To:*oauth@ietf.org > >WG > > *Subject:*[OAUTH-WG] JWT grant_type and client_id > > > > Is there any guidance on the usage of client_id when using the JWT > > assertion profile as a grant type? draft-ietf-oauth-jwt-bearer-04 > makes > > no mention so I assume that it is not required ... but it would be > > necessary if using in conjunction with a HOK profile where the JWT > > assertion is issued to - and may only be used by - the intended > client. > > Obviously this is straight forward enough, really I'm just > looking to be > > sure that I'm not missing anything. > > > > tx > > > > adam > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From jricher@mitre.org Wed Mar 20 10:25: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 23F2E21F8C9E for ; Wed, 20 Mar 2013 10:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.478 X-Spam-Level: X-Spam-Status: No, score=-5.478 tagged_above=-999 required=5 tests=[AWL=1.120, 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 d1TBiLcbFXbC for ; Wed, 20 Mar 2013 10:24:58 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2A77021F8C96 for ; Wed, 20 Mar 2013 10:24:57 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 56C6C1F03EF; Wed, 20 Mar 2013 13:24:56 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 430BD1F03E2; Wed, 20 Mar 2013 13:24:56 -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; Wed, 20 Mar 2013 13:24:56 -0400 Message-ID: <5149F092.7070902@mitre.org> Date: Wed, 20 Mar 2013 13:23:30 -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: Mike Jones References: <1B4C0C9F-4B8E-4B2D-BAF7-665D3EBBE56C@ve7jtb.com> <51408B8B.9000800@mitre.org> <5141E2E6.9020701@aol.com> <5141E671.2050708@mitre.org> <4E1F6AAD24975D4BA5B16804296739436750F5E2@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436750F5E2@TK5EX14MBXC283.redmond.corp.microsoft.com> Content-Type: multipart/alternative; boundary="------------020602020501010602030003" X-Originating-IP: [129.83.31.58] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readable names X-BeenThere: oauth@ietf.org X-Mailman-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, 20 Mar 2013 17:25:03 -0000 --------------020602020501010602030003 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit Personally, I think that this level of specificity is overkill. -- Justin On 03/14/2013 11:42 AM, Mike Jones wrote: > > I agree that having unadorned values likely simplifies things in many > cases, but if we do this, we should let the Client say what > language/script it$B!G(Bs using when providing human-readable strings or > references to them as registration parameters. For this purpose, I$B!G(Bd > propose that we have a parameter something like this one: > > registration_locale > > OPTIONAL or REQURED. Language and script used for human-readable > values or references to human-readable values that are supplied > without language/script tags, represented as a BCP47[RFC5646] language > tag value. This parameter is REQUIRED if any human-readable values or > references to human-readable are provided without language/script tags. > > -- Mike > > *From:*oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On > Behalf Of *Justin Richer > *Sent:* Thursday, March 14, 2013 8:02 AM > *To:* George Fletcher > *Cc:* oauth@ietf.org WG > *Subject:* Re: [OAUTH-WG] Registration: Internationalization of > Human-Readable names > > On the surface this does simplify things, but the issue I forsee with > it is that I want to be able to call "client.getClientName()" and > always get *something* out of it if there are *any* client_name fields > at all. So in this world if I take a client library that assumes en-us > and it talks to a server that only looks for es-cl, there's a very > real chance of the client name not getting set at all. I think that's > a problem. > > This is why I think the default field name (without the language tag) > really should be required and should be left undefined as to what > language and script it is. Essentially, "It's a UTF8 String, hope for > the best". If you want something more specific and smart about > localization, then you can support the language tags. If you just want > to have a string to store and throw at the user, then you can just use > the bare field name. > > In other words, we take what we have now (which works for a > non-internationalized case where everyone just assumes a common > language/script), and we augment it with features that let it be > smarter if you want it to be smarter. Make the simple case simple, > make the complicated case possible. > > -- Justin > > On 03/14/2013 10:47 AM, George Fletcher wrote: > > As a simplifying option... why not just require human-readable > fields to require a "script-tag". This way it is always explicit > what language/locale the text is for. It then becomes the > responsibility of the AS to return an appropriate response if > there is not a direct match between a request and the data stored > at the AS (and out of scope of the spec). > > Thanks, > George > > On 3/13/13 10:22 AM, Justin Richer wrote: > > So with what little feedback I've gotten, I'm proposing to add > text from the proposed webfinger and OIDC drafts for the > hash-based localization of strings, with the following properties: > > * All localized versions of fields are fully optional on both > client and server > * If a localized version of a field is included, its > bare-value (perhaps internationalized) field MUST be included > * All human-readable fields are eligible for this mechanism > (including any uri's for user-facing web pages, which can be > used to point to language-specific pages) > * Clients and servers can decide to use whatever > language/script they want to for the bare-value field, and no > assumptions can be made on either side about what that is > > I think that with these constraints, we can add functionality > to address Stephen's concerns without getting too complicated > or putting too much burden of support. > > -- Justin > > On 03/11/2013 06:52 PM, Nat Sakimura wrote: > > Similar work is in progress at Webfinger. > > See: > http://www.ietf.org/mail-archive/web/webfinger/current/msg00530.html > > Paul is proposing the same syntax as Connect. > > 2013/3/12 Richer, Justin P. > > > It does presume a definition of "claim", which I suppose > we could turn to "metadata field" for DynReg and its > extensions to be appropriately limiting. But we also need > a good definition of what a language-tag-less field means, > and whether or not it's required if the other fields are > present or not (which is something that Connect is trying > to fix at the moment, as I recall from last week). > > So it turns into about a paragraph worth of text. Is that > worth it? I'm not entirely convinced that it is, but I'm > interested to hear what others think, particularly those > who *aren't* tied into the OpenID Connect protocol so > much. (I don't want to pick a solution just because it's > familiar, if we need a solution at all.) > > -- Justin > > On Mar 11, 2013, at 6:35 PM, Brian Campbell > > > > wrote: > > > > A fair question but what would need to be pulled in is > really probably only a couple sentences (and reference) > from > http://openid.net/specs/openid-connect-messages-1_0-16.html#ClaimsLanguagesAndScripts > (note the reference to 2.1.1.1.3 inside > http://openid.net/specs/openid-connect-registration-1_0-15.html > is broken) > > On Mon, Mar 11, 2013 at 6:26 PM, Richer, Justin P. > > wrote: > > My concern with this is that OIDC can get away with > defining this multi-language structure because it defines > the mechanism once (in Messages) and applies it to all > user-readable strings throughout the whole application > protocol, of which there are several. Do we really want to > pull in that whole structure and mechanism for one field > in client registration? I really don't think it should be > something that's defined completely inside of DynReg for a > corner case for a single field, but I also doubt we want > to normatively point to OIDC Messages for this solution > either. > > There are also other ways to do this: Webfinger [1] for > instance uses JSON structures to give language tags to > field values, and has a default mechanism: > > { "en_us": "my client", $B!D(B } > > The fundamental question is this: should a client be able > to register multiple names (in different locales) with a > single client_id, or should it get a different client_id > for each display language set? > > -- Justin > > [1] http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-11 > > On Mar 11, 2013, at 5:54 PM, John Bradley > > > > wrote: > > > > That is what I was thinking. It would be up to the AS to > determine what language and script to present based on the > user preference. > > While a large number of clients will be native and might > be able to customize themselves for a single user during > registration , we don't want to forget the web server > clients that are multi user. > > On 2013-03-11, at 10:49 PM, Brian Campbell > > wrote: > > > > FWIW, the closely related OpenID Connect client > registration draft does have some support for doing this, > which could maybe be borrowed. See client_name in $B!x(B2 at > http://openid.net/specs/openid-connect-registration-1_0-15.html#client-metadata > and the examples. > > "client_name": "My Example", > > "client_name#ja-Jpan-JP":"$B%/%i%$%"%s%HL>(B", > > On Mon, Mar 11, 2013 at 5:15 PM, Richer, Justin P. > > wrote: > > It was brought up at the in-person meeting today that > we'll want to consider issues around internationalization > and localization of human-readable fields like client_name > in the client registration. Which is to say: if a client > supports ten languages and wants to present itself in ten > languages, should it have to register itself ten times > with an AS? > > At the moment, I'm of the opinion a client with ten > languages could register itself ten times, or do something > with the context in which it runs to determine which > human-facing language to use. Keep in mind that in some > cases (such as native clients), you'll be dynamically > registering a client for each user, in effect. In other > words, I personally think that this is a rathole that will > cause more harm than good. > > -- Justin > _______________________________________________ > OAuth mailing 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 > > > > -- > 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 > --------------020602020501010602030003 Content-Type: text/html; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit Personally, I think that this level of specificity is overkill.

 -- Justin


On 03/14/2013 11:42 AM, Mike Jones wrote:

I agree that having unadorned values likely simplifies things in many cases, but if we do this, we should let the Client say what language/script it$B!G(Bs using when providing human-readable strings or references to them as registration parameters.  For this purpose, I$B!G(Bd propose that we have a parameter something like this one:

 

registration_locale

OPTIONAL or REQURED. Language and script used for human-readable values or references to human-readable values that are supplied without language/script tags, represented as a BCP47[RFC5646] language tag value.  This parameter is REQUIRED if any human-readable values or references to human-readable are provided without language/script tags.

 

                                                            -- Mike

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Justin Richer
Sent: Thursday, March 14, 2013 8:02 AM
To: George Fletcher
Cc: oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readable names

 

On the surface this does simplify things, but the issue I forsee with it is that I want to be able to call "client.getClientName()" and always get *something* out of it if there are *any* client_name fields at all. So in this world if I take a client library that assumes en-us and it talks to a server that only looks for es-cl, there's a very real chance of the client name not getting set at all. I think that's a problem.

This is why I think the default field name (without the language tag) really should be required and should be left undefined as to what language and script it is. Essentially, "It's a UTF8 String, hope for the best". If you want something more specific and smart about localization, then you can support the language tags. If you just want to have a string to store and throw at the user, then you can just use the bare field name.

In other words, we take what we have now (which works for a non-internationalized case where everyone just assumes a common language/script), and we augment it with features that let it be smarter if you want it to be smarter. Make the simple case simple, make the complicated case possible.

 -- Justin

 

On 03/14/2013 10:47 AM, George Fletcher wrote:

As a simplifying option... why not just require human-readable fields to require a "script-tag". This way it is always explicit what language/locale the text is for. It then becomes the responsibility of the AS to return an appropriate response if there is not a direct match between a request and the data stored at the AS (and out of scope of the spec).

Thanks,
George

On 3/13/13 10:22 AM, Justin Richer wrote:

So with what little feedback I've gotten, I'm proposing to add text from the proposed webfinger and OIDC drafts for the hash-based localization of strings, with the following properties:

* All localized versions of fields are fully optional on both client and server
* If a localized version of a field is included, its bare-value (perhaps internationalized) field MUST be included
* All human-readable fields are eligible for this mechanism (including any uri's for user-facing web pages, which can be used to point to language-specific pages)
* Clients and servers can decide to use whatever language/script they want to for the bare-value field, and no assumptions can be made on either side about what that is

I think that with these constraints, we can add functionality to address Stephen's concerns without getting too complicated or putting too much burden of support.

 -- Justin

On 03/11/2013 06:52 PM, Nat Sakimura wrote:

Similar work is in progress at Webfinger. 

 

 

Paul is proposing the same syntax as Connect. 

2013/3/12 Richer, Justin P. <jricher@mitre.org>

It does presume a definition of "claim", which I suppose we could turn to "metadata field" for DynReg and its extensions to be appropriately limiting. But we also need a good definition of what a language-tag-less field means, and whether or not it's required if the other fields are present or not (which is something that Connect is trying to fix at the moment, as I recall from last week). 

 

So it turns into about a paragraph worth of text. Is that worth it? I'm not entirely convinced that it is, but I'm interested to hear what others think, particularly those who *aren't* tied into the OpenID Connect protocol so much. (I don't want to pick a solution just because it's familiar, if we need a solution at all.)

 

 -- Justin

 

On Mar 11, 2013, at 6:35 PM, Brian Campbell <bcampbell@pingidentity.com>

 wrote:



A fair question but what would need to be pulled in is really probably only a couple sentences (and reference) from http://openid.net/specs/openid-connect-messages-1_0-16.html#ClaimsLanguagesAndScripts (note the reference to 2.1.1.1.3 inside http://openid.net/specs/openid-connect-registration-1_0-15.html is broken)

 

On Mon, Mar 11, 2013 at 6:26 PM, Richer, Justin P. <jricher@mitre.org> wrote:

My concern with this is that OIDC can get away with defining this multi-language structure because it defines the mechanism once (in Messages) and applies it to all user-readable strings throughout the whole application protocol, of which there are several. Do we really want to pull in that whole structure and mechanism for one field in client registration? I really don't think it should be something that's defined completely inside of DynReg for a corner case for a single field, but I also doubt we want to normatively point to OIDC Messages for this solution either.

 

There are also other ways to do this: Webfinger [1] for instance uses JSON structures to give language tags to field values, and has a default mechanism:

 

   { "en_us": "my client", $B!D(B }

 

The fundamental question is  this: should a client be able to register multiple names (in different locales) with a single client_id, or should it get a different client_id for each display language set?

 

 -- Justin

 

 

On Mar 11, 2013, at 5:54 PM, John Bradley <ve7jtb@ve7jtb.com>

 wrote:



That is what I was thinking.   It would be up to the AS to determine what language and script to present based on the user preference.

 

While a large number of clients will be native and might be able to customize themselves for a single user during registration , we don't want to forget the web server clients that are multi user.

 

On 2013-03-11, at 10:49 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:



FWIW, the closely related OpenID Connect client registration draft does have some support for doing this, which could maybe be borrowed. See client_name in $B!x(B2 at http://openid.net/specs/openid-connect-registration-1_0-15.html#client-metadata and the examples.
 

   "client_name": "My Example",
   "client_name#ja-Jpan-JP":"$B%/%i%$%"%s%HL>(B",

 

 

On Mon, Mar 11, 2013 at 5:15 PM, Richer, Justin P. <jricher@mitre.org> wrote:

It was brought up at the in-person meeting today that we'll want to consider issues around internationalization and localization of human-readable fields like client_name in the client registration. Which is to say: if a client supports ten languages and wants to present itself in ten languages, should it have to register itself ten times with an AS?

At the moment, I'm of the opinion a client with ten languages could register itself ten times, or do something with the context in which it runs to determine which human-facing language to use. Keep in mind that in some cases (such as native clients), you'll be dynamically registering a client for each user, in effect. In other words, I personally think that this is a rathole that will cause more harm than good.

 -- Justin
_______________________________________________
OAuth mailing 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



 

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

 

 


--------------020602020501010602030003-- From Michael.Jones@microsoft.com Wed Mar 20 10:28: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 00E5D21F8FEA for ; Wed, 20 Mar 2013 10:28:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.075, 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 qt0m-L4xImsI for ; Wed, 20 Mar 2013 10:28:27 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0243.outbound.protection.outlook.com [207.46.163.243]) by ietfa.amsl.com (Postfix) with ESMTP id ADBFF21F8FE8 for ; Wed, 20 Mar 2013 10:28:26 -0700 (PDT) Received: from BL2FFO11FD011.protection.gbl (10.173.161.200) by BL2FFO11HUB019.protection.gbl (10.173.160.111) with Microsoft SMTP Server (TLS) id 15.0.641.9; Wed, 20 Mar 2013 17:28:22 +0000 Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD011.mail.protection.outlook.com (10.173.161.17) with Microsoft SMTP Server (TLS) id 15.0.641.9 via Frontend Transport; Wed, 20 Mar 2013 17:28:22 +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, 20 Mar 2013 17:27:56 +0000 From: Mike Jones To: Justin Richer Thread-Topic: [OAUTH-WG] Registration: Internationalization of Human-Readable names Thread-Index: AQHOH/ZlY5HOQV9nDkW4sYSziV3/rJilRaYAgAAEOYCAAAfTkIAJjagAgAABPnc= Date: Wed, 20 Mar 2013 17:27:56 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394367565FEF@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <1B4C0C9F-4B8E-4B2D-BAF7-665D3EBBE56C@ve7jtb.com> <51408B8B.9000800@mitre.org> <5141E2E6.9020701@aol.com> <5141E671.2050708@mitre.org> <4E1F6AAD24975D4BA5B16804296739436750F5E2@TK5EX14MBXC283.redmond.corp.microsoft.com>, <5149F092.7070902@mitre.org> In-Reply-To: <5149F092.7070902@mitre.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394367565FEFTK5EX14MBXC283r_" 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)(55885001)(164054002)(51444002)(479174001)(24454001)(377424002)(199002)(377454001)(54356001)(49866001)(512904001)(20776003)(54316002)(5343645001)(16236675001)(47446002)(16297215001)(50986001)(51856001)(69226001)(55846006)(31966008)(56816002)(77982001)(74662001)(5343655001)(65816001)(46102001)(44976002)(16406001)(59766001)(56776001)(63696002)(15395725002)(15202345001)(53806001)(79102001)(33656001)(47736001)(76482001)(80022001)(47976001)(74502001)(4396001)(5343635001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB019; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 07915F544A Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readable names X-BeenThere: oauth@ietf.org X-Mailman-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, 20 Mar 2013 17:28:31 -0000 --_000_4E1F6AAD24975D4BA5B168042967394367565FEFTK5EX14MBXC283r_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable How would you do this instead then? ________________________________ From: Justin Richer Sent: 3/20/2013 10:25 AM To: Mike Jones Cc: George Fletcher; oauth@ietf.org WG Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readabl= e names Personally, I think that this level of specificity is overkill. -- Justin On 03/14/2013 11:42 AM, Mike Jones wrote: I agree that having unadorned values likely simplifies things in many cases= , but if we do this, we should let the Client say what language/script it= =1B$B!G=1B(Bs using when providing human-readable strings or references to = them as registration parameters. For this purpose, I=1B$B!G=1B(Bd propose = that we have a parameter something like this one: registration_locale OPTIONAL or REQURED. Language and script used for human-readable values or = references to human-readable values that are supplied without language/scri= pt tags, represented as a BCP47[RFC5646] language tag value. This paramete= r is REQUIRED if any human-readable values or references to human-readable = are provided without language/script tags. -- Mike From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Justin Richer Sent: Thursday, March 14, 2013 8:02 AM To: George Fletcher Cc: oauth@ietf.org WG Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readabl= e names On the surface this does simplify things, but the issue I forsee with it is= that I want to be able to call "client.getClientName()" and always get *so= mething* out of it if there are *any* client_name fields at all. So in this= world if I take a client library that assumes en-us and it talks to a serv= er that only looks for es-cl, there's a very real chance of the client name= not getting set at all. I think that's a problem. This is why I think the default field name (without the language tag) reall= y should be required and should be left undefined as to what language and s= cript it is. Essentially, "It's a UTF8 String, hope for the best". If you w= ant something more specific and smart about localization, then you can supp= ort the language tags. If you just want to have a string to store and throw= at the user, then you can just use the bare field name. In other words, we take what we have now (which works for a non-internation= alized case where everyone just assumes a common language/script), and we a= ugment it with features that let it be smarter if you want it to be smarter= . Make the simple case simple, make the complicated case possible. -- Justin On 03/14/2013 10:47 AM, George Fletcher wrote: As a simplifying option... why not just require human-readable fields to re= quire a "script-tag". This way it is always explicit what language/locale t= he text is for. It then becomes the responsibility of the AS to return an a= ppropriate response if there is not a direct match between a request and th= e data stored at the AS (and out of scope of the spec). Thanks, George On 3/13/13 10:22 AM, Justin Richer wrote: So with what little feedback I've gotten, I'm proposing to add text from th= e proposed webfinger and OIDC drafts for the hash-based localization of str= ings, with the following properties: * All localized versions of fields are fully optional on both client and se= rver * If a localized version of a field is included, its bare-value (perhaps in= ternationalized) field MUST be included * All human-readable fields are eligible for this mechanism (including any = uri's for user-facing web pages, which can be used to point to language-spe= cific pages) * Clients and servers can decide to use whatever language/script they want = to for the bare-value field, and no assumptions can be made on either side = about what that is I think that with these constraints, we can add functionality to address St= ephen's concerns without getting too complicated or putting too much burden= of support. -- Justin On 03/11/2013 06:52 PM, Nat Sakimura wrote: Similar work is in progress at Webfinger. See: http://www.ietf.org/mail-archive/web/webfinger/current/msg00530.html Paul is proposing the same syntax as Connect. 2013/3/12 Richer, Justin P. > It does presume a definition of "claim", which I suppose we could turn to "= metadata field" for DynReg and its extensions to be appropriately limiting.= But we also need a good definition of what a language-tag-less field means= , and whether or not it's required if the other fields are present or not (= which is something that Connect is trying to fix at the moment, as I recall= from last week). So it turns into about a paragraph worth of text. Is that worth it? I'm not= entirely convinced that it is, but I'm interested to hear what others thin= k, particularly those who *aren't* tied into the OpenID Connect protocol so= much. (I don't want to pick a solution just because it's familiar, if we n= eed a solution at all.) -- Justin On Mar 11, 2013, at 6:35 PM, Brian Campbell > wrote: A fair question but what would need to be pulled in is really probably only= a couple sentences (and reference) from http://openid.net/specs/openid-con= nect-messages-1_0-16.html#ClaimsLanguagesAndScripts (note the reference to = 2.1.1.1.3 inside http://openid.net/specs/openid-connect-registration-1_0-15= .html is broken) On Mon, Mar 11, 2013 at 6:26 PM, Richer, Justin P. > wrote: My concern with this is that OIDC can get away with defining this multi-lan= guage structure because it defines the mechanism once (in Messages) and app= lies it to all user-readable strings throughout the whole application proto= col, of which there are several. Do we really want to pull in that whole st= ructure and mechanism for one field in client registration? I really don't = think it should be something that's defined completely inside of DynReg for= a corner case for a single field, but I also doubt we want to normatively = point to OIDC Messages for this solution either. There are also other ways to do this: Webfinger [1] for instance uses JSON = structures to give language tags to field values, and has a default mechani= sm: { "en_us": "my client", =1B$B!D=1B(B } The fundamental question is this: should a client be able to register mult= iple names (in different locales) with a single client_id, or should it get= a different client_id for each display language set? -- Justin [1] http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-11 On Mar 11, 2013, at 5:54 PM, John Bradley > wrote: That is what I was thinking. It would be up to the AS to determine what l= anguage and script to present based on the user preference. While a large number of clients will be native and might be able to customi= ze themselves for a single user during registration , we don't want to forg= et the web server clients that are multi user. On 2013-03-11, at 10:49 PM, Brian Campbell > wrote: FWIW, the closely related OpenID Connect client registration draft does hav= e some support for doing this, which could maybe be borrowed. See client_na= me in =1B$B!x=1B(B2 at http://openid.net/specs/openid-connect-registration-= 1_0-15.html#client-metadata and the examples. "client_name": "My Example", "client_name#ja-Jpan-JP":"=1B$B%/%i%$%"%s%HL>=1B(B", On Mon, Mar 11, 2013 at 5:15 PM, Richer, Justin P. > wrote: It was brought up at the in-person meeting today that we'll want to conside= r issues around internationalization and localization of human-readable fie= lds like client_name in the client registration. Which is to say: if a clie= nt supports ten languages and wants to present itself in ten languages, sho= uld it have to register itself ten times with an AS? At the moment, I'm of the opinion a client with ten languages could registe= r itself ten times, or do something with the context in which it runs to de= termine which human-facing language to use. Keep in mind that in some cases= (such as native clients), you'll be dynamically registering a client for e= ach user, in effect. In other words, I personally think that this is a rath= ole that will cause more harm than good. -- Justin _______________________________________________ OAuth mailing 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 -- Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_4E1F6AAD24975D4BA5B168042967394367565FEFTK5EX14MBXC283r_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable
How would you= do this instead then?

From: Justin= Richer
Sent: 3/20/2= 013 10:25 AM
To: Mike J= ones
Cc: George= Fletcher; oauth@ietf.org WG
Subject: Re: [O= AUTH-WG] Registration: Internationalization of Human-Readable names<= br>
Personally, I think that this level of specificity is overkill.

 -- Justin


On 03/14/2013 11:42 AM, Mike Jones wrote:

I agree that having una= dorned values likely simplifies things in many cases, but if we do this, we= should let the Client say what language/script it=1B$B!G=1B(Bs using when providing human-readable strings or references to them as registratio= n parameters.  For this purpose, I=1B$B!G=1B(Bd propose that we have a= parameter something like this one:

 

registration_locale

OPTIONAL or REQ= URED. Language and script used for human-readable values or references to h= uman-readable values that are supplied without language/script tags, represented as a BCP47[RFC5646] language tag value.  This param= eter is REQUIRED if any human-readable values or references to human-readab= le are provided without language/script tags.

 

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

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Justin Richer
Sent: Thursday, March 14, 2013 8:02 AM
To: George Fletcher
Cc: oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-= Readable names

 

On the surface this does simplify things, but the is= sue I forsee with it is that I want to be able to call "client.getClie= ntName()" and always get *something* out of it if there are *any* clie= nt_name fields at all. So in this world if I take a client library that assumes en-us and it talks to a server that onl= y looks for es-cl, there's a very real chance of the client name not gettin= g set at all. I think that's a problem.

This is why I think the default field name (without the language tag) reall= y should be required and should be left undefined as to what language and s= cript it is. Essentially, "It's a UTF8 String, hope for the best"= . If you want something more specific and smart about localization, then you can support the language tags. If you j= ust want to have a string to store and throw at the user, then you can just= use the bare field name.

In other words, we take what we have now (which works for a non-internation= alized case where everyone just assumes a common language/script), and we a= ugment it with features that let it be smarter if you want it to be smarter= . Make the simple case simple, make the complicated case possible.

 -- Justin

 

On 03/14/2013 10:47 AM, George Fletcher wrote:

As a simplifying option= ... why not just require human-readable fields to require a "script-ta= g". This way it is always explicit what language/locale the text is for. It then becomes the responsibility of the AS to return an appropri= ate response if there is not a direct match between a request and the data = stored at the AS (and out of scope of the spec).

Thanks,
George

On 3/13/13 10:22 AM, Justin Richer wrote:

So with what little f= eedback I've gotten, I'm proposing to add text from the proposed webfinger = and OIDC drafts for the hash-based localization of strings, with the follow= ing properties:

* All localized versions of fields are fully optional on both client and se= rver
* If a localized version of a field is included, its bare-value (perhaps in= ternationalized) field MUST be included
* All human-readable fields are eligible for this mechanism (including any = uri's for user-facing web pages, which can be used to point to language-spe= cific pages)
* Clients and servers can decide to use whatever language/script they want = to for the bare-value field, and no assumptions can be made on either side = about what that is

I think that with these constraints, we can add functionality to address St= ephen's concerns without getting too complicated or putting too much burden= of support.

 -- Justin

On 03/11/2013 06:52 PM, Nat Sakimura wrote:

Similar work is in progress at Webfinger. 

 

 

Paul is proposing the= same syntax as Connect. 

2013/3/12 Richer, Justin P. <jricher@mitre.org>

It does presume a definition of "claim", w= hich I suppose we could turn to "metadata field" for DynReg and i= ts extensions to be appropriately limiting. But we also need a good definit= ion of what a language-tag-less field means, and whether or not it's required if the other fields are present or not (which is some= thing that Connect is trying to fix at the moment, as I recall from last we= ek). 

 

So it turns into about a paragraph worth of text. Is= that worth it? I'm not entirely convinced that it is, but I'm interested t= o hear what others think, particularly those who *aren't* tied into the Ope= nID Connect protocol so much. (I don't want to pick a solution just because it's familiar, if we need a solution = at all.)

 

 -- Justin

 

On Mar 11, 2013, at 6:35 PM, Brian Campbell <bcampbell@pingi= dentity.com>

 wrote:



A fair question but what would need to be pulled in = is really probably only a couple sentences (and reference) from http://openid.net/specs/openid-connect-messages-1_0-16.html#ClaimsLanguages= AndScripts (note the reference to 2.1.1.1.3 inside http://openid.net/specs/openid-connect-registration-1_0-15.html is brok= en)

 

On Mon, Mar 11, 2013 at 6:26 PM, Richer, Justin P. &= lt;jricher@mitre.org= > wrote:

My concern with this is that OIDC can get away with = defining this multi-language structure because it defines the mechanism onc= e (in Messages) and applies it to all user-readable strings throughout the = whole application protocol, of which there are several. Do we really want to pull in that whole structure and m= echanism for one field in client registration? I really don't think it shou= ld be something that's defined completely inside of DynReg for a corner cas= e for a single field, but I also doubt we want to normatively point to OIDC Messages for this solution eith= er.

 

There are also other ways to do this: Webfinger [1] = for instance uses JSON structures to give language tags to field values, an= d has a default mechanism:

 

   { "en_us": "my client&qu= ot;, =1B$B!D=1B(B }

 

The fundamental question is  this: should a cli= ent be able to register multiple names (in different locales) with a single= client_id, or should it get a different client_id for each display languag= e set?

 

 -- Justin

 

 

On Mar 11, 2013, at 5:54 PM, John Bradley <ve7jtb@ve7jtb.com><= /p>

 wrote:



That is what I was thinking.   It would be up t= o the AS to determine what language and script to present based on the user= preference.

 

While a large number of clients will be native and m= ight be able to customize themselves for a single user during registration = , we don't want to forget the web server clients that are multi user.

 

On 2013-03-11, at 10:49 PM, Brian Campbell <bcampbell@pingid= entity.com> wrote:



FWIW, the closely related OpenID Connect client regi= stration draft does have some support for doing this, which could maybe be = borrowed. See client_name in =1B$B!x=1B(B2 at http://openid.net/specs/openid-connect-registration-1_0-15.html#client-meta= data and the examples.
 

   "client_name": "My Example",
   "client_name#ja-Jpan-JP":"=1B$B%/%i%$%"%s%HL>=1B(B",

 

 

On Mon, Mar 11, 2013 at 5:15 PM, Richer, Justin P. &= lt;jricher@mitre.org= > wrote:

It was brought up at the in-person meeting today tha= t we'll want to consider issues around internationalization and localizatio= n of human-readable fields like client_name in the client registration. Whi= ch is to say: if a client supports ten languages and wants to present itself in ten languages, should it have= to register itself ten times with an AS?

At the moment, I'm of the opinion a client with ten languages could registe= r itself ten times, or do something with the context in which it runs to de= termine which human-facing language to use. Keep in mind that in some cases= (such as native clients), you'll be dynamically registering a client for each user, in effect. In other wor= ds, I personally think that this is a rathole that will cause more harm tha= n good.

 -- Justin
_______________________________________________
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

 

 

 

 


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



 

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.= org/
@_nat_en





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

 

 


--_000_4E1F6AAD24975D4BA5B168042967394367565FEFTK5EX14MBXC283r_-- From jricher@mitre.org Wed Mar 20 10:44: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 5B0AC21F8FB3 for ; Wed, 20 Mar 2013 10:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.665 X-Spam-Level: X-Spam-Status: No, score=-5.665 tagged_above=-999 required=5 tests=[AWL=0.933, 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 m7lQTSxpmpZ8 for ; Wed, 20 Mar 2013 10:44:52 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id D77AC21F8FAF for ; Wed, 20 Mar 2013 10:44:51 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 387C12260047; Wed, 20 Mar 2013 13:44:46 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 0CE422260027; Wed, 20 Mar 2013 13:44:42 -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; Wed, 20 Mar 2013 13:44:41 -0400 Message-ID: <5149F534.1040500@mitre.org> Date: Wed, 20 Mar 2013 13:43:16 -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: Mike Jones References: <1B4C0C9F-4B8E-4B2D-BAF7-665D3EBBE56C@ve7jtb.com> <51408B8B.9000800@mitre.org> <5141E2E6.9020701@aol.com> <5141E671.2050708@mitre.org> <4E1F6AAD24975D4BA5B16804296739436750F5E2@TK5EX14MBXC283.redmond.corp.microsoft.com>, <5149F092.7070902@mitre.org> <4E1F6AAD24975D4BA5B168042967394367565FEF@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394367565FEF@TK5EX14MBXC283.redmond.corp.microsoft.com> Content-Type: multipart/alternative; boundary="------------040606000004030407050602" X-Originating-IP: [129.83.31.58] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readable names X-BeenThere: oauth@ietf.org X-Mailman-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, 20 Mar 2013 17:44:54 -0000 --------------040606000004030407050602 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit I would say that claims without a language parameter, which I would make REQUIRED in the presence of other claims, would be treated as UTF8 strings with no guarantee of what language, script, or other locale-specific information would be in there. It's a default string, and it's the best the client can give if nothing more specific is useful. And servers would have to accept this default string and do their best with it. A service provider can publish their expected default locale information in either discovery or service documentation, and clients that want to tweak things for specific service providers can do that. The server can display it (because it's a string that'll always be there, if any version is there), but a server that doesn't do internationalized strings very well might not get its display correct. Since displayable text this is likely to be dumped into the middle of a webpage that has its own character encoding and other considerations anyway, so it's not guaranteed that specifying a locale will always help here anyway. This is just for the displayable text, which right now is only the client_name field in OAuth and OIDC: for URLs (the other "human-readable" field), it's a moot point, because the server's just going to spit out the URL itself into an href of some flavor. The server doesn't have to deal with any kind of encoding or text/script issues here. As a server developer, it's just another thing that I *have* to track and deal with on the client model, even if I don't want to support the rest of the multi-language tags in my service. As a client developer, it's one more thing that I *have* to specify when I send things to the server. I don't see how requiring its specification is going to really help interoperability, and I can almost guarantee that implementations will just leave it off even if marked REQUIRED (like how many, many documents in the wild that are supposed to have a character-encoding field of some type just leave it off). I think that it's a lot of work on both sides for just client_name. -- Justin On 03/20/2013 01:27 PM, Mike Jones wrote: > How would you do this instead then? > > ------------------------------------------------------------------------ > From: Justin Richer > Sent: 3/20/2013 10:25 AM > To: Mike Jones > Cc: George Fletcher; oauth@ietf.org WG > Subject: Re: [OAUTH-WG] Registration: Internationalization of > Human-Readable names > > Personally, I think that this level of specificity is overkill. > > -- Justin > > > On 03/14/2013 11:42 AM, Mike Jones wrote: >> >> I agree that having unadorned values likely simplifies things in many >> cases, but if we do this, we should let the Client say what >> language/script it$B!G(Bs using when providing human-readable strings or >> references to them as registration parameters. For this purpose, I$B!G(Bd >> propose that we have a parameter something like this one: >> >> registration_locale >> >> OPTIONAL or REQURED. Language and script used for human-readable >> values or references to human-readable values that are supplied >> without language/script tags, represented as a BCP47[RFC5646] >> language tag value. This parameter is REQUIRED if any human-readable >> values or references to human-readable are provided without >> language/script tags. >> >> -- Mike >> >> *From:*oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On >> Behalf Of *Justin Richer >> *Sent:* Thursday, March 14, 2013 8:02 AM >> *To:* George Fletcher >> *Cc:* oauth@ietf.org WG >> *Subject:* Re: [OAUTH-WG] Registration: Internationalization of >> Human-Readable names >> >> On the surface this does simplify things, but the issue I forsee with >> it is that I want to be able to call "client.getClientName()" and >> always get *something* out of it if there are *any* client_name >> fields at all. So in this world if I take a client library that >> assumes en-us and it talks to a server that only looks for es-cl, >> there's a very real chance of the client name not getting set at all. >> I think that's a problem. >> >> This is why I think the default field name (without the language tag) >> really should be required and should be left undefined as to what >> language and script it is. Essentially, "It's a UTF8 String, hope for >> the best". If you want something more specific and smart about >> localization, then you can support the language tags. If you just >> want to have a string to store and throw at the user, then you can >> just use the bare field name. >> >> In other words, we take what we have now (which works for a >> non-internationalized case where everyone just assumes a common >> language/script), and we augment it with features that let it be >> smarter if you want it to be smarter. Make the simple case simple, >> make the complicated case possible. >> >> -- Justin >> >> On 03/14/2013 10:47 AM, George Fletcher wrote: >> >> As a simplifying option... why not just require human-readable >> fields to require a "script-tag". This way it is always explicit >> what language/locale the text is for. It then becomes the >> responsibility of the AS to return an appropriate response if >> there is not a direct match between a request and the data stored >> at the AS (and out of scope of the spec). >> >> Thanks, >> George >> >> On 3/13/13 10:22 AM, Justin Richer wrote: >> >> So with what little feedback I've gotten, I'm proposing to >> add text from the proposed webfinger and OIDC drafts for the >> hash-based localization of strings, with the following >> properties: >> >> * All localized versions of fields are fully optional on both >> client and server >> * If a localized version of a field is included, its >> bare-value (perhaps internationalized) field MUST be included >> * All human-readable fields are eligible for this mechanism >> (including any uri's for user-facing web pages, which can be >> used to point to language-specific pages) >> * Clients and servers can decide to use whatever >> language/script they want to for the bare-value field, and no >> assumptions can be made on either side about what that is >> >> I think that with these constraints, we can add functionality >> to address Stephen's concerns without getting too complicated >> or putting too much burden of support. >> >> -- Justin >> >> On 03/11/2013 06:52 PM, Nat Sakimura wrote: >> >> Similar work is in progress at Webfinger. >> >> See: >> http://www.ietf.org/mail-archive/web/webfinger/current/msg00530.html >> >> Paul is proposing the same syntax as Connect. >> >> 2013/3/12 Richer, Justin P. > > >> >> It does presume a definition of "claim", which I suppose >> we could turn to "metadata field" for DynReg and its >> extensions to be appropriately limiting. But we also need >> a good definition of what a language-tag-less field >> means, and whether or not it's required if the other >> fields are present or not (which is something that >> Connect is trying to fix at the moment, as I recall from >> last week). >> >> So it turns into about a paragraph worth of text. Is that >> worth it? I'm not entirely convinced that it is, but I'm >> interested to hear what others think, particularly those >> who *aren't* tied into the OpenID Connect protocol so >> much. (I don't want to pick a solution just because it's >> familiar, if we need a solution at all.) >> >> -- Justin >> >> On Mar 11, 2013, at 6:35 PM, Brian Campbell >> > > >> >> wrote: >> >> >> >> A fair question but what would need to be pulled in is >> really probably only a couple sentences (and reference) >> from >> http://openid.net/specs/openid-connect-messages-1_0-16.html#ClaimsLanguagesAndScripts >> (note the reference to 2.1.1.1.3 inside >> http://openid.net/specs/openid-connect-registration-1_0-15.html >> is broken) >> >> On Mon, Mar 11, 2013 at 6:26 PM, Richer, Justin P. >> > wrote: >> >> My concern with this is that OIDC can get away with >> defining this multi-language structure because it defines >> the mechanism once (in Messages) and applies it to all >> user-readable strings throughout the whole application >> protocol, of which there are several. Do we really want >> to pull in that whole structure and mechanism for one >> field in client registration? I really don't think it >> should be something that's defined completely inside of >> DynReg for a corner case for a single field, but I also >> doubt we want to normatively point to OIDC Messages for >> this solution either. >> >> There are also other ways to do this: Webfinger [1] for >> instance uses JSON structures to give language tags to >> field values, and has a default mechanism: >> >> { "en_us": "my client", $B!D(B } >> >> The fundamental question is this: should a client be able >> to register multiple names (in different locales) with a >> single client_id, or should it get a different client_id >> for each display language set? >> >> -- Justin >> >> [1] >> http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-11 >> >> On Mar 11, 2013, at 5:54 PM, John Bradley >> > >> >> wrote: >> >> >> >> That is what I was thinking. It would be up to the AS to >> determine what language and script to present based on >> the user preference. >> >> While a large number of clients will be native and might >> be able to customize themselves for a single user during >> registration , we don't want to forget the web server >> clients that are multi user. >> >> On 2013-03-11, at 10:49 PM, Brian Campbell >> > > wrote: >> >> >> >> FWIW, the closely related OpenID Connect client >> registration draft does have some support for doing this, >> which could maybe be borrowed. See client_name in $B!x(B2 at >> http://openid.net/specs/openid-connect-registration-1_0-15.html#client-metadata >> and the examples. >> >> "client_name": "My Example", >> >> "client_name#ja-Jpan-JP":"$B%/%i%$%"%s%HL>(B", >> >> On Mon, Mar 11, 2013 at 5:15 PM, Richer, Justin P. >> > wrote: >> >> It was brought up at the in-person meeting today that >> we'll want to consider issues around internationalization >> and localization of human-readable fields like >> client_name in the client registration. Which is to say: >> if a client supports ten languages and wants to present >> itself in ten languages, should it have to register >> itself ten times with an AS? >> >> At the moment, I'm of the opinion a client with ten >> languages could register itself ten times, or do >> something with the context in which it runs to determine >> which human-facing language to use. Keep in mind that in >> some cases (such as native clients), you'll be >> dynamically registering a client for each user, in >> effect. In other words, I personally think that this is a >> rathole that will cause more harm than good. >> >> -- Justin >> _______________________________________________ >> OAuth mailing 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 >> >> >> >> -- >> 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 >> > --------------040606000004030407050602 Content-Type: text/html; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit I would say that claims without a language parameter, which I would make REQUIRED in the presence of other claims, would be treated as UTF8 strings with no guarantee of what language, script, or other locale-specific information would be in there. It's a default string, and it's the best the client can give if nothing more specific is useful. And servers would have to accept this default string and do their best with it. A service provider can publish their expected default locale information in either discovery or service documentation, and clients that want to tweak things for specific service providers can do that.

The server can display it (because it's a string that'll always be there, if any version is there), but a server that doesn't do internationalized strings very well might not get its display correct. Since displayable text this is likely to be dumped into the middle of a webpage that has its own character encoding and other considerations anyway, so it's not guaranteed that specifying a locale will always help here anyway. This is just for the displayable text, which right now is only the client_name field in OAuth and OIDC: for URLs (the other "human-readable" field), it's a moot point, because the server's just going to spit out the URL itself into an href of some flavor. The server doesn't have to deal with any kind of encoding or text/script issues here.

As a server developer, it's just another thing that I *have* to track and deal with on the client model, even if I don't want to support the rest of the multi-language tags in my service. As a client developer, it's one more thing that I *have* to specify when I send things to the server. I don't see how requiring its specification is going to really help interoperability, and I can almost guarantee that implementations will just leave it off even if marked REQUIRED (like how many, many documents in the wild that are supposed to have a character-encoding field of some type just leave it off).

I think that it's a lot of work on both sides for just client_name.

 -- Justin


On 03/20/2013 01:27 PM, Mike Jones wrote:
How would you do this instead then?

From: Justin Richer
Sent: 3/20/2013 10:25 AM
To: Mike Jones
Cc: George Fletcher; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readable names

Personally, I think that this level of specificity is overkill.

 -- Justin


On 03/14/2013 11:42 AM, Mike Jones wrote:

I agree that having unadorned values likely simplifies things in many cases, but if we do this, we should let the Client say what language/script it$B!G(Bs using when providing human-readable strings or references to them as registration parameters.  For this purpose, I$B!G(Bd propose that we have a parameter something like this one:

 

registration_locale

OPTIONAL or REQURED. Language and script used for human-readable values or references to human-readable values that are supplied without language/script tags, represented as a BCP47[RFC5646] language tag value.  This parameter is REQUIRED if any human-readable values or references to human-readable are provided without language/script tags.

 

                                                            -- Mike

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Justin Richer
Sent: Thursday, March 14, 2013 8:02 AM
To: George Fletcher
Cc: oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readable names

 

On the surface this does simplify things, but the issue I forsee with it is that I want to be able to call "client.getClientName()" and always get *something* out of it if there are *any* client_name fields at all. So in this world if I take a client library that assumes en-us and it talks to a server that only looks for es-cl, there's a very real chance of the client name not getting set at all. I think that's a problem.

This is why I think the default field name (without the language tag) really should be required and should be left undefined as to what language and script it is. Essentially, "It's a UTF8 String, hope for the best". If you want something more specific and smart about localization, then you can support the language tags. If you just want to have a string to store and throw at the user, then you can just use the bare field name.

In other words, we take what we have now (which works for a non-internationalized case where everyone just assumes a common language/script), and we augment it with features that let it be smarter if you want it to be smarter. Make the simple case simple, make the complicated case possible.

 -- Justin

 

On 03/14/2013 10:47 AM, George Fletcher wrote:

As a simplifying option... why not just require human-readable fields to require a "script-tag". This way it is always explicit what language/locale the text is for. It then becomes the responsibility of the AS to return an appropriate response if there is not a direct match between a request and the data stored at the AS (and out of scope of the spec).

Thanks,
George

On 3/13/13 10:22 AM, Justin Richer wrote:

So with what little feedback I've gotten, I'm proposing to add text from the proposed webfinger and OIDC drafts for the hash-based localization of strings, with the following properties:

* All localized versions of fields are fully optional on both client and server
* If a localized version of a field is included, its bare-value (perhaps internationalized) field MUST be included
* All human-readable fields are eligible for this mechanism (including any uri's for user-facing web pages, which can be used to point to language-specific pages)
* Clients and servers can decide to use whatever language/script they want to for the bare-value field, and no assumptions can be made on either side about what that is

I think that with these constraints, we can add functionality to address Stephen's concerns without getting too complicated or putting too much burden of support.

 -- Justin

On 03/11/2013 06:52 PM, Nat Sakimura wrote:

Similar work is in progress at Webfinger. 

 

 

Paul is proposing the same syntax as Connect. 

2013/3/12 Richer, Justin P. <jricher@mitre.org>

It does presume a definition of "claim", which I suppose we could turn to "metadata field" for DynReg and its extensions to be appropriately limiting. But we also need a good definition of what a language-tag-less field means, and whether or not it's required if the other fields are present or not (which is something that Connect is trying to fix at the moment, as I recall from last week). 

 

So it turns into about a paragraph worth of text. Is that worth it? I'm not entirely convinced that it is, but I'm interested to hear what others think, particularly those who *aren't* tied into the OpenID Connect protocol so much. (I don't want to pick a solution just because it's familiar, if we need a solution at all.)

 

 -- Justin

 

On Mar 11, 2013, at 6:35 PM, Brian Campbell <bcampbell@pingidentity.com>

 wrote:



A fair question but what would need to be pulled in is really probably only a couple sentences (and reference) from http://openid.net/specs/openid-connect-messages-1_0-16.html#ClaimsLanguagesAndScripts (note the reference to 2.1.1.1.3 inside http://openid.net/specs/openid-connect-registration-1_0-15.html is broken)

 

On Mon, Mar 11, 2013 at 6:26 PM, Richer, Justin P. <jricher@mitre.org> wrote:

My concern with this is that OIDC can get away with defining this multi-language structure because it defines the mechanism once (in Messages) and applies it to all user-readable strings throughout the whole application protocol, of which there are several. Do we really want to pull in that whole structure and mechanism for one field in client registration? I really don't think it should be something that's defined completely inside of DynReg for a corner case for a single field, but I also doubt we want to normatively point to OIDC Messages for this solution either.

 

There are also other ways to do this: Webfinger [1] for instance uses JSON structures to give language tags to field values, and has a default mechanism:

 

   { "en_us": "my client", $B!D(B }

 

The fundamental question is  this: should a client be able to register multiple names (in different locales) with a single client_id, or should it get a different client_id for each display language set?

 

 -- Justin

 

 

On Mar 11, 2013, at 5:54 PM, John Bradley <ve7jtb@ve7jtb.com>

 wrote:



That is what I was thinking.   It would be up to the AS to determine what language and script to present based on the user preference.

 

While a large number of clients will be native and might be able to customize themselves for a single user during registration , we don't want to forget the web server clients that are multi user.

 

On 2013-03-11, at 10:49 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:



FWIW, the closely related OpenID Connect client registration draft does have some support for doing this, which could maybe be borrowed. See client_name in $B!x(B2 at http://openid.net/specs/openid-connect-registration-1_0-15.html#client-metadata and the examples.
 

   "client_name": "My Example",
   "client_name#ja-Jpan-JP":"$B%/%i%$%"%s%HL>(B",

 

 

On Mon, Mar 11, 2013 at 5:15 PM, Richer, Justin P. <jricher@mitre.org> wrote:

It was brought up at the in-person meeting today that we'll want to consider issues around internationalization and localization of human-readable fields like client_name in the client registration. Which is to say: if a client supports ten languages and wants to present itself in ten languages, should it have to register itself ten times with an AS?

At the moment, I'm of the opinion a client with ten languages could register itself ten times, or do something with the context in which it runs to determine which human-facing language to use. Keep in mind that in some cases (such as native clients), you'll be dynamically registering a client for each user, in effect. In other words, I personally think that this is a rathole that will cause more harm than good.

 -- Justin
_______________________________________________
OAuth mailing 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



 

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

 

 



--------------040606000004030407050602-- From Michael.Jones@microsoft.com Wed Mar 20 11:30: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 C73C011E80D1 for ; Wed, 20 Mar 2013 11:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.318 X-Spam-Level: X-Spam-Status: No, score=-2.318 tagged_above=-999 required=5 tests=[AWL=0.280, 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 G1VoVDkKkq1a for ; Wed, 20 Mar 2013 11:30:20 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0239.outbound.protection.outlook.com [207.46.163.239]) by ietfa.amsl.com (Postfix) with ESMTP id 80AD111E80A6 for ; Wed, 20 Mar 2013 11:30:20 -0700 (PDT) Received: from BY2FFO11FD008.protection.gbl (10.1.15.200) by BY2FFO11HUB002.protection.gbl (10.1.14.144) with Microsoft SMTP Server (TLS) id 15.0.641.9; Wed, 20 Mar 2013 18:30:17 +0000 Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD008.mail.protection.outlook.com (10.1.14.159) with Microsoft SMTP Server (TLS) id 15.0.641.9 via Frontend Transport; Wed, 20 Mar 2013 18:30:17 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.224]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.02.0318.003; Wed, 20 Mar 2013 18:30:03 +0000 From: Mike Jones To: Justin Richer Thread-Topic: [OAUTH-WG] Registration: Internationalization of Human-Readable names Thread-Index: AQHOH/ZlY5HOQV9nDkW4sYSziV3/rJilRaYAgAAEOYCAAAfTkIAJjagAgAABPneAAARIAIAACsBQ Date: Wed, 20 Mar 2013 18:30:03 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394367567185@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <1B4C0C9F-4B8E-4B2D-BAF7-665D3EBBE56C@ve7jtb.com> <51408B8B.9000800@mitre.org> <5141E2E6.9020701@aol.com> <5141E671.2050708@mitre.org> <4E1F6AAD24975D4BA5B16804296739436750F5E2@TK5EX14MBXC283.redmond.corp.microsoft.com>, <5149F092.7070902@mitre.org> <4E1F6AAD24975D4BA5B168042967394367565FEF@TK5EX14MBXC283.redmond.corp.microsoft.com> <5149F534.1040500@mitre.org> In-Reply-To: <5149F534.1040500@mitre.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.34] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394367567185TK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(164054002)(51444002)(52314002)(377424002)(377454001)(24454001)(189002)(479174001)(199002)(55885001)(49866001)(77982001)(512904001)(55846006)(76482001)(4396001)(5343645001)(20776003)(56816002)(51856001)(15202345001)(53806001)(5343635001)(5343655001)(47736001)(54316002)(59766001)(65816001)(33656001)(74662001)(16297215001)(79102001)(50986001)(63696002)(69226001)(44976002)(56776001)(47976001)(16236675001)(15395725002)(47446002)(46102001)(16406001)(74502001)(31966008)(66066001)(80022001)(54356001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB002; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 07915F544A Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readable names X-BeenThere: oauth@ietf.org X-Mailman-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, 20 Mar 2013 18:30:22 -0000 --_000_4E1F6AAD24975D4BA5B168042967394367567185TK5EX14MBXC283r_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable I suspect you only feel that leaving the locale information out is OK becau= se you (and I) live in a culture where it=1B$B!G=1B(Bs not needed to adequa= tely render characters. I=1B$B!G=1B(Bd actually defer on this decision to = Nat and others from Japan and China (and I think Korea?) where I believe th= at this information is essential. For what it=1B$B!G=1B(Bs worth, it=1B$B!G=1B(Bs more than just client_name.= It=1B$B!G=1B(Bs also tos_uri and policy_uri and potentially client_uri. Also, having thought about it for a few days, I=1B$B!G=1B(Bd change the pro= posed field name from registration_locale to default_registration_locale, s= o the meaning is clearer. Nat and others from Eastern cultures, what is your opinion on this? Thanks, -- Mike From: Justin Richer [mailto:jricher@mitre.org] Sent: Wednesday, March 20, 2013 10:43 AM To: Mike Jones Cc: George Fletcher; oauth@ietf.org WG Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readabl= e names I would say that claims without a language parameter, which I would make RE= QUIRED in the presence of other claims, would be treated as UTF8 strings wi= th no guarantee of what language, script, or other locale-specific informat= ion would be in there. It's a default string, and it's the best the client = can give if nothing more specific is useful. And servers would have to acce= pt this default string and do their best with it. A service provider can pu= blish their expected default locale information in either discovery or serv= ice documentation, and clients that want to tweak things for specific servi= ce providers can do that. The server can display it (because it's a string that'll always be there, i= f any version is there), but a server that doesn't do internationalized str= ings very well might not get its display correct. Since displayable text th= is is likely to be dumped into the middle of a webpage that has its own cha= racter encoding and other considerations anyway, so it's not guaranteed tha= t specifying a locale will always help here anyway. This is just for the di= splayable text, which right now is only the client_name field in OAuth and = OIDC: for URLs (the other "human-readable" field), it's a moot point, becau= se the server's just going to spit out the URL itself into an href of some = flavor. The server doesn't have to deal with any kind of encoding or text/s= cript issues here. As a server developer, it's just another thing that I *have* to track and d= eal with on the client model, even if I don't want to support the rest of t= he multi-language tags in my service. As a client developer, it's one more = thing that I *have* to specify when I send things to the server. I don't se= e how requiring its specification is going to really help interoperability,= and I can almost guarantee that implementations will just leave it off eve= n if marked REQUIRED (like how many, many documents in the wild that are su= pposed to have a character-encoding field of some type just leave it off). I think that it's a lot of work on both sides for just client_name. -- Justin On 03/20/2013 01:27 PM, Mike Jones wrote: How would you do this instead then? ________________________________ From: Justin Richer Sent: 3/20/2013 10:25 AM To: Mike Jones Cc: George Fletcher; oauth@ietf.org WG Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readabl= e names Personally, I think that this level of specificity is overkill. -- Justin On 03/14/2013 11:42 AM, Mike Jones wrote: I agree that having unadorned values likely simplifies things in many cases= , but if we do this, we should let the Client say what language/script it= =1B$B!G=1B(Bs using when providing human-readable strings or references to = them as registration parameters. For this purpose, I=1B$B!G=1B(Bd propose = that we have a parameter something like this one: registration_locale OPTIONAL or REQURED. Language and script used for human-readable values or = references to human-readable values that are supplied without language/scri= pt tags, represented as a BCP47[RFC5646] language tag value. This paramete= r is REQUIRED if any human-readable values or references to human-readable = are provided without language/script tags. -- Mike From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Justin Richer Sent: Thursday, March 14, 2013 8:02 AM To: George Fletcher Cc: oauth@ietf.org WG Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readabl= e names On the surface this does simplify things, but the issue I forsee with it is= that I want to be able to call "client.getClientName()" and always get *so= mething* out of it if there are *any* client_name fields at all. So in this= world if I take a client library that assumes en-us and it talks to a serv= er that only looks for es-cl, there's a very real chance of the client name= not getting set at all. I think that's a problem. This is why I think the default field name (without the language tag) reall= y should be required and should be left undefined as to what language and s= cript it is. Essentially, "It's a UTF8 String, hope for the best". If you w= ant something more specific and smart about localization, then you can supp= ort the language tags. If you just want to have a string to store and throw= at the user, then you can just use the bare field name. In other words, we take what we have now (which works for a non-internation= alized case where everyone just assumes a common language/script), and we a= ugment it with features that let it be smarter if you want it to be smarter= . Make the simple case simple, make the complicated case possible. -- Justin On 03/14/2013 10:47 AM, George Fletcher wrote: As a simplifying option... why not just require human-readable fields to re= quire a "script-tag". This way it is always explicit what language/locale t= he text is for. It then becomes the responsibility of the AS to return an a= ppropriate response if there is not a direct match between a request and th= e data stored at the AS (and out of scope of the spec). Thanks, George On 3/13/13 10:22 AM, Justin Richer wrote: So with what little feedback I've gotten, I'm proposing to add text from th= e proposed webfinger and OIDC drafts for the hash-based localization of str= ings, with the following properties: * All localized versions of fields are fully optional on both client and se= rver * If a localized version of a field is included, its bare-value (perhaps in= ternationalized) field MUST be included * All human-readable fields are eligible for this mechanism (including any = uri's for user-facing web pages, which can be used to point to language-spe= cific pages) * Clients and servers can decide to use whatever language/script they want = to for the bare-value field, and no assumptions can be made on either side = about what that is I think that with these constraints, we can add functionality to address St= ephen's concerns without getting too complicated or putting too much burden= of support. -- Justin On 03/11/2013 06:52 PM, Nat Sakimura wrote: Similar work is in progress at Webfinger. See: http://www.ietf.org/mail-archive/web/webfinger/current/msg00530.html Paul is proposing the same syntax as Connect. 2013/3/12 Richer, Justin P. > It does presume a definition of "claim", which I suppose we could turn to "= metadata field" for DynReg and its extensions to be appropriately limiting.= But we also need a good definition of what a language-tag-less field means= , and whether or not it's required if the other fields are present or not (= which is something that Connect is trying to fix at the moment, as I recall= from last week). So it turns into about a paragraph worth of text. Is that worth it? I'm not= entirely convinced that it is, but I'm interested to hear what others thin= k, particularly those who *aren't* tied into the OpenID Connect protocol so= much. (I don't want to pick a solution just because it's familiar, if we n= eed a solution at all.) -- Justin On Mar 11, 2013, at 6:35 PM, Brian Campbell > wrote: A fair question but what would need to be pulled in is really probably only= a couple sentences (and reference) from http://openid.net/specs/openid-con= nect-messages-1_0-16.html#ClaimsLanguagesAndScripts (note the reference to = 2.1.1.1.3 inside http://openid.net/specs/openid-connect-registration-1_0-15= .html is broken) On Mon, Mar 11, 2013 at 6:26 PM, Richer, Justin P. > wrote: My concern with this is that OIDC can get away with defining this multi-lan= guage structure because it defines the mechanism once (in Messages) and app= lies it to all user-readable strings throughout the whole application proto= col, of which there are several. Do we really want to pull in that whole st= ructure and mechanism for one field in client registration? I really don't = think it should be something that's defined completely inside of DynReg for= a corner case for a single field, but I also doubt we want to normatively = point to OIDC Messages for this solution either. There are also other ways to do this: Webfinger [1] for instance uses JSON = structures to give language tags to field values, and has a default mechani= sm: { "en_us": "my client", =1B$B!D=1B(B } The fundamental question is this: should a client be able to register mult= iple names (in different locales) with a single client_id, or should it get= a different client_id for each display language set? -- Justin [1] http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-11 On Mar 11, 2013, at 5:54 PM, John Bradley > wrote: That is what I was thinking. It would be up to the AS to determine what l= anguage and script to present based on the user preference. While a large number of clients will be native and might be able to customi= ze themselves for a single user during registration , we don't want to forg= et the web server clients that are multi user. On 2013-03-11, at 10:49 PM, Brian Campbell > wrote: FWIW, the closely related OpenID Connect client registration draft does hav= e some support for doing this, which could maybe be borrowed. See client_na= me in =1B$B!x=1B(B2 at http://openid.net/specs/openid-connect-registration-= 1_0-15.html#client-metadata and the examples. "client_name": "My Example", "client_name#ja-Jpan-JP":"=1B$B%/%i%$%"%s%HL>=1B(B", On Mon, Mar 11, 2013 at 5:15 PM, Richer, Justin P. > wrote: It was brought up at the in-person meeting today that we'll want to conside= r issues around internationalization and localization of human-readable fie= lds like client_name in the client registration. Which is to say: if a clie= nt supports ten languages and wants to present itself in ten languages, sho= uld it have to register itself ten times with an AS? At the moment, I'm of the opinion a client with ten languages could registe= r itself ten times, or do something with the context in which it runs to de= termine which human-facing language to use. Keep in mind that in some cases= (such as native clients), you'll be dynamically registering a client for e= ach user, in effect. In other words, I personally think that this is a rath= ole that will cause more harm than good. -- Justin _______________________________________________ OAuth mailing 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 -- Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_4E1F6AAD24975D4BA5B168042967394367567185TK5EX14MBXC283r_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable

I suspect you only feel t= hat leaving the locale information out is OK because you (and I) live in a = culture where it=1B$B!G=1B(Bs not needed to adequately render characters.&n= bsp; I=1B$B!G=1B(Bd actually defer on this decision to Nat and others from Japa= n and China (and I think Korea?) where I believe that this information is e= ssential.

 <= /p>

For what it=1B$B!G=1B(Bs = worth, it=1B$B!G=1B(Bs more than just client_name.  It=1B$B!G=1B(Bs al= so tos_uri and policy_uri and potentially client_uri.

 <= /p>

Also, having thought abou= t it for a few days, I=1B$B!G=1B(Bd change the proposed field name from reg= istration_locale to default_registration_locale, so the meaning is clearer.

 <= /p>

Nat and others from Easte= rn cultures, what is your opinion on this?

 <= /p>

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;     Thanks,

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

 <= /p>

From: Justin Richer [mailto:jricher@mitre.org]
Sent: Wednesday, March 20, 2013 10:43 AM
To: Mike Jones
Cc: George Fletcher; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-= Readable names

 

I would say that clai= ms without a language parameter, which I would make REQUIRED in the presenc= e of other claims, would be treated as UTF8 strings with no guarantee of wh= at language, script, or other locale-specific information would be in there. It's a default string, and it's the best th= e client can give if nothing more specific is useful. And servers would hav= e to accept this default string and do their best with it. A service provid= er can publish their expected default locale information in either discovery or service documentation, and clien= ts that want to tweak things for specific service providers can do that.
The server can display it (because it's a string that'll always be there, i= f any version is there), but a server that doesn't do internationalized str= ings very well might not get its display correct. Since displayable text th= is is likely to be dumped into the middle of a webpage that has its own character encoding and other consider= ations anyway, so it's not guaranteed that specifying a locale will always = help here anyway. This is just for the displayable text, which right now is= only the client_name field in OAuth and OIDC: for URLs (the other "human-readable" field), it's a mo= ot point, because the server's just going to spit out the URL itself into a= n href of some flavor. The server doesn't have to deal with any kind of enc= oding or text/script issues here.

As a server developer, it's just another thing that I *have* to track and d= eal with on the client model, even if I don't want to support the rest of t= he multi-language tags in my service. As a client developer, it's one more = thing that I *have* to specify when I send things to the server. I don't see how requiring its specification i= s going to really help interoperability, and I can almost guarantee that im= plementations will just leave it off even if marked REQUIRED (like how many= , many documents in the wild that are supposed to have a character-encoding field of some type just leave it= off).

I think that it's a lot of work on both sides for just client_name.

 -- Justin

On 03/20/2013 01:27 PM, Mike Jones wrote:=

How woul= d you do this instead then?

From: Justin Richer
Sent: 3/20/2013 10:25 AM
To: Mike Jones
Cc: George Fletcher; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-= Readable names

Personally, I think t= hat this level of specificity is overkill.

 -- Justin

On 03/14/2013 11:42 AM, Mike Jones wrote:=

I agree that having unado= rned values likely simplifies things in many cases, but if we do this, we s= hould let the Client say what language/script it=1B$B!G=1B(Bs using when providing human-readable strings or references to them as registratio= n parameters.  For this purpose, I=1B$B!G=1B(Bd propose that we have a= parameter something like this one:

 <= /p>

registration_locale

OPTIONAL or REQ= URED. Language and script used for human-readable values or references to h= uman-readable values that are supplied without language/script tags, represented as a BCP47[RFC5646] language tag value.  This param= eter is REQUIRED if any human-readable values or references to human-readab= le are provided without language/script tags.

 <= /p>

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

 <= /p>

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Justin Richer
Sent: Thursday, March 14, 2013 8:02 AM
To: George Fletcher
Cc: oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-= Readable names

 

On the surface this does simplify things, but the is= sue I forsee with it is that I want to be able to call "client.getClie= ntName()" and always get *something* out of it if there are *any* clie= nt_name fields at all. So in this world if I take a client library that assumes en-us and it talks to a server that onl= y looks for es-cl, there's a very real chance of the client name not gettin= g set at all. I think that's a problem.

This is why I think the default field name (without the language tag) reall= y should be required and should be left undefined as to what language and s= cript it is. Essentially, "It's a UTF8 String, hope for the best"= . If you want something more specific and smart about localization, then you can support the language tags. If you j= ust want to have a string to store and throw at the user, then you can just= use the bare field name.

In other words, we take what we have now (which works for a non-internation= alized case where everyone just assumes a common language/script), and we a= ugment it with features that let it be smarter if you want it to be smarter= . Make the simple case simple, make the complicated case possible.

 -- Justin

 

On 03/14/2013 10:47 AM, George Fletcher wrote:<= /o:p>

As a simplifying option= ... why not just require human-readable fields to require a "script-ta= g". This way it is always explicit what language/locale the text is for. It then becomes the responsibility of the AS to return an appropri= ate response if there is not a direct match between a request and the data = stored at the AS (and out of scope of the spec).

Thanks,
George

On 3/13/13 10:22 AM, Justin Richer wrote:=

So with what little f= eedback I've gotten, I'm proposing to add text from the proposed webfinger = and OIDC drafts for the hash-based localization of strings, with the follow= ing properties:

* All localized versions of fields are fully optional on both client and se= rver
* If a localized version of a field is included, its bare-value (perhaps in= ternationalized) field MUST be included
* All human-readable fields are eligible for this mechanism (including any = uri's for user-facing web pages, which can be used to point to language-spe= cific pages)
* Clients and servers can decide to use whatever language/script they want = to for the bare-value field, and no assumptions can be made on either side = about what that is

I think that with these constraints, we can add functionality to address St= ephen's concerns without getting too complicated or putting too much burden= of support.

 -- Justin

On 03/11/2013 06:52 PM, Nat Sakimura wrote:

Similar work is in progress at Webfinger. 

 

 

Paul is proposing the= same syntax as Connect. 

2013/3/12 Richer, Justin P. <jricher@mitre.org>

It does presume a definition of "claim", w= hich I suppose we could turn to "metadata field" for DynReg and i= ts extensions to be appropriately limiting. But we also need a good definit= ion of what a language-tag-less field means, and whether or not it's required if the other fields are present or not (which is some= thing that Connect is trying to fix at the moment, as I recall from last we= ek). 

 

So it turns into about a paragraph worth of text. Is= that worth it? I'm not entirely convinced that it is, but I'm interested t= o hear what others think, particularly those who *aren't* tied into the Ope= nID Connect protocol so much. (I don't want to pick a solution just because it's familiar, if we need a solution = at all.)

 

 -- Justin

 

On Mar 11, 2013, at 6:35 PM, Brian Campbell <bcampbell@pingi= dentity.com>

 wrote:

 

A fair question but what would need to be pulled in = is really probably only a couple sentences (and reference) from http://openid.net/specs/openid-connect-messages-1_0-16.html#ClaimsLanguages= AndScripts (note the reference to 2.1.1.1.3 inside http://openid.net/specs/openid-connect-registration-1_0-15.html is brok= en)

 

On Mon, Mar 11, 2013 at 6:26 PM, Richer, Justin P. &= lt;jricher@mitre.org= > wrote:

My concern with this is that OIDC can get away with = defining this multi-language structure because it defines the mechanism onc= e (in Messages) and applies it to all user-readable strings throughout the = whole application protocol, of which there are several. Do we really want to pull in that whole structure and m= echanism for one field in client registration? I really don't think it shou= ld be something that's defined completely inside of DynReg for a corner cas= e for a single field, but I also doubt we want to normatively point to OIDC Messages for this solution eith= er.

 

There are also other ways to do this: Webfinger [1] = for instance uses JSON structures to give language tags to field values, an= d has a default mechanism:

 

   { "en_us": "my client&qu= ot;, =1B$B!D=1B(B }

 

The fundamental question is  this: should a cli= ent be able to register multiple names (in different locales) with a single= client_id, or should it get a different client_id for each display languag= e set?

 

 -- Justin

 

 

On Mar 11, 2013, at 5:54 PM, John Bradley <ve7jtb@ve7jtb.com><= o:p>

 wrote:

 

That is what I was thinking.   It would be up t= o the AS to determine what language and script to present based on the user= preference.

 

While a large number of clients will be native and m= ight be able to customize themselves for a single user during registration = , we don't want to forget the web server clients that are multi user.<= /o:p>

 

On 2013-03-11, at 10:49 PM, Brian Campbell <bcampbell@pingid= entity.com> wrote:

 

FWIW, the closely related OpenID Connect client regi= stration draft does have some support for doing this, which could maybe be = borrowed. See client_name in =1B$B!x=1B(B2 at http://openid.net/specs/openid-connect-registration-1_0-15.html#client-meta= data and the examples.
 

   "client_name": "My Example",
   "client_name#ja-Jpan-JP":"=1B$B%/%i%$%"%s%HL>=1B(B",

 

 

On Mon, Mar 11, 2013 at 5:15 PM, Richer, Justin P. &= lt;jricher@mitre.org= > wrote:

It was brought up at the in-person meeting today tha= t we'll want to consider issues around internationalization and localizatio= n of human-readable fields like client_name in the client registration. Whi= ch is to say: if a client supports ten languages and wants to present itself in ten languages, should it have= to register itself ten times with an AS?

At the moment, I'm of the opinion a client with ten languages could registe= r itself ten times, or do something with the context in which it runs to de= termine which human-facing language to use. Keep in mind that in some cases= (such as native clients), you'll be dynamically registering a client for each user, in effect. In other wor= ds, I personally think that this is a rathole that will cause more harm tha= n good.

 -- Justin
_______________________________________________
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

 

 

 

 


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



 

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.= org/
@_nat_en




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

 

 

 

 

--_000_4E1F6AAD24975D4BA5B168042967394367567185TK5EX14MBXC283r_-- From jricher@mitre.org Wed Mar 20 12:12: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 8C99711E80F0 for ; Wed, 20 Mar 2013 12:12:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.798 X-Spam-Level: X-Spam-Status: No, score=-5.798 tagged_above=-999 required=5 tests=[AWL=0.800, 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 YjSbzXm23go2 for ; Wed, 20 Mar 2013 12:12:43 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8483A11E80F2 for ; Wed, 20 Mar 2013 12:12:42 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 28D8B1F0580; Wed, 20 Mar 2013 15:12:42 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 152231F0565; Wed, 20 Mar 2013 15:12:42 -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, 20 Mar 2013 15:12:41 -0400 Message-ID: <514A09D4.9070802@mitre.org> Date: Wed, 20 Mar 2013 15:11:16 -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: Mike Jones References: <1B4C0C9F-4B8E-4B2D-BAF7-665D3EBBE56C@ve7jtb.com> <51408B8B.9000800@mitre.org> <5141E2E6.9020701@aol.com> <5141E671.2050708@mitre.org> <4E1F6AAD24975D4BA5B16804296739436750F5E2@TK5EX14MBXC283.redmond.corp.microsoft.com>, <5149F092.7070902@mitre.org> <4E1F6AAD24975D4BA5B168042967394367565FEF@TK5EX14MBXC283.redmond.corp.microsoft.com> <5149F534.1040500@mitre.org> <4E1F6AAD24975D4BA5B168042967394367567185@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394367567185@TK5EX14MBXC283.redmond.corp.microsoft.com> Content-Type: multipart/alternative; boundary="------------090107070308070502080000" X-Originating-IP: [129.83.31.58] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readable names X-BeenThere: oauth@ietf.org X-Mailman-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, 20 Mar 2013 19:12:45 -0000 --------------090107070308070502080000 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit I agree that I'm seeing things from the single-language and single-encoding perspective here, and that's the use case I'm currently solving for with my development. I want to see this one remain simple, and I think we can do that without breaking other use cases. I would argue that multi-script languages (such as Chinese, Japanese, and others) are all cases where you're going to assume multiple languages, and the tags would be necessary for real use. So client and AS would both need to know how to deal with the multiple different tags, and smart ones would be able to effectively ignore the default field. The default, scriptless field could be for any one of the supported languages at the AS or Client, and it'd effectively be a backup, internationalized version, the one that you use when there's nothing else more specific to use. I guess what's getting me stuck on the explicit locale field is that I'm not seeing much value in requiring it over George's proposal of always using language tags on everything (which I also don't like, but for different reasons). Having the information doesn't mean that you can do anything intelligent with it, either, but I can see the argument that it makes doing something smart possible. But on the other hand, we already have a mechanism for doing something smart: using the explicit language tags directly. Also, note that the AS doesn't need to render any characters for tos_uri, policy_uri, and other _uri options, just for client_name. That's why I was making the distinction in my explanation below. You might want to give the user the right option, sure, but a served webpage has a much better chance of getting the locale right dynamically than an included string would have (approaches like user preferences, browser settings, etc. -- everything that's used today on web pages, in other words). This is why I think that the _uri claims are in a different category and we're talking almost exclusively about client_name here. I think, ultimately, that I need to think about this more. -- Justin On 03/20/2013 02:30 PM, Mike Jones wrote: > > I suspect you only feel that leaving the locale information out is OK > because you (and I) live in a culture where it$B!G(Bs not needed to > adequately render characters. I$B!G(Bd actually defer on this decision to > Nat and others from Japan and China (and I think Korea?) where I > believe that this information is essential. > > For what it$B!G(Bs worth, it$B!G(Bs more than just client_name. It$B!G(Bs also > tos_uri and policy_uri and potentially client_uri. > > Also, having thought about it for a few days, I$B!G(Bd change the proposed > field name from registration_locale to default_registration_locale, so > the meaning is clearer. > > Nat and others from Eastern cultures, what is your opinion on this? > > Thanks, > > -- Mike > > *From:*Justin Richer [mailto:jricher@mitre.org] > *Sent:* Wednesday, March 20, 2013 10:43 AM > *To:* Mike Jones > *Cc:* George Fletcher; oauth@ietf.org WG > *Subject:* Re: [OAUTH-WG] Registration: Internationalization of > Human-Readable names > > I would say that claims without a language parameter, which I would > make REQUIRED in the presence of other claims, would be treated as > UTF8 strings with no guarantee of what language, script, or other > locale-specific information would be in there. It's a default string, > and it's the best the client can give if nothing more specific is > useful. And servers would have to accept this default string and do > their best with it. A service provider can publish their expected > default locale information in either discovery or service > documentation, and clients that want to tweak things for specific > service providers can do that. > > The server can display it (because it's a string that'll always be > there, if any version is there), but a server that doesn't do > internationalized strings very well might not get its display correct. > Since displayable text this is likely to be dumped into the middle of > a webpage that has its own character encoding and other considerations > anyway, so it's not guaranteed that specifying a locale will always > help here anyway. This is just for the displayable text, which right > now is only the client_name field in OAuth and OIDC: for URLs (the > other "human-readable" field), it's a moot point, because the server's > just going to spit out the URL itself into an href of some flavor. The > server doesn't have to deal with any kind of encoding or text/script > issues here. > > As a server developer, it's just another thing that I *have* to track > and deal with on the client model, even if I don't want to support the > rest of the multi-language tags in my service. As a client developer, > it's one more thing that I *have* to specify when I send things to the > server. I don't see how requiring its specification is going to really > help interoperability, and I can almost guarantee that implementations > will just leave it off even if marked REQUIRED (like how many, many > documents in the wild that are supposed to have a character-encoding > field of some type just leave it off). > > I think that it's a lot of work on both sides for just client_name. > > -- Justin > > On 03/20/2013 01:27 PM, Mike Jones wrote: > > How would you do this instead then? > > ------------------------------------------------------------------------ > > *From: *Justin Richer > *Sent: *3/20/2013 10:25 AM > *To: *Mike Jones > *Cc: *George Fletcher; oauth@ietf.org WG > *Subject: *Re: [OAUTH-WG] Registration: Internationalization of > Human-Readable names > > Personally, I think that this level of specificity is overkill. > > -- Justin > > On 03/14/2013 11:42 AM, Mike Jones wrote: > > I agree that having unadorned values likely simplifies things > in many cases, but if we do this, we should let the Client say > what language/script it$B!G(Bs using when providing human-readable > strings or references to them as registration parameters. For > this purpose, I$B!G(Bd propose that we have a parameter something > like this one: > > registration_locale > > OPTIONAL or REQURED. Language and script used for > human-readable values or references to human-readable values > that are supplied without language/script tags, represented as > a BCP47[RFC5646] language tag value. This parameter is > REQUIRED if any human-readable values or references to > human-readable are provided without language/script tags. > > -- Mike > > *From:*oauth-bounces@ietf.org > [mailto:oauth-bounces@ietf.org] *On Behalf Of *Justin Richer > *Sent:* Thursday, March 14, 2013 8:02 AM > *To:* George Fletcher > *Cc:* oauth@ietf.org WG > *Subject:* Re: [OAUTH-WG] Registration: Internationalization > of Human-Readable names > > On the surface this does simplify things, but the issue I > forsee with it is that I want to be able to call > "client.getClientName()" and always get *something* out of it > if there are *any* client_name fields at all. So in this world > if I take a client library that assumes en-us and it talks to > a server that only looks for es-cl, there's a very real chance > of the client name not getting set at all. I think that's a > problem. > > This is why I think the default field name (without the > language tag) really should be required and should be left > undefined as to what language and script it is. Essentially, > "It's a UTF8 String, hope for the best". If you want something > more specific and smart about localization, then you can > support the language tags. If you just want to have a string > to store and throw at the user, then you can just use the bare > field name. > > In other words, we take what we have now (which works for a > non-internationalized case where everyone just assumes a > common language/script), and we augment it with features that > let it be smarter if you want it to be smarter. Make the > simple case simple, make the complicated case possible. > > -- Justin > > On 03/14/2013 10:47 AM, George Fletcher wrote: > > As a simplifying option... why not just require > human-readable fields to require a "script-tag". This way > it is always explicit what language/locale the text is > for. It then becomes the responsibility of the AS to > return an appropriate response if there is not a direct > match between a request and the data stored at the AS (and > out of scope of the spec). > > Thanks, > George > > On 3/13/13 10:22 AM, Justin Richer wrote: > > So with what little feedback I've gotten, I'm > proposing to add text from the proposed webfinger and > OIDC drafts for the hash-based localization of > strings, with the following properties: > > * All localized versions of fields are fully optional > on both client and server > * If a localized version of a field is included, its > bare-value (perhaps internationalized) field MUST be > included > * All human-readable fields are eligible for this > mechanism (including any uri's for user-facing web > pages, which can be used to point to language-specific > pages) > * Clients and servers can decide to use whatever > language/script they want to for the bare-value field, > and no assumptions can be made on either side about > what that is > > I think that with these constraints, we can add > functionality to address Stephen's concerns without > getting too complicated or putting too much burden of > support. > > -- Justin > > On 03/11/2013 06:52 PM, Nat Sakimura wrote: > > Similar work is in progress at Webfinger. > > See: > http://www.ietf.org/mail-archive/web/webfinger/current/msg00530.html > > Paul is proposing the same syntax as Connect. > > 2013/3/12 Richer, Justin P. > > > It does presume a definition of "claim", which I > suppose we could turn to "metadata field" for > DynReg and its extensions to be appropriately > limiting. But we also need a good definition of > what a language-tag-less field means, and whether > or not it's required if the other fields are > present or not (which is something that Connect is > trying to fix at the moment, as I recall from last > week). > > So it turns into about a paragraph worth of text. > Is that worth it? I'm not entirely convinced that > it is, but I'm interested to hear what others > think, particularly those who *aren't* tied into > the OpenID Connect protocol so much. (I don't want > to pick a solution just because it's familiar, if > we need a solution at all.) > > -- Justin > > On Mar 11, 2013, at 6:35 PM, Brian Campbell > > > > wrote: > > A fair question but what would need to be pulled > in is really probably only a couple sentences (and > reference) from > http://openid.net/specs/openid-connect-messages-1_0-16.html#ClaimsLanguagesAndScripts > (note the reference to 2.1.1.1.3 inside > http://openid.net/specs/openid-connect-registration-1_0-15.html > is broken) > > On Mon, Mar 11, 2013 at 6:26 PM, Richer, Justin P. > > wrote: > > My concern with this is that OIDC can get away > with defining this multi-language structure > because it defines the mechanism once (in > Messages) and applies it to all user-readable > strings throughout the whole application protocol, > of which there are several. Do we really want to > pull in that whole structure and mechanism for one > field in client registration? I really don't think > it should be something that's defined completely > inside of DynReg for a corner case for a single > field, but I also doubt we want to normatively > point to OIDC Messages for this solution either. > > There are also other ways to do this: Webfinger > [1] for instance uses JSON structures to give > language tags to field values, and has a default > mechanism: > > { "en_us": "my client", $B!D(B } > > The fundamental question is this: should a client > be able to register multiple names (in different > locales) with a single client_id, or should it get > a different client_id for each display language set? > > -- Justin > > [1] > http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-11 > > On Mar 11, 2013, at 5:54 PM, John Bradley > > > > wrote: > > That is what I was thinking. It would be up to the > AS to determine what language and script to > present based on the user preference. > > While a large number of clients will be native and > might be able to customize themselves for a single > user during registration , we don't want to forget > the web server clients that are multi user. > > On 2013-03-11, at 10:49 PM, Brian Campbell > > wrote: > > FWIW, the closely related OpenID Connect client > registration draft does have some support for > doing this, which could maybe be borrowed. See > client_name in $B!x(B2 at > http://openid.net/specs/openid-connect-registration-1_0-15.html#client-metadata > and the examples. > > "client_name": "My Example", > > "client_name#ja-Jpan-JP":"$B%/%i%$%"%s%HL>(B", > > On Mon, Mar 11, 2013 at 5:15 PM, Richer, Justin P. > > wrote: > > It was brought up at the in-person meeting today > that we'll want to consider issues around > internationalization and localization of > human-readable fields like client_name in the > client registration. Which is to say: if a client > supports ten languages and wants to present itself > in ten languages, should it have to register > itself ten times with an AS? > > At the moment, I'm of the opinion a client with > ten languages could register itself ten times, or > do something with the context in which it runs to > determine which human-facing language to use. Keep > in mind that in some cases (such as native > clients), you'll be dynamically registering a > client for each user, in effect. In other words, I > personally think that this is a rathole that will > cause more harm than good. > > -- Justin > _______________________________________________ > OAuth mailing 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 > > > > -- > 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 > --------------090107070308070502080000 Content-Type: text/html; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit I agree that I'm seeing things from the single-language and single-encoding perspective here, and that's the use case I'm currently solving for with my development. I want to see this one remain simple, and I think we can do that without breaking other use cases.

I would argue that multi-script languages (such as Chinese, Japanese, and others) are all cases where you're going to assume multiple languages, and the tags would be necessary for real use. So client and AS would both need to know how to deal with the multiple different tags, and smart ones would be able to effectively ignore the default field. The default, scriptless field could be for any one of the supported languages at the AS or Client, and it'd effectively be a backup, internationalized version, the one that you use when there's nothing else more specific to use.

I guess what's getting me stuck on the explicit locale field is that I'm not seeing much value in requiring it over George's proposal of always using language tags on everything (which I also don't like, but for different reasons). Having the information doesn't mean that you can do anything intelligent with it, either, but I can see the argument that it makes doing something smart possible. But on the other hand, we already have a mechanism for doing something smart: using the explicit language tags directly.

Also, note that the AS doesn't need to render any characters for tos_uri, policy_uri, and other _uri options, just for client_name. That's why I was making the distinction in my explanation below. You might want to give the user the right option, sure, but a served webpage has a much better chance of getting the locale right dynamically than an included string would have (approaches like user preferences, browser settings, etc. -- everything that's used today on web pages, in other words). This is why I think that the _uri claims are in a different category and we're talking almost exclusively about client_name here.

I think, ultimately, that I need to think about this more.

  -- Justin

On 03/20/2013 02:30 PM, Mike Jones wrote:

I suspect you only feel that leaving the locale information out is OK because you (and I) live in a culture where it$B!G(Bs not needed to adequately render characters.  I$B!G(Bd actually defer on this decision to Nat and others from Japan and China (and I think Korea?) where I believe that this information is essential.

 

For what it$B!G(Bs worth, it$B!G(Bs more than just client_name.  It$B!G(Bs also tos_uri and policy_uri and potentially client_uri.

 

Also, having thought about it for a few days, I$B!G(Bd change the proposed field name from registration_locale to default_registration_locale, so the meaning is clearer.

 

Nat and others from Eastern cultures, what is your opinion on this?

 

                                                            Thanks,

                                                            -- Mike

 

From: Justin Richer [mailto:jricher@mitre.org]
Sent: Wednesday, March 20, 2013 10:43 AM
To: Mike Jones
Cc: George Fletcher; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readable names

 

I would say that claims without a language parameter, which I would make REQUIRED in the presence of other claims, would be treated as UTF8 strings with no guarantee of what language, script, or other locale-specific information would be in there. It's a default string, and it's the best the client can give if nothing more specific is useful. And servers would have to accept this default string and do their best with it. A service provider can publish their expected default locale information in either discovery or service documentation, and clients that want to tweak things for specific service providers can do that.

The server can display it (because it's a string that'll always be there, if any version is there), but a server that doesn't do internationalized strings very well might not get its display correct. Since displayable text this is likely to be dumped into the middle of a webpage that has its own character encoding and other considerations anyway, so it's not guaranteed that specifying a locale will always help here anyway. This is just for the displayable text, which right now is only the client_name field in OAuth and OIDC: for URLs (the other "human-readable" field), it's a moot point, because the server's just going to spit out the URL itself into an href of some flavor. The server doesn't have to deal with any kind of encoding or text/script issues here.

As a server developer, it's just another thing that I *have* to track and deal with on the client model, even if I don't want to support the rest of the multi-language tags in my service. As a client developer, it's one more thing that I *have* to specify when I send things to the server. I don't see how requiring its specification is going to really help interoperability, and I can almost guarantee that implementations will just leave it off even if marked REQUIRED (like how many, many documents in the wild that are supposed to have a character-encoding field of some type just leave it off).

I think that it's a lot of work on both sides for just client_name.

 -- Justin

On 03/20/2013 01:27 PM, Mike Jones wrote:

How would you do this instead then?

From: Justin Richer
Sent: 3/20/2013 10:25 AM
To: Mike Jones
Cc: George Fletcher; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readable names

Personally, I think that this level of specificity is overkill.

 -- Justin

On 03/14/2013 11:42 AM, Mike Jones wrote:

I agree that having unadorned values likely simplifies things in many cases, but if we do this, we should let the Client say what language/script it$B!G(Bs using when providing human-readable strings or references to them as registration parameters.  For this purpose, I$B!G(Bd propose that we have a parameter something like this one:

 

registration_locale

OPTIONAL or REQURED. Language and script used for human-readable values or references to human-readable values that are supplied without language/script tags, represented as a BCP47[RFC5646] language tag value.  This parameter is REQUIRED if any human-readable values or references to human-readable are provided without language/script tags.

 

                                                            -- Mike

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Justin Richer
Sent: Thursday, March 14, 2013 8:02 AM
To: George Fletcher
Cc: oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readable names

 

On the surface this does simplify things, but the issue I forsee with it is that I want to be able to call "client.getClientName()" and always get *something* out of it if there are *any* client_name fields at all. So in this world if I take a client library that assumes en-us and it talks to a server that only looks for es-cl, there's a very real chance of the client name not getting set at all. I think that's a problem.

This is why I think the default field name (without the language tag) really should be required and should be left undefined as to what language and script it is. Essentially, "It's a UTF8 String, hope for the best". If you want something more specific and smart about localization, then you can support the language tags. If you just want to have a string to store and throw at the user, then you can just use the bare field name.

In other words, we take what we have now (which works for a non-internationalized case where everyone just assumes a common language/script), and we augment it with features that let it be smarter if you want it to be smarter. Make the simple case simple, make the complicated case possible.

 -- Justin

 

On 03/14/2013 10:47 AM, George Fletcher wrote:

As a simplifying option... why not just require human-readable fields to require a "script-tag". This way it is always explicit what language/locale the text is for. It then becomes the responsibility of the AS to return an appropriate response if there is not a direct match between a request and the data stored at the AS (and out of scope of the spec).

Thanks,
George

On 3/13/13 10:22 AM, Justin Richer wrote:

So with what little feedback I've gotten, I'm proposing to add text from the proposed webfinger and OIDC drafts for the hash-based localization of strings, with the following properties:

* All localized versions of fields are fully optional on both client and server
* If a localized version of a field is included, its bare-value (perhaps internationalized) field MUST be included
* All human-readable fields are eligible for this mechanism (including any uri's for user-facing web pages, which can be used to point to language-specific pages)
* Clients and servers can decide to use whatever language/script they want to for the bare-value field, and no assumptions can be made on either side about what that is

I think that with these constraints, we can add functionality to address Stephen's concerns without getting too complicated or putting too much burden of support.

 -- Justin

On 03/11/2013 06:52 PM, Nat Sakimura wrote:

Similar work is in progress at Webfinger. 

 

 

Paul is proposing the same syntax as Connect. 

2013/3/12 Richer, Justin P. <jricher@mitre.org>

It does presume a definition of "claim", which I suppose we could turn to "metadata field" for DynReg and its extensions to be appropriately limiting. But we also need a good definition of what a language-tag-less field means, and whether or not it's required if the other fields are present or not (which is something that Connect is trying to fix at the moment, as I recall from last week). 

 

So it turns into about a paragraph worth of text. Is that worth it? I'm not entirely convinced that it is, but I'm interested to hear what others think, particularly those who *aren't* tied into the OpenID Connect protocol so much. (I don't want to pick a solution just because it's familiar, if we need a solution at all.)

 

 -- Justin

 

On Mar 11, 2013, at 6:35 PM, Brian Campbell <bcampbell@pingidentity.com>

 wrote:

 

A fair question but what would need to be pulled in is really probably only a couple sentences (and reference) from http://openid.net/specs/openid-connect-messages-1_0-16.html#ClaimsLanguagesAndScripts (note the reference to 2.1.1.1.3 inside http://openid.net/specs/openid-connect-registration-1_0-15.html is broken)

 

On Mon, Mar 11, 2013 at 6:26 PM, Richer, Justin P. <jricher@mitre.org> wrote:

My concern with this is that OIDC can get away with defining this multi-language structure because it defines the mechanism once (in Messages) and applies it to all user-readable strings throughout the whole application protocol, of which there are several. Do we really want to pull in that whole structure and mechanism for one field in client registration? I really don't think it should be something that's defined completely inside of DynReg for a corner case for a single field, but I also doubt we want to normatively point to OIDC Messages for this solution either.

 

There are also other ways to do this: Webfinger [1] for instance uses JSON structures to give language tags to field values, and has a default mechanism:

 

   { "en_us": "my client", $B!D(B }

 

The fundamental question is  this: should a client be able to register multiple names (in different locales) with a single client_id, or should it get a different client_id for each display language set?

 

 -- Justin

 

 

On Mar 11, 2013, at 5:54 PM, John Bradley <ve7jtb@ve7jtb.com>

 wrote:

 

That is what I was thinking.   It would be up to the AS to determine what language and script to present based on the user preference.

 

While a large number of clients will be native and might be able to customize themselves for a single user during registration , we don't want to forget the web server clients that are multi user.

 

On 2013-03-11, at 10:49 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:

 

FWIW, the closely related OpenID Connect client registration draft does have some support for doing this, which could maybe be borrowed. See client_name in $B!x(B2 at http://openid.net/specs/openid-connect-registration-1_0-15.html#client-metadata and the examples.
 

   "client_name": "My Example",
   "client_name#ja-Jpan-JP":"$B%/%i%$%"%s%HL>(B",

 

 

On Mon, Mar 11, 2013 at 5:15 PM, Richer, Justin P. <jricher@mitre.org> wrote:

It was brought up at the in-person meeting today that we'll want to consider issues around internationalization and localization of human-readable fields like client_name in the client registration. Which is to say: if a client supports ten languages and wants to present itself in ten languages, should it have to register itself ten times with an AS?

At the moment, I'm of the opinion a client with ten languages could register itself ten times, or do something with the context in which it runs to determine which human-facing language to use. Keep in mind that in some cases (such as native clients), you'll be dynamically registering a client for each user, in effect. In other words, I personally think that this is a rathole that will cause more harm than good.

 -- Justin
_______________________________________________
OAuth mailing 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



 

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

 

 

 

 


--------------090107070308070502080000-- From Michael.Jones@microsoft.com Wed Mar 20 13:08: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 7102111E8122 for ; Wed, 20 Mar 2013 13:08:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[AWL=0.266, 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 pDs0Cmgme6am for ; Wed, 20 Mar 2013 13:08:18 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0208.outbound.protection.outlook.com [207.46.163.208]) by ietfa.amsl.com (Postfix) with ESMTP id 76B7111E8121 for ; Wed, 20 Mar 2013 13:08:17 -0700 (PDT) Received: from BY2FFO11FD005.protection.gbl (10.1.15.200) by BY2FFO11HUB037.protection.gbl (10.1.14.120) with Microsoft SMTP Server (TLS) id 15.0.641.9; Wed, 20 Mar 2013 20:02:43 +0000 Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD005.mail.protection.outlook.com (10.1.14.126) with Microsoft SMTP Server (TLS) id 15.0.641.9 via Frontend Transport; Wed, 20 Mar 2013 20:02:43 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.224]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.02.0318.003; Wed, 20 Mar 2013 20:02:21 +0000 From: Mike Jones To: Justin Richer Thread-Topic: [OAUTH-WG] Registration: Internationalization of Human-Readable names Thread-Index: AQHOH/ZlY5HOQV9nDkW4sYSziV3/rJilRaYAgAAEOYCAAAfTkIAJjagAgAABPneAAARIAIAACsBQgAAN1wCAAAypUA== Date: Wed, 20 Mar 2013 20:02:20 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436756757F@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <1B4C0C9F-4B8E-4B2D-BAF7-665D3EBBE56C@ve7jtb.com> <51408B8B.9000800@mitre.org> <5141E2E6.9020701@aol.com> <5141E671.2050708@mitre.org> <4E1F6AAD24975D4BA5B16804296739436750F5E2@TK5EX14MBXC283.redmond.corp.microsoft.com>, <5149F092.7070902@mitre.org> <4E1F6AAD24975D4BA5B168042967394367565FEF@TK5EX14MBXC283.redmond.corp.microsoft.com> <5149F534.1040500@mitre.org> <4E1F6AAD24975D4BA5B168042967394367567185@TK5EX14MBXC283.redmond.corp.microsoft.com> <514A09D4.9070802@mitre.org> In-Reply-To: <514A09D4.9070802@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_4E1F6AAD24975D4BA5B16804296739436756757FTK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(24454001)(55885001)(199002)(189002)(164054002)(479174001)(52314002)(51444002)(377454001)(377424002)(561944001)(56776001)(77982001)(16406001)(31966008)(53806001)(15395725002)(46102001)(59766001)(76482001)(47976001)(15202345001)(80022001)(56816002)(55846006)(74662001)(5343645001)(69226001)(54356001)(54316002)(51856001)(79102001)(20776003)(5343635001)(65816001)(5343655001)(47446002)(50986001)(66066001)(63696002)(16236675001)(16297215001)(33656001)(49866001)(512904001)(4396001)(74502001)(44976002)(47736001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB037; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 07915F544A Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readable names X-BeenThere: oauth@ietf.org X-Mailman-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, 20 Mar 2013 20:08:22 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436756757FTK5EX14MBXC283r_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable The value of the explicit locale field is that it provides locale informati= on to servers that want to use it without having to use any explicit langua= ge tags in the single-locale case. I guess I don=1B$B!G=1B(Bt see the comp= lication here. With this solution, in the single-locale case, all fields w= ould be passed without language tags (simple for both client and server), a= nd a locale would be provided by the client (simple). The server would sto= re the locale but otherwise could ignore it if it knew that it was in a sin= gle-locale deployment. I just don=1B$B!G=1B(Bt see it as being very hard for a registration reques= t to include =1B$B!H=1B(Bdefault_registration_locale=1B$B!I=1B(B:=1B$B!H=1B= (Ben=1B$B!I=1B(B and for the server to store it and return that value, but = otherwise ignore it, if that reflects the realities of your particular depl= oyment. :) = -- Mike From: Justin Richer [mailto:jricher@mitre.org] Sent: Wednesday, March 20, 2013 12:11 PM To: Mike Jones Cc: George Fletcher; oauth@ietf.org WG Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readabl= e names I agree that I'm seeing things from the single-language and single-encoding= perspective here, and that's the use case I'm currently solving for with m= y development. I want to see this one remain simple, and I think we can do = that without breaking other use cases. I would argue that multi-script languages (such as Chinese, Japanese, and o= thers) are all cases where you're going to assume multiple languages, and t= he tags would be necessary for real use. So client and AS would both need t= o know how to deal with the multiple different tags, and smart ones would b= e able to effectively ignore the default field. The default, scriptless fie= ld could be for any one of the supported languages at the AS or Client, and= it'd effectively be a backup, internationalized version, the one that you = use when there's nothing else more specific to use. I guess what's getting me stuck on the explicit locale field is that I'm no= t seeing much value in requiring it over George's proposal of always using = language tags on everything (which I also don't like, but for different rea= sons). Having the information doesn't mean that you can do anything intelli= gent with it, either, but I can see the argument that it makes doing someth= ing smart possible. But on the other hand, we already have a mechanism for = doing something smart: using the explicit language tags directly. Also, note that the AS doesn't need to render any characters for tos_uri, p= olicy_uri, and other _uri options, just for client_name. That's why I was m= aking the distinction in my explanation below. You might want to give the u= ser the right option, sure, but a served webpage has a much better chance o= f getting the locale right dynamically than an included string would have (= approaches like user preferences, browser settings, etc. -- everything that= 's used today on web pages, in other words). This is why I think that the _= uri claims are in a different category and we're talking almost exclusively= about client_name here. I think, ultimately, that I need to think about this more. -- Justin On 03/20/2013 02:30 PM, Mike Jones wrote: I suspect you only feel that leaving the locale information out is OK becau= se you (and I) live in a culture where it=1B$B!G=1B(Bs not needed to adequa= tely render characters. I=1B$B!G=1B(Bd actually defer on this decision to = Nat and others from Japan and China (and I think Korea?) where I believe th= at this information is essential. For what it=1B$B!G=1B(Bs worth, it=1B$B!G=1B(Bs more than just client_name.= It=1B$B!G=1B(Bs also tos_uri and policy_uri and potentially client_uri. Also, having thought about it for a few days, I=1B$B!G=1B(Bd change the pro= posed field name from registration_locale to default_registration_locale, s= o the meaning is clearer. Nat and others from Eastern cultures, what is your opinion on this? Thanks, -- Mike From: Justin Richer [mailto:jricher@mitre.org] Sent: Wednesday, March 20, 2013 10:43 AM To: Mike Jones Cc: George Fletcher; oauth@ietf.org WG Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readabl= e names I would say that claims without a language parameter, which I would make RE= QUIRED in the presence of other claims, would be treated as UTF8 strings wi= th no guarantee of what language, script, or other locale-specific informat= ion would be in there. It's a default string, and it's the best the client = can give if nothing more specific is useful. And servers would have to acce= pt this default string and do their best with it. A service provider can pu= blish their expected default locale information in either discovery or serv= ice documentation, and clients that want to tweak things for specific servi= ce providers can do that. The server can display it (because it's a string that'll always be there, i= f any version is there), but a server that doesn't do internationalized str= ings very well might not get its display correct. Since displayable text th= is is likely to be dumped into the middle of a webpage that has its own cha= racter encoding and other considerations anyway, so it's not guaranteed tha= t specifying a locale will always help here anyway. This is just for the di= splayable text, which right now is only the client_name field in OAuth and = OIDC: for URLs (the other "human-readable" field), it's a moot point, becau= se the server's just going to spit out the URL itself into an href of some = flavor. The server doesn't have to deal with any kind of encoding or text/s= cript issues here. As a server developer, it's just another thing that I *have* to track and d= eal with on the client model, even if I don't want to support the rest of t= he multi-language tags in my service. As a client developer, it's one more = thing that I *have* to specify when I send things to the server. I don't se= e how requiring its specification is going to really help interoperability,= and I can almost guarantee that implementations will just leave it off eve= n if marked REQUIRED (like how many, many documents in the wild that are su= pposed to have a character-encoding field of some type just leave it off). I think that it's a lot of work on both sides for just client_name. -- Justin On 03/20/2013 01:27 PM, Mike Jones wrote: How would you do this instead then? ________________________________ From: Justin Richer Sent: 3/20/2013 10:25 AM To: Mike Jones Cc: George Fletcher; oauth@ietf.org WG Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readabl= e names Personally, I think that this level of specificity is overkill. -- Justin On 03/14/2013 11:42 AM, Mike Jones wrote: I agree that having unadorned values likely simplifies things in many cases= , but if we do this, we should let the Client say what language/script it= =1B$B!G=1B(Bs using when providing human-readable strings or references to = them as registration parameters. For this purpose, I=1B$B!G=1B(Bd propose = that we have a parameter something like this one: registration_locale OPTIONAL or REQURED. Language and script used for human-readable values or = references to human-readable values that are supplied without language/scri= pt tags, represented as a BCP47[RFC5646] language tag value. This paramete= r is REQUIRED if any human-readable values or references to human-readable = are provided without language/script tags. -- Mike From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Justin Richer Sent: Thursday, March 14, 2013 8:02 AM To: George Fletcher Cc: oauth@ietf.org WG Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readabl= e names On the surface this does simplify things, but the issue I forsee with it is= that I want to be able to call "client.getClientName()" and always get *so= mething* out of it if there are *any* client_name fields at all. So in this= world if I take a client library that assumes en-us and it talks to a serv= er that only looks for es-cl, there's a very real chance of the client name= not getting set at all. I think that's a problem. This is why I think the default field name (without the language tag) reall= y should be required and should be left undefined as to what language and s= cript it is. Essentially, "It's a UTF8 String, hope for the best". If you w= ant something more specific and smart about localization, then you can supp= ort the language tags. If you just want to have a string to store and throw= at the user, then you can just use the bare field name. In other words, we take what we have now (which works for a non-internation= alized case where everyone just assumes a common language/script), and we a= ugment it with features that let it be smarter if you want it to be smarter= . Make the simple case simple, make the complicated case possible. -- Justin On 03/14/2013 10:47 AM, George Fletcher wrote: As a simplifying option... why not just require human-readable fields to re= quire a "script-tag". This way it is always explicit what language/locale t= he text is for. It then becomes the responsibility of the AS to return an a= ppropriate response if there is not a direct match between a request and th= e data stored at the AS (and out of scope of the spec). Thanks, George On 3/13/13 10:22 AM, Justin Richer wrote: So with what little feedback I've gotten, I'm proposing to add text from th= e proposed webfinger and OIDC drafts for the hash-based localization of str= ings, with the following properties: * All localized versions of fields are fully optional on both client and se= rver * If a localized version of a field is included, its bare-value (perhaps in= ternationalized) field MUST be included * All human-readable fields are eligible for this mechanism (including any = uri's for user-facing web pages, which can be used to point to language-spe= cific pages) * Clients and servers can decide to use whatever language/script they want = to for the bare-value field, and no assumptions can be made on either side = about what that is I think that with these constraints, we can add functionality to address St= ephen's concerns without getting too complicated or putting too much burden= of support. -- Justin On 03/11/2013 06:52 PM, Nat Sakimura wrote: Similar work is in progress at Webfinger. See: http://www.ietf.org/mail-archive/web/webfinger/current/msg00530.html Paul is proposing the same syntax as Connect. 2013/3/12 Richer, Justin P. > It does presume a definition of "claim", which I suppose we could turn to "= metadata field" for DynReg and its extensions to be appropriately limiting.= But we also need a good definition of what a language-tag-less field means= , and whether or not it's required if the other fields are present or not (= which is something that Connect is trying to fix at the moment, as I recall= from last week). So it turns into about a paragraph worth of text. Is that worth it? I'm not= entirely convinced that it is, but I'm interested to hear what others thin= k, particularly those who *aren't* tied into the OpenID Connect protocol so= much. (I don't want to pick a solution just because it's familiar, if we n= eed a solution at all.) -- Justin On Mar 11, 2013, at 6:35 PM, Brian Campbell > wrote: A fair question but what would need to be pulled in is really probably only= a couple sentences (and reference) from http://openid.net/specs/openid-con= nect-messages-1_0-16.html#ClaimsLanguagesAndScripts (note the reference to = 2.1.1.1.3 inside http://openid.net/specs/openid-connect-registration-1_0-15= .html is broken) On Mon, Mar 11, 2013 at 6:26 PM, Richer, Justin P. > wrote: My concern with this is that OIDC can get away with defining this multi-lan= guage structure because it defines the mechanism once (in Messages) and app= lies it to all user-readable strings throughout the whole application proto= col, of which there are several. Do we really want to pull in that whole st= ructure and mechanism for one field in client registration? I really don't = think it should be something that's defined completely inside of DynReg for= a corner case for a single field, but I also doubt we want to normatively = point to OIDC Messages for this solution either. There are also other ways to do this: Webfinger [1] for instance uses JSON = structures to give language tags to field values, and has a default mechani= sm: { "en_us": "my client", =1B$B!D=1B(B } The fundamental question is this: should a client be able to register mult= iple names (in different locales) with a single client_id, or should it get= a different client_id for each display language set? -- Justin [1] http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-11 On Mar 11, 2013, at 5:54 PM, John Bradley > wrote: That is what I was thinking. It would be up to the AS to determine what l= anguage and script to present based on the user preference. While a large number of clients will be native and might be able to customi= ze themselves for a single user during registration , we don't want to forg= et the web server clients that are multi user. On 2013-03-11, at 10:49 PM, Brian Campbell > wrote: FWIW, the closely related OpenID Connect client registration draft does hav= e some support for doing this, which could maybe be borrowed. See client_na= me in =1B$B!x=1B(B2 at http://openid.net/specs/openid-connect-registration-= 1_0-15.html#client-metadata and the examples. "client_name": "My Example", "client_name#ja-Jpan-JP":"=1B$B%/%i%$%"%s%HL>=1B(B", On Mon, Mar 11, 2013 at 5:15 PM, Richer, Justin P. > wrote: It was brought up at the in-person meeting today that we'll want to conside= r issues around internationalization and localization of human-readable fie= lds like client_name in the client registration. Which is to say: if a clie= nt supports ten languages and wants to present itself in ten languages, sho= uld it have to register itself ten times with an AS? At the moment, I'm of the opinion a client with ten languages could registe= r itself ten times, or do something with the context in which it runs to de= termine which human-facing language to use. Keep in mind that in some cases= (such as native clients), you'll be dynamically registering a client for e= ach user, in effect. In other words, I personally think that this is a rath= ole that will cause more harm than good. -- Justin _______________________________________________ OAuth mailing 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 -- Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_4E1F6AAD24975D4BA5B16804296739436756757FTK5EX14MBXC283r_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable

The value of the explicit= locale field is that it provides locale information to servers that want t= o use it without having to use any explicit language tags in the single-locale case.  I guess I don=1B$B!G=1B(Bt see the compli= cation here.  With this solution, in the single-locale case, all field= s would be passed without language tags (simple for both client and server)= , and a locale would be provided by the client (simple).  The server would store the locale but otherwise could ignore it if it knew= that it was in a single-locale deployment.

 <= /p>

I just don=1B$B!G=1B(Bt s= ee it as being very hard for a registration request to include =1B$B!H=1B(B= default_registration_locale=1B$B!I=1B(B:=1B$B!H=1B(Ben=1B$B!I=1B(B and for = the server to store it and return that value, but otherwise ignore it, if that reflects the realities of your par= ticular deployment. J

 <= /p>

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

 <= /p>

From: Justin Richer [mailto:jricher@mitre.org]
Sent: Wednesday, March 20, 2013 12:11 PM
To: Mike Jones
Cc: George Fletcher; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-= Readable names

 

I agree that I'm seei= ng things from the single-language and single-encoding perspective here, an= d that's the use case I'm currently solving for with my development. I want= to see this one remain simple, and I think we can do that without breaking other use cases.

I would argue that multi-script languages (such as Chinese, Japanese, and o= thers) are all cases where you're going to assume multiple languages, and t= he tags would be necessary for real use. So client and AS would both need t= o know how to deal with the multiple different tags, and smart ones would be able to effectively ignore the def= ault field. The default, scriptless field could be for any one of the suppo= rted languages at the AS or Client, and it'd effectively be a backup, inter= nationalized version, the one that you use when there's nothing else more specific to use.

I guess what's getting me stuck on the explicit locale field is that I'm no= t seeing much value in requiring it over George's proposal of always using = language tags on everything (which I also don't like, but for different rea= sons). Having the information doesn't mean that you can do anything intelligent with it, either, but I can see t= he argument that it makes doing something smart possible. But on the other = hand, we already have a mechanism for doing something smart: using the expl= icit language tags directly.

Also, note that the AS doesn't need to render any characters for tos_uri, p= olicy_uri, and other _uri options, just for client_name. That's why I was m= aking the distinction in my explanation below. You might want to give the u= ser the right option, sure, but a served webpage has a much better chance of getting the locale right dyna= mically than an included string would have (approaches like user preference= s, browser settings, etc. -- everything that's used today on web pages, in = other words). This is why I think that the _uri claims are in a different category and we're talking almost = exclusively about client_name here.

I think, ultimately, that I need to think about this more.

  -- Justin

On 03/20/2013 02:30 PM, Mike Jones wrote:=

I suspect you only feel t= hat leaving the locale information out is OK because you (and I) live in a = culture where it=1B$B!G=1B(Bs not needed to adequately render characters.&n= bsp; I=1B$B!G=1B(Bd actually defer on this decision to Nat and others from Japa= n and China (and I think Korea?) where I believe that this information is e= ssential.

 <= /p>

For what it=1B$B!G=1B(Bs = worth, it=1B$B!G=1B(Bs more than just client_name.  It=1B$B!G=1B(Bs al= so tos_uri and policy_uri and potentially client_uri.

 <= /p>

Also, having thought abou= t it for a few days, I=1B$B!G=1B(Bd change the proposed field name from reg= istration_locale to default_registration_locale, so the meaning is clearer.

 <= /p>

Nat and others from Easte= rn cultures, what is your opinion on this?

 <= /p>

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;     Thanks,

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

 <= /p>

From: Justin Richer [mailto:jricher@mitre.org]
Sent: Wednesday, March 20, 2013 10:43 AM
To: Mike Jones
Cc: George Fletcher; oauth@ietf.or= g WG
Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-= Readable names

 

I would say that clai= ms without a language parameter, which I would make REQUIRED in the presenc= e of other claims, would be treated as UTF8 strings with no guarantee of wh= at language, script, or other locale-specific information would be in there. It's a default string, and it's the best th= e client can give if nothing more specific is useful. And servers would hav= e to accept this default string and do their best with it. A service provid= er can publish their expected default locale information in either discovery or service documentation, and clien= ts that want to tweak things for specific service providers can do that.
The server can display it (because it's a string that'll always be there, i= f any version is there), but a server that doesn't do internationalized str= ings very well might not get its display correct. Since displayable text th= is is likely to be dumped into the middle of a webpage that has its own character encoding and other consider= ations anyway, so it's not guaranteed that specifying a locale will always = help here anyway. This is just for the displayable text, which right now is= only the client_name field in OAuth and OIDC: for URLs (the other "human-readable" field), it's a mo= ot point, because the server's just going to spit out the URL itself into a= n href of some flavor. The server doesn't have to deal with any kind of enc= oding or text/script issues here.

As a server developer, it's just another thing that I *have* to track and d= eal with on the client model, even if I don't want to support the rest of t= he multi-language tags in my service. As a client developer, it's one more = thing that I *have* to specify when I send things to the server. I don't see how requiring its specification i= s going to really help interoperability, and I can almost guarantee that im= plementations will just leave it off even if marked REQUIRED (like how many= , many documents in the wild that are supposed to have a character-encoding field of some type just leave it= off).

I think that it's a lot of work on both sides for just client_name.

 -- Justin


On 03/20/2013 01:27 PM, Mike Jones wrote:=

How woul= d you do this instead then?

From: Justin Richer
Sent: 3/20/2013 10:25 AM
To: Mike Jones
Cc: George Fletcher; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-= Readable names

Personally, I think t= hat this level of specificity is overkill.

 -- Justin


On 03/14/2013 11:42 AM, Mike Jones wrote:=

I agree that having unado= rned values likely simplifies things in many cases, but if we do this, we s= hould let the Client say what language/script it=1B$B!G=1B(Bs using when providing human-readable strings or references to them as registratio= n parameters.  For this purpose, I=1B$B!G=1B(Bd propose that we have a= parameter something like this one:

 <= /p>

registration_locale

OPTIONAL or REQ= URED. Language and script used for human-readable values or references to h= uman-readable values that are supplied without language/script tags, represented as a BCP47[RFC5646] language tag value.  This param= eter is REQUIRED if any human-readable values or references to human-readab= le are provided without language/script tags.

 <= /p>

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

 <= /p>

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Justin Richer
Sent: Thursday, March 14, 2013 8:02 AM
To: George Fletcher
Cc: oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-= Readable names

 

On the surface this does simplify things, but the is= sue I forsee with it is that I want to be able to call "client.getClie= ntName()" and always get *something* out of it if there are *any* clie= nt_name fields at all. So in this world if I take a client library that assumes en-us and it talks to a server that onl= y looks for es-cl, there's a very real chance of the client name not gettin= g set at all. I think that's a problem.

This is why I think the default field name (without the language tag) reall= y should be required and should be left undefined as to what language and s= cript it is. Essentially, "It's a UTF8 String, hope for the best"= . If you want something more specific and smart about localization, then you can support the language tags. If you j= ust want to have a string to store and throw at the user, then you can just= use the bare field name.

In other words, we take what we have now (which works for a non-internation= alized case where everyone just assumes a common language/script), and we a= ugment it with features that let it be smarter if you want it to be smarter= . Make the simple case simple, make the complicated case possible.

 -- Justin

 

On 03/14/2013 10:47 AM, George Fletcher wrote:<= /o:p>

As a simplifying option= ... why not just require human-readable fields to require a "script-ta= g". This way it is always explicit what language/locale the text is for. It then becomes the responsibility of the AS to return an appropri= ate response if there is not a direct match between a request and the data = stored at the AS (and out of scope of the spec).

Thanks,
George

On 3/13/13 10:22 AM, Justin Richer wrote:=

So with what little f= eedback I've gotten, I'm proposing to add text from the proposed webfinger = and OIDC drafts for the hash-based localization of strings, with the follow= ing properties:

* All localized versions of fields are fully optional on both client and se= rver
* If a localized version of a field is included, its bare-value (perhaps in= ternationalized) field MUST be included
* All human-readable fields are eligible for this mechanism (including any = uri's for user-facing web pages, which can be used to point to language-spe= cific pages)
* Clients and servers can decide to use whatever language/script they want = to for the bare-value field, and no assumptions can be made on either side = about what that is

I think that with these constraints, we can add functionality to address St= ephen's concerns without getting too complicated or putting too much burden= of support.

 -- Justin

On 03/11/2013 06:52 PM, Nat Sakimura wrote:

Similar work is in progress at Webfinger. 

 

 

Paul is proposing the= same syntax as Connect. 

2013/3/12 Richer, Justin P. <jricher@mitre.org>

It does presume a definition of "claim", w= hich I suppose we could turn to "metadata field" for DynReg and i= ts extensions to be appropriately limiting. But we also need a good definit= ion of what a language-tag-less field means, and whether or not it's required if the other fields are present or not (which is some= thing that Connect is trying to fix at the moment, as I recall from last we= ek). 

 

So it turns into about a paragraph worth of text. Is= that worth it? I'm not entirely convinced that it is, but I'm interested t= o hear what others think, particularly those who *aren't* tied into the Ope= nID Connect protocol so much. (I don't want to pick a solution just because it's familiar, if we need a solution = at all.)

 

 -- Justin

 

On Mar 11, 2013, at 6:35 PM, Brian Campbell <bcampbell@pingi= dentity.com>

 wrote:

 

A fair question but what would need to be pulled in = is really probably only a couple sentences (and reference) from http://openid.net/specs/openid-connect-messages-1_0-16.html#ClaimsLanguages= AndScripts (note the reference to 2.1.1.1.3 inside http://openid.net/specs/openid-connect-registration-1_0-15.html is brok= en)

 

On Mon, Mar 11, 2013 at 6:26 PM, Richer, Justin P. &= lt;jricher@mitre.org= > wrote:

My concern with this is that OIDC can get away with = defining this multi-language structure because it defines the mechanism onc= e (in Messages) and applies it to all user-readable strings throughout the = whole application protocol, of which there are several. Do we really want to pull in that whole structure and m= echanism for one field in client registration? I really don't think it shou= ld be something that's defined completely inside of DynReg for a corner cas= e for a single field, but I also doubt we want to normatively point to OIDC Messages for this solution eith= er.

 

There are also other ways to do this: Webfinger [1] = for instance uses JSON structures to give language tags to field values, an= d has a default mechanism:

 

   { "en_us": "my client&qu= ot;, =1B$B!D=1B(B }

 

The fundamental question is  this: should a cli= ent be able to register multiple names (in different locales) with a single= client_id, or should it get a different client_id for each display languag= e set?

 

 -- Justin

 

 

On Mar 11, 2013, at 5:54 PM, John Bradley <ve7jtb@ve7jtb.com><= o:p>

 wrote:

 

That is what I was thinking.   It would be up t= o the AS to determine what language and script to present based on the user= preference.

 

While a large number of clients will be native and m= ight be able to customize themselves for a single user during registration = , we don't want to forget the web server clients that are multi user.<= /o:p>

 

On 2013-03-11, at 10:49 PM, Brian Campbell <bcampbell@pingid= entity.com> wrote:

 

FWIW, the closely related OpenID Connect client regi= stration draft does have some support for doing this, which could maybe be = borrowed. See client_name in =1B$B!x=1B(B2 at http://openid.net/specs/openid-connect-registration-1_0-15.html#client-meta= data and the examples.
 

   "client_name": "My Example",
   "client_name#ja-Jpan-JP":"=1B$B%/%i%$%"%s%HL>=1B(B",

 

 

On Mon, Mar 11, 2013 at 5:15 PM, Richer, Justin P. &= lt;jricher@mitre.org= > wrote:

It was brought up at the in-person meeting today tha= t we'll want to consider issues around internationalization and localizatio= n of human-readable fields like client_name in the client registration. Whi= ch is to say: if a client supports ten languages and wants to present itself in ten languages, should it have= to register itself ten times with an AS?

At the moment, I'm of the opinion a client with ten languages could registe= r itself ten times, or do something with the context in which it runs to de= termine which human-facing language to use. Keep in mind that in some cases= (such as native clients), you'll be dynamically registering a client for each user, in effect. In other wor= ds, I personally think that this is a rathole that will cause more harm tha= n good.

 -- Justin
_______________________________________________
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

 

 

 

 


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



 

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.= org/
@_nat_en





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

 

 

 

 

 

--_000_4E1F6AAD24975D4BA5B16804296739436756757FTK5EX14MBXC283r_-- From jricher@mitre.org Thu Mar 21 11: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 7FB0521F90C7 for ; Thu, 21 Mar 2013 11:16:43 -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.700, 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 Gm-Sm-6BOmoa for ; Thu, 21 Mar 2013 11:16:32 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0A53F21F90F5 for ; Thu, 21 Mar 2013 11:16:32 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 75B9E229004E for ; Thu, 21 Mar 2013 14:16:31 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 57E8C1F09C2 for ; Thu, 21 Mar 2013 14:16:31 -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, 21 Mar 2013 14:16:31 -0400 Message-ID: <514B4E28.7000309@mitre.org> Date: Thu, 21 Mar 2013 14:15:04 -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: "oauth@ietf.org WG" References: <1B4C0C9F-4B8E-4B2D-BAF7-665D3EBBE56C@ve7jtb.com> <51408B8B.9000800@mitre.org> <5141E2E6.9020701@aol.com> <5141E671.2050708@mitre.org> <4E1F6AAD24975D4BA5B16804296739436750F5E2@TK5EX14MBXC283.redmond.corp.microsoft.com>, <5149F092.7070902@mitre.org> <4E1F6AAD24975D4BA5B168042967394367565FEF@TK5EX14MBXC283.redmond.corp.microsoft.com> <5149F534.1040500@mitre.org> <4E1F6AAD24975D4BA5B168042967394367567185@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040804070500060507080806" X-Originating-IP: [129.83.31.58] Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readable names X-BeenThere: oauth@ietf.org X-Mailman-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, 21 Mar 2013 18:16:43 -0000 --------------040804070500060507080806 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit We discussed this issue on the OpenID Connect WG call this morning, in a conversation that included myself, George Fletcher, Nat Sakimura, Mike Jones, and John Bradley (among others) as active participants in this thread. After lots of debate, we propose that the OAuth DynReg adopt the hashtag-based localization method of OIDC (and it seems, possibly webfinger) and explicitly declare that neither the client nor the server make any assumptions about the content of the string and treat it as just a string. I'm proposing this text to that effect (with the references to OIDC-messages removed and replaced with the rule description itself in OAuth DynReg): Fields with human-readable values or references to human-readable values, such as client_name, tos_uri, policy_uri, and client_uri, MAY be represented in multiple languages and scripts, specified by appending a # character and the RFC5646 language tag. If any such human-readable field is sent without a language tag, the server and the client MUST NOT make any assumptions about the language, character set, or script of the value string, and the value string MUST be used as-is wherever it is presented in either the client or server UI. To facilitate interoperability, it is RECOMMENDED that any fields sent without language tags contain an internationalized UTF-8 string suitable for display on a wide variety of systems, and it is RECOMMENDED that clients send fields without language tags in addition to any more-specifically denominated values. Plus some examples. (Anyone whose name I took in vain, please feel free to correct me.) -- Justin On 03/20/2013 03:11 PM, Justin Richer wrote: > I agree that I'm seeing things from the single-language and > single-encoding perspective here, and that's the use case I'm > currently solving for with my development. I want to see this one > remain simple, and I think we can do that without breaking other use > cases. > > I would argue that multi-script languages (such as Chinese, Japanese, > and others) are all cases where you're going to assume multiple > languages, and the tags would be necessary for real use. So client and > AS would both need to know how to deal with the multiple different > tags, and smart ones would be able to effectively ignore the default > field. The default, scriptless field could be for any one of the > supported languages at the AS or Client, and it'd effectively be a > backup, internationalized version, the one that you use when there's > nothing else more specific to use. > > I guess what's getting me stuck on the explicit locale field is that > I'm not seeing much value in requiring it over George's proposal of > always using language tags on everything (which I also don't like, but > for different reasons). Having the information doesn't mean that you > can do anything intelligent with it, either, but I can see the > argument that it makes doing something smart possible. But on the > other hand, we already have a mechanism for doing something smart: > using the explicit language tags directly. > > Also, note that the AS doesn't need to render any characters for > tos_uri, policy_uri, and other _uri options, just for client_name. > That's why I was making the distinction in my explanation below. You > might want to give the user the right option, sure, but a served > webpage has a much better chance of getting the locale right > dynamically than an included string would have (approaches like user > preferences, browser settings, etc. -- everything that's used today on > web pages, in other words). This is why I think that the _uri claims > are in a different category and we're talking almost exclusively about > client_name here. > > I think, ultimately, that I need to think about this more. > > -- Justin > > On 03/20/2013 02:30 PM, Mike Jones wrote: >> >> I suspect you only feel that leaving the locale information out is OK >> because you (and I) live in a culture where it's not needed to >> adequately render characters. I'd actually defer on this decision to >> Nat and others from Japan and China (and I think Korea?) where I >> believe that this information is essential. >> >> For what it's worth, it's more than just client_name. It's also >> tos_uri and policy_uri and potentially client_uri. >> >> Also, having thought about it for a few days, I'd change the proposed >> field name from registration_locale to default_registration_locale, >> so the meaning is clearer. >> >> Nat and others from Eastern cultures, what is your opinion on this? >> >> Thanks, >> >> -- Mike >> >> *From:*Justin Richer [mailto:jricher@mitre.org] >> *Sent:* Wednesday, March 20, 2013 10:43 AM >> *To:* Mike Jones >> *Cc:* George Fletcher; oauth@ietf.org WG >> *Subject:* Re: [OAUTH-WG] Registration: Internationalization of >> Human-Readable names >> >> I would say that claims without a language parameter, which I would >> make REQUIRED in the presence of other claims, would be treated as >> UTF8 strings with no guarantee of what language, script, or other >> locale-specific information would be in there. It's a default string, >> and it's the best the client can give if nothing more specific is >> useful. And servers would have to accept this default string and do >> their best with it. A service provider can publish their expected >> default locale information in either discovery or service >> documentation, and clients that want to tweak things for specific >> service providers can do that. >> >> The server can display it (because it's a string that'll always be >> there, if any version is there), but a server that doesn't do >> internationalized strings very well might not get its display >> correct. Since displayable text this is likely to be dumped into the >> middle of a webpage that has its own character encoding and other >> considerations anyway, so it's not guaranteed that specifying a >> locale will always help here anyway. This is just for the displayable >> text, which right now is only the client_name field in OAuth and >> OIDC: for URLs (the other "human-readable" field), it's a moot point, >> because the server's just going to spit out the URL itself into an >> href of some flavor. The server doesn't have to deal with any kind of >> encoding or text/script issues here. >> >> As a server developer, it's just another thing that I *have* to track >> and deal with on the client model, even if I don't want to support >> the rest of the multi-language tags in my service. As a client >> developer, it's one more thing that I *have* to specify when I send >> things to the server. I don't see how requiring its specification is >> going to really help interoperability, and I can almost guarantee >> that implementations will just leave it off even if marked REQUIRED >> (like how many, many documents in the wild that are supposed to have >> a character-encoding field of some type just leave it off). >> >> I think that it's a lot of work on both sides for just client_name. >> >> -- Justin >> >> On 03/20/2013 01:27 PM, Mike Jones wrote: >> >> How would you do this instead then? >> >> ------------------------------------------------------------------------ >> >> *From: *Justin Richer >> *Sent: *3/20/2013 10:25 AM >> *To: *Mike Jones >> *Cc: *George Fletcher; oauth@ietf.org WG >> *Subject: *Re: [OAUTH-WG] Registration: Internationalization of >> Human-Readable names >> >> Personally, I think that this level of specificity is overkill. >> >> -- Justin >> >> On 03/14/2013 11:42 AM, Mike Jones wrote: >> >> I agree that having unadorned values likely simplifies things >> in many cases, but if we do this, we should let the Client >> say what language/script it's using when providing >> human-readable strings or references to them as registration >> parameters. For this purpose, I'd propose that we have a >> parameter something like this one: >> >> registration_locale >> >> OPTIONAL or REQURED. Language and script used for >> human-readable values or references to human-readable values >> that are supplied without language/script tags, represented >> as a BCP47[RFC5646] language tag value. This parameter is >> REQUIRED if any human-readable values or references to >> human-readable are provided without language/script tags. >> >> -- Mike >> >> *From:*oauth-bounces@ietf.org >> [mailto:oauth-bounces@ietf.org] *On Behalf Of *Justin Richer >> *Sent:* Thursday, March 14, 2013 8:02 AM >> *To:* George Fletcher >> *Cc:* oauth@ietf.org WG >> *Subject:* Re: [OAUTH-WG] Registration: Internationalization >> of Human-Readable names >> >> On the surface this does simplify things, but the issue I >> forsee with it is that I want to be able to call >> "client.getClientName()" and always get *something* out of it >> if there are *any* client_name fields at all. So in this >> world if I take a client library that assumes en-us and it >> talks to a server that only looks for es-cl, there's a very >> real chance of the client name not getting set at all. I >> think that's a problem. >> >> This is why I think the default field name (without the >> language tag) really should be required and should be left >> undefined as to what language and script it is. Essentially, >> "It's a UTF8 String, hope for the best". If you want >> something more specific and smart about localization, then >> you can support the language tags. If you just want to have a >> string to store and throw at the user, then you can just use >> the bare field name. >> >> In other words, we take what we have now (which works for a >> non-internationalized case where everyone just assumes a >> common language/script), and we augment it with features that >> let it be smarter if you want it to be smarter. Make the >> simple case simple, make the complicated case possible. >> >> -- Justin >> >> On 03/14/2013 10:47 AM, George Fletcher wrote: >> >> As a simplifying option... why not just require >> human-readable fields to require a "script-tag". This way >> it is always explicit what language/locale the text is >> for. It then becomes the responsibility of the AS to >> return an appropriate response if there is not a direct >> match between a request and the data stored at the AS >> (and out of scope of the spec). >> >> Thanks, >> George >> >> On 3/13/13 10:22 AM, Justin Richer wrote: >> >> So with what little feedback I've gotten, I'm >> proposing to add text from the proposed webfinger and >> OIDC drafts for the hash-based localization of >> strings, with the following properties: >> >> * All localized versions of fields are fully optional >> on both client and server >> * If a localized version of a field is included, its >> bare-value (perhaps internationalized) field MUST be >> included >> * All human-readable fields are eligible for this >> mechanism (including any uri's for user-facing web >> pages, which can be used to point to >> language-specific pages) >> * Clients and servers can decide to use whatever >> language/script they want to for the bare-value >> field, and no assumptions can be made on either side >> about what that is >> >> I think that with these constraints, we can add >> functionality to address Stephen's concerns without >> getting too complicated or putting too much burden of >> support. >> >> -- Justin >> >> On 03/11/2013 06:52 PM, Nat Sakimura wrote: >> >> Similar work is in progress at Webfinger. >> >> See: >> http://www.ietf.org/mail-archive/web/webfinger/current/msg00530.html >> >> Paul is proposing the same syntax as Connect. >> >> 2013/3/12 Richer, Justin P. > > >> >> It does presume a definition of "claim", which I >> suppose we could turn to "metadata field" for >> DynReg and its extensions to be appropriately >> limiting. But we also need a good definition of >> what a language-tag-less field means, and whether >> or not it's required if the other fields are >> present or not (which is something that Connect >> is trying to fix at the moment, as I recall from >> last week). >> >> So it turns into about a paragraph worth of text. >> Is that worth it? I'm not entirely convinced that >> it is, but I'm interested to hear what others >> think, particularly those who *aren't* tied into >> the OpenID Connect protocol so much. (I don't >> want to pick a solution just because it's >> familiar, if we need a solution at all.) >> >> -- Justin >> >> On Mar 11, 2013, at 6:35 PM, Brian Campbell >> > > >> >> wrote: >> >> A fair question but what would need to be pulled >> in is really probably only a couple sentences >> (and reference) from >> http://openid.net/specs/openid-connect-messages-1_0-16.html#ClaimsLanguagesAndScripts >> (note the reference to 2.1.1.1.3 inside >> http://openid.net/specs/openid-connect-registration-1_0-15.html >> is broken) >> >> On Mon, Mar 11, 2013 at 6:26 PM, Richer, Justin >> P. > >> wrote: >> >> My concern with this is that OIDC can get away >> with defining this multi-language structure >> because it defines the mechanism once (in >> Messages) and applies it to all user-readable >> strings throughout the whole application >> protocol, of which there are several. Do we >> really want to pull in that whole structure and >> mechanism for one field in client registration? I >> really don't think it should be something that's >> defined completely inside of DynReg for a corner >> case for a single field, but I also doubt we want >> to normatively point to OIDC Messages for this >> solution either. >> >> There are also other ways to do this: Webfinger >> [1] for instance uses JSON structures to give >> language tags to field values, and has a default >> mechanism: >> >> { "en_us": "my client", ... } >> >> The fundamental question is this: should a >> client be able to register multiple names (in >> different locales) with a single client_id, or >> should it get a different client_id for each >> display language set? >> >> -- Justin >> >> [1] >> http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-11 >> >> On Mar 11, 2013, at 5:54 PM, John Bradley >> > >> >> wrote: >> >> That is what I was thinking. It would be up to >> the AS to determine what language and script to >> present based on the user preference. >> >> While a large number of clients will be native >> and might be able to customize themselves for a >> single user during registration , we don't want >> to forget the web server clients that are multi user. >> >> On 2013-03-11, at 10:49 PM, Brian Campbell >> > > wrote: >> >> FWIW, the closely related OpenID Connect client >> registration draft does have some support for >> doing this, which could maybe be borrowed. See >> client_name in §2 at >> http://openid.net/specs/openid-connect-registration-1_0-15.html#client-metadata >> and the examples. >> >> "client_name": "My Example", >> >> "client_name#ja-Jpan-JP":"???????", >> >> On Mon, Mar 11, 2013 at 5:15 PM, Richer, Justin >> P. > >> wrote: >> >> It was brought up at the in-person meeting today >> that we'll want to consider issues around >> internationalization and localization of >> human-readable fields like client_name in the >> client registration. Which is to say: if a client >> supports ten languages and wants to present >> itself in ten languages, should it have to >> register itself ten times with an AS? >> >> At the moment, I'm of the opinion a client with >> ten languages could register itself ten times, or >> do something with the context in which it runs to >> determine which human-facing language to use. >> Keep in mind that in some cases (such as native >> clients), you'll be dynamically registering a >> client for each user, in effect. In other words, >> I personally think that this is a rathole that >> will cause more harm than good. >> >> -- Justin >> _______________________________________________ >> OAuth mailing 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 >> >> >> >> -- >> Nat Sakimura (=nat) >> >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >> >> >> >> >> _______________________________________________ >> >> OAuth mailing list >> >> OAuth@ietf.org >> >> https://www.ietf.org/mailman/listinfo/oauth >> > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------040804070500060507080806 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit We discussed this issue on the OpenID Connect WG call this morning, in a conversation that included myself, George Fletcher, Nat Sakimura, Mike Jones, and John Bradley (among others) as active participants in this thread. After lots of debate, we propose that the OAuth DynReg adopt the hashtag-based localization method of OIDC (and it seems, possibly webfinger) and explicitly declare that neither the client nor the server make any assumptions about the content of the string and treat it as just a string. I'm proposing this text to that effect (with the references to OIDC-messages removed and replaced with the rule description itself in OAuth DynReg):

Fields with human-readable values or references to human-readable values, such as client_name, tos_uri, policy_uri, and client_uri, MAY be represented in multiple languages and scripts, specified by appending a # character and the RFC5646 language tag. If any such human-readable field is sent without a language tag, the server and the client MUST NOT make any assumptions about the language, character set, or script of the value string, and the value string MUST be used as-is wherever it is presented in either the client or server UI. To facilitate interoperability, it is RECOMMENDED that any fields sent without language tags contain an internationalized UTF-8 string suitable for display on a wide variety of systems, and it is RECOMMENDED that clients send fields without language tags in addition to any more-specifically denominated values.

Plus some examples.

(Anyone whose name I took in vain, please feel free to correct me.)

 -- Justin

On 03/20/2013 03:11 PM, Justin Richer wrote:
I agree that I'm seeing things from the single-language and single-encoding perspective here, and that's the use case I'm currently solving for with my development. I want to see this one remain simple, and I think we can do that without breaking other use cases.

I would argue that multi-script languages (such as Chinese, Japanese, and others) are all cases where you're going to assume multiple languages, and the tags would be necessary for real use. So client and AS would both need to know how to deal with the multiple different tags, and smart ones would be able to effectively ignore the default field. The default, scriptless field could be for any one of the supported languages at the AS or Client, and it'd effectively be a backup, internationalized version, the one that you use when there's nothing else more specific to use.

I guess what's getting me stuck on the explicit locale field is that I'm not seeing much value in requiring it over George's proposal of always using language tags on everything (which I also don't like, but for different reasons). Having the information doesn't mean that you can do anything intelligent with it, either, but I can see the argument that it makes doing something smart possible. But on the other hand, we already have a mechanism for doing something smart: using the explicit language tags directly.

Also, note that the AS doesn't need to render any characters for tos_uri, policy_uri, and other _uri options, just for client_name. That's why I was making the distinction in my explanation below. You might want to give the user the right option, sure, but a served webpage has a much better chance of getting the locale right dynamically than an included string would have (approaches like user preferences, browser settings, etc. -- everything that's used today on web pages, in other words). This is why I think that the _uri claims are in a different category and we're talking almost exclusively about client_name here.

I think, ultimately, that I need to think about this more.

  -- Justin

On 03/20/2013 02:30 PM, Mike Jones wrote:

I suspect you only feel that leaving the locale information out is OK because you (and I) live in a culture where it’s not needed to adequately render characters.  I’d actually defer on this decision to Nat and others from Japan and China (and I think Korea?) where I believe that this information is essential.

 

For what it’s worth, it’s more than just client_name.  It’s also tos_uri and policy_uri and potentially client_uri.

 

Also, having thought about it for a few days, I’d change the proposed field name from registration_locale to default_registration_locale, so the meaning is clearer.

 

Nat and others from Eastern cultures, what is your opinion on this?

 

                                                            Thanks,

                                                            -- Mike

 

From: Justin Richer [mailto:jricher@mitre.org]
Sent: Wednesday, March 20, 2013 10:43 AM
To: Mike Jones
Cc: George Fletcher; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readable names

 

I would say that claims without a language parameter, which I would make REQUIRED in the presence of other claims, would be treated as UTF8 strings with no guarantee of what language, script, or other locale-specific information would be in there. It's a default string, and it's the best the client can give if nothing more specific is useful. And servers would have to accept this default string and do their best with it. A service provider can publish their expected default locale information in either discovery or service documentation, and clients that want to tweak things for specific service providers can do that.

The server can display it (because it's a string that'll always be there, if any version is there), but a server that doesn't do internationalized strings very well might not get its display correct. Since displayable text this is likely to be dumped into the middle of a webpage that has its own character encoding and other considerations anyway, so it's not guaranteed that specifying a locale will always help here anyway. This is just for the displayable text, which right now is only the client_name field in OAuth and OIDC: for URLs (the other "human-readable" field), it's a moot point, because the server's just going to spit out the URL itself into an href of some flavor. The server doesn't have to deal with any kind of encoding or text/script issues here.

As a server developer, it's just another thing that I *have* to track and deal with on the client model, even if I don't want to support the rest of the multi-language tags in my service. As a client developer, it's one more thing that I *have* to specify when I send things to the server. I don't see how requiring its specification is going to really help interoperability, and I can almost guarantee that implementations will just leave it off even if marked REQUIRED (like how many, many documents in the wild that are supposed to have a character-encoding field of some type just leave it off).

I think that it's a lot of work on both sides for just client_name.

 -- Justin

On 03/20/2013 01:27 PM, Mike Jones wrote:

How would you do this instead then?

From: Justin Richer
Sent: 3/20/2013 10:25 AM
To: Mike Jones
Cc: George Fletcher; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readable names

Personally, I think that this level of specificity is overkill.

 -- Justin

On 03/14/2013 11:42 AM, Mike Jones wrote:

I agree that having unadorned values likely simplifies things in many cases, but if we do this, we should let the Client say what language/script it’s using when providing human-readable strings or references to them as registration parameters.  For this purpose, I’d propose that we have a parameter something like this one:

 

registration_locale

OPTIONAL or REQURED. Language and script used for human-readable values or references to human-readable values that are supplied without language/script tags, represented as a BCP47[RFC5646] language tag value.  This parameter is REQUIRED if any human-readable values or references to human-readable are provided without language/script tags.

 

                                                            -- Mike

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Justin Richer
Sent: Thursday, March 14, 2013 8:02 AM
To: George Fletcher
Cc: oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readable names

 

On the surface this does simplify things, but the issue I forsee with it is that I want to be able to call "client.getClientName()" and always get *something* out of it if there are *any* client_name fields at all. So in this world if I take a client library that assumes en-us and it talks to a server that only looks for es-cl, there's a very real chance of the client name not getting set at all. I think that's a problem.

This is why I think the default field name (without the language tag) really should be required and should be left undefined as to what language and script it is. Essentially, "It's a UTF8 String, hope for the best". If you want something more specific and smart about localization, then you can support the language tags. If you just want to have a string to store and throw at the user, then you can just use the bare field name.

In other words, we take what we have now (which works for a non-internationalized case where everyone just assumes a common language/script), and we augment it with features that let it be smarter if you want it to be smarter. Make the simple case simple, make the complicated case possible.

 -- Justin

 

On 03/14/2013 10:47 AM, George Fletcher wrote:

As a simplifying option... why not just require human-readable fields to require a "script-tag". This way it is always explicit what language/locale the text is for. It then becomes the responsibility of the AS to return an appropriate response if there is not a direct match between a request and the data stored at the AS (and out of scope of the spec).

Thanks,
George

On 3/13/13 10:22 AM, Justin Richer wrote:

So with what little feedback I've gotten, I'm proposing to add text from the proposed webfinger and OIDC drafts for the hash-based localization of strings, with the following properties:

* All localized versions of fields are fully optional on both client and server
* If a localized version of a field is included, its bare-value (perhaps internationalized) field MUST be included
* All human-readable fields are eligible for this mechanism (including any uri's for user-facing web pages, which can be used to point to language-specific pages)
* Clients and servers can decide to use whatever language/script they want to for the bare-value field, and no assumptions can be made on either side about what that is

I think that with these constraints, we can add functionality to address Stephen's concerns without getting too complicated or putting too much burden of support.

 -- Justin

On 03/11/2013 06:52 PM, Nat Sakimura wrote:

Similar work is in progress at Webfinger. 

 

 

Paul is proposing the same syntax as Connect. 

2013/3/12 Richer, Justin P. <jricher@mitre.org>

It does presume a definition of "claim", which I suppose we could turn to "metadata field" for DynReg and its extensions to be appropriately limiting. But we also need a good definition of what a language-tag-less field means, and whether or not it's required if the other fields are present or not (which is something that Connect is trying to fix at the moment, as I recall from last week). 

 

So it turns into about a paragraph worth of text. Is that worth it? I'm not entirely convinced that it is, but I'm interested to hear what others think, particularly those who *aren't* tied into the OpenID Connect protocol so much. (I don't want to pick a solution just because it's familiar, if we need a solution at all.)

 

 -- Justin

 

On Mar 11, 2013, at 6:35 PM, Brian Campbell <bcampbell@pingidentity.com>

 wrote:

 

A fair question but what would need to be pulled in is really probably only a couple sentences (and reference) from http://openid.net/specs/openid-connect-messages-1_0-16.html#ClaimsLanguagesAndScripts (note the reference to 2.1.1.1.3 inside http://openid.net/specs/openid-connect-registration-1_0-15.html is broken)

 

On Mon, Mar 11, 2013 at 6:26 PM, Richer, Justin P. <jricher@mitre.org> wrote:

My concern with this is that OIDC can get away with defining this multi-language structure because it defines the mechanism once (in Messages) and applies it to all user-readable strings throughout the whole application protocol, of which there are several. Do we really want to pull in that whole structure and mechanism for one field in client registration? I really don't think it should be something that's defined completely inside of DynReg for a corner case for a single field, but I also doubt we want to normatively point to OIDC Messages for this solution either.

 

There are also other ways to do this: Webfinger [1] for instance uses JSON structures to give language tags to field values, and has a default mechanism:

 

   { "en_us": "my client", … }

 

The fundamental question is  this: should a client be able to register multiple names (in different locales) with a single client_id, or should it get a different client_id for each display language set?

 

 -- Justin

 

 

On Mar 11, 2013, at 5:54 PM, John Bradley <ve7jtb@ve7jtb.com>

 wrote:

 

That is what I was thinking.   It would be up to the AS to determine what language and script to present based on the user preference.

 

While a large number of clients will be native and might be able to customize themselves for a single user during registration , we don't want to forget the web server clients that are multi user.

 

On 2013-03-11, at 10:49 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:

 

FWIW, the closely related OpenID Connect client registration draft does have some support for doing this, which could maybe be borrowed. See client_name in §2 at http://openid.net/specs/openid-connect-registration-1_0-15.html#client-metadata and the examples.
 

   "client_name": "My Example",
   "client_name#ja-Jpan-JP":"クライアント名",

 

 

On Mon, Mar 11, 2013 at 5:15 PM, Richer, Justin P. <jricher@mitre.org> wrote:

It was brought up at the in-person meeting today that we'll want to consider issues around internationalization and localization of human-readable fields like client_name in the client registration. Which is to say: if a client supports ten languages and wants to present itself in ten languages, should it have to register itself ten times with an AS?

At the moment, I'm of the opinion a client with ten languages could register itself ten times, or do something with the context in which it runs to determine which human-facing language to use. Keep in mind that in some cases (such as native clients), you'll be dynamically registering a client for each user, in effect. In other words, I personally think that this is a rathole that will cause more harm than good.

 -- Justin
_______________________________________________
OAuth mailing 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



 

--
Nat Sakimura (=nat)

Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en




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

 

 

 

 




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

--------------040804070500060507080806-- From prateek.mishra@oracle.com Thu Mar 21 13:28: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 725F621F89B2 for ; Thu, 21 Mar 2013 13:28:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_48=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 gHE9SmfbqbZw for ; Thu, 21 Mar 2013 13:28:29 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 9A36C21F8A0D for ; Thu, 21 Mar 2013 13:28:29 -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 r2LKSPVI030105 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 21 Mar 2013 20:28:26 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r2LKSOON010152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Mar 2013 20:28:25 GMT Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r2LKSOxg024442; Thu, 21 Mar 2013 15:28:24 -0500 Received: from [10.152.55.88] (/10.152.55.88) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 21 Mar 2013 13:28:23 -0700 Message-ID: <514B6D66.9070809@oracle.com> Date: Thu, 21 Mar 2013 16:28:22 -0400 From: prateek mishra Organization: Oracle Corporation User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Nat Sakimura , Mike Jones References: <1362079266.8952.YahooMailClassic@web141002.mail.bf1.yahoo.com> <512FCDF0.6010807@gmx.net> <5141EE22.2030306@oracle.com> <51421CA0.7010400@oracle.com> <4E1F6AAD24975D4BA5B1680429673943675115B6@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] the meaning of audience in SAML vs. OAuth X-BeenThere: oauth@ietf.org X-Mailman-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, 21 Mar 2013 20:28:30 -0000 Mike, Nat - I am honestly not sure what to propose in terms of wording clarification. has a specific meaning in SAML and thats different from its current meaning in OAuth. This issue becomes even more confusing as the SAML assertion draft goes onto redefine the meaning of . Its processing rules for duplicate those for the recipient attribute within . In SAML request messages, models what is represented by "audience" in Oauth. As I mentioned above, SAML assertions utilize a recipient attribute within the element to achieve the same effect. My suggestion would be to replace "audience" by "recipient" or "recipients". That would maintain a certain parallelism between SAML and JWT assertions. It would also avoid the current duplication of processing rules for and the "recipient" attribute in the SAML assertion draft. I understand that as defined in SAML 2.0 is under-used and perhaps also widely misunderstood. Nevertheless there are implementations that make proper use of this element and they are gonna be quite confused when they try to implement the SAML assertion draft. I can also see some real interop. difficulties arising because of this mixup. - prateek > well.. the aud term came from googler's use of the term and not saml. > I agree with Prateek that the intention of the jwt:aud is rather > similar to saml:destination. > JWT is imposing the processing rule on it while saml:audience is > mainly concerned about the liability. > > Nat > > > 2013/3/15 Mike Jones: >> The JWT meaning of the term "audience" is intended to be the same as SAML. Suggested wording clarifications would be welcomed. >> >> -- Mike >> >> -----Original Message----- >> From: prateek mishra [mailto:prateek.mishra@oracle.com] >> Sent: Thursday, March 14, 2013 11:53 AM >> To: Hannes Tschofenig; Mike Jones >> Cc:oauth@ietf.org >> Subject: the meaning of audience in SAML vs. OAuth >> >> Hannes - you make a good point. >> >> I believe that the usage of "audience" inhttp://www.ietf.org/id/draft-ietf-oauth-json-web-token-06.txt >> >> also corresponds to rather than . >> >> [quote-jwt06] >> The aud (audience) claim identifies the audiences that the JWT is intended for. Each principal intended to process the JWT MUST identify itself with a value in audience claim. If the principal processing the claim does not identify itself with a value in the aud claim, then the JWT MUST be rejected. In the general case, the aud value is an array of case sensitive strings, each containing a StringOrURI value. In the special case when the JWT has one audience, the aud value MAY be a single case sensitive string containing a StringOrURI value. The interpretation of audience values is generally application specific. Use of this claim is OPTIONAL. >> [\quote] >> >> I think this is a point of quite some confusion (a similar problem arose during the SAML assertion drafts discussion on Tuesday). >> >> To the extent that JWT re-uses concepts and names from SAML, I dont think this is the correct name with the semantics implied by the processing rules given in jwt06. >> >> - prateek >> >> >> >> >> >>> Hi Prateek, >>> >>> I never had planned to make the term audience to align with the SAML specification. >>> However, in case this could lead to confusion we could also define a different term. >>> >>> Btw, did you look at the JWT spec whether the audience term there is inline with the SAML spec? >>> >>> Ciao >>> Hannes >>> >>> On Mar 14, 2013, at 11:34 AM, prateek mishra wrote: >>> >>>> Hi Hannes, >>>> >>>> I wanted to point out that use of the term "audience" in this document is not consistent with the SAML 2.0 specification. >>>> >>>> >>>> What you are referring to here as "audience" corresponds to >>>> which is described as >>>> >>>> [quote-saml2.0] >>>> Destination [Optional] >>>> A URI reference indicating the address to which this request has been >>>> sent. This is useful to prevent malicious forwarding of requests to >>>> unintended recipients, a protection that is required by some protocol >>>> bindings. If it is present, the actual recipient MUST check that the >>>> URI reference identifies the location at which the message was received. If it does not, the request MUST be discarded. Some protocol bindings may require the use of this attribute (see [SAMLBind]). >>>> [\quote] >>>> >>>> In contrast, is a means of limiting the liability of >>>> the asserting party and is described in the following manner - >>>> >>>> [quote-saml2.0] >>>> >>>> A URI reference that identifies an intended audience. The URI >>>> reference MAY identify a document that describes the terms and >>>> conditions of audience membership. It MAY also contain the unique identifier URI from a SAML name identifier that describes a system entity (see Section 8.3.6). >>>> The audience restriction condition evaluates to Valid if and only if >>>> the SAML relying party is a member of one or more of the audiences specified. >>>> >>>> The SAML asserting party cannot prevent a party to whom the assertion >>>> is disclosed from taking action on the basis of the information >>>> provided. However, the element allows the SAML >>>> asserting party to state explicitly that no warranty is provided to >>>> such a party in a machine- and human-readable form. While there can >>>> be no guarantee that a court would uphold such a warranty exclusion in every circumstance, the probability of upholding the warranty exclusion is considerably improved. >>>> [\quote] >>>> >>>> - prateek >>>> >>>> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > From cmortimore@salesforce.com Thu Mar 21 13:31: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 773C021F8A0D for ; Thu, 21 Mar 2013 13:31:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_48=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 Fu3XwKNZc8SE for ; Thu, 21 Mar 2013 13:31:08 -0700 (PDT) Received: from exprod8og110.obsmtp.com (exprod8og110.obsmtp.com [64.18.3.100]) by ietfa.amsl.com (Postfix) with SMTP id 300FE21F8C11 for ; Thu, 21 Mar 2013 13:31:08 -0700 (PDT) Received: from exsfm-hub4.internal.salesforce.com ([204.14.239.239]) by exprod8ob110.postini.com ([64.18.7.12]) with SMTP ID DSNKUUtuC9hV0l6pYD1pi/21edztd+blQebA@postini.com; Thu, 21 Mar 2013 13:31:08 PDT Received: from sfm-exmb-c6.internal.salesforce.com ([fe80:0000:0000:0000:b801:321e:208.196.5.186]) by exsfm-hub4.internal.salesforce.com ([10.1.127.8]) with mapi; Thu, 21 Mar 2013 13:31:08 -0700 From: Chuck Mortimore To: prateek mishra Date: Thu, 21 Mar 2013 13:31:06 -0700 Thread-Topic: [OAUTH-WG] the meaning of audience in SAML vs. OAuth Thread-Index: Ac4mcwQKKB8rl/UbS4qN8ZKsuQCgRg== Message-ID: <9D24C01D-CDDB-43BB-A8A9-CB5D2653CC3C@salesforce.com> References: <1362079266.8952.YahooMailClassic@web141002.mail.bf1.yahoo.com> <512FCDF0.6010807@gmx.net> <5141EE22.2030306@oracle.com> <51421CA0.7010400@oracle.com> <4E1F6AAD24975D4BA5B1680429673943675115B6@TK5EX14MBXC283.redmond.corp.microsoft.com> <514B6D66.9070809@oracle.com> In-Reply-To: <514B6D66.9070809@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] the meaning of audience in SAML vs. OAuth X-BeenThere: oauth@ietf.org X-Mailman-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, 21 Mar 2013 20:31:09 -0000 Hey Prateek - and suggested improvements for the SAML Bearer draft? On Mar 21, 2013, at 1:28 PM, prateek mishra wrote: > Mike, Nat - >=20 > I am honestly not sure what to propose in terms of wording=20 > clarification. has a specific meaning in SAML and thats differ= ent > from its current meaning in OAuth. This issue becomes even more=20 > confusing as the SAML assertion draft goes onto > redefine the meaning of . Its processing rules for=20 > duplicate those for the recipient attribute within=20 > . >=20 > In SAML request messages, models what is represented=20 > by "audience" in Oauth. > As I mentioned above, SAML assertions utilize a recipient attribute=20 > within the element to achieve the > same effect. >=20 > My suggestion would be to replace "audience" by "recipient" or=20 > "recipients". That would maintain a certain parallelism > between SAML and JWT assertions. It would also avoid the current=20 > duplication of processing rules > for and the "recipient" attribute in the SAML assertion=20 > draft. >=20 > I understand that as defined in SAML 2.0 is under-used=20 > and perhaps also widely misunderstood. Nevertheless there are > implementations that make proper use of this element and they are gonna=20 > be quite confused when they try to > implement the SAML assertion draft. I can also see some real interop.=20 > difficulties arising because of this mixup. >=20 > - prateek >> well.. the aud term came from googler's use of the term and not saml. >> I agree with Prateek that the intention of the jwt:aud is rather >> similar to saml:destination. >> JWT is imposing the processing rule on it while saml:audience is >> mainly concerned about the liability. >>=20 >> Nat >>=20 >>=20 >> 2013/3/15 Mike Jones: >>> The JWT meaning of the term "audience" is intended to be the same as SA= ML. Suggested wording clarifications would be welcomed. >>>=20 >>> -- Mike >>>=20 >>> -----Original Message----- >>> From: prateek mishra [mailto:prateek.mishra@oracle.com] >>> Sent: Thursday, March 14, 2013 11:53 AM >>> To: Hannes Tschofenig; Mike Jones >>> Cc:oauth@ietf.org >>> Subject: the meaning of audience in SAML vs. OAuth >>>=20 >>> Hannes - you make a good point. >>>=20 >>> I believe that the usage of "audience" inhttp://www.ietf.org/id/draft-i= etf-oauth-json-web-token-06.txt >>>=20 >>> also corresponds to rather than . >>>=20 >>> [quote-jwt06] >>> The aud (audience) claim identifies the audiences that the JWT is inten= ded for. Each principal intended to process the JWT MUST identify itself wi= th a value in audience claim. If the principal processing the claim does no= t identify itself with a value in the aud claim, then the JWT MUST be rejec= ted. In the general case, the aud value is an array of case sensitive strin= gs, each containing a StringOrURI value. In the special case when the JWT h= as one audience, the aud value MAY be a single case sensitive string contai= ning a StringOrURI value. The interpretation of audience values is generall= y application specific. Use of this claim is OPTIONAL. >>> [\quote] >>>=20 >>> I think this is a point of quite some confusion (a similar problem aros= e during the SAML assertion drafts discussion on Tuesday). >>>=20 >>> To the extent that JWT re-uses concepts and names from SAML, I dont thi= nk this is the correct name with the semantics implied by the processing ru= les given in jwt06. >>>=20 >>> - prateek >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>> Hi Prateek, >>>>=20 >>>> I never had planned to make the term audience to align with the SAML s= pecification. >>>> However, in case this could lead to confusion we could also define a d= ifferent term. >>>>=20 >>>> Btw, did you look at the JWT spec whether the audience term there is i= nline with the SAML spec? >>>>=20 >>>> Ciao >>>> Hannes >>>>=20 >>>> On Mar 14, 2013, at 11:34 AM, prateek mishra wrote: >>>>=20 >>>>> Hi Hannes, >>>>>=20 >>>>> I wanted to point out that use of the term "audience" in this documen= t is not consistent with the SAML 2.0 specification. >>>>>=20 >>>>>=20 >>>>> What you are referring to here as "audience" corresponds to >>>>> which is described as >>>>>=20 >>>>> [quote-saml2.0] >>>>> Destination [Optional] >>>>> A URI reference indicating the address to which this request has been >>>>> sent. This is useful to prevent malicious forwarding of requests to >>>>> unintended recipients, a protection that is required by some protocol >>>>> bindings. If it is present, the actual recipient MUST check that the >>>>> URI reference identifies the location at which the message was receiv= ed. If it does not, the request MUST be discarded. Some protocol bindings m= ay require the use of this attribute (see [SAMLBind]). >>>>> [\quote] >>>>>=20 >>>>> In contrast, is a means of limiting the liability of >>>>> the asserting party and is described in the following manner - >>>>>=20 >>>>> [quote-saml2.0] >>>>> >>>>> A URI reference that identifies an intended audience. The URI >>>>> reference MAY identify a document that describes the terms and >>>>> conditions of audience membership. It MAY also contain the unique ide= ntifier URI from a SAML name identifier that describes a system entity (see= Section 8.3.6). >>>>> The audience restriction condition evaluates to Valid if and only if >>>>> the SAML relying party is a member of one or more of the audiences sp= ecified. >>>>>=20 >>>>> The SAML asserting party cannot prevent a party to whom the assertion >>>>> is disclosed from taking action on the basis of the information >>>>> provided. However, the element allows the SAML >>>>> asserting party to state explicitly that no warranty is provided to >>>>> such a party in a machine- and human-readable form. While there can >>>>> be no guarantee that a court would uphold such a warranty exclusion i= n every circumstance, the probability of upholding the warranty exclusion i= s considerably improved. >>>>> [\quote] >>>>>=20 >>>>> - prateek >>>>>=20 >>>>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From igor.faynberg@alcatel-lucent.com Thu Mar 21 13:36: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 A5F3A21F8CDD for ; Thu, 21 Mar 2013 13:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.399 X-Spam-Level: X-Spam-Status: No, score=-9.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v2MFEttELUV7 for ; Thu, 21 Mar 2013 13:36:27 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 761CD21F8C9D for ; Thu, 21 Mar 2013 13:36:27 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r2LKaHOS027270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 21 Mar 2013 15:36:18 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id r2LKaH9C002250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 21 Mar 2013 15:36:17 -0500 Received: from [135.222.232.243] (USMUYN0L055118.mh.lucent.com [135.222.232.243]) by umail.lucent.com (8.13.8/TPES) with ESMTP id r2LKaH00013082; Thu, 21 Mar 2013 15:36:17 -0500 (CDT) Message-ID: <514B6F40.4090107@alcatel-lucent.com> Date: Thu, 21 Mar 2013 16:36:16 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: oauth@ietf.org References: <1362079266.8952.YahooMailClassic@web141002.mail.bf1.yahoo.com> <512FCDF0.6010807@gmx.net> <5141EE22.2030306@oracle.com> <51421CA0.7010400@oracle.com> <4E1F6AAD24975D4BA5B1680429673943675115B6@TK5EX14MBXC283.redmond.corp.microsoft.com> <514B6D66.9070809@oracle.com> In-Reply-To: <514B6D66.9070809@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: Re: [OAUTH-WG] the meaning of audience in SAML vs. OAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 20:36:28 -0000 I have no problem with the replacement of "audience" by "recepient," but whether this suggestion implemented or not, I would very much like to see Prateeks elegant explanation of SAML terms and their relation to those defined in OAuth retained somewhere in the document. This would help later those who need to parse the specification without the benefit of being present at this discussion. Igor On 3/21/2013 4:28 PM, prateek mishra wrote: > Mike, Nat - > > I am honestly not sure what to propose in terms of wording > clarification. has a specific meaning in SAML and thats > different > from its current meaning in OAuth. This issue becomes even more > confusing as the SAML assertion draft goes onto > redefine the meaning of . Its processing rules for > duplicate those for the recipient attribute within > . > > In SAML request messages, models what is > represented by "audience" in Oauth. > As I mentioned above, SAML assertions utilize a recipient attribute > within the element to achieve the > same effect. > > My suggestion would be to replace "audience" by "recipient" or > "recipients". That would maintain a certain parallelism > between SAML and JWT assertions. It would also avoid the current > duplication of processing rules > for and the "recipient" attribute in the SAML > assertion draft. > > I understand that as defined in SAML 2.0 is > under-used and perhaps also widely misunderstood. Nevertheless there are > implementations that make proper use of this element and they are > gonna be quite confused when they try to > implement the SAML assertion draft. I can also see some real interop. > difficulties arising because of this mixup. > > - prateek >> well.. the aud term came from googler's use of the term and not saml. >> I agree with Prateek that the intention of the jwt:aud is rather >> similar to saml:destination. >> JWT is imposing the processing rule on it while saml:audience is >> mainly concerned about the liability. >> >> Nat >> >> >> 2013/3/15 Mike Jones: >>> The JWT meaning of the term "audience" is intended to be the same as >>> SAML. Suggested wording clarifications would be welcomed. >>> >>> -- Mike >>> >>> -----Original Message----- >>> From: prateek mishra [mailto:prateek.mishra@oracle.com] >>> Sent: Thursday, March 14, 2013 11:53 AM >>> To: Hannes Tschofenig; Mike Jones >>> Cc:oauth@ietf.org >>> Subject: the meaning of audience in SAML vs. OAuth >>> >>> Hannes - you make a good point. >>> >>> I believe that the usage of "audience" >>> inhttp://www.ietf.org/id/draft-ietf-oauth-json-web-token-06.txt >>> >>> also corresponds to rather than . >>> >>> [quote-jwt06] >>> The aud (audience) claim identifies the audiences that the JWT is >>> intended for. Each principal intended to process the JWT MUST >>> identify itself with a value in audience claim. If the principal >>> processing the claim does not identify itself with a value in the >>> aud claim, then the JWT MUST be rejected. In the general case, the >>> aud value is an array of case sensitive strings, each containing a >>> StringOrURI value. In the special case when the JWT has one >>> audience, the aud value MAY be a single case sensitive string >>> containing a StringOrURI value. The interpretation of audience >>> values is generally application specific. Use of this claim is >>> OPTIONAL. >>> [\quote] >>> >>> I think this is a point of quite some confusion (a similar problem >>> arose during the SAML assertion drafts discussion on Tuesday). >>> >>> To the extent that JWT re-uses concepts and names from SAML, I dont >>> think this is the correct name with the semantics implied by the >>> processing rules given in jwt06. >>> >>> - prateek >>> >>> >>> >>> >>> >>>> Hi Prateek, >>>> >>>> I never had planned to make the term audience to align with the >>>> SAML specification. >>>> However, in case this could lead to confusion we could also define >>>> a different term. >>>> >>>> Btw, did you look at the JWT spec whether the audience term there >>>> is inline with the SAML spec? >>>> >>>> Ciao >>>> Hannes >>>> >>>> On Mar 14, 2013, at 11:34 AM, prateek mishra wrote: >>>> >>>>> Hi Hannes, >>>>> >>>>> I wanted to point out that use of the term "audience" in this >>>>> document is not consistent with the SAML 2.0 specification. >>>>> >>>>> >>>>> What you are referring to here as "audience" corresponds to >>>>> which is described as >>>>> >>>>> [quote-saml2.0] >>>>> Destination [Optional] >>>>> A URI reference indicating the address to which this request has been >>>>> sent. This is useful to prevent malicious forwarding of requests to >>>>> unintended recipients, a protection that is required by some protocol >>>>> bindings. If it is present, the actual recipient MUST check that the >>>>> URI reference identifies the location at which the message was >>>>> received. If it does not, the request MUST be discarded. Some >>>>> protocol bindings may require the use of this attribute (see >>>>> [SAMLBind]). >>>>> [\quote] >>>>> >>>>> In contrast, is a means of limiting the liability of >>>>> the asserting party and is described in the following manner - >>>>> >>>>> [quote-saml2.0] >>>>> >>>>> A URI reference that identifies an intended audience. The URI >>>>> reference MAY identify a document that describes the terms and >>>>> conditions of audience membership. It MAY also contain the unique >>>>> identifier URI from a SAML name identifier that describes a system >>>>> entity (see Section 8.3.6). >>>>> The audience restriction condition evaluates to Valid if and only if >>>>> the SAML relying party is a member of one or more of the audiences >>>>> specified. >>>>> >>>>> The SAML asserting party cannot prevent a party to whom the assertion >>>>> is disclosed from taking action on the basis of the information >>>>> provided. However, the element allows the SAML >>>>> asserting party to state explicitly that no warranty is provided to >>>>> such a party in a machine- and human-readable form. While there can >>>>> be no guarantee that a court would uphold such a warranty >>>>> exclusion in every circumstance, the probability of upholding the >>>>> warranty exclusion is considerably improved. >>>>> [\quote] >>>>> >>>>> - prateek >>>>> >>>>> >>> _______________________________________________ >>> OAuth mailing 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 prateek.mishra@oracle.com Thu Mar 21 14:24: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 4586321F8581 for ; Thu, 21 Mar 2013 14:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_48=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 7A0X-Lp5a4yK for ; Thu, 21 Mar 2013 14:24:20 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id A115E21F8CF8 for ; Thu, 21 Mar 2013 14:24:19 -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 r2LLOG6G024062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 21 Mar 2013 21:24:17 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r2LLOGCC024718 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Mar 2013 21:24:16 GMT Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r2LLOGS3029712; Thu, 21 Mar 2013 16:24:16 -0500 Received: from [10.152.55.88] (/10.152.55.88) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 21 Mar 2013 14:24:15 -0700 Message-ID: <514B7A7C.9010206@oracle.com> Date: Thu, 21 Mar 2013 17:24:12 -0400 From: prateek mishra Organization: Oracle Corporation User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Chuck Mortimore References: <1362079266.8952.YahooMailClassic@web141002.mail.bf1.yahoo.com> <512FCDF0.6010807@gmx.net> <5141EE22.2030306@oracle.com> <51421CA0.7010400@oracle.com> <4E1F6AAD24975D4BA5B1680429673943675115B6@TK5EX14MBXC283.redmond.corp.microsoft.com> <514B6D66.9070809@oracle.com> <9D24C01D-CDDB-43BB-A8A9-CB5D2653CC3C@salesforce.com> In-Reply-To: <9D24C01D-CDDB-43BB-A8A9-CB5D2653CC3C@salesforce.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] the meaning of audience in SAML vs. OAuth X-BeenThere: oauth@ietf.org X-Mailman-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, 21 Mar 2013 21:24:29 -0000 Agreed, Chuck - I need to respond to Brian's message of Feb 14 and suggest proposed text for the draft. I plan to get to it in the next day or two. - prateek > Hey Prateek - and suggested improvements for the SAML Bearer draft? > > > On Mar 21, 2013, at 1:28 PM, prateek mishra wrote: > >> Mike, Nat - >> >> I am honestly not sure what to propose in terms of wording >> clarification. has a specific meaning in SAML and thats different >> from its current meaning in OAuth. This issue becomes even more >> confusing as the SAML assertion draft goes onto >> redefine the meaning of . Its processing rules for >> duplicate those for the recipient attribute within >> . >> >> In SAML request messages, models what is represented >> by "audience" in Oauth. >> As I mentioned above, SAML assertions utilize a recipient attribute >> within the element to achieve the >> same effect. >> >> My suggestion would be to replace "audience" by "recipient" or >> "recipients". That would maintain a certain parallelism >> between SAML and JWT assertions. It would also avoid the current >> duplication of processing rules >> for and the "recipient" attribute in the SAML assertion >> draft. >> >> I understand that as defined in SAML 2.0 is under-used >> and perhaps also widely misunderstood. Nevertheless there are >> implementations that make proper use of this element and they are gonna >> be quite confused when they try to >> implement the SAML assertion draft. I can also see some real interop. >> difficulties arising because of this mixup. >> >> - prateek >>> well.. the aud term came from googler's use of the term and not saml. >>> I agree with Prateek that the intention of the jwt:aud is rather >>> similar to saml:destination. >>> JWT is imposing the processing rule on it while saml:audience is >>> mainly concerned about the liability. >>> >>> Nat >>> >>> >>> 2013/3/15 Mike Jones: >>>> The JWT meaning of the term "audience" is intended to be the same as SAML. Suggested wording clarifications would be welcomed. >>>> >>>> -- Mike >>>> >>>> -----Original Message----- >>>> From: prateek mishra [mailto:prateek.mishra@oracle.com] >>>> Sent: Thursday, March 14, 2013 11:53 AM >>>> To: Hannes Tschofenig; Mike Jones >>>> Cc:oauth@ietf.org >>>> Subject: the meaning of audience in SAML vs. OAuth >>>> >>>> Hannes - you make a good point. >>>> >>>> I believe that the usage of "audience" inhttp://www.ietf.org/id/draft-ietf-oauth-json-web-token-06.txt >>>> >>>> also corresponds to rather than . >>>> >>>> [quote-jwt06] >>>> The aud (audience) claim identifies the audiences that the JWT is intended for. Each principal intended to process the JWT MUST identify itself with a value in audience claim. If the principal processing the claim does not identify itself with a value in the aud claim, then the JWT MUST be rejected. In the general case, the aud value is an array of case sensitive strings, each containing a StringOrURI value. In the special case when the JWT has one audience, the aud value MAY be a single case sensitive string containing a StringOrURI value. The interpretation of audience values is generally application specific. Use of this claim is OPTIONAL. >>>> [\quote] >>>> >>>> I think this is a point of quite some confusion (a similar problem arose during the SAML assertion drafts discussion on Tuesday). >>>> >>>> To the extent that JWT re-uses concepts and names from SAML, I dont think this is the correct name with the semantics implied by the processing rules given in jwt06. >>>> >>>> - prateek >>>> >>>> >>>> >>>> >>>> >>>>> Hi Prateek, >>>>> >>>>> I never had planned to make the term audience to align with the SAML specification. >>>>> However, in case this could lead to confusion we could also define a different term. >>>>> >>>>> Btw, did you look at the JWT spec whether the audience term there is inline with the SAML spec? >>>>> >>>>> Ciao >>>>> Hannes >>>>> >>>>> On Mar 14, 2013, at 11:34 AM, prateek mishra wrote: >>>>> >>>>>> Hi Hannes, >>>>>> >>>>>> I wanted to point out that use of the term "audience" in this document is not consistent with the SAML 2.0 specification. >>>>>> >>>>>> >>>>>> What you are referring to here as "audience" corresponds to >>>>>> which is described as >>>>>> >>>>>> [quote-saml2.0] >>>>>> Destination [Optional] >>>>>> A URI reference indicating the address to which this request has been >>>>>> sent. This is useful to prevent malicious forwarding of requests to >>>>>> unintended recipients, a protection that is required by some protocol >>>>>> bindings. If it is present, the actual recipient MUST check that the >>>>>> URI reference identifies the location at which the message was received. If it does not, the request MUST be discarded. Some protocol bindings may require the use of this attribute (see [SAMLBind]). >>>>>> [\quote] >>>>>> >>>>>> In contrast, is a means of limiting the liability of >>>>>> the asserting party and is described in the following manner - >>>>>> >>>>>> [quote-saml2.0] >>>>>> >>>>>> A URI reference that identifies an intended audience. The URI >>>>>> reference MAY identify a document that describes the terms and >>>>>> conditions of audience membership. It MAY also contain the unique identifier URI from a SAML name identifier that describes a system entity (see Section 8.3.6). >>>>>> The audience restriction condition evaluates to Valid if and only if >>>>>> the SAML relying party is a member of one or more of the audiences specified. >>>>>> >>>>>> The SAML asserting party cannot prevent a party to whom the assertion >>>>>> is disclosed from taking action on the basis of the information >>>>>> provided. However, the element allows the SAML >>>>>> asserting party to state explicitly that no warranty is provided to >>>>>> such a party in a machine- and human-readable form. While there can >>>>>> be no guarantee that a court would uphold such a warranty exclusion in every circumstance, the probability of upholding the warranty exclusion is considerably improved. >>>>>> [\quote] >>>>>> >>>>>> - prateek >>>>>> >>>>>> >>>> _______________________________________________ >>>> OAuth mailing 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 sakimura@gmail.com Thu Mar 21 17:21: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 CF5F421F8900 for ; Thu, 21 Mar 2013 17:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.784 X-Spam-Level: X-Spam-Status: No, score=-0.784 tagged_above=-999 required=5 tests=[AWL=-1.366, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, J_CHICKENPOX_48=0.6, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qqvkUzMuutHp for ; Thu, 21 Mar 2013 17:21:07 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 6CAE821F88BE for ; Thu, 21 Mar 2013 17:21:06 -0700 (PDT) Received: by mail-la0-f51.google.com with SMTP id fo13so6312242lab.38 for ; Thu, 21 Mar 2013 17:21:05 -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=ciL4XB4MAYXXgvebTOmdOcc6I4MvsFr7mzx95kgSnMg=; b=Gdj+Z6N/EjV1aWJIeM4UGatn2Ql2lgYy+1xZOVyNIjIbBbOAKvOXVezboi/Wex90QA uGJJ7f0M7xmuaulyRddxYIkPcqgj/omCnVEDcp9Ti+GZT+aqPG5vxdjrnHhm69rWU1no 9SwiQZRTEvCk8gg1ghs6JJl33lGhUT7T/xy+i5kVRErCv8LqsdTQdXXr29gdKzLcrbDq Nh+8kZBEfbZHx2o2jB/ukmnaWUNrP/aNYGryZtXZwtGSWr3xVqZdW2eoKI/cyEPePL6p ne70xkAWWVaRe01IA+JSWwJAEHoHb3+apfkRWWSfODaVx4/BFt4TSyQetbVr89DtXrZ/ VFOQ== MIME-Version: 1.0 X-Received: by 10.152.105.38 with SMTP id gj6mr8596262lab.25.1363911665220; Thu, 21 Mar 2013 17:21:05 -0700 (PDT) Received: by 10.112.103.202 with HTTP; Thu, 21 Mar 2013 17:21:05 -0700 (PDT) In-Reply-To: <514B6D66.9070809@oracle.com> References: <1362079266.8952.YahooMailClassic@web141002.mail.bf1.yahoo.com> <512FCDF0.6010807@gmx.net> <5141EE22.2030306@oracle.com> <51421CA0.7010400@oracle.com> <4E1F6AAD24975D4BA5B1680429673943675115B6@TK5EX14MBXC283.redmond.corp.microsoft.com> <514B6D66.9070809@oracle.com> Date: Fri, 22 Mar 2013 09:21:05 +0900 Message-ID: From: Nat Sakimura To: prateek mishra Content-Type: multipart/alternative; boundary=f46d0408d3f74f842904d8786e18 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] the meaning of audience in SAML vs. OAuth X-BeenThere: oauth@ietf.org X-Mailman-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, 22 Mar 2013 00:21:08 -0000 --f46d0408d3f74f842904d8786e18 Content-Type: text/plain; charset=ISO-8859-1 Prateek, At this point, I would like to be a bit cautious about changing the claim names as it would impact bunch of implementations that are potentially being used by hundreds of millions of users now. I am more open to change the text that defines "aud". Currently, it goes: 4.1.3. "aud" (Audience) Claim The "aud" (audience) claim identifies the audiences that the JWT is intended for. Each principal intended to process the JWT MUST identify itself with a value in audience claim. If the principal processing the claim does not identify itself with a value in the "aud" claim, then the JWT MUST be rejected. In the general case, the "aud" value is an array of case sensitive strings, each containing a StringOrURI value. In the special case when the JWT has one audience, the "aud" value MAY be a single case sensitive string containing a StringOrURI value. The interpretation of audience values is generally application specific. Use of this claim is OPTIONAL. Personally, I think there are two ways to change it. The first way (Type 1) removes the processing requirements from aud claim. As an individual expert, I feel that JWT should not mandate the processing requirement on aud, but just give the semantics of it and let the protocols/profiles decide on the processing rules. 4.1.3. "aud" (Audience) Claim The "aud" (audience) claim specifies the audiences that the JWT is intended for. In the general case, the "aud" value is an array of case sensitive strings, each containing a StringOrURI value. In the special case when the JWT has one audience, the "aud" value MAY be a single case sensitive string containing a StringOrURI value. The interpretation of audience values is generally application specific. Use of this claim is OPTIONAL. Note 1: The issuer cannot prevent a party to whom the token is disclosed from taking action on the basis of the information provided. However, the aud claim allows the issuer to state explicitly that no warranty is provided to such a party in a machine readable form. While there can be no guarantee that a court would uphold such a warranty exclusion in every circumstance, the probability of upholding the warranty exclusion is considerably improved. A slight variation of Type 1 (Type 1a) alignes more closely to SAML's definition. (Much of the text is straight out of SAML Core 2.0) 4.1.3. "aud" (Audience Restriction) Claim The "aud" (audience restriction) claim specifies that the JWT is addressed to one or more specific audiences identified by the elements of its value. Although a receiving party that is outside the audiences specified is capable of drawing conclusions from the token, the issuer explicitly makes no representation as to accuracy or trustworthiness to such a party. In the general case, the "aud" value is an array of case sensitive strings, each containing a StringOrURI value that identifies the audience intended for. In the special case when the JWT has one audience, the "aud" value MAY be a single case sensitive string containing a StringOrURI value. The interpretation of audience restriction values is generally application specific. Use of this claim is OPTIONAL. Note 1: The issuer cannot prevent a party to whom the token is disclosed from taking action on the basis of the information provided. However, the aud claim allows the issuer to state explicitly that no warranty is provided to such a party in a machine readable form. While there can be no guarantee that a court would uphold such a warranty exclusion in every circumstance, the probability of upholding the warranty exclusion is considerably improved. The second way (Type 2) is to change the acronym text. 4.1.3. "aud" (Assertion Usage Destination) Claim The "aud" (assertion usage destination) claim identifies the party that the JWT is intended for. Each party intended to process the JWT MUST identify itself with a value in audience claim. If the party processing the claim does not identify itself with a value in the "aud" claim, then the JWT MUST be rejected. In the general case, the "aud" value is an array of case sensitive strings, each containing a StringOrURI value. In the special case when the JWT has one audience, the "aud" value MAY be a single case sensitive string containing a StringOrURI value. The interpretation of audience values is generally application specific. Use of this claim is OPTIONAL. Note that I changed principal to party, since principal has more specific meaning than wanted here. Among them, I actually prefer Type 1a as I believe that JWT should be generic. BTW, I feel that the way aud is written now is a bit confusing to developers. Is the value of the aud claim an array or string? It should still spell it out that both are permitted more explicitly. Nat 2013/3/22 prateek mishra > Mike, Nat - > > I am honestly not sure what to propose in terms of wording clarification. > has a specific meaning in SAML and thats different > from its current meaning in OAuth. This issue becomes even more confusing > as the SAML assertion draft goes onto > redefine the meaning of . Its processing rules for > duplicate those for the recipient attribute within > . > > In SAML request messages, models what is represented by > "audience" in Oauth. > As I mentioned above, SAML assertions utilize a recipient attribute within > the element to achieve the > same effect. > > My suggestion would be to replace "audience" by "recipient" or > "recipients". That would maintain a certain parallelism > between SAML and JWT assertions. It would also avoid the current > duplication of processing rules > for and the "recipient" attribute in the SAML assertion > draft. > > I understand that as defined in SAML 2.0 is under-used > and perhaps also widely misunderstood. Nevertheless there are > implementations that make proper use of this element and they are gonna be > quite confused when they try to > implement the SAML assertion draft. I can also see some real interop. > difficulties arising because of this mixup. > > - prateek > >> well.. the aud term came from googler's use of the term and not saml. >> I agree with Prateek that the intention of the jwt:aud is rather >> similar to saml:destination. >> JWT is imposing the processing rule on it while saml:audience is >> mainly concerned about the liability. >> >> Nat >> >> >> 2013/3/15 Mike Jones >> >: >> >>> The JWT meaning of the term "audience" is intended to be the same as >>> SAML. Suggested wording clarifications would be welcomed. >>> >>> -- Mike >>> >>> -----Original Message----- >>> From: prateek mishra [mailto:prateek.mishra@oracle.**com >>> ] >>> Sent: Thursday, March 14, 2013 11:53 AM >>> To: Hannes Tschofenig; Mike Jones >>> Cc:oauth@ietf.org >>> Subject: the meaning of audience in SAML vs. OAuth >>> >>> Hannes - you make a good point. >>> >>> I believe that the usage of "audience" inhttp://www.ietf.org/id/** >>> draft-ietf-oauth-json-web-**token-06.txt >>> >>> >>> also corresponds to rather than . >>> >>> [quote-jwt06] >>> The aud (audience) claim identifies the audiences that the JWT is >>> intended for. Each principal intended to process the JWT MUST identify >>> itself with a value in audience claim. If the principal processing the >>> claim does not identify itself with a value in the aud claim, then the JWT >>> MUST be rejected. In the general case, the aud value is an array of case >>> sensitive strings, each containing a StringOrURI value. In the special case >>> when the JWT has one audience, the aud value MAY be a single case sensitive >>> string containing a StringOrURI value. The interpretation of audience >>> values is generally application specific. Use of this claim is OPTIONAL. >>> [\quote] >>> >>> I think this is a point of quite some confusion (a similar problem arose >>> during the SAML assertion drafts discussion on Tuesday). >>> >>> To the extent that JWT re-uses concepts and names from SAML, I dont >>> think this is the correct name with the semantics implied by the processing >>> rules given in jwt06. >>> >>> - prateek >>> >>> >>> >>> >>> >>> Hi Prateek, >>>> >>>> I never had planned to make the term audience to align with the SAML >>>> specification. >>>> However, in case this could lead to confusion we could also define a >>>> different term. >>>> >>>> Btw, did you look at the JWT spec whether the audience term there is >>>> inline with the SAML spec? >>>> >>>> Ciao >>>> Hannes >>>> >>>> On Mar 14, 2013, at 11:34 AM, prateek mishra wrote: >>>> >>>> Hi Hannes, >>>>> >>>>> I wanted to point out that use of the term "audience" in this document >>>>> is not consistent with the SAML 2.0 specification. >>>>> >>>>> >>>>> What you are referring to here as "audience" corresponds to >>>>> which is described as >>>>> >>>>> [quote-saml2.0] >>>>> Destination [Optional] >>>>> A URI reference indicating the address to which this request has been >>>>> sent. This is useful to prevent malicious forwarding of requests to >>>>> unintended recipients, a protection that is required by some protocol >>>>> bindings. If it is present, the actual recipient MUST check that the >>>>> URI reference identifies the location at which the message was >>>>> received. If it does not, the request MUST be discarded. Some protocol >>>>> bindings may require the use of this attribute (see [SAMLBind]). >>>>> [\quote] >>>>> >>>>> In contrast, is a means of limiting the liability of >>>>> the asserting party and is described in the following manner - >>>>> >>>>> [quote-saml2.0] >>>>> >>>>> A URI reference that identifies an intended audience. The URI >>>>> reference MAY identify a document that describes the terms and >>>>> conditions of audience membership. It MAY also contain the unique >>>>> identifier URI from a SAML name identifier that describes a system entity >>>>> (see Section 8.3.6). >>>>> The audience restriction condition evaluates to Valid if and only if >>>>> the SAML relying party is a member of one or more of the audiences >>>>> specified. >>>>> >>>>> The SAML asserting party cannot prevent a party to whom the assertion >>>>> is disclosed from taking action on the basis of the information >>>>> provided. However, the element allows the SAML >>>>> asserting party to state explicitly that no warranty is provided to >>>>> such a party in a machine- and human-readable form. While there can >>>>> be no guarantee that a court would uphold such a warranty exclusion in >>>>> every circumstance, the probability of upholding the warranty exclusion is >>>>> considerably improved. >>>>> [\quote] >>>>> >>>>> - prateek >>>>> >>>>> >>>>> ______________________________**_________________ >>> 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 --f46d0408d3f74f842904d8786e18 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Prateek,=A0

At this point, I would like to be a bi= t cautious about changing the claim names as it would impact bunch of imple= mentations that are potentially being used by hundreds of millions of users= now.=A0

I am more open to change the text that defines "aud&quo= t;.=A0

Currently, it goes:=A0

= 
4.1.3.  "aud" (Audience) Claim

   The "aud" (audience) claim identifies the audiences that the J=
WT is
   intended for.  Each principal intended to process the JWT MUST
   identify itself with a value in audience claim.  If the principal
   processing the claim does not identify itself with a value in the
   "aud" claim, then the JWT MUST be rejected.  In the general ca=
se, the
   "aud" value is an array of case sensitive strings, each contai=
ning a
   StringOrURI value.  In the special case when the JWT has one
   audience, the "aud" value MAY be a single case sensitive strin=
g
   containing a StringOrURI value.  The interpretation of audience
   values is generally application specific.  Use of this claim is
   OPTIONAL.

Personally, I think= there are two ways to change it.=A0

The first way= (Type 1) removes the processing requirements from aud claim.=A0
As an individual expert, I feel that JWT should not mandate the processing = requirement on aud,=A0
but just give the semantics of it and let = the protocols/profiles decide on the processing rules.=A0

4.1.3.  "aud" (Audience) Claim

   The "aud" (audience) claim specifies the audiences that the JW=
T is
   intended for. In the general case, the
   "aud" value is an array of case sensitive strings, each contai=
ning a
   StringOrURI value.  In the special case when the JWT has one
   audience, the "aud" value MAY be a single case sensitive strin=
g
   containing a StringOrURI value.  The interpretation of audience
   values is generally application specific.  Use of this claim is
   OPTIONAL.
   Note 1: The issuer cannot p=
revent a party to whom the token is=20
   disclosed from taking action on the basis of the information provided.=
=20
   However, the aud claim allows the issuer to state explicitly that=20
   no warranty is provided to such a party in a machine readable form.=20
   While there can be no guarantee that a court would uphold such=20
   a warranty exclusion in every circumstance, the probability of=20
   upholding the warranty exclusion is considerably improved.
<= /div>
A slight variation of Type 1 (Type 1a) alignes more closely to SA= ML's definition.=A0
(Much of the text is straight out of SAML= Core 2.0)

4.1.3.  "aud" (Audience R=
estriction) Claim
=A0 =A0The "aud" (audience restriction) claim specifies = that=A0
=A0 =A0the JWT is addressed to o= ne or more specific audiences identified=A0
=A0 =A0by the elements of its value. Although a rec= eiving party=A0
=A0 =A0that is outside the audie= nces specified is capable of=A0
=A0 =A0drawing conclusions from the token, the issuer explicitl= y makes=A0
=A0 =A0no representation as to a= ccuracy or trustworthiness to such a party.=A0
=A0 =A0
=A0 =A0In the general case, the "aud" value is an= array of case sensitive=A0
=A0 =A0strings, each containing = a StringOrURI value that identifies the =A0=A0
=A0 =A0audience intended for. In the special ca= se when the JWT has one
=A0 =A0audience, the "aud&q= uot; value MAY be a single case sensitive string
=A0 =A0containing a StringOrURI value. =A0The = interpretation of audience
=A0 =A0restriction values is gen= erally application specific. =A0
=A0 =A0Use of this claim is OPTIONAL.
=A0 =A0
=A0 =A0Note 1: The issuer cannot= prevent a party to whom the token is=A0
=A0 =A0disclosed from taking action on the basis of th= e information provided.=A0
=A0 =A0However, the aud claim al= lows the issuer to state explicitly that=A0
=A0 =A0no warranty is provided to such a party in a= machine readable form.=A0
=A0 =A0While there can be no gua= rantee that a court would uphold such=A0
=A0 =A0a warranty exclusion in every circumstance, the= probability of=A0
=A0 =A0upholding the warranty ex= clusion is considerably improved.

The second way (Type 2) =A0is to change the acronym text.=A0

4.1.3.  "aud" (Assertion Usage=
 Destination) Claim

   The "aud" (assertion usage destination) claim identifies=20
   the party that the JWT is intended for. =20
   Each party intended to process the JWT MUST
   identify itself with a value in audience claim.  If the party=20
   processing the claim does not identify itself with a value in the
   "aud" claim, then the JWT MUST be rejected.  In the general ca=
se, the
   "aud" value is an array of case sensitive strings, each contai=
ning a
   StringOrURI value.  In the special case when the JWT has one
   audience, the "aud" value MAY be a single case sensitive strin=
g
   containing a StringOrURI value.  The interpretation of audience
   values is generally application specific.  Use of this claim is
   OPTIONAL.
Note that I changed principal to party, since principal ha= s more specific meaning than wanted here.=A0

Among= them, I actually prefer Type 1a as I believe that JWT should be generic.= =A0


BTW, I feel that the way aud is written = now is a bit confusing to developers.=A0
Is the value of the aud = claim an array or string? =A0
It should still spell it out that b= oth are permitted more explicitly.=A0

Nat


2013/3/22 prateek mishra <prateek.mishra@oracle.com>
Mike, Nat -

I am honestly not sure what to propose in terms of wording clarification. &= lt;Audience> has a specific meaning in SAML and thats different
from its current meaning in OAuth. This issue becomes even more confusing a= s the SAML assertion draft goes onto
redefine the meaning of <saml:audience>. Its processing rules for <= ;saml:audience> duplicate those for the recipient attribute within <s= aml:SubjectConfirmation>.

In SAML request messages, <saml:destination> models what is represent= ed by "audience" in Oauth.
As I mentioned above, SAML assertions utilize a recipient attribute within = the <saml:SubjectConfirmation> element to achieve the
same effect.

My suggestion would be to replace "audience" by "recipient&q= uot; or "recipients". That would maintain a certain parallelism between SAML and JWT assertions. It would also avoid the current duplicatio= n of processing rules
for <saml:audience> and the "recipient" attribute in the SA= ML assertion draft.

I understand that <saml:Audience> as defined in SAML 2.0 =A0is under-= used and perhaps also widely misunderstood. Nevertheless there are
implementations that make proper use of this element and they are gonna be = quite confused when they try to
implement the SAML assertion draft. I can also see some real interop. diffi= culties arising because of this mixup.

- prateek
well.. the aud term came from googler's use of the term and not saml. I agree with Prateek that the intention of the jwt:aud is rather
similar to saml:destination.
JWT is imposing the processing rule on it while saml:audience is
mainly concerned about the liability.

Nat


2013/3/15 Mike Jones<Michael.Jones@microsoft.com>:
The JWT meaning of the term "audience" is intended to be the same= as SAML. =A0Suggested wording clarifications would be welcomed.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-- Mike<= br>
-----Original Message-----
From: prateek mishra [mailto:prateek.mishra@oracle.com]
Sent: Thursday, March 14, 2013 11:53 AM
To: Hannes Tschofenig; Mike Jones
Cc:oauth@ietf.org<= /a>
Subject: the meaning of audience in SAML vs. OAuth

Hannes - you make a good point.

I believe that the usage of "audience" inhttp://= www.ietf.org/id/draft-ietf-oauth-json-web-token-06.txt


also corresponds to <saml:destination> rather than <saml:audience&= gt;.

[quote-jwt06]
The aud (audience) claim identifies the audiences that the JWT is intended = for. Each principal intended to process the JWT MUST identify itself with a= value in audience claim. If the principal processing the claim does not id= entify itself with a value in the aud claim, then the JWT MUST be rejected.= In the general case, the aud value is an array of case sensitive strings, = each containing a StringOrURI value. In the special case when the JWT has o= ne audience, the aud value MAY be a single case sensitive string containing= a StringOrURI value. The interpretation of audience values is generally ap= plication specific. Use of this claim is OPTIONAL.
[\quote]

I think this is a point of quite some confusion (a similar problem arose du= ring the SAML assertion drafts discussion on Tuesday).

To the extent that JWT re-uses concepts and names from SAML, I dont think t= his is the correct name with the semantics implied by the processing rules = given in jwt06.

- prateek





Hi Prateek,

I never had planned to make the term audience to align with the SAML specif= ication.
However, in case this could lead to confusion we could also define a differ= ent term.

Btw, did you look at the JWT spec whether the audience term there is inline= with the SAML spec?

Ciao
Hannes

On Mar 14, 2013, at 11:34 AM, prateek mishra wrote:

Hi Hannes,

I wanted to point out that use of the term "audience" in this doc= ument is not consistent with the SAML 2.0 specification.


What you are referring to here as "audience" corresponds to
<saml:destination> which is described as

[quote-saml2.0]
Destination [Optional]
A URI reference indicating the address to which this request has been
sent. This is useful to prevent malicious forwarding of requests to
unintended recipients, a protection that is required by some protocol
bindings. If it is present, the actual recipient MUST check that the
URI reference identifies the location at which the message was received. If= it does not, the request MUST be discarded. Some protocol bindings may req= uire the use of this attribute (see [SAMLBind]).
[\quote]

In contrast, <saml:audience> =A0is a means of limiting the liability = of
the asserting party and is described in the following manner -

[quote-saml2.0]
=A0 =A0<Audience>
A URI reference that identifies an intended audience. The URI
reference MAY identify a document that describes the terms and
conditions of audience membership. It MAY also contain the unique identifie= r URI from a SAML name identifier that describes a system entity (see Secti= on 8.3.6).
The audience restriction condition evaluates to Valid if and only if
the SAML relying party is a member of one or more of the audiences specifie= d.

The SAML asserting party cannot prevent a party to whom the assertion
is disclosed from taking action on the basis of the information
provided. However, the <AudienceRestriction> element allows the SAML<= br> asserting party to state explicitly that no warranty is provided to
such a party in a machine- and human-readable form. While there can
be no guarantee that a court would uphold such a warranty exclusion in ever= y circumstance, the probability of upholding the warranty exclusion is cons= iderably improved.
[\quote]

- prateek


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





--
Nat Sakimura= (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
--f46d0408d3f74f842904d8786e18-- From sakimura@gmail.com Thu Mar 21 17:35: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 8DB8621F8BF6 for ; Thu, 21 Mar 2013 17:35:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.225 X-Spam-Level: X-Spam-Status: No, score=-1.225 tagged_above=-999 required=5 tests=[AWL=-0.379, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, 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 cV1aRc+QlYZZ for ; Thu, 21 Mar 2013 17:35:25 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 1B98821F8BF4 for ; Thu, 21 Mar 2013 17:35:23 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id ek20so6316667lab.30 for ; Thu, 21 Mar 2013 17:35:23 -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=b3Yh0zHV0aPfMQjBNjSn5Et74eg9fzYG7Qw9McUurbI=; b=l3bMsLZA8c5cUcVv/PPDwZRIr0NhxGrNKAf6kyW2Avf7V0WFcBfRDTpHGX1nuSuHBI c3jL+4zqg/pq60T4pPWgCuq5VJf4MMJ6AS1GyBR6N0zXFnYOEtGn/etN4lmbesvoCDbb xoe1Xg21z+Y4dNQdegbplec92fOMfXp172PQW7OT0i4qGFqVVBpJKpc0rK2D2w5YhmOf 1FfkWdfBOIEw4peNY0/V6eia5Io9vlcqT93qx5Yzmdn/z9cy9/S2CvlpDutrvmZ5/BE3 l0HvC2uPcD+aOUnBKl1toC3lfC3HG8GxXM/KoBYGI/t6qm1vTUscFPcT7aiSG6V8+rOA yCCQ== MIME-Version: 1.0 X-Received: by 10.112.87.132 with SMTP id ay4mr100544lbb.87.1363912522905; Thu, 21 Mar 2013 17:35:22 -0700 (PDT) Received: by 10.112.103.202 with HTTP; Thu, 21 Mar 2013 17:35:22 -0700 (PDT) In-Reply-To: <514B4E28.7000309@mitre.org> References: <1B4C0C9F-4B8E-4B2D-BAF7-665D3EBBE56C@ve7jtb.com> <51408B8B.9000800@mitre.org> <5141E2E6.9020701@aol.com> <5141E671.2050708@mitre.org> <4E1F6AAD24975D4BA5B16804296739436750F5E2@TK5EX14MBXC283.redmond.corp.microsoft.com> <5149F092.7070902@mitre.org> <4E1F6AAD24975D4BA5B168042967394367565FEF@TK5EX14MBXC283.redmond.corp.microsoft.com> <5149F534.1040500@mitre.org> <4E1F6AAD24975D4BA5B168042967394367567185@TK5EX14MBXC283.redmond.corp.microsoft.com> <514B4E28.7000309@mitre.org> Date: Fri, 22 Mar 2013 09:35:22 +0900 Message-ID: From: Nat Sakimura To: Justin Richer Content-Type: multipart/alternative; boundary=f46d0401f8fb6ec68504d878a1d0 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readable names X-BeenThere: oauth@ietf.org X-Mailman-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, 22 Mar 2013 00:35:31 -0000 --f46d0401f8fb6ec68504d878a1d0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Can we tighten it a bit as to the encoding is concerned? I believe all the fields value MUST be UTF-8, so it propagates here as well. Saying that it must not make any assumption on character set (e.g., UTF-8) is a bit too much. Proposed text: Fields with human-readable values or references to human-readable values, such as client_name, tos_uri, policy_uri, and client_uri, MAY be represented in multiple languages and scripts, specified by appending a # character and the RFC5646 language tag. If any such human-readable field is sent without a language tag, the server and the client MUST NOT make any assumptions about the language, script, and country of the value string, and the value string MUST be used as-is wherever it is presented in either the client or server UI. To facilitate interoperability, it is RECOMMENDED that any fields sent without language tags contain an internationalized UTF-8 string suitable for display on a wide variety of systems, and it is RECOMMENDED that clients send fields without language tags in addition to any more-specifically denominated values. 2013/3/22 Justin Richer > We discussed this issue on the OpenID Connect WG call this morning, in a > conversation that included myself, George Fletcher, Nat Sakimura, Mike > Jones, and John Bradley (among others) as active participants in this > thread. After lots of debate, we propose that the OAuth DynReg adopt the > hashtag-based localization method of OIDC (and it seems, possibly > webfinger) and explicitly declare that neither the client nor the server > make any assumptions about the content of the string and treat it as just a > string. I'm proposing this text to that effect (with the references to > OIDC-messages removed and replaced with the rule description itself in > OAuth DynReg): > > Fields with human-readable values or references to human-readable values, > such as client_name, tos_uri, policy_uri, and client_uri, MAY be > represented in multiple languages and scripts, specified by appending a # > character and the RFC5646 language tag. If any such human-readable field is > sent without a language tag, the server and the client MUST NOT make any > assumptions about the language, character set, or script of the value > string, and the value string MUST be used as-is wherever it is presented in > either the client or server UI. To facilitate interoperability, it is > RECOMMENDED that any fields sent without language tags contain an > internationalized UTF-8 string suitable for display on a wide variety of > systems, and it is RECOMMENDED that clients send fields without language > tags in addition to any more-specifically denominated values. > > > Plus some examples. > > (Anyone whose name I took in vain, please feel free to correct me.) > > -- Justin > > > On 03/20/2013 03:11 PM, Justin Richer wrote: > > I agree that I'm seeing things from the single-language and > single-encoding perspective here, and that's the use case I'm currently > solving for with my development. I want to see this one remain simple, and > I think we can do that without breaking other use cases. > > I would argue that multi-script languages (such as Chinese, Japanese, and > others) are all cases where you're going to assume multiple languages, and > the tags would be necessary for real use. So client and AS would both need > to know how to deal with the multiple different tags, and smart ones would > be able to effectively ignore the default field. The default, scriptless > field could be for any one of the supported languages at the AS or Client, > and it'd effectively be a backup, internationalized version, the one that > you use when there's nothing else more specific to use. > > I guess what's getting me stuck on the explicit locale field is that I'm > not seeing much value in requiring it over George's proposal of always > using language tags on everything (which I also don't like, but for > different reasons). Having the information doesn't mean that you can do > anything intelligent with it, either, but I can see the argument that it > makes doing something smart possible. But on the other hand, we already > have a mechanism for doing something smart: using the explicit language > tags directly. > > Also, note that the AS doesn't need to render any characters for tos_uri, > policy_uri, and other _uri options, just for client_name. That's why I was > making the distinction in my explanation below. You might want to give the > user the right option, sure, but a served webpage has a much better chance > of getting the locale right dynamically than an included string would have > (approaches like user preferences, browser settings, etc. -- everything > that's used today on web pages, in other words). This is why I think that > the _uri claims are in a different category and we're talking almost > exclusively about client_name here. > > I think, ultimately, that I need to think about this more. > > -- Justin > > On 03/20/2013 02:30 PM, Mike Jones wrote: > > I suspect you only feel that leaving the locale information out is OK > because you (and I) live in a culture where it$B!G(Bs not needed to adequately > render characters. I$B!G(Bd actually defer on this decision to Nat and others > from Japan and China (and I think Korea?) where I believe that this > information is essential.**** > > ** ** > > For what it$B!G(Bs worth, it$B!G(Bs more than just client_name. It$B!G(Bs also tos_uri > and policy_uri and potentially client_uri.**** > > ** ** > > Also, having thought about it for a few days, I$B!G(Bd change the proposed > field name from registration_locale to default_registration_locale, so the > meaning is clearer.**** > > ** ** > > Nat and others from Eastern cultures, what is your opinion on this?**** > > ** ** > > Thanks,**** > > -- Mike**** > > ** ** > > *From:* Justin Richer [mailto:jricher@mitre.org ] > *Sent:* Wednesday, March 20, 2013 10:43 AM > *To:* Mike Jones > *Cc:* George Fletcher; oauth@ietf.org WG > *Subject:* Re: [OAUTH-WG] Registration: Internationalization of > Human-Readable names**** > > ** ** > > I would say that claims without a language parameter, which I would make > REQUIRED in the presence of other claims, would be treated as UTF8 strings > with no guarantee of what language, script, or other locale-specific > information would be in there. It's a default string, and it's the best the > client can give if nothing more specific is useful. And servers would have > to accept this default string and do their best with it. A service provider > can publish their expected default locale information in either discovery > or service documentation, and clients that want to tweak things for > specific service providers can do that. > > The server can display it (because it's a string that'll always be there, > if any version is there), but a server that doesn't do internationalized > strings very well might not get its display correct. Since displayable text > this is likely to be dumped into the middle of a webpage that has its own > character encoding and other considerations anyway, so it's not guaranteed > that specifying a locale will always help here anyway. This is just for the > displayable text, which right now is only the client_name field in OAuth > and OIDC: for URLs (the other "human-readable" field), it's a moot point, > because the server's just going to spit out the URL itself into an href of > some flavor. The server doesn't have to deal with any kind of encoding or > text/script issues here. > > As a server developer, it's just another thing that I *have* to track and > deal with on the client model, even if I don't want to support the rest of > the multi-language tags in my service. As a client developer, it's one more > thing that I *have* to specify when I send things to the server. I don't > see how requiring its specification is going to really help > interoperability, and I can almost guarantee that implementations will just > leave it off even if marked REQUIRED (like how many, many documents in the > wild that are supposed to have a character-encoding field of some type just > leave it off). > > I think that it's a lot of work on both sides for just client_name. > > -- Justin > > **** > > On 03/20/2013 01:27 PM, Mike Jones wrote:**** > > How would you do this instead then?**** > ------------------------------ > > *From: *Justin Richer > *Sent: *3/20/2013 10:25 AM > *To: *Mike Jones > *Cc: *George Fletcher; oauth@ietf.org WG > *Subject: *Re: [OAUTH-WG] Registration: Internationalization of > Human-Readable names**** > > Personally, I think that this level of specificity is overkill. > > -- Justin > > **** > > On 03/14/2013 11:42 AM, Mike Jones wrote:**** > > I agree that having unadorned values likely simplifies things in many > cases, but if we do this, we should let the Client say what language/script > it$B!G(Bs using when providing human-readable strings or references to them as > registration parameters. For this purpose, I$B!G(Bd propose that we have a > parameter something like this one:**** > > **** > > registration_locale**** > > OPTIONAL or REQURED. Language and script used for human-readable values or > references to human-readable values that are supplied without > language/script tags, represented as a BCP47[RFC5646] language tag value. > This parameter is REQUIRED if any human-readable values or references to > human-readable are provided without language/script tags.**** > > **** > > -- Mike**** > > **** > > *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] > *On Behalf Of *Justin Richer > *Sent:* Thursday, March 14, 2013 8:02 AM > *To:* George Fletcher > *Cc:* oauth@ietf.org WG > *Subject:* Re: [OAUTH-WG] Registration: Internationalization of > Human-Readable names**** > > **** > > On the surface this does simplify things, but the issue I forsee with it > is that I want to be able to call "client.getClientName()" and always get > *something* out of it if there are *any* client_name fields at all. So in > this world if I take a client library that assumes en-us and it talks to a > server that only looks for es-cl, there's a very real chance of the client > name not getting set at all. I think that's a problem. > > This is why I think the default field name (without the language tag) > really should be required and should be left undefined as to what language > and script it is. Essentially, "It's a UTF8 String, hope for the best". If > you want something more specific and smart about localization, then you can > support the language tags. If you just want to have a string to store and > throw at the user, then you can just use the bare field name. > > In other words, we take what we have now (which works for a > non-internationalized case where everyone just assumes a common > language/script), and we augment it with features that let it be smarter if > you want it to be smarter. Make the simple case simple, make the > complicated case possible. > > -- Justin > > **** > > On 03/14/2013 10:47 AM, George Fletcher wrote:**** > > As a simplifying option... why not just require human-readable fields to > require a "script-tag". This way it is always explicit what language/locale > the text is for. It then becomes the responsibility of the AS to return an > appropriate response if there is not a direct match between a request and > the data stored at the AS (and out of scope of the spec). > > Thanks, > George**** > > On 3/13/13 10:22 AM, Justin Richer wrote:**** > > So with what little feedback I've gotten, I'm proposing to add text from > the proposed webfinger and OIDC drafts for the hash-based localization of > strings, with the following properties: > > * All localized versions of fields are fully optional on both client and > server > * If a localized version of a field is included, its bare-value (perhaps > internationalized) field MUST be included > * All human-readable fields are eligible for this mechanism (including any > uri's for user-facing web pages, which can be used to point to > language-specific pages) > * Clients and servers can decide to use whatever language/script they want > to for the bare-value field, and no assumptions can be made on either side > about what that is > > I think that with these constraints, we can add functionality to address > Stephen's concerns without getting too complicated or putting too much > burden of support. > > -- Justin**** > > On 03/11/2013 06:52 PM, Nat Sakimura wrote:**** > > Similar work is in progress at Webfinger. **** > > **** > > See: http://www.ietf.org/mail-archive/web/webfinger/current/msg00530.html* > *** > > **** > > Paul is proposing the same syntax as Connect. **** > > 2013/3/12 Richer, Justin P. **** > > It does presume a definition of "claim", which I suppose we could turn to > "metadata field" for DynReg and its extensions to be appropriately > limiting. But we also need a good definition of what a language-tag-less > field means, and whether or not it's required if the other fields are > present or not (which is something that Connect is trying to fix at the > moment, as I recall from last week). **** > > **** > > So it turns into about a paragraph worth of text. Is that worth it? I'm > not entirely convinced that it is, but I'm interested to hear what others > think, particularly those who *aren't* tied into the OpenID Connect > protocol so much. (I don't want to pick a solution just because it's > familiar, if we need a solution at all.)**** > > **** > > -- Justin**** > > **** > > On Mar 11, 2013, at 6:35 PM, Brian Campbell ** > ** > > wrote:**** > > ** ** > > A fair question but what would need to be pulled in is really probably > only a couple sentences (and reference) from > http://openid.net/specs/openid-connect-messages-1_0-16.html#ClaimsLanguagesAndScripts(note the reference to 2.1.1.1.3 inside > http://openid.net/specs/openid-connect-registration-1_0-15.html is broken) > **** > > **** > > On Mon, Mar 11, 2013 at 6:26 PM, Richer, Justin P. > wrote:**** > > My concern with this is that OIDC can get away with defining this > multi-language structure because it defines the mechanism once (in > Messages) and applies it to all user-readable strings throughout the whole > application protocol, of which there are several. Do we really want to pull > in that whole structure and mechanism for one field in client registration? > I really don't think it should be something that's defined completely > inside of DynReg for a corner case for a single field, but I also doubt we > want to normatively point to OIDC Messages for this solution either. ** ** > > **** > > There are also other ways to do this: Webfinger [1] for instance uses JSON > structures to give language tags to field values, and has a default > mechanism:**** > > **** > > { "en_us": "my client", $B!D(B }**** > > **** > > The fundamental question is this: should a client be able to register > multiple names (in different locales) with a single client_id, or should it > get a different client_id for each display language set?**** > > **** > > -- Justin**** > > **** > > [1] http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-11**** > > **** > > On Mar 11, 2013, at 5:54 PM, John Bradley **** > > wrote:**** > > ** ** > > That is what I was thinking. It would be up to the AS to determine what > language and script to present based on the user preference. **** > > **** > > While a large number of clients will be native and might be able to > customize themselves for a single user during registration , we don't want > to forget the web server clients that are multi user.**** > > **** > > On 2013-03-11, at 10:49 PM, Brian Campbell > wrote:**** > > ** ** > > FWIW, the closely related OpenID Connect client registration draft does > have some support for doing this, which could maybe be borrowed. See > client_name in $B!x(B2 at > http://openid.net/specs/openid-connect-registration-1_0-15.html#client-metadataand the examples. > **** > > "client_name": "My Example",**** > > "client_name#ja-Jpan-JP":"$B%/%i%$%"%s%HL>(B",**** > > **** > > **** > > On Mon, Mar 11, 2013 at 5:15 PM, Richer, Justin P. > wrote:**** > > It was brought up at the in-person meeting today that we'll want to > consider issues around internationalization and localization of > human-readable fields like client_name in the client registration. Which is > to say: if a client supports ten languages and wants to present itself in > ten languages, should it have to register itself ten times with an AS? > > At the moment, I'm of the opinion a client with ten languages could > register itself ten times, or do something with the context in which it > runs to determine which human-facing language to use. Keep in mind that in > some cases (such as native clients), you'll be dynamically registering a > client for each user, in effect. In other words, I personally think that > this is a rathole that will cause more harm than good. > > -- Justin > _______________________________________________ > OAuth mailing 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**** > > > > **** > > **** > > -- > Nat Sakimura (=nat) **** > > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en**** > > > > > **** > > _______________________________________________**** > > OAuth mailing list**** > > OAuth@ietf.org**** > > https://www.ietf.org/mailman/listinfo/oauth**** > > **** > > **** > > ** ** > > ** ** > > > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --f46d0401f8fb6ec68504d878a1d0 Content-Type: text/html; charset=ISO-2022-JP Content-Transfer-Encoding: base64 Q2FuIHdlIHRpZ2h0ZW4gaXQgYSBiaXQgYXMgdG8gdGhlIGVuY29kaW5nIGlzIGNvbmNlcm5lZD8m bmJzcDs8ZGl2PkkgYmVsaWV2ZSBhbGwgdGhlIGZpZWxkcyB2YWx1ZSBNVVNUIGJlIFVURi04LCBz byBpdCBwcm9wYWdhdGVzIGhlcmUgYXMgd2VsbC4gJm5ic3A7PC9kaXY+PGRpdj5TYXlpbmcgdGhh dCBpdCBtdXN0IG5vdCBtYWtlIGFueSBhc3N1bXB0aW9uIG9uIGNoYXJhY3RlciBzZXQgKGUuZy4s IFVURi04KSBpcyBhIGJpdCB0b28gbXVjaC4mbmJzcDs8L2Rpdj4NCjxkaXY+UHJvcG9zZWQgdGV4 dDombmJzcDs8L2Rpdj48ZGl2Pjxicj48L2Rpdj48YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luOjAg MCAwIDQwcHg7Ym9yZGVyOm5vbmU7cGFkZGluZzowcHgiPjxkaXY+RmllbGRzIHdpdGggaHVtYW4t cmVhZGFibGUgdmFsdWVzIG9yIHJlZmVyZW5jZXMgdG8gaHVtYW4tcmVhZGFibGUgdmFsdWVzLCBz dWNoIGFzIGNsaWVudF9uYW1lLCB0b3NfdXJpLCBwb2xpY3lfdXJpLCBhbmQgY2xpZW50X3VyaSwg TUFZIGJlIHJlcHJlc2VudGVkIGluIG11bHRpcGxlIGxhbmd1YWdlcyBhbmQgc2NyaXB0cywgc3Bl Y2lmaWVkIGJ5IGFwcGVuZGluZyBhICMgY2hhcmFjdGVyIGFuZCB0aGUgUkZDNTY0NiBsYW5ndWFn ZSB0YWcuIElmIGFueSBzdWNoIGh1bWFuLXJlYWRhYmxlIGZpZWxkIGlzIHNlbnQgd2l0aG91dCBh IGxhbmd1YWdlIHRhZywgdGhlIHNlcnZlciBhbmQgdGhlIGNsaWVudCBNVVNUIE5PVCBtYWtlIGFu eSBhc3N1bXB0aW9ucyBhYm91dCB0aGUgbGFuZ3VhZ2UsIHNjcmlwdCwgYW5kIGNvdW50cnkgb2Yg dGhlIHZhbHVlIHN0cmluZywgYW5kIHRoZSB2YWx1ZSBzdHJpbmcgTVVTVCBiZSB1c2VkIGFzLWlz IHdoZXJldmVyIGl0IGlzIHByZXNlbnRlZCBpbiBlaXRoZXIgdGhlIGNsaWVudCBvciBzZXJ2ZXIg VUkuIFRvIGZhY2lsaXRhdGUgaW50ZXJvcGVyYWJpbGl0eSwgaXQgaXMgUkVDT01NRU5ERUQgdGhh dCBhbnkgZmllbGRzIHNlbnQgd2l0aG91dCBsYW5ndWFnZSB0YWdzIGNvbnRhaW4gYW4gaW50ZXJu YXRpb25hbGl6ZWQgVVRGLTggc3RyaW5nIHN1aXRhYmxlIGZvciBkaXNwbGF5IG9uIGEgd2lkZSB2 YXJpZXR5IG9mIHN5c3RlbXMsIGFuZCBpdCBpcyBSRUNPTU1FTkRFRCB0aGF0IGNsaWVudHMgc2Vu ZCBmaWVsZHMgd2l0aG91dCBsYW5ndWFnZSB0YWdzIGluIGFkZGl0aW9uIHRvIGFueSBtb3JlLXNw ZWNpZmljYWxseSBkZW5vbWluYXRlZCB2YWx1ZXMuPC9kaXY+DQo8L2Jsb2NrcXVvdGU+PGRpdj48 YnI+PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPjIwMTMvMy8yMiBKdXN0aW4gUmljaGVyIDxzcGFu IGRpcj0ibHRyIj4mbHQ7PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0cmUub3JnIiB0YXJnZXQ9 Il9ibGFuayI+anJpY2hlckBtaXRyZS5vcmc8L2E+Jmd0Ozwvc3Bhbj48YnI+PGJsb2NrcXVvdGUg Y2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6 MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQoNCiAgDQogICAgDQogIA0KICA8ZGl2 IGJnY29sb3I9IiNGRkZGRkYiIHRleHQ9IiMwMDAwMDAiPg0KICAgIFdlIGRpc2N1c3NlZCB0aGlz IGlzc3VlIG9uIHRoZSBPcGVuSUQgQ29ubmVjdCBXRyBjYWxsIHRoaXMgbW9ybmluZywNCiAgICBp biBhIGNvbnZlcnNhdGlvbiB0aGF0IGluY2x1ZGVkIG15c2VsZiwgR2VvcmdlIEZsZXRjaGVyLCBO YXQNCiAgICBTYWtpbXVyYSwgTWlrZSBKb25lcywgYW5kIEpvaG4gQnJhZGxleSAoYW1vbmcgb3Ro ZXJzKSBhcyBhY3RpdmUNCiAgICBwYXJ0aWNpcGFudHMgaW4gdGhpcyB0aHJlYWQuIEFmdGVyIGxv dHMgb2YgZGViYXRlLCB3ZSBwcm9wb3NlIHRoYXQNCiAgICB0aGUgT0F1dGggRHluUmVnIGFkb3B0 IHRoZSBoYXNodGFnLWJhc2VkIGxvY2FsaXphdGlvbiBtZXRob2Qgb2YgT0lEQw0KICAgIChhbmQg aXQgc2VlbXMsIHBvc3NpYmx5IHdlYmZpbmdlcikgYW5kIGV4cGxpY2l0bHkgZGVjbGFyZSB0aGF0 DQogICAgbmVpdGhlciB0aGUgY2xpZW50IG5vciB0aGUgc2VydmVyIG1ha2UgYW55IGFzc3VtcHRp b25zIGFib3V0IHRoZQ0KICAgIGNvbnRlbnQgb2YgdGhlIHN0cmluZyBhbmQgdHJlYXQgaXQgYXMg anVzdCBhIHN0cmluZy4gSSYjMzk7bSBwcm9wb3NpbmcNCiAgICB0aGlzIHRleHQgdG8gdGhhdCBl ZmZlY3QgKHdpdGggdGhlIHJlZmVyZW5jZXMgdG8gT0lEQy1tZXNzYWdlcw0KICAgIHJlbW92ZWQg YW5kIHJlcGxhY2VkIHdpdGggdGhlIHJ1bGUgZGVzY3JpcHRpb24gaXRzZWxmIGluIE9BdXRoDQog ICAgRHluUmVnKTo8YnI+DQogICAgPGJyPg0KICAgIDxibG9ja3F1b3RlPkZpZWxkcyB3aXRoIGh1 bWFuLXJlYWRhYmxlIHZhbHVlcyBvciByZWZlcmVuY2VzIHRvDQogICAgICBodW1hbi1yZWFkYWJs ZSB2YWx1ZXMsIHN1Y2ggYXMgY2xpZW50X25hbWUsIHRvc191cmksIHBvbGljeV91cmksDQogICAg ICBhbmQgY2xpZW50X3VyaSwgTUFZIGJlIHJlcHJlc2VudGVkIGluIG11bHRpcGxlIGxhbmd1YWdl cyBhbmQNCiAgICAgIHNjcmlwdHMsIHNwZWNpZmllZCBieSBhcHBlbmRpbmcgYSAjIGNoYXJhY3Rl ciBhbmQgdGhlIFJGQzU2NDYNCiAgICAgIGxhbmd1YWdlIHRhZy4gSWYgYW55IHN1Y2ggaHVtYW4t cmVhZGFibGUgZmllbGQgaXMgc2VudCB3aXRob3V0IGENCiAgICAgIGxhbmd1YWdlIHRhZywgdGhl IHNlcnZlciBhbmQgdGhlIGNsaWVudCBNVVNUIE5PVCBtYWtlIGFueQ0KICAgICAgYXNzdW1wdGlv bnMgYWJvdXQgdGhlIGxhbmd1YWdlLCBjaGFyYWN0ZXIgc2V0LCBvciBzY3JpcHQgb2YgdGhlDQog ICAgICB2YWx1ZSBzdHJpbmcsIGFuZCB0aGUgdmFsdWUgc3RyaW5nIE1VU1QgYmUgdXNlZCBhcy1p cyB3aGVyZXZlciBpdA0KICAgICAgaXMgcHJlc2VudGVkIGluIGVpdGhlciB0aGUgY2xpZW50IG9y IHNlcnZlciBVSS4gVG8gZmFjaWxpdGF0ZQ0KICAgICAgaW50ZXJvcGVyYWJpbGl0eSwgaXQgaXMg UkVDT01NRU5ERUQgdGhhdCBhbnkgZmllbGRzIHNlbnQgd2l0aG91dA0KICAgICAgbGFuZ3VhZ2Ug dGFncyBjb250YWluIGFuIGludGVybmF0aW9uYWxpemVkIFVURi04IHN0cmluZyBzdWl0YWJsZQ0K ICAgICAgZm9yIGRpc3BsYXkgb24gYSB3aWRlIHZhcmlldHkgb2Ygc3lzdGVtcywgYW5kIGl0IGlz IFJFQ09NTUVOREVEDQogICAgICB0aGF0IGNsaWVudHMgc2VuZCBmaWVsZHMgd2l0aG91dCBsYW5n dWFnZSB0YWdzIGluIGFkZGl0aW9uIHRvIGFueQ0KICAgICAgbW9yZS1zcGVjaWZpY2FsbHkgZGVu b21pbmF0ZWQgdmFsdWVzLjxicj4NCiAgICA8L2Jsb2NrcXVvdGU+DQogICAgPGJyPg0KICAgIFBs dXMgc29tZSBleGFtcGxlcy48YnI+DQogICAgPGJyPg0KICAgIChBbnlvbmUgd2hvc2UgbmFtZSBJ IHRvb2sgaW4gdmFpbiwgcGxlYXNlIGZlZWwgZnJlZSB0byBjb3JyZWN0IG1lLik8c3BhbiBjbGFz cz0iSE9FblpiIj48Zm9udCBjb2xvcj0iIzg4ODg4OCI+PGJyPg0KICAgIDxicj4NCiAgICAmbmJz cDstLSBKdXN0aW48L2ZvbnQ+PC9zcGFuPjxkaXYgY2xhc3M9ImltIj48YnI+DQogICAgPGJyPg0K ICAgIDxkaXY+T24gMDMvMjAvMjAxMyAwMzoxMSBQTSwgSnVzdGluIFJpY2hlcg0KICAgICAgd3Jv dGU6PGJyPg0KICAgIDwvZGl2Pg0KICAgIDwvZGl2PjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxk aXYgY2xhc3M9ImltIj4NCiAgICAgIA0KICAgICAgSSBhZ3JlZSB0aGF0IEkmIzM5O20gc2VlaW5n IHRoaW5ncyBmcm9tIHRoZSBzaW5nbGUtbGFuZ3VhZ2UgYW5kDQogICAgICBzaW5nbGUtZW5jb2Rp bmcgcGVyc3BlY3RpdmUgaGVyZSwgYW5kIHRoYXQmIzM5O3MgdGhlIHVzZSBjYXNlIEkmIzM5O20N CiAgICAgIGN1cnJlbnRseSBzb2x2aW5nIGZvciB3aXRoIG15IGRldmVsb3BtZW50LiBJIHdhbnQg dG8gc2VlIHRoaXMgb25lDQogICAgICByZW1haW4gc2ltcGxlLCBhbmQgSSB0aGluayB3ZSBjYW4g ZG8gdGhhdCB3aXRob3V0IGJyZWFraW5nIG90aGVyDQogICAgICB1c2UgY2FzZXMuPGJyPg0KICAg ICAgPGJyPg0KICAgICAgSSB3b3VsZCBhcmd1ZSB0aGF0IG11bHRpLXNjcmlwdCBsYW5ndWFnZXMg KHN1Y2ggYXMgQ2hpbmVzZSwNCiAgICAgIEphcGFuZXNlLCBhbmQgb3RoZXJzKSBhcmUgYWxsIGNh c2VzIHdoZXJlIHlvdSYjMzk7cmUgZ29pbmcgdG8gYXNzdW1lDQogICAgICBtdWx0aXBsZSBsYW5n dWFnZXMsIGFuZCB0aGUgdGFncyB3b3VsZCBiZSBuZWNlc3NhcnkgZm9yIHJlYWwgdXNlLg0KICAg ICAgU28gY2xpZW50IGFuZCBBUyB3b3VsZCBib3RoIG5lZWQgdG8ga25vdyBob3cgdG8gZGVhbCB3 aXRoIHRoZQ0KICAgICAgbXVsdGlwbGUgZGlmZmVyZW50IHRhZ3MsIGFuZCBzbWFydCBvbmVzIHdv dWxkIGJlIGFibGUgdG8NCiAgICAgIGVmZmVjdGl2ZWx5IGlnbm9yZSB0aGUgZGVmYXVsdCBmaWVs ZC4gVGhlIGRlZmF1bHQsIHNjcmlwdGxlc3MNCiAgICAgIGZpZWxkIGNvdWxkIGJlIGZvciBhbnkg b25lIG9mIHRoZSBzdXBwb3J0ZWQgbGFuZ3VhZ2VzIGF0IHRoZSBBUyBvcg0KICAgICAgQ2xpZW50 LCBhbmQgaXQmIzM5O2QgZWZmZWN0aXZlbHkgYmUgYSBiYWNrdXAsIGludGVybmF0aW9uYWxpemVk DQogICAgICB2ZXJzaW9uLCB0aGUgb25lIHRoYXQgeW91IHVzZSB3aGVuIHRoZXJlJiMzOTtzIG5v dGhpbmcgZWxzZSBtb3JlDQogICAgICBzcGVjaWZpYyB0byB1c2UuIDxicj4NCiAgICAgIDxicj4N CiAgICAgIEkgZ3Vlc3Mgd2hhdCYjMzk7cyBnZXR0aW5nIG1lIHN0dWNrIG9uIHRoZSBleHBsaWNp dCBsb2NhbGUgZmllbGQgaXMNCiAgICAgIHRoYXQgSSYjMzk7bSBub3Qgc2VlaW5nIG11Y2ggdmFs dWUgaW4gcmVxdWlyaW5nIGl0IG92ZXIgR2VvcmdlJiMzOTtzDQogICAgICBwcm9wb3NhbCBvZiBh bHdheXMgdXNpbmcgbGFuZ3VhZ2UgdGFncyBvbiBldmVyeXRoaW5nICh3aGljaCBJIGFsc28NCiAg ICAgIGRvbiYjMzk7dCBsaWtlLCBidXQgZm9yIGRpZmZlcmVudCByZWFzb25zKS4gSGF2aW5nIHRo ZSBpbmZvcm1hdGlvbg0KICAgICAgZG9lc24mIzM5O3QgbWVhbiB0aGF0IHlvdSBjYW4gZG8gYW55 dGhpbmcgaW50ZWxsaWdlbnQgd2l0aCBpdCwgZWl0aGVyLA0KICAgICAgYnV0IEkgY2FuIHNlZSB0 aGUgYXJndW1lbnQgdGhhdCBpdCBtYWtlcyBkb2luZyBzb21ldGhpbmcgc21hcnQNCiAgICAgIHBv c3NpYmxlLiBCdXQgb24gdGhlIG90aGVyIGhhbmQsIHdlIGFscmVhZHkgaGF2ZSBhIG1lY2hhbmlz bSBmb3INCiAgICAgIGRvaW5nIHNvbWV0aGluZyBzbWFydDogdXNpbmcgdGhlIGV4cGxpY2l0IGxh bmd1YWdlIHRhZ3MgZGlyZWN0bHkuDQogICAgICA8YnI+DQogICAgICA8YnI+DQogICAgICBBbHNv LCBub3RlIHRoYXQgdGhlIEFTIGRvZXNuJiMzOTt0IG5lZWQgdG8gcmVuZGVyIGFueSBjaGFyYWN0 ZXJzIGZvcg0KICAgICAgdG9zX3VyaSwgcG9saWN5X3VyaSwgYW5kIG90aGVyIF91cmkgb3B0aW9u cywganVzdCBmb3IgY2xpZW50X25hbWUuDQogICAgICBUaGF0JiMzOTtzIHdoeSBJIHdhcyBtYWtp bmcgdGhlIGRpc3RpbmN0aW9uIGluIG15IGV4cGxhbmF0aW9uIGJlbG93Lg0KICAgICAgWW91IG1p Z2h0IHdhbnQgdG8gZ2l2ZSB0aGUgdXNlciB0aGUgcmlnaHQgb3B0aW9uLCBzdXJlLCBidXQgYQ0K ICAgICAgc2VydmVkIHdlYnBhZ2UgaGFzIGEgbXVjaCBiZXR0ZXIgY2hhbmNlIG9mIGdldHRpbmcg dGhlIGxvY2FsZQ0KICAgICAgcmlnaHQgZHluYW1pY2FsbHkgdGhhbiBhbiBpbmNsdWRlZCBzdHJp bmcgd291bGQgaGF2ZSAoYXBwcm9hY2hlcw0KICAgICAgbGlrZSB1c2VyIHByZWZlcmVuY2VzLCBi cm93c2VyIHNldHRpbmdzLCBldGMuIC0tIGV2ZXJ5dGhpbmcgdGhhdCYjMzk7cw0KICAgICAgdXNl ZCB0b2RheSBvbiB3ZWIgcGFnZXMsIGluIG90aGVyIHdvcmRzKS4gVGhpcyBpcyB3aHkgSSB0aGlu ayB0aGF0DQogICAgICB0aGUgX3VyaSBjbGFpbXMgYXJlIGluIGEgZGlmZmVyZW50IGNhdGVnb3J5 IGFuZCB3ZSYjMzk7cmUgdGFsa2luZw0KICAgICAgYWxtb3N0IGV4Y2x1c2l2ZWx5IGFib3V0IGNs aWVudF9uYW1lIGhlcmUuPGJyPg0KICAgICAgPGJyPg0KICAgICAgSSB0aGluaywgdWx0aW1hdGVs eSwgdGhhdCBJIG5lZWQgdG8gdGhpbmsgYWJvdXQgdGhpcyBtb3JlLjxicj4NCiAgICAgIDxicj4N CiAgICAgICZuYnNwOyAtLSBKdXN0aW48YnI+DQogICAgICA8YnI+DQogICAgICA8ZGl2Pk9uIDAz LzIwLzIwMTMgMDI6MzAgUE0sIE1pa2UgSm9uZXMNCiAgICAgICAgd3JvdGU6PGJyPg0KICAgICAg PC9kaXY+DQogICAgICA8L2Rpdj48ZGl2PjxkaXYgY2xhc3M9Img1Ij48YmxvY2txdW90ZSB0eXBl PSJjaXRlIj4NCiAgICAgICAgDQogICAgICAgIA0KICAgICAgICANCiAgICAgICAgPGRpdj4NCiAg ICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFmNDk3ZCI+SQ0KICAgICAgICAgICAgICBzdXNwZWN0IHlvdSBvbmx5IGZlZWwgdGhh dCBsZWF2aW5nIHRoZSBsb2NhbGUgaW5mb3JtYXRpb24NCiAgICAgICAgICAgICAgb3V0IGlzIE9L IGJlY2F1c2UgeW91IChhbmQgSSkgbGl2ZSBpbiBhIGN1bHR1cmUgd2hlcmUgaXQmcnNxdW87cw0K ICAgICAgICAgICAgICBub3QgbmVlZGVkIHRvIGFkZXF1YXRlbHkgcmVuZGVyIGNoYXJhY3RlcnMu Jm5ic3A7IEkmcnNxdW87ZCBhY3R1YWxseQ0KICAgICAgICAgICAgICBkZWZlciBvbiB0aGlzIGRl Y2lzaW9uIHRvIE5hdCBhbmQgb3RoZXJzIGZyb20gSmFwYW4gYW5kDQogICAgICAgICAgICAgIENo aW5hIChhbmQgSSB0aGluayBLb3JlYT8pIHdoZXJlIEkgYmVsaWV2ZSB0aGF0IHRoaXMNCiAgICAg ICAgICAgICAgaW5mb3JtYXRpb24gaXMgZXNzZW50aWFsLjx1PjwvdT48dT48L3U+PC9zcGFuPjwv cD4NCiAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFmNDk3ZCI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3NwYW4+PC9wPg0KICAg ICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMWY0OTdkIj5Gb3INCg0KICAgICAgICAgICAgICB3aGF0IGl0JnJzcXVvO3Mgd29ydGgs IGl0JnJzcXVvO3MgbW9yZSB0aGFuIGp1c3QgY2xpZW50X25hbWUuJm5ic3A7IEl0JnJzcXVvO3MN CiAgICAgICAgICAgICAgYWxzbyB0b3NfdXJpIGFuZCBwb2xpY3lfdXJpIGFuZCBwb3RlbnRpYWxs eSBjbGllbnRfdXJpLjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCiAgICAgICAgICA8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFmNDk3ZCI+ PHU+PC91PiZuYnNwOzx1PjwvdT48L3NwYW4+PC9wPg0KICAgICAgICAgIDxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMWY0OTdkIj5BbHNvLA0K DQogICAgICAgICAgICAgIGhhdmluZyB0aG91Z2h0IGFib3V0IGl0IGZvciBhIGZldyBkYXlzLCBJ JnJzcXVvO2QgY2hhbmdlIHRoZQ0KICAgICAgICAgICAgICBwcm9wb3NlZCBmaWVsZCBuYW1lIGZy b20gcmVnaXN0cmF0aW9uX2xvY2FsZSB0bw0KICAgICAgICAgICAgICBkZWZhdWx0X3JlZ2lzdHJh dGlvbl9sb2NhbGUsIHNvIHRoZSBtZWFuaW5nIGlzIGNsZWFyZXIuPHU+PC91Pjx1PjwvdT48L3Nw YW4+PC9wPg0KICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMWY0OTdkIj48dT48L3U+Jm5ic3A7PHU+PC91Pjwvc3Bhbj48L3A+ DQogICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxZjQ5N2QiPk5hdA0KDQogICAgICAgICAgICAgIGFuZCBvdGhlcnMgZnJvbSBF YXN0ZXJuIGN1bHR1cmVzLCB3aGF0IGlzIHlvdXIgb3BpbmlvbiBvbg0KICAgICAgICAgICAgICB0 aGlzPzx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCiAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFmNDk3ZCI+PHU+PC91PiZu YnNwOzx1PjwvdT48L3NwYW4+PC9wPg0KICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMWY0OTdkIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCg0K ICAgICAgICAgICAgICBUaGFua3MsPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KICAgICAgICAg IDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MWY0OTdkIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsNCg0KICAgICAgICAgICAgICAtLSBNaWtlPHU+PC91Pjx1Pjwv dT48L3NwYW4+PC9wPg0KICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMWY0OTdkIj48dT48L3U+Jm5ic3A7PHU+PC91Pjwvc3Bh bj48L3A+DQogICAgICAgICAgPGRpdj4NCiAgICAgICAgICAgIDxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI2I1YzRkZiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g MGluIj4NCiAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPg0KICAgICAgICAgICAgICAgICAg SnVzdGluIFJpY2hlciBbPGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0cmUub3JnIiB0YXJnZXQ9 Il9ibGFuayI+bWFpbHRvOmpyaWNoZXJAbWl0cmUub3JnPC9hPl0NCiAgICAgICAgICAgICAgICAg IDxicj4NCiAgICAgICAgICAgICAgICAgIDxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIE1hcmNoIDIw LCAyMDEzIDEwOjQzIEFNPGJyPg0KICAgICAgICAgICAgICAgICAgPGI+VG86PC9iPiBNaWtlIEpv bmVzPGJyPg0KICAgICAgICAgICAgICAgICAgPGI+Q2M6PC9iPiBHZW9yZ2UgRmxldGNoZXI7IDxh IGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoQGlldGYu b3JnPC9hPiBXRzxicj4NCiAgICAgICAgICAgICAgICAgIDxiPlN1YmplY3Q6PC9iPiBSZTogW09B VVRILVdHXSBSZWdpc3RyYXRpb246DQogICAgICAgICAgICAgICAgICBJbnRlcm5hdGlvbmFsaXph dGlvbiBvZiBIdW1hbi1SZWFkYWJsZSBuYW1lczx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCiAg ICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgIDxwIGNsYXNzPSJN c29Ob3JtYWwiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wPg0KICAgICAgICAgIDxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+SSB3b3VsZCBzYXkNCiAgICAg ICAgICAgIHRoYXQgY2xhaW1zIHdpdGhvdXQgYSBsYW5ndWFnZSBwYXJhbWV0ZXIsIHdoaWNoIEkg d291bGQgbWFrZQ0KICAgICAgICAgICAgUkVRVUlSRUQgaW4gdGhlIHByZXNlbmNlIG9mIG90aGVy IGNsYWltcywgd291bGQgYmUgdHJlYXRlZA0KICAgICAgICAgICAgYXMgVVRGOCBzdHJpbmdzIHdp dGggbm8gZ3VhcmFudGVlIG9mIHdoYXQgbGFuZ3VhZ2UsIHNjcmlwdCwNCiAgICAgICAgICAgIG9y IG90aGVyIGxvY2FsZS1zcGVjaWZpYyBpbmZvcm1hdGlvbiB3b3VsZCBiZSBpbiB0aGVyZS4gSXQm IzM5O3MNCiAgICAgICAgICAgIGEgZGVmYXVsdCBzdHJpbmcsIGFuZCBpdCYjMzk7cyB0aGUgYmVz dCB0aGUgY2xpZW50IGNhbiBnaXZlIGlmDQogICAgICAgICAgICBub3RoaW5nIG1vcmUgc3BlY2lm aWMgaXMgdXNlZnVsLiBBbmQgc2VydmVycyB3b3VsZCBoYXZlIHRvDQogICAgICAgICAgICBhY2Nl cHQgdGhpcyBkZWZhdWx0IHN0cmluZyBhbmQgZG8gdGhlaXIgYmVzdCB3aXRoIGl0LiBBDQogICAg ICAgICAgICBzZXJ2aWNlIHByb3ZpZGVyIGNhbiBwdWJsaXNoIHRoZWlyIGV4cGVjdGVkIGRlZmF1 bHQgbG9jYWxlDQogICAgICAgICAgICBpbmZvcm1hdGlvbiBpbiBlaXRoZXIgZGlzY292ZXJ5IG9y IHNlcnZpY2UgZG9jdW1lbnRhdGlvbiwNCiAgICAgICAgICAgIGFuZCBjbGllbnRzIHRoYXQgd2Fu dCB0byB0d2VhayB0aGluZ3MgZm9yIHNwZWNpZmljIHNlcnZpY2UNCiAgICAgICAgICAgIHByb3Zp ZGVycyBjYW4gZG8gdGhhdC48YnI+DQogICAgICAgICAgICA8YnI+DQogICAgICAgICAgICBUaGUg c2VydmVyIGNhbiBkaXNwbGF5IGl0IChiZWNhdXNlIGl0JiMzOTtzIGEgc3RyaW5nIHRoYXQmIzM5 O2xsDQogICAgICAgICAgICBhbHdheXMgYmUgdGhlcmUsIGlmIGFueSB2ZXJzaW9uIGlzIHRoZXJl KSwgYnV0IGEgc2VydmVyIHRoYXQNCiAgICAgICAgICAgIGRvZXNuJiMzOTt0IGRvIGludGVybmF0 aW9uYWxpemVkIHN0cmluZ3MgdmVyeSB3ZWxsIG1pZ2h0IG5vdCBnZXQNCiAgICAgICAgICAgIGl0 cyBkaXNwbGF5IGNvcnJlY3QuIFNpbmNlIGRpc3BsYXlhYmxlIHRleHQgdGhpcyBpcyBsaWtlbHkN CiAgICAgICAgICAgIHRvIGJlIGR1bXBlZCBpbnRvIHRoZSBtaWRkbGUgb2YgYSB3ZWJwYWdlIHRo YXQgaGFzIGl0cyBvd24NCiAgICAgICAgICAgIGNoYXJhY3RlciBlbmNvZGluZyBhbmQgb3RoZXIg Y29uc2lkZXJhdGlvbnMgYW55d2F5LCBzbyBpdCYjMzk7cw0KICAgICAgICAgICAgbm90IGd1YXJh bnRlZWQgdGhhdCBzcGVjaWZ5aW5nIGEgbG9jYWxlIHdpbGwgYWx3YXlzIGhlbHANCiAgICAgICAg ICAgIGhlcmUgYW55d2F5LiBUaGlzIGlzIGp1c3QgZm9yIHRoZSBkaXNwbGF5YWJsZSB0ZXh0LCB3 aGljaA0KICAgICAgICAgICAgcmlnaHQgbm93IGlzIG9ubHkgdGhlIGNsaWVudF9uYW1lIGZpZWxk IGluIE9BdXRoIGFuZCBPSURDOg0KICAgICAgICAgICAgZm9yIFVSTHMgKHRoZSBvdGhlciAmcXVv dDtodW1hbi1yZWFkYWJsZSZxdW90OyBmaWVsZCksIGl0JiMzOTtzIGEgbW9vdA0KICAgICAgICAg ICAgcG9pbnQsIGJlY2F1c2UgdGhlIHNlcnZlciYjMzk7cyBqdXN0IGdvaW5nIHRvIHNwaXQgb3V0 IHRoZSBVUkwNCiAgICAgICAgICAgIGl0c2VsZiBpbnRvIGFuIGhyZWYgb2Ygc29tZSBmbGF2b3Iu IFRoZSBzZXJ2ZXIgZG9lc24mIzM5O3QgaGF2ZQ0KICAgICAgICAgICAgdG8gZGVhbCB3aXRoIGFu eSBraW5kIG9mIGVuY29kaW5nIG9yIHRleHQvc2NyaXB0IGlzc3Vlcw0KICAgICAgICAgICAgaGVy ZS4gPGJyPg0KICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgQXMgYSBzZXJ2ZXIgZGV2ZWxv cGVyLCBpdCYjMzk7cyBqdXN0IGFub3RoZXIgdGhpbmcgdGhhdCBJICpoYXZlKg0KICAgICAgICAg ICAgdG8gdHJhY2sgYW5kIGRlYWwgd2l0aCBvbiB0aGUgY2xpZW50IG1vZGVsLCBldmVuIGlmIEkg ZG9uJiMzOTt0DQogICAgICAgICAgICB3YW50IHRvIHN1cHBvcnQgdGhlIHJlc3Qgb2YgdGhlIG11 bHRpLWxhbmd1YWdlIHRhZ3MgaW4gbXkNCiAgICAgICAgICAgIHNlcnZpY2UuIEFzIGEgY2xpZW50 IGRldmVsb3BlciwgaXQmIzM5O3Mgb25lIG1vcmUgdGhpbmcgdGhhdCBJDQogICAgICAgICAgICAq aGF2ZSogdG8gc3BlY2lmeSB3aGVuIEkgc2VuZCB0aGluZ3MgdG8gdGhlIHNlcnZlci4gSSBkb24m IzM5O3QNCiAgICAgICAgICAgIHNlZSBob3cgcmVxdWlyaW5nIGl0cyBzcGVjaWZpY2F0aW9uIGlz IGdvaW5nIHRvIHJlYWxseSBoZWxwDQogICAgICAgICAgICBpbnRlcm9wZXJhYmlsaXR5LCBhbmQg SSBjYW4gYWxtb3N0IGd1YXJhbnRlZSB0aGF0DQogICAgICAgICAgICBpbXBsZW1lbnRhdGlvbnMg d2lsbCBqdXN0IGxlYXZlIGl0IG9mZiBldmVuIGlmIG1hcmtlZA0KICAgICAgICAgICAgUkVRVUlS RUQgKGxpa2UgaG93IG1hbnksIG1hbnkgZG9jdW1lbnRzIGluIHRoZSB3aWxkIHRoYXQgYXJlDQog ICAgICAgICAgICBzdXBwb3NlZCB0byBoYXZlIGEgY2hhcmFjdGVyLWVuY29kaW5nIGZpZWxkIG9m IHNvbWUgdHlwZQ0KICAgICAgICAgICAganVzdCBsZWF2ZSBpdCBvZmYpLiA8YnI+DQogICAgICAg ICAgICA8YnI+DQogICAgICAgICAgICBJIHRoaW5rIHRoYXQgaXQmIzM5O3MgYSBsb3Qgb2Ygd29y ayBvbiBib3RoIHNpZGVzIGZvciBqdXN0DQogICAgICAgICAgICBjbGllbnRfbmFtZS48YnI+DQog ICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAmbmJzcDstLSBKdXN0aW48YnI+DQogICAgICAg ICAgICA8YnI+DQogICAgICAgICAgICA8dT48L3U+PHU+PC91PjwvcD4NCiAgICAgICAgICA8ZGl2 Pg0KICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMDMvMjAvMjAxMyAwMToyNyBQ TSwgTWlrZSBKb25lcw0KICAgICAgICAgICAgICB3cm90ZTo8dT48L3U+PHU+PC91PjwvcD4NCiAg ICAgICAgICA8L2Rpdj4NCiAgICAgICAgICA8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCiAgICAgICAgICAgIDxkaXY+DQogICAgICAgICAg ICAgIDxkaXY+DQogICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkhvdw0KDQog ICAgICAgICAgICAgICAgICAgIHdvdWxkIHlvdSBkbyB0aGlzIGluc3RlYWQgdGhlbj88dT48L3U+ PHU+PC91Pjwvc3Bhbj48L3A+DQogICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgPC9k aXY+DQogICAgICAgICAgICA8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWdu OmNlbnRlciIgYWxpZ249ImNlbnRlciI+DQogICAgICAgICAgICAgIDxociBhbGlnbj0iY2VudGVy IiBzaXplPSIzIiB3aWR0aD0iMTAwJSI+IDwvZGl2Pg0KICAgICAgICAgICAgPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+RnJvbToNCg0KICAgICAgICAgICAgICAgIDwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPkp1c3Rpbg0KDQogICAgICAgICAgICAgICAgUmljaGVyPC9zcGFu Pjxicj4NCiAgICAgICAgICAgICAgPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlNlbnQ6 DQoNCiAgICAgICAgICAgICAgICA8L3NwYW4+IDwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+My8yMC8yMDEzDQoNCiAgICAgICAgICAgICAgICAxMDoyNSBBTTwvc3Bhbj48YnI+DQogICAg ICAgICAgICAgIDxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UbzoNCg0KICAgICAgICAg ICAgICAgIDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPk1pa2UNCg0KICAg ICAgICAgICAgICAgIEpvbmVzPC9zcGFuPjxicj4NCiAgICAgICAgICAgICAgPGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPkNjOg0KDQogICAgICAgICAgICAgICAgPC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+R2VvcmdlDQoNCiAgICAgICAgICAgICAgICBGbGV0Y2hl cjsgPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGhA aWV0Zi5vcmc8L2E+IFdHPC9zcGFuPjxicj4NCiAgICAgICAgICAgICAgPGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPlN1YmplY3Q6DQoNCiAgICAgICAgICAgICAgICA8L3NwYW4+IDwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+UmU6DQoNCiAgICAgICAgICAgICAgICBbT0FVVEgt V0ddIFJlZ2lzdHJhdGlvbjogSW50ZXJuYXRpb25hbGl6YXRpb24gb2YNCiAgICAgICAgICAgICAg ICBIdW1hbi1SZWFkYWJsZSBuYW1lczwvc3Bhbj48dT48L3U+PHU+PC91PjwvcD4NCiAgICAgICAg ICAgIDxkaXY+DQogICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+UGVyc29uYWxseSwNCg0KICAgICAgICAgICAgICAgIEkgdGhpbmsg dGhhdCB0aGlzIGxldmVsIG9mIHNwZWNpZmljaXR5IGlzIG92ZXJraWxsLjxicj4NCiAgICAgICAg ICAgICAgICA8YnI+DQogICAgICAgICAgICAgICAgJm5ic3A7LS0gSnVzdGluPGJyPg0KICAgICAg ICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICA8dT48L3U+PHU+PC91PjwvcD4NCiAgICAg ICAgICAgICAgPGRpdj4NCiAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAw My8xNC8yMDEzIDExOjQyIEFNLCBNaWtlIEpvbmVzDQogICAgICAgICAgICAgICAgICB3cm90ZTo8 dT48L3U+PHU+PC91PjwvcD4NCiAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgIDxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K ICAgICAgICAgICAgICAgIDxkaXY+DQogICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFmNDk3ZCI+SQ0KICAgICAg ICAgICAgICAgICAgICAgIGFncmVlIHRoYXQgaGF2aW5nIHVuYWRvcm5lZCB2YWx1ZXMgbGlrZWx5 DQogICAgICAgICAgICAgICAgICAgICAgc2ltcGxpZmllcyB0aGluZ3MgaW4gbWFueSBjYXNlcywg YnV0IGlmIHdlIGRvDQogICAgICAgICAgICAgICAgICAgICAgdGhpcywgd2Ugc2hvdWxkIGxldCB0 aGUgQ2xpZW50IHNheSB3aGF0DQogICAgICAgICAgICAgICAgICAgICAgbGFuZ3VhZ2Uvc2NyaXB0 IGl0JnJzcXVvO3MgdXNpbmcgd2hlbiBwcm92aWRpbmcNCiAgICAgICAgICAgICAgICAgICAgICBo dW1hbi1yZWFkYWJsZSBzdHJpbmdzIG9yIHJlZmVyZW5jZXMgdG8gdGhlbSBhcw0KICAgICAgICAg ICAgICAgICAgICAgIHJlZ2lzdHJhdGlvbiBwYXJhbWV0ZXJzLiZuYnNwOyBGb3IgdGhpcyBwdXJw b3NlLCBJJnJzcXVvO2QNCiAgICAgICAgICAgICAgICAgICAgICBwcm9wb3NlIHRoYXQgd2UgaGF2 ZSBhIHBhcmFtZXRlciBzb21ldGhpbmcgbGlrZQ0KICAgICAgICAgICAgICAgICAgICAgIHRoaXMg b25lOjwvc3Bhbj48dT48L3U+PHU+PC91PjwvcD4NCiAgICAgICAgICAgICAgICAgIDxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMWY0OTdkIj4m bmJzcDs8L3NwYW4+PHU+PC91Pjx1PjwvdT48L3A+DQogICAgICAgICAgICAgICAgICA8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7IiBsYW5nPSJFTiI+cmVnaXN0cmF0aW9uX2xvY2FsZTwv c3Bhbj48dT48L3U+PHU+PC91PjwvcD4NCiAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7IiBsYW5nPSJFTiI+T1BU SU9OQUwgb3IgUkVRVVJFRC4gTGFuZ3VhZ2UgYW5kIHNjcmlwdA0KICAgICAgICAgICAgICAgICAg ICAgIHVzZWQgZm9yIGh1bWFuLXJlYWRhYmxlIHZhbHVlcyBvciByZWZlcmVuY2VzIHRvDQogICAg ICAgICAgICAgICAgICAgICAgaHVtYW4tcmVhZGFibGUgdmFsdWVzIHRoYXQgYXJlIHN1cHBsaWVk IHdpdGhvdXQNCiAgICAgICAgICAgICAgICAgICAgICBsYW5ndWFnZS9zY3JpcHQgdGFncywgcmVw cmVzZW50ZWQgYXMgYQ0KICAgICAgICAgICAgICAgICAgICAgIEJDUDQ3W1JGQzU2NDZdIGxhbmd1 YWdlIHRhZyB2YWx1ZS4mbmJzcDsgVGhpcyBwYXJhbWV0ZXINCiAgICAgICAgICAgICAgICAgICAg ICBpcyBSRVFVSVJFRCBpZiBhbnkgaHVtYW4tcmVhZGFibGUgdmFsdWVzIG9yDQogICAgICAgICAg ICAgICAgICAgICAgcmVmZXJlbmNlcyB0byBodW1hbi1yZWFkYWJsZSBhcmUgcHJvdmlkZWQgd2l0 aG91dA0KICAgICAgICAgICAgICAgICAgICAgIGxhbmd1YWdlL3NjcmlwdCB0YWdzLjwvc3Bhbj48 dT48L3U+PHU+PC91PjwvcD4NCiAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMWY0OTdkIj4mbmJzcDs8L3NwYW4+ PHU+PC91Pjx1PjwvdT48L3A+DQogICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFmNDk3ZCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 DQoNCiAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlPC9zcGFuPjx1PjwvdT48dT48L3U+PC9w Pg0KICAgICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxZjQ5N2QiPiZuYnNwOzwvc3Bhbj48dT48L3U+PHU+PC91Pjwv cD4NCiAgICAgICAgICAgICAgICAgIDxkaXY+DQogICAgICAgICAgICAgICAgICAgIDxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI2I1YzRkZiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBpbiAwaW4gMGluIj4NCiAgICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+ DQogICAgICAgICAgICAgICAgICAgICAgICAgIDxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2Vz QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT4NCiAg ICAgICAgICAgICAgICAgICAgICAgICAgWzxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+ XQ0KICAgICAgICAgICAgICAgICAgICAgICAgICA8Yj5PbiBCZWhhbGYgT2YgPC9iPkp1c3RpbiBS aWNoZXI8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgIDxiPlNlbnQ6PC9iPiBUaHVyc2Rh eSwgTWFyY2ggMTQsIDIwMTMgODowMiBBTTxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg PGI+VG86PC9iPiBHZW9yZ2UgRmxldGNoZXI8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAg IDxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+b2F1dGhAaWV0Zi5vcmc8L2E+DQogICAgICAgICAgICAgICAgICAgICAgICAgIFdHPGJyPg0K ICAgICAgICAgICAgICAgICAgICAgICAgICA8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10g UmVnaXN0cmF0aW9uOg0KICAgICAgICAgICAgICAgICAgICAgICAgICBJbnRlcm5hdGlvbmFsaXph dGlvbiBvZiBIdW1hbi1SZWFkYWJsZSBuYW1lczwvc3Bhbj48dT48L3U+PHU+PC91PjwvcD4NCiAg ICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAg ICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzx1PjwvdT48dT48L3U+PC9w Pg0KICAgICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gdGhlIHN1cmZhY2Ug dGhpcyBkb2VzIHNpbXBsaWZ5DQogICAgICAgICAgICAgICAgICAgIHRoaW5ncywgYnV0IHRoZSBp c3N1ZSBJIGZvcnNlZSB3aXRoIGl0IGlzIHRoYXQgSQ0KICAgICAgICAgICAgICAgICAgICB3YW50 IHRvIGJlIGFibGUgdG8gY2FsbCAmcXVvdDtjbGllbnQuZ2V0Q2xpZW50TmFtZSgpJnF1b3Q7IGFu ZA0KICAgICAgICAgICAgICAgICAgICBhbHdheXMgZ2V0ICpzb21ldGhpbmcqIG91dCBvZiBpdCBp ZiB0aGVyZSBhcmUgKmFueSoNCiAgICAgICAgICAgICAgICAgICAgY2xpZW50X25hbWUgZmllbGRz IGF0IGFsbC4gU28gaW4gdGhpcyB3b3JsZCBpZiBJDQogICAgICAgICAgICAgICAgICAgIHRha2Ug YSBjbGllbnQgbGlicmFyeSB0aGF0IGFzc3VtZXMgZW4tdXMgYW5kIGl0DQogICAgICAgICAgICAg ICAgICAgIHRhbGtzIHRvIGEgc2VydmVyIHRoYXQgb25seSBsb29rcyBmb3IgZXMtY2wsIHRoZXJl JiMzOTtzDQogICAgICAgICAgICAgICAgICAgIGEgdmVyeSByZWFsIGNoYW5jZSBvZiB0aGUgY2xp ZW50IG5hbWUgbm90IGdldHRpbmcNCiAgICAgICAgICAgICAgICAgICAgc2V0IGF0IGFsbC4gSSB0 aGluayB0aGF0JiMzOTtzIGEgcHJvYmxlbS48YnI+DQogICAgICAgICAgICAgICAgICAgIDxicj4N CiAgICAgICAgICAgICAgICAgICAgVGhpcyBpcyB3aHkgSSB0aGluayB0aGUgZGVmYXVsdCBmaWVs ZCBuYW1lICh3aXRob3V0DQogICAgICAgICAgICAgICAgICAgIHRoZSBsYW5ndWFnZSB0YWcpIHJl YWxseSBzaG91bGQgYmUgcmVxdWlyZWQgYW5kDQogICAgICAgICAgICAgICAgICAgIHNob3VsZCBi ZSBsZWZ0IHVuZGVmaW5lZCBhcyB0byB3aGF0IGxhbmd1YWdlIGFuZA0KICAgICAgICAgICAgICAg ICAgICBzY3JpcHQgaXQgaXMuIEVzc2VudGlhbGx5LCAmcXVvdDtJdCYjMzk7cyBhIFVURjggU3Ry aW5nLCBob3BlDQogICAgICAgICAgICAgICAgICAgIGZvciB0aGUgYmVzdCZxdW90Oy4gSWYgeW91 IHdhbnQgc29tZXRoaW5nIG1vcmUgc3BlY2lmaWMNCiAgICAgICAgICAgICAgICAgICAgYW5kIHNt YXJ0IGFib3V0IGxvY2FsaXphdGlvbiwgdGhlbiB5b3UgY2FuIHN1cHBvcnQNCiAgICAgICAgICAg ICAgICAgICAgdGhlIGxhbmd1YWdlIHRhZ3MuIElmIHlvdSBqdXN0IHdhbnQgdG8gaGF2ZSBhIHN0 cmluZw0KICAgICAgICAgICAgICAgICAgICB0byBzdG9yZSBhbmQgdGhyb3cgYXQgdGhlIHVzZXIs IHRoZW4geW91IGNhbiBqdXN0DQogICAgICAgICAgICAgICAgICAgIHVzZSB0aGUgYmFyZSBmaWVs ZCBuYW1lLiA8YnI+DQogICAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICAg ICAgSW4gb3RoZXIgd29yZHMsIHdlIHRha2Ugd2hhdCB3ZSBoYXZlIG5vdyAod2hpY2gNCiAgICAg ICAgICAgICAgICAgICAgd29ya3MgZm9yIGEgbm9uLWludGVybmF0aW9uYWxpemVkIGNhc2Ugd2hl cmUNCiAgICAgICAgICAgICAgICAgICAgZXZlcnlvbmUganVzdCBhc3N1bWVzIGEgY29tbW9uIGxh bmd1YWdlL3NjcmlwdCksIGFuZA0KICAgICAgICAgICAgICAgICAgICB3ZSBhdWdtZW50IGl0IHdp dGggZmVhdHVyZXMgdGhhdCBsZXQgaXQgYmUgc21hcnRlcg0KICAgICAgICAgICAgICAgICAgICBp ZiB5b3Ugd2FudCBpdCB0byBiZSBzbWFydGVyLiBNYWtlIHRoZSBzaW1wbGUgY2FzZQ0KICAgICAg ICAgICAgICAgICAgICBzaW1wbGUsIG1ha2UgdGhlIGNvbXBsaWNhdGVkIGNhc2UgcG9zc2libGUu PGJyPg0KICAgICAgICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAgICAgICAgICZuYnNw Oy0tIEp1c3Rpbjxicj4NCiAgICAgICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICAg ICAgICAmbmJzcDs8dT48L3U+PHU+PC91PjwvcD4NCiAgICAgICAgICAgICAgICAgIDxkaXY+DQog ICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDAzLzE0LzIwMTMgMTA6 NDcgQU0sIEdlb3JnZQ0KICAgICAgICAgICAgICAgICAgICAgIEZsZXRjaGVyIHdyb3RlOjx1Pjwv dT48dT48L3U+PC9wPg0KICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAg ICA8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCiAgICAgICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkFzIGENCiAgICAgICAgICAgICAgICAgICAg ICAgIHNpbXBsaWZ5aW5nIG9wdGlvbi4uLiB3aHkgbm90IGp1c3QgcmVxdWlyZQ0KICAgICAgICAg ICAgICAgICAgICAgICAgaHVtYW4tcmVhZGFibGUgZmllbGRzIHRvIHJlcXVpcmUgYSAmcXVvdDtz Y3JpcHQtdGFnJnF1b3Q7Lg0KICAgICAgICAgICAgICAgICAgICAgICAgVGhpcyB3YXkgaXQgaXMg YWx3YXlzIGV4cGxpY2l0IHdoYXQNCiAgICAgICAgICAgICAgICAgICAgICAgIGxhbmd1YWdlL2xv Y2FsZSB0aGUgdGV4dCBpcyBmb3IuIEl0IHRoZW4gYmVjb21lcw0KICAgICAgICAgICAgICAgICAg ICAgICAgdGhlIHJlc3BvbnNpYmlsaXR5IG9mIHRoZSBBUyB0byByZXR1cm4gYW4NCiAgICAgICAg ICAgICAgICAgICAgICAgIGFwcHJvcHJpYXRlIHJlc3BvbnNlIGlmIHRoZXJlIGlzIG5vdCBhIGRp cmVjdA0KICAgICAgICAgICAgICAgICAgICAgICAgbWF0Y2ggYmV0d2VlbiBhIHJlcXVlc3QgYW5k IHRoZSBkYXRhIHN0b3JlZCBhdA0KICAgICAgICAgICAgICAgICAgICAgICAgdGhlIEFTIChhbmQg b3V0IG9mIHNjb3BlIG9mIHRoZSBzcGVjKS48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICA8 YnI+DQogICAgICAgICAgICAgICAgICAgICAgICBUaGFua3MsPGJyPg0KICAgICAgICAgICAgICAg ICAgICAgICAgR2VvcmdlPC9zcGFuPjx1PjwvdT48dT48L3U+PC9wPg0KICAgICAgICAgICAgICAg ICAgICA8ZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPk9u IDMvMTMvMTMgMTA6MjIgQU0sIEp1c3Rpbg0KICAgICAgICAgICAgICAgICAgICAgICAgUmljaGVy IHdyb3RlOjx1PjwvdT48dT48L3U+PC9wPg0KICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAg ICAgICAgICAgICAgICAgICAgPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQogICAgICAgICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5Tbw0KDQogICAgICAgICAgICAgICAg ICAgICAgICB3aXRoIHdoYXQgbGl0dGxlIGZlZWRiYWNrIEkmIzM5O3ZlIGdvdHRlbiwgSSYjMzk7 bQ0KICAgICAgICAgICAgICAgICAgICAgICAgcHJvcG9zaW5nIHRvIGFkZCB0ZXh0IGZyb20gdGhl IHByb3Bvc2VkDQogICAgICAgICAgICAgICAgICAgICAgICB3ZWJmaW5nZXIgYW5kIE9JREMgZHJh ZnRzIGZvciB0aGUgaGFzaC1iYXNlZA0KICAgICAgICAgICAgICAgICAgICAgICAgbG9jYWxpemF0 aW9uIG9mIHN0cmluZ3MsIHdpdGggdGhlIGZvbGxvd2luZw0KICAgICAgICAgICAgICAgICAgICAg ICAgcHJvcGVydGllczo8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICA8YnI+DQogICAgICAg ICAgICAgICAgICAgICAgICAqIEFsbCBsb2NhbGl6ZWQgdmVyc2lvbnMgb2YgZmllbGRzIGFyZSBm dWxseQ0KICAgICAgICAgICAgICAgICAgICAgICAgb3B0aW9uYWwgb24gYm90aCBjbGllbnQgYW5k IHNlcnZlcjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICogSWYgYSBsb2NhbGl6ZWQgdmVy c2lvbiBvZiBhIGZpZWxkIGlzIGluY2x1ZGVkLA0KICAgICAgICAgICAgICAgICAgICAgICAgaXRz IGJhcmUtdmFsdWUgKHBlcmhhcHMgaW50ZXJuYXRpb25hbGl6ZWQpIGZpZWxkDQogICAgICAgICAg ICAgICAgICAgICAgICBNVVNUIGJlIGluY2x1ZGVkPGJyPg0KICAgICAgICAgICAgICAgICAgICAg ICAgKiBBbGwgaHVtYW4tcmVhZGFibGUgZmllbGRzIGFyZSBlbGlnaWJsZSBmb3INCiAgICAgICAg ICAgICAgICAgICAgICAgIHRoaXMgbWVjaGFuaXNtIChpbmNsdWRpbmcgYW55IHVyaSYjMzk7cyBm b3INCiAgICAgICAgICAgICAgICAgICAgICAgIHVzZXItZmFjaW5nIHdlYiBwYWdlcywgd2hpY2gg Y2FuIGJlIHVzZWQgdG8NCiAgICAgICAgICAgICAgICAgICAgICAgIHBvaW50IHRvIGxhbmd1YWdl LXNwZWNpZmljIHBhZ2VzKTxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICogQ2xpZW50cyBh bmQgc2VydmVycyBjYW4gZGVjaWRlIHRvIHVzZSB3aGF0ZXZlcg0KICAgICAgICAgICAgICAgICAg ICAgICAgbGFuZ3VhZ2Uvc2NyaXB0IHRoZXkgd2FudCB0byBmb3IgdGhlIGJhcmUtdmFsdWUNCiAg ICAgICAgICAgICAgICAgICAgICAgIGZpZWxkLCBhbmQgbm8gYXNzdW1wdGlvbnMgY2FuIGJlIG1h ZGUgb24gZWl0aGVyDQogICAgICAgICAgICAgICAgICAgICAgICBzaWRlIGFib3V0IHdoYXQgdGhh dCBpczxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICAg ICAgICAgIEkgdGhpbmsgdGhhdCB3aXRoIHRoZXNlIGNvbnN0cmFpbnRzLCB3ZSBjYW4gYWRkDQog ICAgICAgICAgICAgICAgICAgICAgICBmdW5jdGlvbmFsaXR5IHRvIGFkZHJlc3MgU3RlcGhlbiYj Mzk7cyBjb25jZXJucw0KICAgICAgICAgICAgICAgICAgICAgICAgd2l0aG91dCBnZXR0aW5nIHRv byBjb21wbGljYXRlZCBvciBwdXR0aW5nIHRvbw0KICAgICAgICAgICAgICAgICAgICAgICAgbXVj aCBidXJkZW4gb2Ygc3VwcG9ydC48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICA8YnI+DQog ICAgICAgICAgICAgICAgICAgICAgICAmbmJzcDstLSBKdXN0aW48dT48L3U+PHU+PC91PjwvcD4N CiAgICAgICAgICAgICAgICAgICAgICA8ZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgPHAg Y2xhc3M9Ik1zb05vcm1hbCI+T24gMDMvMTEvMjAxMyAwNjo1MiBQTSwgTmF0DQogICAgICAgICAg ICAgICAgICAgICAgICAgIFNha2ltdXJhIHdyb3RlOjx1PjwvdT48dT48L3U+PC9wPg0KICAgICAg ICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgIDxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KICAgICAgICAg ICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2ltaWxhciB3b3JrIGlzIGluIHBy b2dyZXNzDQogICAgICAgICAgICAgICAgICAgICAgICAgIGF0IFdlYmZpbmdlci4mbmJzcDsgPHU+ PC91Pjx1PjwvdT48L3A+DQogICAgICAgICAgICAgICAgICAgICAgICA8ZGl2Pg0KICAgICAgICAg ICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8dT48L3U+PHU+PC91 PjwvcD4NCiAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAg ICAgICAgPGRpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1h bCI+U2VlOiZuYnNwOzxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dl Yi93ZWJmaW5nZXIvY3VycmVudC9tc2cwMDUzMC5odG1sIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDov L3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3dlYmZpbmdlci9jdXJyZW50L21zZzAwNTMw Lmh0bWw8L2E+PHU+PC91Pjx1PjwvdT48L3A+DQoNCiAgICAgICAgICAgICAgICAgICAgICAgIDwv ZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj4NCiAgICAgICAgICAgICAgICAgICAg ICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PHU+PC91Pjx1PjwvdT48L3A+DQogICAg ICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+ DQogICAgICAgICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjEyLjBwdCI+UGF1bCBpcw0KICAgICAgICAgICAgICAgICAgICAgICAgICAg IHByb3Bvc2luZyB0aGUgc2FtZSBzeW50YXggYXMgQ29ubmVjdC4mbmJzcDs8dT48L3U+PHU+PC91 PjwvcD4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj4NCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj4yMDEzLzMvMTIgUmljaGVyLA0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgSnVzdGluIFAuICZsdDs8YSBocmVmPSJtYWlsdG86anJp Y2hlckBtaXRyZS5vcmciIHRhcmdldD0iX2JsYW5rIj5qcmljaGVyQG1pdHJlLm9yZzwvYT4mZ3Q7 PHU+PC91Pjx1PjwvdT48L3A+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj4NCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IGRvZXMg cHJlc3VtZSBhDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGRlZmluaXRpb24gb2Yg JnF1b3Q7Y2xhaW0mcXVvdDssIHdoaWNoIEkgc3VwcG9zZQ0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB3ZSBjb3VsZCB0dXJuIHRvICZxdW90O21ldGFkYXRhIGZpZWxkJnF1b3Q7IGZv cg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBEeW5SZWcgYW5kIGl0cyBleHRlbnNp b25zIHRvIGJlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFwcHJvcHJpYXRlbHkg bGltaXRpbmcuIEJ1dCB3ZSBhbHNvIG5lZWQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgYSBnb29kIGRlZmluaXRpb24gb2Ygd2hhdCBhDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIGxhbmd1YWdlLXRhZy1sZXNzIGZpZWxkIG1lYW5zLCBhbmQNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgd2hldGhlciBvciBub3QgaXQmIzM5O3MgcmVxdWlyZWQgaWYgdGhl DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG90aGVyIGZpZWxkcyBhcmUgcHJlc2Vu dCBvciBub3QgKHdoaWNoDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGlzIHNvbWV0 aGluZyB0aGF0IENvbm5lY3QgaXMgdHJ5aW5nIHRvDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIGZpeCBhdCB0aGUgbW9tZW50LCBhcyBJIHJlY2FsbCBmcm9tIGxhc3QNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgd2VlaykuJm5ic3A7IDx1PjwvdT48dT48L3U+PC9wPg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj4NCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PHU+PC91Pjx1PjwvdT48L3A+ DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIDxkaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxwIGNs YXNzPSJNc29Ob3JtYWwiPlNvIGl0IHR1cm5zIGludG8NCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBhYm91dCBhIHBhcmFncmFwaCB3b3J0aCBvZiB0ZXh0LiBJcw0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHRoYXQgd29ydGggaXQ/IEkmIzM5O20gbm90IGVudGly ZWx5DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29udmluY2VkIHRoYXQgaXQg aXMsIGJ1dCBJJiMzOTttDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaW50ZXJl c3RlZCB0byBoZWFyIHdoYXQgb3RoZXJzIHRoaW5rLA0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHBhcnRpY3VsYXJseSB0aG9zZSB3aG8gKmFyZW4mIzM5O3QqIHRpZWQNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpbnRvIHRoZSBPcGVuSUQgQ29ubmVjdCBwcm90 b2NvbCBzbw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG11Y2guIChJIGRvbiYj Mzk7dCB3YW50IHRvIHBpY2sgYSBzb2x1dGlvbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIGp1c3QgYmVjYXVzZSBpdCYjMzk7cyBmYW1pbGlhciwgaWYgd2UgbmVlZA0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGEgc29sdXRpb24gYXQgYWxsLik8dT48L3U+PHU+ PC91PjwvcD4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj4NCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8dT48 L3U+PHU+PC91PjwvcD4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7LS0gSnVzdGluPHU+PC91 Pjx1PjwvdT48L3A+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2Pg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzx1PjwvdT48dT48L3U+PC9w Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+DQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICA8ZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNYXIgMTEsDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgMjAxMywgYXQgNjozNSBQTSwgQnJpYW4gQ2FtcGJl bGwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmbHQ7PGEgaHJlZj0i bWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tIiB0YXJnZXQ9Il9ibGFuayI+YmNhbXBi ZWxsQHBpbmdpZGVudGl0eS5jb208L2E+Jmd0Ozx1PjwvdT48dT48L3U+PC9wPg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICA8ZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICA8ZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+DQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDt3cm90ZTo8dT48L3U+PHU+PC91PjwvcD4NCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIDxkaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj5BIGZhaXINCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgcXVlc3Rpb24gYnV0IHdoYXQgd291bGQgbmVlZA0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0byBiZSBwdWxsZWQgaW4gaXMg cmVhbGx5DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHByb2Jh Ymx5IG9ubHkgYSBjb3VwbGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgc2VudGVuY2VzIChhbmQgcmVmZXJlbmNlKQ0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBmcm9tIDxhIGhyZWY9Imh0dHA6Ly9vcGVuaWQubmV0L3NwZWNz L29wZW5pZC1jb25uZWN0LW1lc3NhZ2VzLTFfMC0xNi5odG1sI0NsYWltc0xhbmd1YWdlc0FuZFNj cmlwdHMiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6Ly9vcGVuaWQubmV0L3NwZWNzL29wZW5pZC1j b25uZWN0LW1lc3NhZ2VzLTFfMC0xNi5odG1sI0NsYWltc0xhbmd1YWdlc0FuZFNjcmlwdHM8L2E+ DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChub3RlIHRoZSBy ZWZlcmVuY2UgdG8NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Mi4xLjEuMS4zIGluc2lkZSA8YSBocmVmPSJodHRwOi8vb3BlbmlkLm5ldC9zcGVjcy9vcGVuaWQt Y29ubmVjdC1yZWdpc3RyYXRpb24tMV8wLTE1Lmh0bWwiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6 Ly9vcGVuaWQubmV0L3NwZWNzL29wZW5pZC1jb25uZWN0LXJlZ2lzdHJhdGlvbi0xXzAtMTUuaHRt bDwvYT4gaXMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYnJv a2VuKTx1PjwvdT48dT48L3U+PC9wPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxk aXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPiZuYnNwOzx1PjwvdT48dT48 L3U+PC9wPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj4N CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1z b05vcm1hbCI+T24gTW9uLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIE1hciAxMSwgMjAxMyBhdCA2OjI2IFBNLA0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIFJpY2hlciwgSnVzdGluIFAuICZsdDs8YSBocmVmPSJtYWls dG86anJpY2hlckBtaXRyZS5vcmciIHRhcmdldD0iX2JsYW5rIj5qcmljaGVyQG1pdHJlLm9yZzwv YT4mZ3Q7DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB3 cm90ZTo8dT48L3U+PHU+PC91PjwvcD4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgPGRpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj5NeQ0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgY29uY2VybiB3aXRoIHRoaXMgaXMNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRoYXQgT0lEQyBjYW4gZ2V0IGF3 YXkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHdpdGgg ZGVmaW5pbmcgdGhpcw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgbXVsdGktbGFuZ3VhZ2Ugc3RydWN0dXJlDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBiZWNhdXNlIGl0IGRlZmluZXMgdGhlDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBtZWNoYW5pc20gb25jZSAoaW4N CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE1lc3NhZ2Vz KSBhbmQgYXBwbGllcyBpdA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgdG8gYWxsIHVzZXItcmVhZGFibGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHN0cmluZ3MgdGhyb3VnaG91dCB0aGUNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHdob2xlIGFwcGxpY2F0aW9uDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBwcm90b2NvbCwg b2Ygd2hpY2ggdGhlcmUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIGFyZSBzZXZlcmFsLiBEbyB3ZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgcmVhbGx5IHdhbnQgdG8gcHVsbCBpbg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhhdCB3aG9sZSBzdHJ1Y3R1cmUgYW5k DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBtZWNoYW5p c20gZm9yIG9uZSBmaWVsZA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgaW4gY2xpZW50IHJlZ2lzdHJhdGlvbj8NCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIEkgcmVhbGx5IGRvbiYjMzk7dCB0aGluayBpdA0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc2hvdWxkIGJlIHNv bWV0aGluZw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg dGhhdCYjMzk7cyBkZWZpbmVkDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBjb21wbGV0ZWx5IGluc2lkZSBvZg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgRHluUmVnIGZvciBhIGNvcm5lciBjYXNlDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBmb3IgYSBzaW5nbGUgZmll bGQsIGJ1dA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg SSBhbHNvIGRvdWJ0IHdlIHdhbnQgdG8NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIG5vcm1hdGl2ZWx5IHBvaW50IHRvDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBPSURDIE1lc3NhZ2VzIGZvciB0aGlzDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzb2x1dGlvbiBlaXRo ZXIuIDx1PjwvdT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIDx1PjwvdT48L3A+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgPGRpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzx1PjwvdT48dT48L3U+PC9wPg0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+DQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj5U aGVyZQ0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IGFyZSBhbHNvIG90aGVyIHdheXMgdG8NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgZG8gdGhpczogV2ViZmluZ2VyIFsxXQ0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBmb3IgaW5zdGFuY2UgdXNlcyBKU09O DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0cnVj dHVyZXMgdG8gZ2l2ZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBsYW5ndWFnZSB0YWdzIHRvIGZpZWxkDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHZhbHVlcywgYW5kIGhhcyBhDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGRlZmF1bHQgbWVjaGFuaXNtOjx1 PjwvdT48dT48L3U+PC9wPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIDxkaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICA8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8dT48L3U+PHU+PC91PjwvcD4NCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2Pg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZu YnNwO3sgJnF1b3Q7ZW5fdXMmcXVvdDs6ICZxdW90O215DQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNsaWVudCZxdW90OywgPHNwYW4gbGFuZz0iSkEi PiZoZWxsaXA7PC9zcGFuPiB9PHU+PC91Pjx1PjwvdT48L3A+DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzx1PjwvdT48 dT48L3U+PC9wPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxk aXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8cCBj bGFzcz0iTXNvTm9ybWFsIj5UaGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgZnVuZGFtZW50YWwgcXVlc3Rpb24NCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaXMgJm5ic3A7dGhpczogc2hvdWxkIGENCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY2xpZW50IGJl IGFibGUgdG8NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgcmVnaXN0ZXIgbXVsdGlwbGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgbmFtZXMgKGluIGRpZmZlcmVudA0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBsb2NhbGVzKSB3aXRoIGEgc2luZ2xlDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNsaWVudF9pZCwg b3Igc2hvdWxkDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIGl0IGdldCBhIGRpZmZlcmVudA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBjbGllbnRfaWQgZm9yIGVhY2gNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZGlzcGxheSBsYW5ndWFnZSBzZXQ/PHU+PC91 Pjx1PjwvdT48L3A+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICA8ZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8dT48L3U+PHU+PC91PjwvcD4NCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj4NCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7LS0NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIEp1c3Rpbjx1PjwvdT48dT48L3U+PC9wPg0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2Pg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 dT48L3U+PHU+PC91PjwvcD4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgPGRpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+WzFdJm5ic3A7PGEgaHJlZj0iaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1hcHBzYXdnLXdlYmZpbmdlci0xMSIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYXBwc2F3Zy13 ZWJmaW5nZXItMTE8L2E+PHU+PC91Pjx1PjwvdT48L3A+DQoNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj4NCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PHU+ PC91Pjx1PjwvdT48L3A+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIDxkaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgPGRpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uDQoNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTWFyIDExLCAyMDEzLCBh dA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICA1OjU0IFBNLCBKb2huDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIEJyYWRsZXkgJmx0OzxhIGhyZWY9Im1haWx0bzp2ZTdqdGJAdmU3anRi LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnZlN2p0YkB2ZTdqdGIuY29tPC9hPiZndDs8dT48L3U+PHU+ PC91PjwvcD4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICA8ZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7d3JvdGU6PHU+PC91Pjx1Pjwv dT48L3A+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgPGRpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIDxkaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+DQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+DQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05v cm1hbCI+VGhhdA0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgaXMgd2hhdCBJIHdhcw0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRoaW5raW5nLiAmbmJzcDsgSXQNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB3b3Vs ZCBiZSB1cCB0bw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHRoZSBBUyB0bw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIGRldGVybWluZSB3aGF0DQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbGFuZ3VhZ2UgYW5kDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg c2NyaXB0IHRvDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgcHJlc2VudCBiYXNlZA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIG9uIHRoZSB1c2VyDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcHJlZmVyZW5jZS4gPHU+ PC91Pjx1PjwvdT48L3A+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgPGRpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8dT48 L3U+PHU+PC91PjwvcD4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPldo aWxlDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBhIGxhcmdlIG51bWJlcg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIG9mIGNsaWVudHMNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB3aWxsIGJlIG5hdGl2ZQ0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFu ZCBtaWdodCBiZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIGFibGUgdG8NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBjdXN0b21pemUNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0aGVtc2VsdmVzIGZvcg0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGEgc2lu Z2xlIHVzZXINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBkdXJpbmcNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICByZWdpc3RyYXRpb24gLA0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHdlIGRvbiYjMzk7dCB3YW50DQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg dG8gZm9yZ2V0IHRoZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHdlYiBzZXJ2ZXINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjbGllbnRzIHRoYXQNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhcmUgbXVsdGkNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1 c2VyLjx1PjwvdT48dT48L3U+PC9wPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+DQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PHU+PC91Pjx1PjwvdT48L3A+DQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj4NCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2Pg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxwIGNsYXNz PSJNc29Ob3JtYWwiPk9uDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAyMDEzLTAzLTExLCBhdA0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDEwOjQ5IFBNLA0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEJyaWFuIENh bXBiZWxsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgJmx0OzxhIGhyZWY9Im1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbSIg dGFyZ2V0PSJfYmxhbmsiPmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPC9hPiZndDsNCg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHdy b3RlOjx1PjwvdT48dT48L3U+PC9wPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+DQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRp dj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj5GV0lXLA0KDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhlIGNsb3NlbHkNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICByZWxhdGVk IE9wZW5JRA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIENvbm5lY3QgY2xpZW50DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgcmVnaXN0cmF0aW9uDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZHJhZnQgZG9lcw0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGhh dmUgc29tZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHN1cHBvcnQgZm9yDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgZG9pbmcgdGhpcywNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB3aGljaCBjb3VsZA0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1heWJl IGJlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgYm9ycm93ZWQuIFNlZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIGNsaWVudF9uYW1lIGluDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPHNwYW4gbGFuZz0iSkEiPhsk QiF4GyhCPC9zcGFuPjINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBhdCA8YSBocmVmPSJodHRwOi8vb3BlbmlkLm5ldC9zcGVjcy9vcGVu aWQtY29ubmVjdC1yZWdpc3RyYXRpb24tMV8wLTE1Lmh0bWwjY2xpZW50LW1ldGFkYXRhIiB0YXJn ZXQ9Il9ibGFuayI+DQpodHRwOi8vb3BlbmlkLm5ldC9zcGVjcy9vcGVuaWQtY29ubmVjdC1yZWdp c3RyYXRpb24tMV8wLTE1Lmh0bWwjY2xpZW50LW1ldGFkYXRhPC9hPg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFuZCB0aGUNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBleGFt cGxlcy48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgJm5ic3A7PHU+PC91Pjx1PjwvdT48L3A+DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPHByZT4mbmJzcDsmbmJzcDsg JnF1b3Q7Y2xpZW50X25hbWUmcXVvdDs6ICZxdW90O015IEV4YW1wbGUmcXVvdDssPHU+PC91Pjx1 PjwvdT48L3ByZT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICA8cHJlPiZuYnNwOyZuYnNwOyAmcXVvdDtjbGllbnRfbmFtZSNqYS1KcGFu LUpQJnF1b3Q7OiZxdW90OzxzcGFuIGxhbmc9IkpBIj4bJEIlLyVpJSQlIiVzJUhMPhsoQjwvc3Bh bj4mcXVvdDssPHU+PC91Pjx1PjwvdT48L3ByZT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8dT48L3U+PHU+PC91PjwvcD4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2Pg0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7PHU+PC91Pjx1PjwvdT48L3A+ DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgPGRpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj5Pbg0KDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTW9uLCBNYXIgMTEsDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMjAx MyBhdCA1OjE1DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgUE0sIFJpY2hlciwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBKdXN0aW4gUC4gJmx0OzxhIGhyZWY9Im1haWx0bzpq cmljaGVyQG1pdHJlLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmpyaWNoZXJAbWl0cmUub3JnPC9hPiZn dDsNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHdyb3RlOjx1PjwvdT48dT48L3U+PC9wPg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0 DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB3YXMgYnJvdWdodCB1cA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIGF0IHRoZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGluLXBlcnNvbg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1lZXRpbmcgdG9kYXkN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB0aGF0IHdlJiMzOTtsbA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHdhbnQgdG8NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zaWRlcg0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGlzc3VlcyBhcm91bmQNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBp bnRlcm5hdGlvbmFsaXphdGlvbg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgYW5kDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbG9jYWxpemF0aW9uDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgb2YNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBodW1hbi1y ZWFkYWJsZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIGZpZWxkcyBsaWtlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgY2xpZW50X25hbWUgaW4NCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0aGUgY2xpZW50DQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcmVn aXN0cmF0aW9uLg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIFdoaWNoIGlzIHRvDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgc2F5OiBpZiBhDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY2xpZW50DQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3VwcG9ydHMg dGVuDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgbGFuZ3VhZ2VzIGFuZA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHdhbnRzIHRvDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcHJlc2VudCBpdHNlbGYNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpbiB0ZW4N CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBsYW5ndWFnZXMsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgc2hvdWxkIGl0IGhhdmUNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0byByZWdpc3Rlcg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGl0c2VsZiB0ZW4N CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB0aW1lcyB3aXRoIGFuDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgQVM/PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBdCB0aGUgbW9tZW50LA0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEkmIzM5 O20gb2YgdGhlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgb3BpbmlvbiBhDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgY2xpZW50IHdpdGgNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0ZW4gbGFuZ3VhZ2VzDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY291 bGQgcmVnaXN0ZXINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBpdHNlbGYgdGVuDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgdGltZXMsIG9yIGRvDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc29tZXRoaW5nIHdpdGgN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB0aGUgY29udGV4dCBpbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHdoaWNoIGl0IHJ1bnMNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0byBkZXRlcm1pbmUNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB3aGljaA0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IGh1bWFuLWZhY2luZw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIGxhbmd1YWdlIHRvDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdXNlLiBLZWVwIGluDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbWluZCB0aGF0IGlu DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgc29tZSBjYXNlcw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIChzdWNoIGFzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgbmF0aXZlDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY2xpZW50cyksDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgeW91JiMzOTts bCBiZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIGR5bmFtaWNhbGx5DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgcmVnaXN0ZXJpbmcgYQ0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNsaWVudCBmb3INCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBlYWNoIHVz ZXIsIGluDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgZWZmZWN0LiBJbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIG90aGVyIHdvcmRzLCBJDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcGVyc29uYWxseQ0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRoaW5r IHRoYXQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB0aGlzIGlzIGENCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICByYXRob2xlIHRoYXQNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB3aWxsIGNhdXNlDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbW9yZSBoYXJt IHRoYW4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBnb29kLjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgJm5ic3A7LS0gSnVzdGluPGJyPg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgT0F1dGggbWFpbGlu Zw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIGxpc3Q8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjx1PjwvdT48dT48L3U+PC9wPg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwv ZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzx1PjwvdT48dT48L3U+PC9wPg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwv ZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIE9BdXRoIG1haWxpbmcNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBsaXN0PGJyPg0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxhIGhy ZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3Jn PC9hPjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9vYXV0aDwvYT48dT48L3U+PHU+PC91PjwvcD4NCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8dT48L3U+PHU+PC91PjwvcD4NCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4N CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+ DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzx1PjwvdT48dT48L3U+PC9wPg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8dT48L3U+PHU+PC91PjwvcD4N CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8dT48L3U+PHU+PC91PjwvcD4NCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxi cj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vb2F1dGg8L2E+PHU+PC91Pjx1PjwvdT48L3A+DQogICAgICAgICAgICAgICAgICAg ICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9y bWFsIj48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgPGJyIGNsZWFyPSJhbGwiPg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDx1PjwvdT48dT48L3U+PC9wPg0KICAgICAgICAg ICAgICAgICAgICAgICAgICA8ZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzx1PjwvdT48dT48L3U+PC9wPg0KICAgICAgICAgICAgICAg ICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1z b05vcm1hbCI+LS0gPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIE5hdCBTYWtpbXVy YSAoPW5hdCkgPHU+PC91Pjx1PjwvdT48L3A+DQogICAgICAgICAgICAgICAgICAgICAgICAgIDxk aXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hh aXJtYW4sIE9wZW5JRA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRm91bmRhdGlvbjxi cj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxhIGhyZWY9Imh0dHA6Ly9uYXQuc2Fr aW11cmEub3JnLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9uYXQuc2FraW11cmEub3JnLzwvYT48 YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBAX25hdF9lbjx1PjwvdT48dT48L3U+ PC9wPg0KICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAg ICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgIDwvYmxvY2txdW90ZT4NCiAgICAg ICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAg ICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgIDx1PjwvdT48dT48L3U+ PC9wPg0KICAgICAgICAgICAgICAgICAgICAgIDxwcmU+X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188dT48L3U+PHU+PC91PjwvcHJlPg0KICAgICAgICAgICAg ICAgICAgICAgIDxwcmU+T0F1dGggbWFpbGluZyBsaXN0PHU+PC91Pjx1PjwvdT48L3ByZT4NCiAg ICAgICAgICAgICAgICAgICAgICA8cHJlPjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjx1PjwvdT48dT48L3U+PC9wcmU+DQog ICAgICAgICAgICAgICAgICAgICAgPHByZT48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48dT48L3U+PHU+PC91PjwvcHJlPg0KICAgICAg ICAgICAgICAgICAgICA8L2Jsb2NrcXVvdGU+DQogICAgICAgICAgICAgICAgICAgIDxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzx1PjwvdT48dT48L3U+PC9wPg0KICAgICAgICAgICAgICAgICAg PC9ibG9ja3F1b3RlPg0KICAgICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PHU+PC91Pjx1PjwvdT48L3A+DQogICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAg ICAgIDwvYmxvY2txdW90ZT4NCiAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHU+ PC91PiZuYnNwOzx1PjwvdT48L3A+DQogICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICA8L2Js b2NrcXVvdGU+DQogICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHU+PC91PiZuYnNwOzx1 PjwvdT48L3A+DQogICAgICAgIDwvZGl2Pg0KICAgICAgPC9ibG9ja3F1b3RlPg0KICAgICAgPGJy Pg0KICAgICAgPGJyPg0KICAgICAgPGZpZWxkc2V0PjwvZmllbGRzZXQ+DQogICAgICA8YnI+DQog ICAgICA8cHJlPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpPQXV0aCBtYWlsaW5nIGxpc3QNCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+DQo8L3ByZT4NCiAgICA8L2Rpdj48 L2Rpdj48L2Jsb2NrcXVvdGU+DQogICAgPGJyPg0KICA8L2Rpdj4NCg0KPGJyPl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBs aXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwv YT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h dXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9vYXV0aDwvYT48YnI+DQo8YnI+PC9ibG9ja3F1b3RlPjwvZGl2Pjxicj48YnIgY2xlYXI9ImFs bCI+PGRpdj48YnI+PC9kaXY+LS0gPGJyPk5hdCBTYWtpbXVyYSAoPW5hdCk8ZGl2PkNoYWlybWFu LCBPcGVuSUQgRm91bmRhdGlvbjxicj48YSBocmVmPSJodHRwOi8vbmF0LnNha2ltdXJhLm9yZy8i IHRhcmdldD0iX2JsYW5rIj5odHRwOi8vbmF0LnNha2ltdXJhLm9yZy88L2E+PGJyPkBfbmF0X2Vu PC9kaXY+DQo8L2Rpdj4NCg== --f46d0401f8fb6ec68504d878a1d0-- From sakimura@gmail.com Thu Mar 21 17:44: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 DFCD621F8B97 for ; Thu, 21 Mar 2013 17:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.162 X-Spam-Level: X-Spam-Status: No, score=-1.162 tagged_above=-999 required=5 tests=[AWL=-0.316, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, 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 g11kvvsDCr3t for ; Thu, 21 Mar 2013 17:44:29 -0700 (PDT) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id C861521F8B7E for ; Thu, 21 Mar 2013 17:44:28 -0700 (PDT) Received: by mail-la0-f41.google.com with SMTP id fo12so6341746lab.0 for ; Thu, 21 Mar 2013 17:44:27 -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=mwOqx8Jfp1fCrwKfx1mZdUSKRNdL1aTnWeISemYkcK4=; b=tCtBnTVjj6l92Aprto5jxUMBTQWFmkcnmZlbDi2jI278j5e8542AqYbLKuYi3T1jqG E9Ag0/tnOSZ0tg1EV5dvhUkEpqGg86QyQ7jCUDXVgMnk7yDvUHd278MfsU6tJmyIzSSl eXvCCfnFiG8Sl6j2BlU2RDt7UWp3WcWEXtz21r6HasEsxZgESSbTEnOH/y52P6yMUAQP ygYjA/6mnEzZjRIV7/Y61elkGS68HQC7GwuZs4Buy+WhRzVnhrmek+g5h1NZlE2EUqU3 KDKQKuk+Qt1WNObs6nqrBHxfyRn8W29/Wji1U+YMfNQYKHUAihGh+OcI5Wy0cU/Abetl Dtdg== MIME-Version: 1.0 X-Received: by 10.152.132.138 with SMTP id ou10mr8751797lab.56.1363913067517; Thu, 21 Mar 2013 17:44:27 -0700 (PDT) Received: by 10.112.103.202 with HTTP; Thu, 21 Mar 2013 17:44:27 -0700 (PDT) In-Reply-To: References: <1B4C0C9F-4B8E-4B2D-BAF7-665D3EBBE56C@ve7jtb.com> <51408B8B.9000800@mitre.org> <5141E2E6.9020701@aol.com> <5141E671.2050708@mitre.org> <4E1F6AAD24975D4BA5B16804296739436750F5E2@TK5EX14MBXC283.redmond.corp.microsoft.com> <5149F092.7070902@mitre.org> <4E1F6AAD24975D4BA5B168042967394367565FEF@TK5EX14MBXC283.redmond.corp.microsoft.com> <5149F534.1040500@mitre.org> <4E1F6AAD24975D4BA5B168042967394367567185@TK5EX14MBXC283.redmond.corp.microsoft.com> <514B4E28.7000309@mitre.org> Date: Fri, 22 Mar 2013 09:44:27 +0900 Message-ID: From: Nat Sakimura To: Justin Richer Content-Type: multipart/alternative; boundary=f46d042d051ce4dda804d878c1bf Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readable names X-BeenThere: oauth@ietf.org X-Mailman-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, 22 Mar 2013 00:44:36 -0000 --f46d042d051ce4dda804d878c1bf Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit I withdraw the comment. Somehow, for a moment, charset and encoding was flipped in my head. Maybe I need a vacation. Sorry. Nat 2013/3/22 Nat Sakimura > Can we tighten it a bit as to the encoding is concerned? > I believe all the fields value MUST be UTF-8, so it propagates here as > well. > Saying that it must not make any assumption on character set (e.g., UTF-8) > is a bit too much. > Proposed text: > > Fields with human-readable values or references to human-readable values, > such as client_name, tos_uri, policy_uri, and client_uri, MAY be > represented in multiple languages and scripts, specified by appending a # > character and the RFC5646 language tag. If any such human-readable field is > sent without a language tag, the server and the client MUST NOT make any > assumptions about the language, script, and country of the value string, > and the value string MUST be used as-is wherever it is presented in either > the client or server UI. To facilitate interoperability, it is RECOMMENDED > that any fields sent without language tags contain an internationalized > UTF-8 string suitable for display on a wide variety of systems, and it is > RECOMMENDED that clients send fields without language tags in addition to > any more-specifically denominated values. > > > 2013/3/22 Justin Richer > >> We discussed this issue on the OpenID Connect WG call this morning, in a >> conversation that included myself, George Fletcher, Nat Sakimura, Mike >> Jones, and John Bradley (among others) as active participants in this >> thread. After lots of debate, we propose that the OAuth DynReg adopt the >> hashtag-based localization method of OIDC (and it seems, possibly >> webfinger) and explicitly declare that neither the client nor the server >> make any assumptions about the content of the string and treat it as just a >> string. I'm proposing this text to that effect (with the references to >> OIDC-messages removed and replaced with the rule description itself in >> OAuth DynReg): >> >> Fields with human-readable values or references to human-readable values, >> such as client_name, tos_uri, policy_uri, and client_uri, MAY be >> represented in multiple languages and scripts, specified by appending a # >> character and the RFC5646 language tag. If any such human-readable field is >> sent without a language tag, the server and the client MUST NOT make any >> assumptions about the language, character set, or script of the value >> string, and the value string MUST be used as-is wherever it is presented in >> either the client or server UI. To facilitate interoperability, it is >> RECOMMENDED that any fields sent without language tags contain an >> internationalized UTF-8 string suitable for display on a wide variety of >> systems, and it is RECOMMENDED that clients send fields without language >> tags in addition to any more-specifically denominated values. >> >> >> Plus some examples. >> >> (Anyone whose name I took in vain, please feel free to correct me.) >> >> -- Justin >> >> >> On 03/20/2013 03:11 PM, Justin Richer wrote: >> >> I agree that I'm seeing things from the single-language and >> single-encoding perspective here, and that's the use case I'm currently >> solving for with my development. I want to see this one remain simple, and >> I think we can do that without breaking other use cases. >> >> I would argue that multi-script languages (such as Chinese, Japanese, and >> others) are all cases where you're going to assume multiple languages, and >> the tags would be necessary for real use. So client and AS would both need >> to know how to deal with the multiple different tags, and smart ones would >> be able to effectively ignore the default field. The default, scriptless >> field could be for any one of the supported languages at the AS or Client, >> and it'd effectively be a backup, internationalized version, the one that >> you use when there's nothing else more specific to use. >> >> I guess what's getting me stuck on the explicit locale field is that I'm >> not seeing much value in requiring it over George's proposal of always >> using language tags on everything (which I also don't like, but for >> different reasons). Having the information doesn't mean that you can do >> anything intelligent with it, either, but I can see the argument that it >> makes doing something smart possible. But on the other hand, we already >> have a mechanism for doing something smart: using the explicit language >> tags directly. >> >> Also, note that the AS doesn't need to render any characters for tos_uri, >> policy_uri, and other _uri options, just for client_name. That's why I was >> making the distinction in my explanation below. You might want to give the >> user the right option, sure, but a served webpage has a much better chance >> of getting the locale right dynamically than an included string would have >> (approaches like user preferences, browser settings, etc. -- everything >> that's used today on web pages, in other words). This is why I think that >> the _uri claims are in a different category and we're talking almost >> exclusively about client_name here. >> >> I think, ultimately, that I need to think about this more. >> >> -- Justin >> >> On 03/20/2013 02:30 PM, Mike Jones wrote: >> >> I suspect you only feel that leaving the locale information out is OK >> because you (and I) live in a culture where it$B!G(Bs not needed to adequately >> render characters. I$B!G(Bd actually defer on this decision to Nat and others >> from Japan and China (and I think Korea?) where I believe that this >> information is essential.**** >> >> ** ** >> >> For what it$B!G(Bs worth, it$B!G(Bs more than just client_name. It$B!G(Bs also tos_uri >> and policy_uri and potentially client_uri.**** >> >> ** ** >> >> Also, having thought about it for a few days, I$B!G(Bd change the proposed >> field name from registration_locale to default_registration_locale, so the >> meaning is clearer.**** >> >> ** ** >> >> Nat and others from Eastern cultures, what is your opinion on this?**** >> >> ** ** >> >> Thanks,**** >> >> -- Mike**** >> >> ** ** >> >> *From:* Justin Richer [mailto:jricher@mitre.org ] >> *Sent:* Wednesday, March 20, 2013 10:43 AM >> *To:* Mike Jones >> *Cc:* George Fletcher; oauth@ietf.org WG >> *Subject:* Re: [OAUTH-WG] Registration: Internationalization of >> Human-Readable names**** >> >> ** ** >> >> I would say that claims without a language parameter, which I would make >> REQUIRED in the presence of other claims, would be treated as UTF8 strings >> with no guarantee of what language, script, or other locale-specific >> information would be in there. It's a default string, and it's the best the >> client can give if nothing more specific is useful. And servers would have >> to accept this default string and do their best with it. A service provider >> can publish their expected default locale information in either discovery >> or service documentation, and clients that want to tweak things for >> specific service providers can do that. >> >> The server can display it (because it's a string that'll always be there, >> if any version is there), but a server that doesn't do internationalized >> strings very well might not get its display correct. Since displayable text >> this is likely to be dumped into the middle of a webpage that has its own >> character encoding and other considerations anyway, so it's not guaranteed >> that specifying a locale will always help here anyway. This is just for the >> displayable text, which right now is only the client_name field in OAuth >> and OIDC: for URLs (the other "human-readable" field), it's a moot point, >> because the server's just going to spit out the URL itself into an href of >> some flavor. The server doesn't have to deal with any kind of encoding or >> text/script issues here. >> >> As a server developer, it's just another thing that I *have* to track and >> deal with on the client model, even if I don't want to support the rest of >> the multi-language tags in my service. As a client developer, it's one more >> thing that I *have* to specify when I send things to the server. I don't >> see how requiring its specification is going to really help >> interoperability, and I can almost guarantee that implementations will just >> leave it off even if marked REQUIRED (like how many, many documents in the >> wild that are supposed to have a character-encoding field of some type just >> leave it off). >> >> I think that it's a lot of work on both sides for just client_name. >> >> -- Justin >> >> **** >> >> On 03/20/2013 01:27 PM, Mike Jones wrote:**** >> >> How would you do this instead then?**** >> ------------------------------ >> >> *From: *Justin Richer >> *Sent: *3/20/2013 10:25 AM >> *To: *Mike Jones >> *Cc: *George Fletcher; oauth@ietf.org WG >> *Subject: *Re: [OAUTH-WG] Registration: Internationalization of >> Human-Readable names**** >> >> Personally, I think that this level of specificity is overkill. >> >> -- Justin >> >> **** >> >> On 03/14/2013 11:42 AM, Mike Jones wrote:**** >> >> I agree that having unadorned values likely simplifies things in many >> cases, but if we do this, we should let the Client say what language/script >> it$B!G(Bs using when providing human-readable strings or references to them as >> registration parameters. For this purpose, I$B!G(Bd propose that we have a >> parameter something like this one:**** >> >> **** >> >> registration_locale**** >> >> OPTIONAL or REQURED. Language and script used for human-readable values >> or references to human-readable values that are supplied without >> language/script tags, represented as a BCP47[RFC5646] language tag value. >> This parameter is REQUIRED if any human-readable values or references to >> human-readable are provided without language/script tags.**** >> >> **** >> >> -- Mike**** >> >> **** >> >> *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] >> *On Behalf Of *Justin Richer >> *Sent:* Thursday, March 14, 2013 8:02 AM >> *To:* George Fletcher >> *Cc:* oauth@ietf.org WG >> *Subject:* Re: [OAUTH-WG] Registration: Internationalization of >> Human-Readable names**** >> >> **** >> >> On the surface this does simplify things, but the issue I forsee with it >> is that I want to be able to call "client.getClientName()" and always get >> *something* out of it if there are *any* client_name fields at all. So in >> this world if I take a client library that assumes en-us and it talks to a >> server that only looks for es-cl, there's a very real chance of the client >> name not getting set at all. I think that's a problem. >> >> This is why I think the default field name (without the language tag) >> really should be required and should be left undefined as to what language >> and script it is. Essentially, "It's a UTF8 String, hope for the best". If >> you want something more specific and smart about localization, then you can >> support the language tags. If you just want to have a string to store and >> throw at the user, then you can just use the bare field name. >> >> In other words, we take what we have now (which works for a >> non-internationalized case where everyone just assumes a common >> language/script), and we augment it with features that let it be smarter if >> you want it to be smarter. Make the simple case simple, make the >> complicated case possible. >> >> -- Justin >> >> **** >> >> On 03/14/2013 10:47 AM, George Fletcher wrote:**** >> >> As a simplifying option... why not just require human-readable fields to >> require a "script-tag". This way it is always explicit what language/locale >> the text is for. It then becomes the responsibility of the AS to return an >> appropriate response if there is not a direct match between a request and >> the data stored at the AS (and out of scope of the spec). >> >> Thanks, >> George**** >> >> On 3/13/13 10:22 AM, Justin Richer wrote:**** >> >> So with what little feedback I've gotten, I'm proposing to add text from >> the proposed webfinger and OIDC drafts for the hash-based localization of >> strings, with the following properties: >> >> * All localized versions of fields are fully optional on both client and >> server >> * If a localized version of a field is included, its bare-value (perhaps >> internationalized) field MUST be included >> * All human-readable fields are eligible for this mechanism (including >> any uri's for user-facing web pages, which can be used to point to >> language-specific pages) >> * Clients and servers can decide to use whatever language/script they >> want to for the bare-value field, and no assumptions can be made on either >> side about what that is >> >> I think that with these constraints, we can add functionality to address >> Stephen's concerns without getting too complicated or putting too much >> burden of support. >> >> -- Justin**** >> >> On 03/11/2013 06:52 PM, Nat Sakimura wrote:**** >> >> Similar work is in progress at Webfinger. **** >> >> **** >> >> See: http://www.ietf.org/mail-archive/web/webfinger/current/msg00530.html >> **** >> >> **** >> >> Paul is proposing the same syntax as Connect. **** >> >> 2013/3/12 Richer, Justin P. **** >> >> It does presume a definition of "claim", which I suppose we could turn to >> "metadata field" for DynReg and its extensions to be appropriately >> limiting. But we also need a good definition of what a language-tag-less >> field means, and whether or not it's required if the other fields are >> present or not (which is something that Connect is trying to fix at the >> moment, as I recall from last week). **** >> >> **** >> >> So it turns into about a paragraph worth of text. Is that worth it? I'm >> not entirely convinced that it is, but I'm interested to hear what others >> think, particularly those who *aren't* tied into the OpenID Connect >> protocol so much. (I don't want to pick a solution just because it's >> familiar, if we need a solution at all.)**** >> >> **** >> >> -- Justin**** >> >> **** >> >> On Mar 11, 2013, at 6:35 PM, Brian Campbell * >> *** >> >> wrote:**** >> >> ** ** >> >> A fair question but what would need to be pulled in is really probably >> only a couple sentences (and reference) from >> http://openid.net/specs/openid-connect-messages-1_0-16.html#ClaimsLanguagesAndScripts(note the reference to 2.1.1.1.3 inside >> http://openid.net/specs/openid-connect-registration-1_0-15.html is >> broken)**** >> >> **** >> >> On Mon, Mar 11, 2013 at 6:26 PM, Richer, Justin P. >> wrote:**** >> >> My concern with this is that OIDC can get away with defining this >> multi-language structure because it defines the mechanism once (in >> Messages) and applies it to all user-readable strings throughout the whole >> application protocol, of which there are several. Do we really want to pull >> in that whole structure and mechanism for one field in client registration? >> I really don't think it should be something that's defined completely >> inside of DynReg for a corner case for a single field, but I also doubt we >> want to normatively point to OIDC Messages for this solution either. ** * >> * >> >> **** >> >> There are also other ways to do this: Webfinger [1] for instance uses >> JSON structures to give language tags to field values, and has a default >> mechanism:**** >> >> **** >> >> { "en_us": "my client", $B!D(B }**** >> >> **** >> >> The fundamental question is this: should a client be able to register >> multiple names (in different locales) with a single client_id, or should it >> get a different client_id for each display language set?**** >> >> **** >> >> -- Justin**** >> >> **** >> >> [1] http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-11**** >> >> **** >> >> On Mar 11, 2013, at 5:54 PM, John Bradley **** >> >> wrote:**** >> >> ** ** >> >> That is what I was thinking. It would be up to the AS to determine what >> language and script to present based on the user preference. **** >> >> **** >> >> While a large number of clients will be native and might be able to >> customize themselves for a single user during registration , we don't want >> to forget the web server clients that are multi user.**** >> >> **** >> >> On 2013-03-11, at 10:49 PM, Brian Campbell >> wrote:**** >> >> ** ** >> >> FWIW, the closely related OpenID Connect client registration draft does >> have some support for doing this, which could maybe be borrowed. See >> client_name in $B!x(B2 at >> http://openid.net/specs/openid-connect-registration-1_0-15.html#client-metadataand the examples. >> **** >> >> "client_name": "My Example",**** >> >> "client_name#ja-Jpan-JP":"$B%/%i%$%"%s%HL>(B",**** >> >> **** >> >> **** >> >> On Mon, Mar 11, 2013 at 5:15 PM, Richer, Justin P. >> wrote:**** >> >> It was brought up at the in-person meeting today that we'll want to >> consider issues around internationalization and localization of >> human-readable fields like client_name in the client registration. Which is >> to say: if a client supports ten languages and wants to present itself in >> ten languages, should it have to register itself ten times with an AS? >> >> At the moment, I'm of the opinion a client with ten languages could >> register itself ten times, or do something with the context in which it >> runs to determine which human-facing language to use. Keep in mind that in >> some cases (such as native clients), you'll be dynamically registering a >> client for each user, in effect. In other words, I personally think that >> this is a rathole that will cause more harm than good. >> >> -- Justin >> _______________________________________________ >> OAuth mailing 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**** >> >> >> >> **** >> >> **** >> >> -- >> Nat Sakimura (=nat) **** >> >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en**** >> >> >> >> >> **** >> >> _______________________________________________**** >> >> OAuth mailing list**** >> >> OAuth@ietf.org**** >> >> https://www.ietf.org/mailman/listinfo/oauth**** >> >> **** >> >> **** >> >> ** ** >> >> ** ** >> >> >> >> >> _______________________________________________ >> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > > > -- > Nat Sakimura (=nat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --f46d042d051ce4dda804d878c1bf Content-Type: text/html; charset=ISO-2022-JP Content-Transfer-Encoding: base64 SSB3aXRoZHJhdyB0aGUgY29tbWVudC4mbmJzcDs8ZGl2Pjxicj48L2Rpdj48ZGl2PlNvbWVob3cs IGZvciBhIG1vbWVudCwgY2hhcnNldCBhbmQgZW5jb2Rpbmcgd2FzIGZsaXBwZWQgaW4gbXkgaGVh ZC4mbmJzcDs8L2Rpdj48ZGl2Pk1heWJlIEkgbmVlZCBhIHZhY2F0aW9uLiZuYnNwOzwvZGl2Pjxk aXY+PGJyPjwvZGl2PjxkaXY+U29ycnkuJm5ic3A7PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5O YXQ8L2Rpdj48ZGl2Pjxicj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4yMDEzLzMvMjIgTmF0 IFNha2ltdXJhIDxzcGFuIGRpcj0ibHRyIj4mbHQ7PGEgaHJlZj0ibWFpbHRvOnNha2ltdXJhQGdt YWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnNha2ltdXJhQGdtYWlsLmNvbTwvYT4mZ3Q7PC9zcGFu Pjxicj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAg LjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCkNhbiB3 ZSB0aWdodGVuIGl0IGEgYml0IGFzIHRvIHRoZSBlbmNvZGluZyBpcyBjb25jZXJuZWQ/Jm5ic3A7 PGRpdj5JIGJlbGlldmUgYWxsIHRoZSBmaWVsZHMgdmFsdWUgTVVTVCBiZSBVVEYtOCwgc28gaXQg cHJvcGFnYXRlcyBoZXJlIGFzIHdlbGwuICZuYnNwOzwvZGl2PjxkaXY+U2F5aW5nIHRoYXQgaXQg bXVzdCBub3QgbWFrZSBhbnkgYXNzdW1wdGlvbiBvbiBjaGFyYWN0ZXIgc2V0IChlLmcuLCBVVEYt OCkgaXMgYSBiaXQgdG9vIG11Y2guJm5ic3A7PC9kaXY+DQoNCjxkaXY+UHJvcG9zZWQgdGV4dDom bmJzcDs8L2Rpdj48ZGl2Pjxicj48L2Rpdj48YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luOjAgMCAw IDQwcHg7Ym9yZGVyOm5vbmU7cGFkZGluZzowcHgiPjxkaXY+RmllbGRzIHdpdGggaHVtYW4tcmVh ZGFibGUgdmFsdWVzIG9yIHJlZmVyZW5jZXMgdG8gaHVtYW4tcmVhZGFibGUgdmFsdWVzLCBzdWNo IGFzIGNsaWVudF9uYW1lLCB0b3NfdXJpLCBwb2xpY3lfdXJpLCBhbmQgY2xpZW50X3VyaSwgTUFZ IGJlIHJlcHJlc2VudGVkIGluIG11bHRpcGxlIGxhbmd1YWdlcyBhbmQgc2NyaXB0cywgc3BlY2lm aWVkIGJ5IGFwcGVuZGluZyBhICMgY2hhcmFjdGVyIGFuZCB0aGUgUkZDNTY0NiBsYW5ndWFnZSB0 YWcuIElmIGFueSBzdWNoIGh1bWFuLXJlYWRhYmxlIGZpZWxkIGlzIHNlbnQgd2l0aG91dCBhIGxh bmd1YWdlIHRhZywgdGhlIHNlcnZlciBhbmQgdGhlIGNsaWVudCBNVVNUIE5PVCBtYWtlIGFueSBh c3N1bXB0aW9ucyBhYm91dCB0aGUgbGFuZ3VhZ2UsIHNjcmlwdCwgYW5kIGNvdW50cnkgb2YgdGhl IHZhbHVlIHN0cmluZywgYW5kIHRoZSB2YWx1ZSBzdHJpbmcgTVVTVCBiZSB1c2VkIGFzLWlzIHdo ZXJldmVyIGl0IGlzIHByZXNlbnRlZCBpbiBlaXRoZXIgdGhlIGNsaWVudCBvciBzZXJ2ZXIgVUku IFRvIGZhY2lsaXRhdGUgaW50ZXJvcGVyYWJpbGl0eSwgaXQgaXMgUkVDT01NRU5ERUQgdGhhdCBh bnkgZmllbGRzIHNlbnQgd2l0aG91dCBsYW5ndWFnZSB0YWdzIGNvbnRhaW4gYW4gaW50ZXJuYXRp b25hbGl6ZWQgVVRGLTggc3RyaW5nIHN1aXRhYmxlIGZvciBkaXNwbGF5IG9uIGEgd2lkZSB2YXJp ZXR5IG9mIHN5c3RlbXMsIGFuZCBpdCBpcyBSRUNPTU1FTkRFRCB0aGF0IGNsaWVudHMgc2VuZCBm aWVsZHMgd2l0aG91dCBsYW5ndWFnZSB0YWdzIGluIGFkZGl0aW9uIHRvIGFueSBtb3JlLXNwZWNp ZmljYWxseSBkZW5vbWluYXRlZCB2YWx1ZXMuPC9kaXY+DQoNCjwvYmxvY2txdW90ZT48ZGl2IGNs YXNzPSJIT0VuWmIiPjxkaXYgY2xhc3M9Img1Ij48ZGl2Pjxicj48ZGl2IGNsYXNzPSJnbWFpbF9x dW90ZSI+MjAxMy8zLzIyIEp1c3RpbiBSaWNoZXIgPHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBocmVm PSJtYWlsdG86anJpY2hlckBtaXRyZS5vcmciIHRhcmdldD0iX2JsYW5rIj5qcmljaGVyQG1pdHJl Lm9yZzwvYT4mZ3Q7PC9zcGFuPjxicj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0 eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5n LWxlZnQ6MWV4Ij4NCg0KDQogIA0KICAgIA0KICANCiAgPGRpdiBiZ2NvbG9yPSIjRkZGRkZGIiB0 ZXh0PSIjMDAwMDAwIj4NCiAgICBXZSBkaXNjdXNzZWQgdGhpcyBpc3N1ZSBvbiB0aGUgT3BlbklE IENvbm5lY3QgV0cgY2FsbCB0aGlzIG1vcm5pbmcsDQogICAgaW4gYSBjb252ZXJzYXRpb24gdGhh dCBpbmNsdWRlZCBteXNlbGYsIEdlb3JnZSBGbGV0Y2hlciwgTmF0DQogICAgU2FraW11cmEsIE1p a2UgSm9uZXMsIGFuZCBKb2huIEJyYWRsZXkgKGFtb25nIG90aGVycykgYXMgYWN0aXZlDQogICAg cGFydGljaXBhbnRzIGluIHRoaXMgdGhyZWFkLiBBZnRlciBsb3RzIG9mIGRlYmF0ZSwgd2UgcHJv cG9zZSB0aGF0DQogICAgdGhlIE9BdXRoIER5blJlZyBhZG9wdCB0aGUgaGFzaHRhZy1iYXNlZCBs b2NhbGl6YXRpb24gbWV0aG9kIG9mIE9JREMNCiAgICAoYW5kIGl0IHNlZW1zLCBwb3NzaWJseSB3 ZWJmaW5nZXIpIGFuZCBleHBsaWNpdGx5IGRlY2xhcmUgdGhhdA0KICAgIG5laXRoZXIgdGhlIGNs aWVudCBub3IgdGhlIHNlcnZlciBtYWtlIGFueSBhc3N1bXB0aW9ucyBhYm91dCB0aGUNCiAgICBj b250ZW50IG9mIHRoZSBzdHJpbmcgYW5kIHRyZWF0IGl0IGFzIGp1c3QgYSBzdHJpbmcuIEkmIzM5 O20gcHJvcG9zaW5nDQogICAgdGhpcyB0ZXh0IHRvIHRoYXQgZWZmZWN0ICh3aXRoIHRoZSByZWZl cmVuY2VzIHRvIE9JREMtbWVzc2FnZXMNCiAgICByZW1vdmVkIGFuZCByZXBsYWNlZCB3aXRoIHRo ZSBydWxlIGRlc2NyaXB0aW9uIGl0c2VsZiBpbiBPQXV0aA0KICAgIER5blJlZyk6PGJyPg0KICAg IDxicj4NCiAgICA8YmxvY2txdW90ZT5GaWVsZHMgd2l0aCBodW1hbi1yZWFkYWJsZSB2YWx1ZXMg b3IgcmVmZXJlbmNlcyB0bw0KICAgICAgaHVtYW4tcmVhZGFibGUgdmFsdWVzLCBzdWNoIGFzIGNs aWVudF9uYW1lLCB0b3NfdXJpLCBwb2xpY3lfdXJpLA0KICAgICAgYW5kIGNsaWVudF91cmksIE1B WSBiZSByZXByZXNlbnRlZCBpbiBtdWx0aXBsZSBsYW5ndWFnZXMgYW5kDQogICAgICBzY3JpcHRz LCBzcGVjaWZpZWQgYnkgYXBwZW5kaW5nIGEgIyBjaGFyYWN0ZXIgYW5kIHRoZSBSRkM1NjQ2DQog ICAgICBsYW5ndWFnZSB0YWcuIElmIGFueSBzdWNoIGh1bWFuLXJlYWRhYmxlIGZpZWxkIGlzIHNl bnQgd2l0aG91dCBhDQogICAgICBsYW5ndWFnZSB0YWcsIHRoZSBzZXJ2ZXIgYW5kIHRoZSBjbGll bnQgTVVTVCBOT1QgbWFrZSBhbnkNCiAgICAgIGFzc3VtcHRpb25zIGFib3V0IHRoZSBsYW5ndWFn ZSwgY2hhcmFjdGVyIHNldCwgb3Igc2NyaXB0IG9mIHRoZQ0KICAgICAgdmFsdWUgc3RyaW5nLCBh bmQgdGhlIHZhbHVlIHN0cmluZyBNVVNUIGJlIHVzZWQgYXMtaXMgd2hlcmV2ZXIgaXQNCiAgICAg IGlzIHByZXNlbnRlZCBpbiBlaXRoZXIgdGhlIGNsaWVudCBvciBzZXJ2ZXIgVUkuIFRvIGZhY2ls aXRhdGUNCiAgICAgIGludGVyb3BlcmFiaWxpdHksIGl0IGlzIFJFQ09NTUVOREVEIHRoYXQgYW55 IGZpZWxkcyBzZW50IHdpdGhvdXQNCiAgICAgIGxhbmd1YWdlIHRhZ3MgY29udGFpbiBhbiBpbnRl cm5hdGlvbmFsaXplZCBVVEYtOCBzdHJpbmcgc3VpdGFibGUNCiAgICAgIGZvciBkaXNwbGF5IG9u IGEgd2lkZSB2YXJpZXR5IG9mIHN5c3RlbXMsIGFuZCBpdCBpcyBSRUNPTU1FTkRFRA0KICAgICAg dGhhdCBjbGllbnRzIHNlbmQgZmllbGRzIHdpdGhvdXQgbGFuZ3VhZ2UgdGFncyBpbiBhZGRpdGlv biB0byBhbnkNCiAgICAgIG1vcmUtc3BlY2lmaWNhbGx5IGRlbm9taW5hdGVkIHZhbHVlcy48YnI+ DQogICAgPC9ibG9ja3F1b3RlPg0KICAgIDxicj4NCiAgICBQbHVzIHNvbWUgZXhhbXBsZXMuPGJy Pg0KICAgIDxicj4NCiAgICAoQW55b25lIHdob3NlIG5hbWUgSSB0b29rIGluIHZhaW4sIHBsZWFz ZSBmZWVsIGZyZWUgdG8gY29ycmVjdCBtZS4pPHNwYW4+PGZvbnQgY29sb3I9IiM4ODg4ODgiPjxi cj4NCiAgICA8YnI+DQogICAgJm5ic3A7LS0gSnVzdGluPC9mb250Pjwvc3Bhbj48ZGl2Pjxicj4N CiAgICA8YnI+DQogICAgPGRpdj5PbiAwMy8yMC8yMDEzIDAzOjExIFBNLCBKdXN0aW4gUmljaGVy DQogICAgICB3cm90ZTo8YnI+DQogICAgPC9kaXY+DQogICAgPC9kaXY+PGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSI+PGRpdj4NCiAgICAgIA0KICAgICAgSSBhZ3JlZSB0aGF0IEkmIzM5O20gc2VlaW5n IHRoaW5ncyBmcm9tIHRoZSBzaW5nbGUtbGFuZ3VhZ2UgYW5kDQogICAgICBzaW5nbGUtZW5jb2Rp bmcgcGVyc3BlY3RpdmUgaGVyZSwgYW5kIHRoYXQmIzM5O3MgdGhlIHVzZSBjYXNlIEkmIzM5O20N CiAgICAgIGN1cnJlbnRseSBzb2x2aW5nIGZvciB3aXRoIG15IGRldmVsb3BtZW50LiBJIHdhbnQg dG8gc2VlIHRoaXMgb25lDQogICAgICByZW1haW4gc2ltcGxlLCBhbmQgSSB0aGluayB3ZSBjYW4g ZG8gdGhhdCB3aXRob3V0IGJyZWFraW5nIG90aGVyDQogICAgICB1c2UgY2FzZXMuPGJyPg0KICAg ICAgPGJyPg0KICAgICAgSSB3b3VsZCBhcmd1ZSB0aGF0IG11bHRpLXNjcmlwdCBsYW5ndWFnZXMg KHN1Y2ggYXMgQ2hpbmVzZSwNCiAgICAgIEphcGFuZXNlLCBhbmQgb3RoZXJzKSBhcmUgYWxsIGNh c2VzIHdoZXJlIHlvdSYjMzk7cmUgZ29pbmcgdG8gYXNzdW1lDQogICAgICBtdWx0aXBsZSBsYW5n dWFnZXMsIGFuZCB0aGUgdGFncyB3b3VsZCBiZSBuZWNlc3NhcnkgZm9yIHJlYWwgdXNlLg0KICAg ICAgU28gY2xpZW50IGFuZCBBUyB3b3VsZCBib3RoIG5lZWQgdG8ga25vdyBob3cgdG8gZGVhbCB3 aXRoIHRoZQ0KICAgICAgbXVsdGlwbGUgZGlmZmVyZW50IHRhZ3MsIGFuZCBzbWFydCBvbmVzIHdv dWxkIGJlIGFibGUgdG8NCiAgICAgIGVmZmVjdGl2ZWx5IGlnbm9yZSB0aGUgZGVmYXVsdCBmaWVs ZC4gVGhlIGRlZmF1bHQsIHNjcmlwdGxlc3MNCiAgICAgIGZpZWxkIGNvdWxkIGJlIGZvciBhbnkg b25lIG9mIHRoZSBzdXBwb3J0ZWQgbGFuZ3VhZ2VzIGF0IHRoZSBBUyBvcg0KICAgICAgQ2xpZW50 LCBhbmQgaXQmIzM5O2QgZWZmZWN0aXZlbHkgYmUgYSBiYWNrdXAsIGludGVybmF0aW9uYWxpemVk DQogICAgICB2ZXJzaW9uLCB0aGUgb25lIHRoYXQgeW91IHVzZSB3aGVuIHRoZXJlJiMzOTtzIG5v dGhpbmcgZWxzZSBtb3JlDQogICAgICBzcGVjaWZpYyB0byB1c2UuIDxicj4NCiAgICAgIDxicj4N CiAgICAgIEkgZ3Vlc3Mgd2hhdCYjMzk7cyBnZXR0aW5nIG1lIHN0dWNrIG9uIHRoZSBleHBsaWNp dCBsb2NhbGUgZmllbGQgaXMNCiAgICAgIHRoYXQgSSYjMzk7bSBub3Qgc2VlaW5nIG11Y2ggdmFs dWUgaW4gcmVxdWlyaW5nIGl0IG92ZXIgR2VvcmdlJiMzOTtzDQogICAgICBwcm9wb3NhbCBvZiBh bHdheXMgdXNpbmcgbGFuZ3VhZ2UgdGFncyBvbiBldmVyeXRoaW5nICh3aGljaCBJIGFsc28NCiAg ICAgIGRvbiYjMzk7dCBsaWtlLCBidXQgZm9yIGRpZmZlcmVudCByZWFzb25zKS4gSGF2aW5nIHRo ZSBpbmZvcm1hdGlvbg0KICAgICAgZG9lc24mIzM5O3QgbWVhbiB0aGF0IHlvdSBjYW4gZG8gYW55 dGhpbmcgaW50ZWxsaWdlbnQgd2l0aCBpdCwgZWl0aGVyLA0KICAgICAgYnV0IEkgY2FuIHNlZSB0 aGUgYXJndW1lbnQgdGhhdCBpdCBtYWtlcyBkb2luZyBzb21ldGhpbmcgc21hcnQNCiAgICAgIHBv c3NpYmxlLiBCdXQgb24gdGhlIG90aGVyIGhhbmQsIHdlIGFscmVhZHkgaGF2ZSBhIG1lY2hhbmlz bSBmb3INCiAgICAgIGRvaW5nIHNvbWV0aGluZyBzbWFydDogdXNpbmcgdGhlIGV4cGxpY2l0IGxh bmd1YWdlIHRhZ3MgZGlyZWN0bHkuDQogICAgICA8YnI+DQogICAgICA8YnI+DQogICAgICBBbHNv LCBub3RlIHRoYXQgdGhlIEFTIGRvZXNuJiMzOTt0IG5lZWQgdG8gcmVuZGVyIGFueSBjaGFyYWN0 ZXJzIGZvcg0KICAgICAgdG9zX3VyaSwgcG9saWN5X3VyaSwgYW5kIG90aGVyIF91cmkgb3B0aW9u cywganVzdCBmb3IgY2xpZW50X25hbWUuDQogICAgICBUaGF0JiMzOTtzIHdoeSBJIHdhcyBtYWtp bmcgdGhlIGRpc3RpbmN0aW9uIGluIG15IGV4cGxhbmF0aW9uIGJlbG93Lg0KICAgICAgWW91IG1p Z2h0IHdhbnQgdG8gZ2l2ZSB0aGUgdXNlciB0aGUgcmlnaHQgb3B0aW9uLCBzdXJlLCBidXQgYQ0K ICAgICAgc2VydmVkIHdlYnBhZ2UgaGFzIGEgbXVjaCBiZXR0ZXIgY2hhbmNlIG9mIGdldHRpbmcg dGhlIGxvY2FsZQ0KICAgICAgcmlnaHQgZHluYW1pY2FsbHkgdGhhbiBhbiBpbmNsdWRlZCBzdHJp bmcgd291bGQgaGF2ZSAoYXBwcm9hY2hlcw0KICAgICAgbGlrZSB1c2VyIHByZWZlcmVuY2VzLCBi cm93c2VyIHNldHRpbmdzLCBldGMuIC0tIGV2ZXJ5dGhpbmcgdGhhdCYjMzk7cw0KICAgICAgdXNl ZCB0b2RheSBvbiB3ZWIgcGFnZXMsIGluIG90aGVyIHdvcmRzKS4gVGhpcyBpcyB3aHkgSSB0aGlu ayB0aGF0DQogICAgICB0aGUgX3VyaSBjbGFpbXMgYXJlIGluIGEgZGlmZmVyZW50IGNhdGVnb3J5 IGFuZCB3ZSYjMzk7cmUgdGFsa2luZw0KICAgICAgYWxtb3N0IGV4Y2x1c2l2ZWx5IGFib3V0IGNs aWVudF9uYW1lIGhlcmUuPGJyPg0KICAgICAgPGJyPg0KICAgICAgSSB0aGluaywgdWx0aW1hdGVs eSwgdGhhdCBJIG5lZWQgdG8gdGhpbmsgYWJvdXQgdGhpcyBtb3JlLjxicj4NCiAgICAgIDxicj4N CiAgICAgICZuYnNwOyAtLSBKdXN0aW48YnI+DQogICAgICA8YnI+DQogICAgICA8ZGl2Pk9uIDAz LzIwLzIwMTMgMDI6MzAgUE0sIE1pa2UgSm9uZXMNCiAgICAgICAgd3JvdGU6PGJyPg0KICAgICAg PC9kaXY+DQogICAgICA8L2Rpdj48ZGl2PjxkaXY+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQog ICAgICAgIA0KICAgICAgICANCiAgICAgICAgDQogICAgICAgIDxkaXY+DQogICAgICAgICAgPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxZjQ5 N2QiPkkNCiAgICAgICAgICAgICAgc3VzcGVjdCB5b3Ugb25seSBmZWVsIHRoYXQgbGVhdmluZyB0 aGUgbG9jYWxlIGluZm9ybWF0aW9uDQogICAgICAgICAgICAgIG91dCBpcyBPSyBiZWNhdXNlIHlv dSAoYW5kIEkpIGxpdmUgaW4gYSBjdWx0dXJlIHdoZXJlIGl0JnJzcXVvO3MNCiAgICAgICAgICAg ICAgbm90IG5lZWRlZCB0byBhZGVxdWF0ZWx5IHJlbmRlciBjaGFyYWN0ZXJzLiZuYnNwOyBJJnJz cXVvO2QgYWN0dWFsbHkNCiAgICAgICAgICAgICAgZGVmZXIgb24gdGhpcyBkZWNpc2lvbiB0byBO YXQgYW5kIG90aGVycyBmcm9tIEphcGFuIGFuZA0KICAgICAgICAgICAgICBDaGluYSAoYW5kIEkg dGhpbmsgS29yZWE/KSB3aGVyZSBJIGJlbGlldmUgdGhhdCB0aGlzDQogICAgICAgICAgICAgIGlu Zm9ybWF0aW9uIGlzIGVzc2VudGlhbC48dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQogICAgICAg ICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxZjQ5N2QiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9zcGFuPjwvcD4NCiAgICAgICAgICA8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFmNDk3 ZCI+Rm9yDQoNCiAgICAgICAgICAgICAgd2hhdCBpdCZyc3F1bztzIHdvcnRoLCBpdCZyc3F1bztz IG1vcmUgdGhhbiBqdXN0IGNsaWVudF9uYW1lLiZuYnNwOyBJdCZyc3F1bztzDQogICAgICAgICAg ICAgIGFsc28gdG9zX3VyaSBhbmQgcG9saWN5X3VyaSBhbmQgcG90ZW50aWFsbHkgY2xpZW50X3Vy aS48dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQogICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxZjQ5N2QiPjx1PjwvdT4mbmJz cDs8dT48L3U+PC9zcGFuPjwvcD4NCiAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFmNDk3ZCI+QWxzbywNCg0KICAgICAgICAg ICAgICBoYXZpbmcgdGhvdWdodCBhYm91dCBpdCBmb3IgYSBmZXcgZGF5cywgSSZyc3F1bztkIGNo YW5nZSB0aGUNCiAgICAgICAgICAgICAgcHJvcG9zZWQgZmllbGQgbmFtZSBmcm9tIHJlZ2lzdHJh dGlvbl9sb2NhbGUgdG8NCiAgICAgICAgICAgICAgZGVmYXVsdF9yZWdpc3RyYXRpb25fbG9jYWxl LCBzbyB0aGUgbWVhbmluZyBpcyBjbGVhcmVyLjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCiAg ICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFmNDk3ZCI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3NwYW4+PC9wPg0KICAgICAgICAg IDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MWY0OTdkIj5OYXQNCg0KICAgICAgICAgICAgICBhbmQgb3RoZXJzIGZyb20gRWFzdGVybiBjdWx0 dXJlcywgd2hhdCBpcyB5b3VyIG9waW5pb24gb24NCiAgICAgICAgICAgICAgdGhpcz88dT48L3U+ PHU+PC91Pjwvc3Bhbj48L3A+DQogICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxZjQ5N2QiPjx1PjwvdT4mbmJzcDs8dT48L3U+ PC9zcGFuPjwvcD4NCiAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFmNDk3ZCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQoNCiAgICAgICAgICAg ICAgVGhhbmtzLDx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCiAgICAgICAgICA8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFmNDk3ZCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7DQoNCiAgICAgICAgICAgICAgLS0gTWlrZTx1PjwvdT48dT48L3U+PC9zcGFuPjwv cD4NCiAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFmNDk3ZCI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3NwYW4+PC9wPg0KICAg ICAgICAgIDxkaXY+DQogICAgICAgICAgICA8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNiNWM0ZGYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQogICAg ICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4NCiAgICAgICAgICAgICAgICAgIEp1c3RpbiBSaWNo ZXIgWzxhIGhyZWY9Im1haWx0bzpqcmljaGVyQG1pdHJlLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1h aWx0bzpqcmljaGVyQG1pdHJlLm9yZzwvYT5dDQogICAgICAgICAgICAgICAgICA8YnI+DQogICAg ICAgICAgICAgICAgICA8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBNYXJjaCAyMCwgMjAxMyAxMDo0 MyBBTTxicj4NCiAgICAgICAgICAgICAgICAgIDxiPlRvOjwvYj4gTWlrZSBKb25lczxicj4NCiAg ICAgICAgICAgICAgICAgIDxiPkNjOjwvYj4gR2VvcmdlIEZsZXRjaGVyOyA8YSBocmVmPSJtYWls dG86b2F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aEBpZXRmLm9yZzwvYT4gV0c8 YnI+DQogICAgICAgICAgICAgICAgICA8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gUmVn aXN0cmF0aW9uOg0KICAgICAgICAgICAgICAgICAgSW50ZXJuYXRpb25hbGl6YXRpb24gb2YgSHVt YW4tUmVhZGFibGUgbmFtZXM8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQogICAgICAgICAgICA8 L2Rpdj4NCiAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48 dT48L3U+Jm5ic3A7PHU+PC91PjwvcD4NCiAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkkgd291bGQgc2F5DQogICAgICAgICAgICB0aGF0 IGNsYWltcyB3aXRob3V0IGEgbGFuZ3VhZ2UgcGFyYW1ldGVyLCB3aGljaCBJIHdvdWxkIG1ha2UN CiAgICAgICAgICAgIFJFUVVJUkVEIGluIHRoZSBwcmVzZW5jZSBvZiBvdGhlciBjbGFpbXMsIHdv dWxkIGJlIHRyZWF0ZWQNCiAgICAgICAgICAgIGFzIFVURjggc3RyaW5ncyB3aXRoIG5vIGd1YXJh bnRlZSBvZiB3aGF0IGxhbmd1YWdlLCBzY3JpcHQsDQogICAgICAgICAgICBvciBvdGhlciBsb2Nh bGUtc3BlY2lmaWMgaW5mb3JtYXRpb24gd291bGQgYmUgaW4gdGhlcmUuIEl0JiMzOTtzDQogICAg ICAgICAgICBhIGRlZmF1bHQgc3RyaW5nLCBhbmQgaXQmIzM5O3MgdGhlIGJlc3QgdGhlIGNsaWVu dCBjYW4gZ2l2ZSBpZg0KICAgICAgICAgICAgbm90aGluZyBtb3JlIHNwZWNpZmljIGlzIHVzZWZ1 bC4gQW5kIHNlcnZlcnMgd291bGQgaGF2ZSB0bw0KICAgICAgICAgICAgYWNjZXB0IHRoaXMgZGVm YXVsdCBzdHJpbmcgYW5kIGRvIHRoZWlyIGJlc3Qgd2l0aCBpdC4gQQ0KICAgICAgICAgICAgc2Vy dmljZSBwcm92aWRlciBjYW4gcHVibGlzaCB0aGVpciBleHBlY3RlZCBkZWZhdWx0IGxvY2FsZQ0K ICAgICAgICAgICAgaW5mb3JtYXRpb24gaW4gZWl0aGVyIGRpc2NvdmVyeSBvciBzZXJ2aWNlIGRv Y3VtZW50YXRpb24sDQogICAgICAgICAgICBhbmQgY2xpZW50cyB0aGF0IHdhbnQgdG8gdHdlYWsg dGhpbmdzIGZvciBzcGVjaWZpYyBzZXJ2aWNlDQogICAgICAgICAgICBwcm92aWRlcnMgY2FuIGRv IHRoYXQuPGJyPg0KICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgVGhlIHNlcnZlciBjYW4g ZGlzcGxheSBpdCAoYmVjYXVzZSBpdCYjMzk7cyBhIHN0cmluZyB0aGF0JiMzOTtsbA0KICAgICAg ICAgICAgYWx3YXlzIGJlIHRoZXJlLCBpZiBhbnkgdmVyc2lvbiBpcyB0aGVyZSksIGJ1dCBhIHNl cnZlciB0aGF0DQogICAgICAgICAgICBkb2VzbiYjMzk7dCBkbyBpbnRlcm5hdGlvbmFsaXplZCBz dHJpbmdzIHZlcnkgd2VsbCBtaWdodCBub3QgZ2V0DQogICAgICAgICAgICBpdHMgZGlzcGxheSBj b3JyZWN0LiBTaW5jZSBkaXNwbGF5YWJsZSB0ZXh0IHRoaXMgaXMgbGlrZWx5DQogICAgICAgICAg ICB0byBiZSBkdW1wZWQgaW50byB0aGUgbWlkZGxlIG9mIGEgd2VicGFnZSB0aGF0IGhhcyBpdHMg b3duDQogICAgICAgICAgICBjaGFyYWN0ZXIgZW5jb2RpbmcgYW5kIG90aGVyIGNvbnNpZGVyYXRp b25zIGFueXdheSwgc28gaXQmIzM5O3MNCiAgICAgICAgICAgIG5vdCBndWFyYW50ZWVkIHRoYXQg c3BlY2lmeWluZyBhIGxvY2FsZSB3aWxsIGFsd2F5cyBoZWxwDQogICAgICAgICAgICBoZXJlIGFu eXdheS4gVGhpcyBpcyBqdXN0IGZvciB0aGUgZGlzcGxheWFibGUgdGV4dCwgd2hpY2gNCiAgICAg ICAgICAgIHJpZ2h0IG5vdyBpcyBvbmx5IHRoZSBjbGllbnRfbmFtZSBmaWVsZCBpbiBPQXV0aCBh bmQgT0lEQzoNCiAgICAgICAgICAgIGZvciBVUkxzICh0aGUgb3RoZXIgJnF1b3Q7aHVtYW4tcmVh ZGFibGUmcXVvdDsgZmllbGQpLCBpdCYjMzk7cyBhIG1vb3QNCiAgICAgICAgICAgIHBvaW50LCBi ZWNhdXNlIHRoZSBzZXJ2ZXImIzM5O3MganVzdCBnb2luZyB0byBzcGl0IG91dCB0aGUgVVJMDQog ICAgICAgICAgICBpdHNlbGYgaW50byBhbiBocmVmIG9mIHNvbWUgZmxhdm9yLiBUaGUgc2VydmVy IGRvZXNuJiMzOTt0IGhhdmUNCiAgICAgICAgICAgIHRvIGRlYWwgd2l0aCBhbnkga2luZCBvZiBl bmNvZGluZyBvciB0ZXh0L3NjcmlwdCBpc3N1ZXMNCiAgICAgICAgICAgIGhlcmUuIDxicj4NCiAg ICAgICAgICAgIDxicj4NCiAgICAgICAgICAgIEFzIGEgc2VydmVyIGRldmVsb3BlciwgaXQmIzM5 O3MganVzdCBhbm90aGVyIHRoaW5nIHRoYXQgSSAqaGF2ZSoNCiAgICAgICAgICAgIHRvIHRyYWNr IGFuZCBkZWFsIHdpdGggb24gdGhlIGNsaWVudCBtb2RlbCwgZXZlbiBpZiBJIGRvbiYjMzk7dA0K ICAgICAgICAgICAgd2FudCB0byBzdXBwb3J0IHRoZSByZXN0IG9mIHRoZSBtdWx0aS1sYW5ndWFn ZSB0YWdzIGluIG15DQogICAgICAgICAgICBzZXJ2aWNlLiBBcyBhIGNsaWVudCBkZXZlbG9wZXIs IGl0JiMzOTtzIG9uZSBtb3JlIHRoaW5nIHRoYXQgSQ0KICAgICAgICAgICAgKmhhdmUqIHRvIHNw ZWNpZnkgd2hlbiBJIHNlbmQgdGhpbmdzIHRvIHRoZSBzZXJ2ZXIuIEkgZG9uJiMzOTt0DQogICAg ICAgICAgICBzZWUgaG93IHJlcXVpcmluZyBpdHMgc3BlY2lmaWNhdGlvbiBpcyBnb2luZyB0byBy ZWFsbHkgaGVscA0KICAgICAgICAgICAgaW50ZXJvcGVyYWJpbGl0eSwgYW5kIEkgY2FuIGFsbW9z dCBndWFyYW50ZWUgdGhhdA0KICAgICAgICAgICAgaW1wbGVtZW50YXRpb25zIHdpbGwganVzdCBs ZWF2ZSBpdCBvZmYgZXZlbiBpZiBtYXJrZWQNCiAgICAgICAgICAgIFJFUVVJUkVEIChsaWtlIGhv dyBtYW55LCBtYW55IGRvY3VtZW50cyBpbiB0aGUgd2lsZCB0aGF0IGFyZQ0KICAgICAgICAgICAg c3VwcG9zZWQgdG8gaGF2ZSBhIGNoYXJhY3Rlci1lbmNvZGluZyBmaWVsZCBvZiBzb21lIHR5cGUN CiAgICAgICAgICAgIGp1c3QgbGVhdmUgaXQgb2ZmKS4gPGJyPg0KICAgICAgICAgICAgPGJyPg0K ICAgICAgICAgICAgSSB0aGluayB0aGF0IGl0JiMzOTtzIGEgbG90IG9mIHdvcmsgb24gYm90aCBz aWRlcyBmb3IganVzdA0KICAgICAgICAgICAgY2xpZW50X25hbWUuPGJyPg0KICAgICAgICAgICAg PGJyPg0KICAgICAgICAgICAgJm5ic3A7LS0gSnVzdGluPGJyPg0KICAgICAgICAgICAgPGJyPg0K ICAgICAgICAgICAgPHU+PC91Pjx1PjwvdT48L3A+DQogICAgICAgICAgPGRpdj4NCiAgICAgICAg ICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDAzLzIwLzIwMTMgMDE6MjcgUE0sIE1pa2UgSm9u ZXMNCiAgICAgICAgICAgICAgd3JvdGU6PHU+PC91Pjx1PjwvdT48L3A+DQogICAgICAgICAgPC9k aXY+DQogICAgICAgICAgPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQogICAgICAgICAgICA8ZGl2Pg0KICAgICAgICAgICAgICA8ZGl2Pg0K ICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Ib3cNCg0KICAgICAgICAgICAg ICAgICAgICB3b3VsZCB5b3UgZG8gdGhpcyBpbnN0ZWFkIHRoZW4/PHU+PC91Pjx1PjwvdT48L3Nw YW4+PC9wPg0KICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgIDwvZGl2Pg0KICAgICAg ICAgICAgPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiIGFs aWduPSJjZW50ZXIiPg0KICAgICAgICAgICAgICA8aHIgYWxpZ249ImNlbnRlciIgc2l6ZT0iMyIg d2lkdGg9IjEwMCUiPiA8L2Rpdj4NCiAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PkZyb206DQoNCiAgICAgICAgICAgICAgICA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5KdXN0aW4NCg0KICAgICAgICAgICAgICAgIFJpY2hlcjwvc3Bhbj48YnI+DQogICAg ICAgICAgICAgIDxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5TZW50Og0KDQogICAgICAg ICAgICAgICAgPC9zcGFuPiA8L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjMvMjAvMjAx Mw0KDQogICAgICAgICAgICAgICAgMTA6MjUgQU08L3NwYW4+PGJyPg0KICAgICAgICAgICAgICA8 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+VG86DQoNCiAgICAgICAgICAgICAgICA8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5NaWtlDQoNCiAgICAgICAgICAgICAg ICBKb25lczwvc3Bhbj48YnI+DQogICAgICAgICAgICAgIDxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5DYzoNCg0KICAgICAgICAgICAgICAgIDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPkdlb3JnZQ0KDQogICAgICAgICAgICAgICAgRmxldGNoZXI7IDxhIGhyZWY9 Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoQGlldGYub3JnPC9h PiBXRzwvc3Bhbj48YnI+DQogICAgICAgICAgICAgIDxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5TdWJqZWN0Og0KDQogICAgICAgICAgICAgICAgPC9zcGFuPiA8L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPlJlOg0KDQogICAgICAgICAgICAgICAgW09BVVRILVdHXSBSZWdpc3Ry YXRpb246IEludGVybmF0aW9uYWxpemF0aW9uIG9mDQogICAgICAgICAgICAgICAgSHVtYW4tUmVh ZGFibGUgbmFtZXM8L3NwYW4+PHU+PC91Pjx1PjwvdT48L3A+DQogICAgICAgICAgICA8ZGl2Pg0K ICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox Mi4wcHQiPlBlcnNvbmFsbHksDQoNCiAgICAgICAgICAgICAgICBJIHRoaW5rIHRoYXQgdGhpcyBs ZXZlbCBvZiBzcGVjaWZpY2l0eSBpcyBvdmVya2lsbC48YnI+DQogICAgICAgICAgICAgICAgPGJy Pg0KICAgICAgICAgICAgICAgICZuYnNwOy0tIEp1c3Rpbjxicj4NCiAgICAgICAgICAgICAgICA8 YnI+DQogICAgICAgICAgICAgICAgPHU+PC91Pjx1PjwvdT48L3A+DQogICAgICAgICAgICAgIDxk aXY+DQogICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMDMvMTQvMjAxMyAx MTo0MiBBTSwgTWlrZSBKb25lcw0KICAgICAgICAgICAgICAgICAgd3JvdGU6PHU+PC91Pjx1Pjwv dT48L3A+DQogICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICA8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCiAgICAgICAgICAg ICAgICA8ZGl2Pg0KICAgICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxZjQ5N2QiPkkNCiAgICAgICAgICAgICAgICAg ICAgICBhZ3JlZSB0aGF0IGhhdmluZyB1bmFkb3JuZWQgdmFsdWVzIGxpa2VseQ0KICAgICAgICAg ICAgICAgICAgICAgIHNpbXBsaWZpZXMgdGhpbmdzIGluIG1hbnkgY2FzZXMsIGJ1dCBpZiB3ZSBk bw0KICAgICAgICAgICAgICAgICAgICAgIHRoaXMsIHdlIHNob3VsZCBsZXQgdGhlIENsaWVudCBz YXkgd2hhdA0KICAgICAgICAgICAgICAgICAgICAgIGxhbmd1YWdlL3NjcmlwdCBpdCZyc3F1bztz IHVzaW5nIHdoZW4gcHJvdmlkaW5nDQogICAgICAgICAgICAgICAgICAgICAgaHVtYW4tcmVhZGFi bGUgc3RyaW5ncyBvciByZWZlcmVuY2VzIHRvIHRoZW0gYXMNCiAgICAgICAgICAgICAgICAgICAg ICByZWdpc3RyYXRpb24gcGFyYW1ldGVycy4mbmJzcDsgRm9yIHRoaXMgcHVycG9zZSwgSSZyc3F1 bztkDQogICAgICAgICAgICAgICAgICAgICAgcHJvcG9zZSB0aGF0IHdlIGhhdmUgYSBwYXJhbWV0 ZXIgc29tZXRoaW5nIGxpa2UNCiAgICAgICAgICAgICAgICAgICAgICB0aGlzIG9uZTo8L3NwYW4+ PHU+PC91Pjx1PjwvdT48L3A+DQogICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFmNDk3ZCI+Jm5ic3A7PC9zcGFu Pjx1PjwvdT48dT48L3U+PC9wPg0KICAgICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyIgbGFuZz0iRU4iPnJlZ2lzdHJhdGlvbl9sb2NhbGU8L3NwYW4+PHU+PC91 Pjx1PjwvdT48L3A+DQogICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRh bmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyIgbGFuZz0iRU4iPk9QVElPTkFMIG9yIFJF UVVSRUQuIExhbmd1YWdlIGFuZCBzY3JpcHQNCiAgICAgICAgICAgICAgICAgICAgICB1c2VkIGZv ciBodW1hbi1yZWFkYWJsZSB2YWx1ZXMgb3IgcmVmZXJlbmNlcyB0bw0KICAgICAgICAgICAgICAg ICAgICAgIGh1bWFuLXJlYWRhYmxlIHZhbHVlcyB0aGF0IGFyZSBzdXBwbGllZCB3aXRob3V0DQog ICAgICAgICAgICAgICAgICAgICAgbGFuZ3VhZ2Uvc2NyaXB0IHRhZ3MsIHJlcHJlc2VudGVkIGFz IGENCiAgICAgICAgICAgICAgICAgICAgICBCQ1A0N1tSRkM1NjQ2XSBsYW5ndWFnZSB0YWcgdmFs dWUuJm5ic3A7IFRoaXMgcGFyYW1ldGVyDQogICAgICAgICAgICAgICAgICAgICAgaXMgUkVRVUlS RUQgaWYgYW55IGh1bWFuLXJlYWRhYmxlIHZhbHVlcyBvcg0KICAgICAgICAgICAgICAgICAgICAg IHJlZmVyZW5jZXMgdG8gaHVtYW4tcmVhZGFibGUgYXJlIHByb3ZpZGVkIHdpdGhvdXQNCiAgICAg ICAgICAgICAgICAgICAgICBsYW5ndWFnZS9zY3JpcHQgdGFncy48L3NwYW4+PHU+PC91Pjx1Pjwv dT48L3A+DQogICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFmNDk3ZCI+Jm5ic3A7PC9zcGFuPjx1PjwvdT48dT48 L3U+PC9wPg0KICAgICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxZjQ5N2QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KDQogICAgICAg ICAgICAgICAgICAgICAgLS0gTWlrZTwvc3Bhbj48dT48L3U+PHU+PC91PjwvcD4NCiAgICAgICAg ICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMWY0OTdkIj4mbmJzcDs8L3NwYW4+PHU+PC91Pjx1PjwvdT48L3A+DQogICAgICAg ICAgICAgICAgICA8ZGl2Pg0KICAgICAgICAgICAgICAgICAgICA8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNiNWM0ZGYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGlu IDBpbiI+DQogICAgICAgICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPg0KICAgICAgICAg ICAgICAgICAgICAgICAgICA8YSBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+DQogICAgICAgICAgICAg ICAgICAgICAgICAgIFs8YSBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPm1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPC9hPl0NCiAgICAgICAg ICAgICAgICAgICAgICAgICAgPGI+T24gQmVoYWxmIE9mIDwvYj5KdXN0aW4gUmljaGVyPGJyPg0K ICAgICAgICAgICAgICAgICAgICAgICAgICA8Yj5TZW50OjwvYj4gVGh1cnNkYXksIE1hcmNoIDE0 LCAyMDEzIDg6MDIgQU08YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgIDxiPlRvOjwvYj4g R2VvcmdlIEZsZXRjaGVyPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICA8Yj5DYzo8L2I+ IDxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoQGll dGYub3JnPC9hPg0KICAgICAgICAgICAgICAgICAgICAgICAgICBXRzxicj4NCiAgICAgICAgICAg ICAgICAgICAgICAgICAgPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIFJlZ2lzdHJhdGlv bjoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgSW50ZXJuYXRpb25hbGl6YXRpb24gb2YgSHVt YW4tUmVhZGFibGUgbmFtZXM8L3NwYW4+PHU+PC91Pjx1PjwvdT48L3A+DQogICAgICAgICAgICAg ICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAg ICA8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8dT48L3U+PHU+PC91PjwvcD4NCiAgICAgICAg ICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIHRoZSBzdXJmYWNlIHRoaXMgZG9lcyBz aW1wbGlmeQ0KICAgICAgICAgICAgICAgICAgICB0aGluZ3MsIGJ1dCB0aGUgaXNzdWUgSSBmb3Jz ZWUgd2l0aCBpdCBpcyB0aGF0IEkNCiAgICAgICAgICAgICAgICAgICAgd2FudCB0byBiZSBhYmxl IHRvIGNhbGwgJnF1b3Q7Y2xpZW50LmdldENsaWVudE5hbWUoKSZxdW90OyBhbmQNCiAgICAgICAg ICAgICAgICAgICAgYWx3YXlzIGdldCAqc29tZXRoaW5nKiBvdXQgb2YgaXQgaWYgdGhlcmUgYXJl ICphbnkqDQogICAgICAgICAgICAgICAgICAgIGNsaWVudF9uYW1lIGZpZWxkcyBhdCBhbGwuIFNv IGluIHRoaXMgd29ybGQgaWYgSQ0KICAgICAgICAgICAgICAgICAgICB0YWtlIGEgY2xpZW50IGxp YnJhcnkgdGhhdCBhc3N1bWVzIGVuLXVzIGFuZCBpdA0KICAgICAgICAgICAgICAgICAgICB0YWxr cyB0byBhIHNlcnZlciB0aGF0IG9ubHkgbG9va3MgZm9yIGVzLWNsLCB0aGVyZSYjMzk7cw0KICAg ICAgICAgICAgICAgICAgICBhIHZlcnkgcmVhbCBjaGFuY2Ugb2YgdGhlIGNsaWVudCBuYW1lIG5v dCBnZXR0aW5nDQogICAgICAgICAgICAgICAgICAgIHNldCBhdCBhbGwuIEkgdGhpbmsgdGhhdCYj Mzk7cyBhIHByb2JsZW0uPGJyPg0KICAgICAgICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAg ICAgICAgICAgIFRoaXMgaXMgd2h5IEkgdGhpbmsgdGhlIGRlZmF1bHQgZmllbGQgbmFtZSAod2l0 aG91dA0KICAgICAgICAgICAgICAgICAgICB0aGUgbGFuZ3VhZ2UgdGFnKSByZWFsbHkgc2hvdWxk IGJlIHJlcXVpcmVkIGFuZA0KICAgICAgICAgICAgICAgICAgICBzaG91bGQgYmUgbGVmdCB1bmRl ZmluZWQgYXMgdG8gd2hhdCBsYW5ndWFnZSBhbmQNCiAgICAgICAgICAgICAgICAgICAgc2NyaXB0 IGl0IGlzLiBFc3NlbnRpYWxseSwgJnF1b3Q7SXQmIzM5O3MgYSBVVEY4IFN0cmluZywgaG9wZQ0K ICAgICAgICAgICAgICAgICAgICBmb3IgdGhlIGJlc3QmcXVvdDsuIElmIHlvdSB3YW50IHNvbWV0 aGluZyBtb3JlIHNwZWNpZmljDQogICAgICAgICAgICAgICAgICAgIGFuZCBzbWFydCBhYm91dCBs b2NhbGl6YXRpb24sIHRoZW4geW91IGNhbiBzdXBwb3J0DQogICAgICAgICAgICAgICAgICAgIHRo ZSBsYW5ndWFnZSB0YWdzLiBJZiB5b3UganVzdCB3YW50IHRvIGhhdmUgYSBzdHJpbmcNCiAgICAg ICAgICAgICAgICAgICAgdG8gc3RvcmUgYW5kIHRocm93IGF0IHRoZSB1c2VyLCB0aGVuIHlvdSBj YW4ganVzdA0KICAgICAgICAgICAgICAgICAgICB1c2UgdGhlIGJhcmUgZmllbGQgbmFtZS4gPGJy Pg0KICAgICAgICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAgICAgICAgIEluIG90aGVy IHdvcmRzLCB3ZSB0YWtlIHdoYXQgd2UgaGF2ZSBub3cgKHdoaWNoDQogICAgICAgICAgICAgICAg ICAgIHdvcmtzIGZvciBhIG5vbi1pbnRlcm5hdGlvbmFsaXplZCBjYXNlIHdoZXJlDQogICAgICAg ICAgICAgICAgICAgIGV2ZXJ5b25lIGp1c3QgYXNzdW1lcyBhIGNvbW1vbiBsYW5ndWFnZS9zY3Jp cHQpLCBhbmQNCiAgICAgICAgICAgICAgICAgICAgd2UgYXVnbWVudCBpdCB3aXRoIGZlYXR1cmVz IHRoYXQgbGV0IGl0IGJlIHNtYXJ0ZXINCiAgICAgICAgICAgICAgICAgICAgaWYgeW91IHdhbnQg aXQgdG8gYmUgc21hcnRlci4gTWFrZSB0aGUgc2ltcGxlIGNhc2UNCiAgICAgICAgICAgICAgICAg ICAgc2ltcGxlLCBtYWtlIHRoZSBjb21wbGljYXRlZCBjYXNlIHBvc3NpYmxlLjxicj4NCiAgICAg ICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICAgICAgICAmbmJzcDstLSBKdXN0aW48 YnI+DQogICAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICAgICAgJm5ic3A7 PHU+PC91Pjx1PjwvdT48L3A+DQogICAgICAgICAgICAgICAgICA8ZGl2Pg0KICAgICAgICAgICAg ICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAwMy8xNC8yMDEzIDEwOjQ3IEFNLCBHZW9y Z2UNCiAgICAgICAgICAgICAgICAgICAgICBGbGV0Y2hlciB3cm90ZTo8dT48L3U+PHU+PC91Pjwv cD4NCiAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQogICAgICAg ICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5BcyBhDQogICAgICAgICAgICAgICAgICAgICAgICBzaW1wbGlm eWluZyBvcHRpb24uLi4gd2h5IG5vdCBqdXN0IHJlcXVpcmUNCiAgICAgICAgICAgICAgICAgICAg ICAgIGh1bWFuLXJlYWRhYmxlIGZpZWxkcyB0byByZXF1aXJlIGEgJnF1b3Q7c2NyaXB0LXRhZyZx dW90Oy4NCiAgICAgICAgICAgICAgICAgICAgICAgIFRoaXMgd2F5IGl0IGlzIGFsd2F5cyBleHBs aWNpdCB3aGF0DQogICAgICAgICAgICAgICAgICAgICAgICBsYW5ndWFnZS9sb2NhbGUgdGhlIHRl eHQgaXMgZm9yLiBJdCB0aGVuIGJlY29tZXMNCiAgICAgICAgICAgICAgICAgICAgICAgIHRoZSBy ZXNwb25zaWJpbGl0eSBvZiB0aGUgQVMgdG8gcmV0dXJuIGFuDQogICAgICAgICAgICAgICAgICAg ICAgICBhcHByb3ByaWF0ZSByZXNwb25zZSBpZiB0aGVyZSBpcyBub3QgYSBkaXJlY3QNCiAgICAg ICAgICAgICAgICAgICAgICAgIG1hdGNoIGJldHdlZW4gYSByZXF1ZXN0IGFuZCB0aGUgZGF0YSBz dG9yZWQgYXQNCiAgICAgICAgICAgICAgICAgICAgICAgIHRoZSBBUyAoYW5kIG91dCBvZiBzY29w ZSBvZiB0aGUgc3BlYykuPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgPGJyPg0KICAgICAg ICAgICAgICAgICAgICAgICAgVGhhbmtzLDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgIEdl b3JnZTwvc3Bhbj48dT48L3U+PHU+PC91PjwvcD4NCiAgICAgICAgICAgICAgICAgICAgPGRpdj4N CiAgICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAzLzEzLzEzIDEw OjIyIEFNLCBKdXN0aW4NCiAgICAgICAgICAgICAgICAgICAgICAgIFJpY2hlciB3cm90ZTo8dT48 L3U+PHU+PC91PjwvcD4NCiAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAg ICAgICAgIDxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KICAgICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+U28NCg0KICAgICAgICAgICAgICAgICAgICAgICAgd2l0 aCB3aGF0IGxpdHRsZSBmZWVkYmFjayBJJiMzOTt2ZSBnb3R0ZW4sIEkmIzM5O20NCiAgICAgICAg ICAgICAgICAgICAgICAgIHByb3Bvc2luZyB0byBhZGQgdGV4dCBmcm9tIHRoZSBwcm9wb3NlZA0K ICAgICAgICAgICAgICAgICAgICAgICAgd2ViZmluZ2VyIGFuZCBPSURDIGRyYWZ0cyBmb3IgdGhl IGhhc2gtYmFzZWQNCiAgICAgICAgICAgICAgICAgICAgICAgIGxvY2FsaXphdGlvbiBvZiBzdHJp bmdzLCB3aXRoIHRoZSBmb2xsb3dpbmcNCiAgICAgICAgICAgICAgICAgICAgICAgIHByb3BlcnRp ZXM6PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICAgICAg ICAgICAgKiBBbGwgbG9jYWxpemVkIHZlcnNpb25zIG9mIGZpZWxkcyBhcmUgZnVsbHkNCiAgICAg ICAgICAgICAgICAgICAgICAgIG9wdGlvbmFsIG9uIGJvdGggY2xpZW50IGFuZCBzZXJ2ZXI8YnI+ DQogICAgICAgICAgICAgICAgICAgICAgICAqIElmIGEgbG9jYWxpemVkIHZlcnNpb24gb2YgYSBm aWVsZCBpcyBpbmNsdWRlZCwNCiAgICAgICAgICAgICAgICAgICAgICAgIGl0cyBiYXJlLXZhbHVl IChwZXJoYXBzIGludGVybmF0aW9uYWxpemVkKSBmaWVsZA0KICAgICAgICAgICAgICAgICAgICAg ICAgTVVTVCBiZSBpbmNsdWRlZDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICogQWxsIGh1 bWFuLXJlYWRhYmxlIGZpZWxkcyBhcmUgZWxpZ2libGUgZm9yDQogICAgICAgICAgICAgICAgICAg ICAgICB0aGlzIG1lY2hhbmlzbSAoaW5jbHVkaW5nIGFueSB1cmkmIzM5O3MgZm9yDQogICAgICAg ICAgICAgICAgICAgICAgICB1c2VyLWZhY2luZyB3ZWIgcGFnZXMsIHdoaWNoIGNhbiBiZSB1c2Vk IHRvDQogICAgICAgICAgICAgICAgICAgICAgICBwb2ludCB0byBsYW5ndWFnZS1zcGVjaWZpYyBw YWdlcyk8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAqIENsaWVudHMgYW5kIHNlcnZlcnMg Y2FuIGRlY2lkZSB0byB1c2Ugd2hhdGV2ZXINCiAgICAgICAgICAgICAgICAgICAgICAgIGxhbmd1 YWdlL3NjcmlwdCB0aGV5IHdhbnQgdG8gZm9yIHRoZSBiYXJlLXZhbHVlDQogICAgICAgICAgICAg ICAgICAgICAgICBmaWVsZCwgYW5kIG5vIGFzc3VtcHRpb25zIGNhbiBiZSBtYWRlIG9uIGVpdGhl cg0KICAgICAgICAgICAgICAgICAgICAgICAgc2lkZSBhYm91dCB3aGF0IHRoYXQgaXM8YnI+DQog ICAgICAgICAgICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICBJIHRo aW5rIHRoYXQgd2l0aCB0aGVzZSBjb25zdHJhaW50cywgd2UgY2FuIGFkZA0KICAgICAgICAgICAg ICAgICAgICAgICAgZnVuY3Rpb25hbGl0eSB0byBhZGRyZXNzIFN0ZXBoZW4mIzM5O3MgY29uY2Vy bnMNCiAgICAgICAgICAgICAgICAgICAgICAgIHdpdGhvdXQgZ2V0dGluZyB0b28gY29tcGxpY2F0 ZWQgb3IgcHV0dGluZyB0b28NCiAgICAgICAgICAgICAgICAgICAgICAgIG11Y2ggYnVyZGVuIG9m IHN1cHBvcnQuPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAg ICAgICAgICAgICAgJm5ic3A7LS0gSnVzdGluPHU+PC91Pjx1PjwvdT48L3A+DQogICAgICAgICAg ICAgICAgICAgICAgPGRpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29O b3JtYWwiPk9uIDAzLzExLzIwMTMgMDY6NTIgUE0sIE5hdA0KICAgICAgICAgICAgICAgICAgICAg ICAgICBTYWtpbXVyYSB3cm90ZTo8dT48L3U+PHU+PC91PjwvcD4NCiAgICAgICAgICAgICAgICAg ICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICA8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCiAgICAgICAgICAgICAgICAgICAg ICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPlNpbWlsYXIgd29yayBpcyBpbiBwcm9ncmVzcw0KICAg ICAgICAgICAgICAgICAgICAgICAgICBhdCBXZWJmaW5nZXIuJm5ic3A7IDx1PjwvdT48dT48L3U+ PC9wPg0KICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj4NCiAgICAgICAgICAgICAgICAgICAg ICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PHU+PC91Pjx1PjwvdT48L3A+DQogICAg ICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+ DQogICAgICAgICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPlNlZTombmJz cDs8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvd2ViZmluZ2Vy L2N1cnJlbnQvbXNnMDA1MzAuaHRtbCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93d3cuaWV0Zi5v cmcvbWFpbC1hcmNoaXZlL3dlYi93ZWJmaW5nZXIvY3VycmVudC9tc2cwMDUzMC5odG1sPC9hPjx1 PjwvdT48dT48L3U+PC9wPg0KDQoNCiAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAg ICAgICAgICAgICAgICAgICAgICAgPGRpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PHU+PC91Pjx1PjwvdT48L3A+DQogICAgICAgICAgICAg ICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+DQogICAgICAg ICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdCI+UGF1bCBpcw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIHByb3Bvc2lu ZyB0aGUgc2FtZSBzeW50YXggYXMgQ29ubmVjdC4mbmJzcDs8dT48L3U+PHU+PC91PjwvcD4NCiAg ICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICA8cCBjbGFzcz0iTXNvTm9ybWFsIj4yMDEzLzMvMTIgUmljaGVyLA0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgSnVzdGluIFAuICZsdDs8YSBocmVmPSJtYWlsdG86anJpY2hlckBtaXRy ZS5vcmciIHRhcmdldD0iX2JsYW5rIj5qcmljaGVyQG1pdHJlLm9yZzwvYT4mZ3Q7PHU+PC91Pjx1 PjwvdT48L3A+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj4NCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IGRvZXMgcHJlc3VtZSBh DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGRlZmluaXRpb24gb2YgJnF1b3Q7Y2xh aW0mcXVvdDssIHdoaWNoIEkgc3VwcG9zZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB3ZSBjb3VsZCB0dXJuIHRvICZxdW90O21ldGFkYXRhIGZpZWxkJnF1b3Q7IGZvcg0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBEeW5SZWcgYW5kIGl0cyBleHRlbnNpb25zIHRvIGJl DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFwcHJvcHJpYXRlbHkgbGltaXRpbmcu IEJ1dCB3ZSBhbHNvIG5lZWQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYSBnb29k IGRlZmluaXRpb24gb2Ygd2hhdCBhDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGxh bmd1YWdlLXRhZy1sZXNzIGZpZWxkIG1lYW5zLCBhbmQNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgd2hldGhlciBvciBub3QgaXQmIzM5O3MgcmVxdWlyZWQgaWYgdGhlDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIG90aGVyIGZpZWxkcyBhcmUgcHJlc2VudCBvciBub3Qg KHdoaWNoDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGlzIHNvbWV0aGluZyB0aGF0 IENvbm5lY3QgaXMgdHJ5aW5nIHRvDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGZp eCBhdCB0aGUgbW9tZW50LCBhcyBJIHJlY2FsbCBmcm9tIGxhc3QNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgd2VlaykuJm5ic3A7IDx1PjwvdT48dT48L3U+PC9wPg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgPGRpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PHU+PC91Pjx1PjwvdT48L3A+DQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIDxkaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29O b3JtYWwiPlNvIGl0IHR1cm5zIGludG8NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBhYm91dCBhIHBhcmFncmFwaCB3b3J0aCBvZiB0ZXh0LiBJcw0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHRoYXQgd29ydGggaXQ/IEkmIzM5O20gbm90IGVudGlyZWx5DQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29udmluY2VkIHRoYXQgaXQgaXMsIGJ1dCBJ JiMzOTttDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaW50ZXJlc3RlZCB0byBo ZWFyIHdoYXQgb3RoZXJzIHRoaW5rLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHBhcnRpY3VsYXJseSB0aG9zZSB3aG8gKmFyZW4mIzM5O3QqIHRpZWQNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBpbnRvIHRoZSBPcGVuSUQgQ29ubmVjdCBwcm90b2NvbCBzbw0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG11Y2guIChJIGRvbiYjMzk7dCB3YW50 IHRvIHBpY2sgYSBzb2x1dGlvbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGp1 c3QgYmVjYXVzZSBpdCYjMzk7cyBmYW1pbGlhciwgaWYgd2UgbmVlZA0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIGEgc29sdXRpb24gYXQgYWxsLik8dT48L3U+PHU+PC91PjwvcD4N CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj4NCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8dT48L3U+PHU+PC91 PjwvcD4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIDxkaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7LS0gSnVzdGluPHU+PC91Pjx1PjwvdT48 L3A+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICA8ZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzx1PjwvdT48dT48L3U+PC9wPg0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+DQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICA8ZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICA8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNYXIgMTEsDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgMjAxMywgYXQgNjozNSBQTSwgQnJpYW4gQ2FtcGJlbGwNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJj YW1wYmVsbEBwaW5naWRlbnRpdHkuY29tIiB0YXJnZXQ9Il9ibGFuayI+YmNhbXBiZWxsQHBpbmdp ZGVudGl0eS5jb208L2E+Jmd0Ozx1PjwvdT48dT48L3U+PC9wPg0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICA8ZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2Pg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+DQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDt3cm90ZTo8dT48L3U+PHU+PC91PjwvcD4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICA8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjx1Pjwv dT4mbmJzcDs8dT48L3U+PC9wPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIDxkaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8cCBj bGFzcz0iTXNvTm9ybWFsIj5BIGZhaXINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgcXVlc3Rpb24gYnV0IHdoYXQgd291bGQgbmVlZA0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0byBiZSBwdWxsZWQgaW4gaXMgcmVhbGx5DQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHByb2JhYmx5IG9ubHkg YSBjb3VwbGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc2Vu dGVuY2VzIChhbmQgcmVmZXJlbmNlKQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBmcm9tIDxhIGhyZWY9Imh0dHA6Ly9vcGVuaWQubmV0L3NwZWNzL29wZW5pZC1j b25uZWN0LW1lc3NhZ2VzLTFfMC0xNi5odG1sI0NsYWltc0xhbmd1YWdlc0FuZFNjcmlwdHMiIHRh cmdldD0iX2JsYW5rIj4NCmh0dHA6Ly9vcGVuaWQubmV0L3NwZWNzL29wZW5pZC1jb25uZWN0LW1l c3NhZ2VzLTFfMC0xNi5odG1sI0NsYWltc0xhbmd1YWdlc0FuZFNjcmlwdHM8L2E+DQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChub3RlIHRoZSByZWZlcmVuY2Ug dG8NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMi4xLjEuMS4z IGluc2lkZSA8YSBocmVmPSJodHRwOi8vb3BlbmlkLm5ldC9zcGVjcy9vcGVuaWQtY29ubmVjdC1y ZWdpc3RyYXRpb24tMV8wLTE1Lmh0bWwiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6Ly9vcGVuaWQu bmV0L3NwZWNzL29wZW5pZC1jb25uZWN0LXJlZ2lzdHJhdGlvbi0xXzAtMTUuaHRtbDwvYT4gaXMN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYnJva2VuKTx1Pjwv dT48dT48L3U+PC9wPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwv ZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+DQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPiZuYnNwOzx1PjwvdT48dT48L3U+PC9wPg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj4NCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+ T24gTW9uLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE1h ciAxMSwgMjAxMyBhdCA2OjI2IFBNLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIFJpY2hlciwgSnVzdGluIFAuICZsdDs8YSBocmVmPSJtYWlsdG86anJpY2hl ckBtaXRyZS5vcmciIHRhcmdldD0iX2JsYW5rIj5qcmljaGVyQG1pdHJlLm9yZzwvYT4mZ3Q7DQoN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB3cm90ZTo8dT48 L3U+PHU+PC91PjwvcD4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgPGRpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8 cCBjbGFzcz0iTXNvTm9ybWFsIj5NeQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgY29uY2VybiB3aXRoIHRoaXMgaXMNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRoYXQgT0lEQyBjYW4gZ2V0IGF3YXkNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHdpdGggZGVmaW5pbmcg dGhpcw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbXVs dGktbGFuZ3VhZ2Ugc3RydWN0dXJlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBiZWNhdXNlIGl0IGRlZmluZXMgdGhlDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBtZWNoYW5pc20gb25jZSAoaW4NCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE1lc3NhZ2VzKSBhbmQgYXBw bGllcyBpdA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg dG8gYWxsIHVzZXItcmVhZGFibGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHN0cmluZ3MgdGhyb3VnaG91dCB0aGUNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHdob2xlIGFwcGxpY2F0aW9uDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBwcm90b2NvbCwgb2Ygd2hpY2gg dGhlcmUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFy ZSBzZXZlcmFsLiBEbyB3ZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgcmVhbGx5IHdhbnQgdG8gcHVsbCBpbg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgdGhhdCB3aG9sZSBzdHJ1Y3R1cmUgYW5kDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBtZWNoYW5pc20gZm9yIG9u ZSBmaWVsZA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg aW4gY2xpZW50IHJlZ2lzdHJhdGlvbj8NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIEkgcmVhbGx5IGRvbiYjMzk7dCB0aGluayBpdA0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc2hvdWxkIGJlIHNvbWV0aGluZw0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhhdCYjMzk7 cyBkZWZpbmVkDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBjb21wbGV0ZWx5IGluc2lkZSBvZg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgRHluUmVnIGZvciBhIGNvcm5lciBjYXNlDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBmb3IgYSBzaW5nbGUgZmllbGQsIGJ1dA0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSSBhbHNvIGRv dWJ0IHdlIHdhbnQgdG8NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIG5vcm1hdGl2ZWx5IHBvaW50IHRvDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBPSURDIE1lc3NhZ2VzIGZvciB0aGlzDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzb2x1dGlvbiBlaXRoZXIuIDx1Pjwv dT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDx1Pjwv dT48L3A+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRp dj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzx1PjwvdT48dT48L3U+PC9wPg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+DQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGVyZQ0KDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFyZSBhbHNv IG90aGVyIHdheXMgdG8NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgZG8gdGhpczogV2ViZmluZ2VyIFsxXQ0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBmb3IgaW5zdGFuY2UgdXNlcyBKU09ODQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0cnVjdHVyZXMgdG8g Z2l2ZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBs YW5ndWFnZSB0YWdzIHRvIGZpZWxkDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHZhbHVlcywgYW5kIGhhcyBhDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGRlZmF1bHQgbWVjaGFuaXNtOjx1PjwvdT48dT48 L3U+PC9wPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwv ZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+ DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8dT48L3U+PHU+PC91PjwvcD4NCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7DQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZuYnNwO3sgJnF1 b3Q7ZW5fdXMmcXVvdDs6ICZxdW90O215DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIGNsaWVudCZxdW90OywgPHNwYW4gbGFuZz0iSkEiPiZoZWxsaXA7 PC9zcGFuPiB9PHU+PC91Pjx1PjwvdT48L3A+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgPGRpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzx1PjwvdT48dT48L3U+PC9w Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+DQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNv Tm9ybWFsIj5UaGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgZnVuZGFtZW50YWwgcXVlc3Rpb24NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgaXMgJm5ic3A7dGhpczogc2hvdWxkIGENCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY2xpZW50IGJlIGFibGUgdG8N CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcmVnaXN0 ZXIgbXVsdGlwbGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgbmFtZXMgKGluIGRpZmZlcmVudA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBsb2NhbGVzKSB3aXRoIGEgc2luZ2xlDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNsaWVudF9pZCwgb3Igc2hvdWxk DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGl0IGdl dCBhIGRpZmZlcmVudA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBjbGllbnRfaWQgZm9yIGVhY2gNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgZGlzcGxheSBsYW5ndWFnZSBzZXQ/PHU+PC91Pjx1PjwvdT48 L3A+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2 Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8dT48L3U+PHU+PC91PjwvcD4NCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj4NCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7LS0NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIEp1c3Rpbjx1PjwvdT48dT48L3U+PC9wPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICA8ZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8dT48L3U+PHU+ PC91PjwvcD4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg PGRpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg PHAgY2xhc3M9Ik1zb05vcm1hbCI+WzFdJm5ic3A7PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaWV0Zi1hcHBzYXdnLXdlYmZpbmdlci0xMSIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYXBwc2F3Zy13ZWJmaW5nZXIt MTE8L2E+PHU+PC91Pjx1PjwvdT48L3A+DQoNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICA8ZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8dT48L3U+PHU+ PC91PjwvcD4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgPGRpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICA8ZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24NCg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBNYXIgMTEsIDIwMTMsIGF0DQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDU6NTQg UE0sIEpvaG4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgQnJhZGxleSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tIiB0 YXJnZXQ9Il9ibGFuayI+dmU3anRiQHZlN2p0Yi5jb208L2E+Jmd0Ozx1PjwvdT48dT48L3U+PC9w Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwv ZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IDxkaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDt3cm90ZTo8dT48L3U+PHU+PC91PjwvcD4N CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Rp dj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8 ZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgPGRpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 Ij48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj4NCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj5U aGF0DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBpcyB3aGF0IEkgd2FzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgdGhpbmtpbmcuICZuYnNwOyBJdA0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHdvdWxkIGJlIHVw IHRvDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgdGhlIEFTIHRvDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgZGV0ZXJtaW5lIHdoYXQNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBsYW5ndWFnZSBhbmQNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzY3JpcHQg dG8NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBwcmVzZW50IGJhc2VkDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgb24gdGhlIHVzZXINCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBwcmVmZXJlbmNlLiA8dT48L3U+PHU+ PC91PjwvcD4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICA8ZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzx1PjwvdT48dT48 L3U+PC9wPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIDxkaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hpbGUNCg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IGEgbGFyZ2UgbnVtYmVyDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgb2YgY2xpZW50cw0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHdpbGwgYmUgbmF0aXZlDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYW5kIG1pZ2h0 IGJlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgYWJsZSB0bw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIGN1c3RvbWl6ZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRoZW1zZWx2ZXMgZm9yDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYSBzaW5nbGUgdXNl cg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIGR1cmluZw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHJlZ2lzdHJhdGlvbiAsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgd2UgZG9uJiMzOTt0IHdhbnQNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0byBmb3Jn ZXQgdGhlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgd2ViIHNlcnZlcg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIGNsaWVudHMgdGhhdA0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFyZSBtdWx0aQ0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVzZXIuPHU+ PC91Pjx1PjwvdT48L3A+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj4NCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8dT48L3U+PHU+PC91PjwvcD4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+DQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05v cm1hbCI+T24NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIDIwMTMtMDMtMTEsIGF0DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMTA6NDkgUE0sDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQnJpYW4gQ2FtcGJlbGwN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tIiB0YXJnZXQ9 Il9ibGFuayI+YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208L2E+Jmd0Ow0KDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgd3JvdGU6PHU+ PC91Pjx1PjwvdT48L3A+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD4NCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2Pg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxw IGNsYXNzPSJNc29Ob3JtYWwiPkZXSVcsDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0aGUgY2xvc2VseQ0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJlbGF0ZWQgT3BlbklE DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgQ29ubmVjdCBjbGllbnQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICByZWdpc3RyYXRpb24NCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBkcmFmdCBkb2VzDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaGF2ZSBzb21l DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgc3VwcG9ydCBmb3INCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBkb2luZyB0aGlzLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHdoaWNoIGNvdWxkDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbWF5YmUgYmUNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBi b3Jyb3dlZC4gU2VlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgY2xpZW50X25hbWUgaW4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8c3BhbiBsYW5nPSJKQSI+GyRCIXgbKEI8 L3NwYW4+Mg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIGF0IDxhIGhyZWY9Imh0dHA6Ly9vcGVuaWQubmV0L3NwZWNzL29wZW5pZC1jb25u ZWN0LXJlZ2lzdHJhdGlvbi0xXzAtMTUuaHRtbCNjbGllbnQtbWV0YWRhdGEiIHRhcmdldD0iX2Js YW5rIj4NCmh0dHA6Ly9vcGVuaWQubmV0L3NwZWNzL29wZW5pZC1jb25uZWN0LXJlZ2lzdHJhdGlv bi0xXzAtMTUuaHRtbCNjbGllbnQtbWV0YWRhdGE8L2E+DQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYW5kIHRoZQ0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGV4YW1wbGVzLjxi cj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAmbmJzcDs8dT48L3U+PHU+PC91PjwvcD4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8cHJlPiZuYnNwOyZuYnNwOyAmcXVvdDtj bGllbnRfbmFtZSZxdW90OzogJnF1b3Q7TXkgRXhhbXBsZSZxdW90Oyw8dT48L3U+PHU+PC91Pjwv cHJlPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIDxwcmU+Jm5ic3A7Jm5ic3A7ICZxdW90O2NsaWVudF9uYW1lI2phLUpwYW4tSlAmcXVv dDs6JnF1b3Q7PHNwYW4gbGFuZz0iSkEiPhskQiUvJWklJCUiJXMlSEw+GyhCPC9zcGFuPiZxdW90 Oyw8dT48L3U+PHU+PC91PjwvcHJlPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzx1Pjwv dT48dT48L3U+PC9wPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij4mbmJzcDs8dT48L3U+PHU+PC91PjwvcD4NCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2 Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBNb24sIE1hciAxMSwNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAyMDEzIGF0IDU6 MTUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBQTSwgUmljaGVyLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIEp1c3RpbiBQLiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJA bWl0cmUub3JnIiB0YXJnZXQ9Il9ibGFuayI+anJpY2hlckBtaXRyZS5vcmc8L2E+Jmd0Ow0KDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg d3JvdGU6PHU+PC91Pjx1PjwvdT48L3A+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQNCg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHdh cyBicm91Z2h0IHVwDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgYXQgdGhlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgaW4tcGVyc29uDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbWVldGluZyB0b2RheQ0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRoYXQg d2UmIzM5O2xsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgd2FudCB0bw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIGNvbnNpZGVyDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaXNzdWVzIGFyb3VuZA0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGludGVybmF0 aW9uYWxpemF0aW9uDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBhbmQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBsb2NhbGl6YXRpb24NCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBvZg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGh1bWFuLXJlYWRhYmxl DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgZmllbGRzIGxpa2UNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBjbGllbnRfbmFtZSBpbg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRoZSBjbGllbnQNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICByZWdpc3RyYXRp b24uDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgV2hpY2ggaXMgdG8NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBzYXk6IGlmIGENCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjbGllbnQNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdXBwb3J0cyB0ZW4NCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBs YW5ndWFnZXMgYW5kDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgd2FudHMgdG8NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBwcmVzZW50IGl0c2VsZg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGluIHRlbg0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGxhbmd1 YWdlcywNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBzaG91bGQgaXQgaGF2ZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHRvIHJlZ2lzdGVyDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaXRzZWxmIHRlbg0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRpbWVz IHdpdGggYW4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBBUz88YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIEF0IHRoZSBtb21lbnQsDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSSYjMzk7bSBvZiB0 aGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBvcGluaW9uIGENCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBjbGllbnQgd2l0aA0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRlbiBsYW5ndWFnZXMNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb3VsZCByZWdp c3Rlcg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIGl0c2VsZiB0ZW4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB0aW1lcywgb3IgZG8NCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzb21ldGhpbmcgd2l0aA0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRoZSBj b250ZXh0IGluDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgd2hpY2ggaXQgcnVucw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRvIGRldGVybWluZQ0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHdoaWNoDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaHVtYW4t ZmFjaW5nDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgbGFuZ3VhZ2UgdG8NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB1c2UuIEtlZXAgaW4NCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBtaW5kIHRoYXQgaW4NCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzb21l IGNhc2VzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgKHN1Y2ggYXMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBuYXRpdmUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjbGllbnRzKSwNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB5b3UmIzM5O2xsIGJlDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ZHluYW1pY2FsbHkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICByZWdpc3RlcmluZyBhDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY2xpZW50IGZvcg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGVhY2ggdXNlciwgaW4N CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBlZmZlY3QuIEluDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgb3RoZXIgd29yZHMsIEkNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBwZXJzb25hbGx5DQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhpbmsgdGhhdA0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHRoaXMgaXMgYQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHJhdGhvbGUgdGhhdA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHdpbGwgY2F1c2UNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBtb3JlIGhhcm0gdGhhbg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IGdvb2QuPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAmbmJzcDstLSBKdXN0aW48YnI+DQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBPQXV0aCBtYWlsaW5nDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbGlz dDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICA8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5P QXV0aEBpZXRmLm9yZzwvYT48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PHU+PC91Pjx1PjwvdT48L3A+DQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PHU+PC91Pjx1PjwvdT48L3A+DQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg PHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgT0F1dGggbWFpbGluZw0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGxpc3Q8YnI+DQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGEgaHJlZj0ibWFp bHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJy Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgi IHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h dXRoPC9hPjx1PjwvdT48dT48L3U+PC9wPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzx1PjwvdT48dT48L3U+PC9wPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PHU+PC91Pjx1PjwvdT48L3A+DQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzx1PjwvdT48dT48L3U+PC9wPg0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2 Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzx1PjwvdT48dT48L3U+PC9wPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICA8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h dXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9vYXV0aDwvYT48dT48L3U+PHU+PC91PjwvcD4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg PC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi cj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICA8YnIgY2xlYXI9ImFsbCI+DQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgPHU+PC91Pjx1PjwvdT48L3A+DQogICAgICAgICAgICAgICAg ICAgICAgICAgIDxkaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PHU+PC91Pjx1PjwvdT48L3A+DQogICAgICAgICAgICAgICAgICAgICAg ICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFs Ij4tLSA8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgTmF0IFNha2ltdXJhICg9bmF0 KSA8dT48L3U+PHU+PC91PjwvcD4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj4NCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj5DaGFpcm1hbiwg T3BlbklEDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBGb3VuZGF0aW9uPGJyPg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgPGEgaHJlZj0iaHR0cDovL25hdC5zYWtpbXVyYS5v cmcvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL25hdC5zYWtpbXVyYS5vcmcvPC9hPjxicj4NCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIEBfbmF0X2VuPHU+PC91Pjx1PjwvdT48L3A+DQog ICAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAg PC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgPC9ibG9ja3F1b3RlPg0KICAgICAgICAgICAg ICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dCI+PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICAgICAg ICAgICAgPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgPHU+PC91Pjx1PjwvdT48L3A+DQog ICAgICAgICAgICAgICAgICAgICAgPHByZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzx1PjwvdT48dT48L3U+PC9wcmU+DQogICAgICAgICAgICAgICAgICAg ICAgPHByZT5PQXV0aCBtYWlsaW5nIGxpc3Q8dT48L3U+PHU+PC91PjwvcHJlPg0KICAgICAgICAg ICAgICAgICAgICAgIDxwcmU+PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PHU+PC91Pjx1PjwvdT48L3ByZT4NCiAgICAgICAg ICAgICAgICAgICAgICA8cHJlPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL29hdXRoPC9hPjx1PjwvdT48dT48L3U+PC9wcmU+DQogICAgICAgICAgICAg ICAgICAgIDwvYmxvY2txdW90ZT4NCiAgICAgICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PHU+PC91Pjx1PjwvdT48L3A+DQogICAgICAgICAgICAgICAgICA8L2Jsb2Nr cXVvdGU+DQogICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8dT48 L3U+PHU+PC91PjwvcD4NCiAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgPC9i bG9ja3F1b3RlPg0KICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48dT48L3U+Jm5i c3A7PHU+PC91PjwvcD4NCiAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgIDwvYmxvY2txdW90 ZT4NCiAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48dT48L3U+Jm5ic3A7PHU+PC91Pjwv cD4NCiAgICAgICAgPC9kaXY+DQogICAgICA8L2Jsb2NrcXVvdGU+DQogICAgICA8YnI+DQogICAg ICA8YnI+DQogICAgICA8ZmllbGRzZXQ+PC9maWVsZHNldD4NCiAgICAgIDxicj4NCiAgICAgIDxw cmU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRo IG1haWxpbmcgbGlzdA0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT4NCjwvcHJlPg0KICAgIDwvZGl2PjwvZGl2Pjwv YmxvY2txdW90ZT4NCiAgICA8YnI+DQogIDwvZGl2Pg0KDQo8YnI+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+ DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBp ZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9vYXV0aDwvYT48YnI+DQo8YnI+PC9ibG9ja3F1b3RlPjwvZGl2Pjxicj48YnIg Y2xlYXI9ImFsbCI+PGRpdj48YnI+PC9kaXY+LS0gPGJyPk5hdCBTYWtpbXVyYSAoPW5hdCk8ZGl2 PkNoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbjxicj48YSBocmVmPSJodHRwOi8vbmF0LnNha2lt dXJhLm9yZy8iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vbmF0LnNha2ltdXJhLm9yZy88L2E+PGJy PkBfbmF0X2VuPC9kaXY+DQo8L2Rpdj4NCjwvZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48L2Rpdj48 YnI+PGJyIGNsZWFyPSJhbGwiPjxkaXY+PGJyPjwvZGl2Pi0tIDxicj5OYXQgU2FraW11cmEgKD1u YXQpPGRpdj5DaGFpcm1hbiwgT3BlbklEIEZvdW5kYXRpb248YnI+PGEgaHJlZj0iaHR0cDovL25h dC5zYWtpbXVyYS5vcmcvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL25hdC5zYWtpbXVyYS5vcmcv PC9hPjxicj5AX25hdF9lbjwvZGl2Pg0KDQo8L2Rpdj4NCg== --f46d042d051ce4dda804d878c1bf-- From James.H.Manger@team.telstra.com Thu Mar 21 18:43: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 439C221F8B51 for ; Thu, 21 Mar 2013 18:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.87 X-Spam-Level: X-Spam-Status: No, score=-1.87 tagged_above=-999 required=5 tests=[AWL=-0.970, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDgJRFIqDQ9D for ; Thu, 21 Mar 2013 18:43:34 -0700 (PDT) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by ietfa.amsl.com (Postfix) with ESMTP id B6BC621F8D8D for ; Thu, 21 Mar 2013 18:43:32 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,888,1355058000"; d="scan'208,217";a="125515452" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipocvi.tcif.telstra.com.au with ESMTP; 22 Mar 2013 12:43:30 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,7021"; a="172752655" Received: from wsmsg3754.srv.dir.telstra.com ([172.49.40.198]) by ipcavi.tcif.telstra.com.au with ESMTP; 22 Mar 2013 12:43:30 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3754.srv.dir.telstra.com ([172.49.40.198]) with mapi; Fri, 22 Mar 2013 12:43:29 +1100 From: "Manger, James H" To: Justin Richer , "oauth@ietf.org WG" Date: Fri, 22 Mar 2013 12:43:28 +1100 Thread-Topic: [OAUTH-WG] Registration: Internationalization of Human-Readable names Thread-Index: Ac4mYEWWmMiKs9sSRaOiFnTu42+D8AAPaQag Message-ID: <255B9BB34FB7D647A506DC292726F6E1150BD3FB27@WSMSG3153V.srv.dir.telstra.com> References: <1B4C0C9F-4B8E-4B2D-BAF7-665D3EBBE56C@ve7jtb.com> <51408B8B.9000800@mitre.org> <5141E2E6.9020701@aol.com> <5141E671.2050708@mitre.org> <4E1F6AAD24975D4BA5B16804296739436750F5E2@TK5EX14MBXC283.redmond.corp.microsoft.com>, <5149F092.7070902@mitre.org> <4E1F6AAD24975D4BA5B168042967394367565FEF@TK5EX14MBXC283.redmond.corp.microsoft.com> <5149F534.1040500@mitre.org> <4E1F6AAD24975D4BA5B168042967394367567185@TK5EX14MBXC283.redmond.corp.microsoft.com> <514B4E28.7000309@mitre.org> In-Reply-To: <514B4E28.7000309@mitre.org> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E1150BD3FB27WSMSG3153Vsrv_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readable names X-BeenThere: oauth@ietf.org X-Mailman-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, 22 Mar 2013 01:43:35 -0000 --_000_255B9BB34FB7D647A506DC292726F6E1150BD3FB27WSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2hhdCBpcyBhbiDigJxpbnRlcm5hdGlvbmFsaXplZCBVVEYtOCBzdHJpbmfigJ0/DQoNClAuUy4g SXQgd291bGQgYmUgd29ydGggZXhwbGljaXRseSBzdGF0aW5nIHRoYXQgdGhlICMgY2hhcmFjdGVy IGFuZCBSRkM1NjQ2IGxhbmd1YWdlIHRhZyBhcmUgYXBwZW5kZWQgKnRvIHRoZSBmaWVsZCBuYW1l KiAobm90IHRoZSB2YWx1ZSkuIEkgYXNzdW1lIHRoaXMgaXMgcmlnaHQuDQoNCi0tDQpKYW1lcyBN YW5nZXINCg0KRnJvbTogb2F1dGgtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm9hdXRoLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKdXN0aW4gUmljaGVyDQpTZW50OiBGcmlkYXksIDIy IE1hcmNoIDIwMTMgNToxNSBBTQ0KVG86IG9hdXRoQGlldGYub3JnIFdHDQpTdWJqZWN0OiBSZTog W09BVVRILVdHXSBSZWdpc3RyYXRpb246IEludGVybmF0aW9uYWxpemF0aW9uIG9mIEh1bWFuLVJl YWRhYmxlIG5hbWVzDQoNCldlIGRpc2N1c3NlZCB0aGlzIGlzc3VlIG9uIHRoZSBPcGVuSUQgQ29u bmVjdCBXRyBjYWxsIHRoaXMgbW9ybmluZywgaW4gYSBjb252ZXJzYXRpb24gdGhhdCBpbmNsdWRl ZCBteXNlbGYsIEdlb3JnZSBGbGV0Y2hlciwgTmF0IFNha2ltdXJhLCBNaWtlIEpvbmVzLCBhbmQg Sm9obiBCcmFkbGV5IChhbW9uZyBvdGhlcnMpIGFzIGFjdGl2ZSBwYXJ0aWNpcGFudHMgaW4gdGhp cyB0aHJlYWQuIEFmdGVyIGxvdHMgb2YgZGViYXRlLCB3ZSBwcm9wb3NlIHRoYXQgdGhlIE9BdXRo IER5blJlZyBhZG9wdCB0aGUgaGFzaHRhZy1iYXNlZCBsb2NhbGl6YXRpb24gbWV0aG9kIG9mIE9J REMgKGFuZCBpdCBzZWVtcywgcG9zc2libHkgd2ViZmluZ2VyKSBhbmQgZXhwbGljaXRseSBkZWNs YXJlIHRoYXQgbmVpdGhlciB0aGUgY2xpZW50IG5vciB0aGUgc2VydmVyIG1ha2UgYW55IGFzc3Vt cHRpb25zIGFib3V0IHRoZSBjb250ZW50IG9mIHRoZSBzdHJpbmcgYW5kIHRyZWF0IGl0IGFzIGp1 c3QgYSBzdHJpbmcuIEknbSBwcm9wb3NpbmcgdGhpcyB0ZXh0IHRvIHRoYXQgZWZmZWN0ICh3aXRo IHRoZSByZWZlcmVuY2VzIHRvIE9JREMtbWVzc2FnZXMgcmVtb3ZlZCBhbmQgcmVwbGFjZWQgd2l0 aCB0aGUgcnVsZSBkZXNjcmlwdGlvbiBpdHNlbGYgaW4gT0F1dGggRHluUmVnKToNCkZpZWxkcyB3 aXRoIGh1bWFuLXJlYWRhYmxlIHZhbHVlcyBvciByZWZlcmVuY2VzIHRvIGh1bWFuLXJlYWRhYmxl IHZhbHVlcywgc3VjaCBhcyBjbGllbnRfbmFtZSwgdG9zX3VyaSwgcG9saWN5X3VyaSwgYW5kIGNs aWVudF91cmksIE1BWSBiZSByZXByZXNlbnRlZCBpbiBtdWx0aXBsZSBsYW5ndWFnZXMgYW5kIHNj cmlwdHMsIHNwZWNpZmllZCBieSBhcHBlbmRpbmcgYSAjIGNoYXJhY3RlciBhbmQgdGhlIFJGQzU2 NDYgbGFuZ3VhZ2UgdGFnLiBJZiBhbnkgc3VjaCBodW1hbi1yZWFkYWJsZSBmaWVsZCBpcyBzZW50 IHdpdGhvdXQgYSBsYW5ndWFnZSB0YWcsIHRoZSBzZXJ2ZXIgYW5kIHRoZSBjbGllbnQgTVVTVCBO T1QgbWFrZSBhbnkgYXNzdW1wdGlvbnMgYWJvdXQgdGhlIGxhbmd1YWdlLCBjaGFyYWN0ZXIgc2V0 LCBvciBzY3JpcHQgb2YgdGhlIHZhbHVlIHN0cmluZywgYW5kIHRoZSB2YWx1ZSBzdHJpbmcgTVVT VCBiZSB1c2VkIGFzLWlzIHdoZXJldmVyIGl0IGlzIHByZXNlbnRlZCBpbiBlaXRoZXIgdGhlIGNs aWVudCBvciBzZXJ2ZXIgVUkuIFRvIGZhY2lsaXRhdGUgaW50ZXJvcGVyYWJpbGl0eSwgaXQgaXMg UkVDT01NRU5ERUQgdGhhdCBhbnkgZmllbGRzIHNlbnQgd2l0aG91dCBsYW5ndWFnZSB0YWdzIGNv bnRhaW4gYW4gaW50ZXJuYXRpb25hbGl6ZWQgVVRGLTggc3RyaW5nIHN1aXRhYmxlIGZvciBkaXNw bGF5IG9uIGEgd2lkZSB2YXJpZXR5IG9mIHN5c3RlbXMsIGFuZCBpdCBpcyBSRUNPTU1FTkRFRCB0 aGF0IGNsaWVudHMgc2VuZCBmaWVsZHMgd2l0aG91dCBsYW5ndWFnZSB0YWdzIGluIGFkZGl0aW9u IHRvIGFueSBtb3JlLXNwZWNpZmljYWxseSBkZW5vbWluYXRlZCB2YWx1ZXMuDQoNClBsdXMgc29t ZSBleGFtcGxlcy4NCg0KKEFueW9uZSB3aG9zZSBuYW1lIEkgdG9vayBpbiB2YWluLCBwbGVhc2Ug ZmVlbCBmcmVlIHRvIGNvcnJlY3QgbWUuKQ0KDQogLS0gSnVzdGluDQo= --_000_255B9BB34FB7D647A506DC292726F6E1150BD3FB27WSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Ik1TIEdvdGhpYyI7 DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIg NCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToy IDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFz Ow0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6Ik1TIFBHb3RoaWMiOw0KCXBhbm9zZS0xOjIgMTEgNiAwIDcgMiA1IDggMiA0O30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxATVMgR290aGljIjsNCglwYW5vc2UtMToyIDExIDYg OSA3IDIgNSA4IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1TIFBHb3RoaWMi Ow0KCXBhbm9zZS0xOjIgMTEgNiAwIDcgMiA1IDggMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow Y207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m YW1pbHk6Ik1TIFBHb3RoaWMiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjpibGFjazt9DQphOmxpbmss IHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVy bGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNt Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OiJNUyBHb3RoaWMiOw0KCWNvbG9yOmJsYWNrO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNl dGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21z by1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWls eTpDb25zb2xhczsNCgljb2xvcjpibGFjazt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28t c3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwi c2Fucy1zZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KcC5tc29jaHBkZWZhdWx0LCBsaS5tc29jaHBk ZWZhdWx0LCBkaXYubXNvY2hwZGVmYXVsdA0KCXttc28tc3R5bGUtbmFtZTptc29jaHBkZWZhdWx0 Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6Ik1TIFBHb3RoaWMiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjpibGFj azt9DQpzcGFuLmh0bWxwcmVmb3JtYXR0ZWRjaGFyMA0KCXttc28tc3R5bGUtbmFtZTpodG1scHJl Zm9ybWF0dGVkY2hhcjsNCglmb250LWZhbWlseTpDb25zb2xhczsNCgljb2xvcjpibGFjazt9DQpz cGFuLmVtYWlsc3R5bGUxOQ0KCXttc28tc3R5bGUtbmFtZTplbWFpbHN0eWxlMTk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1h aWxTdHlsZTI0DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyNQ0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIu MHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48 L2hlYWQ+PGJvZHkgYmdjb2xvcj13aGl0ZSBsYW5nPUVOLUFVIGxpbms9Ymx1ZSB2bGluaz1wdXJw bGU+PGRpdiBjbGFzcz1Xb3JkU2VjdGlvbjE+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s b3I6IzFGNDk3RCc+V2hhdCBpcyBhbiDigJxpbnRlcm5hdGlvbmFsaXplZCBVVEYtOCBzdHJpbmfi gJ0/PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y OiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjtjb2xvcjojMUY0OTdEJz5QLlMuIEl0IHdvdWxkIGJlIHdvcnRoIGV4cGxpY2l0bHkg c3RhdGluZyB0aGF0IHRoZSAjIGNoYXJhY3RlciBhbmQgUkZDNTY0NiBsYW5ndWFnZSB0YWcgYXJl IGFwcGVuZGVkICo8Yj50byB0aGUgZmllbGQgbmFtZTwvYj4qIChub3QgdGhlIHZhbHVlKS4gSSBh c3N1bWUgdGhpcyBpcyByaWdodC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+LS08bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SmFt ZXMgTWFuZ2VyPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2IHN0 eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNt IDBjbSAwY20gNC4wcHQnPjxkaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20nPjxwIGNsYXNzPU1z b05vcm1hbD48Yj48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjtjb2xvcjp3aW5kb3d0ZXh0Jz5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eToiVGFob21hIiwic2Fucy1zZXJpZiI7Y29sb3I6d2luZG93dGV4dCc+IG9hdXRoLWJvdW5jZXNA aWV0Zi5vcmcgW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSA8Yj5PbiBCZWhhbGYgT2Yg PC9iPkp1c3RpbiBSaWNoZXI8YnI+PGI+U2VudDo8L2I+IEZyaWRheSwgMjIgTWFyY2ggMjAxMyA1 OjE1IEFNPGJyPjxiPlRvOjwvYj4gb2F1dGhAaWV0Zi5vcmcgV0c8YnI+PGI+U3ViamVjdDo8L2I+ IFJlOiBbT0FVVEgtV0ddIFJlZ2lzdHJhdGlvbjogSW50ZXJuYXRpb25hbGl6YXRpb24gb2YgSHVt YW4tUmVhZGFibGUgbmFtZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAgY2xh c3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHls ZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPldlIGRpc2N1c3NlZCB0aGlzIGlzc3VlIG9uIHRoZSBP cGVuSUQgQ29ubmVjdCBXRyBjYWxsIHRoaXMgbW9ybmluZywgaW4gYSBjb252ZXJzYXRpb24gdGhh dCBpbmNsdWRlZCBteXNlbGYsIEdlb3JnZSBGbGV0Y2hlciwgTmF0IFNha2ltdXJhLCBNaWtlIEpv bmVzLCBhbmQgSm9obiBCcmFkbGV5IChhbW9uZyBvdGhlcnMpIGFzIGFjdGl2ZSBwYXJ0aWNpcGFu dHMgaW4gdGhpcyB0aHJlYWQuIEFmdGVyIGxvdHMgb2YgZGViYXRlLCB3ZSBwcm9wb3NlIHRoYXQg dGhlIE9BdXRoIER5blJlZyBhZG9wdCB0aGUgaGFzaHRhZy1iYXNlZCBsb2NhbGl6YXRpb24gbWV0 aG9kIG9mIE9JREMgKGFuZCBpdCBzZWVtcywgcG9zc2libHkgd2ViZmluZ2VyKSBhbmQgZXhwbGlj aXRseSBkZWNsYXJlIHRoYXQgbmVpdGhlciB0aGUgY2xpZW50IG5vciB0aGUgc2VydmVyIG1ha2Ug YW55IGFzc3VtcHRpb25zIGFib3V0IHRoZSBjb250ZW50IG9mIHRoZSBzdHJpbmcgYW5kIHRyZWF0 IGl0IGFzIGp1c3QgYSBzdHJpbmcuIEknbSBwcm9wb3NpbmcgdGhpcyB0ZXh0IHRvIHRoYXQgZWZm ZWN0ICh3aXRoIHRoZSByZWZlcmVuY2VzIHRvIE9JREMtbWVzc2FnZXMgcmVtb3ZlZCBhbmQgcmVw bGFjZWQgd2l0aCB0aGUgcnVsZSBkZXNjcmlwdGlvbiBpdHNlbGYgaW4gT0F1dGggRHluUmVnKTo8 bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+RmllbGRzIHdpdGggaHVtYW4tcmVhZGFi bGUgdmFsdWVzIG9yIHJlZmVyZW5jZXMgdG8gaHVtYW4tcmVhZGFibGUgdmFsdWVzLCBzdWNoIGFz IGNsaWVudF9uYW1lLCB0b3NfdXJpLCBwb2xpY3lfdXJpLCBhbmQgY2xpZW50X3VyaSwgTUFZIGJl IHJlcHJlc2VudGVkIGluIG11bHRpcGxlIGxhbmd1YWdlcyBhbmQgc2NyaXB0cywgc3BlY2lmaWVk IGJ5IGFwcGVuZGluZyBhICMgY2hhcmFjdGVyIGFuZCB0aGUgUkZDNTY0NiBsYW5ndWFnZSB0YWcu IElmIGFueSBzdWNoIGh1bWFuLXJlYWRhYmxlIGZpZWxkIGlzIHNlbnQgd2l0aG91dCBhIGxhbmd1 YWdlIHRhZywgdGhlIHNlcnZlciBhbmQgdGhlIGNsaWVudCBNVVNUIE5PVCBtYWtlIGFueSBhc3N1 bXB0aW9ucyBhYm91dCB0aGUgbGFuZ3VhZ2UsIGNoYXJhY3RlciBzZXQsIG9yIHNjcmlwdCBvZiB0 aGUgdmFsdWUgc3RyaW5nLCBhbmQgdGhlIHZhbHVlIHN0cmluZyBNVVNUIGJlIHVzZWQgYXMtaXMg d2hlcmV2ZXIgaXQgaXMgcHJlc2VudGVkIGluIGVpdGhlciB0aGUgY2xpZW50IG9yIHNlcnZlciBV SS4gVG8gZmFjaWxpdGF0ZSBpbnRlcm9wZXJhYmlsaXR5LCBpdCBpcyBSRUNPTU1FTkRFRCB0aGF0 IGFueSBmaWVsZHMgc2VudCB3aXRob3V0IGxhbmd1YWdlIHRhZ3MgY29udGFpbiBhbiBpbnRlcm5h dGlvbmFsaXplZCBVVEYtOCBzdHJpbmcgc3VpdGFibGUgZm9yIGRpc3BsYXkgb24gYSB3aWRlIHZh cmlldHkgb2Ygc3lzdGVtcywgYW5kIGl0IGlzIFJFQ09NTUVOREVEIHRoYXQgY2xpZW50cyBzZW5k IGZpZWxkcyB3aXRob3V0IGxhbmd1YWdlIHRhZ3MgaW4gYWRkaXRpb24gdG8gYW55IG1vcmUtc3Bl Y2lmaWNhbGx5IGRlbm9taW5hdGVkIHZhbHVlcy48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz48YnI+UGx1cyBzb21lIGV4YW1wbGVz Ljxicj48YnI+KEFueW9uZSB3aG9zZSBuYW1lIEkgdG9vayBpbiB2YWluLCBwbGVhc2UgZmVlbCBm cmVlIHRvIGNvcnJlY3QgbWUuKTxicj48YnI+Jm5ic3A7LS0gSnVzdGluPG86cD48L286cD48L3A+ PC9kaXY+PC9kaXY+PC9ib2R5PjwvaHRtbD4= --_000_255B9BB34FB7D647A506DC292726F6E1150BD3FB27WSMSG3153Vsrv_-- From markdoristyne@hotmail.com Fri Mar 22 13:35: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 D15D021F9425 for ; Fri, 22 Mar 2013 13:35:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.133 X-Spam-Level: **** X-Spam-Status: No, score=4.133 tagged_above=-999 required=5 tests=[AWL=1.132, BAYES_95=3, 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 DkGjvbIAQoNG for ; Fri, 22 Mar 2013 13:35:13 -0700 (PDT) Received: from snt0-omc4-s12.snt0.hotmail.com (snt0-omc4-s12.snt0.hotmail.com [65.55.90.215]) by ietfa.amsl.com (Postfix) with ESMTP id 3767E21F9423 for ; Fri, 22 Mar 2013 13:35:13 -0700 (PDT) Received: from SNT144-DS14 ([65.55.90.200]) by snt0-omc4-s12.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 22 Mar 2013 13:35:07 -0700 X-EIP: [/3hliErFE/5CJjamYzmOj0wV6a+y1j04] X-Originating-Email: [markdoristyne@hotmail.com] Message-ID: From: "dorismark tyne" To: Date: Fri, 22 Mar 2013 16:35:03 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0019_01CE271B.3406BC60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: MSN 9 X-MimeOLE: Produced By MSN MimeOLE V10.50.0008.2100 Seal-Send-Time: Fri, 22 Mar 2013 16:35:03 -0400 X-OriginalArrivalTime: 22 Mar 2013 20:35:07.0915 (UTC) FILETIME=[BDFA6DB0:01CE273C] Subject: Re: [OAUTH-WG] Confirmation 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: Fri, 22 Mar 2013 20:39:52 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0019_01CE271B.3406BC60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thank you for Confirmation.=20 dmtyne ------=_NextPart_000_0019_01CE271B.3406BC60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Thank you for Confirmation.
dmtyne
------=_NextPart_000_0019_01CE271B.3406BC60-- From andredemarre@gmail.com Fri Mar 22 15:08: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 7BB7C21F9429 for ; Fri, 22 Mar 2013 15:08:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uq7gc+tOmLjL for ; Fri, 22 Mar 2013 15:08:05 -0700 (PDT) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id C9C2D21F9037 for ; Fri, 22 Mar 2013 15:08:03 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id o45so3575097wer.23 for ; Fri, 22 Mar 2013 15:08:03 -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=qVgtyJlCkLixHJ5cutnQoz/f/i2WfWqJ3oaAcVbzk4Y=; b=WIPCMFACndYlLLXUbHW7J+qhZ9bQkIYqWTatOoQM+RklsuPEKxvxUl73/hEMr+DY5+ Zxn2aD9rA/RJUFN7ha+PQkcQFZb2vG47uzmg9f90YoFNPW2UKZ+eiIYhxMJomfcXYdYz /udQNiRQcX5tqJxd1WMWay81EI4axtfAKnvw0EOXh4XyOTxWQ9oqdc+K/38HB26xlsWt YKt7AlV2ohunj4qsI5We1QUR+OgoiEmUpE9/RxVVT6J2CKC4wIVbBWCRDnJn/K7B8cOD Grl2Twyk92pGWUdptr5L2No63kIVSkCJefHZfXOtfaj10UXCdzztNOdKMv1Wua0WMvLF 3g1Q== MIME-Version: 1.0 X-Received: by 10.194.172.71 with SMTP id ba7mr5878314wjc.26.1363990082986; Fri, 22 Mar 2013 15:08:02 -0700 (PDT) Received: by 10.194.235.169 with HTTP; Fri, 22 Mar 2013 15:08:02 -0700 (PDT) Date: Fri, 22 Mar 2013 15:08:02 -0700 Message-ID: From: =?ISO-8859-1?Q?Andr=E9_DeMarre?= To: OAuth WG Content-Type: text/plain; charset=ISO-8859-1 Subject: [OAUTH-WG] Returning 405 Method Not Allowed at token endpoint X-BeenThere: oauth@ietf.org X-Mailman-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, 22 Mar 2013 22:08:06 -0000 The OAuth 2 core spec says the client MUST use POST at the token endpoint (Section 3.2), but it doesn't specify the error response if a different method is used. While describing the error responses for the token endpoint in section 5.2, only 400 and 401 status codes are used. I believe the proper HTTP response should be a "405 Method Not Allowed" along with an "Allow: POST" header. That is what Google's implementation does, and their response body is HTML and not an OAuth error response at all (https://accounts.google.com/o/oauth2/token). Does using 405 conflict with the OAuth 2 spec? Possible interpretations that reconcile the conflict: 1) If a request at the token endpoint doesn't use POST, it isn't technically an access token request, and the server response isn't bound to the OAuth spec at all. (Google uses an HTML error page.) 2) Section 5.2 paragraph 1 appears to be non-normative, where it mentions code 400. The only HTTP error response declared normatively by the spec is 401 regarding failed client authentication. This leaves the server open to implement other status codes in compliance with the HTTP spec along with with OAuth error responses. For example, using 405 Method Not Allowed along with a {"error":"invalid_request"} error response. This is pedantic, but can a compliant authorization server use 405 in response to unsupported method requests at the token endpoint? It doesn't matter from an interoperability standpoint, but I'm noticing this particular error case being handled differently between auth server implementations. Regards, Andre DeMarre From markdoristyne@hotmail.com Sat Mar 23 13:33: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 73E6021F8C03 for ; Sat, 23 Mar 2013 13:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.733 X-Spam-Level: ** X-Spam-Status: No, score=2.733 tagged_above=-999 required=5 tests=[AWL=-0.768, BAYES_99=3.5, 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 Z02exiPASfFp for ; Sat, 23 Mar 2013 13:33:40 -0700 (PDT) Received: from snt0-omc1-s50.snt0.hotmail.com (snt0-omc1-s50.snt0.hotmail.com [65.54.61.87]) by ietfa.amsl.com (Postfix) with ESMTP id 03D7B21F8BF8 for ; Sat, 23 Mar 2013 13:33:36 -0700 (PDT) Received: from SNT144-DS15 ([65.55.90.8]) by snt0-omc1-s50.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 23 Mar 2013 13:33:33 -0700 X-EIP: [LmAvby7NyO/XB4bk9xVm1K4Gw7+oMnvb] X-Originating-Email: [markdoristyne@hotmail.com] Message-ID: From: "dorismark tyne" To: Date: Sat, 23 Mar 2013 16:33:26 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0016_01CE27E4.2516A1B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: MSN 9 X-MimeOLE: Produced By MSN MimeOLE V10.50.0008.2100 Seal-Send-Time: Sat, 23 Mar 2013 16:33:26 -0400 X-OriginalArrivalTime: 23 Mar 2013 20:33:33.0442 (UTC) FILETIME=[B014BE20:01CE2805] Subject: [OAUTH-WG] Identification X-BeenThere: oauth@ietf.org X-Mailman-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, 23 Mar 2013 20:33:40 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0016_01CE27E4.2516A1B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable dmtyne@gmail.com id. Thank You Doris Tyne. dmtyne ------=_NextPart_000_0016_01CE27E4.2516A1B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
dmtyne@gmail.com id. Thank You = Doris=20 Tyne.
dmtyne
------=_NextPart_000_0016_01CE27E4.2516A1B0-- From security.developer22@gmail.com Sun Mar 24 12:47:50 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 367E721F8615 for ; Sun, 24 Mar 2013 12:47:50 -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 VZW0xOr6tw2o for ; Sun, 24 Mar 2013 12:47:49 -0700 (PDT) Received: from mail-oa0-f66.google.com (mail-oa0-f66.google.com [209.85.219.66]) by ietfa.amsl.com (Postfix) with ESMTP id AD9D121F860B for ; Sun, 24 Mar 2013 12:47:49 -0700 (PDT) Received: by mail-oa0-f66.google.com with SMTP id n12so776412oag.5 for ; Sun, 24 Mar 2013 12:47:49 -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=n0lDJgQXWOi0e1xEKCT/BDuA9IwGPsRO9vp4wCEtpqY=; b=ymz4NK/GoBmSME6gpYMFNXIcI60gBsEc3HXE66NRlYMm4bhR5JRgAWBWK+pbzFtKSG 5moJ0dCifQmDwTNMvGYnvjmzU4xT55VU9RcJvXm5QA/xA1TrdvRm8pg716arUbdPwTnm ROI19y0mjTRIZ9oIgNzqR7C8liXRh7YlYBVkZIa56WqKyz2yAdwcTe1k++u75HLqOm41 kNBFJKEb3zX5r8csaJfenJNTSQSN13u+5ZPw5/vTeLS35Bpz4TTcULmoY2rbGi6LpoiQ EpkOhwZyPXEhWyTCsH7W8AwcgprvMh26HdnLlLeyQHIbxV9htWV6BzAVxVEk/m39MxpB lesA== MIME-Version: 1.0 X-Received: by 10.60.1.225 with SMTP id 1mr8691357oep.141.1364154469246; Sun, 24 Mar 2013 12:47:49 -0700 (PDT) Received: by 10.182.79.233 with HTTP; Sun, 24 Mar 2013 12:47:49 -0700 (PDT) Date: Mon, 25 Mar 2013 00:47:49 +0500 Message-ID: From: Security Developer To: OAuth@ietf.org Content-Type: multipart/alternative; boundary=e89a8fb1fbba8f3dcc04d8b0f646 Subject: [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: Sun, 24 Mar 2013 19:47:50 -0000 --e89a8fb1fbba8f3dcc04d8b0f646 Content-Type: text/plain; charset=ISO-8859-1 Hi, Can any body please help in describing the OAuth flow for mobile applications? Thanks for your time. --e89a8fb1fbba8f3dcc04d8b0f646 Content-Type: text/html; charset=ISO-8859-1 Hi,

Can any body please help in describing the OAuth flow for mobile applications?

Thanks for your time.
--e89a8fb1fbba8f3dcc04d8b0f646-- From sweeden@au1.ibm.com Sun Mar 24 15:07:42 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 0957021F8972 for ; Sun, 24 Mar 2013 15:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.11 X-Spam-Level: X-Spam-Status: No, score=-5.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 dVZOpczqhTBH for ; Sun, 24 Mar 2013 15:07:40 -0700 (PDT) Received: from e23smtp04.au.ibm.com (e23smtp04.au.ibm.com [202.81.31.146]) by ietfa.amsl.com (Postfix) with ESMTP id E674C21F88EA for ; Sun, 24 Mar 2013 15:07:39 -0700 (PDT) Received: from /spool/local by e23smtp04.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 25 Mar 2013 07:57:00 +1000 Received: from d23dlp02.au.ibm.com (202.81.31.213) by e23smtp04.au.ibm.com (202.81.31.210) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 25 Mar 2013 07:56:58 +1000 Received: from d23relay03.au.ibm.com (d23relay03.au.ibm.com [9.190.235.21]) by d23dlp02.au.ibm.com (Postfix) with ESMTP id B4F862BB0023; Mon, 25 Mar 2013 09:07:31 +1100 (EST) Received: from d23av05.au.ibm.com (d23av05.au.ibm.com [9.190.234.119]) by d23relay03.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r2OM7R9R2294192; Mon, 25 Mar 2013 09:07:27 +1100 Received: from d23av05.au.ibm.com (loopback [127.0.0.1]) by d23av05.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r2OM7VjN019284; Mon, 25 Mar 2013 09:07:31 +1100 Received: from d23ml004.au.ibm.com (d23ml004.au.ibm.com [9.190.250.23]) by d23av05.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id r2OM7VGH019274; Mon, 25 Mar 2013 09:07:31 +1100 In-Reply-To: References: X-KeepSent: 24B123EA:D61DBE38-4A257B38:00780B84; type=4; name=$KeepSent To: Security Developer X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 Message-ID: From: Shane B Weeden Date: Mon, 25 Mar 2013 07:54:32 +1000 X-MIMETrack: Serialize by Router on d23ml004/23/M/IBM(Release 8.5.3FP2HF29 | July 24, 2012) at 25/03/2013 09:12:00 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13032421-9264-0000-0000-000003652D32 Cc: OAuth@ietf.org, oauth-bounces@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: Sun, 24 Mar 2013 22:07:42 -0000 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 Regards, Shane. From: Security Developer To: OAuth@ietf.org Date: 25/03/2013 05:52 AM Subject: [OAUTH-WG] OAuth mobile flow Sent by: oauth-bounces@ietf.org Hi, Can any body please help in describing the OAuth flow for mobile applications? Thanks for your time._______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From sberyozkin@gmail.com Mon Mar 25 00:56: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 CB75F21F8E72 for ; Mon, 25 Mar 2013 00:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.961 X-Spam-Level: X-Spam-Status: No, score=0.961 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96, 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 d3xaNniRkbWu for ; Mon, 25 Mar 2013 00:56:16 -0700 (PDT) Received: from mail-ee0-f53.google.com (mail-ee0-f53.google.com [74.125.83.53]) by ietfa.amsl.com (Postfix) with ESMTP id 7499021F8E7B for ; Mon, 25 Mar 2013 00:56:15 -0700 (PDT) Received: by mail-ee0-f53.google.com with SMTP id c13so305813eek.12 for ; Mon, 25 Mar 2013 00:56:14 -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=U3QdbBWfRhjX9L7Vbpk6iNLgsPQAPQq2dquKIVv6N+4=; b=wanWMq9ODWAOuazDH/eTyXL8rr7xWnxPYxsJUzep3CJLQv/0p7eknY4TVF6aSyyBtY QeOXMEu0XNG15RmByWTSTbKDMRFda8asUldbNi/TyzIyXw4FrAFngmc2CujhrQu0TDU6 Gk/1UspcIbvYvIaVCslypGMuhzHWX0iZZhnSq275gWvE/WS2xzFkn5aablgqBtTB3gNH jx0eWgzLs06q1E+mj0brSm69nUSoznoOHB2zhIx6pMbU1URhIstLIZC+VnXBcl0OkzqI Yg0zPvExD2hWoJOeXiEml8o04YZThy8s5bc7Phx6ceGIljx8zwVdsv+HFxouW1kh92gL WTFw== X-Received: by 10.14.223.69 with SMTP id u45mr31194785eep.23.1364198174512; Mon, 25 Mar 2013 00:56:14 -0700 (PDT) Received: from [10.39.0.31] ([87.252.227.100]) by mx.google.com with ESMTPS id f47sm17245297eep.13.2013.03.25.00.56.12 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 25 Mar 2013 00:56:13 -0700 (PDT) Message-ID: <51500319.7080907@gmail.com> Date: Mon, 25 Mar 2013 10:56:09 +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: oauth@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Mon, 25 Mar 2013 07:56:19 -0000 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: Security Developer > To: OAuth@ietf.org > Date: 25/03/2013 05:52 AM > Subject: [OAUTH-WG] OAuth mobile flow > Sent by: oauth-bounces@ietf.org > > > > Hi, > > Can any body please help in describing the OAuth flow for mobile > applications? > > Thanks for your time._______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From bcampbell@pingidentity.com Mon Mar 25 04:52: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 6A90221F8CDF for ; Mon, 25 Mar 2013 04:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.562 X-Spam-Level: X-Spam-Status: No, score=-3.562 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UzN+N2FIn-dj for ; Mon, 25 Mar 2013 04:52:24 -0700 (PDT) Received: from na3sys009aog115.obsmtp.com (na3sys009aog115.obsmtp.com [74.125.149.238]) by ietfa.amsl.com (Postfix) with ESMTP id B82F021F8CDD for ; Mon, 25 Mar 2013 04:52:21 -0700 (PDT) Received: from mail-oa0-f71.google.com ([209.85.219.71]) (using TLSv1) by na3sys009aob115.postini.com ([74.125.148.12]) with SMTP ID DSNKUVA6dOBeqMEuF2NqgJQ92/BnrVVMSV22@postini.com; Mon, 25 Mar 2013 04:52:24 PDT Received: by mail-oa0-f71.google.com with SMTP id o6so31515820oag.2 for ; Mon, 25 Mar 2013 04:52:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=bXoJUSMC+UkJi2y3YB3BTDSTBcq7/42znU1g74WO2ps=; b=ExdQZFk4VRV34m2wv1LYHnUCvS8C/ApDeQgjLAuZ4askgEAl1FQMM2zlc4QWZnjYWa eBF1c+PpcdmaU7NT0K/zh26MlZp7gOPh0z87yKnZus64jgsO1scsVOW6Wpe22w6i6frG 45kVW3xWziialRiuLG8VbioIc7Z6aghFQ9xAvhY4JVDwDdXKjsduO0Lcv7ULGVqJhcaG uqdAdVQ+mWHafVkaa6imdMnlOhO2FTo4+eplKEifVPrgPZ5P42UUurOf5S1QdBDnhb+O hQIJD4MTCMaLNDOhlRkQ6NLOpilV0ZrYdgvl+1T4b9Ws2zd6+WzrwLUbgsQ1KExVf0/r 8Jcg== X-Received: by 10.50.178.212 with SMTP id da20mr2484550igc.13.1364212339880; Mon, 25 Mar 2013 04:52:19 -0700 (PDT) X-Received: by 10.50.178.212 with SMTP id da20mr2484544igc.13.1364212339792; Mon, 25 Mar 2013 04:52:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.32.106 with HTTP; Mon, 25 Mar 2013 04:51:49 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Mon, 25 Mar 2013 05:51:49 -0600 Message-ID: To: Security Developer Content-Type: multipart/alternative; boundary=089e0158b2dae97d8b04d8be6f6b X-Gm-Message-State: ALoCoQnOYxEJtT/56teLE/VruVMUiPhrYfnqFW4i5VdxB5wUcH8ivUiUmbcYW5hNGEj762yzn6XZKKx/hulexjDIBoUGUxb5v7L2p11gOElTnt41x1puaBnF+JFF6cOVvfI4QBRPBL6x Cc: oauth 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: Mon, 25 Mar 2013 11:52:25 -0000 --089e0158b2dae97d8b04d8be6f6b Content-Type: text/plain; charset=ISO-8859-1 This little presentation from last year talks about OAuth & mobile. In a nutshell, it discusses using the authorization code grant and a redirect uri with a custom scheme. http://www.slideshare.net/briandavidcampbell/is-that-a-token-in-your-phone-in-your-pocket-or-are-you-just-glad-to-see-me-oauth-20-and-mobile-devices On Sun, Mar 24, 2013 at 1:47 PM, Security Developer < security.developer22@gmail.com> wrote: > Hi, > > Can any body please help in describing the OAuth flow for mobile > applications? > > Thanks for your time. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --089e0158b2dae97d8b04d8be6f6b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This little presentation from last year talks about OAuth = & mobile. In a nutshell, it discusses using the authorization code gran= t and a redirect uri with a custom scheme.

http://www.sl= ideshare.net/briandavidcampbell/is-that-a-token-in-your-phone-in-your-pocke= t-or-are-you-just-glad-to-see-me-oauth-20-and-mobile-devices


On Sun,= Mar 24, 2013 at 1:47 PM, Security Developer <security.devel= oper22@gmail.com> wrote:
Hi,

Can any body please help in descr= ibing the OAuth flow for mobile applications?

Thanks for your time.<= br>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth


--089e0158b2dae97d8b04d8be6f6b-- From sweeden@au1.ibm.com Mon Mar 25 04:56: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 D646B21F8BF1 for ; Mon, 25 Mar 2013 04:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=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 0S8cC1xyd8jC for ; Mon, 25 Mar 2013 04:56:57 -0700 (PDT) Received: from e23smtp03.au.ibm.com (e23smtp03.au.ibm.com [202.81.31.145]) by ietfa.amsl.com (Postfix) with ESMTP id A7EE921F8EBE for ; Mon, 25 Mar 2013 04:56: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 ; Mon, 25 Mar 2013 21:49:48 +1000 Received: from d23dlp01.au.ibm.com (202.81.31.203) by e23smtp03.au.ibm.com (202.81.31.209) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 25 Mar 2013 21:49:44 +1000 Received: from d23relay04.au.ibm.com (d23relay04.au.ibm.com [9.190.234.120]) by d23dlp01.au.ibm.com (Postfix) with ESMTP id 040B12CE804A; Mon, 25 Mar 2013 22:56:38 +1100 (EST) Received: from d23av02.au.ibm.com (d23av02.au.ibm.com [9.190.235.138]) by d23relay04.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r2PBhc6N29556942; Mon, 25 Mar 2013 22:43:38 +1100 Received: from d23av02.au.ibm.com (loopback [127.0.0.1]) by d23av02.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r2PBubfY024440; Mon, 25 Mar 2013 22:56:37 +1100 Received: from d23ml004.au.ibm.com (d23ml004.au.ibm.com [9.190.250.23]) by d23av02.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id r2PBubPc024430; Mon, 25 Mar 2013 22:56:37 +1100 In-Reply-To: <51500319.7080907@gmail.com> References: <51500319.7080907@gmail.com> X-KeepSent: 6A47FCF7:24CA52D3-4A257B39:0040618D; 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: Mon, 25 Mar 2013 21:55:54 +1000 X-MIMETrack: Serialize by Router on d23ml004/23/M/IBM(Release 8.5.3FP2HF29 | July 24, 2012) at 25/03/2013 23:01:07 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13032511-6102-0000-0000-0000033634F1 Cc: oauth@ietf.org, oauth-bounces@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: Mon, 25 Mar 2013 11:56:58 -0000 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. 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: Security Developer > To: OAuth@ietf.org > Date: 25/03/2013 05:52 AM > Subject: [OAUTH-WG] OAuth mobile flow > Sent by: oauth-bounces@ietf.org > > > > Hi, > > Can any body please help in describing the OAuth flow for mobile > applications? > > Thanks for your time._______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From jricher@mitre.org Mon Mar 25 08:13: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 31D0D21F8E84 for ; Mon, 25 Mar 2013 08:13:25 -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 ILskkDDHxrYu for ; Mon, 25 Mar 2013 08:13:24 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id E50F221F8DDD for ; Mon, 25 Mar 2013 08:13:20 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 6EE691F044D; Mon, 25 Mar 2013 11:13:20 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 601581F0434; Mon, 25 Mar 2013 11:13:20 -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; Mon, 25 Mar 2013 11:12:54 -0400 Message-ID: <51506934.4080104@mitre.org> Date: Mon, 25 Mar 2013 11:11:48 -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: "Manger, James H" References: <1B4C0C9F-4B8E-4B2D-BAF7-665D3EBBE56C@ve7jtb.com> <51408B8B.9000800@mitre.org> <5141E2E6.9020701@aol.com> <5141E671.2050708@mitre.org> <4E1F6AAD24975D4BA5B16804296739436750F5E2@TK5EX14MBXC283.redmond.corp.microsoft.com>, <5149F092.7070902@mitre.org> <4E1F6AAD24975D4BA5B168042967394367565FEF@TK5EX14MBXC283.redmond.corp.microsoft.com> <5149F534.1040500@mitre.org> <4E1F6AAD24975D4BA5B168042967394367567185@TK5EX14MBXC283.redmond.corp.microsoft.com> <514B4E28.7000309@mitre.org> <255B9BB34FB7D647A506DC292726F6E1150BD3FB27@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1150BD3FB27@WSMSG3153V.srv.dir.telstra.com> Content-Type: multipart/alternative; boundary="------------030109030609060100060104" X-Originating-IP: [129.83.31.58] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readable names X-BeenThere: oauth@ietf.org X-Mailman-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, 25 Mar 2013 15:13:25 -0000 --------------030109030609060100060104 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit "Internationalization is the process of designing a software application so that it can be adapted to various languages and regions without engineering changes." (From http://en.wikipedia.org/wiki/Internationalization_and_localization) What this means in our case is that you'd want a string that would be usable on the widest variety of systems that you care about without them having to do something special to handle it. For some, that's going to mean ASCII. For others, it's going to mean some common local script. And yes, the # character is appended to the field name, good catch. -- Justin On 03/21/2013 09:43 PM, Manger, James H wrote: > > What is an “internationalized UTF-8 string� > > P.S. It would be worth explicitly stating that the # character and > RFC5646 language tag are appended **to the field name** (not the > value). I assume this is right. > > -- > > James Manger > > *From:*oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On > Behalf Of *Justin Richer > *Sent:* Friday, 22 March 2013 5:15 AM > *To:* oauth@ietf.org WG > *Subject:* Re: [OAUTH-WG] Registration: Internationalization of > Human-Readable names > > We discussed this issue on the OpenID Connect WG call this morning, in > a conversation that included myself, George Fletcher, Nat Sakimura, > Mike Jones, and John Bradley (among others) as active participants in > this thread. After lots of debate, we propose that the OAuth DynReg > adopt the hashtag-based localization method of OIDC (and it seems, > possibly webfinger) and explicitly declare that neither the client nor > the server make any assumptions about the content of the string and > treat it as just a string. I'm proposing this text to that effect > (with the references to OIDC-messages removed and replaced with the > rule description itself in OAuth DynReg): > > Fields with human-readable values or references to human-readable > values, such as client_name, tos_uri, policy_uri, and client_uri, MAY > be represented in multiple languages and scripts, specified by > appending a # character and the RFC5646 language tag. If any such > human-readable field is sent without a language tag, the server and > the client MUST NOT make any assumptions about the language, character > set, or script of the value string, and the value string MUST be used > as-is wherever it is presented in either the client or server UI. To > facilitate interoperability, it is RECOMMENDED that any fields sent > without language tags contain an internationalized UTF-8 string > suitable for display on a wide variety of systems, and it is > RECOMMENDED that clients send fields without language tags in addition > to any more-specifically denominated values. > > > Plus some examples. > > (Anyone whose name I took in vain, please feel free to correct me.) > > -- Justin > --------------030109030609060100060104 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit "Internationalization is the process of designing a software application so that it can be adapted to various languages and regions without engineering changes." (From http://en.wikipedia.org/wiki/Internationalization_and_localization)

What this means in our case is that you'd want a string that would be usable on the widest variety of systems that you care about without them having to do something special to handle it. For some, that's going to mean ASCII. For others, it's going to mean some common local script.

And yes, the # character is appended to the field name, good catch.

 -- Justin


On 03/21/2013 09:43 PM, Manger, James H wrote:

What is an “internationalized UTF-8 string�

 

P.S. It would be worth explicitly stating that the # character and RFC5646 language tag are appended *to the field name* (not the value). I assume this is right.

 

--

James Manger

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Justin Richer
Sent: Friday, 22 March 2013 5:15 AM
To: oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readable names

 

We discussed this issue on the OpenID Connect WG call this morning, in a conversation that included myself, George Fletcher, Nat Sakimura, Mike Jones, and John Bradley (among others) as active participants in this thread. After lots of debate, we propose that the OAuth DynReg adopt the hashtag-based localization method of OIDC (and it seems, possibly webfinger) and explicitly declare that neither the client nor the server make any assumptions about the content of the string and treat it as just a string. I'm proposing this text to that effect (with the references to OIDC-messages removed and replaced with the rule description itself in OAuth DynReg):

Fields with human-readable values or references to human-readable values, such as client_name, tos_uri, policy_uri, and client_uri, MAY be represented in multiple languages and scripts, specified by appending a # character and the RFC5646 language tag. If any such human-readable field is sent without a language tag, the server and the client MUST NOT make any assumptions about the language, character set, or script of the value string, and the value string MUST be used as-is wherever it is presented in either the client or server UI. To facilitate interoperability, it is RECOMMENDED that any fields sent without language tags contain an internationalized UTF-8 string suitable for display on a wide variety of systems, and it is RECOMMENDED that clients send fields without language tags in addition to any more-specifically denominated values.


Plus some examples.

(Anyone whose name I took in vain, please feel free to correct me.)

 -- Justin


--------------030109030609060100060104-- From jricher@mitre.org Mon Mar 25 08:16:04 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 1034F21F8FED for ; Mon, 25 Mar 2013 08:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.298 X-Spam-Level: X-Spam-Status: No, score=-5.298 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, 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 oDKLfE6SmwxX for ; Mon, 25 Mar 2013 08:16:00 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 55ABC21F8E84 for ; Mon, 25 Mar 2013 08:16:00 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 08DD02A50189; Mon, 25 Mar 2013 11:16:00 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id E64482A5017F; Mon, 25 Mar 2013 11:15:59 -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; Mon, 25 Mar 2013 11:15:34 -0400 Message-ID: <515069D4.2040006@mitre.org> Date: Mon, 25 Mar 2013 11:14:28 -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: Nat Sakimura References: <1B4C0C9F-4B8E-4B2D-BAF7-665D3EBBE56C@ve7jtb.com> <51408B8B.9000800@mitre.org> <5141E2E6.9020701@aol.com> <5141E671.2050708@mitre.org> <4E1F6AAD24975D4BA5B16804296739436750F5E2@TK5EX14MBXC283.redmond.corp.microsoft.com> <5149F092.7070902@mitre.org> <4E1F6AAD24975D4BA5B168042967394367565FEF@TK5EX14MBXC283.redmond.corp.microsoft.com> <5149F534.1040500@mitre.org> <4E1F6AAD24975D4BA5B168042967394367567185@TK5EX14MBXC283.redmond.corp.microsoft.com> <514B4E28.7000309@mitre.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040609040300090105020807" X-Originating-IP: [129.83.31.58] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readable names X-BeenThere: oauth@ietf.org X-Mailman-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, 25 Mar 2013 15:16:04 -0000 --------------040609040300090105020807 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit No problem, it's important that we be very precise about this bit of text. There are many terms in this space with subtle differences between them, so I'm glad to have others with more experience reading over it. -- Justin On 03/21/2013 08:44 PM, Nat Sakimura wrote: > I withdraw the comment. > > Somehow, for a moment, charset and encoding was flipped in my head. > Maybe I need a vacation. > > Sorry. > > Nat > > 2013/3/22 Nat Sakimura > > > Can we tighten it a bit as to the encoding is concerned? > I believe all the fields value MUST be UTF-8, so it propagates > here as well. > Saying that it must not make any assumption on character set > (e.g., UTF-8) is a bit too much. > Proposed text: > > Fields with human-readable values or references to > human-readable values, such as client_name, tos_uri, > policy_uri, and client_uri, MAY be represented in multiple > languages and scripts, specified by appending a # character > and the RFC5646 language tag. If any such human-readable field > is sent without a language tag, the server and the client MUST > NOT make any assumptions about the language, script, and > country of the value string, and the value string MUST be used > as-is wherever it is presented in either the client or server > UI. To facilitate interoperability, it is RECOMMENDED that any > fields sent without language tags contain an internationalized > UTF-8 string suitable for display on a wide variety of > systems, and it is RECOMMENDED that clients send fields > without language tags in addition to any more-specifically > denominated values. > > > 2013/3/22 Justin Richer > > > We discussed this issue on the OpenID Connect WG call this > morning, in a conversation that included myself, George > Fletcher, Nat Sakimura, Mike Jones, and John Bradley (among > others) as active participants in this thread. After lots of > debate, we propose that the OAuth DynReg adopt the > hashtag-based localization method of OIDC (and it seems, > possibly webfinger) and explicitly declare that neither the > client nor the server make any assumptions about the content > of the string and treat it as just a string. I'm proposing > this text to that effect (with the references to OIDC-messages > removed and replaced with the rule description itself in OAuth > DynReg): > > Fields with human-readable values or references to > human-readable values, such as client_name, tos_uri, > policy_uri, and client_uri, MAY be represented in multiple > languages and scripts, specified by appending a # > character and the RFC5646 language tag. If any such > human-readable field is sent without a language tag, the > server and the client MUST NOT make any assumptions about > the language, character set, or script of the value > string, and the value string MUST be used as-is wherever > it is presented in either the client or server UI. To > facilitate interoperability, it is RECOMMENDED that any > fields sent without language tags contain an > internationalized UTF-8 string suitable for display on a > wide variety of systems, and it is RECOMMENDED that > clients send fields without language tags in addition to > any more-specifically denominated values. > > > Plus some examples. > > (Anyone whose name I took in vain, please feel free to correct > me.) > > -- Justin > > > On 03/20/2013 03:11 PM, Justin Richer wrote: >> I agree that I'm seeing things from the single-language and >> single-encoding perspective here, and that's the use case I'm >> currently solving for with my development. I want to see this >> one remain simple, and I think we can do that without >> breaking other use cases. >> >> I would argue that multi-script languages (such as Chinese, >> Japanese, and others) are all cases where you're going to >> assume multiple languages, and the tags would be necessary >> for real use. So client and AS would both need to know how to >> deal with the multiple different tags, and smart ones would >> be able to effectively ignore the default field. The default, >> scriptless field could be for any one of the supported >> languages at the AS or Client, and it'd effectively be a >> backup, internationalized version, the one that you use when >> there's nothing else more specific to use. >> >> I guess what's getting me stuck on the explicit locale field >> is that I'm not seeing much value in requiring it over >> George's proposal of always using language tags on everything >> (which I also don't like, but for different reasons). Having >> the information doesn't mean that you can do anything >> intelligent with it, either, but I can see the argument that >> it makes doing something smart possible. But on the other >> hand, we already have a mechanism for doing something smart: >> using the explicit language tags directly. >> >> Also, note that the AS doesn't need to render any characters >> for tos_uri, policy_uri, and other _uri options, just for >> client_name. That's why I was making the distinction in my >> explanation below. You might want to give the user the right >> option, sure, but a served webpage has a much better chance >> of getting the locale right dynamically than an included >> string would have (approaches like user preferences, browser >> settings, etc. -- everything that's used today on web pages, >> in other words). This is why I think that the _uri claims are >> in a different category and we're talking almost exclusively >> about client_name here. >> >> I think, ultimately, that I need to think about this more. >> >> -- Justin >> >> On 03/20/2013 02:30 PM, Mike Jones wrote: >>> >>> I suspect you only feel that leaving the locale information >>> out is OK because you (and I) live in a culture where it$B!G(Bs >>> not needed to adequately render characters. I$B!G(Bd actually >>> defer on this decision to Nat and others from Japan and >>> China (and I think Korea?) where I believe that this >>> information is essential. >>> >>> For what it$B!G(Bs worth, it$B!G(Bs more than just client_name. It$B!G(Bs >>> also tos_uri and policy_uri and potentially client_uri. >>> >>> Also, having thought about it for a few days, I$B!G(Bd change the >>> proposed field name from registration_locale to >>> default_registration_locale, so the meaning is clearer. >>> >>> Nat and others from Eastern cultures, what is your opinion >>> on this? >>> >>> Thanks, >>> >>> -- Mike >>> >>> *From:*Justin Richer [mailto:jricher@mitre.org] >>> *Sent:* Wednesday, March 20, 2013 10:43 AM >>> *To:* Mike Jones >>> *Cc:* George Fletcher; oauth@ietf.org WG >>> *Subject:* Re: [OAUTH-WG] Registration: Internationalization >>> of Human-Readable names >>> >>> I would say that claims without a language parameter, which >>> I would make REQUIRED in the presence of other claims, would >>> be treated as UTF8 strings with no guarantee of what >>> language, script, or other locale-specific information would >>> be in there. It's a default string, and it's the best the >>> client can give if nothing more specific is useful. And >>> servers would have to accept this default string and do >>> their best with it. A service provider can publish their >>> expected default locale information in either discovery or >>> service documentation, and clients that want to tweak things >>> for specific service providers can do that. >>> >>> The server can display it (because it's a string that'll >>> always be there, if any version is there), but a server that >>> doesn't do internationalized strings very well might not get >>> its display correct. Since displayable text this is likely >>> to be dumped into the middle of a webpage that has its own >>> character encoding and other considerations anyway, so it's >>> not guaranteed that specifying a locale will always help >>> here anyway. This is just for the displayable text, which >>> right now is only the client_name field in OAuth and OIDC: >>> for URLs (the other "human-readable" field), it's a moot >>> point, because the server's just going to spit out the URL >>> itself into an href of some flavor. The server doesn't have >>> to deal with any kind of encoding or text/script issues here. >>> >>> As a server developer, it's just another thing that I *have* >>> to track and deal with on the client model, even if I don't >>> want to support the rest of the multi-language tags in my >>> service. As a client developer, it's one more thing that I >>> *have* to specify when I send things to the server. I don't >>> see how requiring its specification is going to really help >>> interoperability, and I can almost guarantee that >>> implementations will just leave it off even if marked >>> REQUIRED (like how many, many documents in the wild that are >>> supposed to have a character-encoding field of some type >>> just leave it off). >>> >>> I think that it's a lot of work on both sides for just >>> client_name. >>> >>> -- Justin >>> >>> On 03/20/2013 01:27 PM, Mike Jones wrote: >>> >>> How would you do this instead then? >>> >>> ------------------------------------------------------------------------ >>> >>> *From: *Justin Richer >>> *Sent: *3/20/2013 10:25 AM >>> *To: *Mike Jones >>> *Cc: *George Fletcher; oauth@ietf.org >>> WG >>> *Subject: *Re: [OAUTH-WG] Registration: >>> Internationalization of Human-Readable names >>> >>> Personally, I think that this level of specificity is >>> overkill. >>> >>> -- Justin >>> >>> On 03/14/2013 11:42 AM, Mike Jones wrote: >>> >>> I agree that having unadorned values likely >>> simplifies things in many cases, but if we do this, >>> we should let the Client say what language/script >>> it$B!G(Bs using when providing human-readable strings or >>> references to them as registration parameters. For >>> this purpose, I$B!G(Bd propose that we have a parameter >>> something like this one: >>> >>> registration_locale >>> >>> OPTIONAL or REQURED. Language and script used for >>> human-readable values or references to >>> human-readable values that are supplied without >>> language/script tags, represented as a >>> BCP47[RFC5646] language tag value. This parameter is >>> REQUIRED if any human-readable values or references >>> to human-readable are provided without >>> language/script tags. >>> >>> -- Mike >>> >>> *From:*oauth-bounces@ietf.org >>> >>> [mailto:oauth-bounces@ietf.org] *On Behalf Of >>> *Justin Richer >>> *Sent:* Thursday, March 14, 2013 8:02 AM >>> *To:* George Fletcher >>> *Cc:* oauth@ietf.org WG >>> *Subject:* Re: [OAUTH-WG] Registration: >>> Internationalization of Human-Readable names >>> >>> On the surface this does simplify things, but the >>> issue I forsee with it is that I want to be able to >>> call "client.getClientName()" and always get >>> *something* out of it if there are *any* client_name >>> fields at all. So in this world if I take a client >>> library that assumes en-us and it talks to a server >>> that only looks for es-cl, there's a very real >>> chance of the client name not getting set at all. I >>> think that's a problem. >>> >>> This is why I think the default field name (without >>> the language tag) really should be required and >>> should be left undefined as to what language and >>> script it is. Essentially, "It's a UTF8 String, hope >>> for the best". If you want something more specific >>> and smart about localization, then you can support >>> the language tags. If you just want to have a string >>> to store and throw at the user, then you can just >>> use the bare field name. >>> >>> In other words, we take what we have now (which >>> works for a non-internationalized case where >>> everyone just assumes a common language/script), and >>> we augment it with features that let it be smarter >>> if you want it to be smarter. Make the simple case >>> simple, make the complicated case possible. >>> >>> -- Justin >>> >>> On 03/14/2013 10:47 AM, George Fletcher wrote: >>> >>> As a simplifying option... why not just require >>> human-readable fields to require a "script-tag". >>> This way it is always explicit what >>> language/locale the text is for. It then becomes >>> the responsibility of the AS to return an >>> appropriate response if there is not a direct >>> match between a request and the data stored at >>> the AS (and out of scope of the spec). >>> >>> Thanks, >>> George >>> >>> On 3/13/13 10:22 AM, Justin Richer wrote: >>> >>> So with what little feedback I've gotten, >>> I'm proposing to add text from the proposed >>> webfinger and OIDC drafts for the hash-based >>> localization of strings, with the following >>> properties: >>> >>> * All localized versions of fields are fully >>> optional on both client and server >>> * If a localized version of a field is >>> included, its bare-value (perhaps >>> internationalized) field MUST be included >>> * All human-readable fields are eligible for >>> this mechanism (including any uri's for >>> user-facing web pages, which can be used to >>> point to language-specific pages) >>> * Clients and servers can decide to use >>> whatever language/script they want to for >>> the bare-value field, and no assumptions can >>> be made on either side about what that is >>> >>> I think that with these constraints, we can >>> add functionality to address Stephen's >>> concerns without getting too complicated or >>> putting too much burden of support. >>> >>> -- Justin >>> >>> On 03/11/2013 06:52 PM, Nat Sakimura wrote: >>> >>> Similar work is in progress at Webfinger. >>> >>> See: >>> http://www.ietf.org/mail-archive/web/webfinger/current/msg00530.html >>> >>> Paul is proposing the same syntax as >>> Connect. >>> >>> 2013/3/12 Richer, Justin P. >>> >> > >>> >>> It does presume a definition of "claim", >>> which I suppose we could turn to >>> "metadata field" for DynReg and its >>> extensions to be appropriately limiting. >>> But we also need a good definition of >>> what a language-tag-less field means, >>> and whether or not it's required if the >>> other fields are present or not (which >>> is something that Connect is trying to >>> fix at the moment, as I recall from last >>> week). >>> >>> So it turns into about a paragraph worth >>> of text. Is that worth it? I'm not >>> entirely convinced that it is, but I'm >>> interested to hear what others think, >>> particularly those who *aren't* tied >>> into the OpenID Connect protocol so >>> much. (I don't want to pick a solution >>> just because it's familiar, if we need a >>> solution at all.) >>> >>> -- Justin >>> >>> On Mar 11, 2013, at 6:35 PM, Brian >>> Campbell >> > >>> >>> wrote: >>> >>> A fair question but what would need to >>> be pulled in is really probably only a >>> couple sentences (and reference) from >>> http://openid.net/specs/openid-connect-messages-1_0-16.html#ClaimsLanguagesAndScripts >>> (note the reference to 2.1.1.1.3 inside >>> http://openid.net/specs/openid-connect-registration-1_0-15.html >>> is broken) >>> >>> On Mon, Mar 11, 2013 at 6:26 PM, Richer, >>> Justin P. >> > wrote: >>> >>> My concern with this is that OIDC can >>> get away with defining this >>> multi-language structure because it >>> defines the mechanism once (in Messages) >>> and applies it to all user-readable >>> strings throughout the whole application >>> protocol, of which there are several. Do >>> we really want to pull in that whole >>> structure and mechanism for one field in >>> client registration? I really don't >>> think it should be something that's >>> defined completely inside of DynReg for >>> a corner case for a single field, but I >>> also doubt we want to normatively point >>> to OIDC Messages for this solution either. >>> >>> There are also other ways to do this: >>> Webfinger [1] for instance uses JSON >>> structures to give language tags to >>> field values, and has a default mechanism: >>> >>> { "en_us": "my client", $B!D(B } >>> >>> The fundamental question is this: should >>> a client be able to register multiple >>> names (in different locales) with a >>> single client_id, or should it get a >>> different client_id for each display >>> language set? >>> >>> -- Justin >>> >>> [1] >>> http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-11 >>> >>> On Mar 11, 2013, at 5:54 PM, John >>> Bradley >> > >>> >>> wrote: >>> >>> That is what I was thinking. It would be >>> up to the AS to determine what language >>> and script to present based on the user >>> preference. >>> >>> While a large number of clients will be >>> native and might be able to customize >>> themselves for a single user during >>> registration , we don't want to forget >>> the web server clients that are multi user. >>> >>> On 2013-03-11, at 10:49 PM, Brian >>> Campbell >> > wrote: >>> >>> FWIW, the closely related OpenID Connect >>> client registration draft does have some >>> support for doing this, which could >>> maybe be borrowed. See client_name in $B!x(B2 >>> at >>> http://openid.net/specs/openid-connect-registration-1_0-15.html#client-metadata >>> and the examples. >>> >>> "client_name": "My Example", >>> >>> "client_name#ja-Jpan-JP":"$B%/%i%$%"%s%HL>(B", >>> >>> On Mon, Mar 11, 2013 at 5:15 PM, Richer, >>> Justin P. >> > wrote: >>> >>> It was brought up at the in-person >>> meeting today that we'll want to >>> consider issues around >>> internationalization and localization of >>> human-readable fields like client_name >>> in the client registration. Which is to >>> say: if a client supports ten languages >>> and wants to present itself in ten >>> languages, should it have to register >>> itself ten times with an AS? >>> >>> At the moment, I'm of the opinion a >>> client with ten languages could register >>> itself ten times, or do something with >>> the context in which it runs to >>> determine which human-facing language to >>> use. Keep in mind that in some cases >>> (such as native clients), you'll be >>> dynamically registering a client for >>> each user, in effect. In other words, I >>> personally think that this is a rathole >>> that will cause more harm than good. >>> >>> -- Justin >>> _______________________________________________ >>> OAuth mailing 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 >>> >>> >>> >>> -- >>> Nat Sakimura (=nat) >>> >>> Chairman, OpenID Foundation >>> http://nat.sakimura.org/ >>> @_nat_en >>> >>> >>> >>> >>> _______________________________________________ >>> >>> OAuth mailing list >>> >>> OAuth@ietf.org >>> >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > -- > Nat Sakimura (=nat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > > > > -- > Nat Sakimura (=nat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en --------------040609040300090105020807 Content-Type: text/html; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit No problem, it's important that we be very precise about this bit of text. There are many terms in this space with subtle differences between them, so I'm glad to have others with more experience reading over it.

 -- Justin

On 03/21/2013 08:44 PM, Nat Sakimura wrote:
I withdraw the comment. 

Somehow, for a moment, charset and encoding was flipped in my head. 
Maybe I need a vacation. 

Sorry. 

Nat

2013/3/22 Nat Sakimura <sakimura@gmail.com>
Can we tighten it a bit as to the encoding is concerned? 
I believe all the fields value MUST be UTF-8, so it propagates here as well.  
Saying that it must not make any assumption on character set (e.g., UTF-8) is a bit too much. 
Proposed text: 

Fields with human-readable values or references to human-readable values, such as client_name, tos_uri, policy_uri, and client_uri, MAY be represented in multiple languages and scripts, specified by appending a # character and the RFC5646 language tag. If any such human-readable field is sent without a language tag, the server and the client MUST NOT make any assumptions about the language, script, and country of the value string, and the value string MUST be used as-is wherever it is presented in either the client or server UI. To facilitate interoperability, it is RECOMMENDED that any fields sent without language tags contain an internationalized UTF-8 string suitable for display on a wide variety of systems, and it is RECOMMENDED that clients send fields without language tags in addition to any more-specifically denominated values.

2013/3/22 Justin Richer <jricher@mitre.org>
We discussed this issue on the OpenID Connect WG call this morning, in a conversation that included myself, George Fletcher, Nat Sakimura, Mike Jones, and John Bradley (among others) as active participants in this thread. After lots of debate, we propose that the OAuth DynReg adopt the hashtag-based localization method of OIDC (and it seems, possibly webfinger) and explicitly declare that neither the client nor the server make any assumptions about the content of the string and treat it as just a string. I'm proposing this text to that effect (with the references to OIDC-messages removed and replaced with the rule description itself in OAuth DynReg):

Fields with human-readable values or references to human-readable values, such as client_name, tos_uri, policy_uri, and client_uri, MAY be represented in multiple languages and scripts, specified by appending a # character and the RFC5646 language tag. If any such human-readable field is sent without a language tag, the server and the client MUST NOT make any assumptions about the language, character set, or script of the value string, and the value string MUST be used as-is wherever it is presented in either the client or server UI. To facilitate interoperability, it is RECOMMENDED that any fields sent without language tags contain an internationalized UTF-8 string suitable for display on a wide variety of systems, and it is RECOMMENDED that clients send fields without language tags in addition to any more-specifically denominated values.

Plus some examples.

(Anyone whose name I took in vain, please feel free to correct me.)

 -- Justin


On 03/20/2013 03:11 PM, Justin Richer wrote:
I agree that I'm seeing things from the single-language and single-encoding perspective here, and that's the use case I'm currently solving for with my development. I want to see this one remain simple, and I think we can do that without breaking other use cases.

I would argue that multi-script languages (such as Chinese, Japanese, and others) are all cases where you're going to assume multiple languages, and the tags would be necessary for real use. So client and AS would both need to know how to deal with the multiple different tags, and smart ones would be able to effectively ignore the default field. The default, scriptless field could be for any one of the supported languages at the AS or Client, and it'd effectively be a backup, internationalized version, the one that you use when there's nothing else more specific to use.

I guess what's getting me stuck on the explicit locale field is that I'm not seeing much value in requiring it over George's proposal of always using language tags on everything (which I also don't like, but for different reasons). Having the information doesn't mean that you can do anything intelligent with it, either, but I can see the argument that it makes doing something smart possible. But on the other hand, we already have a mechanism for doing something smart: using the explicit language tags directly.

Also, note that the AS doesn't need to render any characters for tos_uri, policy_uri, and other _uri options, just for client_name. That's why I was making the distinction in my explanation below. You might want to give the user the right option, sure, but a served webpage has a much better chance of getting the locale right dynamically than an included string would have (approaches like user preferences, browser settings, etc. -- everything that's used today on web pages, in other words). This is why I think that the _uri claims are in a different category and we're talking almost exclusively about client_name here.

I think, ultimately, that I need to think about this more.

  -- Justin

On 03/20/2013 02:30 PM, Mike Jones wrote:

I suspect you only feel that leaving the locale information out is OK because you (and I) live in a culture where it$B!G(Bs not needed to adequately render characters.  I$B!G(Bd actually defer on this decision to Nat and others from Japan and China (and I think Korea?) where I believe that this information is essential.

 

For what it$B!G(Bs worth, it$B!G(Bs more than just client_name.  It$B!G(Bs also tos_uri and policy_uri and potentially client_uri.

 

Also, having thought about it for a few days, I$B!G(Bd change the proposed field name from registration_locale to default_registration_locale, so the meaning is clearer.

 

Nat and others from Eastern cultures, what is your opinion on this?

 

                                                            Thanks,

                                                            -- Mike

 

From: Justin Richer [mailto:jricher@mitre.org]
Sent: Wednesday, March 20, 2013 10:43 AM
To: Mike Jones
Cc: George Fletcher; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readable names

 

I would say that claims without a language parameter, which I would make REQUIRED in the presence of other claims, would be treated as UTF8 strings with no guarantee of what language, script, or other locale-specific information would be in there. It's a default string, and it's the best the client can give if nothing more specific is useful. And servers would have to accept this default string and do their best with it. A service provider can publish their expected default locale information in either discovery or service documentation, and clients that want to tweak things for specific service providers can do that.

The server can display it (because it's a string that'll always be there, if any version is there), but a server that doesn't do internationalized strings very well might not get its display correct. Since displayable text this is likely to be dumped into the middle of a webpage that has its own character encoding and other considerations anyway, so it's not guaranteed that specifying a locale will always help here anyway. This is just for the displayable text, which right now is only the client_name field in OAuth and OIDC: for URLs (the other "human-readable" field), it's a moot point, because the server's just going to spit out the URL itself into an href of some flavor. The server doesn't have to deal with any kind of encoding or text/script issues here.

As a server developer, it's just another thing that I *have* to track and deal with on the client model, even if I don't want to support the rest of the multi-language tags in my service. As a client developer, it's one more thing that I *have* to specify when I send things to the server. I don't see how requiring its specification is going to really help interoperability, and I can almost guarantee that implementations will just leave it off even if marked REQUIRED (like how many, many documents in the wild that are supposed to have a character-encoding field of some type just leave it off).

I think that it's a lot of work on both sides for just client_name.

 -- Justin

On 03/20/2013 01:27 PM, Mike Jones wrote:

How would you do this instead then?

From: Justin Richer
Sent: 3/20/2013 10:25 AM
To: Mike Jones
Cc: George Fletcher; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readable names

Personally, I think that this level of specificity is overkill.

 -- Justin

On 03/14/2013 11:42 AM, Mike Jones wrote:

I agree that having unadorned values likely simplifies things in many cases, but if we do this, we should let the Client say what language/script it$B!G(Bs using when providing human-readable strings or references to them as registration parameters.  For this purpose, I$B!G(Bd propose that we have a parameter something like this one:

 

registration_locale

OPTIONAL or REQURED. Language and script used for human-readable values or references to human-readable values that are supplied without language/script tags, represented as a BCP47[RFC5646] language tag value.  This parameter is REQUIRED if any human-readable values or references to human-readable are provided without language/script tags.

 

                                                            -- Mike

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Justin Richer
Sent: Thursday, March 14, 2013 8:02 AM
To: George Fletcher
Cc: oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readable names

 

On the surface this does simplify things, but the issue I forsee with it is that I want to be able to call "client.getClientName()" and always get *something* out of it if there are *any* client_name fields at all. So in this world if I take a client library that assumes en-us and it talks to a server that only looks for es-cl, there's a very real chance of the client name not getting set at all. I think that's a problem.

This is why I think the default field name (without the language tag) really should be required and should be left undefined as to what language and script it is. Essentially, "It's a UTF8 String, hope for the best". If you want something more specific and smart about localization, then you can support the language tags. If you just want to have a string to store and throw at the user, then you can just use the bare field name.

In other words, we take what we have now (which works for a non-internationalized case where everyone just assumes a common language/script), and we augment it with features that let it be smarter if you want it to be smarter. Make the simple case simple, make the complicated case possible.

 -- Justin

 

On 03/14/2013 10:47 AM, George Fletcher wrote:

As a simplifying option... why not just require human-readable fields to require a "script-tag". This way it is always explicit what language/locale the text is for. It then becomes the responsibility of the AS to return an appropriate response if there is not a direct match between a request and the data stored at the AS (and out of scope of the spec).

Thanks,
George

On 3/13/13 10:22 AM, Justin Richer wrote:

So with what little feedback I've gotten, I'm proposing to add text from the proposed webfinger and OIDC drafts for the hash-based localization of strings, with the following properties:

* All localized versions of fields are fully optional on both client and server
* If a localized version of a field is included, its bare-value (perhaps internationalized) field MUST be included
* All human-readable fields are eligible for this mechanism (including any uri's for user-facing web pages, which can be used to point to language-specific pages)
* Clients and servers can decide to use whatever language/script they want to for the bare-value field, and no assumptions can be made on either side about what that is

I think that with these constraints, we can add functionality to address Stephen's concerns without getting too complicated or putting too much burden of support.

 -- Justin

On 03/11/2013 06:52 PM, Nat Sakimura wrote:

Similar work is in progress at Webfinger. 

 

 

Paul is proposing the same syntax as Connect. 

2013/3/12 Richer, Justin P. <jricher@mitre.org>

It does presume a definition of "claim", which I suppose we could turn to "metadata field" for DynReg and its extensions to be appropriately limiting. But we also need a good definition of what a language-tag-less field means, and whether or not it's required if the other fields are present or not (which is something that Connect is trying to fix at the moment, as I recall from last week). 

 

So it turns into about a paragraph worth of text. Is that worth it? I'm not entirely convinced that it is, but I'm interested to hear what others think, particularly those who *aren't* tied into the OpenID Connect protocol so much. (I don't want to pick a solution just because it's familiar, if we need a solution at all.)

 

 -- Justin

 

On Mar 11, 2013, at 6:35 PM, Brian Campbell <bcampbell@pingidentity.com>

 wrote:

 

A fair question but what would need to be pulled in is really probably only a couple sentences (and reference) from http://openid.net/specs/openid-connect-messages-1_0-16.html#ClaimsLanguagesAndScripts (note the reference to 2.1.1.1.3 inside http://openid.net/specs/openid-connect-registration-1_0-15.html is broken)

 

On Mon, Mar 11, 2013 at 6:26 PM, Richer, Justin P. <jricher@mitre.org> wrote:

My concern with this is that OIDC can get away with defining this multi-language structure because it defines the mechanism once (in Messages) and applies it to all user-readable strings throughout the whole application protocol, of which there are several. Do we really want to pull in that whole structure and mechanism for one field in client registration? I really don't think it should be something that's defined completely inside of DynReg for a corner case for a single field, but I also doubt we want to normatively point to OIDC Messages for this solution either.

 

There are also other ways to do this: Webfinger [1] for instance uses JSON structures to give language tags to field values, and has a default mechanism:

 

   { "en_us": "my client", $B!D(B }

 

The fundamental question is  this: should a client be able to register multiple names (in different locales) with a single client_id, or should it get a different client_id for each display language set?

 

 -- Justin

 

 

On Mar 11, 2013, at 5:54 PM, John Bradley <ve7jtb@ve7jtb.com>

 wrote:

 

That is what I was thinking.   It would be up to the AS to determine what language and script to present based on the user preference.

 

While a large number of clients will be native and might be able to customize themselves for a single user during registration , we don't want to forget the web server clients that are multi user.

 

On 2013-03-11, at 10:49 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:

 

FWIW, the closely related OpenID Connect client registration draft does have some support for doing this, which could maybe be borrowed. See client_name in $B!x(B2 at http://openid.net/specs/openid-connect-registration-1_0-15.html#client-metadata and the examples.
 

   "client_name": "My Example",
   "client_name#ja-Jpan-JP":"$B%/%i%$%"%s%HL>(B",

 

 

On Mon, Mar 11, 2013 at 5:15 PM, Richer, Justin P. <jricher@mitre.org> wrote:

It was brought up at the in-person meeting today that we'll want to consider issues around internationalization and localization of human-readable fields like client_name in the client registration. Which is to say: if a client supports ten languages and wants to present itself in ten languages, should it have to register itself ten times with an AS?

At the moment, I'm of the opinion a client with ten languages could register itself ten times, or do something with the context in which it runs to determine which human-facing language to use. Keep in mind that in some cases (such as native clients), you'll be dynamically registering a client for each user, in effect. In other words, I personally think that this is a rathole that will cause more harm than good.

 -- Justin
_______________________________________________
OAuth mailing 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



 

--
Nat Sakimura (=nat)

Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en




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

 

 

 

 




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


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




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



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

--------------040609040300090105020807-- From jricher@mitre.org Mon Mar 25 08:32: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 1C87E21F8FD6 for ; Mon, 25 Mar 2013 08:32:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.948 X-Spam-Level: X-Spam-Status: No, score=-5.948 tagged_above=-999 required=5 tests=[AWL=0.650, 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 NhT17wrFiRYx for ; Mon, 25 Mar 2013 08:32:16 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id E4B0421F8FD3 for ; Mon, 25 Mar 2013 08:32:12 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C570C1F0459; Mon, 25 Mar 2013 11:32:10 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id B5CF81F045C; Mon, 25 Mar 2013 11:32:10 -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, 25 Mar 2013 11:31:45 -0400 Message-ID: <51506D9F.7090705@mitre.org> Date: Mon, 25 Mar 2013 11:30:39 -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: Brian Campbell References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------000809010702010009010305" X-Originating-IP: [129.83.31.58] Cc: oauth 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: Mon, 25 Mar 2013 15:32:17 -0000 --------------000809010702010009010305 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit This approach is what we've implemented in a few places, most notably on the hReader iOS app (code is in some branch or fork of https://github.com/projecthreader/hReader, I'm told it's going to be pulled into that main branch soon though). Here we pre-register the hReader app with a single redirect URI of hreader://oauth (or something along those lines) and use that as the callback. We also use the system browser as opposed to embedding a web form view, as there are several potential security and usability problems when using an embedded browser that range from loss of session management to the embedded browser leaking the credentials to the client app (which is exactly what OAuth is trying to avoid, after all). -- Justin On 03/25/2013 07:51 AM, Brian Campbell wrote: > This little presentation from last year talks about OAuth & mobile. In > a nutshell, it discusses using the authorization code grant and a > redirect uri with a custom scheme. > > http://www.slideshare.net/briandavidcampbell/is-that-a-token-in-your-phone-in-your-pocket-or-are-you-just-glad-to-see-me-oauth-20-and-mobile-devices > > > On Sun, Mar 24, 2013 at 1:47 PM, Security Developer > > wrote: > > Hi, > > Can any body please help in describing the OAuth flow for mobile > applications? > > Thanks for your time. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------000809010702010009010305 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit This approach is what we've implemented in a few places, most notably on the hReader iOS app (code is in some branch or fork of https://github.com/projecthreader/hReader, I'm told it's going to be pulled into that main branch soon though). Here we pre-register the hReader app with a single redirect URI of hreader://oauth (or something along those lines) and use that as the callback. We also use the system browser as opposed to embedding a web form view, as there are several potential security and usability problems when using an embedded browser that range from loss of session management to the embedded browser leaking the credentials to the client app (which is exactly what OAuth is trying to avoid, after all).

 -- Justin



On 03/25/2013 07:51 AM, Brian Campbell wrote:
This little presentation from last year talks about OAuth & mobile. In a nutshell, it discusses using the authorization code grant and a redirect uri with a custom scheme.

http://www.slideshare.net/briandavidcampbell/is-that-a-token-in-your-phone-in-your-pocket-or-are-you-just-glad-to-see-me-oauth-20-and-mobile-devices


On Sun, Mar 24, 2013 at 1:47 PM, Security Developer <security.developer22@gmail.com> wrote:
Hi,

Can any body please help in describing the OAuth flow for mobile applications?

Thanks for your time.

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




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

--------------000809010702010009010305-- From Michael.Jones@microsoft.com Mon Mar 25 11:14: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 BBB7321F9430 for ; Mon, 25 Mar 2013 11:14:24 -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 fN9NwyM1gLKG for ; Mon, 25 Mar 2013 11:14:23 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0209.outbound.protection.outlook.com [207.46.163.209]) by ietfa.amsl.com (Postfix) with ESMTP id 22BAE21F94FF for ; Mon, 25 Mar 2013 11:14:22 -0700 (PDT) Received: from BL2FFO11FD005.protection.gbl (10.1.15.204) by BY2FFO11HUB019.protection.gbl (10.1.14.178) with Microsoft SMTP Server (TLS) id 15.0.651.3; Mon, 25 Mar 2013 18:08:36 +0000 Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD005.mail.protection.outlook.com (10.173.161.1) with Microsoft SMTP Server (TLS) id 15.0.651.3 via Frontend Transport; Mon, 25 Mar 2013 18:08:36 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.224]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.02.0318.003; Mon, 25 Mar 2013 18:08:06 +0000 From: Mike Jones To: Justin Richer , "Manger, James H" Thread-Topic: [OAUTH-WG] Registration: Internationalization of Human-Readable names Thread-Index: AQHOJmACY5HOQV9nDkW4sYSziV3/rJiw8IwAgAWY1wCAADBbYA== Date: Mon, 25 Mar 2013 18:08:05 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943675881FE@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <1B4C0C9F-4B8E-4B2D-BAF7-665D3EBBE56C@ve7jtb.com> <51408B8B.9000800@mitre.org> <5141E2E6.9020701@aol.com> <5141E671.2050708@mitre.org> <4E1F6AAD24975D4BA5B16804296739436750F5E2@TK5EX14MBXC283.redmond.corp.microsoft.com>, <5149F092.7070902@mitre.org> <4E1F6AAD24975D4BA5B168042967394367565FEF@TK5EX14MBXC283.redmond.corp.microsoft.com> <5149F534.1040500@mitre.org> <4E1F6AAD24975D4BA5B168042967394367567185@TK5EX14MBXC283.redmond.corp.microsoft.com> <514B4E28.7000309@mitre.org> <255B9BB34FB7D647A506DC292726F6E1150BD3FB27@WSMSG3153V.srv.dir.telstra.com> <51506934.4080104@mitre.org> In-Reply-To: <51506934.4080104@mitre.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.78] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943675881FETK5EX14MBXC283r_" 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)(53806001)(56776001)(79102001)(44976002)(47736001)(71186001)(74662001)(33656001)(54356001)(74502001)(76482001)(59766001)(69226001)(63696002)(47976001)(50986001)(54316002)(66066001)(20776003)(77982001)(16406001)(46102001)(65816001)(80022001)(49866001)(31966008)(56816002)(4396001)(51856001)(55846006)(512874001)(47446002); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB019; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0796EBEDE1 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readable names X-BeenThere: oauth@ietf.org X-Mailman-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, 25 Mar 2013 18:14:25 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943675881FETK5EX14MBXC283r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RllJLCB0aGUgZm9sbG93aW5nIHZlcnNpb24gb2YgdGhpcyB3b3JkaW5nIHdhcyBpbmNvcnBvcmF0 ZWQgaW50byB0aGUgT3BlbklEIENvbm5lY3QgUmVnaXN0cmF0aW9uIHNwZWMuICBJIGFsc28gZm91 bmQgdGhlIHBocmFzZSDigJxpbnRlcm5hdGlvbmFsaXplZCBVVEYtOCBzdHJpbmfigJ0gYW1iaWd1 b3VzIGFuZCBzbyByZXZpc2VkIGl0LiAgQWxzbywgVVRGLTggaXMganVzdCBwbGFpbiB3cm9uZywg YXMgb25jZSB5b3XigJlyZSBpbiBKU09OIHlvdeKAmXJlIGp1c3QgZGVhbGluZyB3aXRoIFVuaWNv ZGUgc3RyaW5ncywgd2hldGhlciB0aGV5IHdlcmUgb3JpZ2luYWxseSBlbmNvZGVkIGluIFVURi04 LCBVVEYtMTYsIG9yIGFub3RoZXIgZW5jb2RpbmcgYmVmb3JlIHBhcnNpbmcuDQoNCkh1bWFuLXJl YWRhYmxlIENsaWVudCBNZXRhZGF0YSB2YWx1ZXMgYW5kIENsaWVudCBNZXRhZGF0YSB2YWx1ZXMg dGhhdCByZWZlcmVuY2UgaHVtYW4tcmVhZGFibGUgdmFsdWVzIE1BWSBiZSByZXByZXNlbnRlZCBp biBtdWx0aXBsZSBsYW5ndWFnZXMgYW5kIHNjcmlwdHMuIEZvciBleGFtcGxlLCB2YWx1ZXMgc3Vj aCBhcyBjbGllbnRfbmFtZSwgdG9zX3VyaSwgcG9saWN5X3VyaSwgbG9nb191cmksIGFuZCBjbGll bnRfdXJpIG1pZ2h0IGhhdmUgbXVsdGlwbGUgbG9jYWxlLXNwZWNpZmljIHZhbHVlcyBpbiBzb21l IENsaWVudCByZWdpc3RyYXRpb25zLg0KDQrigKYNCg0KSWYgc3VjaCBhIGh1bWFuLXJlYWRhYmxl IGZpZWxkIGlzIHNlbnQgd2l0aG91dCBhIGxhbmd1YWdlIHRhZywgcGFydGllcyB1c2luZyBpdCBN VVNUIE5PVCBtYWtlIGFueSBhc3N1bXB0aW9ucyBhYm91dCB0aGUgbGFuZ3VhZ2UsIGNoYXJhY3Rl ciBzZXQsIG9yIHNjcmlwdCBvZiB0aGUgc3RyaW5nIHZhbHVlLCBhbmQgdGhlIHN0cmluZyB2YWx1 ZSBNVVNUIGJlIHVzZWQgYXMtaXMgd2hlcmV2ZXIgaXQgaXMgcHJlc2VudGVkIGluIGEgdXNlciBp bnRlcmZhY2UuIFRvIGZhY2lsaXRhdGUgaW50ZXJvcGVyYWJpbGl0eSwgaXQgaXMgUkVDT01NRU5E RUQgdGhhdCBhbnkgaHVtYW4tcmVhZGFibGUgZmllbGRzIHNlbnQgd2l0aG91dCBsYW5ndWFnZSB0 YWdzIGNvbnRhaW4gdmFsdWVzIHN1aXRhYmxlIGZvciBkaXNwbGF5IG9uIGEgd2lkZSB2YXJpZXR5 IG9mIHN5c3RlbXMuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIEJlc3Qgd2lzaGVzLA0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBvYXV0 aC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIEp1c3RpbiBSaWNoZXINClNlbnQ6IE1vbmRheSwgTWFyY2ggMjUsIDIwMTMgODoxMiBB TQ0KVG86IE1hbmdlciwgSmFtZXMgSA0KQ2M6IG9hdXRoQGlldGYub3JnIFdHDQpTdWJqZWN0OiBS ZTogW09BVVRILVdHXSBSZWdpc3RyYXRpb246IEludGVybmF0aW9uYWxpemF0aW9uIG9mIEh1bWFu LVJlYWRhYmxlIG5hbWVzDQoNCiJJbnRlcm5hdGlvbmFsaXphdGlvbiBpcyB0aGUgcHJvY2VzcyBv ZiBkZXNpZ25pbmcgYSBzb2Z0d2FyZSBhcHBsaWNhdGlvbiBzbyB0aGF0IGl0IGNhbiBiZSBhZGFw dGVkIHRvIHZhcmlvdXMgbGFuZ3VhZ2VzIGFuZCByZWdpb25zIHdpdGhvdXQgZW5naW5lZXJpbmcg Y2hhbmdlcy4iIChGcm9tIGh0dHA6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvSW50ZXJuYXRpb25h bGl6YXRpb25fYW5kX2xvY2FsaXphdGlvbikNCg0KV2hhdCB0aGlzIG1lYW5zIGluIG91ciBjYXNl IGlzIHRoYXQgeW91J2Qgd2FudCBhIHN0cmluZyB0aGF0IHdvdWxkIGJlIHVzYWJsZSBvbiB0aGUg d2lkZXN0IHZhcmlldHkgb2Ygc3lzdGVtcyB0aGF0IHlvdSBjYXJlIGFib3V0IHdpdGhvdXQgdGhl bSBoYXZpbmcgdG8gZG8gc29tZXRoaW5nIHNwZWNpYWwgdG8gaGFuZGxlIGl0LiBGb3Igc29tZSwg dGhhdCdzIGdvaW5nIHRvIG1lYW4gQVNDSUkuIEZvciBvdGhlcnMsIGl0J3MgZ29pbmcgdG8gbWVh biBzb21lIGNvbW1vbiBsb2NhbCBzY3JpcHQuDQoNCkFuZCB5ZXMsIHRoZSAjIGNoYXJhY3RlciBp cyBhcHBlbmRlZCB0byB0aGUgZmllbGQgbmFtZSwgZ29vZCBjYXRjaC4NCg0KIC0tIEp1c3Rpbg0K DQpPbiAwMy8yMS8yMDEzIDA5OjQzIFBNLCBNYW5nZXIsIEphbWVzIEggd3JvdGU6DQpXaGF0IGlz IGFuIOKAnGludGVybmF0aW9uYWxpemVkIFVURi04IHN0cmluZ+KAnT8NCg0KUC5TLiBJdCB3b3Vs ZCBiZSB3b3J0aCBleHBsaWNpdGx5IHN0YXRpbmcgdGhhdCB0aGUgIyBjaGFyYWN0ZXIgYW5kIFJG QzU2NDYgbGFuZ3VhZ2UgdGFnIGFyZSBhcHBlbmRlZCAqdG8gdGhlIGZpZWxkIG5hbWUqIChub3Qg dGhlIHZhbHVlKS4gSSBhc3N1bWUgdGhpcyBpcyByaWdodC4NCg0KLS0NCkphbWVzIE1hbmdlcg0K DQpGcm9tOiBvYXV0aC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYu b3JnPiBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKdXN0aW4g UmljaGVyDQpTZW50OiBGcmlkYXksIDIyIE1hcmNoIDIwMTMgNToxNSBBTQ0KVG86IG9hdXRoQGll dGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4gV0cNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0dd IFJlZ2lzdHJhdGlvbjogSW50ZXJuYXRpb25hbGl6YXRpb24gb2YgSHVtYW4tUmVhZGFibGUgbmFt ZXMNCg0KV2UgZGlzY3Vzc2VkIHRoaXMgaXNzdWUgb24gdGhlIE9wZW5JRCBDb25uZWN0IFdHIGNh bGwgdGhpcyBtb3JuaW5nLCBpbiBhIGNvbnZlcnNhdGlvbiB0aGF0IGluY2x1ZGVkIG15c2VsZiwg R2VvcmdlIEZsZXRjaGVyLCBOYXQgU2FraW11cmEsIE1pa2UgSm9uZXMsIGFuZCBKb2huIEJyYWRs ZXkgKGFtb25nIG90aGVycykgYXMgYWN0aXZlIHBhcnRpY2lwYW50cyBpbiB0aGlzIHRocmVhZC4g QWZ0ZXIgbG90cyBvZiBkZWJhdGUsIHdlIHByb3Bvc2UgdGhhdCB0aGUgT0F1dGggRHluUmVnIGFk b3B0IHRoZSBoYXNodGFnLWJhc2VkIGxvY2FsaXphdGlvbiBtZXRob2Qgb2YgT0lEQyAoYW5kIGl0 IHNlZW1zLCBwb3NzaWJseSB3ZWJmaW5nZXIpIGFuZCBleHBsaWNpdGx5IGRlY2xhcmUgdGhhdCBu ZWl0aGVyIHRoZSBjbGllbnQgbm9yIHRoZSBzZXJ2ZXIgbWFrZSBhbnkgYXNzdW1wdGlvbnMgYWJv dXQgdGhlIGNvbnRlbnQgb2YgdGhlIHN0cmluZyBhbmQgdHJlYXQgaXQgYXMganVzdCBhIHN0cmlu Zy4gSSdtIHByb3Bvc2luZyB0aGlzIHRleHQgdG8gdGhhdCBlZmZlY3QgKHdpdGggdGhlIHJlZmVy ZW5jZXMgdG8gT0lEQy1tZXNzYWdlcyByZW1vdmVkIGFuZCByZXBsYWNlZCB3aXRoIHRoZSBydWxl IGRlc2NyaXB0aW9uIGl0c2VsZiBpbiBPQXV0aCBEeW5SZWcpOg0KRmllbGRzIHdpdGggaHVtYW4t cmVhZGFibGUgdmFsdWVzIG9yIHJlZmVyZW5jZXMgdG8gaHVtYW4tcmVhZGFibGUgdmFsdWVzLCBz dWNoIGFzIGNsaWVudF9uYW1lLCB0b3NfdXJpLCBwb2xpY3lfdXJpLCBhbmQgY2xpZW50X3VyaSwg TUFZIGJlIHJlcHJlc2VudGVkIGluIG11bHRpcGxlIGxhbmd1YWdlcyBhbmQgc2NyaXB0cywgc3Bl Y2lmaWVkIGJ5IGFwcGVuZGluZyBhICMgY2hhcmFjdGVyIGFuZCB0aGUgUkZDNTY0NiBsYW5ndWFn ZSB0YWcuIElmIGFueSBzdWNoIGh1bWFuLXJlYWRhYmxlIGZpZWxkIGlzIHNlbnQgd2l0aG91dCBh IGxhbmd1YWdlIHRhZywgdGhlIHNlcnZlciBhbmQgdGhlIGNsaWVudCBNVVNUIE5PVCBtYWtlIGFu eSBhc3N1bXB0aW9ucyBhYm91dCB0aGUgbGFuZ3VhZ2UsIGNoYXJhY3RlciBzZXQsIG9yIHNjcmlw dCBvZiB0aGUgdmFsdWUgc3RyaW5nLCBhbmQgdGhlIHZhbHVlIHN0cmluZyBNVVNUIGJlIHVzZWQg YXMtaXMgd2hlcmV2ZXIgaXQgaXMgcHJlc2VudGVkIGluIGVpdGhlciB0aGUgY2xpZW50IG9yIHNl cnZlciBVSS4gVG8gZmFjaWxpdGF0ZSBpbnRlcm9wZXJhYmlsaXR5LCBpdCBpcyBSRUNPTU1FTkRF RCB0aGF0IGFueSBmaWVsZHMgc2VudCB3aXRob3V0IGxhbmd1YWdlIHRhZ3MgY29udGFpbiBhbiBp bnRlcm5hdGlvbmFsaXplZCBVVEYtOCBzdHJpbmcgc3VpdGFibGUgZm9yIGRpc3BsYXkgb24gYSB3 aWRlIHZhcmlldHkgb2Ygc3lzdGVtcywgYW5kIGl0IGlzIFJFQ09NTUVOREVEIHRoYXQgY2xpZW50 cyBzZW5kIGZpZWxkcyB3aXRob3V0IGxhbmd1YWdlIHRhZ3MgaW4gYWRkaXRpb24gdG8gYW55IG1v cmUtc3BlY2lmaWNhbGx5IGRlbm9taW5hdGVkIHZhbHVlcy4NCg0KUGx1cyBzb21lIGV4YW1wbGVz Lg0KDQooQW55b25lIHdob3NlIG5hbWUgSSB0b29rIGluIHZhaW4sIHBsZWFzZSBmZWVsIGZyZWUg dG8gY29ycmVjdCBtZS4pDQoNCiAtLSBKdXN0aW4NCg0K --_000_4E1F6AAD24975D4BA5B1680429673943675881FETK5EX14MBXC283r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Ik1TIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiTVMgR290aGljIjsNCglwYW5vc2UtMToyIDExIDYgOSA3IDIgNSA4 IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJ cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJNUyBQR290aGljIjsNCglwYW5vc2UtMToyIDExIDYgMCA3IDIgNSA4 IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1TIEdvdGhpYyI7DQoJcGFub3Nl LTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBN UyBQR290aGljIjsNCglwYW5vc2UtMToyIDExIDYgMCA3IDIgNSA4IDIgNDt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJNUyBQR290aGljIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6YmxhY2s7 fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ Y29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bh bi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJ bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsN Cglmb250LWZhbWlseToiTVMgR290aGljIjsNCgljb2xvcjpibGFjazt9DQpwLk1zb0FjZXRhdGUs IGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFo b21hIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVk Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJ Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5CYWxsb29uVGV4dENo YXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6 IlRhaG9tYSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnAubXNvY2hwZGVmYXVsdCwg bGkubXNvY2hwZGVmYXVsdCwgZGl2Lm1zb2NocGRlZmF1bHQNCgl7bXNvLXN0eWxlLW5hbWU6bXNv Y2hwZGVmYXVsdDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGlu Ow0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJNUyBQR290aGljIiwic2Fucy1zZXJpZiI7DQoJ Y29sb3I6YmxhY2s7fQ0Kc3Bhbi5odG1scHJlZm9ybWF0dGVkY2hhcjANCgl7bXNvLXN0eWxlLW5h bWU6aHRtbHByZWZvcm1hdHRlZGNoYXI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJY29sb3I6 YmxhY2s7fQ0Kc3Bhbi5lbWFpbHN0eWxlMTkNCgl7bXNvLXN0eWxlLW5hbWU6ZW1haWxzdHlsZTE5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9 DQpzcGFuLkVtYWlsU3R5bGUyNA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFp bFN0eWxlMjUNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTI2DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4w aW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxl PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+ DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5GWUksIHRoZSBmb2xs b3dpbmcgdmVyc2lvbiBvZiB0aGlzIHdvcmRpbmcgd2FzIGluY29ycG9yYXRlZCBpbnRvIHRoZSBP cGVuSUQgQ29ubmVjdCBSZWdpc3RyYXRpb24gc3BlYy4mbmJzcDsgSSBhbHNvIGZvdW5kIHRoZSBw aHJhc2Ug4oCcaW50ZXJuYXRpb25hbGl6ZWQgVVRGLTggc3RyaW5n4oCdDQogYW1iaWd1b3VzIGFu ZCBzbyByZXZpc2VkIGl0LiZuYnNwOyBBbHNvLCBVVEYtOCBpcyBqdXN0IHBsYWluIHdyb25nLCBh cyBvbmNlIHlvdeKAmXJlIGluIEpTT04geW914oCZcmUganVzdCBkZWFsaW5nIHdpdGggVW5pY29k ZSBzdHJpbmdzLCB3aGV0aGVyIHRoZXkgd2VyZSBvcmlnaW5hbGx5IGVuY29kZWQgaW4gVVRGLTgs IFVURi0xNiwgb3IgYW5vdGhlciBlbmNvZGluZyBiZWZvcmUgcGFyc2luZy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IdW1hbi1yZWFkYWJsZSBDbGllbnQgTWV0YWRhdGEgdmFs dWVzIGFuZCBDbGllbnQgTWV0YWRhdGEgdmFsdWVzIHRoYXQgcmVmZXJlbmNlIGh1bWFuLXJlYWRh YmxlIHZhbHVlcyBNQVkgYmUgcmVwcmVzZW50ZWQgaW4gbXVsdGlwbGUNCiBsYW5ndWFnZXMgYW5k IHNjcmlwdHMuIEZvciBleGFtcGxlLCB2YWx1ZXMgc3VjaCBhcyBjbGllbnRfbmFtZSwgdG9zX3Vy aSwgcG9saWN5X3VyaSwgbG9nb191cmksIGFuZCBjbGllbnRfdXJpIG1pZ2h0IGhhdmUgbXVsdGlw bGUgbG9jYWxlLXNwZWNpZmljIHZhbHVlcyBpbiBzb21lIENsaWVudCByZWdpc3RyYXRpb25zLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij7igKY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+SWYgc3VjaCBhIGh1bWFuLXJlYWRhYmxlIGZpZWxkIGlzIHNlbnQgd2l0aG91dCBh IGxhbmd1YWdlIHRhZywgcGFydGllcyB1c2luZyBpdCBNVVNUIE5PVCBtYWtlIGFueSBhc3N1bXB0 aW9ucyBhYm91dCB0aGUgbGFuZ3VhZ2UsIGNoYXJhY3Rlcg0KIHNldCwgb3Igc2NyaXB0IG9mIHRo ZSBzdHJpbmcgdmFsdWUsIGFuZCB0aGUgc3RyaW5nIHZhbHVlIE1VU1QgYmUgdXNlZCBhcy1pcyB3 aGVyZXZlciBpdCBpcyBwcmVzZW50ZWQgaW4gYSB1c2VyIGludGVyZmFjZS4gVG8gZmFjaWxpdGF0 ZSBpbnRlcm9wZXJhYmlsaXR5LCBpdCBpcyBSRUNPTU1FTkRFRCB0aGF0IGFueSBodW1hbi1yZWFk YWJsZSBmaWVsZHMgc2VudCB3aXRob3V0IGxhbmd1YWdlIHRhZ3MgY29udGFpbiB2YWx1ZXMgc3Vp dGFibGUgZm9yDQogZGlzcGxheSBvbiBhIHdpZGUgdmFyaWV0eSBvZiBzeXN0ZW1zLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IEJlc3Qgd2lzaGVzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndp bmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjp3aW5kb3d0ZXh0Ij4gb2F1dGgtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm9hdXRoLWJvdW5j ZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkp1c3RpbiBSaWNoZXI8YnI+DQo8Yj5T ZW50OjwvYj4gTW9uZGF5LCBNYXJjaCAyNSwgMjAxMyA4OjEyIEFNPGJyPg0KPGI+VG86PC9iPiBN YW5nZXIsIEphbWVzIEg8YnI+DQo8Yj5DYzo8L2I+IG9hdXRoQGlldGYub3JnIFdHPGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIFJlZ2lzdHJhdGlvbjogSW50ZXJuYXRpb25hbGl6 YXRpb24gb2YgSHVtYW4tUmVhZGFibGUgbmFtZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPiZxdW90O0lu dGVybmF0aW9uYWxpemF0aW9uIGlzIHRoZSBwcm9jZXNzIG9mIGRlc2lnbmluZyBhIHNvZnR3YXJl IGFwcGxpY2F0aW9uIHNvIHRoYXQgaXQgY2FuIGJlIGFkYXB0ZWQgdG8gdmFyaW91cyBsYW5ndWFn ZXMgYW5kIHJlZ2lvbnMgd2l0aG91dCBlbmdpbmVlcmluZyBjaGFuZ2VzLiZxdW90OyAoRnJvbQ0K PGEgaHJlZj0iaHR0cDovL2VuLndpa2lwZWRpYS5vcmcvd2lraS9JbnRlcm5hdGlvbmFsaXphdGlv bl9hbmRfbG9jYWxpemF0aW9uIj5odHRwOi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL0ludGVybmF0 aW9uYWxpemF0aW9uX2FuZF9sb2NhbGl6YXRpb248L2E+KTxicj4NCjxicj4NCldoYXQgdGhpcyBt ZWFucyBpbiBvdXIgY2FzZSBpcyB0aGF0IHlvdSdkIHdhbnQgYSBzdHJpbmcgdGhhdCB3b3VsZCBi ZSB1c2FibGUgb24gdGhlIHdpZGVzdCB2YXJpZXR5IG9mIHN5c3RlbXMgdGhhdCB5b3UgY2FyZSBh Ym91dCB3aXRob3V0IHRoZW0gaGF2aW5nIHRvIGRvIHNvbWV0aGluZyBzcGVjaWFsIHRvIGhhbmRs ZSBpdC4gRm9yIHNvbWUsIHRoYXQncyBnb2luZyB0byBtZWFuIEFTQ0lJLiBGb3Igb3RoZXJzLCBp dCdzIGdvaW5nIHRvIG1lYW4NCiBzb21lIGNvbW1vbiBsb2NhbCBzY3JpcHQuPGJyPg0KPGJyPg0K QW5kIHllcywgdGhlICMgY2hhcmFjdGVyIGlzIGFwcGVuZGVkIHRvIHRoZSBmaWVsZCBuYW1lLCBn b29kIGNhdGNoLjxicj4NCjxicj4NCiZuYnNwOy0tIEp1c3Rpbjxicj4NCjxicj4NCjxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDAzLzIxLzIwMTMgMDk6NDMg UE0sIE1hbmdlciwgSmFtZXMgSCB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+V2hhdCBpcyBhbiDigJxpbnRlcm5hdGlvbmFsaXplZCBVVEYtOCBzdHJpbmfigJ0/PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5QLlMuIEl0IHdvdWxkIGJlIHdvcnRoIGV4cGxpY2l0bHkgc3RhdGluZyB0aGF0IHRoZSAj IGNoYXJhY3RlciBhbmQgUkZDNTY0NiBsYW5ndWFnZSB0YWcgYXJlIGFwcGVuZGVkICo8Yj50byB0 aGUgZmllbGQgbmFtZTwvYj4qIChub3QgdGhlIHZhbHVlKS4gSSBhc3N1bWUgdGhpcw0KIGlzIHJp Z2h0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi0tPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkph bWVzIE1hbmdlcjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRp bmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPg0KPGEgaHJlZj0ibWFpbHRv Om9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciPm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IFs8YSBo cmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOm9hdXRoLWJvdW5jZXNA aWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5KdXN0aW4gUmljaGVyPGJyPg0KPGI+ U2VudDo8L2I+IEZyaWRheSwgMjIgTWFyY2ggMjAxMyA1OjE1IEFNPGJyPg0KPGI+VG86PC9iPiA8 YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYub3JnPC9hPiBXRzxicj4N CjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBSZWdpc3RyYXRpb246IEludGVybmF0aW9u YWxpemF0aW9uIG9mIEh1bWFuLVJlYWRhYmxlIG5hbWVzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5XZSBk aXNjdXNzZWQgdGhpcyBpc3N1ZSBvbiB0aGUgT3BlbklEIENvbm5lY3QgV0cgY2FsbCB0aGlzIG1v cm5pbmcsIGluIGEgY29udmVyc2F0aW9uIHRoYXQgaW5jbHVkZWQgbXlzZWxmLCBHZW9yZ2UgRmxl dGNoZXIsIE5hdCBTYWtpbXVyYSwgTWlrZSBKb25lcywgYW5kIEpvaG4gQnJhZGxleSAoYW1vbmcg b3RoZXJzKSBhcyBhY3RpdmUgcGFydGljaXBhbnRzIGluDQogdGhpcyB0aHJlYWQuIEFmdGVyIGxv dHMgb2YgZGViYXRlLCB3ZSBwcm9wb3NlIHRoYXQgdGhlIE9BdXRoIER5blJlZyBhZG9wdCB0aGUg aGFzaHRhZy1iYXNlZCBsb2NhbGl6YXRpb24gbWV0aG9kIG9mIE9JREMgKGFuZCBpdCBzZWVtcywg cG9zc2libHkgd2ViZmluZ2VyKSBhbmQgZXhwbGljaXRseSBkZWNsYXJlIHRoYXQgbmVpdGhlciB0 aGUgY2xpZW50IG5vciB0aGUgc2VydmVyIG1ha2UgYW55IGFzc3VtcHRpb25zIGFib3V0IHRoZSBj b250ZW50DQogb2YgdGhlIHN0cmluZyBhbmQgdHJlYXQgaXQgYXMganVzdCBhIHN0cmluZy4gSSdt IHByb3Bvc2luZyB0aGlzIHRleHQgdG8gdGhhdCBlZmZlY3QgKHdpdGggdGhlIHJlZmVyZW5jZXMg dG8gT0lEQy1tZXNzYWdlcyByZW1vdmVkIGFuZCByZXBsYWNlZCB3aXRoIHRoZSBydWxlIGRlc2Ny aXB0aW9uIGl0c2VsZiBpbiBPQXV0aCBEeW5SZWcpOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+RmllbGRzIHdpdGggaHVtYW4tcmVhZGFibGUgdmFsdWVzIG9yIHJlZmVyZW5j ZXMgdG8gaHVtYW4tcmVhZGFibGUgdmFsdWVzLCBzdWNoIGFzIGNsaWVudF9uYW1lLCB0b3NfdXJp LCBwb2xpY3lfdXJpLCBhbmQgY2xpZW50X3VyaSwgTUFZIGJlIHJlcHJlc2VudGVkIGluIG11bHRp cGxlIGxhbmd1YWdlcyBhbmQgc2NyaXB0cywgc3BlY2lmaWVkIGJ5IGFwcGVuZGluZyBhICMgY2hh cmFjdGVyIGFuZCB0aGUgUkZDNTY0Ng0KIGxhbmd1YWdlIHRhZy4gSWYgYW55IHN1Y2ggaHVtYW4t cmVhZGFibGUgZmllbGQgaXMgc2VudCB3aXRob3V0IGEgbGFuZ3VhZ2UgdGFnLCB0aGUgc2VydmVy IGFuZCB0aGUgY2xpZW50IE1VU1QgTk9UIG1ha2UgYW55IGFzc3VtcHRpb25zIGFib3V0IHRoZSBs YW5ndWFnZSwgY2hhcmFjdGVyIHNldCwgb3Igc2NyaXB0IG9mIHRoZSB2YWx1ZSBzdHJpbmcsIGFu ZCB0aGUgdmFsdWUgc3RyaW5nIE1VU1QgYmUgdXNlZCBhcy1pcyB3aGVyZXZlciBpdCBpcw0KIHBy ZXNlbnRlZCBpbiBlaXRoZXIgdGhlIGNsaWVudCBvciBzZXJ2ZXIgVUkuIFRvIGZhY2lsaXRhdGUg aW50ZXJvcGVyYWJpbGl0eSwgaXQgaXMgUkVDT01NRU5ERUQgdGhhdCBhbnkgZmllbGRzIHNlbnQg d2l0aG91dCBsYW5ndWFnZSB0YWdzIGNvbnRhaW4gYW4gaW50ZXJuYXRpb25hbGl6ZWQgVVRGLTgg c3RyaW5nIHN1aXRhYmxlIGZvciBkaXNwbGF5IG9uIGEgd2lkZSB2YXJpZXR5IG9mIHN5c3RlbXMs IGFuZCBpdCBpcyBSRUNPTU1FTkRFRCB0aGF0DQogY2xpZW50cyBzZW5kIGZpZWxkcyB3aXRob3V0 IGxhbmd1YWdlIHRhZ3MgaW4gYWRkaXRpb24gdG8gYW55IG1vcmUtc3BlY2lmaWNhbGx5IGRlbm9t aW5hdGVkIHZhbHVlcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KUGx1cyBzb21lIGV4YW1wbGVzLjxicj4NCjxi cj4NCihBbnlvbmUgd2hvc2UgbmFtZSBJIHRvb2sgaW4gdmFpbiwgcGxlYXNlIGZlZWwgZnJlZSB0 byBjb3JyZWN0IG1lLik8YnI+DQo8YnI+DQombmJzcDstLSBKdXN0aW48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90 OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_4E1F6AAD24975D4BA5B1680429673943675881FETK5EX14MBXC283r_-- From sm@resistor.net Mon Mar 25 12:07: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 81CFA21F8D32 for ; Mon, 25 Mar 2013 12:07:49 -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 OS8z-fIxsase for ; Mon, 25 Mar 2013 12:07:49 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id F258521F8C9A for ; Mon, 25 Mar 2013 12:07:48 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r2PJ7fn7023858; Mon, 25 Mar 2013 12:07:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1364238466; bh=zM6lhH3kHf+CTdJ5gaIsoic+E3PPcCnvucAxvUdT05w=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=nq9Dwi35FpEXUrBhjdoauMT7+pPPjpf/GISXCu6VntERp4dNphLWqpAh7IaTIfmb7 nQrNZXdovDLUEOJ3jTp5VrSi6h8+0VA9dAmEzI83CJj+qO0/jsb0BFZX2bWcp9H1Us 4jPEfhpwtoVZWl7dIbruqf9Mvlay9YVS19R/xChA= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1364238466; i=@resistor.net; bh=zM6lhH3kHf+CTdJ5gaIsoic+E3PPcCnvucAxvUdT05w=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=wfGT/yZfXRRadGBqxzHAUD3c0+YyH9PlzVOIvOxKuTjAvLhHIVFzo+iSQi9fPziO+ ZWzzdhImHbEvFZT487VE/4p5zQhJbC0xcOTWfXo8Z1Z5JNfYxdWe0dGy3+CfRMT/um 6+6mkd/L3aoCzgolnul+us8b8PzyN3N9TLQwzKMk= Message-Id: <6.2.5.6.2.20130325115645.0b4aac10@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 25 Mar 2013 12:06:57 -0700 To: Justin Richer From: SM In-Reply-To: <51506934.4080104@mitre.org> References: <1B4C0C9F-4B8E-4B2D-BAF7-665D3EBBE56C@ve7jtb.com> <51408B8B.9000800@mitre.org> <5141E2E6.9020701@aol.com> <5141E671.2050708@mitre.org> <4E1F6AAD24975D4BA5B16804296739436750F5E2@TK5EX14MBXC283.redmond.corp.microsoft.com> <5149F092.7070902@mitre.org> <4E1F6AAD24975D4BA5B168042967394367565FEF@TK5EX14MBXC283.redmond.corp.microsoft.com> <5149F534.1040500@mitre.org> <4E1F6AAD24975D4BA5B168042967394367567185@TK5EX14MBXC283.redmond.corp.microsoft.com> <514B4E28.7000309@mitre.org> <255B9BB34FB7D647A506DC292726F6E1150BD3FB27@WSMSG3153V.srv.dir.telstra.com> <51506934.4080104@mitre.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readable names X-BeenThere: oauth@ietf.org X-Mailman-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, 25 Mar 2013 19:07:49 -0000 Hi Justin, At 08:11 25-03-2013, Justin Richer wrote: >"Internationalization is the process of designing a software >application so that it can be adapted to various languages and >regions without engineering changes." (From There is some discussion about internationalization in RFC 6365. Regards, -sm From stpeter@stpeter.im Mon Mar 25 18:25: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 E230421F87FB for ; Mon, 25 Mar 2013 18:25:53 -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 i9ORBDxLqP1k for ; Mon, 25 Mar 2013 18:25:52 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id ADE2021F87F5 for ; Mon, 25 Mar 2013 18:25:52 -0700 (PDT) Received: from [192.168.1.6] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 22A2540520; Mon, 25 Mar 2013 19:35:08 -0600 (MDT) Message-ID: <5150F91B.1030603@stpeter.im> Date: Mon, 25 Mar 2013 19:25:47 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Mike Jones References: <51408B8B.9000800@mitre.org> <5141E2E6.9020701@aol.com> <5141E671.2050708@mitre.org> <4E1F6AAD24975D4BA5B16804296739436750F5E2@TK5EX14MBXC283.redmond.corp.microsoft.com>, <5149F092.7070902@mitre.org> <4E1F6AAD24975D4BA5B168042967394367565FEF@TK5EX14MBXC283.redmond.corp.microsoft.com> <5149F534.1040500@mitre.org> <4E1F6AAD24975D4BA5B168042967394367567185@TK5EX14MBXC283.redmond.corp.microsoft.com> <514B4E28.7000309@mitre.org> <255B9BB34FB7D647A506DC292726F6E1150BD3FB27@WSMSG3153V.srv.dir.telstra.com> <51506934.4080104@mitre.org> <4E1F6AAD24975D4BA5B1680429673943675881FE@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943675881FE@TK5EX14MBXC283.redmond.corp.microsoft.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readable names X-BeenThere: oauth@ietf.org X-Mailman-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, 26 Mar 2013 01:25:54 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 3/25/13 12:08 PM, Mike Jones wrote: > FYI, the following version of this wording was incorporated into > the OpenID Connect Registration spec. I also found the phrase > “internationalized UTF-8 string†ambiguous and so revised it. > Also, UTF-8 is just plain wrong, as once you’re in JSON you’re just > dealing with Unicode strings, whether they were originally encoded > in UTF-8, UTF-16, or another encoding before parsing. Mike and others, please read RFC 6365 at the very least to get some of the terminology right here. For example, a Unicode code point is simply a numbered point in a coded character set, say, U+03C0 (pi). That code point is the same thing no matter whether it is written on a piece of paper, mentioned in spoken text, etc. In an electronic representation on the wire or in a file, the code point MUST be encoded using something like UTF-8 (which we prefer in IETF protocols) or UTF-16 or whatever. So it is incorrect to say that "UTF-8 is just plain wrong, as once you’re in JSON you’re just dealing with Unicode strings". It doesn't work that way! Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRUPkaAAoJEOoGpJErxa2pJmUP/i4anZjL5pia4vJUA1RaY0Ht ec6ItzKGZROEsIPM9jucFvrKyFYnvJARWYHQloWdnv89CCe0XzgX9Kr7LoLJuu+8 AHOosP6NWwxM2TR5PLC0akYKdyPnC6zenEyd94fx2Q12LXGmIBN6g3upveqmjsKW EIk5VTQLV30tXIegmNbVZ6xbflw7rnXuRLc0HTTervAvQSTN9K4qVboDdFyiv3Si oahzfxaEIOHo1ErljK2UzEc5YS7pQjwlPevzL2bc84ZJmuf9SwTD6vLUEeps0tAO 6dRb3B5gs2RFryLQGJ3/M0E4RL+aWc4zVd7tbFh5wF72uUA2o2BwEE6vyMdfuKmn wgYtN9Tkxg9DlOQdfXg6FY5tk4mrWL/i1um1NXgTIy6b7loAZnD7yrliYWjtgBVf Kns+QZOGgO2mkwnkLPI2KwRHRgX4JnXeDZYS1Kcg9yscq/Pdkb+8BfkNbn40TO8M eEuq/mvvU3moAI3+TM6CbVJAwZqmVNsPiVv4M3tzA0lhgditq+rOHiQRvnoMwpzP NLUBu0AJJUs3fnqf+YlG6jCS6lIT9gw/HMCjt1VVzm+hA+ntp5hqRBdXI0xqLyiN LlYTI8W+BRPbnB9bhMX/KKgnvrKo/5zJZWmn1u/GztSapGP5cOr9w7DS/beYiC9K 5LgFphry8ahkTmR/BnD5 =UGRp -----END PGP SIGNATURE----- From stpeter@stpeter.im Mon Mar 25 18:30:52 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 D7D7F21F884B for ; Mon, 25 Mar 2013 18:30:52 -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 idNN6AXWUuQQ for ; Mon, 25 Mar 2013 18:30:52 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 05E6A21F8837 for ; Mon, 25 Mar 2013 18:30:52 -0700 (PDT) Received: from [192.168.1.6] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9BED040520; Mon, 25 Mar 2013 19:40:06 -0600 (MDT) Message-ID: <5150FA45.3090805@stpeter.im> Date: Mon, 25 Mar 2013 19:30:45 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Justin Richer References: <1B4C0C9F-4B8E-4B2D-BAF7-665D3EBBE56C@ve7jtb.com> <51408B8B.9000800@mitre.org> <5141E2E6.9020701@aol.com> <5141E671.2050708@mitre.org> <4E1F6AAD24975D4BA5B16804296739436750F5E2@TK5EX14MBXC283.redmond.corp.microsoft.com>, <5149F092.7070902@mitre.org> <4E1F6AAD24975D4BA5B168042967394367565FEF@TK5EX14MBXC283.redmond.corp.microsoft.com> <5149F534.1040500@mitre.org> <4E1F6AAD24975D4BA5B168042967394367567185@TK5EX14MBXC283.redmond.corp.microsoft.com> <514B4E28.7000309@mitre.org> <255B9BB34FB7D647A506DC292726F6E1150BD3FB27@WSMSG3153V.srv.dir.telstra.com> <51506934.4080104@mitre.org> In-Reply-To: <51506934.4080104@mitre.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readable names X-BeenThere: oauth@ietf.org X-Mailman-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, 26 Mar 2013 01:30:53 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 3/25/13 9:11 AM, Justin Richer wrote: > "Internationalization is the process of designing a software > application so that it can be adapted to various languages and > regions without engineering changes." (From > http://en.wikipedia.org/wiki/Internationalization_and_localization) > > What this means in our case is that you'd want a string that would > be usable on the widest variety of systems that you care about > without them having to do something special to handle it. For some, > that's going to mean ASCII. For others, it's going to mean some > common local script. Again, please read RFC 6365. ASCII means several things (is it a character encoding scheme, a coded character set, etc.?), but in these days of Unicode and UTF-8 it's least confusing to refer to it only as the ASCII range of characters within the Unicode coded character set since the characters in the ASCII range are represented using the same bytes under UTF-8 as they were back in the old days of the ASCII character encoding scheme. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRUPpFAAoJEOoGpJErxa2p+mgP/1XLmRz8HW7ki8YXNWZgKnb1 Nwt2DumjNMere7Q2kTr8fDjs3zmAxNM8HsNhO2tmTtTQ7Vxr9QtUftrLoM/TnXPA zKmyyEl5CUDntjZHHg8c5ab7/rEkdwA4dAAkKBb3yaQr7OFRrQ7XnmVo94QcBBKh 8ieGNV4E5QS6EwIE2V+h7blEfM8VlG0Fk3DFTtfvmcCXf5LFexmuKrMhwf2kmPZe cDiue+Vz75isM6YvVXjp15GSNEWPZS3zjwWuOu3nPbzkOXKgx2qmy3Kg1eE/V1jb kWWkotu3HFXvKT7pm52nTkfjjDGhY7VbM9dt7m1FukOlOb7L5MgxxAWVxaSFmpOg qctxdIcqwMBbbbJT+hTzB7/LBQtj8kXTiqe8AZLjAkJVEbZxkY5GBufG+MaX/M/y bJo0bojqc33sN+jhnSxRRCkr5K7z31L+b80SNGSmOK/wERdepzQcufqBmicgfOds ctdhFR3K/iXWMnMvBoDMTKSDVTVSUVX43b6ClYMQ/fGIoUl61StgIX7HuYDw3KDK iq80u+UF7FK2Ea4qjsMQi9YhnOKBG7DLjB0s249Zlc4nGtBy2RSCqQIUs/KWkPBa jFQiRLTMxbdLx0L0UYnncPr3ULsmkRbpkJF6C5CPdu4Skz6k16kgqcXdbzStBIZj xqwa939rbFMTwIcWSZE+ =lJMh -----END PGP SIGNATURE----- From stpeter@stpeter.im Mon Mar 25 18:32: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 8325021F886A for ; Mon, 25 Mar 2013 18:32:37 -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 OJW8UXwwk05B for ; Mon, 25 Mar 2013 18:32:37 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id F2E1B21F8853 for ; Mon, 25 Mar 2013 18:32:36 -0700 (PDT) Received: from [192.168.1.6] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6DCE040520; Mon, 25 Mar 2013 19:41:53 -0600 (MDT) Message-ID: <5150FAB0.3000109@stpeter.im> Date: Mon, 25 Mar 2013 19:32:32 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Justin Richer References: <51408B8B.9000800@mitre.org> <5141E2E6.9020701@aol.com> <5141E671.2050708@mitre.org> <4E1F6AAD24975D4BA5B16804296739436750F5E2@TK5EX14MBXC283.redmond.corp.microsoft.com> <5149F092.7070902@mitre.org> <4E1F6AAD24975D4BA5B168042967394367565FEF@TK5EX14MBXC283.redmond.corp.microsoft.com> <5149F534.1040500@mitre.org> <4E1F6AAD24975D4BA5B168042967394367567185@TK5EX14MBXC283.redmond.corp.microsoft.com> <514B4E28.7000309@mitre.org> <515069D4.2040006@mitre.org> In-Reply-To: <515069D4.2040006@mitre.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readable names X-BeenThere: oauth@ietf.org X-Mailman-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, 26 Mar 2013 01:32:37 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 3/25/13 9:14 AM, Justin Richer wrote: > No problem, it's important that we be very precise about this bit > of text. There are many terms in this space with subtle differences > between them, so I'm glad to have others with more experience > reading over it. RFC 6365 is your friend. :-) And no, I have not read the entire thread on the topic here, but if pressed into service I will review the proposed text. This i18n stuff can be tricky. ;-) Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRUPqwAAoJEOoGpJErxa2pqGEP/AsJ+6Tknwh/KinjSazu4J+W ENn4S3g4xmslGIyePDSZMM9gu2+/HEVREsS+g3dN7luraQSnRgKGNJsykyk2oXPf /SoOzL9m2Y4KfF6sMcMH4wBizfd5AiravqMcVJKgBfmmu3L/F4tjr5+b5IqdLZGq 8gST/SUCwtTGcK/Une8Hl5x+DBb0qgJz30gv3fbuC0R6XRwuPZuX+cvrCoUTYVB9 hJGF26QS7F08Kexc5liRRJqbmkb2Y5W0d5SY4d/+il2VyUkHbyg4FlNcruGrQsHk F3r5LId57ghobD9RaXj16uQHMRgSgNgslIjYIFDobWgB55gYckNmMw6h3tX3VCih UeRHLltd3s+zYCAf6pSBmcej8H3bR3TnCIuK7NqsqBfrQDDAFok9WECyjxHkc7xt tPltZmBg/W+Xi4qEEkk+hf+HoeWh0/4XXnmiIh10gvuJJjbul60LeaCM1VLJo0Nj WbMJfQv1kY4Dh+OpVzW+41WXYDPJOUVzXlR7EIDopob7JEhRvPnMVRFTAueCI2x7 6s56RVOXDRGXOygcX+3A+WuzqRX0HK7PYdEjOdnhNklBaCnbCCVTQPTGvzWsN/Dr 2dP2tz5sCTzzylbx+TwmMb8m5C9D1/DYN8e2la4eZQf3Vp+HQpMCvQEohWcYp/34 PnvAa39wUT+2hF0fnDxH =4HvZ -----END PGP SIGNATURE----- From Michael.Jones@microsoft.com Mon Mar 25 18:40:04 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 4AD8921F84E2 for ; Mon, 25 Mar 2013 18:40:04 -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=[AWL=0.001, 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 PQECCnAUDxWt for ; Mon, 25 Mar 2013 18:40:03 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0212.outbound.protection.outlook.com [207.46.163.212]) by ietfa.amsl.com (Postfix) with ESMTP id 0FFEA21F84E0 for ; Mon, 25 Mar 2013 18:40:02 -0700 (PDT) Received: from BY2FFO11FD006.protection.gbl (10.173.161.200) by BL2FFO11HUB001.protection.gbl (10.173.161.19) with Microsoft SMTP Server (TLS) id 15.0.651.3; Tue, 26 Mar 2013 01:37:37 +0000 Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD006.mail.protection.outlook.com (10.1.14.127) with Microsoft SMTP Server (TLS) id 15.0.651.3 via Frontend Transport; Tue, 26 Mar 2013 01:37:36 +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; Tue, 26 Mar 2013 01:37:35 +0000 From: Mike Jones To: Peter Saint-Andre Thread-Topic: [OAUTH-WG] Registration: Internationalization of Human-Readable names Thread-Index: AQHOJmACY5HOQV9nDkW4sYSziV3/rJiw8IwAgAWY1wCAADBbYIAAezGAgAABEmA= Date: Tue, 26 Mar 2013 01:37:34 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436758940D@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <51408B8B.9000800@mitre.org> <5141E2E6.9020701@aol.com> <5141E671.2050708@mitre.org> <4E1F6AAD24975D4BA5B16804296739436750F5E2@TK5EX14MBXC283.redmond.corp.microsoft.com>, <5149F092.7070902@mitre.org> <4E1F6AAD24975D4BA5B168042967394367565FEF@TK5EX14MBXC283.redmond.corp.microsoft.com> <5149F534.1040500@mitre.org> <4E1F6AAD24975D4BA5B168042967394367567185@TK5EX14MBXC283.redmond.corp.microsoft.com> <514B4E28.7000309@mitre.org> <255B9BB34FB7D647A506DC292726F6E1150BD3FB27@WSMSG3153V.srv.dir.telstra.com> <51506934.4080104@mitre.org> <4E1F6AAD24975D4BA5B1680429673943675881FE@TK5EX14MBXC283.redmond.corp.microsoft.com> <5150F91B.1030603@stpeter.im> In-Reply-To: <5150F91B.1030603@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.72] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 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)(33656001)(73894001)(56816002)(54316002)(74662001)(46102001)(63696002)(80022001)(53806001)(50986001)(47976001)(44976002)(621065001)(56776001)(66066001)(54356001)(47776003)(20776003)(47736001)(55846006)(49866001)(65816001)(4396001)(23676001)(50466001)(16406001)(47446002)(79102001)(51856001)(69226001)(74502001)(76482001)(77982001)(59766001)(31966008); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB001; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 079756C6B9 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readable names X-BeenThere: oauth@ietf.org X-Mailman-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, 26 Mar 2013 01:40:04 -0000 SGkgUGV0ZXIsDQoNCkZhaXIgZW5vdWdoLiAgSSdsbCB0YWtlIGFuIGFjdGlvbiBpdGVtIHRvIHJl YWQgUkZDIDYzNjUgYW5kIHJldmlldyB0aGUgcmVsYXRlZCB0ZXh0IGFjY29yZGluZ2x5Lg0KDQpU aGUgbWFpbiBwb2ludCBvZiBteSBjb21tZW50YXJ5IHdhcyB0aGF0IHRoZSBwcm9jZXNzaW5nIG9m IHRoZSBwYXJzZWQgSlNPTiB3b3VsZCBiZSB0aGUgc2FtZSBubyBtYXR0ZXIgd2hhdCB0aGUgb3Jp Z2luYWwgZW5jb2RpbmcgdXNlZCB3YXMuDQoNCkZvciB3aGF0IGl0J3Mgd29ydGgsIEkgdGhpbmsg dGhhdCB0aGUgdHdvIHBhcmFncmFwaHMgcXVvdGVkIGZyb20gdGhlIHJlY2VudCBPcGVuSUQgQ29u bmVjdCBSZWdpc3RyYXRpb24gZHJhZnQgdXNlIHRoZSB0ZXJtaW5vbG9neSBjb3JyZWN0bHkgKGJ1 dCBhZ2FpbiwgSSdsbCByZWFkIFJGQyA2MzY1IGluIGEgYml0IGFuZCB0cnkgdG8gY2hlY2sgZm9y IG15c2VsZikuICBJZiB0aGV5IGRvbid0IChzaW5jZSB5b3UncmUgdm9sdW50ZWVyaW5nIHRvIHJl YWQgLCBicmF2ZSBtYW4gdGhhdCB5b3UgYXJlIDotKSApLCBzdWdnZXN0ZWQgY29ycmVjdGlvbnMg d291bGQgYmUgYXBwcmVjaWF0ZWQuICBUaGV5J3JlIHJlcGVhdGVkIGJlbG93Li4uDQoNCgkJCQlU aGFua3MgYWdhaW4sDQoJCQkJLS0gTWlrZQ0KDQpIdW1hbi1yZWFkYWJsZSBDbGllbnQgTWV0YWRh dGEgdmFsdWVzIGFuZCBDbGllbnQgTWV0YWRhdGEgdmFsdWVzIHRoYXQgcmVmZXJlbmNlIGh1bWFu LXJlYWRhYmxlIHZhbHVlcyBNQVkgYmUgcmVwcmVzZW50ZWQgaW4gbXVsdGlwbGUgbGFuZ3VhZ2Vz IGFuZCBzY3JpcHRzLiBGb3IgZXhhbXBsZSwgdmFsdWVzIHN1Y2ggYXMgY2xpZW50X25hbWUsIHRv c191cmksIHBvbGljeV91cmksIGxvZ29fdXJpLCBhbmQgY2xpZW50X3VyaSBtaWdodCBoYXZlIG11 bHRpcGxlIGxvY2FsZS1zcGVjaWZpYyB2YWx1ZXMgaW4gc29tZSBDbGllbnQgcmVnaXN0cmF0aW9u cy4NCg0K4oCmDQoNCklmIHN1Y2ggYSBodW1hbi1yZWFkYWJsZSBmaWVsZCBpcyBzZW50IHdpdGhv dXQgYSBsYW5ndWFnZSB0YWcsIHBhcnRpZXMgdXNpbmcgaXQgTVVTVCBOT1QgbWFrZSBhbnkgYXNz dW1wdGlvbnMgYWJvdXQgdGhlIGxhbmd1YWdlLCBjaGFyYWN0ZXIgc2V0LCBvciBzY3JpcHQgb2Yg dGhlIHN0cmluZyB2YWx1ZSwgYW5kIHRoZSBzdHJpbmcgdmFsdWUgTVVTVCBiZSB1c2VkIGFzLWlz IHdoZXJldmVyIGl0IGlzIHByZXNlbnRlZCBpbiBhIHVzZXIgaW50ZXJmYWNlLiBUbyBmYWNpbGl0 YXRlIGludGVyb3BlcmFiaWxpdHksIGl0IGlzIFJFQ09NTUVOREVEIHRoYXQgYW55IGh1bWFuLXJl YWRhYmxlIGZpZWxkcyBzZW50IHdpdGhvdXQgbGFuZ3VhZ2UgdGFncyBjb250YWluIHZhbHVlcyBz dWl0YWJsZSBmb3IgZGlzcGxheSBvbiBhIHdpZGUgdmFyaWV0eSBvZiBzeXN0ZW1zLg0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUGV0ZXIgU2FpbnQtQW5kcmUgW21haWx0bzpz dHBldGVyQHN0cGV0ZXIuaW1dIA0KU2VudDogTW9uZGF5LCBNYXJjaCAyNSwgMjAxMyA2OjI2IFBN DQpUbzogTWlrZSBKb25lcw0KQ2M6IEp1c3RpbiBSaWNoZXI7IE1hbmdlciwgSmFtZXMgSDsgb2F1 dGhAaWV0Zi5vcmcgV0cNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFJlZ2lzdHJhdGlvbjogSW50 ZXJuYXRpb25hbGl6YXRpb24gb2YgSHVtYW4tUmVhZGFibGUgbmFtZXMNCg0KLS0tLS1CRUdJTiBQ R1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBMQ0KDQpPbiAzLzI1LzEzIDEyOjA4IFBN LCBNaWtlIEpvbmVzIHdyb3RlOg0KPiBGWUksIHRoZSBmb2xsb3dpbmcgdmVyc2lvbiBvZiB0aGlz IHdvcmRpbmcgd2FzIGluY29ycG9yYXRlZCBpbnRvIHRoZSANCj4gT3BlbklEIENvbm5lY3QgUmVn aXN0cmF0aW9uIHNwZWMuICBJIGFsc28gZm91bmQgdGhlIHBocmFzZSANCj4g4oCcaW50ZXJuYXRp b25hbGl6ZWQgVVRGLTggc3RyaW5n4oCdIGFtYmlndW91cyBhbmQgc28gcmV2aXNlZCBpdC4NCj4g QWxzbywgVVRGLTggaXMganVzdCBwbGFpbiB3cm9uZywgYXMgb25jZSB5b3XigJlyZSBpbiBKU09O IHlvdeKAmXJlIGp1c3QgDQo+IGRlYWxpbmcgd2l0aCBVbmljb2RlIHN0cmluZ3MsIHdoZXRoZXIg dGhleSB3ZXJlIG9yaWdpbmFsbHkgZW5jb2RlZCBpbiANCj4gVVRGLTgsIFVURi0xNiwgb3IgYW5v dGhlciBlbmNvZGluZyBiZWZvcmUgcGFyc2luZy4NCg0KTWlrZSBhbmQgb3RoZXJzLCBwbGVhc2Ug cmVhZCBSRkMgNjM2NSBhdCB0aGUgdmVyeSBsZWFzdCB0byBnZXQgc29tZSBvZiB0aGUgdGVybWlu b2xvZ3kgcmlnaHQgaGVyZS4gRm9yIGV4YW1wbGUsIGEgVW5pY29kZSBjb2RlIHBvaW50IGlzIHNp bXBseSBhIG51bWJlcmVkIHBvaW50IGluIGEgY29kZWQgY2hhcmFjdGVyIHNldCwgc2F5LCBVKzAz QzAgKHBpKS4NClRoYXQgY29kZSBwb2ludCBpcyB0aGUgc2FtZSB0aGluZyBubyBtYXR0ZXIgd2hl dGhlciBpdCBpcyB3cml0dGVuIG9uIGEgcGllY2Ugb2YgcGFwZXIsIG1lbnRpb25lZCBpbiBzcG9r ZW4gdGV4dCwgZXRjLiBJbiBhbiBlbGVjdHJvbmljIHJlcHJlc2VudGF0aW9uIG9uIHRoZSB3aXJl IG9yIGluIGEgZmlsZSwgdGhlIGNvZGUgcG9pbnQgTVVTVCBiZSBlbmNvZGVkIHVzaW5nIHNvbWV0 aGluZyBsaWtlIFVURi04ICh3aGljaCB3ZSBwcmVmZXIgaW4gSUVURiBwcm90b2NvbHMpIG9yIFVU Ri0xNiBvciB3aGF0ZXZlci4gU28gaXQgaXMgaW5jb3JyZWN0IHRvIHNheSB0aGF0ICJVVEYtOCBp cyBqdXN0IHBsYWluIHdyb25nLCBhcyBvbmNlIHlvdeKAmXJlIGluIEpTT04geW914oCZcmUganVz dCBkZWFsaW5nIHdpdGggVW5pY29kZSBzdHJpbmdzIi4gSXQgZG9lc24ndCB3b3JrIHRoYXQgd2F5 IQ0KDQpQZXRlcg0KDQotIC0tDQpQZXRlciBTYWludC1BbmRyZQ0KaHR0cHM6Ly9zdHBldGVyLmlt Lw0KDQoNCi0tLS0tQkVHSU4gUEdQIFNJR05BVFVSRS0tLS0tDQpWZXJzaW9uOiBHbnVQRy9NYWNH UEcyIHYyLjAuMTggKERhcndpbikNCkNvbW1lbnQ6IFVzaW5nIEdudVBHIHdpdGggVGh1bmRlcmJp cmQgLSBodHRwOi8vd3d3LmVuaWdtYWlsLm5ldC8NCg0KaVFJY0JBRUJBZ0FHQlFKUlVQa2FBQW9K RU9vR3BKRXJ4YTJwSm1VUC9pNGFuWmpMNXBpYTR2SlVBMVJhWTBIdA0KZWM2SXR6S0daUk9Fc0lQ TTlqdWNGdnJLeUZZbnZKQVJXWUhRbG9XZG52ODlDQ2UwWHpnWDlLcjdMb0xKdXUrOA0KQUhPb3NQ Nk5Xd3hNMlRSNVBMQzBha1lLZHlQbkM2emVuRXlkOTRmeDJRMTJMWEdtSUJONmczdXB2ZXFtanNL Vw0KRUlrNVZUUUxWMzB0WEllZ21OYlZaNnhiZmx3N3JuWHVSTGMwSFRUZXJ2QXZRU1ROOUs0cVZi b0RkRnlpdjNTaQ0Kb2FoemZ4YUVJT0hvMUVybGpLMlV6RWM1WVM3cFFqd2xQZXZ6TDJiYzg0Wkpt dWY5U3dURDZ2TFVFZXBzMHRBTw0KNmRSYjNCNWdzMlJGcnlMUUdKMy9NMEU0UkwrYVdjNHpWZDd0 YkZoNXdGNzJ1VUEybzJCd0VFNnZ5TWRmdUttbg0Kd2dZdE45VGt4ZzlEbE9RZGZYZzZGWTV0azRt cldML2kxdW0xTlhnVEl5NmI3bG9BWm5EN3lybGlZV2p0Z0JWZg0KS25zK1FaT0dnTzJta3dua0xQ STJLd1JIUmdYNEpuWGVEWllTMUtjZzl5c2NxL1Bka2IrOEJma05ibjQwVE84TQ0KZUV1cS9tdnZV M21vQUkzK1RNNkNiVkpBd1pxbVZOc1BpVnY0TTN0ekEwbGhnZGl0cStyT0hpUVJ2bm9Nd3B6UA0K TkxVQnUwQUpKVXMzZm5xZitZbEc2akNTNmxJVDlndy9ITUNqdDFWVnptK2hBK250cDVocVJCZFhJ MHhxTHlpTg0KTGxZVEk4VytCUlBibkI5YmhNWC9LS2dudnJLby81ekpaV21uMXUvR3p0U2FwR1A1 Y09yOXc3RFMvYmVZaUM5Sw0KNUxnRnBocnk4YWhrVG1SL0JuRDUNCj1VR1JwDQotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0NCg== From markdoristyne@hotmail.com Wed Mar 27 09:58: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 0B00521F91D1 for ; Wed, 27 Mar 2013 09:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.501 X-Spam-Level: *** X-Spam-Status: No, score=3.501 tagged_above=-999 required=5 tests=[BAYES_99=3.5, 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 SgNwRENg+18m for ; Wed, 27 Mar 2013 09:58:57 -0700 (PDT) Received: from snt0-omc1-s42.snt0.hotmail.com (snt0-omc1-s42.snt0.hotmail.com [65.54.61.79]) by ietfa.amsl.com (Postfix) with ESMTP id 77B9521F91C7 for ; Wed, 27 Mar 2013 09:58:57 -0700 (PDT) Received: from SNT144-DS6 ([65.55.90.7]) by snt0-omc1-s42.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Mar 2013 09:58:57 -0700 X-EIP: [RGmK07AnK+42aR84jaMP8YdhNnXAuhKH] X-Originating-Email: [markdoristyne@hotmail.com] Message-ID: From: "dorismark tyne" To: Date: Wed, 27 Mar 2013 12:58:51 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0087_01CE2AEA.D47738A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: MSN 9 Seal-Send-Time: Wed, 27 Mar 2013 12:58:51 -0400 X-MimeOLE: Produced By MSN MimeOLE V10.50.0008.2100 X-OriginalArrivalTime: 27 Mar 2013 16:58:57.0664 (UTC) FILETIME=[5F2BF000:01CE2B0C] Subject: [OAUTH-WG] Re X-BeenThere: oauth@ietf.org X-Mailman-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, 27 Mar 2013 16:58:58 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0087_01CE2AEA.D47738A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thank You. dmtyne ------=_NextPart_000_0087_01CE2AEA.D47738A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Thank You.
dmtyne
------=_NextPart_000_0087_01CE2AEA.D47738A0-- From internet-drafts@ietf.org Fri Mar 29 13:31: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 A19DB21F8E6A; Fri, 29 Mar 2013 13:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.528 X-Spam-Level: X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.072, 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 FFDFwDQO+le0; Fri, 29 Mar 2013 13:31:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C554221F8E79; Fri, 29 Mar 2013 13:31:21 -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 Message-ID: <20130329203121.23177.69222.idtracker@ietfa.amsl.com> Date: Fri, 29 Mar 2013 13:31:21 -0700 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-assertions-11.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 20:31:22 -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 : Assertion Framework for OAuth 2.0 Client Authentication = and Authorization Grants Author(s) : Brian Campbell Chuck Mortimore Michael B. Jones Yaron Y. Goland Filename : draft-ietf-oauth-assertions-11.txt Pages : 23 Date : 2013-03-29 Abstract: This specification provides a framework for the use of assertions with OAuth 2.0 in the form of a new client authentication mechanism and a new authorization grant type. Mechanisms are specified for transporting assertions during interactions with a token endpoint, as well as general processing rules. The intent of this specification is to provide a common framework for OAuth 2.0 to interwork with other identity systems using assertions, and to provide alternative client authentication mechanisms. Note that this specification only defines abstract message flows and processing rules. In order to be implementable, companion specifications are necessary to provide the corresponding concrete instantiations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-assertions There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-assertions-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-assertions-11 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Fri Mar 29 13:32: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 5DDF521F8E7A; Fri, 29 Mar 2013 13:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.513 X-Spam-Level: X-Spam-Status: No, score=-102.513 tagged_above=-999 required=5 tests=[AWL=0.087, 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 d8y66j-LSaUn; Fri, 29 Mar 2013 13:32:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F30A21F8EC2; Fri, 29 Mar 2013 13:32:53 -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 Message-ID: <20130329203253.4746.99757.idtracker@ietfa.amsl.com> Date: Fri, 29 Mar 2013 13:32:53 -0700 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-saml2-bearer-16.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 20:32:54 -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 : SAML 2.0 Profile for OAuth 2.0 Client Authentication and= Authorization Grants Author(s) : Brian Campbell Chuck Mortimore Michael B. Jones Filename : draft-ietf-oauth-saml2-bearer-16.txt Pages : 19 Date : 2013-03-29 Abstract: This specification defines the use of a SAML 2.0 Bearer Assertion as a means for requesting an OAuth 2.0 access token as well as for use as a means of client authentication. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-16 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-saml2-bearer-16 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Fri Mar 29 13:35:52 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 0A99221F8EDA; Fri, 29 Mar 2013 13:35:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.519 X-Spam-Level: X-Spam-Status: No, score=-102.519 tagged_above=-999 required=5 tests=[AWL=0.081, 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 0g5JSmM3oua5; Fri, 29 Mar 2013 13:35:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 495BE21F8EF2; Fri, 29 Mar 2013 13:35:51 -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 Message-ID: <20130329203551.4767.23022.idtracker@ietfa.amsl.com> Date: Fri, 29 Mar 2013 13:35:51 -0700 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-bearer-05.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 20:35:52 -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) Profile for OAuth 2.0 Client Authen= tication and Authorization Grants Author(s) : Michael B. Jones Brian Campbell Chuck Mortimore Filename : draft-ietf-oauth-jwt-bearer-05.txt Pages : 13 Date : 2013-03-29 Abstract: This specification defines the use of a JSON Web Token (JWT) Bearer Token as a means for requesting an OAuth 2.0 access token as well as for use as a means of client authentication. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-jwt-bearer-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Fri Mar 29 13:38: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 07EAE21F8F18; Fri, 29 Mar 2013 13:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.521 X-Spam-Level: X-Spam-Status: No, score=-102.521 tagged_above=-999 required=5 tests=[AWL=0.079, 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 PqQtw1F6i5W2; Fri, 29 Mar 2013 13:38:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1047A21F8F22; Fri, 29 Mar 2013 13:38:08 -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 Message-ID: <20130329203808.13164.56358.idtracker@ietfa.amsl.com> Date: Fri, 29 Mar 2013 13:38:08 -0700 Cc: oauth@ietf.org Subject: [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: Fri, 29 Mar 2013 20:38:09 -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 : 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=3Ddraft-ietf-oauth-dyn-reg-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From bcampbell@pingidentity.com Fri Mar 29 13:51: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 23B7D21F8FFB for ; Fri, 29 Mar 2013 13:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.574 X-Spam-Level: X-Spam-Status: No, score=-5.574 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SzTftgCx2yYD for ; Fri, 29 Mar 2013 13:51:22 -0700 (PDT) Received: from na3sys009aog118.obsmtp.com (na3sys009aog118.obsmtp.com [74.125.149.244]) by ietfa.amsl.com (Postfix) with ESMTP id BE21A21F8F00 for ; Fri, 29 Mar 2013 13:51:17 -0700 (PDT) Received: from mail-oa0-f72.google.com ([209.85.219.72]) (using TLSv1) by na3sys009aob118.postini.com ([74.125.148.12]) with SMTP ID DSNKUVX+xaLQI7+QtpgMOx4nV/xdpy2KyunK@postini.com; Fri, 29 Mar 2013 13:51:20 PDT Received: by mail-oa0-f72.google.com with SMTP id j6so5322126oag.7 for ; Fri, 29 Mar 2013 13:51:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:mime-version:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=pTxjSLbQGSENggwuzzo1C05tPNeoOynq0CmM0+0CM9k=; b=XkpqCA1GjyD4aMHjFMvoyg2BZHOCxZz9ae/JsXjqQ79ruo11WqYFo10TDAlKHEBmL7 dKe0UwOP5n1m+t2QAcBypaZbbLoENnrRO5ZZdYsP0A2IPjE8Nj/wPJrp7P6ui+jDXzCS duz104mnDPRXO5CBsj1kBs7kUg05fpyDovIzJDO5jBwUvPf+aP9cyotv649xHaqGdXcU Wcii47AiW5PsUJ++8h7dAZYKwWcOxEhwD3pJZz8OHNpWAbcWequ3kt80HgmXbS5kFKd1 EbCRZDgqP6xhP1TfxxWU6cgGpjA0ndLquWywxRteTyB44xJUFXK/JXb6ovUdIIhLx2CX UWIw== X-Received: by 10.42.126.133 with SMTP id e5mr2098011ics.17.1364590276910; Fri, 29 Mar 2013 13:51:16 -0700 (PDT) X-Received: by 10.42.126.133 with SMTP id e5mr2098008ics.17.1364590276811; Fri, 29 Mar 2013 13:51:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.91.99 with HTTP; Fri, 29 Mar 2013 13:50:46 -0700 (PDT) From: Brian Campbell Date: Fri, 29 Mar 2013 14:50:46 -0600 Message-ID: To: oauth Content-Type: multipart/alternative; boundary=20cf301b6431b6b20504d9166e78 X-Gm-Message-State: ALoCoQktcSi9XetkM2gMA9U1z6Di8qvn9hZald+SKUkdyhLgRsVh2YX6W0NfAH7+FrYp0WWV7mHD/eqI3CEL2b5291s+gWayZ8JWcG+upUyAnSaSviu/dhvTJnnHDIldSTJq10PhOU64 Subject: [OAUTH-WG] New Assertion Drafts Published X-BeenThere: oauth@ietf.org X-Mailman-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, 29 Mar 2013 20:51:23 -0000 --20cf301b6431b6b20504d9166e78 Content-Type: text/plain; charset=ISO-8859-1 New versions of all three OAuth related assertion documents have been published. New document titles, URLs and change logs are listed below. I've tried to address the comments and discuss issues from the IESG review as well as subsequent discussion and decisions that took place in Orlando. There have also been some comments and questions on the WG list, which I've attempted to address and clarify things where possible. Special thanks to Mike Jones for the editorial help with these. Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants http://tools.ietf.org/html/draft-ietf-oauth-assertions-11 SAML 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-16 JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-05 draft-ietf-oauth-assertions-11 o Addressed comments from IESG evaluation https:// datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ballot/. o Reworded Interoperability Considerations to state what identifiers, keys, endpoints, etc. need to be exchanged/agreed upon. o Added brief description of assertion to the into and included a reference to Section 3 (Framework) where it's described more. o Changed such that a self-issued assertion must (was should) have the client id as the issuer. o Changed "Specific Assertion Format and Processing Rules" to "Common Scenarios" and reworded to be more suggestive of common practices, rather than trying to be normative. Also removed lots of repetitive text in that section. o Refined language around audience, subject, client identifiers, etc. to hopefully be clearer and less redundant. o Changed title from "Assertion Framework for OAuth 2.0" to "Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants" to be more explicit about the scope of the document per http://www.ietf.org/mail-archive/web/oauth/current/msg11063.html. o Noted that authentication of the client per Section 3.2.1 of OAuth is optional for an access token request with an assertion as an authorization grant and removed client_id from the associated example. draft-ietf-oauth-saml2-bearer-16 o Changed title from "SAML 2.0 Bearer Assertion Profiles for OAuth 2.0" to "SAML 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants" to be more explicit about the scope of the document per http://www.ietf.org/mail-archive/web/oauth/current/ msg11063.html . o Fixed typo in text identifying the presenter from "or similar element, the" to "or similar element in the". o Numbered the list of processing rules. o Smallish editorial cleanups to try and improve readability and comprehensibility. o Cleaner split out of the processing rules in cases where they differ for client authentication and authorization grants. o Clarified the parameters that are used/available for authorization grants. o Added Interoperability Considerations section and info reference to SAML Metadata. o Added more explanatory context to the example in Section 4 . draft-ietf-oauth-jwt-bearer-05 o Changed title from "JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0" to "JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants" to be more explicit about the scope of the document per http://www.ietf.org/mail-archive/web /oauth/current/msg11063.html . o Numbered the list of processing rules. o Smallish editorial cleanups to try and improve readability and comprehensibility. o Cleaner split out of the processing rules in cases where they differ for client authentication and authorization grants. o Clarified the parameters that are used/available for authorization grants. o Added Interoperability Considerations section. o Added more explanatory context to the example in Section 4 . --20cf301b6431b6b20504d9166e78 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
New versions of all three OAuth related assertion docume= nts have been published.=A0 New document titles, URLs and change logs are l= isted below. I've tried to address the comments and discuss issues from= the = IESG review as well as subsequent discussion and decisions that took= place in Orlando. There have also been some comments and questions on the = WG list, which I've attempted to address and clarify things where pos= sible. Special thanks to Mike Jones for the editorial help with these.


Assertion Framework for OAuth 2.0 Client Authentication and Autho= rization Grants
http://tools.ietf.org/html/draft-ietf-<= span style=3D"background:none repeat scroll 0% 0% yellow" class=3D"">oauth<= /span>-assertions-11

S= AML 2.0 Profile for OAuth 2.0 Client Authentication and Authorizat= ion Grants
http://tools.ietf.org/html/draft-ietf-oauth-saml2-bear= er-16

J= SON Web Token (JWT) Profile for OAuth 2.0 Client Authentication = and Authorization Grants
http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-05<= br>

   draft-ietf-oauth-assertions-11

   o  Addressed comments from IESG evaluation https://
      datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ba=
llot/.

   o  Reworded Interoperability Considerations to state what
      identifiers, keys, endpoints, etc. need to be exchanged/agreed
      upon.

   o  Added brief description of assertion to the into and included a
      reference to Section 3 (Framework) where it's described =
more.

   o  Changed such that a self-issued assertion must (was should) have
      the client id as the issuer.

   o  Changed "Specific Assertion Format and Processing Rules" to
      "Common Scenarios" and reworded to be more suggestive of co=
mmon
      practices, rather than trying to be normative.  Also removed lots
      of repetitive text in that section.

   o  Refined language around audience, subject, client identifiers,
      etc. to hopefully be clearer and less redundant.


   o  Changed title from "Assertion Framework for OAuth 2.0" to
      "Assertion Framework for OAuth 2.0 Client Authentication and
      Authorization Grants" to be more explicit about the scope of the
      document per
      http://www.ietf.org/mail-archive/web/oauth/current/msg11063.htm=
l.

   o  Noted that authentication of the client per Section 3.2.1 of =
OAuth
      is optional for an access token request with an assertion as an
      authorization grant and removed client_id from the associated
      example.


   draft-ietf-oauth-saml2-=
bearer-16

   o  Changed title from "SAML 2.0 Bearer Assertion Profiles for OAuth
      2.0" to "SAML 2.0 Profile for OAuth 2.0 Client Authenti=
cation and
      Authorization Grants" to be more explicit about the scope of the
      document per http://www.ietf.org/mail-archive/web/oauth/current=
/
      msg11063.html.

   o  Fixed typo in text identifying the presenter from "or similar
      element, the" to "or similar element in the".

   o  Numbered the list of processing rules.


   o  Smallish editorial cleanups to try and improve readability and
      comprehensibility.

   o  Cleaner split out of the processing rules in cases where they
      differ for client authentication and authorization grants.

   o  Clarified the parameters that are used/available for authorization
      grants.

   o  Added Interoperability Considerations section and info reference
      to SAML Metadata.

   o  Added more explanatory context to the example in Section 4=
.



   draft-ietf-oauth-jwt-bearer-05

   o  Changed title from "JSON Web Token (JWT) Bearer Token Profil=
es for
      OAuth 2.0" to "JSON Web Token (JWT) Profile for OAuth 2.0 Client
      Authentication and Authorization Grants" to be more explicit abo=
ut
      the scope of the document per http://www.ietf.org/mail-archive/we=
b
      /oauth/current/msg11063.html.

   o  Numbered the list of processing rules.

   o  Smallish editorial cleanups to try and improve readability and
      comprehensibility.

   o  Cleaner split out of the processing rules in cases where they
      differ for client authentication and authorization grants.

   o  Clarified the parameters that are used/available for authorization
      grants.


   o  Added Interoperability Considerations section.

   o  Added more explanatory context to the example in Section 4.<=
/pre>
--20cf301b6431b6b20504d9166e78-- From jricher@mitre.org Fri Mar 29 13:55: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 65E1321F8E7A for ; Fri, 29 Mar 2013 13:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.382 X-Spam-Level: X-Spam-Status: No, score=-6.382 tagged_above=-999 required=5 tests=[AWL=0.217, 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 xenuABUgZ+Fv for ; Fri, 29 Mar 2013 13:55:01 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 97A1121F8BEB for ; Fri, 29 Mar 2013 13:55:00 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 333341F0297 for ; Fri, 29 Mar 2013 16:55:00 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 10CE71F023D for ; Fri, 29 Mar 2013 16:55:00 -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; Fri, 29 Mar 2013 16:54:40 -0400 Message-ID: <5155FF43.6070606@mitre.org> Date: Fri, 29 Mar 2013 16:53:23 -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: References: <20130329203808.13164.56358.idtracker@ietfa.amsl.com> In-Reply-To: <20130329203808.13164.56358.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [129.83.31.58] 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: Fri, 29 Mar 2013 20:55:03 -0000 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 From matake@gmail.com Fri Mar 29 20:56: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 1C26921F8CBE for ; Fri, 29 Mar 2013 20:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.594 X-Spam-Level: X-Spam-Status: No, score=-1.594 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=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 DrTthRMedyMk for ; Fri, 29 Mar 2013 20:56:04 -0700 (PDT) Received: from mail-da0-x234.google.com (mail-da0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id 811DB21F8CA6 for ; Fri, 29 Mar 2013 20:56:04 -0700 (PDT) Received: by mail-da0-f52.google.com with SMTP id f10so418633dak.25 for ; Fri, 29 Mar 2013 20:56:04 -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=D1Z2r9hcFkdVryoYBRIpEgjO6HeB7sP0AMd5d+NVrDc=; b=eJ+7luXHdmQnQP/VYy4EK/U1bkceQyoEE62rqNZye7J3wgK/cWL3joXmTbooJvCxh9 YhtNfZ6GuIks09W21Rw6edt8coJLKvSWGvjvgs9UB6rpDK3HHrT3Msw0SO75sUR2zYgu U/1FqOBxebKIN2Ss+qZcA8PL1w61SbGlCC4WeJeJlVqNB6nGUfRDFciW/nFFw18lmLyz sWPi536Wtng0adqfIWxBoIOQCHkbVaC85X4MeYkpVmUPk1NUY78VOYbktI5ntw7mBt8Q jP+C/6hdQGu4Wr2BCYdihMzdWwsxdmHQ+xUcIkIpk7rxE4S+8Ui8IwsAIDcZ/jr9b71H AqIA== X-Received: by 10.68.163.1 with SMTP id ye1mr6936560pbb.135.1364615764253; Fri, 29 Mar 2013 20:56:04 -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 1sm5013327pbg.18.2013.03.29.20.56.01 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 29 Mar 2013 20:56:02 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: nov matake In-Reply-To: <5155FF43.6070606@mitre.org> Date: Sat, 30 Mar 2013 12:55:59 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <6851D735-F609-4304-AFE6-3BAA35CE9FC4@gmail.com> References: <20130329203808.13164.56358.idtracker@ietfa.amsl.com> <5155FF43.6070606@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: Sat, 30 Mar 2013 03:56:05 -0000 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. >=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 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From matake@gmail.com Fri Mar 29 20:57: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 7F88321F8CBE for ; Fri, 29 Mar 2013 20:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.594 X-Spam-Level: X-Spam-Status: No, score=-1.594 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=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 Y2PezqJwGxwD for ; Fri, 29 Mar 2013 20:57:29 -0700 (PDT) Received: from mail-da0-x232.google.com (mail-da0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 75A7421F8CA6 for ; Fri, 29 Mar 2013 20:57:29 -0700 (PDT) Received: by mail-da0-f50.google.com with SMTP id t1so418237dae.9 for ; Fri, 29 Mar 2013 20:57:29 -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=jcbf46P3kBU9gtDNmKz+o0kBs5dHPZk9L/Niqu9cpVA=; b=hpeu/REqm2tlm/DlWWeVnEJg55/7jkeahuyLyanoYLbsg4pl8TUFaMgxfbrM8JtSSY 0afdhRpaF4hNGZ2xVyfnNzAtSQKF3MRwYVUEeo+k6tpR2WmYBBYirFiNBu/Q5o3wWISb NgWLNxxnU8HL5doti8igHocmi36EBn5CLBCaS4Mlp2g4XfVtWJusjXO8TwKpkaB1JPiO zQuFn/LsoBJxzImISCZcdkcVSKhuEOhFU6sGTxERYP+vEoGhhFFzboe6kE41Mdgt+BTP /b5dg2f0+PWmnjVwqrsElpM7hw5c1T4DrfXvm2Rxh4dfr23ZVIUcioIFzXG9RltKPQXc FIZw== X-Received: by 10.66.120.49 with SMTP id kz17mr7742416pab.133.1364615849182; Fri, 29 Mar 2013 20:57:29 -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 t1sm5787168pab.12.2013.03.29.20.57.26 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 29 Mar 2013 20:57:28 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: nov matake In-Reply-To: <6851D735-F609-4304-AFE6-3BAA35CE9FC4@gmail.com> Date: Sat, 30 Mar 2013 12:57:25 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <328E6FBA-30A1-49EF-A5A7-32EDC04EF48C@gmail.com> References: <20130329203808.13164.56358.idtracker@ietfa.amsl.com> <5155FF43.6070606@mitre.org> <6851D735-F609-4304-AFE6-3BAA35CE9FC4@gmail.com> 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: Sat, 30 Mar 2013 03:57:30 -0000 oops sorry, not draft07, but draft06. On 2013/03/30, at 12:55, nov matake wrote: > 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 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20